[Bug c++/99130] New: Variable template in unevaluated context is wrongly implicitly instantiated

[Bug c++/99130] New: Variable template in unevaluated context is wrongly implicitly instantiated

[xskxzr at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99130

            Bug ID: 99130
           Summary: Variable template in unevaluated context is wrongly
                    implicitly instantiated
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: xskxzr at gmail dot com
  Target Milestone: ---

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.

[Bug c++/99130] Variable template in unevaluated context is wrongly implicitly instantiated

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99130

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Interesting only clang accepts the code, ICC and MSVC reject it for the same
reason as GCC.

[Bug c++/99130] variable template in unevaluated context is instantiated when should not be

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99130

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Variable template in        |variable template in
                   |unevaluated context is      |unevaluated context is
                   |wrongly implicitly          |instantiated when should
                   |instantiated                |not be

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Reduced testcase:
    template<typename T> constexpr int z = T::value;

    int main() {
        decltype(z<int>) a = 1;
    }

[Bug c++/99130] variable template in unevaluated context is instantiated when should not be

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99130

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-08-17
     Ever confirmed|0                           |1

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Here is another example:
    template<typename T> constexpr int z = T::value;
    int main() {
        return sizeof(z<int>) != sizeof(int);
    }

[Bug c++/99130] variable template in unevaluated context is instantiated when should not be

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99130

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
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.

[Bug c++/99130] variable template in unevaluated context is instantiated when should not be

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99130

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org
             Status|NEW                         |RESOLVED
   Target Milestone|---                         |13.0
                 CC|                            |ppalka at gcc dot gnu.org

--- Comment #5 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Fixed for GCC 13, thanks for the bug report.