On Tue, 13 Nov 2018, Tamar Christina wrote: > Would restricting it to flag_unsafe_math_optimizations not be enough in > this case? Since if it's only done for unsafe math then you likely won't > care about a small loss in precision anyway?
We have what should be the right logic (modulo DFP issues) in convert_to_real_1, for converting (outertype)((innertype0)a+(innertype1)b) into ((newtype)a+(newtype)b). I think the right thing to do is to move that logic, including the associated comments, from convert_to_real_1 to match.pd (not duplicate it or a subset in both places - make match.pd able to do everything that logic in convert.c does, so it's no longer needed in convert.c). That logic knows both when the conversion is OK based on flag_unsafe_math_optimizations, and when it's OK based on real_can_shorten_arithmetic. (Most of the other special case logic in convert_to_real_1 to optimize particular conversions would make sense to move as well - but for your present issue, only the PLUS_EXPR / MINUS_EXPR / MULT_EXPR / RDIV_EXPR logic should need to move.) > But my simple testcase is I'd hope a simpler test could be added - one not involving complex arithmetic at all, just an intermediate temporary variable or whatever's needed for convert_to_real_1 not to apply. -- Joseph S. Myers jos...@codesourcery.com
