Re: Help needed to debug an armel build/unittest failure

[Martin Guy <martinwguy@gmail.com>]

On 3/12/10, Iustin Pop <iusty@k1024.org> wrote:
>  I also tried two compiler versions, 4.4 (4.4.3-1) fails unittests but 4.3
>  (4.3.4-6) passes them.
>
>  While trying to debug this under gcc 4.4, I managed to add some code to an
>  inlined function that makes the problem go away. Original function version:
>
>  inline int64 WireFormatLite::ZigZagDecode64(uint64 n) {
>   return (n >> 1) ^ -static_cast<int64>(n & 1);
>  }
>
>  I wanted to add some ugly logging to the function, so I modified it as
>  follows:
>
>  inline int64 WireFormatLite::ZigZagDecode64(uint64 n) {
>   int64 v = (n >> 1) ^ -static_cast<int64>(n & 1);
>   printf("zzd64:%llu r:%lli\n", n, v);
>   return v;
>  }
>
>  It seems this changes something, because now the unittests pass (inline,
>  optimization, problems?). I honestly don't know what's happening here,
>  but this seems more and more like some compiler-related issue (but not
>  necessarily 64-bit-related).

Well, GCC 4.4 does have some code-generation bugs that 4.3 and 4.5 don't.

Example: http://gcc.gnu.org/ml/gcc/2010-03/msg00108.html
Unfortunately the gcc list archiver was broken when someone replied so
I am forwarding the whole reply here, including the original message,
but it doesn't look much like the case you have found.

If you can mangle the code so that 4.4 compiles it correctly I guess
that would do it, or you could insist on gcc-4.3 for the moment, which
is also in squeeze.

    M

---------- Forwarded message ----------
From: Richard Guenther <richard.guenther@gmail.com>
Date: Mar 10, 2010 10:17 AM
Subject: Re: Incorrect casting?
To: Marcin Baczyński <marbacz@gmail.com>
Cc: gcc@gcc.gnu.org


2010/3/9 Marcin Baczyński <marbacz@gmail.com>:

> Hi,
 > the following piece of code produces different output on svn trunk and
 > gcc-4_4-branch:
 >
 > #include <stdio.h>
 > int main()
 > {
 >        struct { unsigned bar:1; } foo;
 >
 >        foo.bar = 0x1;
 >
 >        printf("%08x\n", (unsigned char)(foo.bar * 0xfe));
 >        printf("%08x\n", (unsigned char)(foo.bar * 0xff));
 >
 >        return 0;
 > }
 >
 > monstter@yggdrasil /data/tmp $ gcc -v
 > Using built-in specs.
 > Target: x86_64-unknown-linux-gnu
 > Configured with: ../gcc-svn/configure --enable-stage1-languages-c
 > --enable-languages=c,c++
 > Thread model: posix
 > gcc version 4.4.4 20100309 (prerelease) (GCC)
 > monstter@yggdrasil /data/tmp $ ./a.out
 > 000000fe
 > 00000001
 >
 > monstter@yggdrasil /data/tmp $ gcc -v
 > Using built-in specs.
 > COLLECT_GCC=gcc
 > COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
 > Target: x86_64-unknown-linux-gnu
 > Configured with: ../gcc-svn/configure --enable-stage1-languages-c
 > --enable-languages=c,c++
 > Thread model: posix
 > gcc version 4.5.0 20100309 (experimental) (GCC)
 > monstter@yggdrasil /data/tmp $ ./a.out
 > 000000fe
 > 000000ff
 >
 > Is there something illegal in this code or is it a bug somewhere?


Probably something that was fixed for 4.5 but not backported to 4.4.
 The 4.4 C frontend produces for the 2nd printf:

  printf ((const char * restrict) "%08x\n", (int) -foo.bar);

 while 4.5 does

  printf ((const char * restrict) "%08x\n", (int) -(unsigned char) foo.bar);

 I'm not sure where this difference comes from (and I can't convince
 myself that this is a real fix).  Please file a bugreport.

 Btw, 4.3 produced

  printf ((const char * restrict) (char *) "%08x\n", (int) (unsigned
 char) ((int) foo.bar * 255));

 and the same runtime result as 4.5.

 Thanks,
 Richard.

 > Thanks,
 > Marcin
 >
 -----------------------