From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9C14F3858D35; Sun, 30 Jul 2023 11:26:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9C14F3858D35 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1690716397; bh=j0JMW0xNRlapMLlGwKWVfW0owPc9f+VvPuIC5MIr830=; h=From:To:Subject:Date:In-Reply-To:References:From; b=h2bOYlMYiGltJFzEeIdd7KnTRplW23fVlv1aVj55PcT1Yhqa3mKlKK5dYtzAfOzUo ODgFCxXKhIRriaHgl2lkyc/J1wnFykld3iDw4lMIS5C+CJWEibpmf+R55V9rRCAapT w43ueG+Ss4h0idGx8zGnQ1EI89lbQ2xwBXNdTrKQ= From: "iains at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug objc++/61759] [ICE] [objc++] reaching gcc_unreachable in objc_eh_runtime_type at objc/objc-next-runtime-abi-01.c Date: Sun, 30 Jul 2023 11:26:36 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: objc++ X-Bugzilla-Version: 5.2.0 X-Bugzilla-Keywords: EH, ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: iains at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cf_gcctarget Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D61759 Iain Sandoe changed: What |Removed |Added ---------------------------------------------------------------------------- Target|*-*-darwin |powerpc-*-darwin, | |i686-*-darwin --- Comment #15 from Iain Sandoe --- (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 f= or '-m64') A guess would be that we have a conflict between C++ exception handling (DW= ARF unwinding) and runtime-abi-01 exception handling (set jump / long jump).=20 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 affe= cted targets are 32b powerpc and i686 Darwin. =3D=3D=3D=3D=3D backtrace for curent trunk: * frame #0: 0x00000001021b78a5 cc1objplus`internal_error(gmsgid=3D"in %s,= at %s:%d") at diagnostic.cc:2166:25 frame #1: 0x00000001021b7d8b cc1objplus`fancy_abort(file=3D"/src-local/gcc-master/gcc/objc/objc-next-run= time-abi-01.cc", line=3D2795, function=3D"objc_eh_runtime_type") at diagnostic.cc:2296:18 frame #2: 0x000000010003dab7 cc1objplus`::objc_eh_runtime_type(type=3D0x000000011401c5e8) at objc-next-runtime-abi-01.cc:2795:3 frame #3: 0x00000001011501ad cc1objplus`add_type_for_runtime(type=3D0x000000011401c5e8) at except.cc:683= :40 frame #4: 0x000000010114f8c4 cc1objplus`gen_eh_region_catch(t=3D0x0000000117c3b318, type_or_list=3D0x000000011401c5e8) at except.cc:424:23 frame #5: 0x0000000101a400bb cc1objplus`::lower_catch(state=3D0x0000000309267190, tp=3D0x000000014813f69= 0) at tree-eh.cc:1815:31 frame #6: 0x0000000101a40cfe cc1objplus`::lower_eh_constructs_2(state=3D0x0000000309267190, gsi=3D0x0000000309267140) at tree-eh.cc:2107:27 frame #7: 0x0000000101a40e17 cc1objplus`::lower_eh_constructs_1(state=3D0x0000000309267190, pseq=3D0x0000000309267188) at tree-eh.cc:2153:27 frame #8: 0x0000000101a40f46 cc1objplus`pass_lower_eh::execute(this=3D0x000060000260c540, fun=3D0x00000001480e8678) const at tree-eh.cc:2198:25 frame #9: 0x00000001017b5131 cc1objplus`execute_one_pass(pass=3D0x000060000260c540) at passes.cc:2641:30 frame #10: 0x00000001017b5570 cc1objplus`::execute_pass_list_1(pass=3D0x000060000260c540) at passes.cc:27= 50:28 frame #11: 0x00000001017b5607 cc1objplus`execute_pass_list(fn=3D0x00000001480e8678, pass=3D0x000060000260= c240) at passes.cc:2761:23 frame #12: 0x0000000100fe00c4 cc1objplus`cgraph_node::analyze(this=3D0x0000000148128990) at cgraphunit.cc:694:22 frame #13: 0x0000000100fe23d1 cc1objplus`::analyze_functions(first_time=3Dtrue) at cgraphunit.cc:1247:18 frame #14: 0x0000000100fe5ed4 cc1objplus`symbol_table::finalize_compilation_unit(this=3D0x000000011400600= 0) at cgraphunit.cc:2554:21 frame #15: 0x0000000101987ad5 cc1objplus`::compile_file() at toplev.cc:471:41 frame #16: 0x000000010198b4f0 cc1objplus`::do_compile(no_backend=3Dfals= e) at toplev.cc:2126:24 frame #17: 0x000000010198ba34 cc1objplus`toplev::main(this=3D0x000000030926751a, argc=3D16, argv=3D0x0000000309267668) at toplev.cc:2282:18 frame #18: 0x0000000102187a64 cc1objplus`main(argc=3D16, argv=3D0x0000000309267668) at main.cc:39:23=