Re: bug in objc_alignof_type

[Richard Frith-Macdonald]

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.