https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121865

--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Nathaniel Shead <[email protected]>:

https://gcc.gnu.org/g:b9fde0219f35cd5244f647c20c7b31b0395dbc5a

commit r16-3821-gb9fde0219f35cd5244f647c20c7b31b0395dbc5a
Author: Nathaniel Shead <[email protected]>
Date:   Wed Sep 10 14:25:22 2025 +1000

    ipa-free-lang-data: Don't walk into DECL_CHAIN when finding decls/types
[PR121865]

    On a DECL, TREE_CHAIN will find any other declarations in the same
    binding level.  This caused an ICE in PR121865 because the next entity
    in the binding level was the uninstantiated unique friend 'foo', for
    which after being found the compiler tries to generate a mangled name
    for it and crashes.

    This didn't happen in non-modules testcases only because normally the
    unique friend function would have been chained after its template_decl,
    and find_decl_types_r bails on lang-specific nodes so it never saw the
    uninstantiated decl.  With modules however the order of chaining
    changed, causing the error.

    I don't think it's ever necessary to walk into the DECL_CHAIN, from what
    I can see; other cases where it might be useful (block vars or type
    fields) are already handled explicitly elsewhere, and only one test
    fails because of the change, due to accidentally relying on this "walk
    into the next in-scope declaration" behaviour.

            PR c++/121865

    gcc/ChangeLog:

            * ipa-free-lang-data.cc (find_decls_types_r): Don't walk into
            DECL_CHAIN for any DECL.

    gcc/testsuite/ChangeLog:

            * g++.dg/lto/pr101396_0.C: Ensure A will be walked into (and
            isn't constant-folded out of the GIMPLE for the function).
            * g++.dg/lto/pr101396_1.C: Add message.
            * g++.dg/modules/lto-4_a.C: New test.
            * g++.dg/modules/lto-4_b.C: New test.

    Signed-off-by: Nathaniel Shead <[email protected]>
    Reviewed-by: Richard Biener <[email protected]>

Reply via email to