[Bug c++/50258] New: -std=gnu++0x should allow in-class initialization of static const floating types without constexpr

[Bug c++/50258] New: -std=gnu++0x should allow in-class initialization of static const floating types without constexpr

[jyasskin at gcc dot gnu.org]

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

             Bug #: 50258
           Summary: -std=gnu++0x should allow in-class initialization of
                    static const floating types without constexpr
    Classification: Unclassified
           Product: gcc
           Version: 4.6.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jyasskin@gcc.gnu.org


In c++98 mode, gcc accepts in-class initialization of static const floating
members as an extension. This extension have been removed in C++0x mode, even
when gnu extensions are specifically requested with -std=gnu++0x. It would be
nice to keep the extension, especially since the C++0x draft was only changed
to disallow it in the FDIS.


$ gcc-4.6 --version
gcc-4.6 (GCC) 4.6.1
$ cat test.cc
struct Foo {
  static const double d = 3.14;
};
const double Foo::d;
$ gcc-4.6 -c -Wall test.cc
$ gcc-4.6 -c -Wall -std=gnu++0x test.cc
test.cc:2:27: error: 'constexpr' needed for in-class initialization of static
data member 'd' of non-integral type
test.cc:4:19: error: 'const double Foo::d' is not a static member of 'struct
Foo'
test.cc:4:14: error: uninitialized const 'Foo::d' [-fpermissive]
$

[Bug c++/50258] [C++0x] -std=gnu++0x should allow in-class initialization of static const floating types without constexpr

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-09-01 11:51:36 UTC ---
That extension has been deprecated for years:
http://gcc.gnu.org/onlinedocs/gcc/Deprecated-Features.html

[Bug c++/50258] [C++0x] -std=gnu++0x should allow in-class initialization of static const floating types without constexpr

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-09-23 11:27:49 UTC ---
Jason, what are we going to do about this? For the record, something like the
below would pass the testsuite...

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

