Alignment issue on x86_64?

[John Fine]

Andrew Haley wrote:
>
> Then this is probably a bug in gcc.  I'd debug it a bit more
> then start working on a cut-down test case.
>   
Is the idea that this is a bug in gcc based on something specific in the 
ABI?

Where is the ABI documentation ?  I tried to find it.  I found GCC C++ 
ABI documentation that was too specific to IA64 to be useful otherwise 
(despite comments I found in many other places saying that IA64 ABI 
applies to more than IA64.  I found x86_64 ABI documentation with no 
connection to GCC and little to C++.

If the issue of this thread is a gcc bug, you still would need a specify 
ABI (gcc, C++, X86_64) to answer the question of whether it is a bug in 
the compilation of the calling code discussed in this thread vs. a bug 
in the compilation of the called code inside XGetWindowProperty.

The info posted in this thread is fairly convincing that the issue is 
not a bug in the calling code itself, though I wouldn't rule out the 
possibility that we're all missing something and the bug is actually in 
the calling code.

But my next guess would be that the bug is in the called code (the 
source code of XGetWindowProperty or something it calls).  I haven't 
looked up that source code.

Maybe it is a gcc bug.  But why jump at that theory before checking more 
likely things.

The info posted in this thread seems to show that a 32 bit value was 
passed from caller to callee as a 64 bit value with the low order 32 
bits correct and the high order 32 uninitialized (those uninitialized 
bits then depend on the sequence within some prior activity).

Both ABI documents I mentioned above make clear that a 32 bit value 
would be passed as 64 bits.  Neither makes clear whether the high 32 
bits should be defined under those conditions.  The x86_64 ABI makes it 
clear that passing a bool as 64 bits requires clearing the high 63 
bits.  Right near there, it pointedly fails to comment on high bits when 
passing 8, 16 or 32 bit objects as 64.  That failure implies that the 
high bits are undefined, but that should have been explicit one way or 
the other.

Assuming the ABI makes those bits undefined, the bug is in the called 
code (in its source or in the way gcc compiled it) for using undefined 
bits, not in the compilation of the calling code.