From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 4ABDD385801D; Thu, 23 Sep 2021 07:08:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4ABDD385801D From: "linkw at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO Date: Thu, 23 Sep 2021 07:08:44 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 10.3.1 X-Bugzilla-Keywords: lto X-Bugzilla-Severity: normal X-Bugzilla-Who: linkw at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: linkw at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2021 07:08:45 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102347 --- Comment #9 from Kewen Lin --- (In reply to Peter Bergner from comment #7) > (In reply to Martin Li=C5=A1ka from comment #6) > > Quickly looking at the rs6000 code, it fails here: > >=20 > > #1 0x0000000011a0993c in rs6000_invalid_builtin > > (fncode=3DMMA_BUILTIN_DISASSEMBLE_ACC_INTERNAL) at > > ../../gcc/config/rs6000/rs6000-call.c:11643 > > #2 0x0000000011a13134 in rs6000_builtin_decl (code=3D1603, initialize_= p=3Dtrue) > > at ../../gcc/config/rs6000/rs6000-call.c:13870 > > #3 0x00000000115c3900 in unpack_ts_function_decl_value_fields > > (bp=3D0x3fffffffe2f0, expr=3D0x3fffaf195700) at ../../gcc/tree-streamer= -in.c:361 > > #4 0x00000000115c4790 in streamer_read_tree_bitfields (ib=3D0x3fffffff= e6a0, > > data_in=3D0x132d1910, expr=3D0x3fffaf195700) at ../../gcc/tree-streamer= -in.c:528 > > #5 0x0000000010deaa28 in lto_read_tree_1 (ib=3D0x3fffffffe6a0, > > data_in=3D0x132d1910, expr=3D0x3fffaf195700) at ../../gcc/lto-streamer-= in.c:1697 > >=20 > > which relies on rs6000_builtin_mask. Note the mask is set here: > > rs6000_builtin_mask =3D rs6000_builtin_mask_calculate (); > >=20 > > where rs6000_builtin_mask_calculate is based on TARGET_* values. >=20 > Is that really the issue though? In a non-lto compile, > handle_pragma_target() ends up calling rs6000_option_override_internal wh= ich > sets the TARGET_* flags for the function given the pragma options. Where > does LTO do that? I think I see lto read in the default options that were > set on the command line, but where and when does LTO set the options defi= ned > by the pragma? Are they even streamed out to the fat obj file? They cou= ld > be there, but I'm not seeing it. I guess the problem here is this bif checking is so early, it's when we mak= e up the bif function_decl tree_node, at that time the context is still the one = with default option. I may be wrong, what I understood is that the target_option= is streamed out as part of its associated function decl into decls section, wh= en streaming in the decls section, the decls are constructed (including functi= on decls with target_option and bif decls), the bif validity checking happen h= ere. But function decls with target_option will be used for setting current func= tion later when lto starts to process cgraph_node one by one. IIUC, fat obj file should not affect since it's mainly to control normal non-lto sections generated or not.=