Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #1232

Re: Mysterious triple test failures

Show key headers only | View raw

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]

Back to comp.compilers | Previous | Next | Find similar | Unroll thread

Thread

Re: Mysterious triple test failures "Nils M Holm" <nmh@t3x.org> - 2014-05-04 10:32 +0200

csiph-web