[Bug rtl-optimization/43809] New: ICE on unconditional divide trap

[Bug rtl-optimization/43809] New: ICE on unconditional divide trap

[wilson at gcc dot gnu dot org]

I originally posted this to the gcc mailing list, and then apparently forgot
about it, so I'm reporting it as a bug before I forget again.  This bug report
is a copy of the original message.
http://gcc.gnu.org/ml/gcc/2008-04/msg00336.html

This testcase extracted from libgcc2.c
int
sub (int i)
{
  if (i == 0)
    return 1 / i;

  return i + 2;
}
compiled with -minline-int-divide-min-latency for IA-64 generates an
ICE.
tmp2.c:8: error: flow control insn inside a basic block
(insn 18 17 19 3 tmp2.c:5 (trap_if (const_int 1 [0x1])
        (const_int 1 [0x1])) 352 {*trap} (nil))
tmp2.c:8: internal compiler error: in rtl_verify_flow_info_1, at
cfgrtl.c:1920


The problem is that IA-64 ABI specifies that integer divides trap, so we
must emit a conditional trap instruction.  cse simplifies the compare.
combine substitutes the compare into the conditional trap changing it to
an unconditional trap.  The next pass then fails a consistency check in
cfgrtl.

It seems odd that cfgrtl allows a conditional trap inside a basic block,
but not an unconditional trap.  The way things are now, it means we need
to fix up the basic blocks after running combine or any other pass that
might be able to simplify a conditional trap into an unconditional trap.

I can work around this in the IA64 port.  For instance I could use
different patterns for conditional and unconditional traps so that one
can't be converted to the other.  Or I could try to hide the conditional
trap inside some pattern that doesn't get expanded until after reload.
None of these solutions seems quite right.

But changing the basic block tree during/after combine doesn't seem
quite right either.

The other solution would be to fix cfgbuild to treat all trap
instructions are control flow insns, instead of just the unconditional
ones.  I'm not sure why it was written this way though, so I don't know
if this will cause other problems.  I see that sibling and noreturn
calls are handled the same way as trap instructions, implying that they
are broken too.

I'm looking for suggestions here as what I should do to fix this.


-- 
           Summary: ICE on unconditional divide trap
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: wilson at gcc dot gnu dot org
GCC target triplet: ia64-*


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

[Bug rtl-optimization/43809] ICE on unconditional divide trap

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2010-04-20 08:53 -------
conditional traps should be control-flow instructions just like maybe
throwing calls are.


-- 


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

[Bug rtl-optimization/43809] ICE on unconditional divide trap

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43809

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |7.0
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So all fixed in GCC 7.

The combine issue that was mentioned in the mailing list was fixed in
r7-4961-ga001d4f9b91236 .