Message ID | 20220104142307.GF2646553@tucnak |
---|---|
State | New |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2918F3858437 for <patchwork@sourceware.org>; Tue, 4 Jan 2022 14:24:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2918F3858437 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1641306242; bh=kqGcV/0W1g6squoqT4WmxCDQkr6CudWL5ofvgl61Xo8=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=ecvZGOHRmR6YTBaGpIFN/LHlD0U2nfitdZYshH9IAbnXfHM3Uh3ghbsLXW2x//yWc eAHYiQs+TDxVpkPg8Uh8grqbcrIcpbxeGIyoSImIvs9MwhRWkqOpM81s549vFGVPKq jNxIyyw6ejg7nwJfuaqHtBYpAdH07sOPGQatO+DI= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 457713858416 for <gcc-patches@gcc.gnu.org>; Tue, 4 Jan 2022 14:23:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 457713858416 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-64-C4vT-UivOF-FnKd5xtvu-g-1; Tue, 04 Jan 2022 09:23:13 -0500 X-MC-Unique: C4vT-UivOF-FnKd5xtvu-g-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 12B16101F003; Tue, 4 Jan 2022 14:23:12 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.2.16.169]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A291876117; Tue, 4 Jan 2022 14:23:11 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 204EN8oH2907167 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 4 Jan 2022 15:23:08 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 204EN7bO2907166; Tue, 4 Jan 2022 15:23:07 +0100 Date: Tue, 4 Jan 2022 15:23:07 +0100 To: Thomas Koenig <tkoenig@netcologne.de>, Michael Meissner <meissner@linux.ibm.com>, Segher Boessenkool <segher@kernel.crashing.org>, "fortran@gcc.gnu.org" <fortran@gcc.gnu.org>, Peter Bergner <bergner@linux.ibm.com>, Bill Schmidt <wschmidt@linux.ibm.com>, gcc-patches@gcc.gnu.org, David Edelsohn <dje.gcc@gmail.com> Subject: [power-ieee128] fortran, libgfortran: Assorted -mabi=ieeelongdouble I/O fixes Message-ID: <20220104142307.GF2646553@tucnak> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_MANYTO, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=unavailable autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Jakub Jelinek via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Jakub Jelinek <jakub@redhat.com> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
[power-ieee128] fortran, libgfortran: Assorted -mabi=ieeelongdouble I/O fixes
|
|
Commit Message
Jakub Jelinek
Jan. 4, 2022, 2:23 p.m. UTC
Hi! Another patch, this fixes: FAIL: gfortran.dg/intrinsic_spread_2.f90 -O0 execution test FAIL: gfortran.dg/intrinsic_spread_2.f90 -O1 execution test FAIL: gfortran.dg/intrinsic_spread_2.f90 -O2 execution test FAIL: gfortran.dg/intrinsic_spread_2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/intrinsic_spread_2.f90 -O3 -g execution test FAIL: gfortran.dg/intrinsic_spread_2.f90 -Os execution test FAIL: gfortran.dg/intrinsic_unpack_2.f90 -O0 execution test FAIL: gfortran.dg/intrinsic_unpack_2.f90 -O1 execution test FAIL: gfortran.dg/intrinsic_unpack_2.f90 -O2 execution test FAIL: gfortran.dg/intrinsic_unpack_2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/intrinsic_unpack_2.f90 -O3 -g execution test FAIL: gfortran.dg/intrinsic_unpack_2.f90 -Os execution test FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O0 execution test FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O1 execution test FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O2 execution test FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O3 -g execution test FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -Os execution test FAIL: gfortran.dg/quad_2.f90 -O0 execution test FAIL: gfortran.dg/quad_2.f90 -O1 execution test FAIL: gfortran.dg/quad_2.f90 -O2 execution test FAIL: gfortran.dg/quad_2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/quad_2.f90 -O3 -g execution test FAIL: gfortran.dg/quad_2.f90 -Os execution test Ok for power-ieee128? 2022-01-04 Jakub Jelinek <jakub@redhat.com> gcc/fortran/ * trans-io.c (transfer_array_desc): Pass abi kind instead of kind to libgfortran. libgfortran/ * io/read.c (convert_real): Add missing break; for the HAVE_GFC_REAL_17 case. Jakub
Comments
On 04.01.22 15:23, Jakub Jelinek via Fortran wrote:
> Ok for power-ieee128?
Also OK.
Best regards
Thomas
Hi! This test FAILs because f951: Error: '-mabi=ieeelongdouble' requires full ISA 2.06 support compiler exited with status 1 FAIL: gfortran.dg/pr47614.f -O0 (test for excess errors) As powerpc64le* only supports -mcpu=power8 and newer, I think we shouldn't be testing with that option. Ok for power-ieee128? All the remaining FAILs I get are due to the -flto -mgnu-attribute issues or FAIL also with -mabi=ibmlongdouble. Though, I'm still unsure on what we should do with the array descriptors. typedef struct dtype_type { size_t elem_len; int version; signed char rank; signed char type; signed short attribute; } dtype_type; Is elem_len really element length, or kind, or both? It seems a lot of code uses that interchangeably, is there anything where we'd rely on whether it is the IBM extended real(kind=16) or IEEE quad real(kind=16) (either in libgfortran or elsewhere)? At least in libgfortran/generates/*, GFC_DESCRIPTOR_SIZE is mostly used as mask_kind (I think the mask arrays are always logical not real/complex, right?), or for logical stuff like matmul_l*. 2022-01-04 Jakub Jelinek <jakub@redhat.com> * gfortran.dg/pr47614.f: Don't use -mcpu=power4 for powerpc64le*-*-linux*. --- gcc/testsuite/gfortran.dg/pr47614.f.jj 2021-12-31 11:00:53.733041354 +0000 +++ gcc/testsuite/gfortran.dg/pr47614.f 2022-01-04 17:51:05.422663254 +0000 @@ -1,6 +1,7 @@ ! { dg-do run { target { powerpc*-*-* } } } ! { dg-skip-if "" { powerpc*-*-darwin* } } ! { dg-options "-O3 -funroll-loops -ffast-math -mcpu=power4" } +! { dg-options "-O3 -funroll-loops -ffast-math" { target powerpc64le*-*-linux* } } SUBROUTINE SFCPAR(ZET,NZ,ZMH,TSL,TMES) Jakub
Hi Jakub, > This test FAILs because > f951: Error: '-mabi=ieeelongdouble' requires full ISA 2.06 support > compiler exited with status 1 > FAIL: gfortran.dg/pr47614.f -O0 (test for excess errors) > As powerpc64le* only supports -mcpu=power8 and newer, I think we shouldn't > be testing with that option. > > Ok for power-ieee128? OK (I would also consider it obvious). > Though, I'm still unsure on what we should do with the array descriptors. > typedef struct dtype_type > { > size_t elem_len; > int version; > signed char rank; > signed char type; > signed short attribute; > } > dtype_type; > > Is elem_len really element length, or kind, or both? It is specified as a length, and should be set correctly also for complex (where it is twice the length). > It seems a lot of code uses that interchangeably, is there anything where > we'd rely on whether it is the IBM extended real(kind=16) or IEEE quad > real(kind=16) (either in libgfortran or elsewhere)? I think we use sizeof in all relevant files. > At least in libgfortran/generates/*, GFC_DESCRIPTOR_SIZE is mostly used > as mask_kind (I think the mask arrays are always logical not real/complex, > right?), or for logical stuff like matmul_l*. Yes, masks are always of type logical, so that should not be an issue. There are two direct uses of elem_len in caf/singe.c, one in date_and_time.c and one in io/transfer.c. There is also some use of a variable of that name ISO_Fortran_binding.c, which can be checked later. Best regards Thomas
--- gcc/fortran/trans-io.c.jj 2022-01-04 10:27:56.498322942 +0000 +++ gcc/fortran/trans-io.c 2022-01-04 13:51:50.336998696 +0000 @@ -2528,7 +2528,7 @@ transfer_array_desc (gfc_se * se, gfc_ty else charlen_arg = build_int_cst (gfc_charlen_type_node, 0); - kind_arg = build_int_cst (integer_type_node, ts->kind); + kind_arg = build_int_cst (integer_type_node, gfc_type_abi_kind (ts)); tmp = gfc_build_addr_expr (NULL_TREE, dt_parm); if (last_dt == READ) --- libgfortran/io/read.c.jj 2022-01-04 10:27:56.518323381 +0000 +++ libgfortran/io/read.c 2022-01-04 13:58:51.676285518 +0000 @@ -203,6 +203,7 @@ convert_real (st_parameter_dt *dtp, void # else *((GFC_REAL_17*) dest) = __qmath_(strtoflt128) (buffer, &endptr); # endif + break; #endif default: