[Bug c++/52282] New: [C++0x] ICE / confused by earlier errors with decltype/constexpr

[Bug c++/52282] New: [C++0x] ICE / confused by earlier errors with decltype/constexpr

[andyg1001 at hotmail dot co.uk]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282

             Bug #: 52282
           Summary: [C++0x] ICE / confused by earlier errors with
                    decltype/constexpr
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: andyg1001@hotmail.co.uk


The following code causes the compiler problems.  The version I am using is gcc
4.7.0-20120210.


template <typename T, T V>
struct A
    {
    static constexpr T a() { return V; }
    };

template <typename T, T V>
struct B
    {
    typedef T type;
    static constexpr type b() { return V; }
    };

template <typename T, T V>
struct C
    {
    static constexpr decltype(V) c() { return V; }
    };

static_assert(A<int, 10>::a() == 10, "oops");
static_assert(B<int, 10>::b() == 10, "oops");
static_assert(C<int, 10>::c() == 10, "oops");

struct D
    {
    static constexpr int d() { return 10; }
    };

static_assert((A<int(*)(), &D::d>::a())() == 10, "oops");
static_assert((B<int(*)(), &D::d>::b())() == 10, "oops"); // line 30
static_assert((C<int(*)(), &D::d>::c())() == 10, "oops");


The code as given above will give the following output:

1.cpp:30:1: error: non-constant condition for static assertion
1.cpp:30:38: error: expression ‘D::d’ does not designate a constexpr function
1.cpp:17: confused by earlier errors, bailing out

Commenting out the line 30 will produce an ICE instead:

1.cpp: In instantiation of ‘struct C<int (*)(), D::d>’:
1.cpp:31:34:   required from here
1.cpp:17:31: internal compiler error: in finish_decltype_type, at
cp/semantics.c:5277

There are two issues here: the first is, of course, the ICE; the second is that
gcc is not correctly determining the return type when it is abstracted as in
structs B and C and the type is a static function pointer.

Note that non-static member function pointers do not generate either issues,
although it is necessary to add "const" to the pointer type but not to the
corresponding function definition:

struct E
    {
    constexpr int e() { return 10; }
    };

constexpr E e;
static_assert((e.*A<int(E::*)()const, &E::e>::a())() == 10, "oops");
static_assert((e.*B<int(E::*)()const, &E::e>::b())() == 10, "oops");
static_assert((e.*C<int(E::*)()const, &E::e>::c())() == 10, "oops");

[Bug c++/52282] [C++0x] ICE / confused by earlier errors with decltype/constexpr

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282

Daniel Krügler <daniel.kruegler at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler at
                   |                            |googlemail dot com

--- Comment #1 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2012-02-16 19:24:10 UTC ---
(In reply to comment #0)
> Note that non-static member function pointers do not generate either issues,
> although it is necessary to add "const" to the pointer type but not to the
> corresponding function definition:

Adding const to the function type is required, because the constexpr specifier
for any non-static member functions behaves as if the function were declared as
const member function.

[Bug c++/52282] [C++0x] ICE / confused by earlier errors with decltype/constexpr

[andyg1001 at hotmail dot co.uk]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282

--- Comment #2 from andyg1001 at hotmail dot co.uk 2012-02-24 17:42:59 UTC ---
Created attachment 26743
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26743
test-case for decltype ICE / incorrect evaluation of constexpr

The attached test-case source expands on my previous bug report and shows where
the ICE occurs with decltype but also where the compiler fails to detect that a
value is actually constexpr (lines marked "incorrect evaluation").  What is
interesting is that the incorrect evaluation does not occur for comparable use
inside main().

GCC version: g++ (GCC) 4.7.0 20120224 (experimental)

[Bug c++/52282] [C++0x] ICE / confused by earlier errors with decltype/constexpr

[andyg1001 at hotmail dot co.uk]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282

--- Comment #3 from andyg1001 at hotmail dot co.uk 2012-05-04 16:22:21 UTC ---
This ICE still occurs in the release version of gcc 4.7.0.

Here is the output from compiling the attached test-case as is:

$ g++-4.7 -std=c++11 ice.cpp
ice.cpp: In instantiation of ‘struct Z<const int*, (& a)>’:
ice.cpp:39:33:   required from here
ice.cpp:11:41: internal compiler error: in finish_decltype_type, at
cp/semantics.c:5277
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
Preprocessed source stored into /tmp/ccPyRnUB.out file, please attach this to
your bugreport.

And if the lines in the test-case marked "ICE" are commented out, then this is
the output:

$ g++-4.7 -std=c++11 ice.cpp
ice.cpp:47:1: error: non-constant condition for static assertion
ice.cpp:47:43: error: expression ‘b<10>’ does not designate a constexpr
function
ice.cpp:48:1: error: non-constant condition for static assertion
ice.cpp:48:43: error: expression ‘b<10>’ does not designate a constexpr
function
ice.cpp:64:1: error: non-constant condition for static assertion
ice.cpp:64:56: error: expression ‘0u’ does not designate a constexpr function
ice.cpp:65:1: error: non-constant condition for static assertion
ice.cpp:65:56: error: expression ‘0u’ does not designate a constexpr function
ice.cpp:66:1: error: non-constant condition for static assertion
ice.cpp:66:56: error: expression ‘0u’ does not designate a constexpr function
ice.cpp:67:1: error: non-constant condition for static assertion
ice.cpp:67:56: error: expression ‘0u’ does not designate a constexpr function
ice.cpp:70:1: error: non-constant condition for static assertion
ice.cpp:70:43: error: expression ‘C::c2’ does not designate a constexpr
function
ice.cpp:71:1: error: non-constant condition for static assertion
ice.cpp:71:43: error: expression ‘C::c2’ does not designate a constexpr
function

The attached test-case compiles and runs successfully under clang with one
small change as shown in this diff (this doesn't affect the test-case under
gcc):

--- ice.cpp
+++ ice.cpp
@@ -53,6 +53,7 @@
 static_assert(Z_<int(*)(), &b<10>>::value() == 10, "oops");    // ICE

 constexpr struct C {
+    constexpr C() = default;
     constexpr int c1() const { return 10; }
     static constexpr int c2() { return 10; }
 } c;

[Bug c++/52282] [C++0x] ICE / confused by earlier errors with decltype/constexpr

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282

--- Comment #4 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2012-05-04 16:42:39 UTC ---
(In reply to comment #3)
> This ICE still occurs in the release version of gcc 4.7.0.

And also in 4.8.0 HEAD btw.

> The attached test-case compiles and runs successfully under clang with one
> small change as shown in this diff (this doesn't affect the test-case under
> gcc):
> 
> --- ice.cpp
> +++ ice.cpp
> @@ -53,6 +53,7 @@
>  static_assert(Z_<int(*)(), &b<10>>::value() == 10, "oops");    // ICE
> 
>  constexpr struct C {
> +    constexpr C() = default;
>      constexpr int c1() const { return 10; }
>      static constexpr int c2() { return 10; }
>  } c;

These changes are necessary for any reasonable comparison.

It seems to me that we have at least two compiler bugs here. 

1) The ICE
2) The incorrect diagnostics of some non-constexpr function.

