This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RFC: PATCH for PR 9786: [3.2/3.3/3.4 regression] Ice infixup_abnormal_edges with -fnon-call-exceptions -O2
- From: Jason Merrill <jason at redhat dot com>
- To: gcc-patches at gcc dot gnu dot org
- Date: Thu, 13 Mar 2003 18:46:13 -0500
- Subject: RFC: PATCH for PR 9786: [3.2/3.3/3.4 regression] Ice infixup_abnormal_edges with -fnon-call-exceptions -O2
I don't know much about trapping math, so I need someone who does to review
this patch.
In the testcase, a function wants to compute 0.299*l, where l is a float
data member of a struct. gcc generates this code to load l:
(insn 63 62 64 (nil) (set (reg:SF 74)
(mem/s:SF (reg/v/f:SI 69 [ this ]) [13 <variable>.l+0 S4 A32])) -1 (nil)
(nil))
(insn 64 63 65 (nil) (set (reg:DF 73)
(float_extend:DF (reg:SF 74))) -1 (nil)
(nil))
Both of these are deemed to possibly trap, since they involve floating
point math, so they go in separate basic blocks. By .32.bbro, we have
(insn 63 216 167 2 0x402a2a24 (set (reg:SF 8 st(0) [orig:74 <variable>.l ] [74])
(mem/s:SF (reg/v/u/f:SI 0 eax [orig:59 mi ] [59]) [13 <variable>.l+0 S4 A32])) 62 {*movsf_1} (insn_list 216 (nil))
(expr_list:REG_DEAD (reg/v/u/f:SI 0 eax [orig:59 mi ] [59])
(expr_list:REG_EH_REGION (const_int 2 [0x2])
(nil))))
;; End of basic block 2, registers live:
1 [dx] 6 [bp] 7 [sp] 8 [st] 16 [] 20 [frame]
;; Start of basic block 3, registers live: 1 [dx] 6 [bp] 7 [sp] 8 [st] 16 [] 20 [frame]
(note 167 63 64 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 64 167 168 3 0x402a2a24 (set (reg:DF 8 st(0) [73])
(float_extend:DF (reg:SF 8 st(0) [orig:74 <variable>.l ] [74]))) 93 {*extendsfdf2_1} (nil)
(expr_list:REG_EH_REGION (const_int 2 [0x2])
(nil)))
;; End of basic block 3, registers live:
1 [dx] 6 [bp] 7 [sp] 8 [st] 16 [] 20 [frame]
Next, the reg-stack pass decides that insn 64 is a no-op and deletes it.
But that leaves bb3 as an empty basic block with an EH edge, which doesn't
make any sense, and fixup_abnormal_edges aborts.
Is it actually possible for a float_extend to trap? If not, the simple fix
is to teach may_trap_p about that, as below. Otherwise, we need to delete
the edge somewhere along the way.
Is this patch safe?
2003-03-13 Jason Merrill <jason at redhat dot com>
PR c++/9786
* rtlanal.c (may_trap_p): FLOAT_EXTEND and FLOAT_TRUNCATE cannot
trap.
*** rtlanal.c.~1~ 2003-03-11 17:56:48.000000000 -0500
--- rtlanal.c 2003-03-13 18:37:43.000000000 -0500
*************** may_trap_p (x)
*** 2451,2456 ****
--- 2451,2458 ----
case CC0:
case REG:
case SCRATCH:
+ case FLOAT_EXTEND:
+ case FLOAT_TRUNCATE:
return 0;
case ASM_INPUT: