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.
