public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r12-8653] libfortran: Fix up boz_15.f90 on powerpc64le with -mabi=ieeelongdouble [PR106079] Date: Wed, 3 Aug 2022 09:22:25 +0000 (GMT) [thread overview] Message-ID: <20220803092225.6FC8C3858CDB@sourceware.org> (raw) 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) Diff: --- libgfortran/io/transfer.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c index f543dfd79dc..2760929a1e9 100644 --- a/libgfortran/io/transfer.c +++ b/libgfortran/io/transfer.c @@ -1614,6 +1614,10 @@ formatted_transfer_scalar_read (st_parameter_dt *dtp, bt type, void *p, int kind if (!(compile_options.allow_std & GFC_STD_F2008) && require_type (dtp, BT_INTEGER, type, f)) return; +#ifdef HAVE_GFC_REAL_17 + if (type == BT_REAL && kind == 17) + kind = 16; +#endif read_radix (dtp, f, p, kind, 2); break; @@ -1626,6 +1630,10 @@ formatted_transfer_scalar_read (st_parameter_dt *dtp, bt type, void *p, int kind if (!(compile_options.allow_std & GFC_STD_F2008) && require_type (dtp, BT_INTEGER, type, f)) return; +#ifdef HAVE_GFC_REAL_17 + if (type == BT_REAL && kind == 17) + kind = 16; +#endif read_radix (dtp, f, p, kind, 8); break; @@ -1638,6 +1646,10 @@ formatted_transfer_scalar_read (st_parameter_dt *dtp, bt type, void *p, int kind if (!(compile_options.allow_std & GFC_STD_F2008) && require_type (dtp, BT_INTEGER, type, f)) return; +#ifdef HAVE_GFC_REAL_17 + if (type == BT_REAL && kind == 17) + kind = 16; +#endif read_radix (dtp, f, p, kind, 16); break; @@ -2085,6 +2097,10 @@ formatted_transfer_scalar_write (st_parameter_dt *dtp, bt type, void *p, int kin if (!(compile_options.allow_std & GFC_STD_F2008) && require_type (dtp, BT_INTEGER, type, f)) return; +#ifdef HAVE_GFC_REAL_17 + if (type == BT_REAL && kind == 17) + kind = 16; +#endif write_b (dtp, f, p, kind); break; @@ -2097,6 +2113,10 @@ formatted_transfer_scalar_write (st_parameter_dt *dtp, bt type, void *p, int kin if (!(compile_options.allow_std & GFC_STD_F2008) && require_type (dtp, BT_INTEGER, type, f)) return; +#ifdef HAVE_GFC_REAL_17 + if (type == BT_REAL && kind == 17) + kind = 16; +#endif write_o (dtp, f, p, kind); break; @@ -2109,6 +2129,10 @@ formatted_transfer_scalar_write (st_parameter_dt *dtp, bt type, void *p, int kin if (!(compile_options.allow_std & GFC_STD_F2008) && require_type (dtp, BT_INTEGER, type, f)) return; +#ifdef HAVE_GFC_REAL_17 + if (type == BT_REAL && kind == 17) + kind = 16; +#endif write_z (dtp, f, p, kind); break;
reply other threads:[~2022-08-03 9:22 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20220803092225.6FC8C3858CDB@sourceware.org \ --to=jakub@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).