[cfe-dev] clang bug? Miscompilation of array of unsigned long long

Eli Friedman eli.friedman at gmail.com
Fri Jul 30 15:28:43 PDT 2010


On Fri, Jul 30, 2010 at 12:42 PM, Edward Meewis
<ed at extraordinarymachine.nl> wrote:
>  On 27-07-10 11:32, Edward Meewis wrote:
>
> This still annoyed me, so today I dug a little deeper and tried to
> explore different compilation paths. Turns out the clang driver is
> likely at fault:
>
> Simplified test case:
> ---
> #include <stdio.h>
>
> unsigned long long globalArray[] = {0xFFFFFFFD00000000uLL};
>
> int main()
> {
>         unsigned long long t = 0xFFFFFFFD00000000uLL;
>
>         printf("%016llX, %016llu\n", t, t);
>         printf("%016llX, %016llu\n",
>                 globalArray[0], globalArray[0]);
>
>     return 0;
> }
> ---
>
> Compile to bitcode and execute:
>  > clang -emit-llvm -o arrTest.bc -c arrTest.c
>  > lli arrTest.bc
> FFFFFFFD00000000, 18446744060824649728
> FFFFFFFD00000000, 18446744060824649728
>
> Huh? That correct...
>
> Compile to assembly and execute:
>
>  >clang -o arrTest.asm -S arrTest.c
>  >clang -x assembler -o arrTest-clang arrTest.asm
>  >./arrTest-clang
> FFFFFFFD00000000, 18446744060824649728
> 0000FFFD00000000, 0281462091808768
>
> Incorrect. Let's try gcc...
>
>  > gcc -x assembler -o arrTest-gcc arrTest.asm
>  >./arrTest-gcc
> FFFFFFFD00000000, 18446744060824649728
> FFFFFFFD00000000, 18446744060824649728
>
> Huh? That's correct again. How does the driver call subsequent steps?
>  > clang -x assembler -o arrTest-clang arrTest.asm -###
> clang version 2.8 (trunk 109857)
> Target: i386-unknown-freebsd8.0
> Thread model: posix
>  "/usr/local/bin/as" "--32" "-o" "/home/emeewis/tmp/cc-hOA1tQ.o"
> "arrTest.asm"
>  "/usr/local/bin/ld" "--eh-frame-hdr" "-dynamic-linker"
> "/libexec/ld-elf.so.1" "-m" "elf_i386_fbsd" "-o" "arrTest-clang"
> "/usr/lib/crt1.o" "/usr/lib/crti.o" "/usr/lib/crtbegin.o"
> "/home/emeewis/tmp/cc-hOA1tQ.o" "-lgcc" "--as-needed" "-lgcc_s"
> "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
> "/usr/lib/crtend.o" "/usr/lib/crtn.o"
>
>  >gcc -x assembler -o arrTest-clang arrTest.asm -###
> Using built-in specs.
> Target: i386-undermydesk-freebsd
> Configured with: FreeBSD/i386 system compiler
> Thread model: posix
> gcc version 4.2.1 20070719  [FreeBSD]
>  "/usr/bin/as" "-o" "/home/emeewis/tmp/cciyh8y1.o" "arrTest.asm"
>  "/usr/bin/ld" "--eh-frame-hdr" "-dynamic-linker"
> "/libexec/ld-elf.so.1" "-o" "arrTest-clang" "/usr/lib/crt1.o"
> "/usr/lib/crti.o" "/usr/lib/crtbegin.o" "-L/usr/lib" "-L/usr/lib"
> "/home/emeewis/tmp/cciyh8y1.o" "-lgcc" "--as-needed" "-lgcc_s"
> "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
> "/usr/lib/crtend.o" "/usr/lib/crtn.o"
>
> The difference is in the --32 option that clang adds, but gcc doesn't.
>
> I'm guessing this is a platform detection problem. My initial
> observation was that the compiler-rt tests fails both on FreeBSD-8.0 and
> MinGW. Both are 32-bit environments running on 64 bit processors. (BSD
> is custom build 32 bit running on a 64-bit Atom processor). I suppose
> that's unusual, so I'm wondering whether it is worth filing a bug report?

Are you 100% sure that it's the assembler call at fault?  I don't see
how passing --32 to a 32-bit assembler could possibly break
anything...

-Eli




More information about the cfe-dev mailing list