From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5962 invoked by alias); 19 Apr 2010 23:18:19 -0000 Received: (qmail 5915 invoked by uid 48); 19 Apr 2010 23:18:06 -0000 Date: Mon, 19 Apr 2010 23:18:00 -0000 Subject: [Bug rtl-optimization/43809] New: ICE on unconditional divide trap X-Bugzilla-Reason: CC Message-ID: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "wilson at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-04/txt/msg01920.txt.bz2 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