Motivated by the StackOverflow post: https://stackoverflow.com/questions/66214214/different-sfinae-behavior-of-stdtuple-size-v-on-different-compilers The following code does not compile: #include <type_traits> #include <iostream> template<typename T> constexpr int f() { return T::value; } template<typename T> constexpr int z = T::value; template<typename T, typename = int> struct G : std::false_type {}; template<typename T> struct G<T, decltype(z<T>)> : std::true_type {}; // error // template<typename T> struct G<T, decltype(f<T>())> : std::true_type {}; // ok int main() { std::cout << G<int>::value; } Here the definition of z<T> is not required, so its definition shouldn't be implicitly instantiated. Note if we replace z<T> by f<T>(), the code compiles successfully.
Interesting only clang accepts the code, ICC and MSVC reject it for the same reason as GCC.
Reduced testcase: template<typename T> constexpr int z = T::value; int main() { decltype(z<int>) a = 1; }
Here is another example: template<typename T> constexpr int z = T::value; int main() { return sizeof(z<int>) != sizeof(int); }
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>: https://gcc.gnu.org/g:4db3cb781c355341fa041e6b5bbbfc495c6a0fdb commit r13-2540-g4db3cb781c355341fa041e6b5bbbfc495c6a0fdb Author: Patrick Palka <ppalka@redhat.com> Date: Thu Sep 8 09:45:45 2022 -0400 c++: unnecessary instantiation of constexpr var [PR99130] Here the use of 'value' from within an unevaluated context causes us to overeagerly instantiate it, via maybe_instantiate_decl called from mark_used, despite the use occurring in a context that doesn't require a definition. This seems to only affect constexpr variable specializations, though we used to have the same issue for constexpr function specializations until r6-1309-g81371eff9bc7ef made us delay their instantiation until necessary during constexpr evaluation. This patch expands upon the r6-1309 fix to make mark_used avoid unnecessarily instantiating constexpr variable specializations too, by pulling out from maybe_instantiate_decl the condition (decl_maybe_constant_var_p (decl) || (TREE_CODE (decl) == FUNCTION_DECL && DECL_OMP_DECLARE_REDUCTION_P (decl)) || undeduced_auto_decl (decl)) into each of its three callers (including mark_used), removing the problematic first test from mark_used, and simplifying accordingly. The net result is that only mark_used is changed because the other two callers, resolve_address_of_overloaded_function and decl_constant_var_p, already guard the call appropriately. (This relaxation of mark_used seems to be safe because during constexpr evaluation we already take care to instantiate a constexpr variable as necessary via decl_constant_value etc). PR c++/99130 gcc/cp/ChangeLog: * decl2.cc (maybe_instantiate_decl): Adjust function comment. Check VAR_OR_FUNCTION_DECL_P. Pull out the disjunction into ... (mark_used): ... here, removing the decl_maybe_constant_var_p part of it. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-decltype5.C: New test.
Fixed for GCC 13, thanks for the bug report.