On 11/1/25 5:12 AM, Nathaniel Shead wrote:
On Sat, Nov 01, 2025 at 01:10:43PM +1100, Nathaniel Shead wrote:
On Thu, Oct 30, 2025 at 07:15:01PM +0200, Jason Merrill wrote:
On 10/28/25 4:53 AM, Patrick Palka wrote:
On Sat, 18 Oct 2025, Patrick Palka wrote:
On Sat, 18 Oct 2025, Jason Merrill wrote:
Note local_variable_p also includes DECL_LOCAL_DECL_P decls (i.e.
block-scope externs), not sure what the linkage of those is but their
address could in theory be needed in a less contrived way inside a
template argument where it doesn't get folded at instantiation time.
Ah, good point, block-scope externs have linkage, so we don't want to
include them.
But perhaps local_variable_p itself is the problem; most uses of the term in
the standard have changed to "variables with automatic storage duration".
The primary use for a diagnostic in a default argument has now been changed
in the standard to refer to whether a local *entity* is odr-usable, which
does not apply to block-scope externs. The other uses of "local variable"
in the standard are talking about cleanup of automatic variables.
I think the only current use of local_variable_p where it would make sense
to include local externs is in tsubst_expr, but that function handles
DECL_LOCAL_DECL_P in the previous clause, so it's not needed there either.
So I'd be inclined to change local_variable_p to exclude block-scope
externs.
Local statics are another question; they can have "vague linkage" and
visibility even if they don't have linkage in the standard. And are also
not included in "local entity". But tsubst_expr seems to rely on them being
included in local_variable_p.
We might check decl_storage_duration == dk_auto instead of local_variable_p?
I think using decl_storage_duration makes the most sense, from my
understanding here. Below is an updated patch that uses this instead.
Actually, no, I don't think this is sufficient still; consider
template <typename T> inline void foo() {
static T t;
A<t> a;
}
In this case 't' is still !TREE_PUBLIC, but we have exactly the same
case as with automatic variables in that we might just be using it for
its value, but the A<t> instantiation still gets internal linkage.
Ah, indeed.
As such I think something like my v1 patch is probably the most accurate
in this case (though then we're back to the question of where to check
dependence and in what situations...).
I'm not sure entirely about the DECL_LOCAL_DECL_P case because it turns
out that modules crashes on instantiations naming such decls anyway;
I've made PR c++/122514 for this. But it looks like they may generally
be considered TREE_PUBLIC and so won't have this issue.
I think we want VISIBILITY_ANON if decl_linkage == lk_internal (and
DECL_VISIBILITY if lk_external).
Jason
