John Fine wrote: > 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? As far as I can see there's nothing wrong with the C code. It might be that there is something else going on, but a cut-down test case will show that, one way or the other. > 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++. The x86_64 ABI is here: http://refspecs.freestandards.org/elf/x86_64-abi-0.95.pdf > 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. Me either. That's why we need a test case. > 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. If so, it's a gcc bug either way. Both caller and callee were compiled by gcc. But we don't have enough information to determine what the cause of the problem really is. Andrew.
