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

On 05/19/14 15:20, John David Anglin wrote:
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.
I'd suggest getting a suitable .i/.ii file and debugging it with a cross-debugger ;-) Then again, if you've got a breakpoint that is triggering a million times, it may still take hours to hit when debugging with a cross.

The problem is more apparent with 64-bit compiler due to way PIC
register is saved and restored.
Yea, that makes sense.

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.
I'm pretty sure we're getting this wrong in the backend. In fact, the more I think about it, a NOTE_INSN_DELETED in a delay slot is just asking for all kinds of trouble.

In general, if we have an insn with a filled delay slot, then we will emit the two insns independently of each other (most of the time, there are exceptions).

A NOTE_INSN_DELETED in a delay slot still looks like a filled slot. So the target code isn't going to emit a NOP or anything like that. It's going to leave it up to the generic code to emit the insn with the delay slot and the delay slot insn itself (the NOTE_INSN_DELETED in this case).

Of course we don't output anything for a NOTE_INSN_DELETED. So the net result is we, in essence, fill the delay slot with whatever random instruction happens to fall next in the insn chain.

Amazingly, nothing seems to be failing, but I've seen far worse bugs go unnoticed for a long time.

Sadly,I think we need to start digging deeper to find out what's deleting those insns and take corrective action.

Perhaps writing a little routine to peek at all the filled delay slots and squawk if it finds a NOTE_INSN_DELETED. Then call it after each RTL pass that follows reorg in the pass manager. That'd at least narrow it down to a pass that's mucking things up.

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.
Probably just gone latent.

Still, we shouldn't call reset_insn_used_flags  or verify_insn_sharing
with a note.
Agreed, but at least in this instance, it's the symptom of a deeper problem I think.


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