This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug optimization/9786] [3.3/3.4 regression] Ice in fixup_abnormal_edges with -fnon-call-exceptions -O2
- From: "mmitchel at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 22 Jul 2003 18:41:32 -0000
- Subject: [Bug optimization/9786] [3.3/3.4 regression] Ice in fixup_abnormal_edges with -fnon-call-exceptions -O2
- References: <20030221012600.9786.nick@ilm.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
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?