gcc-5-20140921 is now available
Snapshot gcc-5-20140921 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20140921/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 215438 You'll find: gcc-5-20140921.tar.bz2 Complete GCC MD5=d28fac769a32250938245a511ad34624 SHA1=9047ecc01d7e05ec4d75e82bb64e2c53537578b3 Diffs from 5-20140914 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Is this a compiler bug?
#include
#include
int
main(void)
{
uint16_t i;
i = 0x3ff0+63; printf("%x\n", i);
i = 0x3ff1+63; printf("%x\n", i);
i = 0x3ff2+63; printf("%x\n", i);
i = 0x3ff3+63; printf("%x\n", i);
i = 0x3ff4+63; printf("%x\n", i);
i = 0x3ff4+63; printf("%x\n", i);
i = 0x3ff6+63; printf("%x\n", i);
i = 0x3ff7+63; printf("%x\n", i);
i = 0x3ff8+63; printf("%x\n", i);
i = 0x3ff9+63; printf("%x\n", i);
i = 0x3ffa+63; printf("%x\n", i);
i = 0x3ffb+63; printf("%x\n", i);
i = 0x3ffc+63; printf("%x\n", i);
i = 0x3ffd+63; printf("%x\n", i);
i = 0x3ffe+63; printf("%x\n", i);
i = 0x3fff+63; printf("%x\n", i);
return 0;
}
--
Steve
Re: Is this a compiler bug?
On Sun, Sep 21, 2014 at 6:23 PM, Steve Kargl
wrote:
No e+ is exponent marker.
Thanks,
Andrew
> #include
> #include
>
> int
> main(void)
> {
> uint16_t i;
> i = 0x3ff0+63; printf("%x\n", i);
> i = 0x3ff1+63; printf("%x\n", i);
> i = 0x3ff2+63; printf("%x\n", i);
> i = 0x3ff3+63; printf("%x\n", i);
> i = 0x3ff4+63; printf("%x\n", i);
> i = 0x3ff4+63; printf("%x\n", i);
> i = 0x3ff6+63; printf("%x\n", i);
> i = 0x3ff7+63; printf("%x\n", i);
> i = 0x3ff8+63; printf("%x\n", i);
> i = 0x3ff9+63; printf("%x\n", i);
> i = 0x3ffa+63; printf("%x\n", i);
> i = 0x3ffb+63; printf("%x\n", i);
> i = 0x3ffc+63; printf("%x\n", i);
> i = 0x3ffd+63; printf("%x\n", i);
> i = 0x3ffe+63; printf("%x\n", i);
> i = 0x3fff+63; printf("%x\n", i);
> return 0;
> }
>
> --
> Steve
Re: Is this a compiler bug?
+ 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.
--
steve
On Sun, Sep 21, 2014 at 06:49:54PM -0700, Andrew Pinski wrote:
> On Sun, Sep 21, 2014 at 6:23 PM, Steve Kargl
> wrote:
>
> No e+ is exponent marker.
>
>
> > #include
> > #include
> >
> > int
> > main(void)
> > {
> > uint16_t i;
> > i = 0x3ff0+63; printf("%x\n", i);
> > i = 0x3ff1+63; printf("%x\n", i);
> > i = 0x3ff2+63; printf("%x\n", i);
> > i = 0x3ff3+63; printf("%x\n", i);
> > i = 0x3ff4+63; printf("%x\n", i);
> > i = 0x3ff4+63; printf("%x\n", i);
> > i = 0x3ff6+63; printf("%x\n", i);
> > i = 0x3ff7+63; printf("%x\n", i);
> > i = 0x3ff8+63; printf("%x\n", i);
> > i = 0x3ff9+63; printf("%x\n", i);
> > i = 0x3ffa+63; printf("%x\n", i);
> > i = 0x3ffb+63; printf("%x\n", i);
> > i = 0x3ffc+63; printf("%x\n", i);
> > i = 0x3ffd+63; printf("%x\n", i);
> > i = 0x3ffe+63; printf("%x\n", i);
> > i = 0x3fff+63; printf("%x\n", i);
> > return 0;
> > }
> >
> > --
> > Steve
--
Steve
Re: Is this a compiler bug?
On 09/21/2014 09:56 PM, Steve Kargl 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. Also, a hex floating point uses p as an exponent for this reason... These should just be adding integers. i = 0x3ffe+63; /* integral */ i = 0x3ffp+63; /* floating point */ Post the PR. I did a lot of stuff in this area for C++11 user-defined literals. I either caused it of I might be able to help. Ed
Re: Is this a compiler bug?
On Sun, Sep 21, 2014 at 6:56 PM, Steve Kargl
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.
Also see 6.4/4-5:
If the input stream has been parsed into preprocessing tokens up to a
given character, the
next preprocessing token is the longest sequence of characters that
could constitute a
preprocessing token. There is one exception to this rule: header name
preprocessing
tokens are recognized only within #include preprocessing directives and in
implementation-defined locations within #pragma directives. In such contexts, a
sequence of characters that could be either a header name or a string
literal is recognized
as the former.
5 EXAMPLE 1 The program fragment 1Ex is parsed as a preprocessing
number token (one that is not a
valid floating or integer constant token), even though a parse as the
pair of preprocessing tokens 1 and Ex
might produce a valid expression (for example, if Ex were a macro
defined as +1). Similarly, the program
fragment 1E1 is parsed as a preprocessing number (one that is a valid
floating constant token), whether or
not E is a macro name.
Thanks,
Andrew Pinski
>
> --
> steve
>
> On Sun, Sep 21, 2014 at 06:49:54PM -0700, Andrew Pinski wrote:
>> On Sun, Sep 21, 2014 at 6:23 PM, Steve Kargl
>> wrote:
>>
>> No e+ is exponent marker.
>>
>>
>> > #include
>> > #include
>> >
>> > int
>> > main(void)
>> > {
>> > uint16_t i;
>> > i = 0x3ff0+63; printf("%x\n", i);
>> > i = 0x3ff1+63; printf("%x\n", i);
>> > i = 0x3ff2+63; printf("%x\n", i);
>> > i = 0x3ff3+63; printf("%x\n", i);
>> > i = 0x3ff4+63; printf("%x\n", i);
>> > i = 0x3ff4+63; printf("%x\n", i);
>> > i = 0x3ff6+63; printf("%x\n", i);
>> > i = 0x3ff7+63; printf("%x\n", i);
>> > i = 0x3ff8+63; printf("%x\n", i);
>> > i = 0x3ff9+63; printf("%x\n", i);
>> > i = 0x3ffa+63; printf("%x\n", i);
>> > i = 0x3ffb+63; printf("%x\n", i);
>> > i = 0x3ffc+63; printf("%x\n", i);
>> > i = 0x3ffd+63; printf("%x\n", i);
>> > i = 0x3ffe+63; printf("%x\n", i);
>> > i = 0x3fff+63; printf("%x\n", i);
>> > return 0;
>> > }
>> >
>> > --
>> > Steve
>
> --
> Steve
Re: Is this a compiler bug?
On Sun, Sep 21, 2014 at 10:49:53PM -0400, Ed Smith-Rowland wrote: > On 09/21/2014 09:56 PM, Steve Kargl 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. > > > Also, a hex floating point uses p as an exponent for this reason... > These should just be adding integers. > > i = 0x3ffe+63; /* integral */ > > i = 0x3ffp+63; /* floating point */ > > Post the PR. > I did a lot of stuff in this area for C++11 user-defined literals. > I either caused it of I might be able to help. > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=63324 -- Steve
Re: Is this a compiler bug?
On Sun, Sep 21, 2014 at 07:57:45PM -0700, Andrew Pinski wrote: > On Sun, Sep 21, 2014 at 6:56 PM, Steve Kargl > 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. -- Steve
Re: Is this a compiler bug?
On Sun, Sep 21, 2014 at 8:08 PM, Steve Kargl 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 >> 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. Thanks, Andrew Pinski > > -- > Steve
Re: Is this a compiler bug?
On Sun, Sep 21, 2014 at 7:49 PM, Ed Smith-Rowland <3dw...@verizon.net> wrote: > On 09/21/2014 09:56 PM, Steve Kargl 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. >> > Also, a hex floating point uses p as an exponent for this reason... > These should just be adding integers. > > i = 0x3ffe+63; /* integral */ > > i = 0x3ffp+63; /* floating point */ > > Post the PR. > I did a lot of stuff in this area for C++11 user-defined literals. > I either caused it of I might be able to help. 6.4.8 is what matters here. pp-number is defined as: pp-number e sign pp-number E sign pp-number identifier-nondigit And /3 says: Preprocessing number tokens lexically include all floating and integer constant tokens. And /4 says: A preprocessing number does not have type or a value; it acquires both after a successful conversion (as part of translation phase 7) to a floating constant token or an integer constant token. So we have 0x3ffe+63 as one token (a pp-number) but it is not a successive token to either a floating point token or an integer constant token so it is rejected. Thanks, Andrew Pinski > > Ed >