The latter error reminds me very much of bug 52892 where it became clear that
gcc can loose constexpr information when typedefs and template parameters are
inserted.

[Bug c++/52282] [C++0x] ICE / confused by earlier errors with decltype/constexpr

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282

--- Comment #5 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-05-04 18:40:51 UTC ---
The ICEs, all of them, in the extended testcase too, seem easy to fix,
apparently it's just that finish_decltype_type doesn't handle ADDR_EXPR. The
remaining issues are more nasty, some can be fixed/wa with STRIP_NOPS, looks
like we have to handle many NOP_EXPRs, something I don't really understand.

[Bug c++/52282] [C++0x] ICE / confused by earlier errors with decltype/constexpr

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-05-07
                 CC|                            |paolo.carlini at oracle dot
                   |                            |com
     Ever Confirmed|0                           |1

--- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-05-07 09:50:43 UTC ---
For concreteness, with the below patchlet (for the record, about the
cxx_eval_call_expression bits, in build_data_member_initialization we have
something quite similar) all the test pass, besides the four lines:

static_assert((c.*W_<int(C::*)()const, &C::c1>::value)() == 10, "oops");
static_assert((c.*X_<int(C::*)()const, &C::c1>::value)() == 10, "oops");
static_assert((c.*Y_<int(C::*)()const, &C::c1>::value)() == 10, "oops");
static_assert((c.*Z_<int(C::*)()const, &C::c1>::value)() == 10, "oops");

///////////////

Index: semantics.c
===================================================================
--- semantics.c (revision 187228)
+++ semantics.c (working copy)
@@ -5269,6 +5269,7 @@ finish_decltype_type (tree expr, bool id_expressio

         case INTEGER_CST:
        case PTRMEM_CST:
+       case ADDR_EXPR:
           /* We can get here when the id-expression refers to an
              enumerator or non-type template parameter.  */
           type = TREE_TYPE (expr);
@@ -6488,6 +6489,12 @@ cxx_eval_call_expression (const constexpr_call *ol
       /* Might be a constexpr function pointer.  */
       fun = cxx_eval_constant_expression (old_call, fun, allow_non_constant,
                                          /*addr*/false, non_constant_p);
+      if (TREE_CODE (fun) == NOP_EXPR)
+       {
+         tree tmp = fun;
+         STRIP_NOPS (tmp);
+         fun = tmp;
+       }
       if (TREE_CODE (fun) == ADDR_EXPR)
        fun = TREE_OPERAND (fun, 0);
     }

[Bug c++/52282] [C++0x] ICE / confused by earlier errors with decltype/constexpr

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282

--- Comment #7 from Paolo Carlini <paolo.carlini at oracle dot com> 2013-05-01 11:48:38 UTC ---
With the fix for c++/57092 the ICEs are gone.

[Bug c++/52282] [C++0x] rejects-valid issues with decltype/constexpr

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill <jason at gcc dot gnu.org> ---
Author: jason
Date: Mon Nov 17 17:00:38 2014
New Revision: 217660

URL: https://gcc.gnu.org/viewcvs?rev=217660&root=gcc&view=rev
Log:
    PR c++/52282
    * decl.c (build_ptrmemfunc_type): Don't build a different
    RECORD_TYPE for a qualified PMF.
    * cp-tree.h (TYPE_PTRMEMFUNC_FN_TYPE): Merge cv-quals.
    (TYPE_PTRMEMFUNC_FN_TYPE_RAW): New.
    * decl2.c (cplus_decl_attributes): Use TYPE_PTRMEMFUNC_FN_TYPE_RAW.
    * tree.c (cp_walk_subtrees): Likewise.
    (cp_build_qualified_type_real): Remove special PMF handling.

Added:
    trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-decltype1.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/cp-tree.h
    trunk/gcc/cp/decl.c
    trunk/gcc/cp/decl2.c
    trunk/gcc/cp/tree.c

[Bug c++/52282] [C++0x] rejects-valid issues with decltype/constexpr

[jason at gcc dot gnu.org]

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

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

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

--- Comment #10 from Jason Merrill <jason at gcc dot gnu.org> ---
Fixed for GCC 5.