This is the mail archive of the
mailing list for the libstdc++ project.
PR libstdc++/49813 revisited: constexpr on <cmath> functions (and builtins)
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: libstdc++ at gcc dot gnu dot org
- Cc: jason at redhat dot com, paolo dot carlini at oracle dot com
- Date: Tue, 2 Sep 2014 10:59:21 +0100
- Subject: PR libstdc++/49813 revisited: constexpr on <cmath> functions (and builtins)
- Authentication-results: sourceware.org; auth=none
Rev 176847 (aka e9fea850 in Git) added _GLIBCXX_CONSTEXPR to the
declarations in include/c_global/cmath but that is expressly forbidden
by 220.127.116.11 [constexpr.functions] (as modified by LWG 2013
In the PR trail Paolo argues that we don't want different behaviour
for -std=c++11 and -std=gnu++11, so I believe in that case we must
*never* declare those functions as constexpr.
However, Marc has previously suggested that we can, and should, add
constexpr to more functions in -std=gnu++11 mode, since that is
already not strictly conforming. That is consistent with Jason's view
in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813#c19 i.e.
"G++ treating built-ins as constexpr is an extension, which should be
disabled in strict conformance mode."
However, rather than doing that as described in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813#c43 Jason changed
the FE so all builtins (including std functions that get handled by
builtins) are treated as constexpr, because the original proposed
resolution of LWG 2013 was going to allow us to add constexpr, but
that was reversed for the final resolution.
I believe we should re-open the bug in light of the actual resolution
of LWG 2013 (adding constexpr is forbidden).
The FE should not treat builtins as constexpr in strict-conformance
We should either remove _GLIBCXX_CONSTEXPR from <cmath> entirely or
make it conditional on __STRICT_ANSI__.