[Bug c++/70529] Unhelpful diagnostic for hex float literals, inconsistent parsing

["joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Tue, 5 Apr 2016, manu at gcc dot gnu.org wrote:

> According to the manual, if an extension is not incompatible with the base
> standard, it should not be disabled:

In general, this extension *is* incompatible with the base standard - 
there are cases where a program is valid with both versions of pp-numbers, 
but with different semantics.  See gcc.dg/c90-hexfloat-2.c, for example.

That case involves pp-numbers such as 0x1p+f that aren't valid to convert 
to tokens.  But you could produce other examples involving concatenation 
that are valid without hex floats but not with them, e.g.:

#define a0x123p b
#define concat(x, y) x##y
concat(a, 0x123p-2)

which is valid without hex floats (expanding to b-2), but invalid with 
them because of an invalid concatenation.  So any extended pp-number 
syntax that include valid hex floats also introduces errors on valid code.

It should be possible to lex according to the selected standard, but track 
that a pp-token could be a hex float together with the following two 
pp-tokens (+ or - and the exponent with possible suffix) and then handle 
things specially if that sequence of pp-tokens ends up getting converted 
to tokens.