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 sufficiently 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 http://www.freescale.com/files/dsp/doc/ref_manual/CFPRM.pdf > 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 joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
