Jeff Law <l...@redhat.com> writes:
> On 10/23/2017 11:37 AM, Richard Sandiford wrote:
>> PUSH_ROUNDING is difficult to convert to a hook since there is still
>> a lot of conditional code based on it.  It isn't clear that a direct
>> conversion with checks for null hooks is the right thing to do.
>> 
>> Rather than untangle that, this patch converts all implementations
>> that do something to out-of-line functions that have the same
>> interface as a hook would have.  This should at least help towards
>> any future hook conversion.
>> 
>> 
>> 2017-10-23  Richard Sandiford  <richard.sandif...@linaro.org>
>>          Alan Hayward  <alan.hayw...@arm.com>
>>          David Sherwood  <david.sherw...@arm.com>
>> 
>> gcc/
>>      * config/cr16/cr16-protos.h (cr16_push_rounding): Declare.
>>      * config/cr16/cr16.h (PUSH_ROUNDING): Move implementation to...
>>      * config/cr16/cr16.c (cr16_push_rounding): ...this new function.
>>      * config/h8300/h8300-protos.h (h8300_push_rounding): Declare.
>>      * config/h8300/h8300.h (PUSH_ROUNDING): Move implementation to...
>>      * config/h8300/h8300.c (h8300_push_rounding): ...this new function.
>>      * config/i386/i386-protos.h (ix86_push_rounding): Declare.
>>      * config/i386/i386.h (PUSH_ROUNDING): Move implementation to...
>>      * config/i386/i386.c (ix86_push_rounding): ...this new function.
>>      * config/m32c/m32c-protos.h (m32c_push_rounding): Take and return
>>      a poly_int64.
>>      * config/m32c/m32c.c (m32c_push_rounding): Likewise.
>>      * config/m68k/m68k-protos.h (m68k_push_rounding): Declare.
>>      * config/m68k/m68k.h (PUSH_ROUNDING): Move implementation to...
>>      * config/m68k/m68k.c (m68k_push_rounding): ...this new function.
>>      * config/pdp11/pdp11-protos.h (pdp11_push_rounding): Declare.
>>      * config/pdp11/pdp11.h (PUSH_ROUNDING): Move implementation to...
>>      * config/pdp11/pdp11.c (pdp11_push_rounding): ...this new function.
>>      * config/stormy16/stormy16-protos.h (xstormy16_push_rounding): Declare.
>>      * config/stormy16/stormy16.h (PUSH_ROUNDING): Move implementation to...
>>      * config/stormy16/stormy16.c (xstormy16_push_rounding): ...this new
>>      function.
>>      * expr.c (emit_move_resolve_push): Treat the input and result
>>      of PUSH_ROUNDING as a poly_int64.
>>      (emit_move_complex_push, emit_single_push_insn_1): Likewise.
>>      (emit_push_insn): Likewise.
>>      * lra-eliminations.c (mark_not_eliminable): Likewise.
>>      * recog.c (push_operand): Likewise.
>>      * reload1.c (elimination_effects): Likewise.
>>      * rtlanal.c (nonzero_bits1): Likewise.
>>      * calls.c (store_one_arg): Likewise.  Require the padding to be
>>      known at compile time.
> OK.
>
> I so wish PUSH_ROUNDING wasn't needed and that folks could at least keep
> their processors consistent (I'm looking at the coldfire designers :(.
> For a tale of woe, see BZ68467.

Ouch.  Is this also fallout from having different code for libcalls
and normal calls?  That always seemed like an accident waiting to
happen, but I don't remember seeing cases where it caused actual ABI
breakage before.

Thanks as ever for the reviews :-)

Richard

Reply via email to