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.
