https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70529
--- Comment #2 from Axel Naumann <g...@axel-naumann.de> --- Hi Jakub, Thanks for your reply! Let me try to explain better then. This code auto a = 0x123p2; auto b = 0x123p-2; compiles just fine until the recent hexfloat change. Now, the second line will trigger an error message that does not mention C++1z or hexfloat support in general. The first line continues to compile. This is misleading. In my point of view, the fact that the diagnostic is justified by the tokenization behavior is not relevant for user-level diagnostics. Take an arbitrary user, upgrading from GCC 5.x to 6.0. They will see an error about a missing exponent - which is simply false (the code proves the diagnostic wrong) and doesn't tell the developer what needs to be fixed (let alone why). You asked for it, so here is my wish list: - for C++ < 1z, do not support hexfloats, neither with "unsigned" not negative exponents. Or support both, as a GCC extention that's enabled by default - like in the GCC 5 times. - if you remove support for C++ < 1z, state that hexfloats are unsupported in C++ < 1z. Cheers, Axel. NB: Even if I would buy into the argument that diagnostics are limited by the tokens, I don't yet see why 'P' ends up being concated to the pp-number token in C++ < 1z.
