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

[hainque at act-europe dot fr]

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



------- Additional Comments From hainque at act-europe dot fr  2003-07-24 07:40 -------
Subject: Re:  [3.3/3.4 regression] Ice in fixup_abnormal_edges with -fnon-call-exceptions -O2


mmitchel at gcc dot gnu dot org wrote:
> 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?

 In this case, yes, right after this comment in move_for_stack_reg:

      /* If this appears to be a no-op move, delete it, or else it
	 will confuse the machine description output patterns. 

      if (REGNO (src) == REGNO (dest))

 There are other cases in which some insn may be deleted though (just above
 this comment).

 However,

 - another comment, in the caller (subst_stack_regs), mentions again that
   deletions are performed for no-ops:

  /* subst_stack_regs_pat may have deleted a no-op insn.  If so, any
     REG_UNUSED will already have been dealt with, so just return.  */

 and

 - the file head comment provides a hint that deletions performed in this
   pass are safe because they relate to insns handling *virtual* stack
   registers:

   [...] After the hard register numbers are substituted, the semantics of an
   insn containing stack-like regs are not the same as for an insn with normal
   regs: for instance, it is not safe to delete an insn that appears to be a
   no-op move.

> But wouldn't that be wrong, in that we're then throwing a potential
> exception that was perhaps implied by the source program?

 I'm not sure, which is why I initially asked for advices and ended up with
 a note together with the patch submission.

 The audit trail mentions:

    rth says that extending a NaN can trap, so we can't just
    change may_trap_p. 
 
 It's not quite clear to me if there are conditions in which it couldn't
 trap, and I trusted the "no-op" qualifiers in the comments mentioned above
 in that respect.

 This code is pretty old, tough, so it is possible that the considerations
 we deal with today were not accounted for at that time.

> 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.
 
 Agreed.

> Ideas?
 
 Does the additional input above ring a bell for anyone ?

 In any case, I think the comments will have to be updated to be more explicit
 on this issue.

 Thanks for your feedback.

 Olivier