Re: stack_pointer_delta related ICE in libgcc on 4.9.1

[Jeff Law <law at redhat dot com>]

On 09/03/14 09:56, Bernhard Reutner-Fischer wrote:
> Trying to bootstrap m68k i hit an assert in emit_library_call_value_1
> that wants to assure that the stack is aligned properly.
>
> PUSH_ROUNDING(GET_MODE_SIZE(QImode)) for m5206 is currently 1 so
> the testcase below has stack_pointer_delta = 1 + 1 + 4
> but emit_library_call_value_1() has this:
>
>    /* Stack must be properly aligned now.  */
>    gcc_assert (!(stack_pointer_delta
>                  & (PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT - 1)));
>
> where 6 & 3 != 0 and ICEs
>
> I am not familier with m68k so i would be glad for any help!
>
> Should the arg be partial? Doesn't look like, no.
No.  m68k doesn't pass args in registers.

> Does m68k use stack save area? From the looks it doesn't.
No.  m68k does not pass args in registers, I believe that's a 
requirement for needing a stack save area.

> Is the alignment_pad for QImode arg wrong?
Possibly.  Clearly if the stack is to be aligned to larger than a byte 
and PUSH_ROUNDING has no adjustment for QImode, then padding is needed 
somewhere.  And both the caller and callee need to agree on the padding.

> Should PUSH_ROUNDING be changed back to the !CF variant?
Possibly.  It's unfortunate the CF chips do something different than 
other m68k variants here.  The change in behaviour would seem to imply 
it's impossible to mix traditional m68k code with CF code, though 
perhaps nobody cares about that.


> Or is the alignment assert too strict?
I don't think so.

> Perhaps m5206 is not TARGET_CAS and should not compile this linux-atomic
> in the first place?
No, I don't think so.

You might ping Jim Wilson or Richard Sandiford who have both done 
coldfire work in the past.  I really don't have any experience with the 
coldfire bits.

> (is emit_library_call_value_1 missing a do_pending_stack_adjust() before
> NO_DEFER_POP ? Does not seem relevant for this case though)
Unsure.  I haven't done significant work on the m68k in decades, so the 
rules around defer_pop have long since been dropped from my memory.  If 
you can describe why you think it might be missing it'd be helpful for 
evaluation.

My recommendation would be to file a bug report with the reproducer. 
m68k isn't nearly as important today as it has been in the past, so 
getting developer time to hash through how all this should work for the 
coldfire may be difficult.

jeff