On 7/31/25 10:34 AM, Jason Merrill wrote:
On 7/29/25 8:10 AM, Nathaniel Shead wrote:
Thoughts? Another suggestion raised on the PR was to just make this a
warning or some other non-fatal diagnostic (I suppose not attached to
any particular warning option?) and continue translation; I'm not
particularly fussed either way.
An unconditional warning sounds good.
...OK with that change.
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.
module_state::read_config complains about trunk snapshots from different
days, or different release versions, but it looks like it doesn't
distinguish between release branch snapshots because DEV-PHASE is the
same between snapshots and releases.
Would it make sense to have DEV-PHASE as "prerelease" between actual
releases?
Alternately s-cp-module-version could look for .1 in BASE-VER.
Jason
