[Bug debug/47018] ICE: in pre_and_rev_post_order_compute, at cfganal.c:1047 with -fnon-call-exceptions -fvar-tracking -g

jakub at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Mon Dec 20 09:29:00 GMT 2010


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47018

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-12-20 09:29:41 UTC ---
The problem is that split2 pass splits:
(insn 6 3 7 2 (set (reg:DF 21 xmm0 [orig:59 D.2082 ] [59])            
        (float_extend:DF (reg/v:SF 21 xmm0 [orig:61 f ] [61]))) pr47018-2.C:11
136 {*extendsfdf2_sse}
     (expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil)))

into:
(insn 36 3 37 2 (set (reg:V4SF 21 xmm0 [orig:61 f ] [61])
        (vec_select:V4SF (vec_concat:V8SF (reg:V4SF 21 xmm0 [orig:61 f ] [61])
                (reg:V4SF 21 xmm0 [orig:61 f ] [61]))
            (parallel [
                    (const_int 0 [0])
                    (const_int 4 [0x4])
                    (const_int 1 [0x1])
                    (const_int 5 [0x5])
                ]))) pr47018-2.C:11 1472 {vec_interleave_lowv4sf}
     (nil))

(insn 37 36 7 2 (set (reg:V2DF 21 xmm0 [orig:59 D.2082 ] [59])
        (float_extend:V2DF (vec_select:V2SF (reg:V4SF 21 xmm0 [orig:61 f ]
[61])
                (parallel [
                        (const_int 0 [0])
                        (const_int 1 [0x1])
                    ])))) pr47018-2.C:11 1462 {sse2_cvtps2pd}
     (nil))
and the split2 pass doesn't expect it needs to clean up the cfg and purge dead
eh edges etc.  With -O0 -fvar-tracking then var-tracking ICEs because there is
an unreachable bb.

With -fnon-call-exceptions float_extend in scalar float mode is considered as
may_trap_p while vector float mode is not:
    default:
      /* Any floating arithmetic may trap.  */
      if (SCALAR_FLOAT_MODE_P (GET_MODE (x))
          && flag_trapping_math)
        return 1;
If the reason why float_extend:DF is considered as maybe trapping is sNaN, then
doesn't vector mode float_extend trap too?  Either split2 needs to purge dead
eh edges and cleanup if needed, or the splitter is incorrect for
-fnon-call-exceptions, or may_trap_p is wring in only handling scalar float
modes and not vector float modes too.



More information about the Gcc-bugs mailing list