From: David Miller <davem@davemloft.net>
To: amodra@gmail.com
Cc: gcc-patches@gcc.gnu.org, ebotcazou@adacore.com
Subject: Re: Reload related segfaults
Date: Thu, 27 Oct 2011 08:46:00 -0000 [thread overview]
Message-ID: <20111027.024029.1691741697599158961.davem@davemloft.net> (raw)
In-Reply-To: <20111026.230711.1078076406757764801.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 26 Oct 2011 23:07:11 -0400 (EDT)
> From: Alan Modra <amodra@gmail.com>
> Date: Thu, 27 Oct 2011 13:29:56 +1030
>
>> Some recent patch has exposed a reload bug. I'm seeing
>
> I think this might be a side effect or Eric's recent changes,
> CC:'d.
Eric, I'm seeing a similar segmentation fault in reload on sparc64.
But it's in a slightly different place than Alan's crash.
Simply compile gcc.target/ultrasp12.c with "-m64 -O2 -mcpu=ultrasparc -mvis"
to see this.
The crash is in find_valid_class() called from push_reload(), via this
code block around line 1184 of reload.c:
enum reg_class in_out_class
= find_valid_class (outmode, GET_MODE (SUBREG_REG (out)),
subreg_regno_offset (REGNO (SUBREG_REG (out)),
GET_MODE (SUBREG_REG (out)),
SUBREG_BYTE (out),
GET_MODE (out)),
REGNO (SUBREG_REG (out)));
'out' is:
(subreg:DI (reg/v:V4QI 50 %f18 [orig:314 s2hi4_ ] [314]) 0)
so subreg_regno_offset() returns -1, and find_valid_class() isn't too happy
about getting "-1" for it's 'n' argument.
I suspect the test that you removed in order to fix rtl-optimization/46603
would guard against this happening.
And indeed, I confirmed that backing out the rtl-optimization/46603
fix makes the segmentation fault go away.
next prev parent reply other threads:[~2011-10-27 6:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-27 6:20 Alan Modra
2011-10-27 6:28 ` David Miller
2011-10-27 8:46 ` David Miller [this message]
2011-10-27 12:01 ` Eric Botcazou
2011-10-27 13:21 ` Iain Sandoe
2011-10-27 19:18 ` Eric Botcazou
2011-11-04 13:44 ` Alan Modra
2011-11-04 17:02 ` Eric Botcazou
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=20111027.024029.1691741697599158961.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=amodra@gmail.com \
--cc=ebotcazou@adacore.com \
--cc=gcc-patches@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: link
Be 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).