enable __ieee128 for p9vector tests

enable __ieee128 for p9vector tests

[Alexandre Oliva]

Several compile tests that use the __ieee128 type do not ensure it is
defined.  This patch adds -mfloat128 to their command lines, and
disregards the warning that may be issued by it.

Tested on x86_64-linux-gnu with a cross to powerpc-wrs-vxworks7r2,
configured for a CPU without altivec/vsx support.  Ok to install?


for  gcc/testsuite/ChangeLog

	* gcc_target/powerpc/bfp/scalar-extract-exp-5.c: Add
	-mfloat128, and disregard warning about it.
	* gcc_target/powerpc/bfp/scalar-extract-sig-5.c: Likewise.
	* gcc_target/powerpc/bfp/scalar-insert-exp-11.c: Likewise.
	* gcc_target/powerpc/bfp/scalar-insert-exp-8.c: Likewise.
	* gcc_target/powerpc/bfp/scalar-test-data-class-11.c: Likewise.
	* gcc_target/powerpc/bfp/scalar-test-neg-5.c: Likewise.
---
 .../gcc.target/powerpc/bfp/scalar-extract-exp-5.c  |    3 ++-
 .../gcc.target/powerpc/bfp/scalar-extract-sig-5.c  |    3 ++-
 .../gcc.target/powerpc/bfp/scalar-insert-exp-11.c  |    3 ++-
 .../gcc.target/powerpc/bfp/scalar-insert-exp-8.c   |    3 ++-
 .../powerpc/bfp/scalar-test-data-class-11.c        |    3 ++-
 .../gcc.target/powerpc/bfp/scalar-test-neg-5.c     |    3 ++-
 6 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-5.c b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-5.c
index 34184812dc5cf..f57a388d8628f 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-5.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-5.c
@@ -1,7 +1,8 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target ilp32 } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power9" } */
+/* { dg-options "-mdejagnu-cpu=power9 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 /* This test only runs on 32-bit configurations, where a compiler error
    should be issued because this builtin is not available on
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-5.c b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-5.c
index 13c64fc3acfef..786740b2b8404 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-5.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-5.c
@@ -1,7 +1,8 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target ilp32 } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power9" } */
+/* { dg-options "-mdejagnu-cpu=power9 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 /* This test only runs on 32-bit configurations, producing a compiler
    error because the builtin requires 64 bits.  */
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-11.c b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-11.c
index a5dd852e60f0a..fd055c8a1fc31 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-11.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-11.c
@@ -1,7 +1,8 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target ilp32 } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power9" } */
+/* { dg-options "-mdejagnu-cpu=power9 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 /* This test only runs on 32-bit configurations, where a compiler error
    should be issued because this builtin is not available on
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-8.c b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-8.c
index bd68f77098568..795106b936c88 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-8.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-8.c
@@ -1,7 +1,8 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target ilp32 } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power9" } */
+/* { dg-options "-mdejagnu-cpu=power9 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 /* This test only runs on 32-bit configurations, where a compiler error
    should be issued because this builtin is not available on
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-11.c b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-11.c
index 7c6fca2b7292b..945257762c1dd 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-11.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-11.c
@@ -1,6 +1,7 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power8" } */
+/* { dg-options "-mdejagnu-cpu=power8 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 #include <altivec.h>
 #include <stdbool.h>
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-neg-5.c b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-neg-5.c
index bab86040a7bf4..74b82aee40877 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-neg-5.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-neg-5.c
@@ -1,6 +1,7 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power8" } */
+/* { dg-options "-mdejagnu-cpu=power8 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 #include <altivec.h>
 #include <stdbool.h>


-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist         GNU Toolchain Engineer
        Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

Re: enable __ieee128 for p9vector tests

[Segher Boessenkool]

Hi!

Sorry for the late answer.

On Fri, Apr 02, 2021 at 01:52:59PM -0300, Alexandre Oliva wrote:
> Several compile tests that use the __ieee128 type do not ensure it is
> defined.  This patch adds -mfloat128 to their command lines, and
> disregards the warning that may be issued by it.

But they do make sure it is defined, they use -mcpu=power9 (etc.).  What
is different in your setup that that does not work?


Segher

Re: enable __ieee128 for p9vector tests

[Alexandre Oliva]

On Apr 12, 2021, Segher Boessenkool <segher@kernel.crashing.org> wrote:

> Hi!
> Sorry for the late answer.

> On Fri, Apr 02, 2021 at 01:52:59PM -0300, Alexandre Oliva wrote:
>> Several compile tests that use the __ieee128 type do not ensure it is
>> defined.  This patch adds -mfloat128 to their command lines, and
>> disregards the warning that may be issued by it.

> But they do make sure it is defined, they use -mcpu=power9 (etc.).  What
> is different in your setup that that does not work?

I suppose it's either -mno-altivec -mno-vsx in our self-specs, or the
very old default CPU.  I imagine it's also possible that the issue,
initially observed with GCC 10, is different or absent with the trunk.

I started trying to figure out what led __ieee128 to not be enabled
there, back then, but decided it was not so important, given that other
tests used this flag explicitly, and that it wouldn't hurt to have it
even if it wasn't always necessary.

Now, if you tell me that, even with our implicit flags and old CPU
selection, -mfloat128 should not be necessary to enable the __ieee128
type, I would be glad to dig further to try and fix the underlying bug.

Thanks,

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist         GNU Toolchain Engineer
        Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

Re: enable __ieee128 for p9vector tests

[Alexandre Oliva]

On Apr 17, 2021, Alexandre Oliva <oliva@adacore.com> wrote:

> On Apr 12, 2021, Segher Boessenkool <segher@kernel.crashing.org> wrote:
>> Hi!
>> Sorry for the late answer.

Likewise :-)

>> On Fri, Apr 02, 2021 at 01:52:59PM -0300, Alexandre Oliva wrote:
>>> Several compile tests that use the __ieee128 type do not ensure it is
>>> defined.  This patch adds -mfloat128 to their command lines, and
>>> disregards the warning that may be issued by it.

>> But they do make sure it is defined, they use -mcpu=power9 (etc.).  What
>> is different in your setup that that does not work?

> I suppose it's either -mno-altivec -mno-vsx in our self-specs, or the
> very old default CPU.  I imagine it's also possible that the issue,
> initially observed with GCC 10, is different or absent with the trunk.

My supposition was wrong.  It turned out to be just because in
vxworks.h, for TARGET_VXWORKS7, there's:

#define TARGET_FLOAT128_ENABLE_TYPE 0

This disables TARGET_FLOAT128_TYPE by default, and causes the warning to
be issued when -mfloat128 is explicitly enabled.


So ping https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567630.html
upthread, and expect 3 new patches related with -mfloat128 momentarily.

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

ppc: testsuite: bfp: enable float128 for __ieee128

[Alexandre Oliva]

Multiple bfp tests expect -mcpu=power[89] to enable the __ieee128
type, but on targets that #define TARGET_FLOAT128_ENABLE_TYPE 0, that
is not the case.  Since they are compile-time tests and effective
target support for powerpc_p9vector_ok is required, adding -mfloat128
is safe.  This patch does so, and arranges for the warning raised on
such systems to be pruned.

Tested on x86_64-linux-gnu x ppc64-vx7r2 with gcc-11.  Ok to install?


for  gcc/testsuite/ChangeLog

	* gcc.target/powerpc/bfp/scalar-extract-exp-3.c: Add -mfloat128,
	prune warning.
	* gcc.target/powerpc/bfp/scalar-extract-exp-4.c: Likewise.
	* gcc.target/powerpc/bfp/scalar-extract-sig-3.c: Likewise.
	* gcc.target/powerpc/bfp/scalar-extract-sig-4.c: Likewise.
	* gcc.target/powerpc/bfp/scalar-insert-exp-10.c: Likewise.
	* gcc.target/powerpc/bfp/scalar-insert-exp-6.c: Likewise.
	* gcc.target/powerpc/bfp/scalar-insert-exp-7.c: Likewise.
	* gcc.target/powerpc/bfp/scalar-insert-exp-9.c: Likewise.
	* gcc.target/powerpc/bfp/scalar-test-data-class-10.c: Likewise.
	* gcc.target/powerpc/bfp/scalar-test-data-class-8.c: Likewise.
	* gcc.target/powerpc/bfp/scalar-test-data-class-9.c: Likewise.
	* gcc.target/powerpc/bfp/scalar-test-neg-4.c: Likewise.
---
 .../gcc.target/powerpc/bfp/scalar-extract-exp-3.c  |    3 ++-
 .../gcc.target/powerpc/bfp/scalar-extract-exp-4.c  |    3 ++-
 .../gcc.target/powerpc/bfp/scalar-extract-sig-3.c  |    3 ++-
 .../gcc.target/powerpc/bfp/scalar-extract-sig-4.c  |    3 ++-
 .../gcc.target/powerpc/bfp/scalar-insert-exp-10.c  |    3 ++-
 .../gcc.target/powerpc/bfp/scalar-insert-exp-6.c   |    3 ++-
 .../gcc.target/powerpc/bfp/scalar-insert-exp-7.c   |    3 ++-
 .../gcc.target/powerpc/bfp/scalar-insert-exp-9.c   |    3 ++-
 .../powerpc/bfp/scalar-test-data-class-10.c        |    3 ++-
 .../powerpc/bfp/scalar-test-data-class-8.c         |    3 ++-
 .../powerpc/bfp/scalar-test-data-class-9.c         |    3 ++-
 .../gcc.target/powerpc/bfp/scalar-test-neg-4.c     |    3 ++-
 12 files changed, 24 insertions(+), 12 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-3.c b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-3.c
index 8ddf87cfc8693..4c5615662c917 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-3.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-3.c
@@ -1,7 +1,8 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target lp64 } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power9" } */
+/* { dg-options "-mdejagnu-cpu=power9 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 /* This test should succeed only on 64-bit configurations.  */
 #include <altivec.h>
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-4.c b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-4.c
index 850ff6204900d..1b03967ed8d2c 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-4.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-4.c
@@ -1,7 +1,8 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target lp64 } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power8" } */
+/* { dg-options "-mdejagnu-cpu=power8 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 /* This test should succeed only on 64-bit configurations.  */
 #include <altivec.h>
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-3.c b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-3.c
index 3225a557f84ba..2c459ad808fb0 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-3.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-3.c
@@ -1,7 +1,8 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target lp64 } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power9" } */
+/* { dg-options "-mdejagnu-cpu=power9 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 /* This test should succeed only on 64-bit configurations.  */
 #include <altivec.h>
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-4.c b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-4.c
index 32a53c6fffd7e..e8bb856c91736 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-4.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-4.c
@@ -1,7 +1,8 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target lp64 } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power8" } */
+/* { dg-options "-mdejagnu-cpu=power8 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 /* This test should succeed only on 64-bit configurations.  */
 #include <altivec.h>
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-10.c b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-10.c
index 769d3b0546a6b..e0ed3b8a5e9a0 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-10.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-10.c
@@ -1,7 +1,8 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target lp64 } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power8" } */
+/* { dg-options "-mdejagnu-cpu=power8 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 /* This test should succeed only on 64-bit configurations.  */
 #include <altivec.h>
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-6.c b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-6.c
index f81dff4e1adc5..8087846ecc7ed 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-6.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-6.c
@@ -1,7 +1,8 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target lp64 } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power9" } */
+/* { dg-options "-mdejagnu-cpu=power9 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 /* This test should succeed only on 64-bit configurations.  */
 #include <altivec.h>
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-7.c b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-7.c
index 2e03e15d02542..95dd65a03ec6c 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-7.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-7.c
@@ -1,7 +1,8 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target lp64 } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power8" } */
+/* { dg-options "-mdejagnu-cpu=power8 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 /* This test should succeed only on 64-bit configurations.  */
 #include <altivec.h>
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-9.c b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-9.c
index 209f82dd79967..d577428470234 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-9.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-9.c
@@ -1,7 +1,8 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target lp64 } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power9" } */
+/* { dg-options "-mdejagnu-cpu=power9 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 /* This test should succeed only on 64-bit configurations.  */
 #include <altivec.h>
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-10.c b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-10.c
index fcf6a9dca79d7..450dfb45bb44a 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-10.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-10.c
@@ -3,7 +3,8 @@
    target produces different error message.  */
 /* { dg-require-effective-target lp64 } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power9" } */
