public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "matz at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/48633] New: IRA causes ICE in compensate_edge Date: Fri, 15 Apr 2011 20:14:00 -0000 [thread overview] Message-ID: <bug-48633-4@http.gcc.gnu.org/bugzilla/> (raw) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48633 Summary: IRA causes ICE in compensate_edge Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned@gcc.gnu.org ReportedBy: matz@gcc.gnu.org Since r172516 the Ada testcase cxg2001 fails with an ICE in compensate_edge on x86_64-linux. The problem is not specific to Ada an can be reproduced with a C++ testcase simulating what Ada does. This testcase does not need the patch from r172516 and also fails before: % cat ira-bug.cc /* { dg-do compile} */ /* { dg-options "-O2 -fira-region=all -fnon-call-exceptions" } */ extern long double getme (void); extern void useme (long double); struct Frame { long double tmp; }; void bugme (int n) { Frame f; int i; f.tmp = getme(); try { for (i = 0; i < n; i++) { f.tmp += 1.0; } } catch (...) { f.tmp += 1.0; } useme (f.tmp); } % ./cc1plus -O2 -fnon-call-exceptions -fira-region=all ira-bug.cc ira-bug.cc: In function ‘void bugme(int)’: ira-bug.cc:22:1: internal compiler error: in compensate_edge, at reg-stack.c:2781 -fnon-call-exceptions is needed as Ada effectively sets it, -fira-region=all is needed to make IRA fail on this small testcase, otherwise IRA assigned registers for the subloops here due to low reg pressure. The Ada testcase has much higher pressure causing IRA to go into the same code-paths as with ira-region=all. The problem is the allocation of pseudo 61 to hardreg 10 (a stackreg). pseudo 61 gets two allocnos, a1 for loop0 which conflicts with the stackregs because it's live over abnormal edges, and a8 for loop1 which doesn't conflict with those stackregs (which is okay). The problem is the transition from loop1 (a8 alloced to hardreg 10) to loop0 (a1, spilled), which requires a memory store from h10 to stack. But the transition itself goes over an EH edge, and the compensation code is inserted into the EH block: (code_label/s 65 36 67 11 8 "" [1 uses]) (note 67 65 84 11 [bb 11] NOTE_INSN_BASIC_BLOCK) (insn 84 67 40 11 (set (mem/c:XF (plus:DI (reg/f:DI 7 sp) (const_int 32 [0x20])) [4 %sfp+-16 S16 A128]) (reg:XF 10 st(2) [orig:61 f$tmp ] [61])) 105 {*movxf_internal} (nil)) This is the compensation code, requiring hardreg 10 to be set, but this bb 11 is the target of an EH edge. This then later is checked in the reg-stack pass and asserts. The IRA dump is somewhat interesting: Loop 0 (parent -1, header bb0, depth 0) bbs: 12 11 10 9 8 7 3(->5:l1) 2 all: 0r62 1r61 2r73 3r70 4r69 5r74 6r63 7r66 modified regnos: 61 62 63 66 69 70 73 74 border: Pressure: GENERAL_REGS=2 FLOAT_REGS=4 Hard reg set forest: 0:( 0-6 8-15 21-51)@0 1:( 0-6 37-44)@24004 2:( 0 3 5 6 41-44)@14 3:( 8-15)@60040 Spill a1(r61,l0) So, for loop0 r61 is spilled, fine. Loop 1 (parent 0, header bb5, depth 1) bbs: 6(->7:l0) 5(->11:l0) 4 So we have two exits from this region, via 6->7 (the normal loop exit) and via 5->11 (the EH edge). all: 8r61 9r63 10r66 11r73 12r74 13r62 modified regnos: 61 62 63 border: 8r61 9r63 10r66 11r73 12r74 13r62 Pressure: GENERAL_REGS=2 FLOAT_REGS=4 Hard reg set forest: 0:( 0-6 8-15 21-51)@0 1:( 0-6 37-44)@22920 2:( 8 10-15)@72856 Allocno a8r61 of FLOAT_REGS(8) has 7 avail. regs 8 10-15 ... Popping a8(r61,l1) -- assign reg 10 So, r61 in the loop gets hardreg 10. Then we go on: New iteration of spill/restore move Changing RTL for loop 1 (header bb5) 10 vs parent -1: Creating newreg=75 from oldreg=61 So, it noticed that the two regions have different dispositions for the same pseudo, and generates compensation code: rescanning insn with uid = 18. deleting insn with uid = 18. rescanning insn with uid = 7. deleting insn with uid = 7. scanning new insn with uid = 84. insn 84 is the compensation code, and it's placed in a region where the source (a8 == hardreg 10) isn't live anymore.
next reply other threads:[~2011-04-15 20:14 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-04-15 20:14 matz at gcc dot gnu.org [this message] 2011-04-15 21:19 ` [Bug rtl-optimization/48633] " matz at gcc dot gnu.org 2011-04-16 11:23 ` [Bug rtl-optimization/48633] [4.7 regression] " ebotcazou at gcc dot gnu.org 2011-05-13 15:49 ` vmakarov at redhat dot com 2011-05-15 23:16 ` ubizjak at gmail dot com 2011-05-24 17:15 ` vmakarov at gcc dot gnu.org 2011-05-25 10:26 ` ebotcazou at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-48633-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).