This is the mail archive of the
mailing list for the GCC project.
Re: stack_pointer_delta related ICE in libgcc on 4.9.1
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: Jeff Law <law at redhat dot com>, Bernhard Reutner-Fischer <rep dot dot dot nop at gmail dot com>, Andreas Schwab <schwab at linux-m68k dot org>, Richard Henderson <rth at redhat dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 3 Sep 2014 13:50:57 -0500
- Subject: Re: stack_pointer_delta related ICE in libgcc on 4.9.1
- Authentication-results: sourceware.org; auth=none
- References: <20140903155627 dot GA12173 at mx dot loc> <54075CF5 dot 6030909 at redhat dot com>
On 9/3/2014 1:24 PM, Jeff Law wrote:
> 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.
FWIW For stack alignment RTEMS does not distinguish between any m68k or
Coldfire variant. The note says that what comes from the allocator is
aligned. And that's on a 4-byte boundary.
My recollection is that was selected in the m68020 days to avoid the penalty
of unaligned accesses -- not to avoid faults. I don't recall if
Coldfires fault or
handle the unaligned accesses but either way, there is a penalty incurred
and you want to avoid it.
>> 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.
If that gives you 4-byte stack alignment, then yes. I think the same stack
alignment rules should apply.
> 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.
I would bet that myself also. I know we don't care. But we provide
our users compile it themselves with the best options. :)
>> 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.
Coldfire does not have the CAS instruction per
> 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
> 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.
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985