+/* { dg-options "-mdejagnu-cpu=power9 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 #include <altivec.h>
 #include <stdbool.h>
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-8.c b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-8.c
index a9e107a816cfa..94cb060f97541 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-8.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-8.c
@@ -1,7 +1,8 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target lp64 } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power9" } */
+/* { dg-options "-mdejagnu-cpu=power9 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 #include <altivec.h>
 #include <stdbool.h>
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-9.c b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-9.c
index f87851c2c5f29..030df40d6df0b 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-9.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-9.c
@@ -1,7 +1,8 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target lp64 } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power9" } */
+/* { dg-options "-mdejagnu-cpu=power9 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 #include <altivec.h>
 #include <stdbool.h>
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-neg-4.c b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-neg-4.c
index 4a3f25e7f6349..adf9a0f353bfe 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-neg-4.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-neg-4.c
@@ -1,7 +1,8 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target lp64 } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power9" } */
+/* { dg-options "-mdejagnu-cpu=power9 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 #include <altivec.h>
 #include <stdbool.h>

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

ppc: testsuite: prune float128 partial support warnings

[Alexandre Oliva]

When -mfloat128 is specified on targets that don't have float128 types
enabled by default, a warning is raised that the option may not be
fully supported.  This patch prunes the warning on some tests that use
the flag but don't accept the warning.

Tested on x86_64-linux-gnu x ppc64-vx7r2 with gcc-11.  Ok to install?


for  gcc/testsuite/ChangeLog

	* gcc.target/powerpc/pr79004.c: Prune the -mfloat128 warning.
	* gcc.target/powerpc/pr79038-1.c: Likewise.
	* gcc.target/powerpc/pr81959.c: Likewise.
---
 gcc/testsuite/gcc.target/powerpc/pr79004.c   |    1 +
 gcc/testsuite/gcc.target/powerpc/pr79038-1.c |    1 +
 gcc/testsuite/gcc.target/powerpc/pr81959.c   |    1 +
 3 files changed, 3 insertions(+)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr79004.c b/gcc/testsuite/gcc.target/powerpc/pr79004.c
index 30cdebaad3623..e411702dc98a9 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr79004.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr79004.c
@@ -1,6 +1,7 @@
 /* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
 /* { dg-options "-mdejagnu-cpu=power9 -O2 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 #include <math.h>
 
diff --git a/gcc/testsuite/gcc.target/powerpc/pr79038-1.c b/gcc/testsuite/gcc.target/powerpc/pr79038-1.c
index bf93595fe6541..8f2751d01a0ba 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr79038-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr79038-1.c
@@ -1,6 +1,7 @@
 /* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
 /* { dg-options "-mdejagnu-cpu=power9 -O2 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 #ifndef TYPE
 #define TYPE _Float128
diff --git a/gcc/testsuite/gcc.target/powerpc/pr81959.c b/gcc/testsuite/gcc.target/powerpc/pr81959.c
index c4cc373384195..d9c3319d5d448 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr81959.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr81959.c
@@ -1,6 +1,7 @@
 /* { dg-do compile { target { powerpc64*-*-* && lp64 } } } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
 /* { dg-options "-mpower9-vector -O2 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 /* PR 81959, the compiler raised on unrecognizable insn message in converting
    int to __float128, where the int had a PRE_INC in the address.  */

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

[PATCH] ppc: testsuite: enable _Float128 type

[Alexandre Oliva]

[sorry, I failed to add [PATCH] to the subject of the two previous patches]

Though -mpower9-vector makes float128 support possible, some target
systems such as vxworks disable float128 types by default
(TARGET_FLOAT128_ENABLE_TYPE is defined to 0), so explicit -mfloat128
is needed to enable it, and then the fact that the full support may be
unavailable is flagged with a warning.

This patch adds -mfloat128 and prunes the warning in two tests that
use the _Float128 type without explicitly enabling it.

Tested on x86_64-linux-gnu x ppc64-vx7r2 with gcc-11.  Ok to install?


for  gcc/testsuite/ChangeLog

	* gcc.target/powerpc/pr82748-1.c: Add -mfloat128 and prune its
	warning.
	* gcc.target/powerpc/pr82748-2.c: Likewise.
---
 gcc/testsuite/gcc.target/powerpc/pr82748-1.c |    3 ++-
 gcc/testsuite/gcc.target/powerpc/pr82748-2.c |    3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr82748-1.c b/gcc/testsuite/gcc.target/powerpc/pr82748-1.c
index 15a746bcf63ea..2bb6be1183a59 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr82748-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr82748-1.c
@@ -1,6 +1,7 @@
 /* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mpower9-vector -O2 -mabi=ieeelongdouble -Wno-psabi" } */
+/* { dg-options "-mpower9-vector -O2 -mfloat128 -mabi=ieeelongdouble -Wno-psabi" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 /* Make sure the old 'q' builtin functions work correctly when the long double
    default has been changed to be IEEE 128-bit floating point.  */
diff --git a/gcc/testsuite/gcc.target/powerpc/pr82748-2.c b/gcc/testsuite/gcc.target/powerpc/pr82748-2.c
index 0079394b1016e..c031ae037dd8d 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr82748-2.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr82748-2.c
@@ -1,6 +1,7 @@
 /* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mpower9-vector -O2 -mabi=ibmlongdouble -Wno-psabi" } */
