Re: Mysterious triple test failures

"Nils M Holm" <>
Sun, 4 May 2014 10:32:43 +0200

          From comp.compilers

Related articles
Mysterious triple test failures (Nils M Holm) (2014-05-03)
Re: Mysterious triple test failures (Kaz Kylheku) (2014-05-03)
Re: Mysterious triple test failures mrs@Kithrup.COM (2014-05-04)
Re: Mysterious triple test failures (Nils M Holm) (2014-05-04)
Re: Mysterious triple test failures (2014-05-04)
| List of all articles for this month |

From: "Nils M Holm" <>
Newsgroups: comp.compilers
Date: Sun, 4 May 2014 10:32:43 +0200
Organization: Compilers Central
Keywords: debug, comment
Posted-Date: 04 May 2014 15:30:25 EDT

On 04 May 2014, Kaz Kylheku <> wrote:
> On 2014-05-03, Nils M Holm <> 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]

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.