[Bug c++/68288] botched floating-point UDL

rs2740 at gmail dot com gcc-bugzilla@gcc.gnu.org
Thu Nov 12 09:50:00 GMT 2015


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68288

TC <rs2740 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rs2740 at gmail dot com

--- Comment #1 from TC <rs2740 at gmail dot com> ---
This behavior looks correct to me. (Clang behaves identically.)

0e1_e+0 is a valid pp-number, so per max munch it must be parsed that way, as a
single preprocessing token; it then fails to convert to a valid literal token.

0e1_a+0 isn't a valid pp-number (the only thing in the pp-number production
that can precede + in C++ is e/E), so it's parsed as three tokens, 0e1_a, +,
and 0. Ditto for 0e1_e*0.

However, GCC is treating 0e1_p+0 as a single pp-number, and rejecting

long double operator""_p(long double) { return {}; }
auto x = 0e1_p+0;

which isn't correct in C++.


More information about the Gcc-bugs mailing list