[compare-debug] use call loc for nop_endbr
commitdc988bc8e1b44b7be040b29369b28e7fdbf3fe07
authoraoliva <aoliva@138bc75d-0d04-0410-961f-82ee72b054a4>
Thu, 14 Dec 2017 15:03:09 +0000 (14 15:03 +0000)
committeraoliva <aoliva@138bc75d-0d04-0410-961f-82ee72b054a4>
Thu, 14 Dec 2017 15:03:09 +0000 (14 15:03 +0000)
treec8073edf762e1ecf67435fbd269555ae646dd524
parentad1d5c78da501538c5d963076624e6effb326a21
[compare-debug] use call loc for nop_endbr

We skip debug insns and notes after a call that needs a nop_endbr, but
since a debug insn could be the last in a block, it may affect the loc
in the emitted nop_endbr insn.  Although this has no effect on
codegen, it does mess with debug info a bit, and it causes
-fcompare-debug to fail for e.g. libsanitizer's
tsan/tsan_platform_linux.cc on x86_64.

So, pick the location of the call insn for the nop_endbr insn, to
avoid the line number differences in dumps, including -fcompare-debug
ones.

Also, we don't need to determine what the insert point would be unless
we're actually emitting the nop_endbr insn after the call, so
rearrange the code to avoid wasting cycles.

Finally, it seems like testing for barriers is a mistake.  We probably
never actually pass that test, for the barriers would hit BB_END
first.  If we did, we'd end up emitting the nop_endbr outside any BB,
even after the end of the function!  That would be Very Bad (TM).
Now, since the test as it is can't hurt, I figured I wouldn't change
the logic right now, just add a comment so that someone involved in
endbr stuff can have a second look and hopefully fix it.

for  gcc/ChangeLog

* config/i386/i386.c (rest_of_insert_endbranch): Use call loc
for its nop_endbr.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@255639 138bc75d-0d04-0410-961f-82ee72b054a4
gcc/ChangeLog
gcc/config/i386/i386.c