[Bug c++/63924] New: Constexpr constructible expression "is not constexpr" when used in a template non-type argument

[Bug c++/63924] New: Constexpr constructible expression "is not constexpr" when used in a template non-type argument

[mouchtaris at gmail dot com]

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

            Bug ID: 63924
           Summary: Constexpr constructible expression "is not constexpr"
                    when used in a template non-type argument
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mouchtaris at gmail dot com

A proper constexpr constructible type is found non-constexpr by the compiler,
under the following conditions:

- it is used in an expression which is passed as a template non-type argument,
- its copy constructor is defaulted (whether explicitly or implicitly).

In the following test case this is demostrated:

// -------------------------------------------------------
// File t.cpp
// -------------------------------------------------------
// utils
template <unsigned N> struct require_constexpr {
  static constexpr unsigned value = N;
};
template <typename...> constexpr void noop (void) { }

// a constexpr constructible class
struct test { 
  constexpr unsigned size() const { return 0; }
  constexpr test() { }
  constexpr test(const test &) = default;
};

// size wrappers
constexpr auto size0 (test t) { return t.size(); }
// just making sure type "test" is still considered
constexpr auto size1 (test t) { return size0(t); }
// constexpr constructible outside a template argument
constexpr auto size2 (test t) { return size1(t); }
// PROBLEM here
constexpr auto size3 (test t) { return require_constexpr< size0(t) >::value; }

int main (int, char**)
{
  constexpr auto const ar = test { };

  noop<
    require_constexpr< size3(ar) >
  >();

  return 0;
}
// -------------------------------------------------------


Compiling with
    g++ -std=c++1y -pedantic -Wall -Wextra -o /tmp/a t.cpp 

and here is the output:
//--------------------------------------------------------
t.cpp: In function ‘constexpr auto size3(test)’:
t.cpp:22:68: error: ‘t’ is not a constant expression
 constexpr auto size3 (test t) { return require_constexpr< size0(t) >::value; }
                                                                    ^
t.cpp:22:68: note: in template argument for type ‘unsigned int’ 
t.cpp:22:16: error: invalid return type ‘void’ of constexpr function ‘constexpr
auto size3(test)’
 constexpr auto size3 (test t) { return require_constexpr< size0(t) >::value; }
                ^
t.cpp: In function ‘int main(int, char**)’:
t.cpp:29:34: error: could not convert template argument ‘size3((ar, test()))’
to ‘unsigned int’
     require_constexpr< size3(ar) >
                                  ^
t.cpp:30:5: error: no matching function for call to ‘noop()’
   >();
     ^
t.cpp:30:5: note: candidate is:
t.cpp:6:39: note: template<class ...> constexpr void noop()
 template <typename...> constexpr void noop (void) { }
                                       ^
t.cpp:6:39: note:   template argument deduction/substitution failed:
t.cpp:30:5: error: template argument 1 is invalid
   >();
     ^
//--------------------------------------------------------

"test" is still properly constexpr-copy-constructed when used outside
template arguments, as in size1() and size2().

The code segment also compiles cleanly if we define a non-default constructor.
In other words, if we change line
  constexpr test(const test &) = default;
to
  constexpr test(const test &) { }

So the bug (probably) pertrains to defaulting constructors and the use of such
in non-type template arguments.
>From gcc-bugs-return-467099-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Nov 18 01:11:09 2014
Return-Path: <gcc-bugs-return-467099-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15776 invoked by alias); 18 Nov 2014 01:11:08 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 15713 invoked by uid 48); 18 Nov 2014 01:10:59 -0000
From: "mouchtaris at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63924] Constexpr constructible expression "is not constexpr" when used in a template non-type argument
Date: Tue, 18 Nov 2014 01:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mouchtaris at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63924-4-Y43lGw1XAR@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63924-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63924-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg01571.txt.bz2
Content-length: 224

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc924

--- Comment #1 from Nikos <mouchtaris at gmail dot com> ---
Special thanks and kudos to "T.C." for helping figuring this out:

