[Bug debug/95080] [10 Regression] -fcompare-debug failure (length) with -Og -fcse-follow-jumps -fnon-call-exceptions

2020-09-17 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95080

--- Comment #8 from Jakub Jelinek  ---
For 8.5 fixed in r8-10504-g819a383e5952dad6613791adba16c44d81da749b.

[Bug debug/95080] [10 Regression] -fcompare-debug failure (length) with -Og -fcse-follow-jumps -fnon-call-exceptions

2020-09-16 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95080

--- Comment #7 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:9d01f91514f627590adc408ac9a35a7153123119

commit r9-8898-g9d01f91514f627590adc408ac9a35a7153123119
Author: Jakub Jelinek 
Date:   Wed May 13 11:22:37 2020 +0200

Fix -fcompare-debug issue in purge_dead_edges [PR95080]

The following testcase fails with -fcompare-debug, the bug used to be
latent
since introduction of -fcompare-debug.
The loop at the start of purge_dead_edges behaves differently between -g0
and -g - if the last insn is a DEBUG_INSN, then it skips not just
DEBUG_INSNs but also NOTEs until it finds some other real insn (or bb
head),
while with -g0 it will not skip any NOTEs, so if we have
real_insn
note
debug_insn // not present with -g0
then with -g it might remove useless REG_EH_REGION from real_insn, while
with -g0 it will not.

Yet another option would be not skipping NOTE_P in the loop; I couldn't
find
in history rationale for why it is done.

2020-05-13  Jakub Jelinek  

PR debug/95080
* cfgrtl.c (purge_dead_edges): Skip over debug and note insns even
if the last insn is a note.

* g++.dg/opt/pr95080.C: New test.

(cherry picked from commit 18edc195442291525e04f0fa4d5ef972155117da)

[Bug debug/95080] [10 Regression] -fcompare-debug failure (length) with -Og -fcse-follow-jumps -fnon-call-exceptions

2020-06-14 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95080

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug debug/95080] [10 Regression] -fcompare-debug failure (length) with -Og -fcse-follow-jumps -fnon-call-exceptions

2020-06-14 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95080

--- Comment #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:16710ff9803bc48aabdfecce30866ffac6d29342

commit r10-8292-g16710ff9803bc48aabdfecce30866ffac6d29342
Author: Jakub Jelinek 
Date:   Wed May 13 11:22:37 2020 +0200

Fix -fcompare-debug issue in purge_dead_edges [PR95080]

The following testcase fails with -fcompare-debug, the bug used to be
latent
since introduction of -fcompare-debug.
The loop at the start of purge_dead_edges behaves differently between -g0
and -g - if the last insn is a DEBUG_INSN, then it skips not just
DEBUG_INSNs but also NOTEs until it finds some other real insn (or bb
head),
while with -g0 it will not skip any NOTEs, so if we have
real_insn
note
debug_insn // not present with -g0
then with -g it might remove useless REG_EH_REGION from real_insn, while
with -g0 it will not.

Yet another option would be not skipping NOTE_P in the loop; I couldn't
find
in history rationale for why it is done.

2020-05-13  Jakub Jelinek  

PR debug/95080
* cfgrtl.c (purge_dead_edges): Skip over debug and note insns even
if the last insn is a note.

* g++.dg/opt/pr95080.C: New test.

(cherry picked from commit 18edc195442291525e04f0fa4d5ef972155117da)

[Bug debug/95080] [10 Regression] -fcompare-debug failure (length) with -Og -fcse-follow-jumps -fnon-call-exceptions

2020-05-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95080

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11 Regression]  |[10 Regression]
   |-fcompare-debug failure |-fcompare-debug failure
   |(length) with -Og   |(length) with -Og
   |-fcse-follow-jumps  |-fcse-follow-jumps
   |-fnon-call-exceptions   |-fnon-call-exceptions

--- Comment #4 from Jakub Jelinek  ---
Fixed for 11+ so far.