[Bug c++/124477] [14/15/16 Regression] ICE in nonnull_arg_p in call to memset via std module with -D_FORTIFY_SOURCE=1
jakub at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Sat Mar 21 07:42:16 GMT 2026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124477
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Nathaniel Shead from comment #9)
> (In reply to Jakub Jelinek from comment #8)
> > Talking about DECL_ARGUMENTS, for -freflection we now track whether a
> > PARM_DECL had different names and if not, care about the name even in just
> > declarations.
> > E.g.
> > https://eel.is/c++draft/meta.reflection#names-1.8
> > Wonder what survives from that for modules, what should happen if
> > declarations of the same function come from multiple different modules etc.
>
> Modules streaming will need to be adjusted. We currently just merge the
> parameters directly, so if there's an existing declaration we just use those
> PARM_DECLs and throw away the ones we're currently reading.
>
> We'll probably need to call 'merge_decl_arguments' in
> 'trees_in::fn_parms_fini'. But I'm not sure if we can just call it as-is or
> if it makes assumptions about the ordering of declarations that can arrive,
> and e.g. that we can see multiple definitions for the same declaration.
>
> Eventually the aim is that we should probably teach 'duplicate_decls' about
> modules and just use that instead of just the modules-specific logic we have
> separate currently. This will be needed for PR99000, for instance. But
> that will be a lot of work so just duplicating the necessary logic with
> modules understanding in 'trees_in::fn_parms_fini' might be the best
> approach for now.
For the has_identifier thing etc., i.e. DECL_NAME, MULTIPLE_NAMES_PARM_P flag,
"old parm name" attribute, DECL_HAS_DEFAULT_ARGUMENT_P flag
merge_decl_arguments only cares about whether there is just one definition of a
function and everything else are declarations (with modules can one have
multiple inline definitions as long as all of them are the same?).
Then there is the OLD_PARM_DECL_P flag set elsewhere (directly in
duplicate_decls and elsewhere). That needs to be set for the case where two
FUNCTION_DECLs are merged and DECL_CONTEXT of the parms of the one being merged
into the other is adjusted to the one which will be kept afterwards. In that
case OLD_PARM_DECL_P needs to be set on the PARM_DECLs which have changed
DECL_CONTEXT. This is just for the case where some reflections could be
already refering to the old parms and need to be told that they need to update
to the corresponding new PARM_DECL.
And finally there are annotations in DECL_ATTRIBUTES. And C++ requires them to
be
https://eel.is/c++draft/meta.reflection#annotation-2.sentence-2 and
https://eel.is/c++draft/meta.reflection#annotation-2.sentence-3 ordered (in GCC
that is actually reverse ordering of that in DECL_ATTRIBUTES, the first one
that appears there is the last one). Annotations are merged by
merge_decl_arguments for PARM_DECLs, but manually for other declarations.
Dunno what precedes means in the modules world.
More information about the Gcc-bugs
mailing list