On 3/12/10, Iustin Pop <[email protected]> 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 <[email protected]> Date: Mar 10, 2010 10:17 AM Subject: Re: Incorrect casting? To: Marcin Baczyński <[email protected]> Cc: [email protected] 2010/3/9 Marcin Baczyński <[email protected]>: > 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; > } > > monst...@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) > monst...@yggdrasil /data/tmp $ ./a.out > 000000fe > 00000001 > > monst...@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) > monst...@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 > ----------------------- -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
