[Bug translation/111689] New: Unexpected comparison result of signed long long literal with zero

[Bug translation/111689] New: Unexpected comparison result of signed long long literal with zero

[guminb at ajou dot ac.kr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111689

            Bug ID: 111689
           Summary: Unexpected comparison result of signed long long
                    literal with zero
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: translation
          Assignee: unassigned at gcc dot gnu.org
          Reporter: guminb at ajou dot ac.kr
  Target Milestone: ---

I've come across an unexpected behavior when performing a comparison between
the value `0` and the signed long long literal `0x8F3700142F89C2A5LL`.

#include<stdio.h>
#include<stdint.h>

int main (int argc, char* argv[])
{   
    long long zero = 0;
    printf("Comparison result of zero <= signed long long 0x8F3700142F89C2A5LL:
%d\n", (zero <= 0x8F3700142F89C2A5LL));
    return 0;
}

The binary representation of 0x8F3700142F89C2A5LL is:
1000111100110111000000000001010000101111100010011100001010100101

This corresponds to the decimal value -8127026915869867355, indicating that it
is unambiguously a negative number.

Considering that 0x8F3700142F89C2A5LL is meant to be interpreted as a signed
long long and represents a negative value, the expected result for (zero <=
0x8F3700142F89C2A5LL) should be 0. However, the actual result is 1 across
several compilers including gcc and clang.

Interestingly, the cl compiler correctly interprets ULL as unsigned and LL as
signed for the given literal.

It appears that the compiler is not treating the literal 0x8F3700142F89C2A5LL
as a signed long long as it should, which results in this discrepancy.

I'm seeking understanding or clarification regarding this behavior. Would it be
possible for this to be a compiler bug?

[Bug c/111689] Unexpected comparison result of signed long long literal with zero

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111689

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|translation                 |c

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>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.

[Bug c/111689] Unexpected comparison result of signed long long literal with zero

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111689

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111689

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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

[guminb at ajou dot ac.kr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111689

gyumin <guminb at ajou dot ac.kr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #4 from gyumin <guminb at ajou dot ac.kr> ---
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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111689

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111689

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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

[guminb at ajou dot ac.kr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111689

gyumin <guminb at ajou dot ac.kr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |---
             Status|RESOLVED                    |UNCONFIRMED

--- Comment #7 from gyumin <guminb at ajou dot ac.kr> ---
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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111689

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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

[guminb at ajou dot ac.kr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111689

gyumin <guminb at ajou dot ac.kr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |---
             Status|RESOLVED                    |UNCONFIRMED

--- Comment #9 from gyumin <guminb at ajou dot ac.kr> ---
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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111689

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.