From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id E8ECB3858C39; Thu, 16 Sep 2021 10:36:00 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E8ECB3858C39
From: "linkw at gcc dot gnu.org" <gcc-bugzilla@gcc.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, 16 Sep 2021 10:36:00 +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: <bug-102347-4-NQlCoetm9Y@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-102347-4@http.gcc.gnu.org/bugzilla/>
References: <bug-102347-4@http.gcc.gnu.org/bugzilla/>
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 <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Sep 2021 10:36:01 -0000

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

--- Comment #3 from Kewen Lin <linkw at gcc dot gnu.org> ---
This seems not a target specific issue. I noticed the target_option tree no=
de
is created expectedly when seeing target pragma, it explains why it works w=
ell
without lto. When lto does streaming out, it does stream the target_option
node.=20

Creating output block for decls
Creating compressed section .gnu.lto_.decls.db802b44a7cc3ae9
Outputting global stream
 0:  <function_decl 0x7d785d7f9e00 main>
    Streaming tree  <function_decl 0x7d785d7f9e00 main>
     Start of LTO_tree_scc of size 1
      Streaming header of  <optimization_node 0x7d785d590000>  to decls
      Streaming body of  <optimization_node 0x7d785d590000>  to decls
     286 bytes
     Start of LTO_tree_scc of size 1
      Streaming header of  <target_option_node 0x7d785d580030>  to decls
      Streaming body of  <target_option_node 0x7d785d580030>  to decls
     149 bytes

But debugging the read_decls part, I noticed it can materialize the
corresponding option_node, but it seems we don't associate this option_node=
 to
the related function_decl.=20


I constructed one aarch64 test case, it fails as well.

int64x2_t v1 =3D {100, 200};
int32x4_t v2 =3D {11, 22, 33, 44};

#pragma GCC target ("+simd")
int main()
{
  uint64x2_t vres =3D (uint64x2_t) __builtin_aarch64_usubw2v4si (v1, v2);
  printf("vres: %lld %lld\n", vres[0], vres[1]);
  return 0;
}

Command: -march=3Darmv8-a+nosimd -flto

It can pass without -flto.=