From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DB0173857C41; Mon, 1 Aug 2022 06:26:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DB0173857C41 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: Mon, 01 Aug 2022 06:26:41 +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: Mon, 01 Aug 2022 06:26:42 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106079 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:82ac4cd213867be939aedee15347e8fd3f200b6a commit r13-1913-g82ac4cd213867be939aedee15347e8fd3f200b6a 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}.=