https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122019
--- Comment #2 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Nathaniel Shead <nsh...@gcc.gnu.org>: https://gcc.gnu.org/g:fe2f86a960435a7c8c4e5134a0dfc64dd6062157 commit r16-4070-gfe2f86a960435a7c8c4e5134a0dfc64dd6062157 Author: Nathaniel Shead <nathanielosh...@gmail.com> Date: Mon Sep 22 19:16:01 2025 +1000 c++/modules: Fix language linkage handling [PR122019] The ICE in the linked PR is caused because when current_lang_name is lang_name_c, set_decl_linkage calls decl_linkage on the retrofitted declaration. This is problematic because at this point we haven't finished streaming the declaration, and so we crash when attempting to access these missing bits (such as the type). The only declarations we can reach here will be things like types that don't get a language linkage anyway, so it seems reasonable to just hardcode a C++ language linkage here to work around the issue. An alternative fix would be to override current_lang_name in lazy_load_binding instead, but this is potentially confusing if we ever deliberately implement `extern "C" import "header_unit.hpp";` to override the language linkage of imported declarations, so I went with this approach instead. (Though it seems we never will do this.) While testing this I found that we don't currently complain about mismatching language linkages for variables, and module_may_redeclare doesn't cope well with implementation units, so this patch also fixes those issues. PR c++/122019 gcc/cp/ChangeLog: * module.cc (trees_in::install_entity): Don't be affected by global language linkage state. (trees_in::is_matching_decl): Check mismatching language linkage for variables too. (module_may_redeclare): Report the correct module name for partitions and implementation units. gcc/testsuite/ChangeLog: * g++.dg/modules/lang-4_a.C: New test. * g++.dg/modules/lang-4_b.C: New test. Signed-off-by: Nathaniel Shead <nathanielosh...@gmail.com> Reviewed-by: Jason Merrill <ja...@redhat.com>
