public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "steven at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/39607] [4.5 Regression] Revision 145309 caused ICE in emit_swap_insn, at reg-stack.c:827 Date: Sun, 28 Oct 2012 11:42:00 -0000 [thread overview] Message-ID: <bug-39607-4-E04NZsvX8u@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-39607-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39607 Steven Bosscher <steven at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |steven at gcc dot gnu.org Resolution|FIXED | --- Comment #8 from Steven Bosscher <steven at gcc dot gnu.org> 2012-10-28 11:41:45 UTC --- Open again since r192440. The real problem here is this assert: if (hard_regno == -1) { /* Something failed if the register wasn't on the stack. If we had malformed asms, we zapped the instruction itself, but that didn't produce the same pattern of register sets as before. To prevent further failure, adjust REGSTACK to include REG at TOP. */ gcc_assert (any_malformed_asm); regstack->reg[++regstack->top] = REGNO (reg); return; } If IRA uses DF_LIVE, the assert may trigger if there is a use of a stack register that is not initialized. The following C test case (derived from gfortran.dg/pr40587.f) shows the problem: void test (int *i, double *r, double *result) { int i2; double r2; i2 = *i; if (i == 0) r2 = *r; else error (); *result = r2; } r2 is used uninitialized if the path through "error()" is taken. When using DF_LR, r2 is made live through that path all the way up to the function entry, but when using DF_LIVE r2 is only live in the trace from "r2 = *r" to "*result = r2". With IRA using DF_LIVE and removing the assert, the result is an fstpl instruction that triggers an FP-stack underflow. IMHO that would be a reasonable behavior for this kind of problem.
next parent reply other threads:[~2012-10-28 11:42 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-39607-4@http.gcc.gnu.org/bugzilla/> 2012-10-28 11:42 ` steven at gcc dot gnu.org [this message] 2012-10-28 11:54 ` steven at gcc dot gnu.org 2012-12-07 9:19 ` [Bug rtl-optimization/39607] " rguenth at gcc dot gnu.org 2009-04-01 7:57 [Bug c++/39607] New: internal compiler error: " mario-baumann at web dot de 2009-04-01 14:53 ` [Bug rtl-optimization/39607] [4.5 Regression] Revision 145309 caused ICE " hjl dot tools at gmail dot com 2009-04-02 18:28 ` hjl dot tools at gmail dot com 2009-04-03 22:26 ` hjl at gcc dot gnu dot org 2009-04-03 22:35 ` hjl at gcc dot gnu dot org 2009-04-03 22:35 ` hjl at gcc dot gnu dot org 2009-04-03 22:36 ` hjl dot tools at gmail dot com
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-39607-4-E04NZsvX8u@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).