This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: unable to detect exception model


On Sun, 25 Jun 2006, Seongbae Park wrote:

> On 6/25/06, Eric Botcazou <ebotcazou@libertysurf.fr> 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 <rguenther@suse.de>
Novell / SUSE Labs


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]