This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix PR middle-end/61141

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

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.

John David Anglin

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]