This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch] [libstdc++] [constexpr] [no-longer-useful] use macros in place of 'constexpr' to allow for disabling constexpr until fully supported by compiler
- From: "Adam Butcher" <dev dot lists at jessamine dot co dot uk>
- To: "Gabriel Dos Reis" <gdr at integrable-solutions dot net>
- Cc: dev dot lists at jessamine dot co dot uk, "Jonathan Wakely" <jwakely dot gcc at gmail dot com>, "libstdc++" <libstdc++ at gcc dot gnu dot org>, "Marc Glisse" <marc dot glisse at inria dot fr>, "Paolo Carlini" <paolo dot carlini at oracle dot com>, gcc-patches at gcc dot gnu dot org, "Jason Merrill" <jason at redhat dot com>
- Date: Thu, 3 Mar 2011 09:15:08 -0000
- Subject: Re: [Patch] [libstdc++] [constexpr] [no-longer-useful] 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> <AANLkTimP6W8r6DmZ_DnpcJCKH_yKNKvw8aYkOWGF1r+z@mail.gmail.com> <alpine.DEB.2.02.1102171958290.2488@laptop-mg.saclay.inria.fr> <AANLkTin8hZGZgvX0mZDxtJAaievKKphUaeKxvnhoRTX_@mail.gmail.com> <alpine.DEB.2.02.1102172114060.3089@laptop-mg.saclay.inria.fr> <AANLkTi=0kcewhTHiHbYRHBpU73MexsL8d=EHzgD1P6WH@mail.gmail.com> <e51001e3246817f039293066639020a4.squirrel@webmail.plus.net> <AANLkTi=Ly2zgpcV93fr0qwW6iLmXjGyX1JLYxs_+4DUQ@mail.gmail.com>
- Reply-to: dev dot lists at jessamine dot co dot uk
On Thu, February 17, 2011 10:31 pm, Adam Butcher wrote:
> the consensus of this thread, which I agree with,
> seems to be that a library-based 'workaround' is ugly. It would be
> preferable to fix the compiler;
On Fri, February 18, 2011 12:56 am, Gabriel Dos Reis wrote:
> I certainly agree that we should resist the __GBLICXX_CONSTEXPR macro.
> The current semantics implemented by the compiler is not going to meet
> anybody's expectation by the time GCC is released. I don't see the
> point of introducing the macro.
>
Jason has fixed the compiler issues that motivated this workaround so
there is no need for it as of GCC trunk rev 170638. Great!
Adam