This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR middle-end/61141
- From: John David Anglin <dave dot anglin at bell dot net>
- To: Jeff Law <law at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 19 May 2014 17:20:32 -0400
- Subject: Re: [PATCH] Fix PR middle-end/61141
- Authentication-results: sourceware.org; auth=none
- References: <BLU0-SMTP43F10F32286A327F4C627297330 at phx dot gbl> <537A44A8 dot 3020502 at redhat dot com>
Hi Jeff,
On 19-May-14, at 1:51 PM, Jeff Law wrote:
On 05/18/14 09:33, John David Anglin wrote:
The attached change appears to fix PR middle-end/61141. On PA, we
can get
deleted insn notes in call sequences. The attached change checks to
make sure we have
a valid insn before calling reset_insn_used_flags and
verify_insn_sharing.
Tested on hppa-unknown-linux-gnu, hppa2.0w-hp-hpux11.11 and
hppa64-hp-hpux11.11.
OK for trunk?
Maybe :-)
c#1 you incluide a blob of RTL, but it's not clear where insn 238
was to begin with. ie, was it inside a SEQUENCE or somewhere else?
Yes, it was inside a SEQUENCE.
The problem compiling c-common.c is very hard to debug. These
routines are called intensively and the ICE occurs after several
million calls.
It takes a couple of hours of running under gdb to reach the failing
call to reset_insn_used_flags just counting calls up to ICE.
The problem is more apparent with 64-bit compiler due to way PIC
register is saved and restored.
In c#2 you indicate we can get this stuff when an insn in a delay
slot sequence is deleted. Where/when are those insns being deleted?
Presumably the backends know enough to handle deleted insns in delay
slot sequences?!? It's been a long time since I looked at that code
in detail, so if you already know it's safe, just say "it's safe"
and I'll believe you :-) Otherwise a bit of digging may be needed.
I believe that the backend must handle the deleted insns in the delay
slot as there are are no compilation errors or regressions.
However, like you, I'm not 100% certain this done correctly.
My preference would be to remove these insns from the RTL chain, but
if that's not going to be reasonably feasible, then we'll probably
need to go with something like your patch.
Something has changed. Either these insns aren't being removed from
RTL chain as they were before or they are being deleted
at a much later stage. The same code is present in 4.9 and the
problem doesn't seem to occur there. Possibly, a regression search
would pin point this.
Still, we shouldn't call reset_insn_used_flags or verify_insn_sharing
with a note.
Dave
--
John David Anglin dave.anglin@bell.net