This is the mail archive of the gcc-patches@gcc.gnu.org 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 -fcompare-debug due to DEBUG_BEGIN_STMTs (PR debug/83419)


On 12/20/2017 06:37 PM, Alexandre Oliva wrote:
> On Dec 20, 2017, Alexandre Oliva <aoliva@redhat.com> wrote:
> 
>> things work reasonably flawlessly now is not suggestive that it was
>> easy, or not too intrusive, but rather that the work to make it seamless
>> despite the intrusiveness was done, at first, and then over time.
>> That's the reason for -fcompare-debug and the various bootstrap options
>> that stress it further.
> 
>> sparc64-linux-gnu ran into -fcompare-debug failures early in stage3,
>> the same I ran into before, and that I'll investigate next.
> 
> The problems I observed on sparc64 were all similar, caused by the
> delayed branch infrastructure.  Here's a patch that fixes it.  Testing
> on sparc64-linux-gnu underway, but I'm posting it right away because
> it's so obvious.  And yet, I ask: ok to install?
> 
> This fixes stage3 -fcompare-debug builds of at least the builds of
> libbacktrace/dwarf.o, zlib/deflate.o, and libiberty/cplus-dem.o.
> 
> 
> [-fcompare-debug] retain insn locations when turning dbr seq into return
> 
> A number of -fcompare-debug errors on sparc arise as we split a dbr
> SEQUENCE back into separate insns to turn the branch into a return.
> If we just take the location from the PREV_INSN, it might be a debug
> insn without INSN_LOCATION, or an insn with an unrelated location.
> But that's silly: each of the SEQUENCEd insns is still an insn with
> its own INSN_LOCATION, so use that instead, even though some may have
> been adjusted while constructing the SEQUENCE.
> 
> for  gcc/ChangeLog
> 
> 	* reorg.c (make_return_insns): Reemit each insn with its own
> 	location.
OK.  FWIW I wouldn't be surprised if there's other places in reorg that
are going to need similar fixes.

FOr example, look at the code after these two comments:

         /* Delete the RETURN and just execute the delay list insns.

             We do this by deleting the INSN containing the SEQUENCE, then
             re-emitting the insns separately, and then deleting the RETURN.
             This allows the count of the jump target to be properly
             decremented.

             Note that we need to change the INSN_UID of the re-emitted
insns
             since it is used to hash the insns for
mark_target_live_regs and
             the re-emitted insns will no longer be wrapped up in a
SEQUENCE.

             Clear the from target bit, since these insns are no longer
             in delay slots.  */


         /* All this insn does is execute its delay list and jump to the
             following insn.  So delete the jump and just execute the delay
             list insns.

             We do this by deleting the INSN containing the SEQUENCE, then
             re-emitting the insns separately, and then deleting the jump.
             This allows the count of the jump target to be properly
             decremented.

             Note that we need to change the INSN_UID of the re-emitted
insns
             since it is used to hash the insns for
mark_target_live_regs and
             the re-emitted insns will no longer be wrapped up in a
SEQUENCE.

             Clear the from target bit, since these insns are no longer
             in delay slots.  */

> ---


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