[Bug debug/119190] [15 Regression] Debug info quality regression at -O0 since r15-3128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119190 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug debug/119190] [15 Regression] Debug info quality regression at -O0 since r15-3128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119190 --- Comment #6 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e1da6283a1cbd5db474c0f7e5cca9b9876768199 commit r15-7946-ge1da6283a1cbd5db474c0f7e5cca9b9876768199 Author: Jakub Jelinek Date: Tue Mar 11 10:57:30 2025 +0100 complex: Don't DCE unused COMPLEX_EXPRs for -O0 [PR119190] The PR116463 r15-3128 change regressed the following testcase at -O0. While for -O1+ we can do -fvar-tracking-assignments, for -O0 we don't (partly because it is compile time expensive and partly because at -O0 most of the vars live most of their lifetime in memory slots), so if we DCE some statements, it can mean that DW_AT_location for some vars won't be available or even it won't be possible to put a breakpoint at some particular line in the source. We normally perform dce just in the subpasses of pass_local_optimization_passes or pass_all_optimizations or pass_all_optimizations_g, so don't do that at all for -O0. So the complex change is an exception. And it was described as a way to help forwprop and reassoc, neither applies to -O0. This regresses PR119120 again though, I'll post a patch for that momentarily. 2025-03-11 Jakub Jelinek PR debug/119190 * tree-complex.cc (update_complex_assignment, tree_lower_complex): Perform simple dce on dce_worklist only if optimize. * gfortran.dg/guality/pr119190.f90: New test.
[Bug debug/119190] [15 Regression] Debug info quality regression at -O0 since r15-3128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119190 --- Comment #5 from Jakub Jelinek --- I'd say for PR119120 we should better change expansion so that either at -O0 only or always it performs the complex part moves of COMPLEX_EXPR in corresponding integral moves (and do something reasonable also for XFmode and TFmode on 32-bit arches), because COMPLEX_EXPR the way it is used even for partial stores necessarily results in sometimes copying uninitialized data around. Or do it only for -O0 and when lhs of the COMPLEX_EXPR isn't used, as if we pass it anywhere like e.g. function argument, both parts should better should be initialized.
[Bug debug/119190] [15 Regression] Debug info quality regression at -O0 since r15-3128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119190 --- Comment #3 from Richard Biener --- Oh, so we don't have debug stmts at -O0 because we don't run var-tracking. I guess the patch is reasonable.
[Bug debug/119190] [15 Regression] Debug info quality regression at -O0 since r15-3128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119190 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=119120 --- Comment #4 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #2) > Created attachment 60693 [details] > gcc15-pr119190.patch > > Untested fix. Note with this patch, you will need to reopen PR 119120 or close it was invalid (because partial writes to an uninitialized complex being undefined).
[Bug debug/119190] [15 Regression] Debug info quality regression at -O0 since r15-3128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119190 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2025-03-10 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Jakub Jelinek --- Created attachment 60693 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60693&action=edit gcc15-pr119190.patch Untested fix.
[Bug debug/119190] [15 Regression] Debug info quality regression at -O0 since r15-3128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119190 Jakub Jelinek changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Target Milestone|--- |15.0 --- Comment #1 from Jakub Jelinek --- One possibility would be to guard the bitmap_set_bit (dce_worklist, SSA_NAME_VERSION (gimple_assign_lhs (stmt))); on if (optimize && !optimize_debug) or maybe just if (optimize). For -Og -g it actually works fine, we get - ci = COMPLEX_EXPR <_2, _4>; + ci_8 = COMPLEX_EXPR <_2, _4>; + # DEBUG ci => ci_8 from ssa pass and - ci_8 = COMPLEX_EXPR <_2, _4>; - # DEBUG ci => ci_8 + # DEBUG ci => __complex__ (1.0e+0, 2.0e+0) from fre1. While for -Og we can get var-tracking-assignments for this, for -O0 we can't.