http://stackoverflow.com/questions/25465379

[Bug c++/63924] Constexpr constructible expression "is not constexpr" when used in a template non-type argument

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2014-11-19
                 CC|                            |jason at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |jason at gcc dot gnu.org
   Target Milestone|---                         |5.0
     Ever confirmed|0                           |1

--- Comment #2 from Jason Merrill <jason at gcc dot gnu.org> ---
> constexpr auto size3 (test t) { return require_constexpr< size0(t) >::value; }

The problem here is that 't' is non-constant within size3 and the implicit
trivial copy constructor does a bitwise copy, which involves copying a
(non-constant) byte of padding, whereas your user-provided copy constructor
doesn't copy anything.  This seems like a grey area in the standard, but I'll
go ahead and make it work for now.

[Bug c++/63924] Constexpr constructible expression "is not constexpr" when used in a template non-type argument

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill <jason at gcc dot gnu.org> ---
Author: jason
Date: Wed Nov 19 03:03:45 2014
New Revision: 217749

URL: https://gcc.gnu.org/viewcvs?rev=217749&root=gcc&view=rev
Log:
    PR c++/63924
    * constexpr.c (cxx_eval_constant_expression) [PARM_DECL]: A load
    from a variable of empty class type is constant.

Added:
    trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-empty8.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/constexpr.c

[Bug c++/63924] Constexpr constructible expression "is not constexpr" when used in a template non-type argument

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from Jason Merrill <jason at gcc dot gnu.org> ---
Fixed.

[Bug c++/63924] Constexpr constructible expression "is not constexpr" when used in a template non-type argument

[mouchtaris at gmail dot com]

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

--- Comment #5 from Nikos <mouchtaris at gmail dot com> ---
I am sorry, it is missing from the original test case, but

  noop<
    require_costexpr< size0(ar) >,
    require_constexp< size1(ar) >
  >();

compiles fine. If the issue about test's trivial byte-wise copy construction is
true, shouldn't it cause the degenaration of size0's and size1's constexpr-ness
and cause errors in their usage as template arguments?

Standard-addressing issues are mentioned in the stackoverflow link I have
provided. Specifically, the following comes from §12.8 [class.copy]/p13:

  If the implicitly-defined constructor would satisfy the requirements of a
  constexpr constructor (7.1.5), the implicitly-defined constructor is
constexpr.

I don't see why an implicit constructor copying a literal padding byte is not a
constexpr constructor. The compiler, I assume, is capable of keeping track of
padding bytes as literals at compile time. Or am I mistaken?

Thanks a lot for the fix, and thanks a lot for such a quick response.
>From gcc-bugs-return-467623-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Nov 19 22:18:07 2014
Return-Path: <gcc-bugs-return-467623-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8210 invoked by alias); 19 Nov 2014 22:18:07 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 8094 invoked by uid 48); 19 Nov 2014 22:18:03 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/63958] [5 Regression] bootstrap failure in the sanitizer libs on sparc-linux-gnu
Date: Wed, 19 Nov 2014 22:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-63958-4-NFMUbiG30V@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63958-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63958-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg02095.txt.bz2
Content-length: 480

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc958

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
I am offering testing Sparc changes upstream.  If you want, I
can submit your changes upstream under my name.

[Bug c++/63924] Constexpr constructible expression "is not constexpr" when used in a template non-type argument

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Nikos from comment #5)
> I am sorry, it is missing from the original test case, but
> 
>   noop<
>     require_costexpr< size0(ar) >,
>     require_constexp< size1(ar) >
>   >();
> 
> compiles fine.

Yes, because ar is a constexpr variable.  The parameter 't' of size3 is not a
constexpr variable.  When compiling a constexpr function, the parameters are
not constant; only in a call to that function are the parameters (sometimes)
replaced by constants.  Remember that a constexpr function is still a normal
function, and can be called with non-constant arguments.

I agree that the compiler should treat the implicit trivial constructor the
same as the user-defined constructor.