[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] [BUG] tcc and INT64: wrong result of comparison (a te
From: |
Sergey Korshunoff |
Subject: |
Re: [Tinycc-devel] [BUG] tcc and INT64: wrong result of comparison (a test included) |
Date: |
Mon, 5 Jan 2015 02:03:12 +0300 |
There is another approach: assume the constant is negative by default.
This is the method used in nimrod to scan a constants:
lib/pure/parseutils.nim(rawparse)
proc rawParseInt(s: string, b: var BiggestInt, start: int = 0): int =
var
sign: BiggestInt = -1 # minus by defaul
i = start
if s[i] == '+': inc(i)
elif s[i] == '-':
inc(i)
sign = 1
if s[i] in {'0'..'9'}:
b = 0
while s[i] in {'0'..'9'}:
b = b * 10 - (ord(s[i]) - ord('0')) #! the point
inc(i)
while s[i] == '_': inc(i) # underscores are allowed and ignored
b = b * sign
result = i - start
Sun, 04 Jan 2015 16:51 +0000, Thomas Preud'homme <address@hidden>:
> Le dimanche 4 janvier 2015, 19:18:34 Sergey Korshunoff a écrit :
>> By replacing a -2147483648 with a -2147483647 I can succesfully build
>> a working nim compiler. But this is not so good...
>
> The bug is in tccpp.c parse_number. The function tries to guess what should
> be
> the size and sign of the litteral before parsing the suffix (which might not
>
> exist).
>
> /* XXX: not exactly ANSI compliant */
> if ((n & 0xffffffff00000000LL) != 0) {
> if ((n >> 63) != 0)
> tok = TOK_CULLONG;
> else
> tok = TOK_CLLONG;
> } else if (n > 0x7fffffff) {
> tok = TOK_CUINT;
> } else {
> tok = TOK_CINT;
> }
>
> In your case it will pass in the first else if and set tok to TOK_CUINT. So
> far
> so good.
>
> Then it will parse the suffix and when it sees the second L it does this:
>
> if (tok == TOK_CINT)
> tok = TOK_CLLONG;
> else if (tok == TOK_CUINT)
> tok = TOK_CULLONG;
>
> So here it will set the value to TOK_CULLONG while it should set it to
> TOK_CLLONG and warn if the value is too big.
>
> My feeling is that the automatic guess for the size and sign should be done
>
> after trying to look for a suffix.
>
> The algorithm would be something like:
>
> 1) Set tok to TOK_CINT and suffix_found to false.
> 2) Then look for a L or U suffix with unchanged code except for setting a
> suffix_found variable if any such suffix is found.
> 3) Then if suffix_found is false try automatic detection, otherwise warn of
>
> overflow and possibly process the overflow (what does GCC does in this
> case?) Be
> careful about the sign when checking for overflow.
>
> Do you want to take a stab at it?
>
> Best regards,
>
> Thomas
>