This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: stack_pointer_delta related ICE in libgcc on 4.9.1

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
source and
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 
> 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

Joel Sherrill, Ph.D.             Director of Research & Development        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]