On Mon, 2014-09-22 at 16:32 +0200, Jakub Jelinek wrote: > On Mon, Sep 22, 2014 at 10:22:59AM -0400, David Malcolm wrote: > > On Sun, 2014-09-21 at 22:15 -0700, Andrew Pinski wrote: > > > On Sun, Sep 21, 2014 at 8:08 PM, Steve Kargl > > > <s...@troutmask.apl.washington.edu> wrote: > > > > On Sun, Sep 21, 2014 at 07:57:45PM -0700, Andrew Pinski wrote: > > > >> On Sun, Sep 21, 2014 at 6:56 PM, Steve Kargl > > > >> <s...@troutmask.apl.washington.edu> wrote: > > > >> > + is a binary operator. 0x3ffe is a hexidecimal-constant according > > > >> > to 6.6.4.1 in n1256.pdf. 63 is, of course, a decimal-constant. > > > >> > > > >> > > > >> This is before tokens happen and during lexing of the program. > > > >> e+64 is exponent-part see 6.4.4.2. > > > > > > > > 6.4.4.2 applies to floating point constant. > > > > 6.4.4.1 is for integer constants. > > > > > > Nope again, this time from bug 3885: > > > Strange as it may seem, the behavior is correct, and mandated by the C > > > Standard. 0x00E-0x00A is a single preprocessor token, of type > > > pp-number, and it must become a single compiler token, but it can't. > > > The gotcha is the `E-' sequence, that makes it seem like the exponent > > > notation of floating-point constants. > > > > > > Looks like this is a common misunderstood part of C. > > > > If people tend to get this wrong, should we issue a warning for it? > > We already diagnose it, with an error actually, not warning: > error: invalid suffix "+63" on integer constant > etc. > Just apparently people are surprised when the compiler diagnoses it. > So perhaps some extra note explaining it (== hint how to fix that).
I've filed PR63337 with some ideas on how the error message could be improved for this case.
