On Tue, Jul 29, 2025 at 02:04:52PM +0200, Jakub Jelinek wrote:
> On Tue, Jul 29, 2025 at 09:57:19PM +1000, Nathaniel Shead wrote:
> > @@ -7114,8 +7121,10 @@ trees_in::core_vals (tree t)
> > }
> >
> > RT (t->function_decl.personality);
> > - RT (t->function_decl.function_specific_target);
> > - RT (t->function_decl.function_specific_optimization);
> > + /* These properties are not streamed, and should be reconstructed
> > + from any function attributes. */
>
> I'd just like to chime in on this. I'm afraid that is not possible,
> because target/optimize attributes aren't the only way to add a non-standard
> TARGET_OPTION_NODE/OPTIMIZATION_NODE to a FUNCTION_DECL, #pragma GCC
> {target,optimize} can be used for that as well (and mixed with attributes).
>
Right; from my testing, though, the behaviour of the pragma is to
actually simulate an attribute being applied to each function declared
from that point on (until a pop_options, as necessary).
See decl_attributes in attribs.cc:639:
/* If this is a function and the user used #pragma GCC optimize, add the
options to the attribute((optimize(...))) list. */
if (TREE_CODE (*node) == FUNCTION_DECL && current_optimize_pragma)
{
tree cur_attr = lookup_attribute ("optimize", attributes);
tree opts = copy_list (current_optimize_pragma);
if (! cur_attr)
attributes
= tree_cons (get_identifier ("optimize"), opts, attributes);
else
TREE_VALUE (cur_attr) = chainon (opts, TREE_VALUE (cur_attr));
}
(and later for target pragma.)
> I agree it is better to sorry than ICE for 15.2, but eventually it might be
> better to stream the node. Of course it depends on how portable the modules
> file format is and whether one can compile with one version of compiler and
> use with say a few days later snapshot which could have some new option
> added.
We do currently say that this isn't supported, though in the case of
snapshots it appears we may not always check this if modules.cc wasn't
modified/rebuilt for the new version.
Nathaniel
