https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 12 Apr 2022, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231 > > --- Comment #6 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- > > So interestingly distribute_notes sees > > > > (gdb) p debug_rtx (i2) > > (insn 78 22 24 3 (set (reg:XF 99) > > (float_extend:XF (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) > > [0 S4 A32]))) 166 {*extendsfxf2_i387} > > (nil)) > > > > as may_trap_p (), but we did not place an EH note on this previously. I'm > > not sure how the RTL IL is sanitized but eventually we simply take what RTL > > expansion yields as granted. > > This is the insn before combine though: > > (insn 78 22 24 3 (set (reg:XF 99) > (float_extend:XF (reg:SF 92))) 166 {*extendsfxf2_i387} > (expr_list:REG_DEAD (reg:SF 92) > (expr_list:REG_EQUAL (const_double:XF 1.8446744073709551616e+19 > [0x0.8p+65]) > (nil)))) > > so combine apparently forced the constant into the constant pool. Yes, but still the float_extend:XF would have made may_trap_p say the insn possibly traps but there's no EH on it despite -fnon-call-exceptions.
