http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45962
--- Comment #18 from Richard Henderson <rth at gcc dot gnu.org> 2010-10-19
23:21:31 UTC ---
(In reply to comment #17)
> Is there a particular reason it should be MAX_OFILE_ALIGNMENT?
No. For ELF, that just means "arbitrarily large".
> Hm, the default should fall back to effectively BIGGEST_ALIGNMENT unless
> there's a specific __attribute__ ((__aligned__ (N))) in there. That it
> apparently doesn't is a bug
Hum. I hadn't noticed previously that your BIGGEST_ALIGNMENT
is *also* set to BITS_PER_UNIT.
> (BTW, shouldn't MINIMUM_ALIGNMENT default to STACK_ALIGNMENT?
> And be named DYNAMIC_STACK_ALIGNMENT?)
I dunno about "dynamic". That sounds like stack re-alignment.
The current MINIMUM_ALIGNMENT leaves the alignment unchanged.
> Are you open to having that fixed?
Well, it appears as if get_mode_alignment is already correct, but
TYPE_ALIGN and thus DECL_ALIGN don't honor BIGGEST_ALIGNMENT.
I can see that if we adjust TYPE_ALIGN we'll alter the layout of
all structures, which can't be a good thing. I'm not sure what
the fallout would be from changing
if (code != FIELD_DECL)
/* For non-fields, update the alignment from the type. */
do_type_align (type, decl);
to also take BIGGEST_ALIGNMENT into account. Certainly we can't
change do_type_align because that's also used for FIELD_DECLs.
> Not a spilled pseudo, rather the stack-saving code going wrong.
> Stack-saving/restoring seems explicit and a bit intertwined; earlier
> well-placed do_pending_stack_adjust() calls playing a part, then effected by
> explow.c:emit_stack_save. Not a big surprise if it goes wrong due to or
> uncovered by r165240. To be investigated; I'll do my part.
Ug.
> It might not be wrong in the long run to completely replace EXIT_IGNORE_STACK
> with 1 and apply dead-code-elimination.
That would be really nice. There are several ports that explicitly
set it to 0: arc, h8300, m68hc11, spu, mcore, m32c. Those probably
need a simple update to their epilogues to restore from frame pointer.
