[Bug ipa/120987] [13/14/15/16 regression] gdb build with lto triggers use after free since r12-5541-g2cadaa1f134bec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987 --- Comment #26 from Tom de Vries --- Eventually, a-test-2.c.121t.retslot has: ... [count: 0]: : _3 = MEM[(struct __shared_count *)&file_exception + 8B]._M_pi; if (_3 != 0B) ... and then the following a-test-2.c.122t.fre3 introduces the wrong code: ... [count: 0]: : if (_15 != 0B) ... where _15 is the initial nonnull value of file_exception.message._M_refcount._M_pi, and we need the actual value as updated by throw_exception, which is null.
[Bug ipa/120987] [13/14/15/16 regression] gdb build with lto triggers use after free since r12-5541-g2cadaa1f134bec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987 --- Comment #25 from rguenther at suse dot de --- On Sat, 12 Jul 2025, vries at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987 > > --- Comment #22 from Tom de Vries --- > FYI, I've submitted a workaround for gdb that disables -fipa-modref for > release > gcc 12.0 - 16.0 ( > https://sourceware.org/pipermail/gdb-patches/2025-July/219213.html ), assuming > that his will be fixed in 16.1. It's usually better to place a noipa attribute on a select function where the issue shows up than disabling a whole pass which might lead to other latent bugs pop up here and there given test coverage with -fno-ipa-* or -fno-tree-* is very weak.
[Bug ipa/120987] [13/14/15/16 regression] gdb build with lto triggers use after free since r12-5541-g2cadaa1f134bec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987 --- Comment #24 from Tom de Vries --- Created attachment 61858 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61858&action=edit debug patch Using this patch (on top of current trunk), I get the following in a-test-2.c.092i.inline: ... Considering gdb_exception::gdb_exception(gdb_exception&&)/482 with 15 size to be inlined into void throw_exception(gdb_exception&&)/487 in test-2.c:28 Estimated badness is -0.002532, frequency 1.00. Called 0 (precise) times flags from gdb_exception::gdb_exception(gdb_exception&&)/482: nothrow flags from void throw_exception(gdb_exception&&)/487: noreturn merged flags for void throw_exception(gdb_exception&&)/487: noreturn nothrow IGNORE_STORES: 1 Parm map: -1 0 Updated mod-ref summary for void throw_exception(gdb_exception&&)/487 loads: Base 0: alias set 0 Ref 0: alias set 0 access: Parm 0 param offset:0 offset:0 size:64 max_size:128 stores: Side effects Try dse parm 0 flags: no_direct_clobber no_direct_escape no_indirect_escape ... Without the "Minor ipa-modref tweaks" change we have instead: ... Considering gdb_exception::gdb_exception(gdb_exception&&)/482 with 15 size to be inlined into void throw_exception(gdb_exception&&)/487 in test-2.c:28 Estimated badness is -0.002532, frequency 1.00. Called 0 (precise) times flags from gdb_exception::gdb_exception(gdb_exception&&)/482: nothrow merged flags for void throw_exception(gdb_exception&&)/487: nothrow IGNORE_STORES: 0 Parm map: -1 0 Updated mod-ref summary for void throw_exception(gdb_exception&&)/487 loads: Base 0: alias set 0 Ref 0: alias set 0 access: Parm 0 param offset:0 offset:0 size:64 max_size:128 stores: Every base Side effects Nondeterministic Try dse parm 0 flags: no_direct_escape ... I think that the change that the commit brought is not unreasonable: throw_exception is noreturn before inlining, and should be so after inlining. It seems wrong to me that we propagate the nothrow flag from the gdb_exception constructor to throw_exception. That already happened before the commit.
[Bug ipa/120987] [13/14/15/16 regression] gdb build with lto triggers use after free since r12-5541-g2cadaa1f134bec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987 --- Comment #23 from Sam James --- (In reply to Tom de Vries from comment #20) > Seems to be fixed by: I've regtested this and it was fine.
[Bug ipa/120987] [13/14/15/16 regression] gdb build with lto triggers use after free since r12-5541-g2cadaa1f134bec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987 --- Comment #22 from Tom de Vries --- FYI, I've submitted a workaround for gdb that disables -fipa-modref for release gcc 12.0 - 16.0 ( https://sourceware.org/pipermail/gdb-patches/2025-July/219213.html ), assuming that his will be fixed in 16.1.
[Bug ipa/120987] [13/14/15/16 regression] gdb build with lto triggers use after free since r12-5541-g2cadaa1f134bec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987 --- Comment #21 from Tom de Vries --- (In reply to Tom de Vries from comment #20) > Seems to be fixed by: > ... > diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c > index 9e537b04196..fbdf8da36df 100644 > --- a/gcc/ipa-modref.c > +++ b/gcc/ipa-modref.c > @@ -5109,7 +5109,6 @@ ipa_merge_modref_summary_after_inlining (cgraph_edge > *edge) >cgraph_node *n; >for (n = edge->caller; n->inlined_to; n = n->callers->caller) > flags |= flags_from_decl_or_type (n->decl); > - flags |= flags_from_decl_or_type (n->decl); >bool ignore_stores = ignore_stores_p (edge->caller->decl, flags); > >if (!callee_info && to_info) > ... Which causes this difference in test-2.c.085i.modref: ... - parm 0 flags: no_direct_clobber no_direct_escape no_indirect_escape + parm 0 flags: no_direct_escape ... in the analysis of throw_exception. I don't understand these flags very well, but my guess is that it's the no_direct_clobber that is causing the problems.
[Bug ipa/120987] [13/14/15/16 regression] gdb build with lto triggers use after free since r12-5541-g2cadaa1f134bec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987 Sam James changed: What|Removed |Added Summary|[14/15/16 regression] gdb |[13/14/15/16 regression] |build with lto triggers use |gdb build with lto triggers |after free since|use after free since |r12-5541-g2cadaa1f134bec|r12-5541-g2cadaa1f134bec Target Milestone|14.4|13.5
