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.
