From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by sourceware.org (Postfix) with ESMTPS id 233FB3857BAD; Thu, 23 Jun 2022 20:50:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 233FB3857BAD X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.29] ([79.251.4.179]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MDhlV-1nvRcA1rcd-00AmmQ; Thu, 23 Jun 2022 22:49:57 +0200 Message-ID: Date: Thu, 23 Jun 2022 22:49:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH] fortran, libgfortran: Avoid using libquadmath for glibc 2.26+ Content-Language: en-US To: Jakub Jelinek , gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org Cc: "Joseph S. Myers" Newsgroups: gmane.comp.gcc.patches,gmane.comp.gcc.fortran References: From: Harald Anlauf In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:klx9yGBEj64QT7S1+jlr0P1hni9d5Zn/GX4amtPMdjvxcp9DwrI n09+BG+0dZ9au2xp+YK92MHabjXX1Hjm+u26Jn8pzxKx5aaBQp2RhkmJsGMocmwSi2IuAyQ 64Nl5ep7KOEOFhiI4qIeuTp65Fq0uDPBu6s4WJGSyv8w1wdz9Oy3I1Jvfch7VaICUgaqlu3 PLbz2CAW1Ks8agOLHD8tQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:FO7NDnMduVU=:gya610RnukdnD6VBtCRSLH kbnX5eB5uRV9+Xfg+8mF4Id7Gt6A7/wKn76KCvOGa6uHdz9GiO2C6mZIDAhgqJKVhcL7Yqmi+ NJedn78wd05Uqgywp3fdTngkCLvBTd9vltRe78Juy/0FsabrDsdDbXLIRU00a7ld3gdHNqElS oNBPL8XEEYLz8/bhXAoagOrfyNChA89U1WsmW2AUvnAikrkRRtBc/rlHDlH7bPLakP7h2l9Ny hbehXxoNQE8a0mKzRnb3nl/XC5QvjB+wG8eH9jl0EMnv833Zh5nvzw8P6dB63v7sLBp/zFF00 MQp/Heno3P18diLm38mXZQwD3gp6F7C3Ssqp3hq5AY7ajB4JRI3M8R5AkcQUWTX+JBC3ig4ev TANpTZuQsebG2VyjNlKzURKm9ogk8x36q4FEa97OXqdil246et6Ko1/to2GBYqFy2pj7ZtfLd mBGGV4c7EEcX2dAq3xILAPiDoEDJvivczOaw7j9VnUx9QEWUPGo2lZYFuoVjmG4eYtr+W2OYF jpKucIvM0zO0l6aVDsH+MgSB1BUW2co5SPFDiUzIqWRml8APa8QWvHAyXTgZd6aHpj7rdoimT M3ficYnOsV4UtknDpxqsm0iscVi6BPAfrc/F8sJqxjWRZfzkqmzKUC43FQNOQweJN5f0XW+8B zfwgfELsgw9sF7r6Ce0DO+FdHPjXXeRX+4dbCjvcG8kg7HaoD+N4Esg+JVesm3D5uQNIW4SH1 6kw9Ybro7SLEoJD8GSVw2Nzi95t9fxDxTN+sEYjQ1N/PolnzsupzZpqy2dv27VVwItv4riZOR jZ9RHY6vPkoX8A9QWt5QERPo0cDXGoaztsgi+KXmCB9w7exrRIxb0ONjlw9sHnUu1JzMjip+A V2HPnvZZDaIL0pxxH5H8yEEcH1R3ZB5CZvIgh85DjXNjCNrfxRq7cD5v9bjQPBPZ2ll70kpcq TnLsjPsmY0YEBg9bRAzljI34t0J0R1qmHUKU+p3k6YM8RgiOUn4wsIOb9FKHIDBE2lQ68Uwsc xovSaz+vfBRW5iBXuElPOomiP4i+ZGG3B8NCCuGTad63JiunAmJUHHv+EDjj3ejWNkloqqJ2d s1QaS/SuGsr7EjaMd8jpmFqCUZrcc8VMD2PRUo3Q7ZMi/5rI7DxaJl5OA== X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Thu, 23 Jun 2022 20:50:07 -0000 Hi Jakub, Am 23.06.22 um 14:04 schrieb Jakub Jelinek via Gcc-patches: > Hi! > > As mentioned by Joseph in PR105101, glibc 2.26 or later has on x86 > (both -m32/-m64), powerpc64le, ia64 and mips support for > *f128 math/complex APIs plus strtof128 and strfromf128, and these APIs a= llow > us to avoid libquadmath for Fortran purposes on these architectures, > replace *q math/complex APIs, strtof128 instead of strtoflt128 and, > while strfromf128 unfortunately isn't a perfect replacement to > quadmath_snprintf, it can be made to work. > > The advantage of this is that when configured against such glibcs > (2.26 is now almost 5 years old), we can avoid linking against an extra = shared > library and the math support in glibc is maintained better than libquadm= ath. > > We need both a compiler change (so that for glibc 2.26+ it uses *f128 AP= Is > instead of *q) and library change. this is quite an important change in the gfortran ABI, as it will require recompilation of (library) code using quad precision. Not that I am particularly affected, but this should be highlighted for users. Am I right in assuming that this also effectively fixes PR46539? (Add -static-libquadmath). > So far lightly tested on x86_64-linux with glibc 2.35 (removed libgfortr= an > dirs, rebuilt stage3 f951 and make all-target-libgfortran + make > check-gfortran), ok for trunk if it passes full testing? I did not look into all details, but noticed the following: > --- gcc/fortran/trans-intrinsic.cc.jj 2022-05-16 11:14:57.587427707 +020= 0 > +++ gcc/fortran/trans-intrinsic.cc 2022-06-23 11:42:03.355899271 +0200 > @@ -155,7 +155,7 @@ builtin_decl_for_precision (enum built_i > else if (precision =3D=3D TYPE_PRECISION (double_type_node)) > i =3D m->double_built_in; > else if (precision =3D=3D TYPE_PRECISION (long_double_type_node) > - && (!gfc_real16_is_float128 > + && ((!gfc_real16_is_float128 & !gfc_real16_is__Float128) Shouldn't this be && instead of & ? > || long_double_type_node !=3D gfc_float128_type_node)) > i =3D m->long_double_built_in; > else if (precision =3D=3D TYPE_PRECISION (gfc_float128_type_node)) > @@ -175,7 +175,7 @@ gfc_builtin_decl_for_float_kind (enum bu > { > int i =3D gfc_validate_kind (BT_REAL, kind, false); > > - if (gfc_real_kinds[i].c_float128) > + if (gfc_real_kinds[i].c_float128 || gfc_real_kinds[i].c__Float128) > { > /* For _Float128, the story is a bit different, because we retur= n > a decl to a library function rather than a built-in. */ > @@ -688,7 +688,7 @@ gfc_build_intrinsic_lib_fndecls (void) > gfc_intrinsic_map_t *m; > tree quad_decls[END_BUILTINS + 1]; > > - if (gfc_real16_is_float128) > + if (gfc_real16_is_float128 || gfc_real16_is__Float128) > { > /* If we have soft-float types, we create the decls for their > C99-like library functions. For now, we only handle _Float128 > @@ -739,7 +739,10 @@ gfc_build_intrinsic_lib_fndecls (void) > builtin_decl_for_float_type(). The others are all constructed b= y > gfc_get_intrinsic_lib_fndecl(). */ > #define OTHER_BUILTIN(ID, NAME, TYPE, CONST) \ > - quad_decls[BUILT_IN_ ## ID] =3D define_quad_builtin (NAME "q", func_ = ## TYPE, CONST); > + quad_decls[BUILT_IN_ ## ID] \ > + =3D define_quad_builtin (gfc_real16_is__Float128 \ > + ? NAME "f128" : NAME "q", func_ ## TYPE, \ > + CONST); > > #include "mathbuiltins.def" > > @@ -751,8 +754,9 @@ gfc_build_intrinsic_lib_fndecls (void) > /* There is one built-in we defined manually, because it gets call= ed > with builtin_decl_for_precision() or builtin_decl_for_float_typ= e() > even though it is not an OTHER_BUILTIN: it is SQRT. */ > - quad_decls[BUILT_IN_SQRT] =3D define_quad_builtin ("sqrtq", func_1,= true); > - > + quad_decls[BUILT_IN_SQRT] > + =3D define_quad_builtin (gfc_real16_is__Float128 > + ? "sqrtf128" : "sqrtq", func_1, true); > } > > /* Add GCC builtin functions. */ > @@ -775,7 +779,7 @@ gfc_build_intrinsic_lib_fndecls (void) > m->complex10_decl > =3D builtin_decl_explicit (m->complex_long_double_built_in); > > - if (!gfc_real16_is_float128) > + if (!gfc_real16_is_float128 && !gfc_real16_is__Float128) > { > if (m->long_double_built_in !=3D END_BUILTINS) > m->real16_decl =3D builtin_decl_explicit (m->long_double_built_in= ); > @@ -876,6 +880,9 @@ gfc_get_intrinsic_lib_fndecl (gfc_intrin > else if (gfc_real_kinds[n].c_float128) > snprintf (name, sizeof (name), "%s%s%s", > ts->type =3D=3D BT_COMPLEX ? "c" : "", m->name, "q"); > + else if (gfc_real_kinds[n].c__Float128) > + snprintf (name, sizeof (name), "%s%s%s", > + ts->type =3D=3D BT_COMPLEX ? "c" : "", m->name, "f128"); > else > gcc_unreachable (); > } > --- gcc/fortran/trans-expr.cc.jj 2022-04-23 10:10:51.146097072 +0200 > +++ gcc/fortran/trans-expr.cc 2022-06-23 11:49:31.191964727 +0200 > @@ -3582,7 +3582,7 @@ gfc_conv_power_op (gfc_se * se, gfc_expr > case 3: > /* Use the __builtin_powil() only if real(kind=3D16) is > actually the C long double type. */ > - if (!gfc_real16_is_float128) > + if (!gfc_real16_is_float128 & !gfc_real16_is__Float128) Likewise. > fndecl =3D builtin_decl_explicit (BUILT_IN_POWIL); > break; > You may wish to wait for further comments. Thanks for the patch! Harald