From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BC01C38582A4; Wed, 3 Aug 2022 09:22:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BC01C38582A4 From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libfortran/106079] [12/13 regression] gfortran.dg/boz_15.f90 fails after r12-6498-g07c60b8e33 Date: Wed, 03 Aug 2022 09:22:26 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libfortran X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.2 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2022 09:22:26 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106079 --- Comment #9 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4e5ca7ff8c9afd3c38245aa6b939cd3ae49bf1fe commit r12-8653-g4e5ca7ff8c9afd3c38245aa6b939cd3ae49bf1fe Author: Jakub Jelinek Date: Mon Aug 1 08:26:03 2022 +0200 libfortran: Fix up boz_15.f90 on powerpc64le with -mabi=3Dieeelongdouble [PR106079] The boz_15.f90 test FAILs on powerpc64le-linux when -mabi=3Dieeelongdou= ble is used (either default through --with-long-double-format=3Dieee 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=3D16) rather than the IBM double double real(kind=3D16). For the floating point input/output we then handle ki= nd 17 specially, but for B/O/Z we just treat the bytes of the floating poi= nt 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} cal= ls. 2022-08-01 Jakub Jelinek 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)=