[Bug c++/54002] New: [C++0x][constexpr] Initializing constexpr static member using constexpr static method fails

["Martin.vGagern at gmx dot net" <gcc-bugzilla at gcc dot gnu dot org>]

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

             Bug #: 54002
           Summary: [C++0x][constexpr] Initializing constexpr static
                    member using constexpr static method fails
    Classification: Unclassified
           Product: gcc
           Version: 4.7.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: Martin.vGagern@gmx.net


I would expect the following code to work with -std=gnu++0x, but it does not:

class C1 {
  constexpr static int foo(int x) { return x + 1; }
  constexpr static int bar = foo(sizeof(int));
};

g++ 4.5 complains:
error: âstatic int C1::foo(int)â cannot appear in a constant-expression
error: a function call cannot appear in a constant-expression

g++ 4.6 and 4.7 complain:
error: field initializer is not constant



Detailed analysis of this problem follows below.

As the function is declared to be constexpr, this surprises me. I took this to
Stack Overflow to get some insight:
http://stackoverflow.com/q/11522399/1468366

In his answer http://stackoverflow.com/a/11523155/1468366, Ben Voigt quoted
relevant parts from the spec. The most likely cause for this *not* being a
constant expression appears to be section 5.19 paragraph 2 item 3:
"an invocation of an undefined constexpr function [â]"
qutoed from http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf

But the definition is there, right in the class. Neither of us could find a
part in the specification which might cause the function to not be defined at
that point, particularly as the class is completely defined within the
initializer, according to section 9.2 paragraph 2.

In case there actually is some part of the spec which makes gccs current
behaviour the only correct one, then please consider this report here as a
request for a more useful error message, which might make the actual problem
known without having to read the specs for hours.

If, on the other hand, the specs allow code like the one above, as I believe
they do, then please try to make gcc accept that code as well.