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