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.
