This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [Patch] [libstdc++] [constexpr] use macros in place of 'constexpr' to allow for disabling constexpr until fully supported by compiler
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>
- Cc: dev dot lists at jessamine dot co dot uk, gcc-patches at gcc dot gnu dot org, "libstdc++" <libstdc++ at gcc dot gnu dot org>, Jason Merrill <jason at redhat dot com>
- Date: Thu, 17 Feb 2011 18:49:46 +0000
- Subject: Re: [Patch] [libstdc++] [constexpr] use macros in place of 'constexpr' to allow for disabling constexpr until fully supported by compiler
- References: <3f47a1ba92b11724c7daafd3f4c15e75.squirrel@webmail.plus.net> <4D5D48A9.7020001@oracle.com>
On 17 February 2011 16:11, Paolo Carlini wrote:
> On 02/17/2011 03:06 PM, Adam Butcher wrote:
>> Hi,
>>
>> The attached patch replaces occurrences of the plain word 'constexpr'
>> with either the symbol _GLIBCXX_CONSTEXPR or the symbol
>> _GLIBCXX_USE_CONSTEXPR, depending on whether the disabled replacement
>> should be '' or 'const' respectively.
>>
>> This allows for disabling constexpr usage by the standard library in
>> C++0x mode until issues such as
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47774 /
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46472 are resolved in the
>> compiler.
>>
>> Note I have only changed files required to build the project I'm
>> currently working on. ?Specifically std/limits and std/complex. ?There
>> may be other occurrences of the plain word 'constexpr' that are not
>> referenced by it.
>>
> Please always send library patches to the libstdc++ mailing list too
> (and of course, at some point you will need a Copyright Assignment on
> file...)
>
> Anyway, about the technical point: currently the macros are just an
> implementation detail, are *not* meant to be changed at will be the user
> (among other things, note that they appear in *.cc files too...).
> Anyway, if we are going to do what you are suggesting we have to do it
> consistently everywhere and document it.
>
> At the moment, I don't know *exactly* how serious are the front-end
> issues you mentioned above (in the specific sense: how much C++03 code
> using <limits>, <complex>, etc, which we care about, would break in
> C++0x mode only because of the bugs), or if in principle could be fixed
> in time for 4.6.0.
>
> Missing further clarifications, I vote against the library-only changes.
I don't much like the idea of patching the library and having to ship
those changes in 4.6.0 to workaround that bug (I think the two PRs are
the same issue.) Especially as neither of those PRs shows code which
is affected by using constexpr in the library (I'm sure such code
exists, but the testcases provided don't show a library-related
problem.)
Adam, if the constexpr additions to the library have broken code that
worked with GCC 4.5 please provide a small testcase showing the
problem (your self-executing script is clever and comprehensive but
not very easy to parse quickly to identify the issue!)
If you can show a valid program (possibly using <limits> or <complex>,
ideally one which is valid in C++03 and C++0x) which compiles using
-std=c++0x with GCC 4.5 but not with 4.6 then the bugs can be marked
as regressions, which means they're more likely to be fixed for 4.6
If you have code examples which don't explicitly use constexpr, but
break because libstdc++ code you make use of has been changed to use
constexpr, that's more likely to get given a higher priority by the
4.6 release managers.