+/* { dg-options "-mpower9-vector -O2 -mfloat128 -mabi=ibmlongdouble -Wno-psabi" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 /* Make sure the old 'q' builtin functions work correctly when the long double
    default uses the IBM double-double format.  */

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

[PATCH] ppc: testsuite: pr79004 needs -mlong-double-128 (was: Re: ppc: testsuite: prune float128 partial support warnings)

[Alexandre Oliva]

On Apr 13, 2022, Alexandre Oliva <oliva@adacore.com> wrote:

> 	* gcc.target/powerpc/pr79004.c: Prune the -mfloat128 warning.

I failed to mention that this fixed a problem in the test, but that was
not enough for this test to pass; here's an incremental patch that is.


Some of the asm opcodes expected by pr79004 depend on
-mlong-double-128 to be output.  E.g., without this flag, the
conditions of patterns @extenddf<mode>2 and extendsf<mode>2 do not
hold, and so GCC resorts to libcalls instead of even trying
rs6000_expand_float128_convert.

Perhaps the conditions are too strict, and they could enable the use
of conversion insns involving __ieee128/_Float128 even with 64-bit
long doubles.  Alas, for now, we need this flag for the test to pass
on target variants that use 64-bit long doubles.

Tested on x86_64-linux-gnu x ppc64-vx7r2 with gcc-11.  Ok to install?


for  gcc/testsuite/ChangeLog

	* gcc.target/powerpr/pr79004.c: Add -mlong-double-128.
---
 gcc/testsuite/gcc.target/powerpc/pr79004.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr79004.c b/gcc/testsuite/gcc.target/powerpc/pr79004.c
index e411702dc98a9..061a0e83fe2ad 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr79004.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr79004.c
@@ -1,6 +1,6 @@
 /* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -mfloat128" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -mfloat128 -mlong-double-128" } */
 /* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 #include <math.h>


-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

Re: enable __ieee128 for p9vector tests

[Segher Boessenkool]

Hi!

On Sat, Apr 17, 2021 at 06:19:02AM -0300, Alexandre Oliva wrote:
> On Apr 12, 2021, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> > On Fri, Apr 02, 2021 at 01:52:59PM -0300, Alexandre Oliva wrote:
> >> Several compile tests that use the __ieee128 type do not ensure it is
> >> defined.  This patch adds -mfloat128 to their command lines, and
> >> disregards the warning that may be issued by it.
> 
> > But they do make sure it is defined, they use -mcpu=power9 (etc.).  What
> > is different in your setup that that does not work?
> 
> I suppose it's either -mno-altivec -mno-vsx in our self-specs,

Yes, that is a problem.  None of our testcases are set up for compilers
with weird defaults (and this is not specific to rs6000).

I do not want to change many thousands of test cases to not use defaults
anymore, to specify everything everywhere instead :-(  This would make
things more unmaintainable than they already are.

> or the very old default CPU.

powerpc-linux uses 603, introduced at the same time as 604 (in 1994),
which is what vxworks appears to use.  It has all the same features.

> I imagine it's also possible that the issue,
> initially observed with GCC 10, is different or absent with the trunk.
> 
> I started trying to figure out what led __ieee128 to not be enabled
> there, back then, but decided it was not so important, given that other
> tests used this flag explicitly, and that it wouldn't hurt to have it
> even if it wasn't always necessary.

GCC for PowerPC does not currently support IEEE QP float on CPUs without
VSX.  Other than that, it should work (but no doubt there still are
problems).


Segher

Re: enable __ieee128 for p9vector tests

[Segher Boessenkool]

On Wed, Apr 13, 2022 at 08:37:40PM -0300, Alexandre Oliva wrote:
> On Apr 17, 2021, Alexandre Oliva <oliva@adacore.com> wrote:
> > On Apr 12, 2021, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> My supposition was wrong.  It turned out to be just because in
> vxworks.h, for TARGET_VXWORKS7, there's:
> 
> #define TARGET_FLOAT128_ENABLE_TYPE 0

This is the default as well, so what vsworks.h does is a no-op.

> This disables TARGET_FLOAT128_TYPE by default, and causes the warning to
> be issued when -mfloat128 is explicitly enabled.
> 
> So ping https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567630.html

NAK on that patch, as explained upthread.

> upthread, and expect 3 new patches related with -mfloat128 momentarily.

Thanks,


Segher

Re: ppc: testsuite: bfp: enable float128 for __ieee128

[Segher Boessenkool]

On Wed, Apr 13, 2022 at 08:58:18PM -0300, Alexandre Oliva wrote:
> 
> Multiple bfp tests expect -mcpu=power[89] to enable the __ieee128
> type, but on targets that #define TARGET_FLOAT128_ENABLE_TYPE 0, that
> is not the case.  Since they are compile-time tests and effective
> target support for powerpc_p9vector_ok is required, adding -mfloat128
> is safe.  This patch does so, and arranges for the warning raised on
> such systems to be pruned.
> 
> Tested on x86_64-linux-gnu x ppc64-vx7r2 with gcc-11.  Ok to install?

Not okay.  We rely everywhere else on -mcpu=power9 (etc.) to enable VSX
just as well.

You should not change such defaults for your platform.


Segher

Re: enable __ieee128 for p9vector tests

[Alexandre Oliva]

On Apr 14, 2022, Segher Boessenkool <segher@kernel.crashing.org> wrote:

> Hi!
> On Sat, Apr 17, 2021 at 06:19:02AM -0300, Alexandre Oliva wrote:
>> On Apr 12, 2021, Segher Boessenkool <segher@kernel.crashing.org> wrote:
>> > On Fri, Apr 02, 2021 at 01:52:59PM -0300, Alexandre Oliva wrote:
>> >> Several compile tests that use the __ieee128 type do not ensure it is
>> >> defined.  This patch adds -mfloat128 to their command lines, and
>> >> disregards the warning that may be issued by it.
>> 
>> > But they do make sure it is defined, they use -mcpu=power9 (etc.).  What
>> > is different in your setup that that does not work?
>> 
>> I suppose it's either -mno-altivec -mno-vsx in our self-specs,

> Yes, that is a problem.

Sorry, that message from last year was an unfounded suspicion of mine
based on incorrect information.  Indeed, -mcpu=power9 combined with
-mno-vsx raise an error.

The relevant fact, described in yesterday's message, is that -mfloat128
is not enabled by default, even with -mcpu=power9, except on target
variants that define TARGET_FLOAT128_ENABLE_TYPE to nonzero.  As you
stated, its overall default is zero (though GNU/Linux overrides it to
nonzero), so the existing tests do not conform with the machine's
defaults in assuming -mfloat128 is enabled by -mcpu=power9.

Would you please reconsider your assessment, disregarding my incorrect
and irrelevant suspicions from last year, and instead taking the updated
and corrected information about float128 defaults into account?

Thanks,

>> or the very old default CPU.

> powerpc-linux uses 603, introduced at the same time as 604 (in 1994),
> which is what vxworks appears to use.  It has all the same features.

Yup, this was another incorrect suspicion of mine, based on another
piece of irrelevant information.

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

Re: enable __ieee128 for p9vector tests

[Segher Boessenkool]

On Thu, Apr 14, 2022 at 01:56:39PM -0300, Alexandre Oliva wrote:
> On Apr 14, 2022, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> > On Sat, Apr 17, 2021 at 06:19:02AM -0300, Alexandre Oliva wrote:
> >> On Apr 12, 2021, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> >> > On Fri, Apr 02, 2021 at 01:52:59PM -0300, Alexandre Oliva wrote:
> >> >> Several compile tests that use the __ieee128 type do not ensure it is
> >> >> defined.  This patch adds -mfloat128 to their command lines, and
> >> >> disregards the warning that may be issued by it.
> >> 
> >> > But they do make sure it is defined, they use -mcpu=power9 (etc.).  What
> >> > is different in your setup that that does not work?
> >> 
> >> I suppose it's either -mno-altivec -mno-vsx in our self-specs,
> 
> > Yes, that is a problem.
> 
> Sorry, that message from last year was an unfounded suspicion of mine
> based on incorrect information.  Indeed, -mcpu=power9 combined with
> -mno-vsx raise an error.

Lol, the dates line up very well, I didn't realise it was from 2021 :-)

> The relevant fact, described in yesterday's message, is that -mfloat128
> is not enabled by default, even with -mcpu=power9, except on target
> variants that define TARGET_FLOAT128_ENABLE_TYPE to nonzero.  As you
> stated, its overall default is zero (though GNU/Linux overrides it to
> nonzero), so the existing tests do not conform with the machine's
> defaults in assuming -mfloat128 is enabled by -mcpu=power9.

First off, vxworks.h should not disable it again.

Then, this needs to be fixed, indeed.  But that would be a code fix, not
a testsuite workaround.  If you use -mcpu=power9 it should support QP
float.


Segher

Re: enable __ieee128 for p9vector tests

[Alexandre Oliva]

On Apr 14, 2022, Segher Boessenkool <segher@kernel.crashing.org> wrote:

> Lol, the dates line up very well, I didn't realise it was from 2021 :-)

Heh, indeed.  Same testsuite results cleanup season, too ;-)

>> The relevant fact, described in yesterday's message, is that -mfloat128
>> is not enabled by default, even with -mcpu=power9, except on target
>> variants that define TARGET_FLOAT128_ENABLE_TYPE to nonzero.  As you
>> stated, its overall default is zero (though GNU/Linux overrides it to
>> nonzero), so the existing tests do not conform with the machine's
>> defaults in assuming -mfloat128 is enabled by -mcpu=power9.

> First off, vxworks.h should not disable it again.

Erhm...  I'm not sure what the 'it' is.

For abundance of clarity, we do *not* disable vsx when -mcpu=power9 is
given.  vsx is enabled for these tests.  But neither -mcpu=power9 nor
having vsx enabled are enough for the _Float128/_ieee128 type to be
defined.

The target-specific option that controls whether _Float128/_ieee128 is
defined when VSX is enabled is TARGET_FLOAT128_ENABLE_TYPE.  The only
file that defines it as nonzero is rs6000/linux64.h, which backs up the
comment in rs6000.cc before the statement that carries out this choice:

  /* Enable the default support for IEEE 128-bit floating point on
     [GNU/]Linux VSX sytems.  [...]  */
  TARGET_FLOAT128_TYPE = TARGET_FLOAT128_ENABLE_TYPE && TARGET_VSX;


