[Bug c/111689] Unexpected comparison result of signed long long literal with zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111689 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #10 from Andrew Pinski --- .
[Bug c/111689] Unexpected comparison result of signed long long literal with zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111689 gyumin changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|UNCONFIRMED --- Comment #9 from gyumin --- okay Thank you for your feedback.I'm striving to better understand the intricacies of C standard and appreciate all guidance provided.
[Bug c/111689] Unexpected comparison result of signed long long literal with zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111689 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #8 from Andrew Pinski --- This is not the right place to learn C (or C++) really.
[Bug c/111689] Unexpected comparison result of signed long long literal with zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111689 gyumin changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|UNCONFIRMED --- Comment #7 from gyumin --- Based on your explanation, it seems that hex literals with the LL suffix are treated in the same manner. Essentially, hex literals are always considered as positive values. If the value does not fit within the positive range of a signed long long, it is interpreted as an unsigned long long. For instance, the value 0x8F3700142F89C2A5, even though not being that large of a positive number in reality, is interpreted as an unsigned long long since it exceeds 9,223,372,036,854,775,807. This can be a bit confusing as the literal's value could actually be interpreted as a negative, yet according to the C standard, it is only considered as a positive. And if that positive value exceeds the signed long long range, it is treated as unsigned. Am I understanding this correctly?
[Bug c/111689] Unexpected comparison result of signed long long literal with zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111689 --- Comment #6 from Andrew Pinski --- That being said 0x8F3700142F89C2A5 is a positive # so it will be unsigned as it does not fit in a 64bit signed integer.
[Bug c/111689] Unexpected comparison result of signed long long literal with zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111689 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Andrew Pinski --- (In reply to gyumin from comment #4) > I'm trying to understand how the type of a hex constant is determined in C. > According to the C standard, when a hex constant has the LL suffix, it > should first check if the value fits within the range of a long long int > before checking if it fits within the range of an unsigned long long int. > > Given the constant 0x8F3700142F89C2A5LL, which corresponds to the value > -8,127,026,915,869,867,355, it seems that this value should fit within the > range of a signed long long int, which is from -9,223,372,036,854,775,808 to > 9,223,372,036,854,775,807. If that's the case, why do gcc, clang interpret > it as an unsigned long long int? > > Could you clarify this behavior? No, there is no negative literals. So when a value like 0x8F3700142F89C2A5 happens, it is see if it fits in (positive) signed long long and since it is greater than 9,223,372,036,854,775,807, it chooses unsigned long long.
[Bug c/111689] Unexpected comparison result of signed long long literal with zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111689 gyumin changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #4 from gyumin --- I'm trying to understand how the type of a hex constant is determined in C. According to the C standard, when a hex constant has the LL suffix, it should first check if the value fits within the range of a long long int before checking if it fits within the range of an unsigned long long int. Given the constant 0x8F3700142F89C2A5LL, which corresponds to the value -8,127,026,915,869,867,355, it seems that this value should fit within the range of a signed long long int, which is from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. If that's the case, why do gcc, clang interpret it as an unsigned long long int? Could you clarify this behavior?
[Bug c/111689] Unexpected comparison result of signed long long literal with zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111689 --- Comment #3 from Andrew Pinski --- Note C99 has the same table: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf C++11 has the same table too: https://timsong-cpp.github.io/cppwp/n3337/lex.icon
[Bug c/111689] Unexpected comparison result of signed long long literal with zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111689 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Because this is exactly what the C standard says it should be. See https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf 6.4.4.1/5 . For hex (and Octal) constants, if the value is not representable in `signed long long` (which it is not as it is too big) but representable as `unsigned long long` then unsigned long long is chosen for LL. For Decimals, it is just signed.
[Bug c/111689] Unexpected comparison result of signed long long literal with zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111689 Andrew Pinski changed: What|Removed |Added Component|translation |c --- Comment #1 from Andrew Pinski --- >Interestingly, the cl compiler correctly interprets ULL as unsigned and LL as >signed for the given literal. clang produces the same result as GCC here. MSVC does not though.
