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

[linkw at gcc dot gnu.org]

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

--- Comment #9 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #7)
> (In reply to Martin Liška from comment #6)
> > Quickly looking at the rs6000 code, it fails here:
> > 
> > #1  0x0000000011a0993c in rs6000_invalid_builtin
> > (fncode=MMA_BUILTIN_DISASSEMBLE_ACC_INTERNAL) at
> > ../../gcc/config/rs6000/rs6000-call.c:11643
> > #2  0x0000000011a13134 in rs6000_builtin_decl (code=1603, initialize_p=true)
> > at ../../gcc/config/rs6000/rs6000-call.c:13870
> > #3  0x00000000115c3900 in unpack_ts_function_decl_value_fields
> > (bp=0x3fffffffe2f0, expr=0x3fffaf195700) at ../../gcc/tree-streamer-in.c:361
> > #4  0x00000000115c4790 in streamer_read_tree_bitfields (ib=0x3fffffffe6a0,
> > data_in=0x132d1910, expr=0x3fffaf195700) at ../../gcc/tree-streamer-in.c:528
> > #5  0x0000000010deaa28 in lto_read_tree_1 (ib=0x3fffffffe6a0,
> > data_in=0x132d1910, expr=0x3fffaf195700) at ../../gcc/lto-streamer-in.c:1697
> > 
> > which relies on rs6000_builtin_mask. Note the mask is set here:
> > rs6000_builtin_mask = rs6000_builtin_mask_calculate ();
> > 
> > where rs6000_builtin_mask_calculate is based on TARGET_* values.
> 
> Is that really the issue though?  In a non-lto compile,
> handle_pragma_target() ends up calling rs6000_option_override_internal which
> 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 defined
> by the pragma?  Are they even streamed out to the fat obj file?  They could
> be there, but I'm not seeing it.

I guess the problem here is this bif checking is so early, it's when we make 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, when
streaming in the decls section, the decls are constructed (including function
decls with target_option and bif decls), the bif validity checking happen here.
But function decls with target_option will be used for setting current function
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.