https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57607
Eric Gallager <egallager at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #5 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Eric Gallager from comment #4)
> The testcase breaks again with gcc8 though, this time causing an ICE:
>
> $ /usr/local/bin/g++ -std=c++11 -framework CoreFoundation -lobjc test57607.mm
> In file included from /usr/local/include/c++/8.0.0/bits/ios_base.h:46:0,
> from /usr/local/include/c++/8.0.0/ios:42,
> from /usr/local/include/c++/8.0.0/ostream:38,
> from /usr/local/include/c++/8.0.0/iostream:39,
> from test57607.mm:2:
> /usr/local/include/c++/8.0.0/system_error:191:23: internal compiler error:
> Segmentation fault
> explicit operator bool() const noexcept
> ^~~~
> libbacktrace could not find executable to open
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <https://gcc.gnu.org/bugs/> for instructions.
>
>
> Attaching gdb gives the following backtrace:
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x3a138e4c
> 0x0010d744 in make_conv_op_name ()
> (gdb) bt
> #0 0x0010d744 in make_conv_op_name ()
> #1 0x00169ac7 in cp_parser_unqualified_id ()
> #2 0x00169e49 in cp_parser_id_expression ()
> #3 0x00169fb3 in cp_parser_parse_and_diagnose_invalid_type_name ()
> #4 0x0015e084 in cp_parser_member_declaration ()
> #5 0x0015ea24 in cp_parser_type_specifier ()
> #6 0x0016f480 in cp_parser_decl_specifier_seq ()
> #7 0x00174ab5 in cp_parser_simple_declaration ()
> #8 0x00175bdf in cp_parser_block_declaration ()
> #9 0x0017addc in cp_parser_declaration ()
> #10 0x0017b21e in cp_parser_declaration_seq_opt ()
> #11 0x0017b965 in cp_parser_namespace_definition ()
> #12 0x0017aeb9 in cp_parser_declaration ()
> #13 0x0017b21e in cp_parser_declaration_seq_opt ()
> #14 0x0017b576 in c_parse_file ()
> #15 0x00280a78 in c_common_parse_file ()
> #16 0x00bee0e5 in compile_file ()
> #17 0x01b02420 in toplev::main ()
> #18 0x01b03a34 in main ()
>
> I'll have to rebuild my gcc with debug info to get a better backtrace. It
> might be an entirely different issue that's just triggered by the same
> testcase, though, so I'm leaving this bug as UNCONFIRMED for now.
This ICE seems to have disappeared on me; file compiles successfully for me
now, but the resulting executable crashes when run:
$ /usr/local/bin/g++ -std=gnu++11 -framework CoreFoundation -lobjc -g -Wall
-Wextra -pedantic -o 57607.exe test57607.mm
$ ./57607.exe && echo $?
Hello world!
Bus error
$
gdb shows the error comes from objc_msgSend:
.+.... done
Hello world!
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x940e968c in objc_msgSend ()
(gdb) bt
#0 0x940e968c in objc_msgSend ()
#1 0x00001e81 in main () at test57607.mm:10
#2 0x00001dde in start ()
(gdb) quit
The program is running. Exit anyway? (y or n) y
objc_msgSend comes from the system libobjc, so this is an issue with Apple's
system libraries for my (outdated) OS version, not gcc. So since this is no
longer gcc's issue and the original ICE is fixed, I can close this as FIXED.
