[Bug libfortran/106079] [12/13 regression] gfortran.dg/boz_15.f90 fails after r12-6498-g07c60b8e33

[cvs-commit at gcc dot gnu.org]

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

--- 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:4e5ca7ff8c9afd3c38245aa6b939cd3ae49bf1fe

commit r12-8653-g4e5ca7ff8c9afd3c38245aa6b939cd3ae49bf1fe
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon Aug 1 08:26:03 2022 +0200

    libfortran: Fix up boz_15.f90 on powerpc64le with -mabi=ieeelongdouble
[PR106079]

    The boz_15.f90 test FAILs on powerpc64le-linux when -mabi=ieeelongdouble
    is used (either default through --with-long-double-format=ieee or
    when used explicitly).
    The problem is that the read/write transfer routines are called with
    BT_REAL (or BT_COMPLEX) type and kind 17 which is magic we use to say
    it is the IEEE quad real(kind=16) rather than the IBM double double
    real(kind=16).  For the floating point input/output we then handle kind
    17 specially, but for B/O/Z we just treat the bytes of the floating point
    value as binary blob and using 17 in that case results in unexpected
    behavior, for write it means we don't estimate right how many chars we'll
    need and print ******************** etc. rather than what we should, and
    even with explicit size we'd print one further byte than intended.
    For read it would even mean overwriting some unrelated byte after the
    floating point object.

    Fixed by using 16 instead of 17 in the read_radix and write_{b,o,z} calls.

    2022-08-01  Jakub Jelinek  <jakub@redhat.com>

            PR libfortran/106079
            * io/transfer.c (formatted_transfer_scalar_read,
            formatted_transfer_scalar_write): For type BT_REAL with kind 17
            change kind to 16 before calling read_radix or write_{b,o,z}.

    (cherry picked from commit 82ac4cd213867be939aedee15347e8fd3f200b6a)