[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug in objc_alignof_type
From: |
Richard Frith-Macdonald |
Subject: |
Re: bug in objc_alignof_type |
Date: |
Wed, 9 Apr 2003 09:27:25 +0100 |
On Tuesday, April 8, 2003, at 11:16 pm, Frederic De Jaeger wrote:
In the case of the double type, objc_alignof_type answers 8. Thus,
the result of that computation is that offset is incremented by 4 in
order to align on double word boundary. Offset will be set to 16
instead of 12, with all the funny consequences.
Apparently, it looks like a bug of gcc. Does it ?
I've spent some time investigating this, and my conclusion is not a
happy one.
Testing on the intel boxes I have available ...
In gcc-2.91.66 __alignof__(double) used to generate 4
In gcc-3.0 it generates 8
In gcc-3.4 it generates 8
On the face of it, that change is an obvious bug, but when you read the
documentation
of __alignof__ (for all three versions of the compiler I tested) you
find that the returned
value is the 'recommended' value rather than the actual value.
Now that doesn't make much sense to me ... if the recommended alignment
for double
has changed to 8, why hasn't the actual alignment changed too ... or to
put it another
way, why would gcc generate code using an alignment other than the one
it recommends?
And what's the use of __alignof__ if the value it returns is not the
actual one used?
The objc runtime library (and several places in the GNUstep base
library) has code that
assumes that __alignof__ provides the actual type alignment. The only
workaround I can
see is to abandon __alignof__ and use autoconf to build a configure
script for the objc
runtime which will check the actual alignment used, then change
gnustep-base to use
objc_alignof_type exclusively, rather than using __alignof__ for simple
types.
Anyway ... it's perhaps a documented 'feature' of gcc, but if you tell
them its a bug (and
ask what the use of __alignof__ is if it doesn't return the values gcc
isself uses) they
might fix the compiler.
I'd be interested to hear what response you get from the gcc
maintainers anyway.