Re: Mysterious triple test failures

On 04 May 2014, Kaz Kylheku <kaz@kylheku.com> wrote:
> On 2014-05-03, Nils M Holm <nmh@t3x.org> wrote:
> > In the recent months, several people who ported and/or used my
> > SubC compiler[1] 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 comp.compilers page.
Search the comp.compilers archives again.