So, if the 'it' refers to VSX, I reaffirm it's enabled as it should.
But if 'it' refers to TARGET_FLOAT128_ENABLE_TYPE, then it would seem
that you're saying that this is no longer a choice available to targets,
and that _Float128/_ieee128 are now mandatory when VSX is available.
That would be quite a departure from the current state.

Now, we are looking into the possibility of enabling _Float128/_ieee128
on ppc64-vx7r2, but keep in mind it's a nonfree system, so if system
libraries (or kernel) aren't up to it, that would be a blocker.  So I'd
prefer if both choices for TARGET_FLOAT128_ENABLE_TYPE remained
available.


> Then, this needs to be fixed, indeed.  But that would be a code fix, not
> a testsuite workaround.  If you use -mcpu=power9 it should support QP
> float.

I guess there's room for improvement indeed, especially in light of the
second patch for pr79004.c sent out ealier today, but I don't think I'd
risk such changes at this stage of development of gcc-12, let alone when
maintainer and implementation seem to me to disagree as to what the
expected behavior is :-(

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

[PATCH] ppc: testsuite: p9-vec-length: add -mno-strict-align and -misel (was: Re: enable __ieee128 for p9vector tests)

[Alexandre Oliva]

On Apr 14, 2022, Segher Boessenkool <segher@kernel.crashing.org> wrote:

> Yes, that is a problem.  None of our testcases are set up for compilers
> with weird defaults (and this is not specific to rs6000).

> I do not want to change many thousands of test cases to not use defaults
> anymore, to specify everything everywhere instead :-(  This would make
> things more unmaintainable than they already are.

I guess you're not going to like this one, then :-(

Our (AdaCore's) ppc64-vx7r2 builds have -mstrict-align and -mno-isel as
defaults, but several p9-vec-length* tests fail with those defaults.
Given your statement above, I'm not very hopeful that adding options to
make such expectations of the tests more explicit would be well
received, but at least the mailing list records will hold that
information, in case it happens to be useful for someone else.


The p9-vec-length tests expect vectorization on loop bodies and
epilogues that reference arrays that are not known to be more aligned
than their small element types.

Though VSX vectors work best with 32- or 64-bit alignment, unaligned
vector loads and stores are expected by the tests.  However, with our
implicit default to -mstrict-align, vector loads and stores not known
to be aligned end up open coded, which doesn't match the asm output
expectations coded in the tests.

Adding -mno-strict-align restores the unaligned vector loads and
stores, and this is enough for some of these tests to pass.

Some also require -misel, without which conditional stores end up open
coded into compares and branches.  That, in turn, makes some of the
epilogue blocks short enough that bbro duplicates them, so that
expected vector loads and stores with limited length diverge from the
expectation.

Restoring the defaults with both options, all of these tests pass
on x86_64-linux-gnu x ppc64-vx7r2.  Ok to install?

for  gcc/testsuite/ChangeLog

	* gcc.target/powerpc/p9-vec-length-epil-1.c: Add
	-mno-strict-align and -misel.
	* gcc.target/powerpc/p9-vec-length-epil-2.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-epil-3.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-epil-4.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-epil-5.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-epil-6.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-epil-7.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-epil-8.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-epil-run-1.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-epil-run-2.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-epil-run-3.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-epil-run-4.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-epil-run-5.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-epil-run-6.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-epil-run-7.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-epil-run-8.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-full-1.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-full-2.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-full-3.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-full-4.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-full-5.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-full-6.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-full-7.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-full-8.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-full-run-1.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-full-run-2.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-full-run-3.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-full-run-4.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-full-run-5.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-full-run-6.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-full-run-7.c: Likewise.
	* gcc.target/powerpc/p9-vec-length-full-run-8.c: Likewise.

TN: V413-044
---
 .../gcc.target/powerpc/p9-vec-length-epil-1.c      |    2 +-
 .../gcc.target/powerpc/p9-vec-length-epil-2.c      |    2 +-
 .../gcc.target/powerpc/p9-vec-length-epil-3.c      |    2 +-
 .../gcc.target/powerpc/p9-vec-length-epil-4.c      |    2 +-
 .../gcc.target/powerpc/p9-vec-length-epil-5.c      |    2 +-
 .../gcc.target/powerpc/p9-vec-length-epil-6.c      |    2 +-
 .../gcc.target/powerpc/p9-vec-length-epil-7.c      |    2 +-
 .../gcc.target/powerpc/p9-vec-length-epil-8.c      |    2 +-
 .../gcc.target/powerpc/p9-vec-length-epil-run-1.c  |    2 +-
 .../gcc.target/powerpc/p9-vec-length-epil-run-2.c  |    2 +-
 .../gcc.target/powerpc/p9-vec-length-epil-run-3.c  |    2 +-
 .../gcc.target/powerpc/p9-vec-length-epil-run-4.c  |    2 +-
 .../gcc.target/powerpc/p9-vec-length-epil-run-5.c  |    2 +-
 .../gcc.target/powerpc/p9-vec-length-epil-run-6.c  |    2 +-
 .../gcc.target/powerpc/p9-vec-length-epil-run-7.c  |    2 +-
 .../gcc.target/powerpc/p9-vec-length-epil-run-8.c  |    2 +-
 .../gcc.target/powerpc/p9-vec-length-full-1.c      |    2 +-
 .../gcc.target/powerpc/p9-vec-length-full-2.c      |    2 +-
 .../gcc.target/powerpc/p9-vec-length-full-3.c      |    2 +-
 .../gcc.target/powerpc/p9-vec-length-full-4.c      |    2 +-
 .../gcc.target/powerpc/p9-vec-length-full-5.c      |    2 +-
 .../gcc.target/powerpc/p9-vec-length-full-6.c      |    2 +-
 .../gcc.target/powerpc/p9-vec-length-full-7.c      |    2 +-
 .../gcc.target/powerpc/p9-vec-length-full-8.c      |    2 +-
 .../gcc.target/powerpc/p9-vec-length-full-run-1.c  |    2 +-
 .../gcc.target/powerpc/p9-vec-length-full-run-2.c  |    2 +-
 .../gcc.target/powerpc/p9-vec-length-full-run-3.c  |    2 +-
 .../gcc.target/powerpc/p9-vec-length-full-run-4.c  |    2 +-
 .../gcc.target/powerpc/p9-vec-length-full-run-5.c  |    2 +-
 .../gcc.target/powerpc/p9-vec-length-full-run-6.c  |    2 +-
 .../gcc.target/powerpc/p9-vec-length-full-run-7.c  |    2 +-
 .../gcc.target/powerpc/p9-vec-length-full-run-8.c  |    2 +-
 32 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-1.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-1.c
index d248f091b52ac..cd4ee3ff7eecd 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-1.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target { lp64 && powerpc_p9vector_ok } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=1" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-2.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-2.c
index 9f78a447ec7ae..77bf501d32aae 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-2.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-2.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target { lp64 && powerpc_p9vector_ok } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=1" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-3.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-3.c
index a08797fcbca48..f886d1bface73 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-3.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-3.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target { lp64 && powerpc_p9vector_ok } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=1" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-4.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-4.c
index ad051fb1cef92..c8cb6db6088ed 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-4.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-4.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target { lp64 && powerpc_p9vector_ok } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=1" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-5.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-5.c
index a24c30feeba19..de7e3f43bbfd8 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-5.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-5.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target { lp64 && powerpc_p9vector_ok } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=1" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-6.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-6.c
index 4eaeb3b005f1d..74e0539f53942 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-6.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-6.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target { lp64 && powerpc_p9vector_ok } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=1" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-7.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-7.c
index 011b731f7c5a0..a4be772d61122 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-7.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-7.c
@@ -1,7 +1,7 @@
 /* { dg-do compile { target { lp64 && powerpc_p9vector_ok } } } */
 /* Pass cunroll isn't disabled by -fno-unroll-loops, so use explicit
    disabling option for it.  */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops -ffast-math -fdisable-tree-cunroll" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops -ffast-math -fdisable-tree-cunroll -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=1" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-8.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-8.c
index 961df0d56469f..6c6974df06606 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-8.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-8.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target { lp64 && powerpc_p9vector_ok } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=1" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-1.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-1.c
index d1cd67f0c4d96..bb6381044e4ee 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-1.c
@@ -1,5 +1,5 @@
 /* { dg-do run { target { lp64 && p9vector_hw } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=1" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-2.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-2.c
index 815867b51d05d..96cce56e5026b 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-2.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-2.c
@@ -1,5 +1,5 @@
 /* { dg-do run { target { lp64 && p9vector_hw } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=1" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-3.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-3.c
index 5378d02c26975..1622682f9f533 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-3.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-3.c
@@ -1,5 +1,5 @@
 /* { dg-do run { target { lp64 && p9vector_hw } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=1" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-4.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-4.c
index daed9a7774ee0..19c2c5e69ad0d 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-4.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-4.c
@@ -1,5 +1,5 @@
 /* { dg-do run { target { lp64 && p9vector_hw } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=1" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-5.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-5.c
index b5f24e68d8461..41a9c4b932285 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-5.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-5.c
@@ -1,5 +1,5 @@
 /* { dg-do run { target { lp64 && p9vector_hw } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=1" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-6.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-6.c
index a3e6367384711..a867c9caa9c44 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-6.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-6.c
@@ -1,5 +1,5 @@
 /* { dg-do run { target { lp64 && p9vector_hw } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=1" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-7.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-7.c
index f0b69d462a19f..82306f4a23d5e 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-7.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-7.c
@@ -1,5 +1,5 @@
 /* { dg-do run { target { lp64 && p9vector_hw } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -ffast-math" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -ffast-math -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=1" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-8.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-8.c
index 84abecf3f692a..72d92f539210b 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-8.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-8.c
@@ -1,5 +1,5 @@
 /* { dg-do run { target { lp64 && p9vector_hw } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=1" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-1.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-1.c
index 3336752edbbf9..59a4e0485985d 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-1.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target { lp64 && powerpc_p9vector_ok } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=2" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-2.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-2.c
index 98abf8b33b1cf..eb44c6ced72dc 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-2.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-2.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target { lp64 && powerpc_p9vector_ok } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=2" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-3.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-3.c
index 0881d1a960aaf..3c6122ff9dd4d 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-3.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-3.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target { lp64 && powerpc_p9vector_ok } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=2" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-4.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-4.c
index 8ce3dc19a6097..4a8e477fe8703 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-4.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-4.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target { lp64 && powerpc_p9vector_ok } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=2" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-5.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-5.c
index f9f58ba11f5b9..560b9cd17d824 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-5.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-5.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target { lp64 && powerpc_p9vector_ok } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=2" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-6.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-6.c
index 5d2357aabfa57..c3a3ef321f69f 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-6.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-6.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target { lp64 && powerpc_p9vector_ok } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=2" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-7.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-7.c
index e0e51d9a9724c..3cd11ec0cbcd1 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-7.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-7.c
@@ -1,7 +1,7 @@
 /* { dg-do compile { target { lp64 && powerpc_p9vector_ok } } } */
 /* Pass cunroll isn't disabled by -fno-unroll-loops, so use explicit
    disabling option for it.  */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops -ffast-math -fdisable-tree-cunroll" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops -ffast-math -fdisable-tree-cunroll -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=2" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-8.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-8.c
index 1fc2af1e75381..20dd184ba33f4 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-8.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-8.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target { lp64 && powerpc_p9vector_ok } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -fno-unroll-loops -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=2" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-1.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-1.c
index 4e9bd0fbad303..c7a422f42462f 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-1.c
@@ -1,5 +1,5 @@
 /* { dg-do run { target { lp64 && p9vector_hw } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=2" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-2.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-2.c
index 8e06b1b9304a8..961db328172a1 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-2.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-2.c
@@ -1,5 +1,5 @@
 /* { dg-do run { target { lp64 && p9vector_hw } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=2" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-3.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-3.c
index 0b86f62834fb4..f36400b92dcd7 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-3.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-3.c
@@ -1,5 +1,5 @@
 /* { dg-do run { target { lp64 && p9vector_hw } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=2" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-4.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-4.c
index 359f31c9ed5ec..86ababa0caf5e 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-4.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-4.c
@@ -1,5 +1,5 @@
 /* { dg-do run { target { lp64 && p9vector_hw } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=2" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-5.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-5.c
index 7aa468e5b4e4b..f54abbfed6bcc 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-5.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-5.c
@@ -1,5 +1,5 @@
 /* { dg-do run { target { lp64 && p9vector_hw } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=2" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-6.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-6.c
index 53a2ad07fb324..084defeb545be 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-6.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-6.c
@@ -1,5 +1,5 @@
 /* { dg-do run { target { lp64 && p9vector_hw } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=2" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-7.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-7.c
index 0c21d137b9d58..53ba4a55ed47d 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-7.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-7.c
@@ -1,5 +1,5 @@
 /* { dg-do run { target { lp64 && p9vector_hw } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -ffast-math" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -ffast-math -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=2" } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-8.c b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-8.c
index 910784260677d..d02ea996b718e 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-8.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-run-8.c
@@ -1,5 +1,5 @@
 /* { dg-do run { target { lp64 && p9vector_hw } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize -fno-vect-cost-model -mno-strict-align -misel" } */
 
 /* { dg-additional-options "--param=vect-partial-vector-usage=2" } */
 



-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

[PATCH] ppc: testsuite: float128-hw{,4}.c need -mlong-double-128 (was: [PATCH] ppc: testsuite: pr79004 needs -mlong-double-128)

[Alexandre Oliva]

On Apr 14, 2022, Alexandre Oliva <oliva@adacore.com> wrote:

> 	* gcc.target/powerpr/pr79004.c: Add -mlong-double-128.

Just like pr79004, float128-hw.c requires -mlong-double-128 for some
the expected asm opcodes to be output on target variants that have
64-bit long doubles.  That's because their expanders,
e.g. floatsi<mode>2 for FLOAT128 modes, are conditioned on
TARGET_LONG_DOUBLE_128, which is not set on target variants that use
64-bit long double.

float128-hw4.c doesn't even compile without -mlong-double-128, on
64-bit long double target variants.  The error is "invalid parameter
combination for AltiVec intrinsic" in get_float128_exponent,
get_float128_mantissa, and set_float128_exponent_float128, presumably
caused by rs6000_builtin_type_compatible's refusal to consider
_Float128 compatible when TARGET_LONG_DOUBLE_128 is not set.

Since these are compile tests, -mlong-double-128 doesn't hurt even on
target variants that use 64-bit long double, and enables both tests to
pass.

Tested on x86_64-linux-gnu x ppc64-vx7r2 with gcc-11.  Ok to install?


for  gcc/testsuite/ChangeLog

	* gcc.target/powerpc/float128-hw.c: Add -mlong-double-128.
	* gcc.target/powerpc/float128-hw4.c: Likewise.
---
 gcc/testsuite/gcc.target/powerpc/float128-hw.c  |    2 +-
 gcc/testsuite/gcc.target/powerpc/float128-hw4.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/float128-hw.c b/gcc/testsuite/gcc.target/powerpc/float128-hw.c
index 8c9beafa90ad0..284d744c00978 100644
--- a/gcc/testsuite/gcc.target/powerpc/float128-hw.c
+++ b/gcc/testsuite/gcc.target/powerpc/float128-hw.c
@@ -1,7 +1,7 @@
 /* { dg-do compile { target lp64 } } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
 /* { dg-require-effective-target float128 } */
-/* { dg-options "-mpower9-vector -O2" } */
+/* { dg-options "-mpower9-vector -O2 -mlong-double-128" } */
 
 #ifndef TYPE
 #define TYPE _Float128
diff --git a/gcc/testsuite/gcc.target/powerpc/float128-hw4.c b/gcc/testsuite/gcc.target/powerpc/float128-hw4.c
index fc149169bc632..d86eadbcc7d06 100644
--- a/gcc/testsuite/gcc.target/powerpc/float128-hw4.c
+++ b/gcc/testsuite/gcc.target/powerpc/float128-hw4.c
@@ -1,7 +1,7 @@
 /* { dg-do compile { target lp64 } } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
 /* { dg-require-effective-target float128 } */
-/* { dg-options "-mpower9-vector -O2 -mabi=ieeelongdouble -Wno-psabi" } */
+/* { dg-options "-mpower9-vector -O2 -mlong-double-128 -mabi=ieeelongdouble -Wno-psabi" } */
 
 /* Insure that the ISA 3.0 IEEE 128-bit floating point built-in functions can
    be used with long double when the default is IEEE 128-bit.  */


-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

Re: [PATCH] ppc: testsuite: float128-hw{, 4}.c need -mlong-double-128 (was: [PATCH] ppc: testsuite: pr79004 needs -mlong-double-128)

[Segher Boessenkool]

Hi!

Please don't send patches as replies.

On Sat, Apr 23, 2022 at 10:33:35AM -0300, Alexandre Oliva wrote:
> On Apr 14, 2022, Alexandre Oliva <oliva@adacore.com> wrote:
> 
> > 	* gcc.target/powerpr/pr79004.c: Add -mlong-double-128.
> 
> Just like pr79004, float128-hw.c requires -mlong-double-128 for some
> the expected asm opcodes to be output on target variants that have
> 64-bit long doubles.  That's because their expanders,
> e.g. floatsi<mode>2 for FLOAT128 modes, are conditioned on
> TARGET_LONG_DOUBLE_128, which is not set on target variants that use
> 64-bit long double.
> 
> float128-hw4.c doesn't even compile without -mlong-double-128, on
> 64-bit long double target variants.  The error is "invalid parameter
> combination for AltiVec intrinsic" in get_float128_exponent,
> get_float128_mantissa, and set_float128_exponent_float128, presumably
> caused by rs6000_builtin_type_compatible's refusal to consider
> _Float128 compatible when TARGET_LONG_DOUBLE_128 is not set.
> 
> Since these are compile tests, -mlong-double-128 doesn't hurt even on
> target variants that use 64-bit long double, and enables both tests to
> pass.

This is not okay, sorry.  The testcase uses _Float128, what code that
generates should not depend on your long double setting.  Please file
a PR instead?


Segher

Re: [PATCH] ppc: testsuite: float128-hw{,4}.c need -mlong-double-128

[Alexandre Oliva]

On Apr 26, 2022, Segher Boessenkool <segher@kernel.crashing.org> wrote:

> The testcase uses _Float128, what code that
> generates should not depend on your long double setting.

Good, that means my hunch that it shouldn't is on the right track.

> Please file a PR instead?

I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105359 the other
day, how does that look?

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

Re: [PATCH] ppc: testsuite: pr79004 needs -mlong-double-128

[Alexandre Oliva]

On Apr 23, 2024, "Kewen.Lin" <linkw@linux.ibm.com> wrote:

> This patch seemed to miss to CC gcc-patches list. :)

Oops, sorry, thanks for catching that.

Here it is.  FTR, you've already responded suggesting an apparent
preference for addressing PR105359, but since I meant to contribute it,
I'm reposting is to gcc-patches, now with a reference to the PR.


ppc: testsuite: pr79004 needs -mlong-double-128

Some of the asm opcodes expected by pr79004 depend on
-mlong-double-128 to be output.  E.g., without this flag, the
conditions of patterns @extenddf<mode>2 and extendsf<mode>2 do not
hold, and so GCC resorts to libcalls instead of even trying
rs6000_expand_float128_convert.

Perhaps the conditions are too strict, and they could enable the use
of conversion insns involving __ieee128/_Float128 even with 64-bit
long doubles.  Alas, for now, we need this flag for the test to pass
on target variants that use 64-bit long doubles.


for  gcc/testsuite/ChangeLog

	* gcc.target/powerpr/pr79004.c: Add -mlong-double-128.
---
 gcc/testsuite/gcc.target/powerpc/pr79004.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr79004.c b/gcc/testsuite/gcc.target/powerpc/pr79004.c
index e411702dc98a9..061a0e83fe2ad 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr79004.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr79004.c
@@ -1,6 +1,6 @@
 /* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power9 -O2 -mfloat128" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -mfloat128 -mlong-double-128" } */
 /* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 #include <math.h>


-- 
Alexandre Oliva, happy hacker            https://FSFLA.org/blogs/lxo/
   Free Software Activist                   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

Re: [PATCH] ppc: testsuite: pr79004 needs -mlong-double-128

[Kewen.Lin]

Hi,

on 2024/4/28 16:20, Alexandre Oliva wrote:
> On Apr 23, 2024, "Kewen.Lin" <linkw@linux.ibm.com> wrote:
> 
>> This patch seemed to miss to CC gcc-patches list. :)
> 
> Oops, sorry, thanks for catching that.
> 
> Here it is.  FTR, you've already responded suggesting an apparent
> preference for addressing PR105359, but since I meant to contribute it,
> I'm reposting is to gcc-patches, now with a reference to the PR.

OK, from this perspective IMHO it seems more clear to adopt xfail
with effective target long_double_64bit?

BR,
Kewen

> 
> 
> ppc: testsuite: pr79004 needs -mlong-double-128
> 
> Some of the asm opcodes expected by pr79004 depend on
> -mlong-double-128 to be output.  E.g., without this flag, the
> conditions of patterns @extenddf<mode>2 and extendsf<mode>2 do not
> hold, and so GCC resorts to libcalls instead of even trying
> rs6000_expand_float128_convert.
> 
> Perhaps the conditions are too strict, and they could enable the use
> of conversion insns involving __ieee128/_Float128 even with 64-bit
> long doubles.  Alas, for now, we need this flag for the test to pass
> on target variants that use 64-bit long doubles.
> 
> 
> for  gcc/testsuite/ChangeLog
> 
> 	* gcc.target/powerpr/pr79004.c: Add -mlong-double-128.
> ---
>  gcc/testsuite/gcc.target/powerpc/pr79004.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr79004.c b/gcc/testsuite/gcc.target/powerpc/pr79004.c
> index e411702dc98a9..061a0e83fe2ad 100644
> --- a/gcc/testsuite/gcc.target/powerpc/pr79004.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr79004.c
> @@ -1,6 +1,6 @@
>  /* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
>  /* { dg-require-effective-target powerpc_p9vector_ok } */
> -/* { dg-options "-mdejagnu-cpu=power9 -O2 -mfloat128" } */
> +/* { dg-options "-mdejagnu-cpu=power9 -O2 -mfloat128 -mlong-double-128" } */
>  /* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
>  
>  #include <math.h>
> 
> 

Re: [PATCH] ppc: testsuite: pr79004 needs -mlong-double-128

[Alexandre Oliva]

On Apr 28, 2024, "Kewen.Lin" <linkw@linux.ibm.com> wrote:

> OK, from this perspective IMHO it seems more clear to adopt xfail
> with effective target long_double_64bit?

*nod*, yeah, that makes sense.

I'm going to travel this week, to speak at FSF's LibrePlanet conference,
so I'll look into massaging the patch into that when I get back, if you
haven't rendered it obsolete by then ;-)

Thanks,

-- 
Alexandre Oliva, happy hacker            https://FSFLA.org/blogs/lxo/
   Free Software Activist                   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

Re: [PATCH] ppc: testsuite: pr79004 needs -mlong-double-128

[Alexandre Oliva]

On Apr 28, 2024, "Kewen.Lin" <linkw@linux.ibm.com> wrote:

> OK, from this perspective IMHO it seems more clear to adopt xfail
> with effective target long_double_64bit?

That's effective target is quite broken, alas.  I doubt it's used
anywhere: it calls an undefined proc, and its memcmp call seems to have
the size cut&pasto-ed from the 128-bit functions.  (a patchlet that
fixes these most glaring issues is below)

Furthermore, it doesn't really work.  Since it adds -mlong-double-64 for
the effective target test, it overrides the default, so it sort of
always passes, even on a 128-bit long double target.  But since the test
itself doesn't add that option, any xfails on long_double_64bit would be
flagged as XPASS.

There's no effective target test for 64-bit long double that doesn't
override the default, so we'd have to add one.  Alas, the natural name
for it is the one that's taken with overriding behavior, and the current
option-overriding tests, that need to be used along with the
corresponding add-options in testcases, might benefit from a renaming to
make them fit the already-established (?) naming standards.  Yuck.


diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 182d80129de9b..603da25c97d67 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2961,12 +2961,12 @@ proc check_effective_target_long_double_64bit { } {
 	  /* eliminate removing volatile cast warning.  */
 	  a2 = a;
 	  b2 = b;
-	  if (memcmp (&a2, &b2, 16) != 0)
+	  if (memcmp (&a2, &b2, 8) != 0)
 	    return 1;
 	  sprintf (buffer, "%lg", b);
 	  return strcmp (buffer, "3") != 0;
 	}
-    }  [add_options_for_ppc_long_double_override_64bit ""]]
+    }  [add_options_for_long_double_64bit ""]]
 }
 
 # Return the appropriate options to specify that long double uses the IEEE


