From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id CB9E0384B13A; Fri, 3 Sep 2021 17:18:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CB9E0384B13A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: 7XS+/ynXq+C12bdDVk4uwUyVZpsfBMXY+EzWkuUIaPHCXdMI6EWmQnyHTc3t2SQl/EjpUWkJm9 KoBdwbnEkT+rTzs+OE9Qp54t1zNHB6hQO8inG7kv1xhX+gyO33VXMRMLpn39qSW3CGvnY79vn8 5EccuAPDRwLClLLJboMb/2PZhhwB7sRLXGIVynj6LbNL5iML8xCApXIOJLrbWsuzIlzSIuWidZ gjZ22oe5CR+RtwNuNOLmbwEdTLfteSeDYh/GNoiGhCEE5Ez8ZQiSRgPbK9I4EY2bINvs9Du3yt 15hnHdEnZXKNo3zr4kzcLBwz X-IronPort-AV: E=Sophos;i="5.85,265,1624348800"; d="scan'208";a="67965949" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 03 Sep 2021 09:18:39 -0800 IronPort-SDR: GBr743ReIzrb2lwZlAmDljmoOazSfk7KM0RsO5lAQPGPdX12E2KckCu4k9/OEMw1oZBw56nbMq IfpKj83QtBYpHNJlqYeaKqDsSscdhwKuXaPfFvogPFR6Jftvqqq4xa+4/dtEGdEpla2OsW9dft Q0qjMzFHgBPuhLYjUsNdz6ZiKzkoF3gouWtsvGAN4+dGfuSjYRKcSfhMvlbJxBVgG+DbByd3h1 YhPYwKFG4uMiokm5yO4XmXmjdb9fMsKoqO7P3rGvb7vMuFckKPSve2JFDM6u/6jOwALxrmMFPg BH4= Subject: Re: [PATCH v3, Fortran] TS 29113 testsuite To: Tobias Burnus , Christophe Lyon CC: "gcc-patches@gcc.gnu.org" , "fortran@gcc.gnu.org" , Thomas Koenig , =?UTF-8?Q?Jos=c3=a9_Rui_Faustino_de_Sousa?= References: <64135fb4-c218-4026-6166-5018f11ebfe0@codesourcery.com> <84cbe3c1-b9db-a4ae-649f-c426448f8bcc@codesourcery.com> <47e5cae8-1d71-4017-0978-96670a773ad0@codesourcery.com> <83695368-5a76-054c-f0ad-fb5c7f1af9d2@codesourcery.com> From: Sandra Loosemore Message-ID: <4cc4a2dd-55bc-961f-a131-0dd1a9360fa7@codesourcery.com> Date: Fri, 3 Sep 2021 11:18:32 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <83695368-5a76-054c-f0ad-fb5c7f1af9d2@codesourcery.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) To svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2021 17:18:41 -0000 On 9/3/21 3:14 AM, Tobias Burnus wrote: > If I read https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html > correctly, we should use _Float128 for the following errors > > "The _Float128 type is supported on all systems where __float128 is > supported or where long double has the IEEE binary128 format." > > Applies to: > >> For >> typecodes-array-float128.f90 >> FAIL: gfortran.dg/c-interop/typecodes-array-float128.f90   -O0  (test >> for excess errors) >> Excess errors: >> /gcc/testsuite/gfortran.dg/c-interop/typecodes-array-float128-c.c:35:32: >> error: '__float128' undeclared (first use in this function); did you >> mean '_Float128'? >> typecodes-sanity.f90 >> FAIL: gfortran.dg/c-interop/typecodes-sanity.f90   -O0  (test for >> excess errors) >> Excess errors: >> /gcc/testsuite/gfortran.dg/c-interop/typecodes-sanity-c.c:41:13: >> error: '__float128' undeclared here (not in a function); did you mean >> '_Float128'? >> typecodes-scalar-float128.f90 >> FAIL: gfortran.dg/c-interop/typecodes-scalar-float128.f90   -O0  (test >> for excess errors) >> Excess errors: >> /gcc/testsuite/gfortran.dg/c-interop/typecodes-scalar-float128-c.c:34:32: >> error: '__float128' undeclared (first use in this function); did you >> mean '_Float128'? Just so I'm clear on this, the situation with ARM/AArch64 is that it provides _Float128 but not __float128? The GNU Fortran manual explicitly defines C_FLOAT128 as corresponding to __float128, not _Float128 or some other 128-bit floating-point type. https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gfortran/ISO_005fC_005fBINDING.html#ISO_005fC_005fBINDING So the situation with ARM/AArch64 is that it provides _Float128 but not __float128? I guess we could change the documentation and all the references in the implementation as well as the test cases to tie this kind to _Float128 instead. I think that is backward-compatible with all existing uses? > * * * >> PR100914.f90 >> FAIL: gfortran.dg/PR100914.f90   -O0  (test for excess errors) >> Excess errors: >> /gcc/testsuite/gfortran.dg/PR100914.c:8:10: fatal error: quadmath.h: >> No such file or directory Does ARM/Aarch64 provide _Float128 support without also providing libquadmath.h? I'm trying to understand why it got that particular error. :-S > >  * * * > > On a normal x86-64 system, I get XPASS for: > > gfortran.dg/PR100914.f90 > > gfortran.dg/c-interop/typecodes-array-float128.f90 > > The ! { dg-do run { xfail { { x86_64*-*-* i?86*-*-* } && longdouble128 } > } } > does not help as it just checks whether 'sizeof(long double)==16', > which seemingly passes also on x86-64 with 80bit long double. I don't understand this, either. I've been testing on an i686-pc-linux-gnu build with both -m32 and -m64. The tests PASS on -m32 and XFAIL on -m64. The XFAIL is there because with -m64, sizeof (long double) == 16 and it can't be disambiguated from the true 128-bit floating point type __float128 which also has size 16, and the other patch I committed makes it choose the standard type over the GNU extension type. With -m32, the 80-bit long double type has size 12 instead so there is no conflict. -Sandra