On 3/8/24 12:02, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?-- >8 -- Consider constexpr int VAL = 1; struct foo { template <int B> void bar(typename std::conditional<B==VAL, int, float>::type arg) { } }; template void foo::bar<1>(int arg); where we since r11-291 fail to emit the code for the explicit instantiation. That's because cp_walk_subtrees/TYPENAME_TYPE now walks TYPE_CONTEXT ('conditional' here) as well, and in a template finds the B==VAL template argument. VAL is constexpr, which implies const, which in the global scope implies static. constrain_visibility_for_template then makes "struct conditional<(B == VAL), int, float>" non-TREE_PUBLIC. Then symtab_node::needed_p checks TREE_PUBLIC, sees it's 0, and we don't emit any code. I thought the fix would be some ODR-esque check to not consider constexpr variables/fns that are used just for their value. But it turned out to be tricky. For instance, we can't skip determine_visibility in a template; we can't even skip it for value-dep expressions. For example, no-linkage-expr1.C has using P = struct {}*; template <int N> void f(int(*)[((P)0, N)]) {} where ((P)0, N) is value-dep, but N is not relevant here: we have to ferret out the anonymous type. When instantiating, it's already gone.
Hmm, how is that different from the B == VAL case? In both cases we're naming an internal entity that gets folded away.
I guess the difference is that B == VAL falls under the special allowance in https://eel.is/c++draft/basic.def.odr#14.5.1 because it's a constant used as a prvalue, and therefore is not odr-used under https://eel.is/c++draft/basic.def.odr#5.2
So I would limit this change to decl_constant_var_p. Really we should also be checking that the lvalue-rvalue conversion is applied, but that's more complicated.
Jason
