This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Alignment issue on x86_64?
John Fine a écrit :
I don't think that is an alignment issue. What you wrote isn't even
convincing that there is anything wrong with the way type was passed.
But I don't know what exactly an Atom is, so I'm not sure how it should
be passed. Most importantly, how many bits are there in an Atom as
compiled for your architecture.
An Atom is a standard X11 object ID. There's a first typedef from Atom
to CARD32, and depending on the architecture, CARD32 is defined like so:
#ifdef LONG64
typedef unsigned long CARD64;
typedef unsigned int CARD32;
#else
typedef unsigned long CARD32;
#endif
#if !defined(WORD64) && !defined(LONG64)
typedef unsigned long long CARD64;
#endif
(this is taken from <X11/Xmd.h>)
So I believe on x86_64, that would end up being "unsigned int".
1) It is correct to pass an Atom as 32 bits with the high 32 undefined,
and the called routine correctly uses it that way and you are confused
by gdb and your problem is somewhere else.
2) It is correct to pass an Atom as 32 bits with the high 32 undefined,
but the called routine incorrectly uses the high bits.
3) It is incorrect to pass an Atom as 32 bits with the high 32 undefined.
Atom being such a "simple" integer type, I'm not really sure what to do
here.
Thanks for your help
--
Rémi Cardona
LRI, INRIA
remi.cardona@lri.fr
remi@gentoo.org