-- 
Alexandre Oliva, happy hacker            https://FSFLA.org/blogs/lxo/
   Free Software Activist                   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

Re: [PATCH] ppc: testsuite: pr79004 needs -mlong-double-128

[Kewen.Lin]

on 2024/4/29 15:20, Alexandre Oliva wrote:
> On Apr 28, 2024, "Kewen.Lin" <linkw@linux.ibm.com> wrote:
> 
>> OK, from this perspective IMHO it seems more clear to adopt xfail
>> with effective target long_double_64bit?
> 
> That's effective target is quite broken, alas.  I doubt it's used
> anywhere: it calls an undefined proc, and its memcmp call seems to have
> the size cut&pasto-ed from the 128-bit functions.  (a patchlet that
> fixes these most glaring issues is below)
> 
> Furthermore, it doesn't really work.  Since it adds -mlong-double-64 for
> the effective target test, it overrides the default, so it sort of
> always passes, even on a 128-bit long double target.  But since the test
> itself doesn't add that option, any xfails on long_double_64bit would be
> flagged as XPASS.
> 
> There's no effective target test for 64-bit long double that doesn't
> override the default, so we'd have to add one.  Alas, the natural name
> for it is the one that's taken with overriding behavior, and the current
> option-overriding tests, that need to be used along with the
> corresponding add-options in testcases, might benefit from a renaming to
> make them fit the already-established (?) naming standards.  Yuck.
> 

