This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug optimization/9786] [3.3/3.4 regression] Ice in fixup_abnormal_edges with -fnon-call-exceptions -O2


PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hainque at act-europe dot fr


------- Additional Comments From mmitchel at gcc dot gnu dot org  2003-07-22 18:41 -------
I'm confused.

Olivier's message says:

> I first thought that deletion of trapping insns should not occur in the first
> place, but the insn is known to be a no-op there so this seems OK.

I'm not sure that this is OK.  In particular, the instruction shown is:

    (insn 21 19 87 2 (set (reg:DF 8 st(0) [63])
            (float_extend:DF (reg:SF 8 st(0)))) 136 {*extendsfdf2_1} (nil)
        (expr_list:REG_EH_REGION (const_int 1 [0x1])
            (nil)))

In an earlier piece of this audit trail, Jason says that Richard says that if
the value were a NaN this would trap.

Is the point that we do not end up actually generating an x86 instruction for
this operation because we realize that the source and destination register are
the same?  But wouldn't that be wrong, in that we're then throwing a potential
exception that was perhaps implied by the source program?

If it is OK to delete these instructions, then Olivier's patch looks OK to me,
except that the ??? comment should be updated.  If it is not OK to delete these
instructions, then we need to stop reg-stack from doing that.

Ideas?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]