On Sun, 25 Jun 2006, Seongbae Park wrote:
> On 6/25/06, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > > So, something obviously wrong with
> > >
> > > struct max_alignment {
> > > char c;
> > > union {
> > > HOST_WIDEST_INT i;
> > > long double d;
> > > } u;
> > > };
> > >
> > > /* The biggest alignment required. */
> > >
> > > #define MAX_ALIGNMENT (offsetof (struct max_alignment, u))
> > >
> > > for SPARC 32bit?
> >
> > I don't think so, the ABI says 8 in both cases.
> >
> > Note that bootstrap doesn't fail on SPARC/Solaris 2.[56] and (presumably)
> > SPARC/Linux, which have HOST_WIDE_INT == 32, whereas SPARC/Solaris 7+ have
> > HOST_WIDE_INT == 64. All are 32-bit compilers.
> >
> > Bootstrap doesn't fail on SPARC64/Solaris 7+ either, for which the ABI says
> > 16
> > for the alignment in both cases. They are 64-bit compilers.
>
> SPARC psABI3.0 (32bit version) defines long double as 8 byte aligned.
> SCD4.2, 64bit version, defines long double as 16 byte aligned with some caveat
> (which essentially says long double can be 8-byte aligned in some cases
> - fortran common block case - but the compiler should assume
> 16-byte unless it can prove otherwise).
> On 32bit ABI, there's also a possiblity of "double"s being only 4-byte aligned
> when a double is passed on the stack.
>
> I don't know enough about gcc's gc to know whether the above can trip it over,
> but the memory allocation (malloc and the likes) shouldn't be a
> problem as long as
> it returns 8-byte aligned block on 32bit and 16-byte aligned on 64bit.
If the above (MAX_ALIGNMENT) is not 8 byte aligned on 32bit and 16 byte
aligned on 64bit then we might allocate objects from a malloced page
(4096bytes, e.g.) of sub-objects of size 24, which would be not 16 byte
aligned for a requested storage of 16 bytes. (I just made up the numbers
for illustration, in this exact way it cannot happen)
So, allocation via ggc_malloc only guarantees alignment up to
MAX_ALIGNMENT, and if that is wrong, MAX_ALIGNMENT has to be fixed. But
if it has to, it was wrong before...
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
Novell / SUSE Labs