Oops, it's really out of my expectation, I just noticed that no test cases
are using this effective target and the commit r12-3151-g4c5d76a655b9ab
contributing this even doesn't adopt it.  Thanks for catching this and sorry
that I didn't check it before suggesting it, I think we can aggressively
drop this effective target instead to avoid any possible confusion.

CC Mike for this.

How about the generic one "longdouble64"?  I did a grep and found it has one
use, I'd expect it can work here. :)

gcc/testsuite//gcc.target/powerpc/pr99708.c:/* { dg-xfail-run-if "unsupported type __ibm128 with long-double-64" { longdouble64 } } */

BR,
Kewen

> 
> diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
> index 182d80129de9b..603da25c97d67 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -2961,12 +2961,12 @@ proc check_effective_target_long_double_64bit { } {
>  	  /* eliminate removing volatile cast warning.  */
>  	  a2 = a;
>  	  b2 = b;
> -	  if (memcmp (&a2, &b2, 16) != 0)
> +	  if (memcmp (&a2, &b2, 8) != 0)
>  	    return 1;
>  	  sprintf (buffer, "%lg", b);
>  	  return strcmp (buffer, "3") != 0;
>  	}
> -    }  [add_options_for_ppc_long_double_override_64bit ""]]
> +    }  [add_options_for_long_double_64bit ""]]
>  }
>  
>  # Return the appropriate options to specify that long double uses the IEEE
> 
> 

