[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Pascal, I still see the bug in a very recent gcc, see below.

John


[regehr@gamow ~]$ cat foo.c
#include <stdio.h>

signed char g_2 = (-6L);
int R;

main()
{
  R = ((g_2 ^ 0U) <= (-4L));
  printf("long:%u int:%u R:%d\n", (unsigned)sizeof(long),
(unsigned)sizeof(int), R);
  return R;
}
[regehr@gamow ~]$ current-gcc foo.c
[regehr@gamow ~]$ ./a.out
long:8 int:4 R:0
[regehr@gamow ~]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r172662-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto --prefix=/home/regehr/z/compiler-install/gcc-r172662-install --program-prefix=r172662- --enable-languages=c,c++ 
Thread model: posix
gcc version 4.7.0 20110418 (experimental) (GCC)





On 4/18/11 1:30 PM, Pascal Cuoq wrote:

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