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

Groups > comp.compilers > #1229

Re: Mysterious triple test failures

Show all headers | View raw

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. :)


>
> 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.

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.

> However, both compilers seem to work fine.

Do these tests execute with zero errors under Valgrind on a Linux box?

> 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!

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.

> 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?

Only if the assembly stage is responsible for the differences.

> Please let me know what you think!

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.

A bug could be causing some optimization or other code transformation decision
to be done differently.  If such a decision is semantics-preserving
(which such decisions often are) then the differing variants of the
translated code behave the same way.

It still points to a bug, which is why it's smart to do that comparison between
the stages.

You have a simple case here of a program compiled by two different C compilers
producing different output. How does that happen? I mean, let me count
the ways, right? Dependencies on orders of evaluation, uninitialized
storage, or numerous other "undefined behaviors". This is why a sweep with
a debugging tool like Valgrind wouldn't hurt.

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

Thread

Mysterious triple test failures "Nils M Holm" <nmh@t3x.org> - 2014-05-03 21:38 +0200
  Re: Mysterious triple test failures Kaz Kylheku <kaz@kylheku.com> - 2014-05-03 22:19 +0000
    Tripe test failure update "Nils M Holm" <nmh@t3x.org> - 2014-05-04 10:53 +0200
      Re: Triple test failure update Chris Dodd <cdodd@acm.org> - 2014-05-23 01:50 +0000
        Re: Triple test failure update "Nils M Holm" <nmh@t3x.org> - 2014-05-23 09:09 +0200
        Re: Triple test failure update alexfrunews@gmail.com - 2014-05-23 02:17 -0700
  Re: Mysterious triple test failures mrs@Kithrup.COM (Mike Stump) - 2014-05-04 04:47 +0000
  Re: Mysterious triple test failures alexfrunews@gmail.com - 2014-05-04 03:57 -0700
    Re: Tripe test failure update "Nils M Holm" <nmh@t3x.org> - 2014-05-05 10:30 +0200

csiph-web