https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124031
John Scott <jscott at posteo dot net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jscott at posteo dot net
--- Comment #2 from John Scott <jscott at posteo dot net> ---
I believe I've run into this same issue while building WebKit, but in case I'm
wrong and because I've already dug into it some, I'll describe what I know
herein.
The issue presented itself the same with:
• Debian Trixie's GCC 14 release package
• Debian Forky's GCC 16 release package
• upstream gcc.git built from trunk today (commit
b44616b54d80acac4329204b189efd987b31169c)
all on x86_64-linux-gnu.
The error occurs within cc1plus and I've made a minimal reproducer as follows:
make one source foo.h with the contents
class Thread {
public:
int m_mutex;
};
and bar.cxx with
#include "./repno.h"
class ReflectedThread : public Thread {
using Thread::m_mutex;
};
The issue does not occur if the files have the same basename: if the files are
named foo.h and foo.cxx instead, for example, the problem will not appear. This
must be due to a heuristic in the vein of -femit-struct-debug-base. I've found
more specifically the problem is triggered by
-femit-struct-debug-detailed=ord:base (and -g2). An invocation approximately
like this will trigger the ICE; the g++ frontend can still be used, of course:
/usr/libexec/gcc/x86_64-linux-gnu/16/cc1plus -I . ./bar.cxx -g2
-femit-struct-debug-detailed=ord:base -o /dev/null
and on my fresh trunk build I find
bar.cxx:3:7: internal compiler error: in force_decl_die, at dwarf2out.cc:27385
3 | class ReflectedThread : public Thread {
| ^~~~~~~~~~~~~~~
0x3c729f3 diagnostics::context::diagnostic_impl(rich_location*,
diagnostics::metadata const*, diagnostics::option_id, char const*,
__va_list_tag (*) [1], diagnostics::kind)
???:0
0x3c64393 internal_error(char const*, ...)
???:0
0x3c72e09 fancy_abort(char const*, int, char const*)
???:0
0xc707bd force_decl_die(tree_node*)
???:0
0xc72571 dwarf2out_imported_module_or_decl_1(tree_node*, tree_node*,
tree_node*, die_struct*)
???:0
0xc72834 dwarf2out_imported_module_or_decl(tree_node*, tree_node*, tree_node*,
bool, bool)
???:0
0x709831 cp_emit_debug_info_for_using(tree_node*, tree_node*)
???:0
0x456afb handle_using_decl(tree_node*, tree_node*)
???:0
0x47321c check_bases_and_members(tree_node*)
???:0
0x479f68 finish_struct_1(tree_node*)
???:0
0x47c06a finish_struct(tree_node*, tree_node*)
???:0
0x75aee2 cp_parser_class_specifier(cp_parser*)
???:0
0x7494ab cp_parser_type_specifier(cp_parser*, int, cp_decl_specifier_seq*,
bool, int*, bool*)
???:0
0x7428d8 cp_parser_decl_specifier_seq(cp_parser*, int, cp_decl_specifier_seq*,
int*)
???:0
0x740309 cp_parser_simple_declaration(cp_parser*, bool, tree_node**)
???:0
0x74027e cp_parser_block_declaration(cp_parser*, bool)
???:0
0x73fcb2 cp_parser_declaration(cp_parser*, tree_node*)
???:0
0x73fd8f cp_parser_toplevel_declaration(cp_parser*)
???:0
0x71f237 cp_parser_translation_unit(cp_parser*)
???:0
0x7b34f2 c_parse_file()
???:0
I don't know anything about C++ so I don't understand what's going on here, so
it's a good thing it sounds like you folks do 😀
