clang vs GCC error case: both ‘const’ and ‘constexpr’ cannot be used here

Clang Frontend
#1

Hi there,

clang compiles the following code, but GCC does not:

#include <iostream>

static constexpr const char Data[] = {
  'D', 'A', 'T', 'A',
};
static constexpr const char *data_func() { return Data; }

int main(int argc, char **argv)
{

  char c = 'T';

  switch(c)
  {
    case *data_func():
      std::cout << "GOT A D" << std::endl;
      break;
    case *(data_func() + 2):
      std::cout << "GOT A T" << std::endl;
  }
}

$ clang++ --version
clang version 3.2
Target: x86_64-unknown-linux-gnu
Thread model: posix

$ g++ -dumpversion
4.6.1

$ g++ main.cpp -std=c++0x
main.cpp:163:48: error: both ‘const’ and ‘constexpr’ cannot be used here

Which compiler is buggy?

Thanks,

Steve.

#2

[dcl.constexpr]p9: A constexpr specifier used in an object declaration declares the object as const.

[dcl.type]p2: const can be combined with any type specifier except itself.

I could see how GCC could interpret that as meaning "constexpr replaces const", but I think Clang is doing the right thing by allowing both specifiers. The constexpr's "declaring the object as const" is a semantic property, not an implicit inclusion of the const /specifier/.

I'm still not a standardista, though, so someone might have another view (or another citation I missed).
Jordan

#3

Yes, I came to the same conclusion. [dcl.type]p2 is talking only about the type-specifiers which appear in the decl-specifier-seq. [dcl.constexpr]p9 is clearly not saying we should act as if ‘const’ appeared in the decl-specifier-seq, since in this case, the constexpr implies a const on p, not on *p:

constexpr const char *p = 0;

The relevant rule seems to be [dcl.type.cv]p1: “Redundant cv-qualifications are ignored.”

Hence I believe this is a GCC bug.

#4

Richard Smith wrote:

On Mon, Jul 23, 2012 at 8:39 AM, Jordan Rose

I'm still not a standardista, though, so someone might have another view
(or another citation I missed).

Yes, I came to the same conclusion.

Hence I believe this is a GCC bug.

Thanks!

Submitted this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54086