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
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
