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

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Andrew Pinski  ---
GCC, ICC, and clang all reject this.
MSVC accepts this.

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

[solodon at mail dot com via Gcc-bugs]

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

--- Comment #4 from Yuriy Solodkyy  ---
P.S. I added my previous example to this bug as they seemed to be related, feel
free to split it into a separate bug if they are not.

P.P.S. Change that return expression to 42_sp-p and the parser seems to think
the entire _sp-p is a UDL suffix:

:9:12: error: unable to find numeric literal operator 'operator""_sp-p'

9 | return 42_sp-p;
  |^~~

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

[solodon at mail dot com via Gcc-bugs]

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

Yuriy Solodkyy  changed:

   What|Removed |Added

 CC||solodon at mail dot com

--- Comment #3 from Yuriy Solodkyy  ---
This seems to be a genuine bug in GCC, not specific to floating-point UDL. It
is still present in GCC 10.2. ICC barks on it as well, but Clang and MSVC
accepts. 

Consider:

struct s_points { unsigned long long value; };
inline s_points operator"" _sp(unsigned long long v) { return {v}; }

s_points operator+(s_points, s_points);
s_points operator-(s_points, s_points);

s_points foo(s_points p)
{
return p-42_sp+1_sp; // Put space before + here and GCC will accept the
code
}

I get the following error on return statement line above:

:9:14: error: unable to find numeric literal operator
'operator""_sp+1_sp'

9 | return p-42_sp+1_sp;
  |  ^~

Since ud-suffix is just an identifier in the grammar, it should not grab +
while parsing, which according to error is what it seems to be doing.

Here is this snippet on Compiler Explorer: https://godbolt.org/z/4bfs6P

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

[lucdanton at free dot fr]

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

--- Comment #2 from lucdanton at free dot fr ---
(In reply to TC from comment #1)
> 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++.

I should clarify that I can't tell which way it's meant to be parsed. This PR
is either a bug report, or a feature enhancement request because that
diagnostic looks less-than-helpful to me. Hopefully we'll soon know which it
is.

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

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
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++.