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.
