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

[Dimitry Andric]

On 2010-08-01 16:52, Edward Meewis wrote:
> clang asm with old as:
> clang -o arrTest-clang.asm -S arrTest.c
> /usr/bin/ld -o arrTest-clang-oldas arrTest-clang-oldas.o ${LINKOPTS}
> ./arrTest-clang-oldas
> FFFFFFFD00000000, 18446744060824649728
> FFFFFFFD00000000, 18446744060824649728
> 
> clang asm with new as:
> /usr/local/bin/as -o arrTest-clang-newas.o arrTest-clang.asm
> /usr/local/bin/ld -o arrTest-clang-newas arrTest-clang-newas.o ${LINKOPTS}
> ./arrTest-clang-newas
> FFFFFFFD00000000, 18446744060824649728
> 0000FFFD00000000, 0281462091808768

This looks like a bug in GNU as 2.20.1, at least on FreeBSD.  If I
assemble this simple fragment of the assembly produced by clang:

	.file	"quadtest.s"
	.type	globalArray, at object
	.data
	.globl	globalArray
	.align	16
globalArray:
	.quad	542196645677236224
	.quad	-12884901888
	.quad	0
	.quad	542196645677236224
	.size	globalArray, 32

with as 2.20.1, the resulting .o file looks like this:

Contents of section .data:
 0000 00000000 fa448607 00000000 fdff0000  .....D..........
 0010 00000000 00000000 00000000 fa448607  .............D..

You can clearly see the faulty 64-bit constant at offset 0x8.  If you
assemble the same file with as 2.15 (the FreeBSD system as), you get an
.o file that looks like this:

Contents of section .data:
 0000 00000000 fa448607 00000000 fdffffff  .....D..........
 0010 00000000 00000000 00000000 fa448607  .............D..

and there the constant is fine.

I am not sure if this is a binutils bug on FreeBSD, or in general.  Can
someone please try the above assembly fragment on e.g. Linux or Mac OS?

The reason that all this does not go wrong with gcc, is that it does not
produce ".quad" statements in the assembly; the globalArray declaration
is done as follows, in 32-bit chunks:

globalArray:
	.long	0
	.long	126239994
	.long	0
	.long	-3
	.long	0
	.long	0
	.long	0
	.long	126239994