[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

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

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.