[Bug tree-optimization/49937] [4.7 Regression] g++.dg/tree-ssa/fwprop-align.C

["hp at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49937

--- Comment #5 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2011-08-09 15:38:32 UTC ---
(In reply to comment #3)
Thanks for looking.

> hp, can you maybe answer the question about correctness for aligns
> bigger than BIGGEST_ALIGNMENT?

I'm not completely sure what you're asking, but I think I can answer the
question, when asked. :)

Having BIGGEST_ALIGNMENT 8 for cris-* seems valid, as BIGGEST_ALIGNMENT is the
"biggest alignment that any data type can require on this machine, in bits",
but when calling a function we're not accessing data, right?

Anyway, "this is not the biggest alignment that is supported, just the biggest
alignment that, when violated, may cause a fault".  So, it's definitely valid
to mention or explicitly demanding higher alignment (like in
attribute-aligned).  I guess we're violating an alignment when calling a
misaligned function, but letting BIGGEST_ALIGNMENT control that, doesn't seem
right.  All the macros defaulting to BIGGEST_ALIGNMENT and many (all?) other
uses are about data accesses and aligning objects being created for valid
alignment for any data.  Raising it just to match FUNCTION_BOUNDARY would be
just wrong, I can't see any caller to intend to include function alignments and
it'd pessimize the results for them.  I see frv and lm32 also have a higher
FUNCTION_BOUNDARY than BIGGEST_ALIGNMENT but luckily larger than 8 bits...

>  And eventually audit other callers?

I had a look and can definitely have a more thorough review when we're done
interpreting what the alignment macros should control. ;)  I'm not sure all
callers accessing data are using it correctly; some of those using it for
pointers (rather than objects) may assume a too big alignment.