Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newspeer1.nac.net!border4.nntp.dca.giganews.com!backlog4.nntp.dca3.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED!nerds-end From: "Nils M Holm" Newsgroups: comp.compilers Subject: Re: Mysterious triple test failures Date: Sun, 4 May 2014 10:32:43 +0200 Organization: Compilers Central Lines: 71 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <14-05-007@comp.compilers> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: miucha.iecc.com 1399231825 17068 2001:470:1f07:1126:0:676f:7373:6970 (4 May 2014 19:30:25 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Sun, 4 May 2014 19:30:25 +0000 (UTC) Keywords: debug, comment Posted-Date: 04 May 2014 15:30:25 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com X-Original-Bytes: 3902 Xref: csiph.com comp.compilers:1232 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]