Re: [csmith-dev] Bug in GCC LP64 targets

[Pascal Cuoq <pascal.cuoq@gmail.com>]

On Mon, Apr 18, 2011 at 8:47 PM, John Regehr <regehr@cs.utah.edu> wrote:
> Ok I looked more closely and it seems that Jakub believes this (or a related
> issue) is fixed.
>
> So I think it should be reported.  I'm happy to do it if you don't want to.

Well, I'm still in the middle of bootstrapping GCC's SVN version...

UPDATE: Although GCC is still compiling its Java front-end, I was able
to install the C part and the bug is gone in SVN version 172652. There
is no need to report.

> Nice job with the testcase reduction Pascal :).  How long did it take?

This one was quick. I have switched to testing and debugging the
x86_64 target of Frama-C's value analysis. When a difference between
64-bit analysis and 64-bit compilation comes up, my first step is to
compile and analyze in 32-bit, in case that exposes the bug
immediately as a 64-bit target analysis platform bug.

In this case, the program was behaving the same when compiled as
32-bit or 64-bit, and the analyses traces on the other hand were
different for the two platforms. The expression where the analyses
diverged was the one you have seen. It was a lucky chance that this
let me find it in a few minutes, since both analyses were correct, and
the compiler's bug was to generate executables that computed the same
thing. :)

By the way, I used to think that extensive use of intXX_t types made
Csmith-generated programs absolutely portable, but this is an example
of target platform nuances changing the meaning of a Csmith-generated
program (not that there is anything wrong with that).

Pascal