This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

PR libstdc++/49813 revisited: constexpr on <cmath> functions (and builtins)


Rev 176847 (aka e9fea850 in Git) added _GLIBCXX_CONSTEXPR to the
declarations in include/c_global/cmath but that is expressly forbidden
by 17.6.5.6  [constexpr.functions] (as modified by LWG 2013
http://cplusplus.github.io/LWG/lwg-defects.html#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
mode.

We should either remove _GLIBCXX_CONSTEXPR from <cmath> entirely or
make it conditional on __STRICT_ANSI__.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]