[Bug objc++/61759] [ICE] [objc++] reaching gcc_unreachable in objc_eh_runtime_type at objc/objc-next-runtime-abi-01.c

["iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|*-*-darwin                  |powerpc-*-darwin,
                   |                            |i686-*-darwin

--- Comment #15 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Sergey Fedorov from comment #14)
> (In reply to Eric Gallager from comment #8)

With current trunk on a cross to powerpc-apple-darwin9 this reproduces for the
runtime ABI 01 - which is used on 32b Darwin. (i.e the code compiles fine for
'-m64')

A guess would be that we have a conflict between C++ exception handling (DWARF
unwinding) and runtime-abi-01 exception handling (set jump / long jump). 
Probably, there needs to be some way to flag which kind of exception is
present.

For runtime ABI 02 (64bit) this should not happen - so the only really affected
targets are 32b powerpc and i686 Darwin.

===== backtrace for curent trunk:

  * frame #0: 0x00000001021b78a5 cc1objplus`internal_error(gmsgid="in %s, at
%s:%d") at diagnostic.cc:2166:25
    frame #1: 0x00000001021b7d8b
cc1objplus`fancy_abort(file="/src-local/gcc-master/gcc/objc/objc-next-runtime-abi-01.cc",
line=2795, function="objc_eh_runtime_type") at diagnostic.cc:2296:18
    frame #2: 0x000000010003dab7
cc1objplus`::objc_eh_runtime_type(type=0x000000011401c5e8) at
objc-next-runtime-abi-01.cc:2795:3
    frame #3: 0x00000001011501ad
cc1objplus`add_type_for_runtime(type=0x000000011401c5e8) at except.cc:683:40
    frame #4: 0x000000010114f8c4
cc1objplus`gen_eh_region_catch(t=0x0000000117c3b318,
type_or_list=0x000000011401c5e8) at except.cc:424:23
    frame #5: 0x0000000101a400bb
cc1objplus`::lower_catch(state=0x0000000309267190, tp=0x000000014813f690) at
tree-eh.cc:1815:31
    frame #6: 0x0000000101a40cfe
cc1objplus`::lower_eh_constructs_2(state=0x0000000309267190,
gsi=0x0000000309267140) at tree-eh.cc:2107:27
    frame #7: 0x0000000101a40e17
cc1objplus`::lower_eh_constructs_1(state=0x0000000309267190,
pseq=0x0000000309267188) at tree-eh.cc:2153:27
    frame #8: 0x0000000101a40f46
cc1objplus`pass_lower_eh::execute(this=0x000060000260c540,
fun=0x00000001480e8678) const at tree-eh.cc:2198:25
    frame #9: 0x00000001017b5131
cc1objplus`execute_one_pass(pass=0x000060000260c540) at passes.cc:2641:30
    frame #10: 0x00000001017b5570
cc1objplus`::execute_pass_list_1(pass=0x000060000260c540) at passes.cc:2750:28
    frame #11: 0x00000001017b5607
cc1objplus`execute_pass_list(fn=0x00000001480e8678, pass=0x000060000260c240) at
passes.cc:2761:23
    frame #12: 0x0000000100fe00c4
cc1objplus`cgraph_node::analyze(this=0x0000000148128990) at
cgraphunit.cc:694:22
    frame #13: 0x0000000100fe23d1
cc1objplus`::analyze_functions(first_time=true) at cgraphunit.cc:1247:18
    frame #14: 0x0000000100fe5ed4
cc1objplus`symbol_table::finalize_compilation_unit(this=0x0000000114006000) at
cgraphunit.cc:2554:21
    frame #15: 0x0000000101987ad5 cc1objplus`::compile_file() at
toplev.cc:471:41
    frame #16: 0x000000010198b4f0 cc1objplus`::do_compile(no_backend=false) at
toplev.cc:2126:24
    frame #17: 0x000000010198ba34
cc1objplus`toplev::main(this=0x000000030926751a, argc=16,
argv=0x0000000309267668) at toplev.cc:2282:18
    frame #18: 0x0000000102187a64 cc1objplus`main(argc=16,
argv=0x0000000309267668) at main.cc:39:23