This is the mail archive of the gcc-patches@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: [PATCH] Fix PR49937


On Tue, 9 Aug 2011, Hans-Peter Nilsson wrote:

> On Tue, 9 Aug 2011, Richard Guenther wrote:
> >
> > This fixes PR49937 - callers of get_{pointer,object}_alignment
> > probably should not use BIGGEST_ALIGNMENT to limit what these
> > functions return (why do they do that?  Maybe because formerly
> > the routines returned TYPE_ALIGN?  But why wasn't that bound by
> > BIGGEST_ALIGNMENT?) - some targets define that as 8 (such as cris or avr).
> 
> ISTM such limiting is only valid when constructing non-function
> pointers to unknown data and the goal is to error on the safe
> side regarding generally unknown data placement and alignment.
> (If it's known to be on stack or in constant or static storage,
> there are other macros.)
> 
> BIGGEST_ALIGNMENT is not what its name says. As can be seen in
> the docs; it's rather something like
> BIGGEST_MINIMAL_HARDWARE_ENFORCED_ALIGNMENT_FOR_DATA_ACCESS.
> 
> Point being, it's likely there's a greater alignment that's
> preferable for e.g. performance reasons when generating objects
> and pointers to them.
> 
> BIGGEST_ALIGNMENT cannot be used for checking alignment of
> function pointers (to see e.g. how many low bits can be
> scavenged for hacks).  Raising BIGGEST_ALIGNMENT to include
> FUNCTION_BOUNDARY would be just wrong, as that's not data being
> accessed.
> 
> > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> 
> And regtest cross to cris-elf passes at r177605.

Committed.

I think the max-align argument to get_{pointer,object}_alignment
doesn't make much sense.  I'll cook up a patch to remove them.

Richard.


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