From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id EE85C3858D1E; Wed, 10 Aug 2022 17:51:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EE85C3858D1E From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64 Date: Wed, 10 Aug 2022 17:51:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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: Wed, 10 Aug 2022 17:51:18 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106579 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fxcoudert at gcc dot gnu.o= rg, | |jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Ouch, indeed. Looking at ieee/ieee_exceptions.F90, I think that one is ok, while __ieee_exceptions_MOD_ieee_support_flag_16 is exported from the library, all of __ieee_exceptions_MOD_ieee_support_flag_{4,8,16} return the same result and= I think it is the same for both IEEE quad and IBM double double formats too, so using __ieee_exceptions_MOD_ieee_support_flag_16 for it is fine. On the other side, ieee/ieee_arithmetic.F90 is problematic. I must say I don't understand at all stuff like IEEE_IS_FINITE, because it refers to stuff like _gfortran_ieee_is_finite_16 which I don't see anywhere in libgfortran.{so.5,a}. Looking purely on what is exported from libgfortran.so.5 from the ieee_arithmetic module symbols, I see: readelf -Wa ../powerpc64le-unknown-linux-gnu/libgfortran/.libs/libgfortran.= so.5 | grep ieee_arith | grep _16@@ 483: 00000000001ca770 20 FUNC GLOBAL DEFAULT 11 __ieee_arithmetic_MOD_ieee_support_io_16@@GFORTRAN_8 555: 00000000001ca670 20 FUNC GLOBAL DEFAULT 11 __ieee_arithmetic_MOD_ieee_support_sqrt_16@@GFORTRAN_8 753: 00000000001cac10 72 FUNC GLOBAL DEFAULT 11 __ieee_arithmetic_MOD_ieee_support_rounding_16@@GFORTRAN_8 [:= 8] 771: 00000000001caef0 56 FUNC GLOBAL DEFAULT 11 __ieee_arithmetic_MOD_ieee_class_16@@GFORTRAN_8 [: 8] 795: 00000000001ca8f0 20 FUNC GLOBAL DEFAULT 11 __ieee_arithmetic_MOD_ieee_support_subnormal_16@@GFORTRAN_9 823: 00000000001ca970 20 FUNC GLOBAL DEFAULT 11 __ieee_arithmetic_MOD_ieee_support_denormal_16@@GFORTRAN_8 961: 00000000001ca6f0 20 FUNC GLOBAL DEFAULT 11 __ieee_arithmetic_MOD_ieee_support_nan_16@@GFORTRAN_8 1220: 00000000001cae30 60 FUNC GLOBAL DEFAULT 11 __ieee_arithmetic_MOD_ieee_value_16@@GFORTRAN_8 [: 8] 1265: 00000000001ca7f0 20 FUNC GLOBAL DEFAULT 11 __ieee_arithmetic_MOD_ieee_support_inf_16@@GFORTRAN_8 1502: 00000000001caad0 72 FUNC GLOBAL DEFAULT 11 __ieee_arithmetic_MOD_ieee_support_underflow_control_16@@GFORTRAN_8=20 [: 8] 1532: 00000000001ca5f0 20 FUNC GLOBAL DEFAULT 11 __ieee_arithmetic_MOD_ieee_support_standard_16@@GFORTRAN_8 1596: 00000000001ca870 20 FUNC GLOBAL DEFAULT 11 __ieee_arithmetic_MOD_ieee_support_divide_16@@GFORTRAN_8 1703: 00000000001ca9f0 20 FUNC GLOBAL DEFAULT 11 __ieee_arithmetic_MOD_ieee_support_datatype_16@@GFORTRAN_8 Now, most of the above are probably fine too, they just return true and aga= in that answer seems to be fine for both when real(kind=3D16) is IBM double double or IEEE quad. The problematic cases from those are: __ieee_arithmetic_MOD_ieee_class_16 __ieee_arithmetic_MOD_ieee_value_16 The above 2 clearly need different behavior when real(kind=3D16) is IEEE qu= ad vs. IBM double double, the implementation right now implements those for IBM double double. So, either we need to arrange for those to be expanded inline by the fronte= nd (and it can be done either by hardcoding the enumerators or say transforming the calls from working wi= th IEEE quad to working with IBM double double or vice versa), or we need to add __ieee_arithmetic_MOD_ieee_class_17 __ieee_arithmetic_MOD_ieee_value_17 entrypoints to the library and arrange for the _16 to be remapped to _17 for these 2. Other possibly problematic functions are __ieee_arithmetic_MOD_ieee_support_rounding_16 __ieee_arithmetic_MOD_ieee_support_underflow_control_16 The former seems to do the exact same call in each case, so is probably fine like the true cases, the latter actually calls support_underflow_control_helper with kind value,= but it is ignored everywhere but alpha, so is fine too. For the transformation above, I mean something like handling ieee_class by doing __builtin_fpclassify + issignalling and __builtin_signbit and depending on the result call __ieee_arithmetic_MOD_ieee_class_16 on sample IBM double double values with the same properties. Similarly, ieee_value by calling __ieee_arithmetic_MOD_ieee_value_16 first, analyzing the result with __builtin_fpclassify and in most cases just converting the IBM double doubl= e to IEEE quad. Guess NaNs (especially signalling NaN) and denormals need to be an exceptio= n. Another question is if one needs to implement these as actual out of line functions (even hidden), whether it is permissible to say call some function/subroutine with ieee_value or ieee_cl= ass as procedure argument. Given that they are overloaded, I'd hope it is not possible.=