[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO

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

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

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

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. 


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

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

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

Command: -march=armv8-a+nosimd -flto

It can pass without -flto.