[Bug c/96788] "integer constant is so large that it is unsigned" warning is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96788 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=84764 --- Comment #7 from Jonathan Wakely --- Is this a dup of PR 84764?
[Bug c/96788] "integer constant is so large that it is unsigned" warning is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96788
Pascal Cuoq changed:
What|Removed |Added
CC||pascal_cuoq at hotmail dot com
--- Comment #6 from Pascal Cuoq ---
Joseph Myers wrote:
> The warnings are attempting to cover both the C90
> case where a decimal constant too large for signed long can be unsigned
> long, and the case of a constant too large for intmax_t.
In the case of the constant 1000, each of the two kind of
warnings, “ integer constant is so large that it is unsigned” and “this decimal
constant is unsigned only in ISO C90” can be misleading.
Consider the compilation unit:
int x;
void f(void) {
x = -1000 < 0;
}
1/ Misleading warning “this decimal constant is unsigned only in ISO C90”
Compiler Explorer link: https://gcc.godbolt.org/z/4Eze1f
Using GCC 10.2 targeting x86, the compilation options “-O -m32 -std=c89” make
GCC compile f as below, and emit the warning “this decimal constant is unsigned
only in ISO C90”
f:
movl$0, x
ret
Actually, changing the C dialect to C99 does not make the constant not
unsigned, since GCC emits the same assembly code for f (setting x to 0) with
“-O -m32 -std=c99”
2/ Misleading warning “integer constant is so large that it is unsigned”
Compiler Explorer link: https://gcc.godbolt.org/z/MGjn5G
Using GCC 10.2 targeting x86, the compilation options “-O -m64 -std=c99” make
GCC compile f as below, and emit the warning “integer constant is so large that
it is unsigned”.
f:
movl$1, x(%rip)
ret
The constant is not unsigned. If it were, the function f would not set x to 1.
[Bug c/96788] "integer constant is so large that it is unsigned" warning is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96788 --- Comment #5 from joseph at codesourcery dot com --- The way GCC actually behaves is that this constant is unsigned in the preprocessor but signed outside the preprocessor. I'm not sure that's exactly intent (though the preprocessor having only a single signed and unsigned type, with this constant not fitting in the signed type, means it couldn't be interpreted as signed in the preprocessor if allowed in #if expressions at all). The warnings are attempting to cover both the C90 case where a decimal constant too large for signed long can be unsigned long, and the case of a constant too large for intmax_t.
[Bug c/96788] "integer constant is so large that it is unsigned" warning is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96788 --- Comment #4 from Richard Smith --- (In reply to Richard Smith from comment #3) > such a literal "has no type" in C, which presumably results in undefined > behavior Ah, no, C11 6.4.4/2 makes this a constraint violation. But either way I think there's room for a vendor extension here.
[Bug c/96788] "integer constant is so large that it is unsigned" warning is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96788 --- Comment #3 from Richard Smith --- In the mean time, what is GCC's intent here? Clang is following the behavior described by GCC's diagnostic text, treating decimal integer literals that don't fit in 'long long' but do fit in 'unsigned long long' as the latter type (I've not checked back far enough to tell if this is what GCC ever actually did, or if we got this by looking at the diagnostics and didn't check the behavior). If that's not what GCC intends to do any more, that'd be useful for us to know, and we can switch to following GCC's actual behavior. (It'd also make sense to update the diagnostic text in that case!) It looks like both the Clang behavior (treat the literal as 'unsigned long long') and the GCC behavior (treat the literal as '__int128' where available and 'long long' otherwise) are conforming extensions in both C and C++, even though __int128 isn't (yet) an extended integer type: such a literal "has no type" in C, which presumably results in undefined behavior, and makes the program ill-formed in C++, so it seems there is room for a vendor extension in both languages.
[Bug c/96788] "integer constant is so large that it is unsigned" warning is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96788 --- Comment #2 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #1) > __int128 is NOT extended integer type: WG14 are supposed to be fixing that though.
[Bug c/96788] "integer constant is so large that it is unsigned" warning is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96788 --- Comment #1 from Andrew Pinski --- __int128 should not be used with respect to the type at all. __int128 is NOT extended integer type: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50441
