[PATCH] powerpc64le: Fix TFtype in sqrtf128 when using -mabi=ieeelongdouble

[PATCH] powerpc64le: Fix TFtype in sqrtf128 when using -mabi=ieeelongdouble

[Tulio Magno Quites Machado Filho]

When building with -mlong-double-128 or -mabi=ibmlongdouble, TFtype
represents the IBM 128-bit extended floating point type, while KFtype
represents the IEEE 128-bit floating point type.
The soft float implementation of e_sqrtf128 had to redefine TFtype and
TF in order to workaround this issue.  However, this behavior changes
when -mabi=ieeelongdouble is used and the macros are not necessary.

2018-05-28  Tulio Magno Quites Machado Filho  <tuliom@linux.ibm.com>

	* sysdeps/powerpc/powerpc64le/fpu/e_sqrtf128.c
	[__HAVE_FLOAT128_UNLIKE_LDBL] (TFtype, TF): Restrict TFtype
	and TF redirection to KFtype and KF only when the default
	long double type is not the IEEE 128-bit floating point type.

Signed-off-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
---
 sysdeps/powerpc/powerpc64/le/fpu/e_sqrtf128.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/sysdeps/powerpc/powerpc64/le/fpu/e_sqrtf128.c b/sysdeps/powerpc/powerpc64/le/fpu/e_sqrtf128.c
index 0ff897bef3..1ef3d509b0 100644
--- a/sysdeps/powerpc/powerpc64/le/fpu/e_sqrtf128.c
+++ b/sysdeps/powerpc/powerpc64/le/fpu/e_sqrtf128.c
@@ -26,9 +26,12 @@
    License along with the GNU C Library; if not, see
    <http://www.gnu.org/licenses/>.  */
 
-/* Unavoidable hacks since TFmode is assumed to be binary128. */
-#define TFtype KFtype
-#define TF KF
+/* Unavoidable hacks since TFmode is assumed to be binary128 when
+   -mabi=ibmlongdouble is used.  */
+#if __HAVE_FLOAT128_UNLIKE_LDBL
+# define TFtype KFtype
+# define TF KF
+#endif
 
 #include <soft-fp.h>
 #include <quad.h>
-- 
2.14.3

Re: [PATCH] powerpc64le: Fix TFtype in sqrtf128 when using -mabi=ieeelongdouble

[Gabriel F. T. Gomes]

On Mon, 28 May 2018, Tulio Magno Quites Machado Filho wrote:

>When building with -mlong-double-128 or -mabi=ibmlongdouble, TFtype
>represents the IBM 128-bit extended floating point type, while KFtype
>represents the IEEE 128-bit floating point type.
>The soft float implementation of e_sqrtf128 had to redefine TFtype and
>TF in order to workaround this issue.  However, this behavior changes
>when -mabi=ieeelongdouble is used and the macros are not necessary.

OK.

>	* sysdeps/powerpc/powerpc64le/fpu/e_sqrtf128.c
                          ~~~~~~~~~~~
Missing the slash, i.e.: powerpc64/le.
 
>--- a/sysdeps/powerpc/powerpc64/le/fpu/e_sqrtf128.c
>+++ b/sysdeps/powerpc/powerpc64/le/fpu/e_sqrtf128.c
>@@ -26,9 +26,12 @@
>    License along with the GNU C Library; if not, see
>    <http://www.gnu.org/licenses/>.  */
> 
>-/* Unavoidable hacks since TFmode is assumed to be binary128. */
>-#define TFtype KFtype
>-#define TF KF
>+/* Unavoidable hacks since TFmode is assumed to be binary128 when
>+   -mabi=ibmlongdouble is used.  */
>+#if __HAVE_FLOAT128_UNLIKE_LDBL

Don't you have to include bits/floatn.h to get the definition of
__HAVE_FLOAT128_UNLIKE_LDBL?


Looks good to me with these changes.

Re: [PATCH] powerpc64le: Fix TFtype in sqrtf128 when using -mabi=ieeelongdouble

[Tulio Magno Quites Machado Filho]

"Gabriel F. T. Gomes" <gabriel@inconstante.eti.br> writes:

> On Mon, 28 May 2018, Tulio Magno Quites Machado Filho wrote:
>
>>	* sysdeps/powerpc/powerpc64le/fpu/e_sqrtf128.c
>                           ~~~~~~~~~~~
> Missing the slash, i.e.: powerpc64/le.

Oops.  This was outdated.

>>--- a/sysdeps/powerpc/powerpc64/le/fpu/e_sqrtf128.c
>>+++ b/sysdeps/powerpc/powerpc64/le/fpu/e_sqrtf128.c
>>@@ -26,9 +26,12 @@
>>    License along with the GNU C Library; if not, see
>>    <http://www.gnu.org/licenses/>.  */
>> 
>>-/* Unavoidable hacks since TFmode is assumed to be binary128. */
>>-#define TFtype KFtype
>>-#define TF KF
>>+/* Unavoidable hacks since TFmode is assumed to be binary128 when
>>+   -mabi=ibmlongdouble is used.  */
>>+#if __HAVE_FLOAT128_UNLIKE_LDBL
>
> Don't you have to include bits/floatn.h to get the definition of
> __HAVE_FLOAT128_UNLIKE_LDBL?

Indeed.

Fixed and pushed as 1c09524e4d.

Thanks!

-- 
Tulio Magno