diff options
author | Alexandre Oliva <aoliva@redhat.com> | 2017-12-14 15:03:09 +0000 |
---|---|---|
committer | Alexandre Oliva <aoliva@gcc.gnu.org> | 2017-12-14 15:03:09 +0000 |
commit | 4a0cafdda88f0f9993467067bb7ed4b5f7281f75 (patch) | |
tree | c8073edf762e1ecf67435fbd269555ae646dd524 /gcc/c | |
parent | c483db37a4d962ed2a60919c33629d080629fea6 (diff) | |
download | gcc-4a0cafdda88f0f9993467067bb7ed4b5f7281f75.zip gcc-4a0cafdda88f0f9993467067bb7ed4b5f7281f75.tar.gz gcc-4a0cafdda88f0f9993467067bb7ed4b5f7281f75.tar.bz2 |
[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.
From-SVN: r255639
Diffstat (limited to 'gcc/c')
0 files changed, 0 insertions, 0 deletions