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

[Jordy Rose]

FWIW, I don't see the error on OS X. Did you check the assembly file, to
make sure it's not LLVM CodeGen's fault? Mine accesses both words of
globalArray.


On Fri, 30 Jul 2010 15:28:43 -0700, Eli Friedman <eli.friedman at gmail.com>
wrote:
> 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
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev