[Bug c++/108934] New: bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12

[Bug c++/108934] New: bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12

[janpmoeller at gmx dot de]

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

            Bug ID: 108934
           Summary: bit_cast'ing to long double errors out with "the
                    argument cannot be interpreted" since gcc-12
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: janpmoeller at gmx dot de
  Target Milestone: ---

In gcc-trunk, gcc-12.2 and gcc-12.1, the following code fails to compile, while
gcc-11.3 accepts it:

/////////////////////////////////////////////////////////////////////////////////////////////////////////////
#include <array>
#include <bit>
#include <cstdint>

using uint64_x_2_t = std::array<std::uint64_t, 2>;
using uint32_x_2_t = std::array<std::uint32_t, 2>;
using uint16_x_2_t = std::array<std::uint16_t, 2>;

static_assert(sizeof(long double) == sizeof(uint64_x_2_t));
static_assert(sizeof(double) == sizeof(uint32_x_2_t));
static_assert(sizeof(float) == sizeof(uint16_x_2_t));

constexpr long double testld = 42.42;
constexpr double testd = 42.42;
constexpr float testf = 42.42f;

constexpr uint64_x_2_t test_uint64_x_2_t{1u, 2u};
constexpr uint32_x_2_t test_uint32_x_2_t{1u, 2u};
constexpr uint16_x_2_t test_uint16_x_2_t{1u, 2u};

constexpr auto ld_to_uint64_x_2_t = std::bit_cast<uint64_x_2_t>(testld); //
works! (reverse direction)
constexpr auto d_to_uint32_x_2_t = std::bit_cast<uint32_x_2_t>(testd);
constexpr auto f_to_uint16_x_2_t = std::bit_cast<uint16_x_2_t>(testf);

constexpr auto default_uint64_x_2_t_to_ld = std::bit_cast<long
double>(uint64_x_2_t{}); // works! (default initialized)
constexpr auto default_uint32_x_2_t_to_d =
std::bit_cast<double>(uint32_x_2_t{});
constexpr auto default_uint16_x_2_t_to_f =
std::bit_cast<float>(uint16_x_2_t{});

constexpr auto temp_uint64_x_2_t_to_ld = std::bit_cast<long
double>(uint64_x_2_t{1u, 2u}); // <= fails
constexpr auto temp_uint32_x_2_t_to_d = std::bit_cast<double>(uint32_x_2_t{1u,
2u});
constexpr auto temp_uint16_x_2_t_to_f = std::bit_cast<float>(uint16_x_2_t{1u,
2u});

constexpr auto uint64_x_2_t_to_ld = std::bit_cast<long
double>(test_uint64_x_2_t); // <= fails
constexpr auto uint32_x_2_t_to_d = std::bit_cast<double>(test_uint32_x_2_t);
constexpr auto uint16_x_2_t_to_f = std::bit_cast<float>(test_uint16_x_2_t);
/////////////////////////////////////////////////////////////////////////////////////////////////////////////

The compile error for both offending lines is:
/usr/include/c++/12/bit:87:33: sorry, unimplemented: ‘__builtin_bit_cast’
cannot be constant evaluated because the argument cannot be interpreted

The strange thing is that this error only seems to appear if the array is
aggregate-initialized; default initialized arrays do not trigger the error.
float and double do not trigger the error either. Replacing std::array with a
struct aggregate type behaves the same as the array example above.

The reverse direction, i.e. bit_cast'ing from long double to array, seems to be
working fine.

The above example on compiler explorer: https://godbolt.org/z/ba5d6hEG1

[Bug c++/108934] bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
r12-7240-g2801f23fb82a5e (aka PR 104522) is what changed the behavior but I am
not 100% sure the resulting code in GCC 11 was correct ...

[Bug c++/108934] bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note long double on x86_64 has padding bits which almost likely you are running
into here ...

[Bug c++/108934] bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
That is doing {0u, 0u} works too.
And even {1u, 0u}; does too.

[Bug c++/108934] bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Yes GCC 11.x produces wrong code too, remove constexpr from uint64_x_2_t_to_ld
and temp_uint64_x_2_t_to_ld to see that:
uint64_x_2_t_to_ld:
        .long   1
        .long   0
        .long   0
        .long   0
temp_uint64_x_2_t_to_ld:
        .long   1
        .long   0
        .long   0
        .long   0

[Bug c++/108934] bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If you are complaining about:
struct S { unsigned long long a[2]; };
struct T { unsigned long long b[6]; };
struct U { unsigned long long c[2]; long double d; unsigned long long e[2]; };

#if __SIZEOF_LONG_DOUBLE__ == 16 && __LDBL_MANT_DIG__ == 64 &&
__SIZEOF_LONG_LONG__ == 8
constexpr long double
foo (S x)
{
  return __builtin_bit_cast (long double, x);
}

constexpr S a = { 0ULL, 0xffffffffffff0000ULL };
constexpr long double b = foo (a);
static_assert (b == 0.0L, "");

constexpr U
bar (T x)
{
  return __builtin_bit_cast (U, x);
}

constexpr T c = { 0ULL, 0ULL, 0ULL, 0xffffffffffff0000ULL, 0ULL, 0ULL };
constexpr U d = bar (c);
static_assert (d.d == 0.0L, "");
#endif

which is an unintended side-effects of the PR104522 changes, then that can be
fixed e.g. with
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 9aaea71a2fc..99882ef820a 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -8873,11 +8873,13 @@ native_interpret_expr (tree type, const unsigned char
*ptr, int len)
             valid values that GCC can't really represent accurately.
             See PR95450.  Even for other modes, e.g. x86 XFmode can have some
             bit combinationations which GCC doesn't preserve.  */
-         unsigned char buf[24];
+         unsigned char buf[24 * 2];
          scalar_float_mode mode = SCALAR_FLOAT_TYPE_MODE (type);
          int total_bytes = GET_MODE_SIZE (mode);
+         memcpy (buf + 24, ptr, total_bytes);
+         clear_type_padding_in_mask (type, buf + 24);
          if (native_encode_expr (ret, buf, total_bytes, 0) != total_bytes
-             || memcmp (ptr, buf, total_bytes) != 0)
+             || memcmp (buf + 24, buf, total_bytes) != 0)
            return NULL_TREE;
          return ret;
        }

The intent of the PR104522 change was to verify that the interpreted floating
point value represents the in memory value correctly, but padding bits
shouldn't be considered in that, they can contain anything.  That said, for IBM
double double format or e.g. x86 
extended format there are still many values which can't be interpretted
correctly,
for the latter e.g. pseudo denormals, pseudo infinities, pseudo NaNs and
unnormal values.

[Bug c++/108934] [12/13 Regression] bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-03-01
            Summary|bit_cast'ing to long double |[12/13 Regression]
                   |errors out with "the        |bit_cast'ing to long double
                   |argument cannot be          |errors out with "the
                   |interpreted" since gcc-12   |argument cannot be
                   |                            |interpreted" since gcc-12
             Status|UNCONFIRMED                 |NEW

[Bug c++/108934] [12/13 Regression] bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
   Target Milestone|---                         |12.3

[Bug c++/108934] [12/13 Regression] bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 54566
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54566&action=edit
gcc13-pr108934.patch

Untested fix.

[Bug c++/108934] [12/13 Regression] bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:cc88366a80e35b3e53141f49d3071010ff3c2ef8

commit r13-6408-gcc88366a80e35b3e53141f49d3071010ff3c2ef8
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Mar 2 09:27:40 2023 +0100

    fold-const: Ignore padding bits in native_interpret_expr REAL_CST reverse
verification [PR108934]

    In the following testcase we try to std::bit_cast a (pair of) integral
    value(s) which has some non-zero bits in the place of x86 long double
    (for 64-bit 16 byte type with 10 bytes actually loaded/stored by hw,
    for 32-bit 12 byte) and starting with my PR104522 change we reject that
    as native_interpret_expr fails on it.  The PR104522 change extends what
    has been done before for MODE_COMPOSITE_P (but those don't have any padding
    bits) to all floating point types, because e.g. the exact x86 long double
    has various bit combinations we don't support, like
    pseudo-(denormals,infinities,NaNs) or unnormals.  The HW handles some of
    those as exceptional cases and others similarly to the non-pseudo ones.
    But for the padding bits it actually doesn't load/store those bits at all,
    it loads/stores 10 bytes.  So, I think we should exempt the padding bits
    from the reverse comparison (the native_encode_expr bits for the padding
    will be all zeros), which the following patch does.  For bit_cast it is
    similar to e.g. ignoring padding bits if the destination is a structure
    which has padding bits in there.

    The change changed auto-init-4.c to how it has been behaving before the
    PR105259 change, where some more VCEs can be now done.

    2023-03-02  Jakub Jelinek  <jakub@redhat.com>

            PR c++/108934
            * fold-const.cc (native_interpret_expr) <case REAL_CST>: Before
memcmp
            comparison copy the bytes from ptr to a temporary buffer and
clearing
            padding bits in there.

            * gcc.target/i386/auto-init-4.c: Revert PR105259 change.
            * g++.target/i386/pr108934.C: New test.

[Bug c++/108934] [12 Regression] bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[12/13 Regression]          |[12 Regression]
                   |bit_cast'ing to long double |bit_cast'ing to long double
                   |errors out with "the        |errors out with "the
                   |argument cannot be          |argument cannot be
                   |interpreted" since gcc-12   |interpreted" since gcc-12

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.

[Bug c++/108934] [12 Regression] bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:726682897d877afacb8164130cbbc715f8b44784

commit r12-9280-g726682897d877afacb8164130cbbc715f8b44784
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Mar 2 09:27:40 2023 +0100

    fold-const: Ignore padding bits in native_interpret_expr REAL_CST reverse
verification [PR108934]

    In the following testcase we try to std::bit_cast a (pair of) integral
    value(s) which has some non-zero bits in the place of x86 long double
    (for 64-bit 16 byte type with 10 bytes actually loaded/stored by hw,
    for 32-bit 12 byte) and starting with my PR104522 change we reject that
    as native_interpret_expr fails on it.  The PR104522 change extends what
    has been done before for MODE_COMPOSITE_P (but those don't have any padding
    bits) to all floating point types, because e.g. the exact x86 long double
    has various bit combinations we don't support, like
    pseudo-(denormals,infinities,NaNs) or unnormals.  The HW handles some of
    those as exceptional cases and others similarly to the non-pseudo ones.
    But for the padding bits it actually doesn't load/store those bits at all,
    it loads/stores 10 bytes.  So, I think we should exempt the padding bits
    from the reverse comparison (the native_encode_expr bits for the padding
    will be all zeros), which the following patch does.  For bit_cast it is
    similar to e.g. ignoring padding bits if the destination is a structure
    which has padding bits in there.

    The change changed auto-init-4.c to how it has been behaving before the
    PR105259 change, where some more VCEs can be now done.

    2023-03-02  Jakub Jelinek  <jakub@redhat.com>

            PR c++/108934
            * fold-const.cc (native_interpret_expr) <case REAL_CST>: Before
memcmp
            comparison copy the bytes from ptr to a temporary buffer and
clearing
            padding bits in there.

            * gcc.target/i386/auto-init-4.c: Revert PR105259 change.
            * g++.target/i386/pr108934.C: New test.

    (cherry picked from commit cc88366a80e35b3e53141f49d3071010ff3c2ef8)

[Bug c++/108934] [12 Regression] bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 12.3 too.