Re: [PATCH] ppc: testsuite: pr79004 needs -mlong-double-128

[Alexandre Oliva]

On Apr 29, 2024, "Kewen.Lin" <linkw@linux.ibm.com> wrote:

> Thanks for catching this and sorry
> that I didn't check it before suggesting it, I think we can aggressively
> drop this effective target instead to avoid any possible confusion.

The 128-bit ones, unfortunately, follow the same pattern but are
probably used.  IMHO we should transition all 3 to an '_ok' suffix, but...

> How about the generic one "longdouble64"?  I did a grep and found it has one
> use, I'd expect it can work here. :)

... since this and longdouble128 exist, maybe we can fix it and leave
them all alone, despite the interface oddity.

-- 
Alexandre Oliva, happy hacker            https://FSFLA.org/blogs/lxo/
   Free Software Activist                   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

Re: [PATCH] ppc: testsuite: pr79004 needs -mlong-double-128

[Kewen.Lin]

on 2024/4/30 07:11, Alexandre Oliva wrote:
> On Apr 29, 2024, "Kewen.Lin" <linkw@linux.ibm.com> wrote:
> 
>> Thanks for catching this and sorry
>> that I didn't check it before suggesting it, I think we can aggressively
>> drop this effective target instead to avoid any possible confusion.
> 
> The 128-bit ones, unfortunately, follow the same pattern but are
> probably used.  IMHO we should transition all 3 to an '_ok' suffix, but...
> 

