Fix libgfortran FMA3/FMA4 tests

Fix libgfortran FMA3/FMA4 tests

[Rainer Orth]

[-- Attachment #1: Type: text/plain, Size: 1579 bytes --]

The recent libgfortran AVX128 patch broke bootstrap on Solaris/x86 with
the native assembler.  libgfortran compilation fails like this:

Assembler: matmulavx128_r8.c
        "/var/tmp//cc51E6lb.s", line 5811 : Illegal mnemonic
        Near line: "    vfmaddpd        %xmm0, (%edi), %xmm5, %xmm7"
        "/var/tmp//cc51E6lb.s", line 5811 : Syntax error
        Near line: "    vfmaddpd        %xmm0, (%edi), %xmm5, %xmm7"
[...]
Too many errors - Goodbye
make[3]: *** [Makefile:4663: matmulavx128_r8.lo] Error 1

and several more.

It turns out that the FMA3 and FMA4 tests in acinclude.m4 don't test
what they claim to:  if one compiles the test program

float
flt_mul_add (float a, float b, float c)
{
	return __builtin_fmaf (a, b, c);
}

with -O2 -mfma -mno-fma4 (FMA3) resp. -O2 -mfma4 -mno-fma (FMA4), both
boil done to

flt_mul_add:
        jmp     fmaf

so the test always succeeds.

The following patch fixes this by instead using the tests from
gcc.target/i386/i386.exp.  While the FMA3 test still passes with
/bin/as, the FMA4 one fails, avoiding the breakage.

Bootstrapped on i386-pc-solaris2.12 with both as and gas without
regressions.

Ok for mainline?

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University


2017-05-28  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	* acinclude.m4 (LIBGFOR_CHECK_FMA3): Use test from
	check_effective_target_fma in gcc.target/i386/i386.exp.
	(LIBGFOR_CHECK_FMA4): Use test from check_effective_target_fma4.
	* configure: Regenerate.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: solx86-libgfortran-fma34.patch --]
[-- Type: text/x-patch, Size: 1524 bytes --]

# HG changeset patch
# Parent  743cb41a74816da876222b6da785fdf5f3fc2efb
Fix libgfortran FMA3/FMA4 tests

diff --git a/libgfortran/acinclude.m4 b/libgfortran/acinclude.m4
--- a/libgfortran/acinclude.m4
+++ b/libgfortran/acinclude.m4
@@ -459,10 +459,13 @@ AC_DEFUN([LIBGFOR_CHECK_FMA3], [
   ac_save_CFLAGS="$CFLAGS"
   CFLAGS="-O2 -mfma -mno-fma4"
   AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
-	float
-	flt_mul_add (float a, float b, float c)
+        typedef float __m128 __attribute__ ((__vector_size__ (16)));
+	typedef float __v4sf __attribute__ ((__vector_size__ (16)));
+	__m128 _mm_macc_ps(__m128 __A, __m128 __B, __m128 __C)
 	{
-		return __builtin_fmaf (a, b, c);
+	    return (__m128) __builtin_ia32_vfmaddps ((__v4sf)__A,
+						     (__v4sf)__B,
+						     (__v4sf)__C);
         }]], [[]])],
 	AC_DEFINE(HAVE_FMA3, 1,
 	[Define if FMA3 instructions can be compiled.]),
@@ -476,10 +479,13 @@ AC_DEFUN([LIBGFOR_CHECK_FMA4], [
   ac_save_CFLAGS="$CFLAGS"
   CFLAGS="-O2 -mfma4 -mno-fma"
   AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
-	float
-	flt_mul_add (float a, float b, float c)
+        typedef float __m128 __attribute__ ((__vector_size__ (16)));
+	typedef float __v4sf __attribute__ ((__vector_size__ (16)));
+	__m128 _mm_macc_ps(__m128 __A, __m128 __B, __m128 __C)
 	{
-		return __builtin_fmaf (a, b, c);
+	    return (__m128) __builtin_ia32_vfmaddps ((__v4sf)__A,
+						     (__v4sf)__B,
+						     (__v4sf)__C);
         }]], [[]])],
 	AC_DEFINE(HAVE_FMA4, 1,
 	[Define if FMA4 instructions can be compiled.]),

Re: Fix libgfortran FMA3/FMA4 tests

[Thomas Koenig]

Hi Rainer,

> It turns out that the FMA3 and FMA4 tests in acinclude.m4 don't test
> what they claim to:  if one compiles the test program
> 
> float
> flt_mul_add (float a, float b, float c)
> {
> 	return __builtin_fmaf (a, b, c);
> }
> 
> with -O2 -mfma -mno-fma4 (FMA3) resp. -O2 -mfma4 -mno-fma (FMA4), both
> boil done to
> 
> flt_mul_add:
>          jmp     fmaf
> 
> so the test always succeeds.
> 
> The following patch fixes this by instead using the tests from
> gcc.target/i386/i386.exp.  While the FMA3 test still passes with
> /bin/as, the FMA4 one fails, avoiding the breakage.
> 
> Bootstrapped on i386-pc-solaris2.12 with both as and gas without
> regressions.
> 
> Ok for mainline?

OK, and thanks a lot for the patch!

I hope this is the last fallout from the AMD patchess...

Regards

	Thomas