https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96788
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96788
Pascal Cuoq changed:
What|Removed |Added
CC||pascal_cuoq at hotmail dot com
---
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
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
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
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.
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
