This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Is this a compiler bug?
- From: Andrew Pinski <pinskia at gmail dot com>
- To: Ed Smith-Rowland <3dw4rd at verizon dot net>
- Cc: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>, GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: Sun, 21 Sep 2014 23:11:21 -0700
- Subject: Re: Is this a compiler bug?
- Authentication-results: sourceware.org; auth=none
- References: <20140922012346 dot GA4376 at troutmask dot apl dot washington dot edu> <CA+=Sn1nT8by8dUHugr_Ye8TYmSbGS6Axbbmau7d+-d7WCUVPfQ at mail dot gmail dot com> <20140922015627 dot GA4508 at troutmask dot apl dot washington dot edu> <541F8E51 dot 7080602 at verizon dot net>
On Sun, Sep 21, 2014 at 7:49 PM, Ed Smith-Rowland <3dw4rd@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
>