|Mysterious triple test failures firstname.lastname@example.org (Nils M Holm) (2014-05-03)|
|Re: Mysterious triple test failures email@example.com (Kaz Kylheku) (2014-05-03)|
|Re: Mysterious triple test failures mrs@Kithrup.COM (2014-05-04)|
|Re: Mysterious triple test failures firstname.lastname@example.org (Nils M Holm) (2014-05-04)|
|Re: Mysterious triple test failures email@example.com (2014-05-04)|
|From:||"Nils M Holm" <firstname.lastname@example.org>|
|Date:||Sun, 4 May 2014 10:32:43 +0200|
|Posted-Date:||04 May 2014 15:30:25 EDT|
On 04 May 2014, Kaz Kylheku <email@example.com> wrote:
> On 2014-05-03, Nils M Holm <firstname.lastname@example.org> wrote:
> > In the recent months, several people who ported and/or used my
> > SubC compiler reported that the triple test failed, but the
> > compiler still worked fine.
> If you don't understand it, who can? Haha.
> This isn't real-time-event-processing software with nonrepeatable
> inputs and scheduling patterns. :)
But it almost looks like it! :-)
> > I am running the triple test as follows:
> > Subc sources ---[ third-party C compiler ]---> stage-0 SubC
> > Subc sources ---[ stage-0 SubC ]---> stage-1 SubC
> > Subc sources ---[ stage-1 SubC ]---> stage-2 SubC
> It means you have some uninitialized variable or something which leads
> the third-party-C-compiled SubC to write different code from the
> SubC-compiled SubC.
Then why is the assembly language output of stage-1 and stage-2 identical?
> Do these tests execute with zero errors under Valgrind on a Linux box?
Have never used valgrind, will have a look at it.
> > Further tests have shown that the assembly language output of
> > the differing compilers is identical.
> But that of stage-0 and stage-1 isn't identical: they produce
> different output when compiling SubC. Necessarily so: the stages use
> completely different compilers. But those outputs, in turn, have a different
> behavior: they produce different code!
Of course, stage-0 and stage-1 are comletely different compilers.
However, they accept the same input language and *should* produce the
same code. Indeed they *do* generate the same assembly language output
on all supported platforms. Only the binaries differ, and that's
beyond the control of the compiler, since I am using the system's
assembler and linker.
> If you were to iterate and make a stage-3 with stage-2, it would probably come
> out identical to stage-2. I.e. there is a "fixed point" when you feed
> the compiler into itself.
As far as I see it, the fixed point is at stage-2.
Exactly the same thing happens between stage-2 and stage-3:
same assembly, different binaries.
> > And: to work around the problem, I thought about comparing the
> > assembly output of the compilers instead of the binaries. This
> > should yield the same results, shouldn't it?
> Only if the assembly stage is responsible for the differences.
It has to be the assembler or linker, because the compiler output of
stages 1,2,3 is identical.
> Disable all special code-generation options like optimizations.
> If that makes the problem go away, re-introduce them one by one until
> a difference shows up.
The compiler is bootstrapped with "cc -o scc0 file...". No magic here.
I think I can say with certainty at this point that the reason for the
differing binaries lies in the Linux assembler and/or linker.
[You do know that object files include time stamps, don't you? -John]
Return to the
Search the comp.compilers archives again.