|Mysterious triple test failures email@example.com (Nils M Holm) (2014-05-03)|
|Re: Mysterious triple test failures firstname.lastname@example.org (Kaz Kylheku) (2014-05-03)|
|Re: Mysterious triple test failures mrs@Kithrup.COM (2014-05-04)|
|Re: Mysterious triple test failures email@example.com (Nils M Holm) (2014-05-04)|
|Tripe test failure update firstname.lastname@example.org (Nils M Holm) (2014-05-04)|
|Re: Mysterious triple test failures email@example.com (2014-05-04)|
|Re: Tripe test failure update firstname.lastname@example.org (Nils M Holm) (2014-05-05)|
|[3 later articles]|
|From:||"Nils M Holm" <email@example.com>|
|Date:||Sat, 3 May 2014 21:38:13 +0200|
|Keywords:||errors, question, comment|
|Posted-Date:||03 May 2014 16:12:24 EDT|
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.
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
(where x---[y]--->z means "compile x with y to z"). Finally the
stage-1 and stage-2 compilers are compared. When they are equal,
the triple test is passed.
Now it has happened that this test failed, resulting in stage-1
and stage-2 compiler of identical size, but with tens of thousands
of differences. However, both compilers seem to work fine. The
differences are not in the symbol table, stripping the binaries
did not make any difference.
Further tests have shown that the assembly language output of
the differing compilers is identical.
This happened on 386-based OpenBSD and x86-64-based Linux systems.
So, what is going on here? Does anybody have an explanation?
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?
Please let me know what you think!
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
[Are the stage-0 and stage-1 assembly sources the same? The
first thing that occurs to me is that the code is laid out
differently so the variable-length branch logic has long
and short instructions in different places. -John]
Return to the
Search the comp.compilers archives again.