Index: cp/decl.c
===================================================================
--- cp/decl.c   (revision 179115)
+++ cp/decl.c   (working copy)
@@ -7716,8 +7716,9 @@ check_static_variable_definition (tree decl, tree
   else if (cxx_dialect >= cxx0x && !INTEGRAL_OR_ENUMERATION_TYPE_P (type))
     {
       if (literal_type_p (type))
-       error ("%<constexpr%> needed for in-class initialization of static "
-              "data member %q#D of non-integral type", decl);
+       pedwarn (input_location, OPT_pedantic,
+                "%<constexpr%> needed for in-class initialization of static "
+                "data member %q#D of non-integral type %qT", decl, type);
       else
        error ("in-class initialization of static data member %q#D of "
               "non-literal type", decl);

[Bug c++/50258] [C++0x] -std=gnu++0x should allow in-class initialization of static const floating types without constexpr

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-09-23 12:18:03 UTC ---
How about using a permerror instead?  Since it's deprecated, requiring users to
give -fpermissive if they want to use it in C++11 seems reasonable to me.

[Bug c++/50258] [C++0x] -std=gnu++0x should allow in-class initialization of static const floating types without constexpr

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-09-23 12:45:43 UTC ---
Of course would work for me.

[Bug c++/50258] [C++0x] -std=gnu++0x should allow in-class initialization of static const floating types without constexpr

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill <jason at gcc dot gnu.org> 2011-09-23 13:07:33 UTC ---
permerror sounds good to me.

[Bug c++/50258] [C++0x] -std=gnu++0x should allow in-class initialization of static const floating types without constexpr

[paolo.carlini at oracle dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2011-09-23
         AssignedTo|unassigned at gcc dot       |paolo.carlini at oracle dot
                   |gnu.org                     |com
     Ever Confirmed|0                           |1

--- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-09-23 13:13:28 UTC ---
Ok, let me test that + testcase.

[Bug c++/50258] [C++0x] -std=gnu++0x should allow in-class initialization of static const floating types without constexpr

[paolo at gcc dot gnu.org]

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

--- Comment #7 from paolo at gcc dot gnu.org <paolo at gcc dot gnu.org> 2011-09-23 16:20:00 UTC ---
Author: paolo
Date: Fri Sep 23 16:19:52 2011
New Revision: 179121

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179121
Log:
/cp
2011-09-23  Paolo Carlini  <paolo.carlini@oracle.com>

    PR c++/50258
    * decl.c (check_static_variable_definition): Allow in-class
    initialization of static data member of non-integral type in
    permissive mode.

/testsuite
2011-09-23  Paolo Carlini  <paolo.carlini@oracle.com>

    PR c++/50258
    * g++.dg/cpp0x/constexpr-static8.C: New.

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

[Bug c++/50258] [C++0x] -std=gnu++0x should allow in-class initialization of static const floating types without constexpr

[paolo.carlini at oracle dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.7.0

--- Comment #8 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-09-23 16:22:32 UTC ---
Done.

[Bug c++/50258] [C++0x] -std=gnu++0x should allow in-class initialization of static const floating types without constexpr

[bsys.com.ar at gmail dot com]

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

Carlos Becker <bsys.com.ar at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bsys.com.ar at gmail dot
                   |                            |com

--- Comment #9 from Carlos Becker <bsys.com.ar at gmail dot com> 2011-09-29 10:31:15 UTC ---
Hello, thanks for taking care of this 'bug'.
I am currently working with ITK (www.itk.org) which doesn't compile with
-std=c++0x in gcc 4.6.1 due to this error.

Even though the proposed patch seems to be a proper solution, to me it seems to
be that using -fpermissive just to come around this particular error is
allowing other non-confirming code to compile as well, which may not be desired
in many situations (for instance, assigning a const pointer to a non-const
pointer would not be regarded as an error).

In my case, I have modified the patch to throw a warning instead, but probably
the best solution would be to add a sort of -fno-constexpr-initialization-check
flag. I read that the previous GCC extension is deprecated now, but it is
important to take into account that then it would be hard to use c++11 with
older code, just because of details like this one.

Thank you.

[Bug c++/50258] [C++0x] -std=gnu++0x should allow in-class initialization of static const floating types without constexpr

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-09-29 11:49:09 UTC ---
(In reply to comment #9)
> Even though the proposed patch seems to be a proper solution, to me it seems to
> be that using -fpermissive just to come around this particular error is
> allowing other non-confirming code to compile as well, which may not be desired
> in many situations (for instance, assigning a const pointer to a non-const
> pointer would not be regarded as an error).

Yup. Some compilers allow every single backwards-compatibility feature to be
controlled by a separate option. The cost of developing, testing and
maintaining that is enormous.

> In my case, I have modified the patch to throw a warning instead, but probably
> the best solution would be to add a sort of -fno-constexpr-initialization-check
> flag. I read that the previous GCC extension is deprecated now, but it is
> important to take into account that then it would be hard to use c++11 with
> older code, just because of details like this one.

That older code wasn't valid in C++03 either, and relied on an extension which
was deprecated many years ago.  That sounds like exactly the sort of situation
-fpermissive is for.

Rather than changing the effect on this extension, I'd prefer if -fpermissive
was changed to reject some truly *ancient* features which haven't been
supported without -fpermissive by any version of G++ since 3.0

[Bug c++/50258] [C++0x] -std=gnu++0x should allow in-class initialization of static const floating types without constexpr

[bsys.com.ar at gmail dot com]

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

--- Comment #11 from Carlos Becker <bsys.com.ar at gmail dot com> 2011-09-29 19:27:39 UTC ---
Thanks for the quick reply. I understand the implications of having a compiler
flag for each deprecated feature, but that would be the best option from the
developer's point of view (and obviously not so much from the gcc developer
side).

In my case I guess that I will have to patch the headers of the libraries I am
using with something like const -> constexpr in the places where I get those
errors. -fpermissive is too broad for my taste.

Anyhow I will keep track on this particular 'bug'. Whatever choice is made, it
will be important in order to use c++11/0x with older code.