Yeah, I noticed the 128-bit ones are used, I was just suggesting dropping
check_effective_target_long_double_64bit and add_options_for_long_double_64bit
as there is no user (since release 12 when it's introduced r12-3151), IMHO
there would be not any uses in future, ...

>> How about the generic one "longdouble64"?  I did a grep and found it has one
>> use, I'd expect it can work here. :)
> 
> ... since this and longdouble128 exist, maybe we can fix it and leave
> them all alone, despite the interface oddity.
> 
... personally I'm inclined to drop this 64 bit one. :)

BR,
Kewen

[PATCH v2] [testsuite] xfail pr79004 on longdouble64; drop long_double_64bit (was: ppc: testsuite: pr79004 needs -mlong-double-128)

[Alexandre Oliva]

On May  8, 2024, "Kewen.Lin" <linkw@linux.ibm.com> wrote:

>>> How about the generic one "longdouble64"?  I did a grep and found it has one
>>> use, I'd expect it can work here. :)
>> 
>> ... since this and longdouble128 exist, maybe we can fix it and leave
>> them all alone, despite the interface oddity.
>> 
> ... personally I'm inclined to drop this 64 bit one. :)

Some of the asm opcodes expected by pr79004 depend on
-mlong-double-128 to be output.  E.g., without this flag, the
conditions of patterns @extenddf<mode>2 and extendsf<mode>2 do not
hold, and so GCC resorts to libcalls instead of even trying
rs6000_expand_float128_convert.

Perhaps the conditions are too strict, and they could enable the use
of conversion insns involving __ieee128/_Float128 even with 64-bit
long doubles.

For now, xfail the opcodes that are not available on longdouble64.

While at that, drop long_double_64bit, since it's broken and sort of
redundant.

Regstrapped on x86_64-linux-gnu, also tested with gcc-13 on ppc64-vx7r2.
Ok to install?


for  gcc/testsuite/ChangeLog

	PR target/105359
	* gcc.target/powerpc/pr79004.c: Xfail opcodes not available on
	longdouble64.
	* lib/target-supports.exp
	(check_effective_target_long_double_64bit): Drop.
	(add_options_for_long_double_64bit): Likewise.
---
 gcc/testsuite/gcc.target/powerpc/pr79004.c |   14 +++++----
 gcc/testsuite/lib/target-supports.exp      |   43 ----------------------------
 2 files changed, 8 insertions(+), 49 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr79004.c b/gcc/testsuite/gcc.target/powerpc/pr79004.c
index caf1f6c1eefe4..2cb8bf4bc14bc 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr79004.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr79004.c
@@ -100,10 +100,12 @@ void to_uns_short_store_n (TYPE a, unsigned short *p, long n) { p[n] = (unsigned
 void to_uns_int_store_n (TYPE a, unsigned int *p, long n) { p[n] = (unsigned int)a; }
 void to_uns_long_store_n (TYPE a, unsigned long *p, long n) { p[n] = (unsigned long)a; }
 
-/* { dg-final { scan-assembler-not {\mbl __}       } } */
-/* { dg-final { scan-assembler     {\mxscvdpqp\M}  } } */
-/* { dg-final { scan-assembler     {\mxscvqpdp\M}  } } */
-/* { dg-final { scan-assembler     {\mxscvqpdpo\M} } } */
+/* On targets with 64-bit long double, some opcodes to deal with __float128 are
+   disabled, see PR target/105359.  */
+/* { dg-final { scan-assembler-not {\mbl __}       { xfail longdouble64 } } } */
+/* { dg-final { scan-assembler     {\mxscvdpqp\M}  { xfail longdouble64 } } } */
+/* { dg-final { scan-assembler     {\mxscvqpdp\M}  { xfail longdouble64 } } } */
+/* { dg-final { scan-assembler     {\mxscvqpdpo\M} { xfail longdouble64 } } } */
 /* { dg-final { scan-assembler     {\mxscvqpsdz\M} } } */
 /* { dg-final { scan-assembler     {\mxscvqpswz\M} } } */
 /* { dg-final { scan-assembler     {\mxscvsdqp\M}  } } */
@@ -111,7 +113,7 @@ void to_uns_long_store_n (TYPE a, unsigned long *p, long n) { p[n] = (unsigned l
 /* { dg-final { scan-assembler     {\mlxsd\M}      } } */
 /* { dg-final { scan-assembler     {\mlxsiwax\M}   } } */
 /* { dg-final { scan-assembler     {\mlxsiwzx\M}   } } */
-/* { dg-final { scan-assembler     {\mlxssp\M}     } } */
+/* { dg-final { scan-assembler     {\mlxssp\M}     { xfail longdouble64 } } } */
 /* { dg-final { scan-assembler     {\mstxsd\M}     } } */
 /* { dg-final { scan-assembler     {\mstxsiwx\M}   } } */
-/* { dg-final { scan-assembler     {\mstxssp\M}    } } */
+/* { dg-final { scan-assembler     {\mstxssp\M}    { xfail longdouble64 } } } */
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index ec9baa4f32a30..dc7d4f2b5f39e 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2930,49 +2930,6 @@ proc add_options_for_long_double_ieee128 { flags } {
     return "$flags"
 }
 
-# Check if GCC and GLIBC supports explicitly specifying that the long double
-# format uses the IEEE 64-bit.  Under little endian PowerPC Linux, you need
-# GLIBC 2.32 or later to be able to use a different long double format for
-# running a program than the system default.
-
-proc check_effective_target_long_double_64bit { } {
-    return [check_runtime_nocache long_double_64bit {
-	#include <string.h>
-	#include <stdio.h>
-	/* use volatile to prevent optimization.  */
-	volatile double a = 3.0;
-	volatile long double one = 1.0L;
-	volatile long double two = 2.0L;
-	volatile long double b;
-	char buffer[20];
-	int main()
-	{
-	  double a2;
-	  long double b2;
-	  if (sizeof (long double) != 8)
-	    return 1;
-	  b = one + two;
-	  /* eliminate removing volatile cast warning.  */
-	  a2 = a;
-	  b2 = b;
-	  if (memcmp (&a2, &b2, 16) != 0)
-	    return 1;
-	  sprintf (buffer, "%lg", b);
-	  return strcmp (buffer, "3") != 0;
-	}
-    }  [add_options_for_ppc_long_double_override_64bit ""]]
-}
-
-# Return the appropriate options to specify that long double uses the IEEE
-# 64-bit format on PowerPC.
-
-proc add_options_for_long_double_64bit { flags } {
-    if { [istarget powerpc*-*-*] } {
-	return "$flags -mlong-double-64"
-    }
-    return "$flags"
-}
-
 # Return 1 if the target supports executing VSX instructions, 0
 # otherwise.  Cache the result.
 

-- 
Alexandre Oliva, happy hacker            https://FSFLA.org/blogs/lxo/
   Free Software Activist                   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

Re: [PATCH v2] [testsuite] xfail pr79004 on longdouble64; drop long_double_64bit (was: ppc: testsuite: pr79004 needs -mlong-double-128)

[Kewen.Lin]

Hi,

on 2024/5/21 11:04, Alexandre Oliva wrote:
> On May  8, 2024, "Kewen.Lin" <linkw@linux.ibm.com> wrote:
> 
>>>> How about the generic one "longdouble64"?  I did a grep and found it has one
>>>> use, I'd expect it can work here. :)
>>>
>>> ... since this and longdouble128 exist, maybe we can fix it and leave
>>> them all alone, despite the interface oddity.
>>>
>> ... personally I'm inclined to drop this 64 bit one. :)
> 
> Some of the asm opcodes expected by pr79004 depend on
> -mlong-double-128 to be output.  E.g., without this flag, the
> conditions of patterns @extenddf<mode>2 and extendsf<mode>2 do not
> hold, and so GCC resorts to libcalls instead of even trying
> rs6000_expand_float128_convert.
> 
> Perhaps the conditions are too strict, and they could enable the use
> of conversion insns involving __ieee128/_Float128 even with 64-bit
> long doubles.
> 
> For now, xfail the opcodes that are not available on longdouble64.
> 
> While at that, drop long_double_64bit, since it's broken and sort of
> redundant.
> 
> Regstrapped on x86_64-linux-gnu, also tested with gcc-13 on ppc64-vx7r2.
> Ok to install?

OK for trunk, thanks!

BR,
Kewen

> 
> 
> for  gcc/testsuite/ChangeLog
> 
> 	PR target/105359
> 	* gcc.target/powerpc/pr79004.c: Xfail opcodes not available on
> 	longdouble64.
> 	* lib/target-supports.exp
> 	(check_effective_target_long_double_64bit): Drop.
> 	(add_options_for_long_double_64bit): Likewise.
> ---
>  gcc/testsuite/gcc.target/powerpc/pr79004.c |   14 +++++----
>  gcc/testsuite/lib/target-supports.exp      |   43 ----------------------------
>  2 files changed, 8 insertions(+), 49 deletions(-)
> 
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr79004.c b/gcc/testsuite/gcc.target/powerpc/pr79004.c
> index caf1f6c1eefe4..2cb8bf4bc14bc 100644
> --- a/gcc/testsuite/gcc.target/powerpc/pr79004.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr79004.c
> @@ -100,10 +100,12 @@ void to_uns_short_store_n (TYPE a, unsigned short *p, long n) { p[n] = (unsigned
>  void to_uns_int_store_n (TYPE a, unsigned int *p, long n) { p[n] = (unsigned int)a; }
>  void to_uns_long_store_n (TYPE a, unsigned long *p, long n) { p[n] = (unsigned long)a; }
>  
> -/* { dg-final { scan-assembler-not {\mbl __}       } } */
> -/* { dg-final { scan-assembler     {\mxscvdpqp\M}  } } */
> -/* { dg-final { scan-assembler     {\mxscvqpdp\M}  } } */
> -/* { dg-final { scan-assembler     {\mxscvqpdpo\M} } } */
> +/* On targets with 64-bit long double, some opcodes to deal with __float128 are
> +   disabled, see PR target/105359.  */
> +/* { dg-final { scan-assembler-not {\mbl __}       { xfail longdouble64 } } } */
> +/* { dg-final { scan-assembler     {\mxscvdpqp\M}  { xfail longdouble64 } } } */
> +/* { dg-final { scan-assembler     {\mxscvqpdp\M}  { xfail longdouble64 } } } */
> +/* { dg-final { scan-assembler     {\mxscvqpdpo\M} { xfail longdouble64 } } } */
>  /* { dg-final { scan-assembler     {\mxscvqpsdz\M} } } */
>  /* { dg-final { scan-assembler     {\mxscvqpswz\M} } } */
>  /* { dg-final { scan-assembler     {\mxscvsdqp\M}  } } */
> @@ -111,7 +113,7 @@ void to_uns_long_store_n (TYPE a, unsigned long *p, long n) { p[n] = (unsigned l
>  /* { dg-final { scan-assembler     {\mlxsd\M}      } } */
>  /* { dg-final { scan-assembler     {\mlxsiwax\M}   } } */
>  /* { dg-final { scan-assembler     {\mlxsiwzx\M}   } } */
> -/* { dg-final { scan-assembler     {\mlxssp\M}     } } */
> +/* { dg-final { scan-assembler     {\mlxssp\M}     { xfail longdouble64 } } } */
>  /* { dg-final { scan-assembler     {\mstxsd\M}     } } */
>  /* { dg-final { scan-assembler     {\mstxsiwx\M}   } } */
> -/* { dg-final { scan-assembler     {\mstxssp\M}    } } */
> +/* { dg-final { scan-assembler     {\mstxssp\M}    { xfail longdouble64 } } } */
> diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
> index ec9baa4f32a30..dc7d4f2b5f39e 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -2930,49 +2930,6 @@ proc add_options_for_long_double_ieee128 { flags } {
>      return "$flags"
>  }
>  
> -# Check if GCC and GLIBC supports explicitly specifying that the long double
> -# format uses the IEEE 64-bit.  Under little endian PowerPC Linux, you need
> -# GLIBC 2.32 or later to be able to use a different long double format for
> -# running a program than the system default.
> -
> -proc check_effective_target_long_double_64bit { } {
> -    return [check_runtime_nocache long_double_64bit {
> -	#include <string.h>
> -	#include <stdio.h>
> -	/* use volatile to prevent optimization.  */
> -	volatile double a = 3.0;
> -	volatile long double one = 1.0L;
> -	volatile long double two = 2.0L;
> -	volatile long double b;
> -	char buffer[20];
> -	int main()
> -	{
> -	  double a2;
> -	  long double b2;
> -	  if (sizeof (long double) != 8)
> -	    return 1;
> -	  b = one + two;
> -	  /* eliminate removing volatile cast warning.  */
> -	  a2 = a;
> -	  b2 = b;
> -	  if (memcmp (&a2, &b2, 16) != 0)
> -	    return 1;
> -	  sprintf (buffer, "%lg", b);
> -	  return strcmp (buffer, "3") != 0;
> -	}
> -    }  [add_options_for_ppc_long_double_override_64bit ""]]
> -}
> -
> -# Return the appropriate options to specify that long double uses the IEEE
> -# 64-bit format on PowerPC.
> -
> -proc add_options_for_long_double_64bit { flags } {
> -    if { [istarget powerpc*-*-*] } {
> -	return "$flags -mlong-double-64"
> -    }
> -    return "$flags"
> -}
> -
>  # Return 1 if the target supports executing VSX instructions, 0
>  # otherwise.  Cache the result.
>  
>