On 9/9/25 4:11 PM, Jakub Jelinek wrote:
On Fri, Sep 05, 2025 at 05:19:06PM +0200, Jason Merrill wrote:
Regarding temporaries, I wonder if we want to .DEFERRED_INIT them when
expanding TARGET_EXPRs in the gimplifier (but whether to do that always
when flag_auto_var_init != AUTO_INIT_UNINITIALIZED or for C++26 only),
or if it should be in the C++ gimplification hook (but then it is more
costly because it would need to create a GENERIC IFN CALL only to
immediately gimplify it).
I guess doing it whenever flag_auto_var_init is set makes sense.
The following WIP patch does that (except for TARGET_EXPR_SLOTS created for
[[indeterminate]] arguments.
Also, I haven't added yet CLOBBER (bob) for -flifetime-dse=2 addition for
new expressions before calling constructors (which is now desirable when
the ctors no longer clobber it themselves).
I'll look at this.
Ok. I wonder whether to keep adding CLOBBER (bob) as before to the start
of some of the ctors for -std=c++23 and earlier (unless
-ftrivial-auto-var-init= is specified). The current patch does that. If we
stop doing that, we'd need to emit also CLOBBER (bob) before the calls to
full object constructors for -flifetime-dse=2.
I had been thinking to do that at the same place as/instead of
-ftrivial-auto-var-init when =unitialized.
PARM_DECLs from function declarations (rather than definitions) are thrown
away, so guess we need to remember those say in some custom attribute on
the FUNCTION_DECLs (indexes of parameters with the attribute) and perhaps
when the FE creates TARGET_EXPRs for those params, mark their
TARGET_EXPR_SLOT with indeterminate attribute.
Doesn't the "Merge parameter attributes" code in duplicate_decls address
this?
You're right. I thought DECL_ARGUMENTS is only set on FUNCTION_DECLs with
definitions rather than declarations (I think that is the case for C FE),
but clearly C++ FE has DECL_ARGUMENTS even for declarations.
Added there diagnostics of [[indeterminate]] not specified on the first
declaration.
I guess we could change
{
T t;
do_stuff ();
label:
do_more ();
}
to
{
T t = ERR;
do_stuff ();
goto skip;
label:
t = ERR;
skip:
do_more ();
}
I'll try to work on this next, but it won't be trivial. The forward gotos
and switch cases are one thing and backward gotos another one, both need
to be handled differently, plus make it work properly with [[fallthrough]]
etc. (I'm contemplating on marking the if (0) { } around the extra labels
and perhaps moved case labels with some flag so that gimplification can
see it has been added artificially).
True, the above transformation works for switch or goto from outside the
scope of 't', but from within the scope of 't' you want them to jump to
'skip'. We would need check_previous_goto to be able to fix up a
previous goto to jump to the right label.
Jason
