Re: [PATCH] testsuite: Disable finate math only for test [PR115826]
On Mon, 15 Jul 2024, Torbjörn SVENSSON wrote:
> As the test case requires +-Inf and NaN to work and -ffast-math is added
> by default for arm-none-eabi, re-enable non-finite math.
Isn't
/* { dg-add-options ieee } */
the canonical way to handle CPU/testsuite defaults?
> gcc/testsuite/ChangeLog:
>
> PR testsuite/115826
> * gcc.dg/vect/tsvc/vect-tsvc-s1281.c: Use -fno-finite-math-only.
>
> Signed-off-by: Torbjörn SVENSSON
> ---
> gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1281.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1281.c
> b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1281.c
> index dba95a81973..3e619a3fa5a 100644
> --- a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1281.c
> +++ b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1281.c
> @@ -4,6 +4,9 @@
> /* { dg-additional-options "--param vect-epilogues-nomask=0" } */
> /* { dg-require-effective-target vect_float } */
>
> +/* This test requires +-Inf and NaN, so disable finite-math-only */
> +/* { dg-additional-options "-fno-finite-math-only" } */
> +
> #include "tsvc.h"
>
> real_t s1281(struct args_t * func_args)
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
[PATCH] testsuite: Disable finate math only for test [PR115826]
As the test case requires +-Inf and NaN to work and -ffast-math is added
by default for arm-none-eabi, re-enable non-finite math.
gcc/testsuite/ChangeLog:
PR testsuite/115826
* gcc.dg/vect/tsvc/vect-tsvc-s1281.c: Use -fno-finite-math-only.
Signed-off-by: Torbjörn SVENSSON
---
gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1281.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1281.c
b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1281.c
index dba95a81973..3e619a3fa5a 100644
--- a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1281.c
+++ b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1281.c
@@ -4,6 +4,9 @@
/* { dg-additional-options "--param vect-epilogues-nomask=0" } */
/* { dg-require-effective-target vect_float } */
+/* This test requires +-Inf and NaN, so disable finite-math-only */
+/* { dg-additional-options "-fno-finite-math-only" } */
+
#include "tsvc.h"
real_t s1281(struct args_t * func_args)
--
2.25.1
[committed] libstdc++: Disable expensive test for debug mode [PR108636]
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This test uses -fkeep-inline-functions and with debug mode enabled that
compiles much slower and times out if the system is under heavy load.
The original problem being tested is independent of debug mode, so just
require normal mode for the test.
libstdc++-v3/ChangeLog:
PR libstdc++/108636
* testsuite/27_io/filesystem/path/108636.cc: Require normal
mode.
---
libstdc++-v3/testsuite/27_io/filesystem/path/108636.cc | 1 +
1 file changed, 1 insertion(+)
diff --git a/libstdc++-v3/testsuite/27_io/filesystem/path/108636.cc
b/libstdc++-v3/testsuite/27_io/filesystem/path/108636.cc
index 73742df93b0..48435525d36 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/path/108636.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/path/108636.cc
@@ -1,6 +1,7 @@
// { dg-do link { target c++17 } }
// { dg-options "-fkeep-inline-functions" }
// { dg-require-filesystem-ts "" }
+// { dg-require-normal-mode "too slow with debug mode" }
#include
int main()
--
2.45.2
Re: [PATCH 10/10] autovectorizer: Test autovectorization of different dot-prod modes.
On Thu, Jul 11, 2024 at 9:03 AM Tamar Christina wrote:
>
> Hi Victor,
>
> > -Original Message-
> > From: Victor Do Nascimento
> > Sent: Wednesday, July 10, 2024 3:06 PM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Richard Sandiford ; Richard Earnshaw
> > ; Victor Do Nascimento
> >
> > Subject: [PATCH 10/10] autovectorizer: Test autovectorization of different
> > dot-
> > prod modes.
> >
> > From: Victor Do Nascimento
> >
> > Given the novel treatment of the dot product optab as a conversion we
> > are now able to target, for a given architecture, different
> > relationships between output modes and input modes.
> >
> > This is made clearer by way of example. Previously, on AArch64, the
> > following loop was vectorizable:
> >
> > uint32_t udot4(int n, uint8_t* data) {
> > uint32_t sum = 0;
> > for (int i=0; i > sum += data[i] * data[i];
> > return sum;
> > }
> >
> > while the following wasn't:
> >
> > uint32_t udot2(int n, uint16_t* data) {
> > uint32_t sum = 0;
> > for (int i=0; i > sum += data[i] * data[i];
> > return sum;
> > }
> >
> > Under the new treatment of the dot product optab, they are both now
> > vectorizable.
> >
> > This adds the relevant target-agnostic check to ensure this behaviour
> > in the autovectorizer.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.dg/vect/vect-dotprod-twoway.c: New.
> > ---
> > .../gcc.dg/vect/vect-dotprod-twoway.c | 38 +++
> > 1 file changed, 38 insertions(+)
> > create mode 100644 gcc/testsuite/gcc.dg/vect/vect-dotprod-twoway.c
> >
> > diff --git a/gcc/testsuite/gcc.dg/vect/vect-dotprod-twoway.c
> > b/gcc/testsuite/gcc.dg/vect/vect-dotprod-twoway.c
> > new file mode 100644
> > index 000..5caa7b81fce
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/vect/vect-dotprod-twoway.c
> > @@ -0,0 +1,38 @@
> > +/* { dg-do compile } */
> > +/* { dg-require-effective-target vect_int } */
> > +/* Ensure both the two-way and four-way dot products are autovectorized.
> > */
> > +#include
> > +
> > +uint32_t udot4(int n, uint8_t* data) {
> > + uint32_t sum = 0;
> > + for (int i=0; i > +sum += data[i] * data[i];
> > + }
> > + return sum;
> > +}
> > +
> > +int32_t sdot4(int n, int8_t* data) {
> > + int32_t sum = 0;
> > + for (int i=0; i > +sum += data[i] * data[i];
> > + }
> > + return sum;
> > +}
> > +
> > +uint32_t udot2(int n, uint16_t* data) {
> > + uint32_t sum = 0;
> > + for (int i=0; i > +sum += data[i] * data[i];
> > + }
> > + return sum;
> > +}
> > +
> > +int32_t sdot2(int n, int16_t* data) {
> > + int32_t sum = 0;
> > + for (int i=0; i > +sum += data[i] * data[i];
> > + }
> > + return sum;
> > +}
> > +
> > +/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 4 "vect" } } */
>
> These tests only test that you have vectorized the loops, not that the loop
> was vectorized
> using dotprod. I think you want to have a scan for DOT_PROD_EXPR as well,
> gated to the
> targets that support two-way dot prod.
Ideally they'd also verify correctness, thus make them have runtime checks.
> Cheers,
> Tamar
>
> > --
> > 2.34.1
>
RE: [PATCH 10/10] autovectorizer: Test autovectorization of different dot-prod modes.
Hi Victor,
> -Original Message-
> From: Victor Do Nascimento
> Sent: Wednesday, July 10, 2024 3:06 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Sandiford ; Richard Earnshaw
> ; Victor Do Nascimento
>
> Subject: [PATCH 10/10] autovectorizer: Test autovectorization of different
> dot-
> prod modes.
>
> From: Victor Do Nascimento
>
> Given the novel treatment of the dot product optab as a conversion we
> are now able to target, for a given architecture, different
> relationships between output modes and input modes.
>
> This is made clearer by way of example. Previously, on AArch64, the
> following loop was vectorizable:
>
> uint32_t udot4(int n, uint8_t* data) {
> uint32_t sum = 0;
> for (int i=0; i sum += data[i] * data[i];
> return sum;
> }
>
> while the following wasn't:
>
> uint32_t udot2(int n, uint16_t* data) {
> uint32_t sum = 0;
> for (int i=0; i sum += data[i] * data[i];
> return sum;
> }
>
> Under the new treatment of the dot product optab, they are both now
> vectorizable.
>
> This adds the relevant target-agnostic check to ensure this behaviour
> in the autovectorizer.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/vect/vect-dotprod-twoway.c: New.
> ---
> .../gcc.dg/vect/vect-dotprod-twoway.c | 38 +++
> 1 file changed, 38 insertions(+)
> create mode 100644 gcc/testsuite/gcc.dg/vect/vect-dotprod-twoway.c
>
> diff --git a/gcc/testsuite/gcc.dg/vect/vect-dotprod-twoway.c
> b/gcc/testsuite/gcc.dg/vect/vect-dotprod-twoway.c
> new file mode 100644
> index 000..5caa7b81fce
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/vect/vect-dotprod-twoway.c
> @@ -0,0 +1,38 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target vect_int } */
> +/* Ensure both the two-way and four-way dot products are autovectorized. */
> +#include
> +
> +uint32_t udot4(int n, uint8_t* data) {
> + uint32_t sum = 0;
> + for (int i=0; i +sum += data[i] * data[i];
> + }
> + return sum;
> +}
> +
> +int32_t sdot4(int n, int8_t* data) {
> + int32_t sum = 0;
> + for (int i=0; i +sum += data[i] * data[i];
> + }
> + return sum;
> +}
> +
> +uint32_t udot2(int n, uint16_t* data) {
> + uint32_t sum = 0;
> + for (int i=0; i +sum += data[i] * data[i];
> + }
> + return sum;
> +}
> +
> +int32_t sdot2(int n, int16_t* data) {
> + int32_t sum = 0;
> + for (int i=0; i +sum += data[i] * data[i];
> + }
> + return sum;
> +}
> +
> +/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 4 "vect" } } */
These tests only test that you have vectorized the loops, not that the loop was
vectorized
using dotprod. I think you want to have a scan for DOT_PROD_EXPR as well,
gated to the
targets that support two-way dot prod.
Cheers,
Tamar
> --
> 2.34.1
Re: [r15-1936 Regression] FAIL: gcc.target/i386/avx512vl-vpmovuswb-2.c execution test on Linux/x86_64
On Wed, Jul 10, 2024 at 3:42 PM haochen.jiang wrote: > > On Linux/x86_64, > > 80e446e829d818dc19daa6e671b9626e93ee4949 is the first bad commit > commit 80e446e829d818dc19daa6e671b9626e93ee4949 > Author: Pan Li > Date: Fri Jul 5 20:36:35 2024 +0800 > > Match: Support form 2 for the .SAT_TRUNC > > caused > > FAIL: gcc.target/i386/avx512f-vpmovusqb-2.c execution test > FAIL: gcc.target/i386/avx512vl-vpmovusdb-2.c execution test > FAIL: gcc.target/i386/avx512vl-vpmovusdw-2.c execution test > FAIL: gcc.target/i386/avx512vl-vpmovusqb-2.c execution test > FAIL: gcc.target/i386/avx512vl-vpmovusqd-2.c execution test > FAIL: gcc.target/i386/avx512vl-vpmovusqw-2.c execution test > FAIL: gcc.target/i386/avx512vl-vpmovuswb-2.c execution test This is fixed by [1]. The consequence of a last-minute "impossible-to-fail-so-no-need-to-test" change. Lesson learned. [1] https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656898.html Uros.
[PATCH 10/10] autovectorizer: Test autovectorization of different dot-prod modes.
From: Victor Do Nascimento
Given the novel treatment of the dot product optab as a conversion we
are now able to target, for a given architecture, different
relationships between output modes and input modes.
This is made clearer by way of example. Previously, on AArch64, the
following loop was vectorizable:
uint32_t udot4(int n, uint8_t* data) {
uint32_t sum = 0;
for (int i=0; i
+
+uint32_t udot4(int n, uint8_t* data) {
+ uint32_t sum = 0;
+ for (int i=0; i
[r15-1936 Regression] FAIL: gcc.target/i386/avx512vl-vpmovuswb-2.c execution test on Linux/x86_64
On Linux/x86_64,
80e446e829d818dc19daa6e671b9626e93ee4949 is the first bad commit
commit 80e446e829d818dc19daa6e671b9626e93ee4949
Author: Pan Li
Date: Fri Jul 5 20:36:35 2024 +0800
Match: Support form 2 for the .SAT_TRUNC
caused
FAIL: gcc.target/i386/avx512f-vpmovusqb-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpmovusdb-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpmovusdw-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpmovusqb-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpmovusqd-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpmovusqw-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpmovuswb-2.c execution test
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-1936/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512f-vpmovusqb-2.c
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512f-vpmovusqb-2.c
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vpmovusdb-2.c
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vpmovusdb-2.c
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vpmovusdb-2.c
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vpmovusdb-2.c
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vpmovusdw-2.c
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vpmovusdw-2.c
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vpmovusdw-2.c
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vpmovusdw-2.c
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vpmovusqb-2.c
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vpmovusqb-2.c
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vpmovusqd-2.c
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vpmovusqd-2.c
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vpmovusqw-2.c
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vpmovusqw-2.c
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vpmovuswb-2.c
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vpmovuswb-2.c
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vpmovuswb-2.c
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512vl-vpmovuswb-2.c
--target_board='unix{-m64\ -march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at haochen dot jiang at intel.com.)
(If you met problems with cascadelake related, disabling AVX512F in command
line might save that.)
(However, please make sure that there is no potential problems with AVX512.)
Re: [PATCH] Fix test errors introduced with fix for PR115157
Am Dienstag, dem 09.07.2024 um 19:11 -0300 schrieb Thiago Jung Bauermann: > Hello Martin, > > Martin Uecker writes: > > > BTW: Did you try the other testsuite patch as well? > > > > [PATCH] Fix test errors after r15-1394 for sizeof(int)==sizeof(long) > > [PR115545] > > I hadn't, but I did today and the patch is good from our CI's > perspective. I replied directly to its email thread. Thank you!
Re: [PATCH] Fix test errors introduced with fix for PR115157
Hello Martin, Martin Uecker writes: > BTW: Did you try the other testsuite patch as well? > > [PATCH] Fix test errors after r15-1394 for sizeof(int)==sizeof(long) > [PR115545] I hadn't, but I did today and the patch is good from our CI's perspective. I replied directly to its email thread. -- Thiago
Re: [PATCH] Fix test errors after r15-1394 for sizeof(int)==sizeof(long) [PR115545]
Hello, Martin Uecker writes: > This fixes the test failures introduced by the fix for PR115109. > > Tested on x86_64 and also tested with -m32. > > > > Fix test errors after r15-1394 for sizeof(int)==sizeof(long) [PR115545] > > Some tests added to test the type of redeclarations of enumerators > in r15-1394 fail on architectures where sizeof(long) == sizeof(int). > Adapt tests to use long long and/or accept that long long is selected > as type for the enumerator. > > gcc/testsuite/Changelog: > PR testsuite/115545 > * gcc.dg/pr115109.c: Adapt test. > * gcc.dg/c23-tag-enum-6.c: Adapt test. > * gcc.dg/c23-tag-enum-7.c: Adapt test. I manually triggered a couple of our CI loops testing bare-metal arm-eabi, and this patch doesn't introduce any regressions and fixes the following failures: Running gcc:gcc.dg/dg.exp ... FAIL: gcc.dg/c23-tag-enum-6.c (test for errors, line 10) FAIL: gcc.dg/c23-tag-enum-6.c (test for errors, line 13) FAIL: gcc.dg/c23-tag-enum-7.c (test for excess errors) FAIL: gcc.dg/pr115109.c (test for excess errors) Thanks! -- Thiago
Re: [PATCH] Fix test errors after r15-1394 for sizeof(int)==sizeof(long) [PR115545]
On Sun, 23 Jun 2024, Martin Uecker wrote: > This fixes the test failures introduced by the fix for PR115109. > > Tested on x86_64 and also tested with -m32. > > > > Fix test errors after r15-1394 for sizeof(int)==sizeof(long) [PR115545] > > Some tests added to test the type of redeclarations of enumerators > in r15-1394 fail on architectures where sizeof(long) == sizeof(int). > Adapt tests to use long long and/or accept that long long is selected > as type for the enumerator. > > gcc/testsuite/Changelog: > PR testsuite/115545 > * gcc.dg/pr115109.c: Adapt test. > * gcc.dg/c23-tag-enum-6.c: Adapt test. > * gcc.dg/c23-tag-enum-7.c: Adapt test. OK. -- Joseph S. Myers josmy...@redhat.com
Re: [PING^2] [PATCH 00/11] AArch64/OpenMP: Test SVE ACLE types with various OpenMP constructs.
Ping^2 on the series please. Thanks, Tejas. On 5/27/24 10:36 AM, Tejas Belagod wrote: Note: This patch series is based on Richard's initial patch https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606741.html and Jakub's suggestion https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611892.html The following patch series handles various scenarios with OpenMP and SVE types. The starting point for the series follows a suggestion from Jakub to cover all the possible scenarios that could arise when OMP constructs/clauses etc are used with SVE ACLE types. Here are a few instances that this patch series tests and in some cases fixes the expected output. This patch series does not follow a formal definition or a spec of how OMP interacts with SVE ACLE types, so it's more of a proposed behaviour. Comments and discussion welcome. This list is not exhaustive, but covers most scenarios of how SVE ACLE types ought to interact with OMP constructs/clauses. 1. Poly-int structures that represent variable-sized objects and OMP runtime. Currently poly-int type structures are passed by value to OpenMP runtime functions for shared clauses etc. This patch improves on this by passing around poly-int structures by address to avoid copy-overhead. 2. SVE ACLE types in OMP Shared clauses. We test the behaviour where SVE ACLE type objects are shared in the following methods into an OMP region: a. Explicit Shared clause on SVE ACLE type objects. b. Implicit shared clause. c. Implicit shared with default clause. d. SVE ALCE types in the presence of predetermined (static) shared objects. The associated tests ensure that all such shared objects are passed by address into the OMP runtime. There are runtime tests to verify the functional correctness of the change. 3. Offloading and SVE ACLE types. The target clause in OpenMP is used to offload loop kernels to accelerator peripeherals. target's 'map' clause is used to move data from and to the accelarator. When the data is SVE type, it may not be suitable because of various reasons i.e. the two SVE targets may not agree on vector size or some targets don't support variable vector size. This makes SVE unsuitable for use in OMP's 'map' clause. We diagnose all such cases and issue errors where appropriate. The cases we cover in this patch are: a. Implicitly-mapped SVE ACLE types in OMP target regions are diagnosed. b. Explicitly-mapped SVE ACLE types in OMP target regions using map clause are diagnosed. c. Explicilty-mapped SVLE ACLE types of various directions - to, from, tofrom in the map clause are diagnosed. d. target enter and exit data clauses with map on SVE ACLE types are diagnosed. e. target data map with alloc on SVE ACLE types are diagnosed. f. target update from clause on SVE ACLE types are diagnosed. g. target private firstprivate with SVE ACLE types are diagnosed. h. All combinations of target with work-sharing constructs like parallel, loop, simd, teams, distribute etc are also diagnosed when SVE ACLE types are involved. 3. Lastprivate and SVE ACLE types. Various OpenMP lastprivate clause scenarios with SVE object types are diagnosed. Worksharing constructs like sections, for, distribute bind to an implicit outer parallel region in whose scope SVE ACLE types are declared and are therefore default private. The lastprivate clause list with SVE ACLE type object items are diagnosed in this scenario. 4. Threadprivate on SVE ACLE type objects. We ensure threadprivate SVE ACLE type objects are supported. We also ensure copyin clause is also supported. 5. User-Defined Reductions on SVE ACLE types. We define a reduction using OMP declare reduction using SVE ACLE intrinsics and ensure its functional correctness with various work-sharing constructs like for, simd, parallel, task, taskloop. 6. Uniform and Aligned Clause with SVE ACLE We ensure the uniform clause's functional correctness with simd construct and associated SVE ACLE intrinsics in the simd region. There is no direct interaction between uniform and SVE ACLE type objects, but we ensure the uniform clause applies correctly to a region where SVE ACLE intrinsics are present. Similarly for the aligned clause. 7. Linear clause and SVE ACLE type. We diagnose if a linear clause list item has SVE ACLE type objects present. Its doesn't mean much if the linear clause is applied to SVE ACLE types. 8. Depend clause and SVE ACLE objects. We test for functional correctness many combinations of dependency of shared SVE ACLE type objects in parallel regions. We test if in, out dependencies and anti-dependencies are supported for SVE ACLE type objects using the depend clause with work-sharing constructs like task. 9. 'doacross' clause and SVE ACLE object types. doacross is mainly supported for scalars and loop iteration variables. We diagnose cases where SVE ACLE objects are used in doacross list items. Tejas Belagod (11
Re: [PATCH] Fix test errors introduced with fix for PR115157
Am Montag, dem 01.07.2024 um 14:29 -0300 schrieb Thiago Jung Bauermann: > Hello Martin, > > Martin Uecker writes: > > > This should fix the test failures introduced by the fix for PR115157. > > > > Tested on x86_64 and also tested with -m32. > > > > > > Fix test errors introduced with fix for PR115157. > > > > Fix tests introduced when fixing PR115157 that assume > > sizeof(enum)==sizeof(int) > > by adding the flag -fno-short-enums. > > > > gcc/testsuite/Changelog: > > * gcc.dg/enum-alias-1.c: Add flag. > > * gcc.dg/enum-alias-2.c: Add flag. > > * gcc.dg/enum-alias-3.c: Add flag. > > * gcc.dg/enum-alias-4.c: Add flag. > > Thank you for the patch! It fixes the execution test failures but > unfortunately they still have excess errors failures due to an > unexpected linker warning: > > spawn -ignore SIGHUP > /home/tcwg-build/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/bin/arm-eabi-gcc > > /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.dg/enum-alias-1.c > -fdiagnostics-plain-output -O2 -fno-short-enums -specs=rdimon.specs -lm -o > ./enum-alias-1.exe > /home/tcwg-build/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/lib/gcc/arm-eabi/15.0.0/../../../../arm-eabi/bin/ld: > warning: /tmp/ccP9AJZd.o uses 32-bit enums yet the output is to use > variable-size enums; use of enum values across objects may fail > ⋮ > FAIL: gcc.dg/enum-alias-1.c (test for excess errors) > Excess errors: > /home/tcwg-build/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/lib/gcc/arm-eabi/15.0.0/../../../../arm-eabi/bin/ld: > warning: /tmp/ccP9AJZd.o uses 32-bit enums yet the output is to use > variable-size enums; use of enum values across objects may fail > > The same happens with gcc.dg/enum-alias-[234].c. Thank you! BTW: Did you try the other testsuite patch as well? [PATCH] Fix test errors after r15-1394 for sizeof(int)==sizeof(long) [PR115545] Best, Martin >
[PATCH, pushed] Fortran: switch test to use issignaling() built-in
Pushed after testing on x86_64-unknown-linux-gnu. The macro may not be present in all libc's, but the built-in is always available. See https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656409.html for context. gcc/testsuite/ChangeLog: * gfortran.dg/ieee/signaling_2.f90: Adjust test. * gfortran.dg/ieee/signaling_2_c.c: Adjust test. 0001-Fortran-switch-test-to-use-issignaling-built-in.patch Description: Binary data
[committed][RISC-V] Fix test expectations after recent late-combine changes
With the recent DCE related adjustment to late-combine the
rvv/base/vcreate.c test no longer has those undesirable vmvNr statements.
It's a bit unclear why this wasn't written as a scan-assembler-not and
xfailed given the comment says we don't want to see vmvNr insructions.
I must have missed that during review.
This patch adjusts the test to expect no vmvNr statements and if they're
ever re-introduced, we'll get a nice unexpected failure.
Pushing to the trunk.
Jeff
gcc/testsuite
* gcc.target/riscv/rvv/base/vcreate.c: Update expected output.
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/vcreate.c
b/gcc/testsuite/gcc.target/riscv/rvv/base/vcreate.c
index 01006de7c81..1c7c154637e 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/vcreate.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/vcreate.c
@@ -256,6 +256,6 @@ test_vcreate_v_i64m2x4 (vint64m2_t v0, vint64m2_t v1,
vint64m2_t v2,
}
// Ideally with O3, should find 0 instances of any vmvnr.v PR113913
-/* { dg-final { scan-assembler-times {vmv1r.v\s+v[0-9]+,\s*v[0-9]+} 72 } } */
-/* { dg-final { scan-assembler-times {vmv2r.v\s+v[0-9]+,\s*v[0-9]+} 36 } } */
-/* { dg-final { scan-assembler-times {vmv4r.v\s+v[0-9]+,\s*v[0-9]+} 16 } } */
+/* { dg-final { scan-assembler-not {vmv1r.v\s+v[0-9]+,\s*v[0-9]+} } } */
+/* { dg-final { scan-assembler-not {vmv2r.v\s+v[0-9]+,\s*v[0-9]+} } } */
+/* { dg-final { scan-assembler-not {vmv4r.v\s+v[0-9]+,\s*v[0-9]+} } } */
[PATCH][committed][testsuite]: Update test for PR115537 to use SVE .
Hi All,
The PR was about SVE codegen, the testcase accidentally used neoverse-n1
instead of neoverse-v1 as was the original report.
This updates the tool options.
Regtested on aarch64-none-linux-gnu and no issues.
committed under the obvious rule.
Thanks,
Tamar
gcc/testsuite/ChangeLog:
PR tree-optimization/115537
* gcc.dg/vect/pr115537.c: Update flag from neoverse-n1 to neoverse-v1.
---
diff --git a/gcc/testsuite/gcc.dg/vect/pr115537.c
b/gcc/testsuite/gcc.dg/vect/pr115537.c
index
99ed467feb884b745e1d499339fd6ef58aa0e6d2..9f7347a5f2adf03dadf428cc1cfab46c3f930466
100644
--- a/gcc/testsuite/gcc.dg/vect/pr115537.c
+++ b/gcc/testsuite/gcc.dg/vect/pr115537.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-additional-options "-mcpu=neoverse-n1" { target aarch64*-*-* } } */
+/* { dg-additional-options "-mcpu=neoverse-v1" { target aarch64*-*-* } } */
char *a;
int b;
--
diff --git a/gcc/testsuite/gcc.dg/vect/pr115537.c b/gcc/testsuite/gcc.dg/vect/pr115537.c
index 99ed467feb884b745e1d499339fd6ef58aa0e6d2..9f7347a5f2adf03dadf428cc1cfab46c3f930466 100644
--- a/gcc/testsuite/gcc.dg/vect/pr115537.c
+++ b/gcc/testsuite/gcc.dg/vect/pr115537.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-additional-options "-mcpu=neoverse-n1" { target aarch64*-*-* } } */
+/* { dg-additional-options "-mcpu=neoverse-v1" { target aarch64*-*-* } } */
char *a;
int b;
Ping^5: [PATCH 0/2] Fix two test failures with --enable-default-pie [PR70150]
Ping^5 https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650763.html On Mon, 2024-05-06 at 12:45 +0800, Xi Ruoyao wrote: > In GCC 14.1-rc1, there are two new (comparing to GCC 13) failures if > the build is configured --enable-default-pie. Let's fix them. > > Tested on x86_64-linux-gnu. Ok for trunk and releases/gcc-14? > > Xi Ruoyao (2): > i386: testsuite: Add -no-pie for pr113689-1.c [PR70150] > i386: testsuite: Adapt fentryname3.c for r14-811 change [PR70150] > > gcc/testsuite/gcc.target/i386/fentryname3.c | 3 +-- > gcc/testsuite/gcc.target/i386/pr113689-1.c | 2 +- > 2 files changed, 2 insertions(+), 3 deletions(-) -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
Re: [PATCH] testsuite: Fix pr115278.cc test when uint32_t isn't unsigned int
Thiago Jung Bauermann writes:
> --- a/gcc/testsuite/g++.dg/vect/pr115278.cc
> +++ b/gcc/testsuite/g++.dg/vect/pr115278.cc
> @@ -2,6 +2,7 @@
> // { dg-require-effective-target c++11 }
> // { dg-additional-options "-fdump-tree-optimized" }
>
> +#include
> #include
>
> const int runs = 92;
Sorry, the new include isn't necessary. It's a leftover from a previous
version of the patch.
I removed it locally and if the patch is approved, I'll commit it
without this hunk.
--
Thiago
[PATCH] testsuite: Fix pr115278.cc test when uint32_t isn't unsigned int
On arm-none-eabi, g++.dg/vect/pr115278.cc fails with:
FAIL: g++.dg/vect/pr115278.cc -std=c++14 (test for excess errors)
Excess errors:
/path/to/gcc.git/gcc/testsuite/g++.dg/vect/pr115278.cc:24:28: error: invalid
conversion from 'volatile unsigned int*' to 'volatile uint32_t*' {aka 'volatile
long unsigned int*'} [-fpermissive]
g++.dg/vect/pr115278.cc -std=c++14 : dump file does not exist
UNRESOLVED: g++.dg/vect/pr115278.cc -std=c++14 scan-tree-dump-times optimized
"\\*WRITE[^\r\n]* ={v} " 2
The problem is that the cast used to initialize the WRITE variable
doesn't match the underlying type of uint32_t. Fix by using
__UINT32_TYPE__ instead.
Verified that after this change, the test still fails when reverting the
fix for PR115278.
Tested on:
- Host x86_64-linux-gnu, target arm-unknown-eabi
- Native armv8l-linux-gnueabihf
- Native aarch64-linux-gnu
- Native x86_64-linux-gnu
gcc/testsuite/
* g++.dg/vect/pr115278.cc: Use __UINT32_TYPE__ in cast used to
initialize WRITE.
---
gcc/testsuite/g++.dg/vect/pr115278.cc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/g++.dg/vect/pr115278.cc
b/gcc/testsuite/g++.dg/vect/pr115278.cc
index 331075fb2781..39a7537a3e6a 100644
--- a/gcc/testsuite/g++.dg/vect/pr115278.cc
+++ b/gcc/testsuite/g++.dg/vect/pr115278.cc
@@ -2,6 +2,7 @@
// { dg-require-effective-target c++11 }
// { dg-additional-options "-fdump-tree-optimized" }
+#include
#include
const int runs = 92;
@@ -21,7 +22,7 @@ union BitfieldStructUnion {
BitfieldStructUnion(uint32_t value_low, uint32_t value_high) :
value_low(value_low), value_high(value_high) {}
};
-volatile uint32_t *WRITE = (volatile unsigned*)0x42;
+volatile uint32_t *WRITE = (volatile __UINT32_TYPE__*)0x42;
void buggy() {
for (int i = 0; i < runs; i++) {
Re: [PATCH] ARC: Update gcc.target/arc/pr9001184797.c test
On 7/3/24 8:24 AM, Luis Silva wrote: ... to comply with new standards due to stricter analysis in the latest GCC versions. gcc/testsuite/ChangeLog: * gcc.target/arc/pr9001184797.c: (Fix compiler warnings) I fixed the ChangeLog entry and pushed this to the trunk for you. I guess we shouldn't be surprised that some of the target tests slipped through the cracks. Thanks! Jeff
[PATCH] ARC: Update gcc.target/arc/pr9001184797.c test
... to comply with new standards due to stricter analysis in
the latest GCC versions.
gcc/testsuite/ChangeLog:
* gcc.target/arc/pr9001184797.c: (Fix compiler warnings)
---
gcc/testsuite/ChangeLog | 4
gcc/testsuite/gcc.target/arc/pr9001184797.c | 4 +++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 9aeec32f9e6..bd825881b75 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2024-07-03 Luis Silva
+
+ * gcc.target/arc/pr9001184797.c: (Fix compiler warnings)
+
2024-07-02 Pengxuan Zheng
PR target/113859
diff --git a/gcc/testsuite/gcc.target/arc/pr9001184797.c
b/gcc/testsuite/gcc.target/arc/pr9001184797.c
index e76c6769042..6c5de5fe729 100644
--- a/gcc/testsuite/gcc.target/arc/pr9001184797.c
+++ b/gcc/testsuite/gcc.target/arc/pr9001184797.c
@@ -4,13 +4,15 @@
/* This test studies the use of anchors and tls symbols. */
+extern int h();
+
struct a b;
struct a {
long c;
long d
} e() {
static __thread struct a f;
- static __thread g;
+ static __thread int g;
g = 5;
h();
if (f.c)
--
2.37.1
[PATCH v1 1/2] Aarch64: Add test for non-commutative SIMD intrinsic
This adds a test for non-commutative SIMD NEON intrinsics.
Specifically addp is non-commutative and has a bug in the current big-endian
implementation.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/vector_intrinsics_asm.c: New test.
---
.../aarch64/vector_intrinsics_asm.c | 371 ++
1 file changed, 371 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/aarch64/vector_intrinsics_asm.c
diff --git a/gcc/testsuite/gcc.target/aarch64/vector_intrinsics_asm.c b/gcc/testsuite/gcc.target/aarch64/vector_intrinsics_asm.c
new file mode 100644
index 000..b7d5620abab
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/vector_intrinsics_asm.c
@@ -0,0 +1,371 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-final { check-function-bodies "**" "" "" { xfail be } } } */
+
+#include "arm_neon.h"
+
+// SIGNED VADD INTRINSICS
+
+/*
+**test_vadd_s8:
+** addp v0\.8b, v0\.8b, v1\.8b
+** ret
+*/
+int8x8_t test_vadd_s8(int8x8_t v1, int8x8_t v2) {
+ int8x8_t v3 = vpadd_s8(v1, v2);
+ return v3;
+}
+
+/*
+**test_vadd_s16:
+**addp v0\.4h, v0\.4h, v1\.4h
+**ret
+*/
+int16x4_t test_vadd_s16(int16x4_t v1, int16x4_t v2) {
+ int16x4_t v3 = vpadd_s16(v1, v2);
+ return v3;
+}
+
+/*
+**test_vadd_s32:
+** addp v0\.2s, v0\.2s, v1\.2s
+** ret
+*/
+int32x2_t test_vadd_s32(int32x2_t v1, int32x2_t v2) {
+ int32x2_t v3 = vpadd_s32(v1, v2);
+ return v3;
+}
+
+/*
+**test_vaddq_s8:
+**...
+** addp v0\.16b, v0\.16b, v1\.16b
+** ret
+*/
+int8x16_t test_vaddq_s8(int8x16_t v1, int8x16_t v2) {
+ int8x16_t v3 = vpaddq_s8(v1, v2);
+ return v3;
+}
+
+/*
+**test_vaddq_s16:
+**...
+** addp v0\.8h, v0\.8h, v1\.8h
+** ret
+*/
+int16x8_t test_vaddq_s16(int16x8_t v1, int16x8_t v2) {
+ int16x8_t v3 = vpaddq_s16(v1, v2);
+ return v3;
+}
+
+/*
+**test_vaddq_s32:
+**...
+** addp v0\.4s, v0\.4s, v1\.4s
+** ret
+*/
+int32x4_t test_vaddq_s32(int32x4_t v1, int32x4_t v2) {
+ int32x4_t v3 = vpaddq_s32(v1, v2);
+ return v3;
+}
+
+/*
+**test_vaddq_s64:
+**...
+** addp v0\.2d, v0\.2d, v1\.2d
+** ret
+*/
+int64x2_t test_vaddq_s64(int64x2_t v1, int64x2_t v2) {
+ int64x2_t v3 = vpaddq_s64(v1, v2);
+ return v3;
+}
+
+/*
+**test_vaddd_s64:
+**...
+** addp (d[0-9]+), v0\.2d
+** fmov x0, \1
+** ret
+*/
+int64_t test_vaddd_s64(int64x2_t v1) {
+ int64_t v2 = vpaddd_s64(v1);
+ return v2;
+}
+
+/*
+**test_vaddl_s8:
+**...
+** saddlp v0\.4h, v0\.8b
+** ret
+*/
+int16x4_t test_vaddl_s8(int8x8_t v1) {
+ int16x4_t v2 = vpaddl_s8(v1);
+ return v2;
+}
+
+/*
+**test_vaddlq_s8:
+**...
+** saddlp v0\.8h, v0\.16b
+** ret
+*/
+int16x8_t test_vaddlq_s8(int8x16_t v1) {
+ int16x8_t v2 = vpaddlq_s8(v1);
+ return v2;
+}
+/*
+**test_vaddl_s16:
+**...
+** saddlp v0\.2s, v0\.4h
+** ret
+*/
+int32x2_t test_vaddl_s16(int16x4_t v1) {
+ int32x2_t v2 = vpaddl_s16(v1);
+ return v2;
+}
+
+/*
+**test_vaddlq_s16:
+**...
+** saddlp v0\.4s, v0\.8h
+** ret
+*/
+int32x4_t test_vaddlq_s16(int16x8_t v1) {
+ int32x4_t v2 = vpaddlq_s16(v1);
+ return v2;
+}
+
+/*
+**test_vaddl_s32:
+**...
+** saddlp v0\.1d, v0\.2s
+** ret
+*/
+int64x1_t test_vaddl_s32(int32x2_t v1) {
+ int64x1_t v2 = vpaddl_s32(v1);
+ return v2;
+}
+
+/*
+**test_vaddlq_s32:
+**...
+** saddlp v0\.2d, v0\.4s
+** ret
+*/
+int64x2_t test_vaddlq_s32(int32x4_t v1) {
+ int64x2_t v2 = vpaddlq_s32(v1);
+ return v2;
+}
+
+// UNSIGNED VADD INTRINSICS
+
+/*
+**test_vadd_u8:
+**...
+** addp v0\.8b, v0\.8b, v1\.8b
+** ret
+*/
+uint8x8_t test_vadd_u8(uint8x8_t v1, uint8x8_t v2) {
+ uint8x8_t v3 = vpadd_u8(v1, v2);
+ return v3;
+}
+
+/*
+**test_vadd_u16:
+**...
+** addp v0\.4h, v0\.4h, v1\.4h
+** ret
+*/
+uint16x4_t test_vadd_u16(uint16x4_t v1, uint16x4_t v2) {
+ uint16x4_t v3 = vpadd_u16(v1, v2);
+ return v3;
+}
+
+/*
+**test_vadd_u32:
+**...
+** addp v0\.2s, v0\.2s, v1\.2s
+** ret
+*/
+uint32x2_t test_vadd_u32(uint32x2_t v1, uint32x2_t v2) {
+ uint32x2_t v3 = vpadd_u32(v1, v2);
+ return v3;
+}
+
+/*
+**test_vaddq_u8:
+**...
+** addp v0\.16b, v0\.16b, v1\.16b
+** ret
+*/
+uint8x16_t test_vaddq_u8(uint8x16_t v1, uint8x16_t v2) {
+ uint8x16_t v3 = vpaddq_u8(v1, v2);
+ return v3;
+}
+
+/*
+**test_vaddq_u16:
+**...
+** addp v0\.8h, v0\.8h, v1\.8h
+** ret
+*/
+uint16x8_t test_vaddq_u16(uint16x8_t v1, uint16x8_t v2) {
+ uint16x8_t v3 = vpaddq_u16(v1, v2);
+ return v3;
+}
+
+/*
+**test_vaddq_u32:
+**...
+** addp v0\.4s, v0\.4s, v1\.4s
+** ret
+*/
+uint32x4_t test_vaddq_u32(uint32x4_t v1, uint32x4_t v2) {
+ uint32x4_t v3 = vpaddq_u32(v1, v2);
+ return v3;
+}
+
+/*
+**test_vaddq_u64:
+**...
+** addp v0\.2d, v0\.2d, v1\.2d
+** ret
+*/
+uint64x2_t test_vaddq_u64(uint64x2_t v1, uint64x2_t v2) {
+ uint64x2_t v3 = vpaddq_u64(v1, v2);
+ return v3;
+}
+
+/*
+**test_vaddd_u64:
+**...
+** addp (d[0-9]+), v0\.2d
+** fmov x0, \1
+** ret
+*/
+uint64_t test_vaddd_u64(uint64x2_t v1) {
+ uint64_t v2 = vpaddd_u64(v1);
+ return v2;
+}
+
+/*
+**test_vaddl_u8:
+**...
+** uaddlp v0\.4h, v0\.8b
+** ret
+*/
+uint16x4_t test_vaddl_u8(uint8x8_t v1) {
+ uint16x4_t v2 = vpad
[r15-1758 Regression] FAIL: g++.dg/cpp2a/spaceship-narrowing1.C -std=c++20 (test for excess errors) on Linux/x86_64
On Linux/x86_64,
52d71b6b1f0f465a6cf064f61b22fc99453ec132 is the first bad commit
commit 52d71b6b1f0f465a6cf064f61b22fc99453ec132
Author: Marek Polacek
Date: Fri Jun 28 17:51:19 2024 -0400
c++: DR2627, Bit-fields and narrowing conversions [PR94058]
caused
FAIL: g++.dg/cpp2a/spaceship-narrowing1.C -std=c++20 (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-1758/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg.exp=g++.dg/cpp2a/spaceship-narrowing1.C
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg.exp=g++.dg/cpp2a/spaceship-narrowing1.C
--target_board='unix{-m32\ -march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at haochen dot jiang at intel.com.)
(If you met problems with cascadelake related, disabling AVX512F in command
line might save that.)
(However, please make sure that there is no potential problems with AVX512.)
Re: [PATCH] Fix test errors introduced with fix for PR115157
Hello Martin, Martin Uecker writes: > This should fix the test failures introduced by the fix for PR115157. > > Tested on x86_64 and also tested with -m32. > > > Fix test errors introduced with fix for PR115157. > > Fix tests introduced when fixing PR115157 that assume > sizeof(enum)==sizeof(int) > by adding the flag -fno-short-enums. > > gcc/testsuite/Changelog: > * gcc.dg/enum-alias-1.c: Add flag. > * gcc.dg/enum-alias-2.c: Add flag. > * gcc.dg/enum-alias-3.c: Add flag. > * gcc.dg/enum-alias-4.c: Add flag. Thank you for the patch! It fixes the execution test failures but unfortunately they still have excess errors failures due to an unexpected linker warning: spawn -ignore SIGHUP /home/tcwg-build/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/bin/arm-eabi-gcc /home/tcwg-build/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.dg/enum-alias-1.c -fdiagnostics-plain-output -O2 -fno-short-enums -specs=rdimon.specs -lm -o ./enum-alias-1.exe /home/tcwg-build/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/lib/gcc/arm-eabi/15.0.0/../../../../arm-eabi/bin/ld: warning: /tmp/ccP9AJZd.o uses 32-bit enums yet the output is to use variable-size enums; use of enum values across objects may fail ⋮ FAIL: gcc.dg/enum-alias-1.c (test for excess errors) Excess errors: /home/tcwg-build/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/lib/gcc/arm-eabi/15.0.0/../../../../arm-eabi/bin/ld: warning: /tmp/ccP9AJZd.o uses 32-bit enums yet the output is to use variable-size enums; use of enum values across objects may fail The same happens with gcc.dg/enum-alias-[234].c. -- Thiago
test
test mail
test mail
Re: [PATCH v3] [testsuite] [arm] [vect] adjust mve-vshr test [PR113281]
On Jun 26, 2024, Richard Sandiford wrote: > Alexandre Oliva writes: >> On Jun 25, 2024, Richard Sandiford wrote: >> Richard (Sandiford), do you happen to recall why the IRC conversation mentioned in the PR trail decided to drop it entirely, even for signed types? >> >>> In the PR, the original shift was 32768 >> x (x >= 16) on ints, which the >>> vectoriser was narrowing to 32768 >> x' on shorts. The original shift is >>> well-defined for both signed and unsigned shifts, and no valid x' exists >>> for that case. >> >> It sounds like shifts on shorts proper, that would have benefitted from >> the optimization, was not covered and thus there may be room for >> reconsidering, eh? > What kind of case are you thinking of? If a frontend creates a true > 16-bit shift then it wouldn't need to be narrowed by this optimisation. I'm thinking of *any* (looped over arrays) shifts of *signed* shorts. The compiler can't generally tell that the shift count is < 16, as would now be required to use the vector instructions, but that's not necessary: for *signed* shorts, clamping the shift count at 15 like we used to do is enough to get the correct result for well-defined (as in non-overflowing) operations. ISTM we've given up a useful optimization. -- Alexandre Oliva, happy hackerhttps://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: [committed] Remove compromised sh test
On 6/26/24 7:27 PM, Oleg Endo wrote: On Wed, 2024-06-26 at 18:30 -0600, Jeff Law wrote: OK, then what's the default config of your test setup / triplet? Can you please show the generated code that you get? Because - like I said - I can't reproduce it. test01: sts.l pr,@-r15! 31[c=4 l=2] movsi_i/10 add #-4,r15 ! 32[c=4 l=2] *addsi3/0 mov.l .L3,r0 ! 26[c=10 l=2] movsi_i/0 jsr @r0 ! 12[c=5 l=2] call_valuei mov.l r6,@r15 ! 4 [c=4 l=2] movsi_i/8 mov.l @r15,r1 ! 29[c=1 l=2] movsi_i/5 add r1,r0 ! 30[c=4 l=2] *addsi3/0 add #4,r15 ! 36[c=4 l=2] *addsi3/0 lds.l @r15+,pr! 38[c=1 l=2] movsi_i/14 rts nop ! 40[c=0 l=4] *return_i Note that there's a scheduling barrier in the RTL between insns 30 and 36. So instructions prior to insn 36 can't be used to fill the delay slot. Thanks. Now I'm also seeing the same result. Needed to specify -O2 to get that. -O1 was not enough it seems. I don't know why you said that the code for this case improved -- it has not?! I think the test is still valid. The reason for the failure might be different from the original one (the scheduling barrier for whatever reason), but the end result is the same -- the last delay slot is not stuffed, although the 'add r1,r0' could go in there. I'd like to revert the removal of this test case, as it catches a valid issue. Before the IRA patch there is an additional prologue/epilogue save/restore for a callee saved register. That's what filled the delay slot before. THe add r1,r0 can not move down to fill the delay slot. There's scheduling barrier in the RTL. Feel free to restore it, but you're just adding a bogus, failing, test to the testsuite. jeff
Re: [committed] Remove compromised sh test
On Wed, 2024-06-26 at 18:30 -0600, Jeff Law wrote: > > > > > > > OK, then what's the default config of your test setup / triplet? > > Can you please show the generated code that you get? Because - like I said > > - I can't reproduce it. > test01: > sts.l pr,@-r15! 31[c=4 l=2] movsi_i/10 > add #-4,r15 ! 32[c=4 l=2] *addsi3/0 > mov.l .L3,r0 ! 26[c=10 l=2] movsi_i/0 > jsr @r0 ! 12[c=5 l=2] call_valuei > mov.l r6,@r15 ! 4 [c=4 l=2] movsi_i/8 > mov.l @r15,r1 ! 29[c=1 l=2] movsi_i/5 > add r1,r0 ! 30[c=4 l=2] *addsi3/0 > add #4,r15 ! 36[c=4 l=2] *addsi3/0 > lds.l @r15+,pr! 38[c=1 l=2] movsi_i/14 > rts > nop ! 40[c=0 l=4] *return_i > > > Note that there's a scheduling barrier in the RTL between insns 30 and > 36. So instructions prior to insn 36 can't be used to fill the delay slot. > Thanks. Now I'm also seeing the same result. Needed to specify -O2 to get that. -O1 was not enough it seems. I don't know why you said that the code for this case improved -- it has not?! I think the test is still valid. The reason for the failure might be different from the original one (the scheduling barrier for whatever reason), but the end result is the same -- the last delay slot is not stuffed, although the 'add r1,r0' could go in there. I'd like to revert the removal of this test case, as it catches a valid issue. Best regards, Oleg Endo
Re: [committed] Remove compromised sh test
On 6/26/24 4:44 PM, Oleg Endo wrote: On Wed, 2024-06-26 at 16:39 -0600, Jeff Law wrote: On 6/26/24 4:12 PM, Oleg Endo wrote: On Wed, 2024-06-26 at 07:22 -0600, Jeff Law wrote: Surya's recent patch to IRA improves the code for sh/pr54602-1.c slightly. Specifically it's able to eliminate a save/restore in the prologue/epilogue and a bit of register shuffling. As a result there literally aren't any insns that can be used to fill the delay slot of the return, so a nop gets emitted and the test fails. Given there literally aren't any insns to move into the delay slot, the best course of action is to just drop the test. Pushed to the trunk. Jeff I can't reproduce what you are saying. Which triplet and flags is your test setup using? For this test case, GCC 13 with -m4 -ml -O1 -fno-pic: No -m flags at all. As plain of a testrun as you can do. OK, then what's the default config of your test setup / triplet? Can you please show the generated code that you get? Because - like I said - I can't reproduce it. test01: sts.l pr,@-r15! 31[c=4 l=2] movsi_i/10 add #-4,r15 ! 32[c=4 l=2] *addsi3/0 mov.l .L3,r0 ! 26[c=10 l=2] movsi_i/0 jsr @r0 ! 12[c=5 l=2] call_valuei mov.l r6,@r15 ! 4 [c=4 l=2] movsi_i/8 mov.l @r15,r1 ! 29[c=1 l=2] movsi_i/5 add r1,r0 ! 30[c=4 l=2] *addsi3/0 add #4,r15 ! 36[c=4 l=2] *addsi3/0 lds.l @r15+,pr! 38[c=1 l=2] movsi_i/14 rts nop ! 40[c=0 l=4] *return_i Note that there's a scheduling barrier in the RTL between insns 30 and 36. So instructions prior to insn 36 can't be used to fill the delay slot. jeff
Re: [committed] Remove compromised sh test
On Wed, 2024-06-26 at 16:39 -0600, Jeff Law wrote: > > On 6/26/24 4:12 PM, Oleg Endo wrote: > > > > > > On Wed, 2024-06-26 at 07:22 -0600, Jeff Law wrote: > > > Surya's recent patch to IRA improves the code for sh/pr54602-1.c > > > slightly. Specifically it's able to eliminate a save/restore in the > > > prologue/epilogue and a bit of register shuffling. > > > > > > As a result there literally aren't any insns that can be used to fill > > > the delay slot of the return, so a nop gets emitted and the test fails. > > > > > > Given there literally aren't any insns to move into the delay slot, the > > > best course of action is to just drop the test. > > > > > > Pushed to the trunk. > > > > > > Jeff > > > > I can't reproduce what you are saying. > > Which triplet and flags is your test setup using? > > > > For this test case, GCC 13 with -m4 -ml -O1 -fno-pic: > No -m flags at all. As plain of a testrun as you can do. > OK, then what's the default config of your test setup / triplet? Can you please show the generated code that you get? Because - like I said - I can't reproduce it. Best regards, Oleg Endo
Re: [committed] Remove compromised sh test
On 6/26/24 4:12 PM, Oleg Endo wrote: On Wed, 2024-06-26 at 07:22 -0600, Jeff Law wrote: Surya's recent patch to IRA improves the code for sh/pr54602-1.c slightly. Specifically it's able to eliminate a save/restore in the prologue/epilogue and a bit of register shuffling. As a result there literally aren't any insns that can be used to fill the delay slot of the return, so a nop gets emitted and the test fails. Given there literally aren't any insns to move into the delay slot, the best course of action is to just drop the test. Pushed to the trunk. Jeff I can't reproduce what you are saying. Which triplet and flags is your test setup using? For this test case, GCC 13 with -m4 -ml -O1 -fno-pic: No -m flags at all. As plain of a testrun as you can do. jeff
Re: [committed] Remove compromised sh test
On Wed, 2024-06-26 at 07:22 -0600, Jeff Law wrote: > Surya's recent patch to IRA improves the code for sh/pr54602-1.c > slightly. Specifically it's able to eliminate a save/restore in the > prologue/epilogue and a bit of register shuffling. > > As a result there literally aren't any insns that can be used to fill > the delay slot of the return, so a nop gets emitted and the test fails. > > Given there literally aren't any insns to move into the delay slot, the > best course of action is to just drop the test. > > Pushed to the trunk. > > Jeff I can't reproduce what you are saying. Which triplet and flags is your test setup using? For this test case, GCC 13 with -m4 -ml -O1 -fno-pic: _test01: mov.l r8,@-r15 sts.l pr,@-r15 mov.l .L3,r0 jsr @r0 mov r6,r8 add r8,r0 lds.l @r15+,pr rts mov.l @r15+,r8 .L3: .long _test00 current GCC master branch with -m4 -ml -O1 -fno-pic: _test00: mov.l r8,@-r15 sts.l pr,@-r15 mov.l .L3,r0 jsr @r0 mov r6,r8 add r8,r0 lds.l @r15+,pr rts mov.l @r15+,r8 .L4: .align 2 .L3: .long _test01 Best regards, Oleg Endo
[committed] libstdc++: Remove duplicate test
Tested x86_64-linux. Pushed to trunk.
-- >8 --
We currently have 808590.cc which only runs for C++98 mode, and
808590-cxx11.cc which only runs for C++11 and later, but have almost
identical content (except for a defaulted special member in the C++11
one, to suppress a -Wdeprecated-copy warning).
This was done originally to ensure that the test ran for both C++98 mode
and C++11 mode, because the logic being tested was different enough to
need both to be tested. But it's trivial to run all tests in multiple
-std modes now, using GLIBCXX_TESTSUITE_STDS, so we don't need two
separate tests. We can remove one of the tests and allow the other one
to run in any -std mode.
libstdc++-v3/ChangeLog:
* testsuite/20_util/specialized_algorithms/uninitialized_copy/808590.cc:
Copy defaulted assignment operator from 808590-cxx11.cc to
suppress a warning.
*
testsuite/20_util/specialized_algorithms/uninitialized_copy/808590-cxx11.cc:
Removed.
---
.../uninitialized_copy/808590-cxx11.cc| 55 ---
.../uninitialized_copy/808590.cc | 7 ++-
2 files changed, 5 insertions(+), 57 deletions(-)
delete mode 100644
libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/808590-cxx11.cc
diff --git
a/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/808590-cxx11.cc
b/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/808590-cxx11.cc
deleted file mode 100644
index 2e93aa75738..000
---
a/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/808590-cxx11.cc
+++ /dev/null
@@ -1,55 +0,0 @@
-// Copyright (C) 2012-2024 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library. This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 3, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-
-// You should have received a copy of the GNU General Public License along
-// with this library; see the file COPYING3. If not see
-// <http://www.gnu.org/licenses/>.
-
-// { dg-do run { target c++11 } }
-
-// This is identical to ./808590.cc but for C++11 and later.
-// See https://gcc.gnu.org/ml/libstdc++/2014-05/msg00027.html
-
-#include
-#include
-
-// 4.4.x only
-struct c
-{
- void *m;
-
- c(void* o = 0) : m(o) {}
- c(const c ) : m(r.m) {}
-
- c& operator=(const c &) = default;
-
- template
-explicit c(T ) : m((void*)0xdeadbeef) { }
-};
-
-int main()
-{
- std::vector cbs;
- const c cb((void*)0xcafebabe);
-
- for (int fd = 62; fd < 67; ++fd)
-{
- cbs.resize(fd + 1);
- cbs[fd] = cb;
-}
-
- for (int fd = 62; fd< 67; ++fd)
-if (cb.m != cbs[fd].m)
- throw std::runtime_error("wrong");
- return 0;
-}
diff --git
a/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/808590.cc
b/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/808590.cc
index d2e07127323..b53db0e154d 100644
---
a/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/808590.cc
+++
b/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/808590.cc
@@ -15,8 +15,6 @@
// with this library; see the file COPYING3. If not see
// <http://www.gnu.org/licenses/>.
-// { dg-options "-std=gnu++98" }
-
#include
#include
@@ -28,6 +26,11 @@ struct c
c(void* o = 0) : m(o) {}
c(const c ) : m(r.m) {}
+#if __cplusplus >= 201103L
+ // Avoid -Wdeprecated-copy warning.
+ c& operator=(const c &) = default;
+#endif
+
template
explicit c(T ) : m((void*)0xdeadbeef) { }
};
--
2.45.2
Re: [PATCH 1/2] libstdc++: Work around some PSTL test failures for debug mode [PR90276]
Pushed to trunk now.
On Thu, 20 Jun 2024 at 16:36, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> -- >8 --
>
> This addresses one known failure due to a bug in the upstream tests, and
> a number of timeouts due to the algorithms running much more slowly with
> debug mode checks enabled.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/90276
> * testsuite/25_algorithms/pstl/alg_sorting/partial_sort.cc
> [_GLIBCXX_DEBUG]: Add xfail-run-if for debug mode.
> * testsuite/25_algorithms/pstl/alg_nonmodifying/nth_element.cc
> [_GLIBCXX_DEBUG]: Reduce size of test data.
> * testsuite/25_algorithms/pstl/alg_sorting/includes.cc:
> Likewise.
> * testsuite/25_algorithms/pstl/alg_sorting/set_util.h:
> Likewise.
> ---
> .../25_algorithms/pstl/alg_nonmodifying/nth_element.cc| 4
> .../testsuite/25_algorithms/pstl/alg_sorting/includes.cc | 4
> .../testsuite/25_algorithms/pstl/alg_sorting/partial_sort.cc | 1 +
> .../testsuite/25_algorithms/pstl/alg_sorting/set_util.h | 4
> 4 files changed, 13 insertions(+)
>
> diff --git
> a/libstdc++-v3/testsuite/25_algorithms/pstl/alg_nonmodifying/nth_element.cc
> b/libstdc++-v3/testsuite/25_algorithms/pstl/alg_nonmodifying/nth_element.cc
> index 61bbca758b4..63e6abe2ea4 100644
> ---
> a/libstdc++-v3/testsuite/25_algorithms/pstl/alg_nonmodifying/nth_element.cc
> +++
> b/libstdc++-v3/testsuite/25_algorithms/pstl/alg_nonmodifying/nth_element.cc
> @@ -133,7 +133,11 @@ void
> test_by_type(Generator1 generator1, Generator2 generator2, Compare comp)
> {
> using namespace std;
> +#ifdef _GLIBCXX_DEBUG
> +size_t max_size = 1000;
> +#else
> size_t max_size = 1;
> +#endif
> Sequence in1(max_size, [](size_t v) { return T(v); });
> Sequence exp(max_size, [](size_t v) { return T(v); });
> size_t m;
> diff --git
> a/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/includes.cc
> b/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/includes.cc
> index ed07810618d..1567c369c4c 100644
> --- a/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/includes.cc
> +++ b/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/includes.cc
> @@ -77,7 +77,11 @@ void
> test_includes(Compare compare)
> {
>
> +#ifdef _GLIBCXX_DEBUG
> +const std::size_t n_max = 1;
> +#else
> const std::size_t n_max = 100;
> +#endif
>
> // The rand()%(2*n+1) encourages generation of some duplicates.
> std::srand(42);
> diff --git
> a/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/partial_sort.cc
> b/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/partial_sort.cc
> index 6d441cc3ae9..797d0ee9340 100644
> --- a/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/partial_sort.cc
> +++ b/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/partial_sort.cc
> @@ -3,6 +3,7 @@
> // { dg-do run { target c++17 } }
> // { dg-timeout-factor 3 }
> // { dg-require-effective-target tbb_backend }
> +// { dg-xfail-run-if "see PR 90276" { debug_mode } }
>
> //===-- partial_sort.pass.cpp
> -===//
> //
> diff --git a/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/set_util.h
> b/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/set_util.h
> index ecf5cd1c89d..214e3452aa7 100644
> --- a/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/set_util.h
> +++ b/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/set_util.h
> @@ -51,7 +51,11 @@ namespace TestUtils
> void
> test_set_op(Compare compare)
> {
> +#ifdef _GLIBCXX_DEBUG
> +const std::size_t n_max = 1000;
> +#else
> const std::size_t n_max = 10;
> +#endif
>
> // The rand()%(2*n+1) encourages generation of some duplicates.
> std::srand(4200);
> --
> 2.45.2
>
[committed] Remove compromised sh test
Surya's recent patch to IRA improves the code for sh/pr54602-1.c
slightly. Specifically it's able to eliminate a save/restore in the
prologue/epilogue and a bit of register shuffling.
As a result there literally aren't any insns that can be used to fill
the delay slot of the return, so a nop gets emitted and the test fails.
Given there literally aren't any insns to move into the delay slot, the
best course of action is to just drop the test.
Pushed to the trunk.
Jeffcommit 47b68cda2c4afe32e84c5f18da0196c39e5e0edf
Author: Jeff Law
Date: Wed Jun 26 07:20:29 2024 -0600
[committed] Remove compromised sh test
Surya's recent patch to IRA improves the code for sh/pr54602-1.c slightly.
Specifically it's able to eliminate a save/restore in the prologue/epilogue
and
a bit of register shuffling.
As a result there literally aren't any insns that can be used to fill the
delay
slot of the return, so a nop gets emitted and the test fails.
Given there literally aren't any insns to move into the delay slot, the best
course of action is to just drop the test.
gcc/testsuite
* gcc.target/sh/pr54602-1.c: Delete test.
diff --git a/gcc/testsuite/gcc.target/sh/pr54602-1.c
b/gcc/testsuite/gcc.target/sh/pr54602-1.c
deleted file mode 100644
index e7fb2a9a642..000
--- a/gcc/testsuite/gcc.target/sh/pr54602-1.c
+++ /dev/null
@@ -1,14 +0,0 @@
-/* Verify that the delay slot is stuffed with register pop insns for normal
- (i.e. not interrupt handler) function returns. If everything goes as
- expected we won't see any nop insns. */
-/* { dg-do compile } */
-/* { dg-options "-O1" } */
-/* { dg-final { scan-assembler-not "nop" } } */
-
-int test00 (int a, int b);
-
-int
-test01 (int a, int b, int c, int d)
-{
- return test00 (a, b) + c;
-}
[committed] Remove compromised sh test
Surya's recent patch to IRA improves the code for sh/pr54602-1.c
slightly. Specifically it's able to eliminate a save/restore in the
prologue/epilogue and a bit of register shuffling.
As a result there literally aren't any insns that can be used to fill
the delay slot of the return, so a nop gets emitted and the test fails.
Given there literally aren't any insns to move into the delay slot, the
best course of action is to just drop the test.
Pushed to the trunk.
Jeffcommit 47b68cda2c4afe32e84c5f18da0196c39e5e0edf
Author: Jeff Law
Date: Wed Jun 26 07:20:29 2024 -0600
[committed] Remove compromised sh test
Surya's recent patch to IRA improves the code for sh/pr54602-1.c slightly.
Specifically it's able to eliminate a save/restore in the prologue/epilogue
and
a bit of register shuffling.
As a result there literally aren't any insns that can be used to fill the
delay
slot of the return, so a nop gets emitted and the test fails.
Given there literally aren't any insns to move into the delay slot, the best
course of action is to just drop the test.
gcc/testsuite
* gcc.target/sh/pr54602-1.c: Delete test.
diff --git a/gcc/testsuite/gcc.target/sh/pr54602-1.c
b/gcc/testsuite/gcc.target/sh/pr54602-1.c
deleted file mode 100644
index e7fb2a9a642..000
--- a/gcc/testsuite/gcc.target/sh/pr54602-1.c
+++ /dev/null
@@ -1,14 +0,0 @@
-/* Verify that the delay slot is stuffed with register pop insns for normal
- (i.e. not interrupt handler) function returns. If everything goes as
- expected we won't see any nop insns. */
-/* { dg-do compile } */
-/* { dg-options "-O1" } */
-/* { dg-final { scan-assembler-not "nop" } } */
-
-int test00 (int a, int b);
-
-int
-test01 (int a, int b, int c, int d)
-{
- return test00 (a, b) + c;
-}
[committed][RISC-V] Fix expected output for thead store pair test
Surya's patch to IRA has improved the code we generate for one of the
thead store pair tests for both rv32 and rv64. This patch adjusts the
expectations of that test.
I've verified that the test now passes on rv32 and rv64 in my tester.
Pushing to the trunk.
Jeffcommit 03a3dffa43145f80548d32b266b9b87be07b52ee
Author: Jeff Law
Date: Wed Jun 26 06:59:26 2024 -0600
[committed][RISC-V] Fix expected output for thead store pair test
Surya's patch to IRA has improved the code we generate for one of the thead
store pair tests for both rv32 and rv64. This patch adjusts the
expectations
of that test.
I've verified that the test now passes on rv32 and rv64 in my tester.
Pushing
to the trunk.
gcc/testsuite
* gcc.target/riscv/xtheadmempair-3.c: Update expected output.
diff --git a/gcc/testsuite/gcc.target/riscv/xtheadmempair-3.c
b/gcc/testsuite/gcc.target/riscv/xtheadmempair-3.c
index 5dec702819a..99a6ae7f4d7 100644
--- a/gcc/testsuite/gcc.target/riscv/xtheadmempair-3.c
+++ b/gcc/testsuite/gcc.target/riscv/xtheadmempair-3.c
@@ -17,13 +17,11 @@ void bar (xlen_t, xlen_t, xlen_t, xlen_t, xlen_t, xlen_t,
xlen_t, xlen_t);
void baz (xlen_t a, xlen_t b, xlen_t c, xlen_t d, xlen_t e, xlen_t f, xlen_t
g, xlen_t h)
{
foo (a, b, c, d, e, f, g, h);
- /* RV64: We don't use 0(sp), therefore we can only get 3 mempairs. */
- /* RV32: We don't use 0(sp)-8(sp), therefore we can only get 2 mempairs. */
bar (a, b, c, d, e, f, g, h);
}
-/* { dg-final { scan-assembler-times "th.ldd\t" 3 { target { rv64 } } } } */
-/* { dg-final { scan-assembler-times "th.sdd\t" 3 { target { rv64 } } } } */
+/* { dg-final { scan-assembler-times "th.ldd\t" 4 { target { rv64 } } } } */
+/* { dg-final { scan-assembler-times "th.sdd\t" 4 { target { rv64 } } } } */
-/* { dg-final { scan-assembler-times "th.lwd\t" 2 { target { rv32 } } } } */
-/* { dg-final { scan-assembler-times "th.swd\t" 2 { target { rv32 } } } } */
+/* { dg-final { scan-assembler-times "th.lwd\t" 4 { target { rv32 } } } } */
+/* { dg-final { scan-assembler-times "th.swd\t" 4 { target { rv32 } } } } */
Re: [PATCH v3] [testsuite] [arm] [vect] adjust mve-vshr test [PR113281]
Alexandre Oliva writes: > On Jun 25, 2024, Richard Sandiford wrote: > >>> Richard (Sandiford), do you happen to recall why the IRC conversation >>> mentioned in the PR trail decided to drop it entirely, even for signed >>> types? > >> In the PR, the original shift was 32768 >> x (x >= 16) on ints, which the >> vectoriser was narrowing to 32768 >> x' on shorts. The original shift is >> well-defined for both signed and unsigned shifts, and no valid x' exists >> for that case. > > It sounds like shifts on shorts proper, that would have benefitted from > the optimization, was not covered and thus there may be room for > reconsidering, eh? What kind of case are you thinking of? If a frontend creates a true 16-bit shift then it wouldn't need to be narrowed by this optimisation. Like you say in the commit message, the problem here is that the values are promoted to ints and then shifted as 32-bit values, so shifts by >= 16 are well-defined. Richard
Re: [PATCH v3] [testsuite] [arm] [vect] adjust mve-vshr test [PR113281]
On Jun 25, 2024, Richard Sandiford wrote: >> Richard (Sandiford), do you happen to recall why the IRC conversation >> mentioned in the PR trail decided to drop it entirely, even for signed >> types? > In the PR, the original shift was 32768 >> x (x >= 16) on ints, which the > vectoriser was narrowing to 32768 >> x' on shorts. The original shift is > well-defined for both signed and unsigned shifts, and no valid x' exists > for that case. It sounds like shifts on shorts proper, that would have benefitted from the optimization, was not covered and thus there may be room for reconsidering, eh? -- Alexandre Oliva, happy hackerhttps://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 v3] [testsuite] [arm] [vect] adjust mve-vshr test [PR113281]
Alexandre Oliva writes: > On Jun 24, 2024, "Richard Earnshaw (lists)" wrote: > >> A signed shift right on a 16-bit vector element by 15 would still >> yield -1 > > Yeah. Indeed, ISTM that we *could* have retained the clamping > transformation for *signed* shifts, since the clamping would only make a > difference in case of (undefined) overflow. Only for unsigned shifts > can well-defined shifts yield different results with clamping. > > Richard (Sandiford), do you happen to recall why the IRC conversation > mentioned in the PR trail decided to drop it entirely, even for signed > types? In the PR, the original shift was 32768 >> x (x >= 16) on ints, which the vectoriser was narrowing to 32768 >> x' on shorts. The original shift is well-defined for both signed and unsigned shifts, and no valid x' exists for that case. Thanks, Richard
Ping^4: [PATCH 0/2] Fix two test failures with --enable-default-pie [PR70150]
Ping^4 https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650763.html On Mon, 2024-05-06 at 12:45 +0800, Xi Ruoyao wrote: > In GCC 14.1-rc1, there are two new (comparing to GCC 13) failures if > the build is configured --enable-default-pie. Let's fix them. > > Tested on x86_64-linux-gnu. Ok for trunk and releases/gcc-14? > > Xi Ruoyao (2): > i386: testsuite: Add -no-pie for pr113689-1.c [PR70150] > i386: testsuite: Adapt fentryname3.c for r14-811 change [PR70150] > > gcc/testsuite/gcc.target/i386/fentryname3.c | 3 +-- > gcc/testsuite/gcc.target/i386/pr113689-1.c | 2 +- > 2 files changed, 2 insertions(+), 3 deletions(-) -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
Re: [PATCH v3] [testsuite] [arm] [vect] adjust mve-vshr test [PR113281]
On Jun 24, 2024, "Richard Earnshaw (lists)" wrote: > A signed shift right on a 16-bit vector element by 15 would still > yield -1 Yeah. Indeed, ISTM that we *could* have retained the clamping transformation for *signed* shifts, since the clamping would only make a difference in case of (undefined) overflow. Only for unsigned shifts can well-defined shifts yield different results with clamping. Richard (Sandiford), do you happen to recall why the IRC conversation mentioned in the PR trail decided to drop it entirely, even for signed types? -- Alexandre Oliva, happy hackerhttps://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 v3] [testsuite] [arm] [vect] adjust mve-vshr test [PR113281]
On 24/06/2024 12:35, Alexandre Oliva wrote:
> On Jun 21, 2024, Christophe Lyon wrote:
>
>>> How about mentioning Christophe's simplification in the commit log?
>
>> For the avoidance of doubt: it's OK for me (but you don't need to
>> mention my name in fact ;-)
>
> Needing or not, I added it ;-)
>
>>>> be accepted. (int16_t)32768 >> (int16_t)16 must yield 0, not 1 (as
>>>> before the fix).
>
>>> This is OK, but you might wish to revisit this statement before
>>> committing.
>
> Oh, right, sorry, I messed it up. uint16_t was what I should have put
> in there. int16_t would have overflown and invoked undefined behavior
> to begin with, and I see it misled you far down the wrong path.
>
>>> I think the original bug was that we were losing the cast to short
>
> The problem was that the shift count saturated at 15. AFAIK sign
> extension was not relevant. Hopefully the rewritten opening paragraph
> below makes that clearer. I will put it in later this week barring
> objections or further suggestions of improvement. Thanks,
A signed shift right on a 16-bit vector element by 15 would still yield -1; but
...
>
>
> [testsuite] [arm] [vect] adjust mve-vshr test [PR113281]
>
> The test was too optimistic, alas. We used to vectorize shifts by
> clamping the shift counts below the bit width of the types (e.g. at 15
> for 16-bit vector elements), but (uint16_t)32768 >> (uint16_t)16 is
> well defined (because of promotion to 32-bit int) and must yield 0,
> not 1 (as before the fix).
That make more sense now. Thanks.
>
> Unfortunately, in the gimple model of vector units, such large shift
> counts wouldn't be well-defined, so we won't vectorize such shifts any
> more, unless we can tell they're in range or undefined.
>
> So the test that expected the vectorization we no longer performed
> needs to be adjusted. Instead of nobbling the test, Richard Earnshaw
> suggested annotating the test with the expected ranges so as to enable
> the optimization, and Christophe Lyon suggested a further
> simplification.
>
>
> Co-Authored-By: Richard Earnshaw
>
> for gcc/testsuite/ChangeLog
>
> PR tree-optimization/113281
> * gcc.target/arm/simd/mve-vshr.c: Add expected ranges.
I think this is OK now.
R.
> ---
> gcc/testsuite/gcc.target/arm/simd/mve-vshr.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
> b/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
> index 8c7adef9ed8f1..03078de49c65e 100644
> --- a/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
> +++ b/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
> @@ -9,6 +9,8 @@
>void test_ ## NAME ##_ ## SIGN ## BITS ## x ## NB (TYPE##BITS##_t *
> __restrict__ dest, TYPE##BITS##_t *a, TYPE##BITS##_t *b) { \
> int i; \
> for (i=0; i + if ((unsigned)b[i] >= (unsigned)(BITS))
> \
> + __builtin_unreachable();\
>dest[i] = a[i] OP b[i];
> \
> }
> \
> }
>
>
Re: [PATCH v3] [testsuite] [arm] [vect] adjust mve-vshr test [PR113281]
On Jun 21, 2024, Christophe Lyon wrote:
>> How about mentioning Christophe's simplification in the commit log?
> For the avoidance of doubt: it's OK for me (but you don't need to
> mention my name in fact ;-)
Needing or not, I added it ;-)
>> > be accepted. (int16_t)32768 >> (int16_t)16 must yield 0, not 1 (as
>> > before the fix).
>> This is OK, but you might wish to revisit this statement before
>> committing.
Oh, right, sorry, I messed it up. uint16_t was what I should have put
in there. int16_t would have overflown and invoked undefined behavior
to begin with, and I see it misled you far down the wrong path.
>> I think the original bug was that we were losing the cast to short
The problem was that the shift count saturated at 15. AFAIK sign
extension was not relevant. Hopefully the rewritten opening paragraph
below makes that clearer. I will put it in later this week barring
objections or further suggestions of improvement. Thanks,
[testsuite] [arm] [vect] adjust mve-vshr test [PR113281]
The test was too optimistic, alas. We used to vectorize shifts by
clamping the shift counts below the bit width of the types (e.g. at 15
for 16-bit vector elements), but (uint16_t)32768 >> (uint16_t)16 is
well defined (because of promotion to 32-bit int) and must yield 0,
not 1 (as before the fix).
Unfortunately, in the gimple model of vector units, such large shift
counts wouldn't be well-defined, so we won't vectorize such shifts any
more, unless we can tell they're in range or undefined.
So the test that expected the vectorization we no longer performed
needs to be adjusted. Instead of nobbling the test, Richard Earnshaw
suggested annotating the test with the expected ranges so as to enable
the optimization, and Christophe Lyon suggested a further
simplification.
Co-Authored-By: Richard Earnshaw
for gcc/testsuite/ChangeLog
PR tree-optimization/113281
* gcc.target/arm/simd/mve-vshr.c: Add expected ranges.
---
gcc/testsuite/gcc.target/arm/simd/mve-vshr.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
b/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
index 8c7adef9ed8f1..03078de49c65e 100644
--- a/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
+++ b/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
@@ -9,6 +9,8 @@
void test_ ## NAME ##_ ## SIGN ## BITS ## x ## NB (TYPE##BITS##_t *
__restrict__ dest, TYPE##BITS##_t *a, TYPE##BITS##_t *b) { \
int i; \
for (i=0; i= (unsigned)(BITS)) \
+ __builtin_unreachable();\
dest[i] = a[i] OP b[i]; \
} \
}
--
Alexandre Oliva, happy hackerhttps://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] rs6000, change altivec*-runnable.c test file names
Hi,
on 2024/6/22 00:15, Carl Love wrote:
> GCC maintainers:
>
> Per the discussion of the dg header changes for test files
> altivec-1-runnable.c and altivec-2-runnable.c it was decided it would be best
> to change the names of the two tests to better align them with the tests that
> they are better aligned with.
>
> This patch is dependent on the two patches to update the dg arguments for
> test files altivec-1-runnable.c and altivec-2-runnable.c being accepted and
> committed before this patch.
>
> The patch has been tested on Power 10 with no regression failures.
>
> Please let me know if this patch is acceptable for mainline. Thanks.
OK, thanks!
BR,
Kewen
>
> Carl
>
> --
> rs6000, change altivec*-runnable.c test file names
>
> Changed the names of the test files.
>
> gcc/testsuite/ChangeLog:gcc/testsuite/ChangeLog:
> * gcc.target/powerpc/altivec-1-runnable.c: Change the name to
> altivec-38.c.
> * gcc.target/powerpc/altivec-2-runnable.c: Change the name to
> p8vector-builtin-9.c.
> ---
> .../gcc.target/powerpc/{altivec-1-runnable.c => altivec-38.c} | 0
> .../powerpc/{altivec-2-runnable.c => p8vector-builtin-9.c}| 0
> 2 files changed, 0 insertions(+), 0 deletions(-)
> rename gcc/testsuite/gcc.target/powerpc/{altivec-1-runnable.c =>
> altivec-38.c} (100%)
> rename gcc/testsuite/gcc.target/powerpc/{altivec-2-runnable.c =>
> p8vector-builtin-9.c} (100%)
>
> diff --git a/gcc/testsuite/gcc.target/powerpc/altivec-1-runnable.c
> b/gcc/testsuite/gcc.target/powerpc/altivec-38.c
> similarity index 100%
> rename from gcc/testsuite/gcc.target/powerpc/altivec-1-runnable.c
> rename to gcc/testsuite/gcc.target/powerpc/altivec-38.c
> diff --git a/gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c
> b/gcc/testsuite/gcc.target/powerpc/p8vector-builtin-9.c
> similarity index 100%
> rename from gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c
> rename to gcc/testsuite/gcc.target/powerpc/p8vector-builtin-9.c
[PATCH] Fix test errors introduced with fix for PR115157
This should fix the test failures introduced by the fix for PR115157.
Tested on x86_64 and also tested with -m32.
Fix test errors introduced with fix for PR115157.
Fix tests introduced when fixing PR115157 that assume
sizeof(enum)==sizeof(int)
by adding the flag -fno-short-enums.
gcc/testsuite/Changelog:
* gcc.dg/enum-alias-1.c: Add flag.
* gcc.dg/enum-alias-2.c: Add flag.
* gcc.dg/enum-alias-3.c: Add flag.
* gcc.dg/enum-alias-4.c: Add flag.
diff --git a/gcc/testsuite/gcc.dg/enum-alias-1.c
b/gcc/testsuite/gcc.dg/enum-alias-1.c
index 8fa30eb7897..725d88580b8 100644
--- a/gcc/testsuite/gcc.dg/enum-alias-1.c
+++ b/gcc/testsuite/gcc.dg/enum-alias-1.c
@@ -1,5 +1,5 @@
/* { dg-do run } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O2 -fno-short-enums" } */
enum E { E1 = -1, E2 = 0, E3 = 1 };
diff --git a/gcc/testsuite/gcc.dg/enum-alias-2.c
b/gcc/testsuite/gcc.dg/enum-alias-2.c
index 7ca3f3b2db8..d988c5ee698 100644
--- a/gcc/testsuite/gcc.dg/enum-alias-2.c
+++ b/gcc/testsuite/gcc.dg/enum-alias-2.c
@@ -1,5 +1,5 @@
/* { dg-do run } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O2 -fno-short-enums" } */
typedef int A;
diff --git a/gcc/testsuite/gcc.dg/enum-alias-3.c
b/gcc/testsuite/gcc.dg/enum-alias-3.c
index 36a4f02a455..4dbf0c9293a 100644
--- a/gcc/testsuite/gcc.dg/enum-alias-3.c
+++ b/gcc/testsuite/gcc.dg/enum-alias-3.c
@@ -1,5 +1,5 @@
/* { dg-do run } */
-/* { dg-options "-O2 -flto" } */
+/* { dg-options "-O2 -flto -fno-short-enums" } */
typedef int *A;
diff --git a/gcc/testsuite/gcc.dg/enum-alias-4.c
b/gcc/testsuite/gcc.dg/enum-alias-4.c
index b78d0451e3e..a1a8613fca0 100644
--- a/gcc/testsuite/gcc.dg/enum-alias-4.c
+++ b/gcc/testsuite/gcc.dg/enum-alias-4.c
@@ -1,5 +1,5 @@
/* { dg-do run } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O2 -fno-short-enums" } */
typedef int A;
typedef int __attribute__ (( hardbool(0, 1) )) B;
[PATCH] Fix test errors after r15-1394 for sizeof(int)==sizeof(long) [PR115545]
This fixes the test failures introduced by the fix for PR115109.
Tested on x86_64 and also tested with -m32.
Fix test errors after r15-1394 for sizeof(int)==sizeof(long) [PR115545]
Some tests added to test the type of redeclarations of enumerators
in r15-1394 fail on architectures where sizeof(long) == sizeof(int).
Adapt tests to use long long and/or accept that long long is selected
as type for the enumerator.
gcc/testsuite/Changelog:
PR testsuite/115545
* gcc.dg/pr115109.c: Adapt test.
* gcc.dg/c23-tag-enum-6.c: Adapt test.
* gcc.dg/c23-tag-enum-7.c: Adapt test.
diff --git a/gcc/testsuite/gcc.dg/c23-tag-enum-6.c
b/gcc/testsuite/gcc.dg/c23-tag-enum-6.c
index 29aef7ee3fd..d8d304d9b3d 100644
--- a/gcc/testsuite/gcc.dg/c23-tag-enum-6.c
+++ b/gcc/testsuite/gcc.dg/c23-tag-enum-6.c
@@ -7,10 +7,10 @@ enum E : int { a = 1, b = 2 };
enum E : int { b = _Generic(a, enum E: 2), a = 1 };
enum H { x = 1 };
-enum H { x = 2UL + UINT_MAX }; /* { dg-error "outside the range" } */
+enum H { x = 2ULL + UINT_MAX };/* { dg-error "outside the range" } */
enum K : int { z = 1 };
-enum K : int { z = 2UL + UINT_MAX }; /* { dg-error "outside the range" } */
+enum K : int { z = 2ULL + UINT_MAX }; /* { dg-error "outside the range" } */
enum F { A = 0, B = UINT_MAX };
enum F { B = UINT_MAX, A };/* { dg-error "outside the range" } */
diff --git a/gcc/testsuite/gcc.dg/c23-tag-enum-7.c
b/gcc/testsuite/gcc.dg/c23-tag-enum-7.c
index d4c787c8f71..974735bf2ef 100644
--- a/gcc/testsuite/gcc.dg/c23-tag-enum-7.c
+++ b/gcc/testsuite/gcc.dg/c23-tag-enum-7.c
@@ -4,23 +4,23 @@
#include
// enumerators are all representable in int
-enum E { a = 1UL, b = _Generic(a, int: 2) };
+enum E { a = 1ULL, b = _Generic(a, int: 2) };
static_assert(_Generic(a, int: 1));
static_assert(_Generic(b, int: 1));
-enum E { a = 1UL, b = _Generic(a, int: 2) };
+enum E { a = 1ULL, b = _Generic(a, int: 2) };
static_assert(_Generic(a, int: 1));
static_assert(_Generic(b, int: 1));
// enumerators are not representable in int
-enum H { c = 1UL << (UINT_WIDTH + 1), d = 2 };
+enum H { c = 1ULL << (UINT_WIDTH + 1), d = 2 };
static_assert(_Generic(c, enum H: 1));
static_assert(_Generic(d, enum H: 1));
-enum H { c = 1UL << (UINT_WIDTH + 1), d = _Generic(c, enum H: 2) };
+enum H { c = 1ULL << (UINT_WIDTH + 1), d = _Generic(c, enum H: 2) };
static_assert(_Generic(c, enum H: 1));
static_assert(_Generic(d, enum H: 1));
// there is an overflow in the first declaration
-enum K { e = UINT_MAX, f, g = _Generic(e, unsigned int: 0) + _Generic(f,
unsigned long: 1) };
+enum K { e = UINT_MAX, f, g = _Generic(e, unsigned int: 0) + _Generic(f,
unsigned long: 1, unsigned long long: 1) };
static_assert(_Generic(e, enum K: 1));
static_assert(_Generic(f, enum K: 1));
static_assert(_Generic(g, enum K: 1));
@@ -30,7 +30,7 @@ static_assert(_Generic(f, enum K: 1));
static_assert(_Generic(g, enum K: 1));
// there is an overflow in the first declaration
-enum U { k = INT_MAX, l, m = _Generic(k, int: 0) + _Generic(l, long: 1) };
+enum U { k = INT_MAX, l, m = _Generic(k, int: 0) + _Generic(l, long: 1, long
long: 1) };
static_assert(_Generic(k, enum U: 1));
static_assert(_Generic(l, enum U: 1));
static_assert(_Generic(m, enum U: 1));
diff --git a/gcc/testsuite/gcc.dg/pr115109.c b/gcc/testsuite/gcc.dg/pr115109.c
index 4baee0f3445..8245ff7fadb 100644
--- a/gcc/testsuite/gcc.dg/pr115109.c
+++ b/gcc/testsuite/gcc.dg/pr115109.c
@@ -3,6 +3,6 @@
#include
-enum E { a = 1UL << (ULONG_WIDTH - 5), b = 2 };
-enum E { a = 1ULL << (ULONG_WIDTH - 5), b = _Generic(a, enum E: 2) };
+enum E { a = 1ULL << (ULLONG_WIDTH - 5), b = 2 };
+enum E { a = 1ULL << (ULLONG_WIDTH - 5), b = _Generic(a, enum E: 2) };
[PATCH] rs6000, change altivec*-runnable.c test file names
GCC maintainers:
Per the discussion of the dg header changes for test files altivec-1-runnable.c
and altivec-2-runnable.c it was decided it would be best to change the names of
the two tests to better align them with the tests that they are better aligned
with.
This patch is dependent on the two patches to update the dg arguments for test
files altivec-1-runnable.c and altivec-2-runnable.c being accepted and
committed before this patch.
The patch has been tested on Power 10 with no regression failures.
Please let me know if this patch is acceptable for mainline. Thanks.
Carl
--
rs6000, change altivec*-runnable.c test file names
Changed the names of the test files.
gcc/testsuite/ChangeLog:gcc/testsuite/ChangeLog:
* gcc.target/powerpc/altivec-1-runnable.c: Change the name to
altivec-38.c.
* gcc.target/powerpc/altivec-2-runnable.c: Change the name to
p8vector-builtin-9.c.
---
.../gcc.target/powerpc/{altivec-1-runnable.c => altivec-38.c} | 0
.../powerpc/{altivec-2-runnable.c => p8vector-builtin-9.c}| 0
2 files changed, 0 insertions(+), 0 deletions(-)
rename gcc/testsuite/gcc.target/powerpc/{altivec-1-runnable.c => altivec-38.c}
(100%)
rename gcc/testsuite/gcc.target/powerpc/{altivec-2-runnable.c =>
p8vector-builtin-9.c} (100%)
diff --git a/gcc/testsuite/gcc.target/powerpc/altivec-1-runnable.c
b/gcc/testsuite/gcc.target/powerpc/altivec-38.c
similarity index 100%
rename from gcc/testsuite/gcc.target/powerpc/altivec-1-runnable.c
rename to gcc/testsuite/gcc.target/powerpc/altivec-38.c
diff --git a/gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c
b/gcc/testsuite/gcc.target/powerpc/p8vector-builtin-9.c
similarity index 100%
rename from gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c
rename to gcc/testsuite/gcc.target/powerpc/p8vector-builtin-9.c
--
2.45.0
Re: [PATCH] libstdc++: Fix test on x86_64 and non-simd targets
On Fri, 21 Jun 2024 at 16:07, Matthias Kretz wrote: > > > * Running a test compiled with AVX512 instructions requires > avx512f_runtime not just avx512f. > > * The 'reduce2' test violated an invariant of fixed_size_simd_mask and > thus failed on all targets without 16-Byte vector builtins enabled (in > bits/simd.h). OK, thanks for the quick diagnosis and fix. > > Signed-off-by: Matthias Kretz > > libstdc++-v3/ChangeLog: > > PR libstdc++/115575 > * testsuite/experimental/simd/pr115454_find_last_set.cc: Require > avx512f_runtime. Don't memcpy fixed_size masks. > --- > .../testsuite/experimental/simd/pr115454_find_last_set.cc | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > > -- > ── > Dr. Matthias Kretz https://mattkretz.github.io > GSI Helmholtz Centre for Heavy Ion Research https://gsi.de > stdₓ::simd > ──
[PATCH] libstdc++: Fix test on x86_64 and non-simd targets
* Running a test compiled with AVX512 instructions requires
avx512f_runtime not just avx512f.
* The 'reduce2' test violated an invariant of fixed_size_simd_mask and
thus failed on all targets without 16-Byte vector builtins enabled (in
bits/simd.h).
Signed-off-by: Matthias Kretz
libstdc++-v3/ChangeLog:
PR libstdc++/115575
* testsuite/experimental/simd/pr115454_find_last_set.cc: Require
avx512f_runtime. Don't memcpy fixed_size masks.
---
.../testsuite/experimental/simd/pr115454_find_last_set.cc | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--
──
Dr. Matthias Kretz https://mattkretz.github.io
GSI Helmholtz Centre for Heavy Ion Research https://gsi.de
stdₓ::simd
──diff --git a/libstdc++-v3/testsuite/experimental/simd/pr115454_find_last_set.cc b/libstdc++-v3/testsuite/experimental/simd/pr115454_find_last_set.cc
index b47f19d3067..25a713b4e94 100644
--- a/libstdc++-v3/testsuite/experimental/simd/pr115454_find_last_set.cc
+++ b/libstdc++-v3/testsuite/experimental/simd/pr115454_find_last_set.cc
@@ -1,7 +1,7 @@
// { dg-options "-std=gnu++17" }
// { dg-do run { target *-*-* } }
// { dg-require-effective-target c++17 }
-// { dg-additional-options "-march=x86-64-v4" { target avx512f } }
+// { dg-additional-options "-march=x86-64-v4" { target avx512f_runtime } }
// { dg-require-cmath "" }
#include
@@ -25,7 +25,9 @@ namespace stdx
{
using M8 = typename V::mask_type;
using M4 = typename V::mask_type;
- if constexpr (sizeof(M8) == sizeof(M4))
+ if constexpr (sizeof(M8) == sizeof(M4)
+ && !std::is_same_v>)
+// fixed_size invariant: padding bits of masks are zero, the memcpy would violate that
{
M4 k;
__builtin_memcpy(&__data(k), &__data(M8(true)), sizeof(M4));
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH 3/6] iq2000: Fix test and branch instructions
On 6/20/24 7:34 AM, Richard Sandiford wrote: The iq2000 test and branch instructions had patterns like: [(set (pc) (if_then_else (eq (and:SI (match_operand:SI 0 "register_operand" "r") (match_operand:SI 1 "power_of_2_operand" "I")) (const_int 0)) (match_operand 2 "pc_or_label_operand" "") (match_operand 3 "pc_or_label_operand" "")))] power_of_2_operand allows any 32-bit power of 2, whereas "I" only accepts 16-bit signed constants. This meant that any power of 2 greater than 32768 would cause an "insn does not satisfy its constraints" ICE. Also, the %p operand modifier barfed on 1<<31, which is sign- rather than zero-extended to 64 bits. The code is inherently limited to 32-bit operands -- power_of_2_operand contains a test involving "unsigned" -- so this patch just ands with 0x. gcc/ * config/iq2000/iq2000.cc (iq2000_print_operand): Make %p handle 1<<31. * config/iq2000/iq2000.md: Remove "I" constraints on power_of_2_operands. OK for the trunk. jeff
Re: [PATCH v3] [testsuite] [arm] [vect] adjust mve-vshr test [PR113281]
On Fri, 21 Jun 2024 at 12:14, Richard Earnshaw (lists)
wrote:
>
> On 21/06/2024 08:57, Alexandre Oliva wrote:
> > On Jun 20, 2024, Christophe Lyon wrote:
> >
> >> Maybe using
> >> if ((unsigned)b[i] >= BITS) \
> >> would be clearer?
> >
> > Heh. Why make it simpler if we can make it unreadable, right? :-D
> >
> > Thanks, here's another version I've just retested on x-arm-eabi. Ok?
> >
> > I'm not sure how to credit your suggestion. It's not like you pretty
> > much wrote the entire patch, as in Richard's case, but it's still a
> > sizable chunk of this two-liner. Any preferences?
>
> How about mentioning Christophe's simplification in the commit log?
For the avoidance of doubt: it's OK for me (but you don't need to
mention my name in fact ;-)
Thanks,
Christophe
> >
> >
> > The test was too optimistic, alas. We used to vectorize shifts
> > involving 8-bit and 16-bit integral types by clamping the shift count
> > at the highest in-range shift count, but that was not correct: such
> > narrow shifts expect integral promotion, so larger shift counts should
> > be accepted. (int16_t)32768 >> (int16_t)16 must yield 0, not 1 (as
> > before the fix).
>
> This is OK, but you might wish to revisit this statement before committing.
> I think the above is a mis-summary of the original bug report which had a
> test to pick between 0 and 1 as the result of a shift operation.
>
> If I've understood what's going on here correctly, then we have
>
> (int16_t)32768 >> (int16_t) 16
>
> but shift is always done at int precision, so this is (due to default
> promotions)
>
> (int)(int16_t)32768 >> 16 // size/type of the shift amount does not matter.
>
> which then simplifies to
>
> -32768 >> 16; // 0x8000 >> 16
>
> = -1;
>
> I think the original bug was that we were losing the cast to short (and hence
> the sign extension of the intermediate value), so effectively we simplified
> this to
>
> 32768 >> 16; // 0x8000 >> 16
>
> = 0;
>
> And the other part of the observation was that it had to be done this way
> (and couldn't be narrowed for vectorization) because 16 is larger than the
> maximum shift for a short (actually you say that just below).
>
> R.
>
> >
> > Unfortunately, in the gimple model of vector units, such large shift
> > counts wouldn't be well-defined, so we won't vectorize such shifts any
> > more, unless we can tell they're in range or undefined.
> >
> > So the test that expected the incorrect clamping we no longer perform
> > needs to be adjusted. Instead of nobbling the test, Richard Earnshaw
> > suggested annotating the test with the expected ranges so as to enable
> > the optimization.
> >
> >
> > Co-Authored-By: Richard Earnshaw
> >
> > for gcc/testsuite/ChangeLog
> >
> > PR tree-optimization/113281
> > * gcc.target/arm/simd/mve-vshr.c: Add expected ranges.
> > ---
> > gcc/testsuite/gcc.target/arm/simd/mve-vshr.c |2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
> > b/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
> > index 8c7adef9ed8f1..03078de49c65e 100644
> > --- a/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
> > +++ b/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
> > @@ -9,6 +9,8 @@
> >void test_ ## NAME ##_ ## SIGN ## BITS ## x ## NB (TYPE##BITS##_t *
> > __restrict__ dest, TYPE##BITS##_t *a, TYPE##BITS##_t *b) { \
> > int i; \
> > for (i=0; i > + if ((unsigned)b[i] >= (unsigned)(BITS))
> > \
> > + __builtin_unreachable();\
> >dest[i] = a[i] OP b[i];
> > \
> > }
> > \
> > }
> >
> >
>
Re: [PATCH v3] [testsuite] [arm] [vect] adjust mve-vshr test [PR113281]
On 21/06/2024 08:57, Alexandre Oliva wrote:
> On Jun 20, 2024, Christophe Lyon wrote:
>
>> Maybe using
>> if ((unsigned)b[i] >= BITS) \
>> would be clearer?
>
> Heh. Why make it simpler if we can make it unreadable, right? :-D
>
> Thanks, here's another version I've just retested on x-arm-eabi. Ok?
>
> I'm not sure how to credit your suggestion. It's not like you pretty
> much wrote the entire patch, as in Richard's case, but it's still a
> sizable chunk of this two-liner. Any preferences?
How about mentioning Christophe's simplification in the commit log?
>
>
> The test was too optimistic, alas. We used to vectorize shifts
> involving 8-bit and 16-bit integral types by clamping the shift count
> at the highest in-range shift count, but that was not correct: such
> narrow shifts expect integral promotion, so larger shift counts should
> be accepted. (int16_t)32768 >> (int16_t)16 must yield 0, not 1 (as
> before the fix).
This is OK, but you might wish to revisit this statement before committing. I
think the above is a mis-summary of the original bug report which had a test to
pick between 0 and 1 as the result of a shift operation.
If I've understood what's going on here correctly, then we have
(int16_t)32768 >> (int16_t) 16
but shift is always done at int precision, so this is (due to default
promotions)
(int)(int16_t)32768 >> 16 // size/type of the shift amount does not matter.
which then simplifies to
-32768 >> 16; // 0x8000 >> 16
= -1;
I think the original bug was that we were losing the cast to short (and hence
the sign extension of the intermediate value), so effectively we simplified
this to
32768 >> 16; // 0x8000 >> 16
= 0;
And the other part of the observation was that it had to be done this way (and
couldn't be narrowed for vectorization) because 16 is larger than the maximum
shift for a short (actually you say that just below).
R.
>
> Unfortunately, in the gimple model of vector units, such large shift
> counts wouldn't be well-defined, so we won't vectorize such shifts any
> more, unless we can tell they're in range or undefined.
>
> So the test that expected the incorrect clamping we no longer perform
> needs to be adjusted. Instead of nobbling the test, Richard Earnshaw
> suggested annotating the test with the expected ranges so as to enable
> the optimization.
>
>
> Co-Authored-By: Richard Earnshaw
>
> for gcc/testsuite/ChangeLog
>
> PR tree-optimization/113281
> * gcc.target/arm/simd/mve-vshr.c: Add expected ranges.
> ---
> gcc/testsuite/gcc.target/arm/simd/mve-vshr.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
> b/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
> index 8c7adef9ed8f1..03078de49c65e 100644
> --- a/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
> +++ b/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
> @@ -9,6 +9,8 @@
>void test_ ## NAME ##_ ## SIGN ## BITS ## x ## NB (TYPE##BITS##_t *
> __restrict__ dest, TYPE##BITS##_t *a, TYPE##BITS##_t *b) { \
> int i; \
> for (i=0; i + if ((unsigned)b[i] >= (unsigned)(BITS))
> \
> + __builtin_unreachable();\
>dest[i] = a[i] OP b[i];
> \
> }
> \
> }
>
>
[committed] libstdc++: Initialize base in test allocator's constructor
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This fixes a warning from one of the test allocators:
warning: base class 'class std::allocator<__gnu_test::copy_tracker>' should be
explicitly initialized in the copy constructor [-Wextra]
libstdc++-v3/ChangeLog:
* testsuite/util/testsuite_allocator.h (tracker_allocator):
Initialize base class in copy constructor.
---
libstdc++-v3/testsuite/util/testsuite_allocator.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/testsuite/util/testsuite_allocator.h
b/libstdc++-v3/testsuite/util/testsuite_allocator.h
index b7739f13ca3..2f9c453cbd1 100644
--- a/libstdc++-v3/testsuite/util/testsuite_allocator.h
+++ b/libstdc++-v3/testsuite/util/testsuite_allocator.h
@@ -154,7 +154,7 @@ namespace __gnu_test
tracker_allocator()
{ }
- tracker_allocator(const tracker_allocator&)
+ tracker_allocator(const tracker_allocator& a) : Alloc(a)
{ }
~tracker_allocator()
--
2.45.2
[PATCH v3] [testsuite] [arm] [vect] adjust mve-vshr test [PR113281]
On Jun 20, 2024, Christophe Lyon wrote:
> Maybe using
> if ((unsigned)b[i] >= BITS) \
> would be clearer?
Heh. Why make it simpler if we can make it unreadable, right? :-D
Thanks, here's another version I've just retested on x-arm-eabi. Ok?
I'm not sure how to credit your suggestion. It's not like you pretty
much wrote the entire patch, as in Richard's case, but it's still a
sizable chunk of this two-liner. Any preferences?
The test was too optimistic, alas. We used to vectorize shifts
involving 8-bit and 16-bit integral types by clamping the shift count
at the highest in-range shift count, but that was not correct: such
narrow shifts expect integral promotion, so larger shift counts should
be accepted. (int16_t)32768 >> (int16_t)16 must yield 0, not 1 (as
before the fix).
Unfortunately, in the gimple model of vector units, such large shift
counts wouldn't be well-defined, so we won't vectorize such shifts any
more, unless we can tell they're in range or undefined.
So the test that expected the incorrect clamping we no longer perform
needs to be adjusted. Instead of nobbling the test, Richard Earnshaw
suggested annotating the test with the expected ranges so as to enable
the optimization.
Co-Authored-By: Richard Earnshaw
for gcc/testsuite/ChangeLog
PR tree-optimization/113281
* gcc.target/arm/simd/mve-vshr.c: Add expected ranges.
---
gcc/testsuite/gcc.target/arm/simd/mve-vshr.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
b/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
index 8c7adef9ed8f1..03078de49c65e 100644
--- a/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
+++ b/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
@@ -9,6 +9,8 @@
void test_ ## NAME ##_ ## SIGN ## BITS ## x ## NB (TYPE##BITS##_t *
__restrict__ dest, TYPE##BITS##_t *a, TYPE##BITS##_t *b) { \
int i; \
for (i=0; i= (unsigned)(BITS)) \
+ __builtin_unreachable();\
dest[i] = a[i] OP b[i]; \
} \
}
--
Alexandre Oliva, happy hackerhttps://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
[PATCH 1/2] libstdc++: Work around some PSTL test failures for debug mode [PR90276]
Tested x86_64-linux.
-- >8 --
This addresses one known failure due to a bug in the upstream tests, and
a number of timeouts due to the algorithms running much more slowly with
debug mode checks enabled.
libstdc++-v3/ChangeLog:
PR libstdc++/90276
* testsuite/25_algorithms/pstl/alg_sorting/partial_sort.cc
[_GLIBCXX_DEBUG]: Add xfail-run-if for debug mode.
* testsuite/25_algorithms/pstl/alg_nonmodifying/nth_element.cc
[_GLIBCXX_DEBUG]: Reduce size of test data.
* testsuite/25_algorithms/pstl/alg_sorting/includes.cc:
Likewise.
* testsuite/25_algorithms/pstl/alg_sorting/set_util.h:
Likewise.
---
.../25_algorithms/pstl/alg_nonmodifying/nth_element.cc| 4
.../testsuite/25_algorithms/pstl/alg_sorting/includes.cc | 4
.../testsuite/25_algorithms/pstl/alg_sorting/partial_sort.cc | 1 +
.../testsuite/25_algorithms/pstl/alg_sorting/set_util.h | 4
4 files changed, 13 insertions(+)
diff --git
a/libstdc++-v3/testsuite/25_algorithms/pstl/alg_nonmodifying/nth_element.cc
b/libstdc++-v3/testsuite/25_algorithms/pstl/alg_nonmodifying/nth_element.cc
index 61bbca758b4..63e6abe2ea4 100644
--- a/libstdc++-v3/testsuite/25_algorithms/pstl/alg_nonmodifying/nth_element.cc
+++ b/libstdc++-v3/testsuite/25_algorithms/pstl/alg_nonmodifying/nth_element.cc
@@ -133,7 +133,11 @@ void
test_by_type(Generator1 generator1, Generator2 generator2, Compare comp)
{
using namespace std;
+#ifdef _GLIBCXX_DEBUG
+size_t max_size = 1000;
+#else
size_t max_size = 1;
+#endif
Sequence in1(max_size, [](size_t v) { return T(v); });
Sequence exp(max_size, [](size_t v) { return T(v); });
size_t m;
diff --git a/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/includes.cc
b/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/includes.cc
index ed07810618d..1567c369c4c 100644
--- a/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/includes.cc
+++ b/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/includes.cc
@@ -77,7 +77,11 @@ void
test_includes(Compare compare)
{
+#ifdef _GLIBCXX_DEBUG
+const std::size_t n_max = 1;
+#else
const std::size_t n_max = 100;
+#endif
// The rand()%(2*n+1) encourages generation of some duplicates.
std::srand(42);
diff --git
a/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/partial_sort.cc
b/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/partial_sort.cc
index 6d441cc3ae9..797d0ee9340 100644
--- a/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/partial_sort.cc
+++ b/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/partial_sort.cc
@@ -3,6 +3,7 @@
// { dg-do run { target c++17 } }
// { dg-timeout-factor 3 }
// { dg-require-effective-target tbb_backend }
+// { dg-xfail-run-if "see PR 90276" { debug_mode } }
//===-- partial_sort.pass.cpp
-===//
//
diff --git a/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/set_util.h
b/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/set_util.h
index ecf5cd1c89d..214e3452aa7 100644
--- a/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/set_util.h
+++ b/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/set_util.h
@@ -51,7 +51,11 @@ namespace TestUtils
void
test_set_op(Compare compare)
{
+#ifdef _GLIBCXX_DEBUG
+const std::size_t n_max = 1000;
+#else
const std::size_t n_max = 10;
+#endif
// The rand()%(2*n+1) encourages generation of some duplicates.
std::srand(4200);
--
2.45.2
[PATCH 3/6] iq2000: Fix test and branch instructions
The iq2000 test and branch instructions had patterns like:
[(set (pc)
(if_then_else
(eq (and:SI (match_operand:SI 0 "register_operand" "r")
(match_operand:SI 1 "power_of_2_operand" "I"))
(const_int 0))
(match_operand 2 "pc_or_label_operand" "")
(match_operand 3 "pc_or_label_operand" "")))]
power_of_2_operand allows any 32-bit power of 2, whereas "I" only
accepts 16-bit signed constants. This meant that any power of 2
greater than 32768 would cause an "insn does not satisfy its
constraints" ICE.
Also, the %p operand modifier barfed on 1<<31, which is sign-
rather than zero-extended to 64 bits. The code is inherently
limited to 32-bit operands -- power_of_2_operand contains a test
involving "unsigned" -- so this patch just ands with 0x.
gcc/
* config/iq2000/iq2000.cc (iq2000_print_operand): Make %p handle 1<<31.
* config/iq2000/iq2000.md: Remove "I" constraints on
power_of_2_operands.
---
gcc/config/iq2000/iq2000.cc | 2 +-
gcc/config/iq2000/iq2000.md | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/config/iq2000/iq2000.cc b/gcc/config/iq2000/iq2000.cc
index f9f8c417841..136675d0fbb 100644
--- a/gcc/config/iq2000/iq2000.cc
+++ b/gcc/config/iq2000/iq2000.cc
@@ -3127,7 +3127,7 @@ iq2000_print_operand (FILE *file, rtx op, int letter)
{
int value;
if (code != CONST_INT
- || (value = exact_log2 (INTVAL (op))) < 0)
+ || (value = exact_log2 (UINTVAL (op) & 0x)) < 0)
output_operand_lossage ("invalid %%p value");
else
fprintf (file, "%d", value);
diff --git a/gcc/config/iq2000/iq2000.md b/gcc/config/iq2000/iq2000.md
index 8617efac3c6..e62c250ce8c 100644
--- a/gcc/config/iq2000/iq2000.md
+++ b/gcc/config/iq2000/iq2000.md
@@ -1175,7 +1175,7 @@ (define_insn ""
[(set (pc)
(if_then_else
(eq (and:SI (match_operand:SI 0 "register_operand" "r")
-(match_operand:SI 1 "power_of_2_operand" "I"))
+(match_operand:SI 1 "power_of_2_operand"))
(const_int 0))
(match_operand 2 "pc_or_label_operand" "")
(match_operand 3 "pc_or_label_operand" "")))]
@@ -1189,7 +1189,7 @@ (define_insn ""
[(set (pc)
(if_then_else
(ne (and:SI (match_operand:SI 0 "register_operand" "r")
-(match_operand:SI 1 "power_of_2_operand" "I"))
+(match_operand:SI 1 "power_of_2_operand"))
(const_int 0))
(match_operand 2 "pc_or_label_operand" "")
(match_operand 3 "pc_or_label_operand" "")))]
--
2.25.1
Re: [PATCH v2] [testsuite] [arm] [vect] adjust mve-vshr test [PR113281]
Hi,
On Thu, 20 Jun 2024 at 12:51, Alexandre Oliva wrote:
>
> On Jun 19, 2024, "Richard Earnshaw (lists)" wrote:
>
> > It looks like adding
>
> > if ((unsigned)b[i] >= 8*sizeof (TYPE##BITS##_t)) \
> > __builtin_unreachable(); \
>
> Ah, yes, nice, good idea, thanks!
>
> Here's the patch that implements that, co-attributed to you, as IMHO it
> should be; please let me know if you find otherwise. The commit message
> is mostly unchanged from v1, except for the very end. Tested on
> x86_64-linux-gnu-x-arm-eabi. Ok to install?
>
>
> The test was too optimistic, alas. We used to vectorize shifts
> involving 8-bit and 16-bit integral types by clamping the shift count
> at the highest in-range shift count, but that was not correct: such
> narrow shifts expect integral promotion, so larger shift counts should
> be accepted. (int16_t)32768 >> (int16_t)16 must yield 0, not 1 (as
> before the fix).
>
> Unfortunately, in the gimple model of vector units, such large shift
> counts wouldn't be well-defined, so we won't vectorize such shifts any
> more, unless we can tell they're in range or undefined.
>
> So the test that expected the incorrect clamping we no longer perform
> needs to be adjusted. Instead of nobbling the test, Richard Earnshaw
> suggested annotating the test with the expected ranges so as to enable
> the optimization.
>
>
> Co-Authored-By: Richard Earnshaw
>
> for gcc/testsuite/ChangeLog
>
> PR tree-optimization/113281
> * gcc.target/arm/simd/mve-vshr.c: Add expected ranges.
> ---
> gcc/testsuite/gcc.target/arm/simd/mve-vshr.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
> b/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
> index 8c7adef9ed8f1..35cd0e75be5dc 100644
> --- a/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
> +++ b/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
> @@ -9,6 +9,8 @@
>void test_ ## NAME ##_ ## SIGN ## BITS ## x ## NB (TYPE##BITS##_t *
> __restrict__ dest, TYPE##BITS##_t *a, TYPE##BITS##_t *b) { \
> int i; \
> for (i=0; i + if ((unsigned)b[i] >= __CHAR_BIT__ * sizeof (TYPE##BITS##_t))\
Maybe using
if ((unsigned)b[i] >= BITS) \
would be clearer?
Thanks,
Christophe
> + __builtin_unreachable();\
>dest[i] = a[i] OP b[i]; \
> } \
> }
>
>
> --
> Alexandre Oliva, happy hackerhttps://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
[wwwdocs] simtest-howto.html: Add test instructions for avr.
Added the following hint on testing for target avr. Johann -- diff --git a/htdocs/simtest-howto.html b/htdocs/simtest-howto.html index 3afbdb0b..ea69c9ed 100644 --- a/htdocs/simtest-howto.html +++ b/htdocs/simtest-howto.html @@ -304,5 +304,22 @@ to exercise the just-built gcc on every test-suite in the tree. + +Target specific test instructions + +avr + + +See the +https://github.com/sprintersb/atest; + >AVRtest +core simulator and +href="https://github.com/sprintersb/atest?tab=readme-ov-file#running-the-avr-gcc-testsuite-using-the-avrtest-simulator; + >README: Running the avr-gcc Testsuite using the AVRtest Simulator. +The AVRtest project comes with a number of different board descriptions +that cover the various AVR cores. avr-gdb is not required. + + +
[PATCH v2] [testsuite] [arm] [vect] adjust mve-vshr test [PR113281]
On Jun 19, 2024, "Richard Earnshaw (lists)" wrote:
> It looks like adding
> if ((unsigned)b[i] >= 8*sizeof (TYPE##BITS##_t)) \
> __builtin_unreachable(); \
Ah, yes, nice, good idea, thanks!
Here's the patch that implements that, co-attributed to you, as IMHO it
should be; please let me know if you find otherwise. The commit message
is mostly unchanged from v1, except for the very end. Tested on
x86_64-linux-gnu-x-arm-eabi. Ok to install?
The test was too optimistic, alas. We used to vectorize shifts
involving 8-bit and 16-bit integral types by clamping the shift count
at the highest in-range shift count, but that was not correct: such
narrow shifts expect integral promotion, so larger shift counts should
be accepted. (int16_t)32768 >> (int16_t)16 must yield 0, not 1 (as
before the fix).
Unfortunately, in the gimple model of vector units, such large shift
counts wouldn't be well-defined, so we won't vectorize such shifts any
more, unless we can tell they're in range or undefined.
So the test that expected the incorrect clamping we no longer perform
needs to be adjusted. Instead of nobbling the test, Richard Earnshaw
suggested annotating the test with the expected ranges so as to enable
the optimization.
Co-Authored-By: Richard Earnshaw
for gcc/testsuite/ChangeLog
PR tree-optimization/113281
* gcc.target/arm/simd/mve-vshr.c: Add expected ranges.
---
gcc/testsuite/gcc.target/arm/simd/mve-vshr.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
b/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
index 8c7adef9ed8f1..35cd0e75be5dc 100644
--- a/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
+++ b/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
@@ -9,6 +9,8 @@
void test_ ## NAME ##_ ## SIGN ## BITS ## x ## NB (TYPE##BITS##_t *
__restrict__ dest, TYPE##BITS##_t *a, TYPE##BITS##_t *b) { \
int i; \
for (i=0; i= __CHAR_BIT__ * sizeof (TYPE##BITS##_t))\
+ __builtin_unreachable();\
dest[i] = a[i] OP b[i]; \
} \
}
--
Alexandre Oliva, happy hackerhttps://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] i386: Fix some ISA bit test in option_override
On Thu, Jun 20, 2024 at 3:16 AM Hongyu Wang wrote:
>
> Hi,
>
> This patch adjusts several new feature check in ix86_option_override_interal
> that directly use TARGET_* instead of TARGET_*_P (opts->ix86_isa_flags),
> which caused cmdline option overrides target_attribute isa flag.
>
> Bootstrapped && regtested on x86_64-pc-linux-gnu.
>
> Ok for trunk?
>
> gcc/ChangeLog:
>
> * config/i386/i386-options.cc (ix86_option_override_internal):
> Use TARGET_*_P (opts->x_ix86_isa_flags*) instead of TARGET_*
> for UINTR, LAM and APX_F.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/apx-ccmp-2.c: Remove -mno-apxf in option.
> * gcc.target/i386/funcspec-56.inc: Drop uintr tests.
> * gcc.target/i386/funcspec-6.c: Add uintr tests.
OK.
Thanks,
Uros.
> ---
> gcc/config/i386/i386-options.cc | 14 +-
> gcc/testsuite/gcc.target/i386/apx-ccmp-2.c| 2 +-
> gcc/testsuite/gcc.target/i386/funcspec-56.inc | 2 --
> gcc/testsuite/gcc.target/i386/funcspec-6.c| 2 ++
> 4 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/gcc/config/i386/i386-options.cc b/gcc/config/i386/i386-options.cc
> index f2cecc0e254..34adedb3127 100644
> --- a/gcc/config/i386/i386-options.cc
> +++ b/gcc/config/i386/i386-options.cc
> @@ -2113,15 +2113,18 @@ ix86_option_override_internal (bool main_args_p,
>opts->x_ix86_stringop_alg = no_stringop;
> }
>
> - if (TARGET_APX_F && !TARGET_64BIT)
> + if (TARGET_APX_F_P (opts->x_ix86_isa_flags2)
> + && !TARGET_64BIT_P (opts->x_ix86_isa_flags))
> error ("%<-mapxf%> is not supported for 32-bit code");
> - else if (opts->x_ix86_apx_features != apx_none && !TARGET_64BIT)
> + else if (opts->x_ix86_apx_features != apx_none
> + && !TARGET_64BIT_P (opts->x_ix86_isa_flags))
> error ("%<-mapx-features=%> option is not supported for 32-bit code");
>
> - if (TARGET_UINTR && !TARGET_64BIT)
> + if (TARGET_UINTR_P (opts->x_ix86_isa_flags2)
> + && !TARGET_64BIT_P (opts->x_ix86_isa_flags))
> error ("%<-muintr%> not supported for 32-bit code");
>
> - if (ix86_lam_type && !TARGET_LP64)
> + if (ix86_lam_type && !TARGET_LP64_P (opts->x_ix86_isa_flags))
> error ("%<-mlam=%> option: [u48|u57] not supported for 32-bit code");
>
>if (!opts->x_ix86_arch_string)
> @@ -2502,7 +2505,8 @@ ix86_option_override_internal (bool main_args_p,
>init_machine_status = ix86_init_machine_status;
>
>/* Override APX flag here if ISA bit is set. */
> - if (TARGET_APX_F && !OPTION_SET_P (ix86_apx_features))
> + if (TARGET_APX_F_P (opts->x_ix86_isa_flags2)
> + && !OPTION_SET_P (ix86_apx_features))
> opts->x_ix86_apx_features = apx_all;
>
>/* Validate -mregparm= value. */
> diff --git a/gcc/testsuite/gcc.target/i386/apx-ccmp-2.c
> b/gcc/testsuite/gcc.target/i386/apx-ccmp-2.c
> index 4a0784394c3..192c0458728 100644
> --- a/gcc/testsuite/gcc.target/i386/apx-ccmp-2.c
> +++ b/gcc/testsuite/gcc.target/i386/apx-ccmp-2.c
> @@ -1,6 +1,6 @@
> /* { dg-do run { target { ! ia32 } } } */
> /* { dg-require-effective-target apxf } */
> -/* { dg-options "-O3 -mno-apxf" } */
> +/* { dg-options "-O3" } */
>
> __attribute__((noinline, noclone, target("apxf")))
> int foo_apx(int a, int b, int c, int d)
> diff --git a/gcc/testsuite/gcc.target/i386/funcspec-56.inc
> b/gcc/testsuite/gcc.target/i386/funcspec-56.inc
> index 2a50f5bf67c..8825e88768a 100644
> --- a/gcc/testsuite/gcc.target/i386/funcspec-56.inc
> +++ b/gcc/testsuite/gcc.target/i386/funcspec-56.inc
> @@ -69,7 +69,6 @@ extern void test_avx512vp2intersect (void)
> __attribute__((__target__("avx512vp2i
> extern void test_amx_tile (void)
> __attribute__((__target__("amx-tile")));
> extern void test_amx_int8 (void)
> __attribute__((__target__("amx-int8")));
> extern void test_amx_bf16 (void)
> __attribute__((__target__("amx-bf16")));
> -extern void test_uintr (void)
> __attribute__((__target__("uintr")));
> extern void test_hreset (void)
> __attribute__((__target__("hreset")));
> extern void test_keylocker (void)
> __attribute__((__target__("kl")));
> extern void test_widekl (void)
> __attribute__((__target__("widekl")));
> @@ -158,7 +157,6 @@ extern void test_no_avx512vp2intersect (void)
> __attribute__((__target__("no-avx5
> extern void test_no_amx_tile (void)
> __attribute__((__target__("no-amx-tile")));
> extern void test_no_amx_int8 (void)
> __attribute__((__target__("no-amx-int8")));
> extern void test_no_amx_bf16 (void)
> __attribute__((__target__("no-amx-bf16")));
> -extern void test_no_uintr (void)
> __attribute__((__target__("no-uintr")));
> extern void test_no_hreset (void)
> __attribute__((__target__("no-hreset")));
> extern void test_no_keylocker (void)
> __attribute__((__target__("no-kl")));
> extern void
Re: [PATCH 00/11] AArch64/OpenMP: Test SVE ACLE types with various OpenMP constructs.
PING for the series. Thanks, Tejas. On 5/27/24 10:36 AM, Tejas Belagod wrote: Note: This patch series is based on Richard's initial patch https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606741.html and Jakub's suggestion https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611892.html The following patch series handles various scenarios with OpenMP and SVE types. The starting point for the series follows a suggestion from Jakub to cover all the possible scenarios that could arise when OMP constructs/clauses etc are used with SVE ACLE types. Here are a few instances that this patch series tests and in some cases fixes the expected output. This patch series does not follow a formal definition or a spec of how OMP interacts with SVE ACLE types, so it's more of a proposed behaviour. Comments and discussion welcome. This list is not exhaustive, but covers most scenarios of how SVE ACLE types ought to interact with OMP constructs/clauses. 1. Poly-int structures that represent variable-sized objects and OMP runtime. Currently poly-int type structures are passed by value to OpenMP runtime functions for shared clauses etc. This patch improves on this by passing around poly-int structures by address to avoid copy-overhead. 2. SVE ACLE types in OMP Shared clauses. We test the behaviour where SVE ACLE type objects are shared in the following methods into an OMP region: a. Explicit Shared clause on SVE ACLE type objects. b. Implicit shared clause. c. Implicit shared with default clause. d. SVE ALCE types in the presence of predetermined (static) shared objects. The associated tests ensure that all such shared objects are passed by address into the OMP runtime. There are runtime tests to verify the functional correctness of the change. 3. Offloading and SVE ACLE types. The target clause in OpenMP is used to offload loop kernels to accelerator peripeherals. target's 'map' clause is used to move data from and to the accelarator. When the data is SVE type, it may not be suitable because of various reasons i.e. the two SVE targets may not agree on vector size or some targets don't support variable vector size. This makes SVE unsuitable for use in OMP's 'map' clause. We diagnose all such cases and issue errors where appropriate. The cases we cover in this patch are: a. Implicitly-mapped SVE ACLE types in OMP target regions are diagnosed. b. Explicitly-mapped SVE ACLE types in OMP target regions using map clause are diagnosed. c. Explicilty-mapped SVLE ACLE types of various directions - to, from, tofrom in the map clause are diagnosed. d. target enter and exit data clauses with map on SVE ACLE types are diagnosed. e. target data map with alloc on SVE ACLE types are diagnosed. f. target update from clause on SVE ACLE types are diagnosed. g. target private firstprivate with SVE ACLE types are diagnosed. h. All combinations of target with work-sharing constructs like parallel, loop, simd, teams, distribute etc are also diagnosed when SVE ACLE types are involved. 3. Lastprivate and SVE ACLE types. Various OpenMP lastprivate clause scenarios with SVE object types are diagnosed. Worksharing constructs like sections, for, distribute bind to an implicit outer parallel region in whose scope SVE ACLE types are declared and are therefore default private. The lastprivate clause list with SVE ACLE type object items are diagnosed in this scenario. 4. Threadprivate on SVE ACLE type objects. We ensure threadprivate SVE ACLE type objects are supported. We also ensure copyin clause is also supported. 5. User-Defined Reductions on SVE ACLE types. We define a reduction using OMP declare reduction using SVE ACLE intrinsics and ensure its functional correctness with various work-sharing constructs like for, simd, parallel, task, taskloop. 6. Uniform and Aligned Clause with SVE ACLE We ensure the uniform clause's functional correctness with simd construct and associated SVE ACLE intrinsics in the simd region. There is no direct interaction between uniform and SVE ACLE type objects, but we ensure the uniform clause applies correctly to a region where SVE ACLE intrinsics are present. Similarly for the aligned clause. 7. Linear clause and SVE ACLE type. We diagnose if a linear clause list item has SVE ACLE type objects present. Its doesn't mean much if the linear clause is applied to SVE ACLE types. 8. Depend clause and SVE ACLE objects. We test for functional correctness many combinations of dependency of shared SVE ACLE type objects in parallel regions. We test if in, out dependencies and anti-dependencies are supported for SVE ACLE type objects using the depend clause with work-sharing constructs like task. 9. 'doacross' clause and SVE ACLE object types. doacross is mainly supported for scalars and loop iteration variables. We diagnose cases where SVE ACLE objects are used in doacross list items. Tejas Belagod (11
[PATCH] i386: Fix some ISA bit test in option_override
Hi,
This patch adjusts several new feature check in ix86_option_override_interal
that directly use TARGET_* instead of TARGET_*_P (opts->ix86_isa_flags),
which caused cmdline option overrides target_attribute isa flag.
Bootstrapped && regtested on x86_64-pc-linux-gnu.
Ok for trunk?
gcc/ChangeLog:
* config/i386/i386-options.cc (ix86_option_override_internal):
Use TARGET_*_P (opts->x_ix86_isa_flags*) instead of TARGET_*
for UINTR, LAM and APX_F.
gcc/testsuite/ChangeLog:
* gcc.target/i386/apx-ccmp-2.c: Remove -mno-apxf in option.
* gcc.target/i386/funcspec-56.inc: Drop uintr tests.
* gcc.target/i386/funcspec-6.c: Add uintr tests.
---
gcc/config/i386/i386-options.cc | 14 +-
gcc/testsuite/gcc.target/i386/apx-ccmp-2.c| 2 +-
gcc/testsuite/gcc.target/i386/funcspec-56.inc | 2 --
gcc/testsuite/gcc.target/i386/funcspec-6.c| 2 ++
4 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/gcc/config/i386/i386-options.cc b/gcc/config/i386/i386-options.cc
index f2cecc0e254..34adedb3127 100644
--- a/gcc/config/i386/i386-options.cc
+++ b/gcc/config/i386/i386-options.cc
@@ -2113,15 +2113,18 @@ ix86_option_override_internal (bool main_args_p,
opts->x_ix86_stringop_alg = no_stringop;
}
- if (TARGET_APX_F && !TARGET_64BIT)
+ if (TARGET_APX_F_P (opts->x_ix86_isa_flags2)
+ && !TARGET_64BIT_P (opts->x_ix86_isa_flags))
error ("%<-mapxf%> is not supported for 32-bit code");
- else if (opts->x_ix86_apx_features != apx_none && !TARGET_64BIT)
+ else if (opts->x_ix86_apx_features != apx_none
+ && !TARGET_64BIT_P (opts->x_ix86_isa_flags))
error ("%<-mapx-features=%> option is not supported for 32-bit code");
- if (TARGET_UINTR && !TARGET_64BIT)
+ if (TARGET_UINTR_P (opts->x_ix86_isa_flags2)
+ && !TARGET_64BIT_P (opts->x_ix86_isa_flags))
error ("%<-muintr%> not supported for 32-bit code");
- if (ix86_lam_type && !TARGET_LP64)
+ if (ix86_lam_type && !TARGET_LP64_P (opts->x_ix86_isa_flags))
error ("%<-mlam=%> option: [u48|u57] not supported for 32-bit code");
if (!opts->x_ix86_arch_string)
@@ -2502,7 +2505,8 @@ ix86_option_override_internal (bool main_args_p,
init_machine_status = ix86_init_machine_status;
/* Override APX flag here if ISA bit is set. */
- if (TARGET_APX_F && !OPTION_SET_P (ix86_apx_features))
+ if (TARGET_APX_F_P (opts->x_ix86_isa_flags2)
+ && !OPTION_SET_P (ix86_apx_features))
opts->x_ix86_apx_features = apx_all;
/* Validate -mregparm= value. */
diff --git a/gcc/testsuite/gcc.target/i386/apx-ccmp-2.c
b/gcc/testsuite/gcc.target/i386/apx-ccmp-2.c
index 4a0784394c3..192c0458728 100644
--- a/gcc/testsuite/gcc.target/i386/apx-ccmp-2.c
+++ b/gcc/testsuite/gcc.target/i386/apx-ccmp-2.c
@@ -1,6 +1,6 @@
/* { dg-do run { target { ! ia32 } } } */
/* { dg-require-effective-target apxf } */
-/* { dg-options "-O3 -mno-apxf" } */
+/* { dg-options "-O3" } */
__attribute__((noinline, noclone, target("apxf")))
int foo_apx(int a, int b, int c, int d)
diff --git a/gcc/testsuite/gcc.target/i386/funcspec-56.inc
b/gcc/testsuite/gcc.target/i386/funcspec-56.inc
index 2a50f5bf67c..8825e88768a 100644
--- a/gcc/testsuite/gcc.target/i386/funcspec-56.inc
+++ b/gcc/testsuite/gcc.target/i386/funcspec-56.inc
@@ -69,7 +69,6 @@ extern void test_avx512vp2intersect (void)
__attribute__((__target__("avx512vp2i
extern void test_amx_tile (void)
__attribute__((__target__("amx-tile")));
extern void test_amx_int8 (void)
__attribute__((__target__("amx-int8")));
extern void test_amx_bf16 (void)
__attribute__((__target__("amx-bf16")));
-extern void test_uintr (void)
__attribute__((__target__("uintr")));
extern void test_hreset (void)
__attribute__((__target__("hreset")));
extern void test_keylocker (void)
__attribute__((__target__("kl")));
extern void test_widekl (void)
__attribute__((__target__("widekl")));
@@ -158,7 +157,6 @@ extern void test_no_avx512vp2intersect (void)
__attribute__((__target__("no-avx5
extern void test_no_amx_tile (void)
__attribute__((__target__("no-amx-tile")));
extern void test_no_amx_int8 (void)
__attribute__((__target__("no-amx-int8")));
extern void test_no_amx_bf16 (void)
__attribute__((__target__("no-amx-bf16")));
-extern void test_no_uintr (void)
__attribute__((__target__("no-uintr")));
extern void test_no_hreset (void)
__attribute__((__target__("no-hreset")));
extern void test_no_keylocker (void)
__attribute__((__target__("no-kl")));
extern void test_no_widekl (void)
__attribute__((__target__("no-widekl")));
diff --git a/gcc/testsuite/gcc.target/i386/funcspec-6.c
b/gcc/testsuite/gcc.target/i386/funcspec-6.c
index ea896b7ebfd..033c9a50e23 100644
--- a/gcc/testsuite/gcc.target/i386/funcspec-6.c
+++
Re: [pushed] readings: Drop FORTRAN 77 test suite at itl.nist.gov
On 6/18/24 10:20 AM, Steve Kargl wrote: On Tue, Jun 18, 2024 at 09:13:23AM +0200, Gerald Pfeifer wrote: The original subsite has disappeared and we couldn't find it elsewhere. https://github.com/gklimowicz/FCVS gklimowicz is a flang developer and member of J3. FWIW my copy of the tests still pass: --- snip --- FM921 compiles and runs OK ***FM922*** FM922 compiles and runs OK ***FM923*** FM923 compiles and runs OK The logfile is nist.log 0 compilation errors or warnings 0 load and link errors 0 runtime errors 192 completely successful
Re: [PATCH] [testsuite] [arm] [vect] adjust mve-vshr test [PR113281]
On 13/06/2024 10:23, Alexandre Oliva wrote:
>
> The test was too optimistic, alas. We used to vectorize shifts
> involving 8-bit and 16-bit integral types by clamping the shift count
> at the highest in-range shift count, but that was not correct: such
> narrow shifts expect integral promotion, so larger shift counts should
> be accepted. (int16_t)32768 >> (int16_t)16 must yield 0, not 1 (as
> before the fix).
>
> Unfortunately, in the gimple model of vector units, such large shift
> counts wouldn't be well-defined, so we won't vectorize such shifts any
> more, unless we can tell they're in range or undefined.
>
> So the test that expected the incorrect clamping we no longer perform
> needs to be adjusted.
>
> Tested on x86_64-linux-gnu-x-arm-eabi. Also tested with gcc-13
> x-arm-vx7r2. Ok to install?
>
>
> for gcc/testsuite/ChangeLog
>
> PR tree-optimization/113281
> * gcc.target/arm/simd/mve-vshr.c: Adjust expectations.
> ---
> gcc/testsuite/gcc.target/arm/simd/mve-vshr.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
> b/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
> index 8c7adef9ed8f1..8253427db6ef6 100644
> --- a/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
> +++ b/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
> @@ -56,9 +56,9 @@ FUNC_IMM(u, uint, 8, 16, >>, vshrimm)
> /* MVE has only 128-bit vectors, so we can vectorize only half of the
> functions above. */
> /* Vector right shifts use vneg and left shifts. */
> -/* { dg-final { scan-assembler-times {vshl.s[0-9]+\tq[0-9]+, q[0-9]+} 3 } }
> */
> -/* { dg-final { scan-assembler-times {vshl.u[0-9]+\tq[0-9]+, q[0-9]+} 3 } }
> */
> -/* { dg-final { scan-assembler-times {vneg.s[0-9]+\tq[0-9]+, q[0-9]+} 6 } }
> */
> +/* { dg-final { scan-assembler-times {vshl.s[0-9]+\tq[0-9]+, q[0-9]+} 1 } }
> */
> +/* { dg-final { scan-assembler-times {vshl.u[0-9]+\tq[0-9]+, q[0-9]+} 1 } }
> */
> +/* { dg-final { scan-assembler-times {vneg.s[0-9]+\tq[0-9]+, q[0-9]+} 2 } }
> */
>
>
> /* Shift by immediate. */
>
>
We know the range of the LHS of the shift operand (it comes from a T* array, so
that isn't the issue. The problem comes from the RHS of the shift where the
range can legitimately come from 0..31 (since the shift is conceptually
performed at int precision). That can't be handled correctly as gimple only
supports shifts on the number of bits in the type, itself. But we can inform
the compiler that it needn't care about the larger range with a
__builtin_unreachable().
It looks like adding
if ((unsigned)b[i] >= 8*sizeof (TYPE##BITS##_t)) \
__builtin_unreachable(); \
to the shift-by-variable case is enough to tell the vectorizer that it's safe
to vectorize this code without needing to handle any additional clamping.
Since this test is primarily about testing the MVE vector operations, I think
I'd rather go with a solution along those lines rather than nobbling the test.
Thoughts?
R.
[PATCH] libstdc++: testsuite: Skip atomics test if there's no -latomic
On arm-none-eabi, 29_atomics/atomic_float/compare_exchange_padding.cc
fails to build:
FAIL: 29_atomics/atomic_float/compare_exchange_padding.cc -std=gnu++20 (test
for excess errors)
Excess errors:
/home/bauermann/.cache/builds/combined-tree-thumb-m55-hard-eabi/ld/.libs/ld-new:
cannot find -latomic: No such file or directory
collect2: error: ld returned 1 exit status
UNRESOLVED: 29_atomics/atomic_float/compare_exchange_padding.cc -std=gnu++20
compilation failed to produce executable
This test should be skipped if libatomic is not available for the
target. To that end, add dg-require-libatomic-available and use it in
29_atomics/atomic_float/compare_exchange_padding.cc.
Also, check_effective_target_libatomic_available is fixed to use
atomic_link_flags to properly compile the test executable.
Tested on:
- Host x86_64-linux-gnu, target arm-unknown-eabi
- Native aarch64-linux-gnu
- Native x86_64-linux-gnu
gcc/testsuite/
* lib/target-supports-dg.exp (dg-require-libatomic-available):
New procedure.
* lib/target-supports.exp (check_effective_target_libatomic_available):
Use atomic_link_flags.
libstdc++-v3/
* testsuite/29_atomics/atomic_float/compare_exchange_padding.cc:
Use dg-require-libatomic-available.
---
gcc/testsuite/lib/target-supports-dg.exp | 9 +
gcc/testsuite/lib/target-supports.exp| 2 +-
.../29_atomics/atomic_float/compare_exchange_padding.cc | 1 +
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/lib/target-supports-dg.exp
b/gcc/testsuite/lib/target-supports-dg.exp
index 6dce9fdc1ce2..502e4e22b368 100644
--- a/gcc/testsuite/lib/target-supports-dg.exp
+++ b/gcc/testsuite/lib/target-supports-dg.exp
@@ -698,3 +698,12 @@ proc dg-require-prog-name-available { args } {
}
}
+# If the atomic library is supported on this target, skip this test.
+
+proc dg-require-libatomic-available { args } {
+set libatomic_available [check_effective_target_libatomic_available]
+if { $libatomic_available == 0 } {
+ upvar dg-do-what dg-do-what
+ set dg-do-what [list [lindex ${dg-do-what} 0] "N" "P"]
+}
+}
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index e307f4e69efb..de27297c1787 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -1662,7 +1662,7 @@ proc check_iconv_available { test_what } {
proc check_effective_target_libatomic_available { } {
return [check_no_compiler_messages libatomic_available executable {
int main (void) { return 0; }
-} "-latomic"]
+} "[atomic_link_flags [get_multilibs]] -latomic"]
}
# Return 1 if an ASCII locale is supported on this host, 0 otherwise.
diff --git
a/libstdc++-v3/testsuite/29_atomics/atomic_float/compare_exchange_padding.cc
b/libstdc++-v3/testsuite/29_atomics/atomic_float/compare_exchange_padding.cc
index 49626ac66511..351244b25279 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic_float/compare_exchange_padding.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic_float/compare_exchange_padding.cc
@@ -1,4 +1,5 @@
// { dg-do run { target c++20 } }
+// { dg-require-libatomic-available "" }
// { dg-options "-O0" }
// { dg-additional-options "[atomic_link_flags [get_multilibs]] -latomic" }
Re: [pushed] readings: Drop FORTRAN 77 test suite at itl.nist.gov
On Tue, Jun 18, 2024 at 09:13:23AM +0200, Gerald Pfeifer wrote: > The original subsite has disappeared and we couldn't find it elsewhere. > https://github.com/gklimowicz/FCVS gklimowicz is a flang developer and member of J3. -- Steve
[r15-1394 Regression] FAIL: gcc.dg/pr115109.c (test for excess errors) on Linux/x86_64
On Linux/x86_64,
c9b96a68860bfdee49d40b4a844af7c5ef69cd12 is the first bad commit
commit c9b96a68860bfdee49d40b4a844af7c5ef69cd12
Author: Martin Uecker
Date: Sat May 18 22:00:04 2024 +0200
c23: Fix for redeclared enumerator initialized with different type
[PR115109]
caused
FAIL: gcc.dg/c23-tag-enum-6.c (test for errors, line 10)
FAIL: gcc.dg/c23-tag-enum-6.c (test for errors, line 13)
FAIL: gcc.dg/c23-tag-enum-7.c (test for excess errors)
FAIL: gcc.dg/pr115109.c (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-1394/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/c23-tag-enum-6.c
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/c23-tag-enum-6.c
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/c23-tag-enum-7.c
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/c23-tag-enum-7.c
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/pr115109.c
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/pr115109.c
--target_board='unix{-m32\ -march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at haochen dot jiang at intel.com.)
(If you met problems with cascadelake related, disabling AVX512F in command
line might save that.)
(However, please make sure that there is no potential problems with AVX512.)
[RFC] MIPS: Use SLL+BGEZ for one bit test on pre-R2
PR target/111376.
Currently, we are using LUI/ANDI/BEQZ for on-bit-test if the bitpos>=16,
while in fact we can use SLL/BGEZ.
Note:
1) if bitpos<16, we can use ANDI/BEQZ.
2) For R2+, we have EXT.
Known problems:
1. On some uarch, SLL has more delay, such as 74K:
See the talk in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376.
2. We haven't test it on any real pre-R2 hardware for performance.
So, I request some test here.
---
gcc/config/mips/mips.md | 33 +++
.../gcc.target/mips/mips3-one-bit-test.c | 55 +++
2 files changed, 88 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/mips/mips3-one-bit-test.c
diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md
index 806fd29cf97..508fb1afa6c 100644
--- a/gcc/config/mips/mips.md
+++ b/gcc/config/mips/mips.md
@@ -6256,6 +6256,39 @@ (define_insn "*branch_bit_inverted"
}
[(set_attr "type" "branch")
(set_attr "branch_likely" "no")])
+
+(define_insn_and_split "*branch_on_bit"
+ [(set (pc)
+ (if_then_else
+ (match_operator 0 "equality_operator"
+ [(zero_extract:GPR (match_operand:GPR 2 "register_operand" "d")
+(const_int 1)
+(match_operand:GPR 3 "const_int_operand"))
+(const_int 0)])
+ (label_ref (match_operand 1))
+ (pc)))]
+ "!ISA_HAS_BBIT && !ISA_HAS_EXT_INS && !TARGET_MIPS16 && UINTVAL
(operands[3]) >= 16"
+ "#"
+ "&& !reload_completed"
+ [(set (match_dup 4)
+ (ashift:GPR (match_dup 2) (match_dup 3)))
+ (set (pc)
+ (if_then_else
+ (match_op_dup 0 [(match_dup 4) (const_int 0)])
+ (label_ref (match_operand 1))
+ (pc)))]
+{
+ int shift = GET_MODE_BITSIZE (mode) - 1 - INTVAL (operands[3]);
+ operands[3] = GEN_INT (shift);
+ operands[4] = gen_reg_rtx (mode);
+
+ if (GET_CODE (operands[0]) == EQ)
+operands[0] = gen_rtx_GE (mode, operands[4], const0_rtx);
+ else
+operands[0] = gen_rtx_LT (mode, operands[4], const0_rtx);
+}
+[(set_attr "type" "branch")])
+
;;
;;
diff --git a/gcc/testsuite/gcc.target/mips/mips3-one-bit-test.c
b/gcc/testsuite/gcc.target/mips/mips3-one-bit-test.c
new file mode 100644
index 000..50672e71d73
--- /dev/null
+++ b/gcc/testsuite/gcc.target/mips/mips3-one-bit-test.c
@@ -0,0 +1,55 @@
+/* { dg-options "-mips3 -mgp64" } */
+/* FIXME: -Os fails due to rtx_cost: PR115473. */
+/* { dg-skip-if "code quality test" { *-*-* } { "-O0" "-Os" } { "" } } */
+/* { dg-final { scan-assembler "f32_15:.*andi\t\\\$4,\\\$4,0x8000" } } */
+/* { dg-final { scan-assembler "f32:.*sll\t\\\$4,\\\$4,15" } } */
+/* { dg-final { scan-assembler "f64_15:.*andi\t\\\$4,\\\$4,0x8000" } } */
+/* { dg-final { scan-assembler "f64:.*dsll\t\\\$4,\\\$4,47" } } */
+
+/* Test to make sure we can use sll+bgtz to test one bit.
+ See PR111376. */
+
+int f1();
+int f2();
+
+/* If the bits is < 16, we can use andi+beqz. */
+NOMIPS16 int
+f32_15(int a)
+{
+ int p = (a & (1<<15));
+ if (p)
+return f1();
+ else
+return f2();
+}
+
+/* If the bits >= 16, we can use sll+bgez. */
+NOMIPS16 int
+f32(int a)
+{
+ int p = (a & (1<<16));
+ if (p)
+return f1();
+ else
+return f2();
+}
+
+NOMIPS16 int
+f64_15(long long a)
+{
+ long long p = (a & (1LL<<15));
+ if (p)
+return f1();
+ else
+return f2();
+}
+
+NOMIPS16 int
+f64(long long a)
+{
+ long long p = (a & (1LL<<16));
+ if (p)
+return f1();
+ else
+return f2();
+}
--
2.39.3 (Apple Git-146)
[pushed] readings: Drop FORTRAN 77 test suite at itl.nist.gov
The original subsite has disappeared and we couldn't find it elsewhere. Pushed. Gerald --- htdocs/readings.html | 6 -- 1 file changed, 6 deletions(-) diff --git a/htdocs/readings.html b/htdocs/readings.html index 784a3bd7..ae1b52bb 100644 --- a/htdocs/readings.html +++ b/htdocs/readings.html @@ -423,12 +423,6 @@ names. Testing and Validation - Some packages aimed at Fortran compiler validation. - -https://www.itl.nist.gov/div897/ctg/fortran_form.htm;>FORTRAN -77 test suite by the NIST Information Technology Laboratory -(https://www.itl.nist.gov/div897/ctg/software.htm;>license) -contains legal and operational Fortran 77 code. - The g77 testsuite (which is part of GCC). -- 2.45.2
Re: [committed] testsuite: Add -Wno-psabi to vshuf-mem.C test
On 6/14/24 20:03, Jakub Jelinek wrote:
Also wonder about the
// { dg-additional-options "-march=z14" { target s390*-*-* } }
line, doesn't that mean the test will FAIL on all pre-z14 HW?
Shouldn't it use some z14_runtime or similar effective target, or
check in main (in that case copied over to g++.target/s390) whether
z14 instructions can be actually used at runtime?
Oh right. I'll remove that line and replicate the testcase in the arch
specific test dir.
Andreas
Re: [Patch, Fortran, 96418] Fix Test coarray_alloc_comp_4.f08 ICEs
Hi Andre, Am 17.06.24 um 09:51 schrieb Andre Vehreschild: Regarding your question on the coarray-tests that are not in the coarray-directory: These test in most cases test only one method of implementing coarrays. I.e., they are either testing just -fcoarray=single or -fcoarray=lib -lcaf_single, which are two different approaches. The tests in the coarray-directory test all available methods to implement coarrays. Pushing ah, that explains it. I only looked at some of the test sources, but did not think of looking at caf.exp ... all coarray-tests into the coarray-directory will fail a lot of them, because the behavior of -fcoarray=single and -fcoarray=lib -lcaf_single is different in some corner cases. That's why the coarray-tests in the main gfortran-dir are separate. I do understand why it may be confusing, but I don't see an easy solution. Does this answer your question? Indeed it does! Thanks, Harald
Re: [committed] testsuite: Add -Wno-psabi to vshuf-mem.C test
On Mon, Jun 17, 2024 at 09:09:37PM +0200, Andreas Krebbel wrote:
> On 6/14/24 20:03, Jakub Jelinek wrote:
> > Also wonder about the
> > // { dg-additional-options "-march=z14" { target s390*-*-* } }
> > line, doesn't that mean the test will FAIL on all pre-z14 HW?
> > Shouldn't it use some z14_runtime or similar effective target, or
> > check in main (in that case copied over to g++.target/s390) whether
> > z14 instructions can be actually used at runtime?
>
> Oh right. I'll remove that line and replicate the testcase in the arch
> specific test dir.
Though, looking around some more, perhaps
// { dg-additional-options "-march=z14" { target s390_vxe } }
might be all that is needed, even in current dir.
Jakub
[PATCH Committed][APX ZU] Fix test for target-support check
Fix test for APX ZU. Add attribute for no-inline and target APX, and
target-support check.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Committed as an obvious patch.
gcc/testsuite/ChangeLog:
* gcc.target/i386/apx-zu-1.c: Add attribute for noinline,
and target apx.
* gcc.target/i386/apx-zu-2.c: Add target-support check.
---
gcc/testsuite/gcc.target/i386/apx-zu-1.c | 6 ++
gcc/testsuite/gcc.target/i386/apx-zu-2.c | 3 +++
2 files changed, 9 insertions(+)
diff --git a/gcc/testsuite/gcc.target/i386/apx-zu-1.c
b/gcc/testsuite/gcc.target/i386/apx-zu-1.c
index 927a87673a7..bc0e7fbb4dd 100644
--- a/gcc/testsuite/gcc.target/i386/apx-zu-1.c
+++ b/gcc/testsuite/gcc.target/i386/apx-zu-1.c
@@ -9,26 +9,32 @@
/* { dg-final { scan-assembler-times "setzue" 1} } */
/* { dg-final { scan-assembler-times "setzuge" 1} } */
/* { dg-final { scan-assembler "imulzu"} } */
+
+__attribute__((noinline, noclone, target("apxf")))
long long foo0 (int a)
{
return a == 0 ? 0 : 1;
}
+__attribute__((noinline, noclone, target("apxf")))
long foo1 (int a, int b)
{
return a > b ? 0 : 1;
}
+__attribute__((noinline, noclone, target("apxf")))
int foo2 (int a, int b)
{
return a != b ? 0 : 1;
}
+__attribute__((noinline, noclone, target("apxf")))
short foo3 (int a, int b)
{
return a < b ? 0 : 1;
}
+__attribute__((noinline, noclone, target("apxf")))
unsigned long
f1(unsigned short x)
{
diff --git a/gcc/testsuite/gcc.target/i386/apx-zu-2.c
b/gcc/testsuite/gcc.target/i386/apx-zu-2.c
index 3ee04495d98..7585492bd7c 100644
--- a/gcc/testsuite/gcc.target/i386/apx-zu-2.c
+++ b/gcc/testsuite/gcc.target/i386/apx-zu-2.c
@@ -5,6 +5,9 @@
int main(void)
{
+ if (!__builtin_cpu_supports ("apxf"))
+return 0;
+
if (foo0 (0))
__builtin_abort ();
if (foo1 (3, 2))
--
2.31.1
Re: [Patch, Fortran, 96418] Fix Test coarray_alloc_comp_4.f08 ICEs
Hi Harald, thank you very much for the review. Committed as: gcc-15-1369-gdb75a6657e9 Regarding your question on the coarray-tests that are not in the coarray-directory: These test in most cases test only one method of implementing coarrays. I.e., they are either testing just -fcoarray=single or -fcoarray=lib -lcaf_single, which are two different approaches. The tests in the coarray-directory test all available methods to implement coarrays. Pushing all coarray-tests into the coarray-directory will fail a lot of them, because the behavior of -fcoarray=single and -fcoarray=lib -lcaf_single is different in some corner cases. That's why the coarray-tests in the main gfortran-dir are separate. I do understand why it may be confusing, but I don't see an easy solution. Does this answer your question? Thanks again for the review. Regards, Andre On Fri, 14 Jun 2024 21:43:47 +0200 Harald Anlauf wrote: > Hi Andre, > > the patch looks fairly simple and obvious, so OK from my side. > > *** > > Regarding the testsuite: since you renamed one of the testcases > gfortran.dg/coarray_alloc_comp_* and moved it to gfortran.dg/coarray/, > I checked and noticed that there are other similar runtime tests for > coarrays (while some are compile-time only tests). > > Do we plan to "clean" this up and move more/all related runtime > tests to the coarray/ subdirectory? What is the general opinion on > this? > > *** > > Thanks for the patch! > > Harald > > > Am 14.06.24 um 09:22 schrieb Andre Vehreschild: > > Hi all, > > > > I messed up renaming of the coarray_alloc_comp-test. This is fixed in the > > second version of the patch. Sorry for the inconvenience. > > > > Additionally I figured that this patch also fixed PR fortran/103112. > > > > Regtests ok on x86_64 Fedora 39. Ok for mainline? > > > > Regards, > > Andre > > > > On Tue, 11 Jun 2024 16:12:38 +0200 > > Andre Vehreschild wrote: > > > >> Hi all, > >> > >> attached patch has already been present in 2020, but lost my attention. It > >> fixes an ICE in the testsuite. The old mails description is: > >> > >> attached patch fixes PR96418 where the code in the testsuite when compiled > >> with -fcoarray=single lead to an ICE. The reason was that the coarray > >> object was derefed as an array, but it was no array. Introducing the test > >> for the descriptor removes the ICE. > >> > >> Regtests ok on x86_64-linux/Fedora 39. Ok for mainline? > >> > >> Regards, > >>Andre > >> -- > >> Andre Vehreschild * Email: vehre ad gmx dot de > > > > > > -- > > Andre Vehreschild * Email: vehre ad gmx dot de > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [PATCH v1] RISC-V: Refine the SAT_ARITH test help header files [NFC]
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-06-15 10:44
To: gcc-patches
CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; Pan Li
Subject: [PATCH v1] RISC-V: Refine the SAT_ARITH test help header files [NFC]
From: Pan Li
Separate the vector part code to one standalone header file, which
is independent with the scalar part.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-1.c: Leverage
the new header file for vector part.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-4.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-run-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-run-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-run-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-run-4.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-4.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-run-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-run-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-run-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-run-4.c: Ditto.
* gcc.target/riscv/sat_arith.h: Move vector part out.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_arith.h: New test.
Signed-off-by: Pan Li
---
.../riscv/rvv/autovec/binop/vec_sat_arith.h | 59 +++
.../riscv/rvv/autovec/binop/vec_sat_u_add-1.c | 2 +-
.../riscv/rvv/autovec/binop/vec_sat_u_add-2.c | 2 +-
.../riscv/rvv/autovec/binop/vec_sat_u_add-3.c | 2 +-
.../riscv/rvv/autovec/binop/vec_sat_u_add-4.c | 2 +-
.../rvv/autovec/binop/vec_sat_u_add-run-1.c | 2 +-
.../rvv/autovec/binop/vec_sat_u_add-run-2.c | 2 +-
.../rvv/autovec/binop/vec_sat_u_add-run-3.c | 2 +-
.../rvv/autovec/binop/vec_sat_u_add-run-4.c | 2 +-
.../riscv/rvv/autovec/binop/vec_sat_u_sub-1.c | 2 +-
.../riscv/rvv/autovec/binop/vec_sat_u_sub-2.c | 2 +-
.../riscv/rvv/autovec/binop/vec_sat_u_sub-3.c | 2 +-
.../riscv/rvv/autovec/binop/vec_sat_u_sub-4.c | 2 +-
.../rvv/autovec/binop/vec_sat_u_sub-run-1.c | 2 +-
.../rvv/autovec/binop/vec_sat_u_sub-run-2.c | 2 +-
.../rvv/autovec/binop/vec_sat_u_sub-run-3.c | 2 +-
.../rvv/autovec/binop/vec_sat_u_sub-run-4.c | 2 +-
gcc/testsuite/gcc.target/riscv/sat_arith.h| 57 ++
18 files changed, 80 insertions(+), 68 deletions(-)
create mode 100644
gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vec_sat_arith.h
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vec_sat_arith.h
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vec_sat_arith.h
new file mode 100644
index 000..450f0fbbc72
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vec_sat_arith.h
@@ -0,0 +1,59 @@
+#ifndef HAVE_VEC_SAT_ARITH
+#define HAVE_VEC_SAT_ARITH
+
+#include
+
+/**/
+/* Saturation Add (unsigned and signed)
*/
+/**/
+#define DEF_VEC_SAT_U_ADD_FMT_1(T) \
+void __attribute__((noinline)) \
+vec_sat_u_add_##T##_fmt_1 (T *out, T *op_1, T *op_2, unsigned limit) \
+{\
+ unsigned i;\
+ for (i = 0; i < limit; i++)\
+{\
+ T x = op_1[i]; \
+ T y = op_2[i]; \
+ out[i] = (x + y) | (-(T)((T)(x + y) < x)); \
+}\
+}
+
+#define RUN_VEC_SAT_U_ADD_FMT_1(T, out, op_1, op_2, N) \
+ vec_sat_u_add_##T##_fmt_1(out, op_1, op_2, N)
+
+/**/
+/* Saturation Sub (Unsigned and Signed)
*/
+/**/
+#define DEF_VEC_SAT_U_SUB_FMT_1(T) \
+void __attribute__((noinline)) \
+vec_sat_u_sub_##T##_fmt_1 (T *out, T *op_1, T *op_2, unsigned limit) \
+{\
+ unsigned i;\
+ for (i = 0; i <
[PATCH v1] RISC-V: Refine the SAT_ARITH test help header files [NFC]
From: Pan Li
Separate the vector part code to one standalone header file, which
is independent with the scalar part.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-1.c: Leverage
the new header file for vector part.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-4.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-run-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-run-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-run-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-run-4.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-4.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-run-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-run-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-run-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-run-4.c: Ditto.
* gcc.target/riscv/sat_arith.h: Move vector part out.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_arith.h: New test.
Signed-off-by: Pan Li
---
.../riscv/rvv/autovec/binop/vec_sat_arith.h | 59 +++
.../riscv/rvv/autovec/binop/vec_sat_u_add-1.c | 2 +-
.../riscv/rvv/autovec/binop/vec_sat_u_add-2.c | 2 +-
.../riscv/rvv/autovec/binop/vec_sat_u_add-3.c | 2 +-
.../riscv/rvv/autovec/binop/vec_sat_u_add-4.c | 2 +-
.../rvv/autovec/binop/vec_sat_u_add-run-1.c | 2 +-
.../rvv/autovec/binop/vec_sat_u_add-run-2.c | 2 +-
.../rvv/autovec/binop/vec_sat_u_add-run-3.c | 2 +-
.../rvv/autovec/binop/vec_sat_u_add-run-4.c | 2 +-
.../riscv/rvv/autovec/binop/vec_sat_u_sub-1.c | 2 +-
.../riscv/rvv/autovec/binop/vec_sat_u_sub-2.c | 2 +-
.../riscv/rvv/autovec/binop/vec_sat_u_sub-3.c | 2 +-
.../riscv/rvv/autovec/binop/vec_sat_u_sub-4.c | 2 +-
.../rvv/autovec/binop/vec_sat_u_sub-run-1.c | 2 +-
.../rvv/autovec/binop/vec_sat_u_sub-run-2.c | 2 +-
.../rvv/autovec/binop/vec_sat_u_sub-run-3.c | 2 +-
.../rvv/autovec/binop/vec_sat_u_sub-run-4.c | 2 +-
gcc/testsuite/gcc.target/riscv/sat_arith.h| 57 ++
18 files changed, 80 insertions(+), 68 deletions(-)
create mode 100644
gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vec_sat_arith.h
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vec_sat_arith.h
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vec_sat_arith.h
new file mode 100644
index 000..450f0fbbc72
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vec_sat_arith.h
@@ -0,0 +1,59 @@
+#ifndef HAVE_VEC_SAT_ARITH
+#define HAVE_VEC_SAT_ARITH
+
+#include
+
+/**/
+/* Saturation Add (unsigned and signed)
*/
+/**/
+#define DEF_VEC_SAT_U_ADD_FMT_1(T) \
+void __attribute__((noinline)) \
+vec_sat_u_add_##T##_fmt_1 (T *out, T *op_1, T *op_2, unsigned limit) \
+{\
+ unsigned i;\
+ for (i = 0; i < limit; i++)\
+{\
+ T x = op_1[i]; \
+ T y = op_2[i]; \
+ out[i] = (x + y) | (-(T)((T)(x + y) < x)); \
+}\
+}
+
+#define RUN_VEC_SAT_U_ADD_FMT_1(T, out, op_1, op_2, N) \
+ vec_sat_u_add_##T##_fmt_1(out, op_1, op_2, N)
+
+/**/
+/* Saturation Sub (Unsigned and Signed)
*/
+/**/
+#define DEF_VEC_SAT_U_SUB_FMT_1(T) \
+void __attribute__((noinline)) \
+vec_sat_u_sub_##T##_fmt_1 (T *out, T *op_1, T *op_2, unsigned limit) \
+{\
+ unsigned i;\
+ for (i = 0; i < limit; i++)\
+{\
+ T x
Re: [Patch, Fortran, 96418] Fix Test coarray_alloc_comp_4.f08 ICEs
Hi Andre, the patch looks fairly simple and obvious, so OK from my side. *** Regarding the testsuite: since you renamed one of the testcases gfortran.dg/coarray_alloc_comp_* and moved it to gfortran.dg/coarray/, I checked and noticed that there are other similar runtime tests for coarrays (while some are compile-time only tests). Do we plan to "clean" this up and move more/all related runtime tests to the coarray/ subdirectory? What is the general opinion on this? *** Thanks for the patch! Harald Am 14.06.24 um 09:22 schrieb Andre Vehreschild: Hi all, I messed up renaming of the coarray_alloc_comp-test. This is fixed in the second version of the patch. Sorry for the inconvenience. Additionally I figured that this patch also fixed PR fortran/103112. Regtests ok on x86_64 Fedora 39. Ok for mainline? Regards, Andre On Tue, 11 Jun 2024 16:12:38 +0200 Andre Vehreschild wrote: Hi all, attached patch has already been present in 2020, but lost my attention. It fixes an ICE in the testsuite. The old mails description is: attached patch fixes PR96418 where the code in the testsuite when compiled with -fcoarray=single lead to an ICE. The reason was that the coarray object was derefed as an array, but it was no array. Introducing the test for the descriptor removes the ICE. Regtests ok on x86_64-linux/Fedora 39. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de -- Andre Vehreschild * Email: vehre ad gmx dot de
[committed] testsuite: Add -Wno-psabi to vshuf-mem.C test
On Mon, Jun 10, 2024 at 10:06:31AM +0200, Andreas Krebbel wrote:
> The current implementation assumes to always be invoked with register
> operands. For memory operands we even have an instruction
> though (vlrep). With the patch we try this first and only if it fails
> force the input into a register and continue.
>
> vec_splats generation fails for single element 128bit types which are
> allowed for vec_splat. This is something to sort out with another
> patch I guess.
>
> Bootstrapped and regtested on IBM Z. Committed to mainline. Needs to
> be committed to GCC 14 branch as well.
The newly added test FAILs on i686-linux.
On x86_64-linux
make check-g++
RUNTESTFLAGS='--target_board=unix\{-m64,-m32/-msse2,-m32/-mno-sse/-mno-mmx\}
dg-torture.exp=vshuf-mem.C'
shows that as well.
The problem is that without SSE2/MMX the vector is passed differently
than normally and so GCC warns about that.
-Wno-psabi is the usual way to shut it up.
Also wonder about the
// { dg-additional-options "-march=z14" { target s390*-*-* } }
line, doesn't that mean the test will FAIL on all pre-z14 HW?
Shouldn't it use some z14_runtime or similar effective target, or
check in main (in that case copied over to g++.target/s390) whether
z14 instructions can be actually used at runtime?
Tested on x86_64-linux, committed to trunk as obvious.
2024-06-14 Jakub Jelinek
* g++.dg/torture/vshuf-mem.C: Add -Wno-psabi to dg-options.
--- gcc/testsuite/g++.dg/torture/vshuf-mem.C.jj 2024-06-14 19:45:09.116781920
+0200
+++ gcc/testsuite/g++.dg/torture/vshuf-mem.C2024-06-14 19:56:08.744135867
+0200
@@ -1,4 +1,4 @@
-// { dg-options "-std=c++11" }
+// { dg-options "-std=c++11 -Wno-psabi" }
// { dg-do run }
// { dg-additional-options "-march=z14" { target s390*-*-* } }
Jakub
Re: [Patch, Fortran, 96418] Fix Test coarray_alloc_comp_4.f08 ICEs
Hi all,
I messed up renaming of the coarray_alloc_comp-test. This is fixed in the second
version of the patch. Sorry for the inconvenience.
Additionally I figured that this patch also fixed PR fortran/103112.
Regtests ok on x86_64 Fedora 39. Ok for mainline?
Regards,
Andre
On Tue, 11 Jun 2024 16:12:38 +0200
Andre Vehreschild wrote:
> Hi all,
>
> attached patch has already been present in 2020, but lost my attention. It
> fixes an ICE in the testsuite. The old mails description is:
>
> attached patch fixes PR96418 where the code in the testsuite when compiled
> with -fcoarray=single lead to an ICE. The reason was that the coarray object
> was derefed as an array, but it was no array. Introducing the test for the
> descriptor removes the ICE.
>
> Regtests ok on x86_64-linux/Fedora 39. Ok for mainline?
>
> Regards,
> Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 50ed0af756a3eb6b9c95a39c379e1b3f2daf331d Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Tue, 11 Jun 2024 15:24:55 +0200
Subject: [PATCH] Fix ICE when compiling with -fcoarray=single, when derefing a
non-array.
PR fortran/96418
PR fortran/103112
gcc/fortran/ChangeLog:
* trans.c (gfc_deallocate_with_status): Check that object to deref
is an array, before applying array deref.
gcc/testsuite/ChangeLog:
* gfortran.dg/coarray_alloc_comp_3.f08: Moved to...
* gfortran.dg/coarray/alloc_comp_8.f90: ...here.
Should be tested for both -fcoarray=single and lib, resp.
* gfortran.dg/coarray_alloc_comp_4.f08: Fix program name.
---
gcc/fortran/trans.cc | 3 ++-
.../{coarray_alloc_comp_3.f08 => coarray/alloc_comp_8.f90} | 3 +--
gcc/testsuite/gfortran.dg/coarray_alloc_comp_4.f08 | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
rename gcc/testsuite/gfortran.dg/{coarray_alloc_comp_3.f08 => coarray/alloc_comp_8.f90} (95%)
diff --git a/gcc/fortran/trans.cc b/gcc/fortran/trans.cc
index a208afe90ab..1335b8cc48b 100644
--- a/gcc/fortran/trans.cc
+++ b/gcc/fortran/trans.cc
@@ -1838,7 +1838,8 @@ gfc_deallocate_with_status (tree pointer, tree status, tree errmsg,
else
caf_dereg_type = (enum gfc_coarray_deregtype) coarray_dealloc_mode;
}
- else if (flag_coarray == GFC_FCOARRAY_SINGLE)
+ else if (flag_coarray == GFC_FCOARRAY_SINGLE
+ && GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (pointer)))
pointer = gfc_conv_descriptor_data_get (pointer);
}
else if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (pointer)))
diff --git a/gcc/testsuite/gfortran.dg/coarray_alloc_comp_3.f08 b/gcc/testsuite/gfortran.dg/coarray/alloc_comp_8.f90
similarity index 95%
rename from gcc/testsuite/gfortran.dg/coarray_alloc_comp_3.f08
rename to gcc/testsuite/gfortran.dg/coarray/alloc_comp_8.f90
index e2037aa5809..8b153925129 100644
--- a/gcc/testsuite/gfortran.dg/coarray_alloc_comp_3.f08
+++ b/gcc/testsuite/gfortran.dg/coarray/alloc_comp_8.f90
@@ -1,12 +1,11 @@
! { dg-do run }
-! { dg-options "-fcoarray=lib -lcaf_single" }
! { dg-additional-options "-latomic" { target libatomic_available } }
!
! Contributed by Andre Vehreschild
! Check that manually freeing components does not lead to a runtime crash,
! when the auto-deallocation is taking care.
-program coarray_alloc_comp_3
+program alloc_comp_6
implicit none
type dt
diff --git a/gcc/testsuite/gfortran.dg/coarray_alloc_comp_4.f08 b/gcc/testsuite/gfortran.dg/coarray_alloc_comp_4.f08
index 6586ec651dd..4c71a90af8f 100644
--- a/gcc/testsuite/gfortran.dg/coarray_alloc_comp_4.f08
+++ b/gcc/testsuite/gfortran.dg/coarray_alloc_comp_4.f08
@@ -5,7 +5,7 @@
! Contributed by Andre Vehreschild
! Check that sub-components are caf_deregistered and not freed.
-program coarray_alloc_comp_3
+program coarray_alloc_comp_4
implicit none
type dt
--
2.45.1
Re: [PATCH] rs6000, altivec-2-runnable.c should be a runnable test
Hi!
on 2024/6/14 05:16, Carl Love wrote:
> Segher:
>
> On 6/13/24 12:51, Segher Boessenkool wrote:
>
>
>
>>
>>> --- a/gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c
>>> +++ b/gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c
>>> @@ -1,4 +1,4 @@
>>> -/* { dg-do compile { target powerpc*-*-* } } */
>>> +/* { dg-do run { target powerpc*-*-* } } */
>>> /* { dg-options "-mvsx" } */
>>> /* { dg-additional-options "-mdejagnu-cpu=power8" { target { !
>>> has_arch_pwr8 } } } */
>>> /* { dg-require-effective-target powerpc_vsx } */
>>
>> Everything in gcc.target/powerpc/ is tested for "target powerpc*-*-*"
>> already, so you could remove that target clause even (after testing of
>> course :-) )
>>
>> Okay for trunk with or without that extra tweak. Thank you!
>
> I updated the patch by removing the target clause as suggested:
>
> -/* { dg-do compile { target powerpc*-*-* } } */
> +/* { dg-do run } */
> /* { dg-options "-mvsx" } */
> /* { dg-additional-options "-mdejagnu-cpu=power8" { target { ! has_arch_pwr8
> } } } */
> /* { dg-require-effective-target powerpc_vsx } */
Since you changed this for "run", I think you also want s/powerpc_vsx/vsx_hw/ .
BR,
Kewen
>
> Retested on Power 10. Reports 2 passes and no failures. I will go ahead and
> commit.
>
> Thanks.
>
>Carl
Re: [PATCH] rs6000, altivec-2-runnable.c should be a runnable test
Hi,
on 2024/6/14 11:58, Peter Bergner wrote:
> On 6/13/24 9:34 PM, Kewen.Lin wrote:
>> on 2024/6/14 05:16, Carl Love wrote:
>
>>> /* { dg-options "-mvsx" } */
>>> /* { dg-additional-options "-mdejagnu-cpu=power8" { target { !
>>> has_arch_pwr8 } } } */
>
> With the above, we're going to compile and run this test case with
> -mcpu=power8
> or higher, which means we could have P8, P9 or even P10 instructions emitted.
>
>
>
>>> /* { dg-require-effective-target powerpc_vsx } */
>>
>> Since you changed this for "run", I think you also want
>> s/powerpc_vsx/vsx_hw/ .
>
> ...which means we'd need p8vector_hw, p9vector_hw or ... here.
Ah, good catch! Yes, it would require some harder guard.
>
>
> Should we just always compile with -mcpu=power8 and then check for p8vector_hw
> to make our lives easier? Ala...
>
>
>/* { dg-options "-mdejagnu-cpu=power8" } */
>...
>/* { dg-require-effective-target p8vector_hw } */
>
>
> Note I've removed -mvsx, since that is implied by -mcpu=power8 and no
> need for dg-additional-options. Maybe we want to add -O2 as well?
> Thoughts?
Both sounds reasonable to me, it looks useless to distinguish p8 or p8-up for
this test case.
BR,
Kewen
Re: [PATCH] rs6000, altivec-2-runnable.c should be a runnable test
On 6/13/24 9:34 PM, Kewen.Lin wrote:
> on 2024/6/14 05:16, Carl Love wrote:
>> /* { dg-options "-mvsx" } */
>> /* { dg-additional-options "-mdejagnu-cpu=power8" { target { !
>> has_arch_pwr8 } } } */
With the above, we're going to compile and run this test case with -mcpu=power8
or higher, which means we could have P8, P9 or even P10 instructions emitted.
>> /* { dg-require-effective-target powerpc_vsx } */
>
> Since you changed this for "run", I think you also want s/powerpc_vsx/vsx_hw/
> .
...which means we'd need p8vector_hw, p9vector_hw or ... here.
Should we just always compile with -mcpu=power8 and then check for p8vector_hw
to make our lives easier? Ala...
/* { dg-options "-mdejagnu-cpu=power8" } */
...
/* { dg-require-effective-target p8vector_hw } */
Note I've removed -mvsx, since that is implied by -mcpu=power8 and no
need for dg-additional-options. Maybe we want to add -O2 as well?
Thoughts?
Peter
Re: [PATCH] rs6000, altivec-2-runnable.c should be a runnable test
Segher:
On 6/13/24 12:51, Segher Boessenkool wrote:
>
>> --- a/gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c
>> +++ b/gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c
>> @@ -1,4 +1,4 @@
>> -/* { dg-do compile { target powerpc*-*-* } } */
>> +/* { dg-do run { target powerpc*-*-* } } */
>> /* { dg-options "-mvsx" } */
>> /* { dg-additional-options "-mdejagnu-cpu=power8" { target { !
>> has_arch_pwr8 } } } */
>> /* { dg-require-effective-target powerpc_vsx } */
>
> Everything in gcc.target/powerpc/ is tested for "target powerpc*-*-*"
> already, so you could remove that target clause even (after testing of
> course :-) )
>
> Okay for trunk with or without that extra tweak. Thank you!
I updated the patch by removing the target clause as suggested:
-/* { dg-do compile { target powerpc*-*-* } } */
+/* { dg-do run } */
/* { dg-options "-mvsx" } */
/* { dg-additional-options "-mdejagnu-cpu=power8" { target { ! has_arch_pwr8 }
} } */
/* { dg-require-effective-target powerpc_vsx } */
Retested on Power 10. Reports 2 passes and no failures. I will go ahead and
commit.
Thanks.
Carl
Re: [PATCH] rs6000, altivec-2-runnable.c should be a runnable test
Hi!
On Thu, Jun 13, 2024 at 11:32:58AM -0700, Carl Love wrote:
> The test gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c is supposed to
> be a runnable test
> to verify the execution of the vec_unpackl and vec_unpackh built-ins. The
> dg-do command is set to
> compile not run. This patch fixes the dg-do command argument.
>
> The patch has been verified on a P10. The test runs without errors.
> rs6000, altivec-2-runnable.c should be a runnable test
>
> The test case has "dg-do compile" set not "dg-do run" for a runnable
> test. This patch changes the dg-do command argument to run.
>
> gcc/testsuite/ChangeLog:gcc/testsuite/ChangeLog:
> * gcc.target/powerpc/altivec-2-runnable.c: Change dg-do
> argument to run.
> --- a/gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c
> +++ b/gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c
> @@ -1,4 +1,4 @@
> -/* { dg-do compile { target powerpc*-*-* } } */
> +/* { dg-do run { target powerpc*-*-* } } */
> /* { dg-options "-mvsx" } */
> /* { dg-additional-options "-mdejagnu-cpu=power8" { target { ! has_arch_pwr8
> } } } */
> /* { dg-require-effective-target powerpc_vsx } */
Everything in gcc.target/powerpc/ is tested for "target powerpc*-*-*"
already, so you could remove that target clause even (after testing of
course :-) )
Okay for trunk with or without that extra tweak. Thank you!
Segher
[PATCH] rs6000, altivec-2-runnable.c should be a runnable test
GCC maintainers:
The test gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c is supposed to
be a runnable test
to verify the execution of the vec_unpackl and vec_unpackh built-ins. The
dg-do command is set to
compile not run. This patch fixes the dg-do command argument.
The patch has been verified on a P10. The test runs without errors.
Please let me know if the patch is acceptable. Thanks.
Carl
-
rs6000, altivec-2-runnable.c should be a runnable test
The test case has "dg-do compile" set not "dg-do run" for a runnable
test. This patch changes the dg-do command argument to run.
gcc/testsuite/ChangeLog:gcc/testsuite/ChangeLog:
* gcc.target/powerpc/altivec-2-runnable.c: Change dg-do
argument to run.
---
gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c
b/gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c
index 6975ea57e65..3e66435d0d2 100644
--- a/gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c
+++ b/gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target powerpc*-*-* } } */
+/* { dg-do run { target powerpc*-*-* } } */
/* { dg-options "-mvsx" } */
/* { dg-additional-options "-mdejagnu-cpu=power8" { target { ! has_arch_pwr8 }
} } */
/* { dg-require-effective-target powerpc_vsx } */
--
2.45.0
[COMMITTED 26/30] ada: Fix test for giving hint on ambiguous aggregate
From: Yannick Moy In the case the type of an aggregate cannot be determined due to an ambiguity, caused by the existence of container aggregates, a hint can be given by GNAT. The test for giving this hint should be the Ada language version, not the fact that extensions are allowed. Now fixed. There is no impact on code generation. gcc/ada/ * sem_util.adb (Check_Ambiguous_Aggregate): Fix test. Tested on x86_64-pc-linux-gnu, committed on master. --- gcc/ada/sem_util.adb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/ada/sem_util.adb b/gcc/ada/sem_util.adb index e8120c2adda..3d12f552f41 100644 --- a/gcc/ada/sem_util.adb +++ b/gcc/ada/sem_util.adb @@ -2387,7 +2387,7 @@ package body Sem_Util is Actual : Node_Id; begin - if All_Extensions_Allowed then + if Ada_Version >= Ada_2022 then Actual := First_Actual (Call); while Present (Actual) loop if Nkind (Actual) = N_Aggregate then -- 2.45.1
[r15-1239 Regression] FAIL: gcc.dg/vect/pr115385.c -flto -ffat-lto-objects execution test on Linux/x86_64
On Linux/x86_64,
6669dc51515313dd1e60c493596dbc90429fc362 is the first bad commit
commit 6669dc51515313dd1e60c493596dbc90429fc362
Author: Richard Biener
Date: Fri Jun 7 14:47:12 2024 +0200
tree-optimization/115385 - handle more gaps with peeling of a single
iteration
caused
FAIL: gcc.dg/vect/pr115385.c execution test
FAIL: gcc.dg/vect/pr115385.c -flto -ffat-lto-objects execution test
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-1239/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="vect.exp=gcc.dg/vect/pr115385.c --target_board='unix{-m32\
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="vect.exp=gcc.dg/vect/pr115385.c --target_board='unix{-m64\
-march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at haochen dot jiang at intel.com.)
(If you met problems with cascadelake related, disabling AVX512F in command
line might save that.)
(However, please make sure that there is no potential problems with AVX512.)
[PATCH] [testsuite] [arm] [vect] adjust mve-vshr test [PR113281]
The test was too optimistic, alas. We used to vectorize shifts
involving 8-bit and 16-bit integral types by clamping the shift count
at the highest in-range shift count, but that was not correct: such
narrow shifts expect integral promotion, so larger shift counts should
be accepted. (int16_t)32768 >> (int16_t)16 must yield 0, not 1 (as
before the fix).
Unfortunately, in the gimple model of vector units, such large shift
counts wouldn't be well-defined, so we won't vectorize such shifts any
more, unless we can tell they're in range or undefined.
So the test that expected the incorrect clamping we no longer perform
needs to be adjusted.
Tested on x86_64-linux-gnu-x-arm-eabi. Also tested with gcc-13
x-arm-vx7r2. Ok to install?
for gcc/testsuite/ChangeLog
PR tree-optimization/113281
* gcc.target/arm/simd/mve-vshr.c: Adjust expectations.
---
gcc/testsuite/gcc.target/arm/simd/mve-vshr.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
b/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
index 8c7adef9ed8f1..8253427db6ef6 100644
--- a/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
+++ b/gcc/testsuite/gcc.target/arm/simd/mve-vshr.c
@@ -56,9 +56,9 @@ FUNC_IMM(u, uint, 8, 16, >>, vshrimm)
/* MVE has only 128-bit vectors, so we can vectorize only half of the
functions above. */
/* Vector right shifts use vneg and left shifts. */
-/* { dg-final { scan-assembler-times {vshl.s[0-9]+\tq[0-9]+, q[0-9]+} 3 } } */
-/* { dg-final { scan-assembler-times {vshl.u[0-9]+\tq[0-9]+, q[0-9]+} 3 } } */
-/* { dg-final { scan-assembler-times {vneg.s[0-9]+\tq[0-9]+, q[0-9]+} 6 } } */
+/* { dg-final { scan-assembler-times {vshl.s[0-9]+\tq[0-9]+, q[0-9]+} 1 } } */
+/* { dg-final { scan-assembler-times {vshl.u[0-9]+\tq[0-9]+, q[0-9]+} 1 } } */
+/* { dg-final { scan-assembler-times {vneg.s[0-9]+\tq[0-9]+, q[0-9]+} 2 } } */
/* Shift by immediate. */
--
Alexandre Oliva, happy hackerhttps://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] Test: Move target independent test cases to gcc.dg/torture
Committed, thanks Jeff. Pan -Original Message- From: Jeff Law Sent: Thursday, June 13, 2024 2:11 AM To: Li, Pan2 ; gcc-patches@gcc.gnu.org Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; richard.guent...@gmail.com; pins...@gmail.com Subject: Re: [PATCH v2] Test: Move target independent test cases to gcc.dg/torture On 6/11/24 8:53 AM, pan2...@intel.com wrote: > From: Pan Li > > The test cases of pr115387 are target independent, at least x86 > and riscv are able to reproduce. Thus, move these cases to > the gcc.dg/torture. > > The below test suites are passed. > 1. The rv64gcv fully regression test. > 2. The x86 fully regression test. > > gcc/testsuite/ChangeLog: > > * gcc.target/riscv/pr115387-1.c: Move to... > * gcc.dg/torture/pr115387-1.c: ...here. > * gcc.target/riscv/pr115387-2.c: Move to... > * gcc.dg/torture/pr115387-2.c: ...here. OK jeff
Re: [PATCH] testsuite: Fix pr66144-3.c test to accept multiple equivalent insns. [PR115262]
On Wed, Jun 12, 2024 at 07:02:31PM -0500, Peter Bergner wrote:
> On 6/12/24 3:00 PM, Segher Boessenkool wrote:
> >> /* { dg-do compile { target { powerpc64*-*-* } } } */
> >
> > Probably should be an "lp64" instead?
>
> Actually, there is nothing inherently 64-bit about the test case.
> I removed the target test altogether and it executes just fine on
> our BE system in both 32-bit and 64-bit modes, so I'll just drop
> the target test as part of the patch.
Ha, even better!
> >> /* { dg-require-effective-target powerpc_vsx } */
> >
> > This isn't needed either.
>
> Maybe not strictly needed, but it shields us from users who force
> some options to be used via RUNTESTFLAGS env var that can cause the
> test case to FAIL. I'm going to leave this for someone else to
> clean up.
Users can make most tests fail in interesting and exciting ways like
that, heh.
In general, only realistic settings are supported: things for which
hardware exists, an OS exists for, etc. With any other settings many
things can fail, and that is Just Fine.
Thanks again,
Segher
Re: [PATCH] testsuite: Fix pr66144-3.c test to accept multiple equivalent insns. [PR115262]
On 6/12/24 3:00 PM, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Jun 12, 2024 at 02:49:40PM -0500, Peter Bergner wrote:
>> testsuite: Fix pr66144-3.c test to accept multiple equivalent insns.
>> [PR115262]
>
> ("rs6000:", not "testsuite")
Done.
>> /* { dg-do compile { target { powerpc64*-*-* } } } */
>
> Probably should be an "lp64" instead?
Actually, there is nothing inherently 64-bit about the test case.
I removed the target test altogether and it executes just fine on
our BE system in both 32-bit and 64-bit modes, so I'll just drop
the target test as part of the patch.
>> -/* { dg-options "-mdejagnu-cpu=power8 -mvsx -O2 -ftree-vectorize" } */
>> +/* { dg-options "-mdejagnu-cpu=power8 -mvsx -O2 -ftree-vectorize
>> -fno-unroll-loops" } */
>
> The "-mvsx" is superfluous btw (implied by -mcpu=power8).
Ok, I removed -mvsx since I'm touching the line already.
>> /* { dg-require-effective-target powerpc_vsx } */
>
> This isn't needed either.
Maybe not strictly needed, but it shields us from users who force
some options to be used via RUNTESTFLAGS env var that can cause the
test case to FAIL. I'm going to leave this for someone else to
clean up.
>> -/* { dg-final { scan-assembler {\mvcmpequw\M} } } */
>> -/* { dg-final { scan-assembler {\mxxsel\M}} } */
>> +/* { dg-final { scan-assembler-times {\mvcmpequw\M} 1 } } */
>> +/* { dg-final { scan-assembler-times {\m(?:xxsel|xxlor|vor)\M} 1 } } */
>> /* { dg-final { scan-assembler-not {\mvspltisw\M} } } */
>> /* { dg-final { scan-assembler-not {\mxxlorc\M} } } */
>
> Okido, thanks! The three trivial tweaks I suggest here are okay as
> well if you want, after testing of course ;-)
Thanks. For completeness, the final patch looks like the following.
Peter
gcc/testsuite/
PR testsuite/115262
* gcc.target/powerpc/pr66144-3.c (dg-do): Compile for all targets.
(dg-options): Add -fno-unroll-loops and remove -mvsx.
(scan-assembler): Change from this...
(scan-assembler-times): ...to this. Tweak regex to accept multiple
allowable instructions.
---
gcc/testsuite/gcc.target/powerpc/pr66144-3.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/testsuite/gcc.target/powerpc/pr66144-3.c
b/gcc/testsuite/gcc.target/powerpc/pr66144-3.c
index 4c93b2a7a3d..14ecb809edc 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr66144-3.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr66144-3.c
@@ -1,5 +1,5 @@
-/* { dg-do compile { target { powerpc64*-*-* } } } */
-/* { dg-options "-mdejagnu-cpu=power8 -mvsx -O2 -ftree-vectorize" } */
+/* { dg-do compile } */
+/* { dg-options "-mdejagnu-cpu=power8 -O2 -ftree-vectorize -fno-unroll-loops"
} */
/* { dg-require-effective-target powerpc_vsx } */
/* Verify that we can optimize a vector conditional move, where one of the arms
@@ -20,7 +20,7 @@ test (void)
a[i] = (b[i] == c[i]) ? -1 : a[i];
}
-/* { dg-final { scan-assembler {\mvcmpequw\M} } } */
-/* { dg-final { scan-assembler {\mxxsel\M}} } */
+/* { dg-final { scan-assembler-times {\mvcmpequw\M} 1 } } */
+/* { dg-final { scan-assembler-times {\m(?:xxsel|xxlor|vor)\M} 1 } } */
/* { dg-final { scan-assembler-not {\mvspltisw\M} } } */
/* { dg-final { scan-assembler-not {\mxxlorc\M} } } */
Re: [PATCH] testsuite: Fix pr66144-3.c test to accept multiple equivalent insns. [PR115262]
Hi!
On Wed, Jun 12, 2024 at 02:49:40PM -0500, Peter Bergner wrote:
> testsuite: Fix pr66144-3.c test to accept multiple equivalent insns.
> [PR115262]
("rs6000:", not "testsuite")
> Jeff's commit r15-831-g05daf617ea22e1 changed the instruction we expected
> for this test case into an equivalent instruction. Modify the test case
> so it will accept any of three equivalent instructions we could get depending
> on the options used.
They aren't equivalent insns, but they are all simple insns, and all
just as cheap :-)
> I've verified this test case PASSes on all scenarios where the three possible
> instructions are generated. Ok for trunk?
> --- a/gcc/testsuite/gcc.target/powerpc/pr66144-3.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr66144-3.c
> @@ -1,5 +1,5 @@
> /* { dg-do compile { target { powerpc64*-*-* } } } */
Probably should be an "lp64" instead?
> -/* { dg-options "-mdejagnu-cpu=power8 -mvsx -O2 -ftree-vectorize" } */
> +/* { dg-options "-mdejagnu-cpu=power8 -mvsx -O2 -ftree-vectorize
> -fno-unroll-loops" } */
The "-mvsx" is superfluous btw (implied by -mcpu=power8).
> /* { dg-require-effective-target powerpc_vsx } */
This isn't needed either.
> -/* { dg-final { scan-assembler {\mvcmpequw\M} } } */
> -/* { dg-final { scan-assembler {\mxxsel\M}} } */
> +/* { dg-final { scan-assembler-times {\mvcmpequw\M} 1 } } */
> +/* { dg-final { scan-assembler-times {\m(?:xxsel|xxlor|vor)\M} 1 } } */
> /* { dg-final { scan-assembler-not {\mvspltisw\M} } } */
> /* { dg-final { scan-assembler-not {\mxxlorc\M} } } */
Okido, thanks! The three trivial tweaks I suggest here are okay as
well if you want, after testing of course ;-)
Segher
[PATCH] testsuite: Fix pr66144-3.c test to accept multiple equivalent insns. [PR115262]
testsuite: Fix pr66144-3.c test to accept multiple equivalent insns. [PR115262]
Jeff's commit r15-831-g05daf617ea22e1 changed the instruction we expected
for this test case into an equivalent instruction. Modify the test case
so it will accept any of three equivalent instructions we could get depending
on the options used.
I've verified this test case PASSes on all scenarios where the three possible
instructions are generated. Ok for trunk?
Peter
2024-06-12 Peter Bergner
gcc/testsuite/
PR testsuite/115262
* gcc.target/powerpc/pr66144-3.c: Add -fno-unroll-loops to options.
(scan-assembler): Change from this...
(scan-assembler-times): ...to this. Tweak regex to accept multiple
equivalent instructions.
diff --git a/gcc/testsuite/gcc.target/powerpc/pr66144-3.c
b/gcc/testsuite/gcc.target/powerpc/pr66144-3.c
index 4c93b2a7a3d..dbd746c5489 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr66144-3.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr66144-3.c
@@ -1,5 +1,5 @@
/* { dg-do compile { target { powerpc64*-*-* } } } */
-/* { dg-options "-mdejagnu-cpu=power8 -mvsx -O2 -ftree-vectorize" } */
+/* { dg-options "-mdejagnu-cpu=power8 -mvsx -O2 -ftree-vectorize
-fno-unroll-loops" } */
/* { dg-require-effective-target powerpc_vsx } */
/* Verify that we can optimize a vector conditional move, where one of the arms
@@ -20,7 +20,7 @@ test (void)
a[i] = (b[i] == c[i]) ? -1 : a[i];
}
-/* { dg-final { scan-assembler {\mvcmpequw\M} } } */
-/* { dg-final { scan-assembler {\mxxsel\M}} } */
+/* { dg-final { scan-assembler-times {\mvcmpequw\M} 1 } } */
+/* { dg-final { scan-assembler-times {\m(?:xxsel|xxlor|vor)\M} 1 } } */
/* { dg-final { scan-assembler-not {\mvspltisw\M} } } */
/* { dg-final { scan-assembler-not {\mxxlorc\M} } } */
Re: [PATCH v2] Test: Move target independent test cases to gcc.dg/torture
On 6/11/24 8:53 AM, pan2...@intel.com wrote: From: Pan Li The test cases of pr115387 are target independent, at least x86 and riscv are able to reproduce. Thus, move these cases to the gcc.dg/torture. The below test suites are passed. 1. The rv64gcv fully regression test. 2. The x86 fully regression test. gcc/testsuite/ChangeLog: * gcc.target/riscv/pr115387-1.c: Move to... * gcc.dg/torture/pr115387-1.c: ...here. * gcc.target/riscv/pr115387-2.c: Move to... * gcc.dg/torture/pr115387-2.c: ...here. OK jeff
Re: [PATCH v3 2/2] testsuite: Fix expand-return CMSE test for Armv8.1-M [PR115253]
On 2024-06-11 16:00, Richard Earnshaw (lists) wrote:
On 10/06/2024 15:04, Torbjörn SVENSSON wrote:
For Armv8.1-M, the clearing of the registers is handled differently than
for Armv8-M, so update the test case accordingly.
gcc/testsuite/ChangeLog:
PR target/115253
* gcc.target/arm/cmse/extend-return.c: Update test case
condition for Armv8.1-M.
Signed-off-by: Torbjörn SVENSSON
Co-authored-by: Yvan ROUX
---
.../gcc.target/arm/cmse/extend-return.c | 62 +--
1 file changed, 56 insertions(+), 6 deletions(-)
diff --git a/gcc/testsuite/gcc.target/arm/cmse/extend-return.c
b/gcc/testsuite/gcc.target/arm/cmse/extend-return.c
index 081de0d699f..2288d166bd3 100644
--- a/gcc/testsuite/gcc.target/arm/cmse/extend-return.c
+++ b/gcc/testsuite/gcc.target/arm/cmse/extend-return.c
@@ -1,5 +1,7 @@
/* { dg-do compile } */
/* { dg-options "-mcmse -fshort-enums" } */
+/* ARMv8-M expectation with target { ! arm_cmse_clear_ok }. */
+/* ARMv8.1-M expectation with target arm_cmse_clear_ok. */
/* { dg-final { check-function-bodies "**" "" "" } } */
#include
@@ -20,7 +22,15 @@ typedef enum offset __attribute__ ((cmse_nonsecure_call))
ns_enum_foo_t (void);
typedef bool __attribute__ ((cmse_nonsecure_call)) ns_bool_foo_t (void);
/*
-**unsignNonsecure0:
+**unsignNonsecure0: { target arm_cmse_clear_ok }
+** ...
+** blxns r[0-3]
+** ...
+** uxtbr0, r0
+** ...
+*/
+/*
+**unsignNonsecure0: { target { ! arm_cmse_clear_ok } }
**...
**bl __gnu_cmse_nonsecure_call
**uxtbr0, r0
@@ -32,7 +42,15 @@ unsigned char unsignNonsecure0 (ns_unsign_foo_t * ns_foo_p)
}
/*
-**signNonsecure0:
+**signNonsecure0: { target arm_cmse_clear_ok }
+** ...
+** blxns r[0-3]
+** ...
+** sxtbr0, r0
+** ...
+*/
+/*
+**signNonsecure0: { target { ! arm_cmse_clear_ok } }
**...
**bl __gnu_cmse_nonsecure_call
**sxtbr0, r0
@@ -44,7 +62,15 @@ signed char signNonsecure0 (ns_sign_foo_t * ns_foo_p)
}
/*
-**shortUnsignNonsecure0:
+**shortUnsignNonsecure0: { target arm_cmse_clear_ok }
+** ...
+** blxns r[0-3]
+** ...
+** uxthr0, r0
+** ...
+*/
+/*
+**shortUnsignNonsecure0: { target { ! arm_cmse_clear_ok } }
**...
**bl __gnu_cmse_nonsecure_call
**uxthr0, r0
@@ -56,7 +82,15 @@ unsigned short shortUnsignNonsecure0 (ns_short_unsign_foo_t
* ns_foo_p)
}
/*
-**shortSignNonsecure0:
+**shortSignNonsecure0: { target arm_cmse_clear_ok }
+** ...
+** blxns r[0-3]
+** ...
+** sxthr0, r0
+** ...
+*/
+/*
+**shortSignNonsecure0: { target { ! arm_cmse_clear_ok } }
**...
**bl __gnu_cmse_nonsecure_call
**sxthr0, r0
@@ -68,7 +102,15 @@ signed short shortSignNonsecure0 (ns_short_sign_foo_t *
ns_foo_p)
}
/*
-**enumNonsecure0:
+**enumNonsecure0: { target arm_cmse_clear_ok }
+** ...
+** blxns r[0-3]
+** ...
+** uxtbr0, r0
+** ...
+*/
+/*
+**enumNonsecure0: { target { ! arm_cmse_clear_ok } }
**...
**bl __gnu_cmse_nonsecure_call
**uxtbr0, r0
@@ -80,7 +122,15 @@ unsigned char __attribute__((noipa)) enumNonsecure0
(ns_enum_foo_t * ns_foo_p)
}
/*
-**boolNonsecure0:
+**boolNonsecure0: { target arm_cmse_clear_ok }
+** ...
+** blxns r[0-3]
+** ...
+** uxtbr0, r0
+** ...
+*/
+/*
+**boolNonsecure0: { target { ! arm_cmse_clear_ok } }
**...
**bl __gnu_cmse_nonsecure_call
**uxtbr0, r0
OK when the nits in the first patch are sorted.
R.
Pushed as:
basepoints/gcc-15-1201-gcf5f9171bae
releases/gcc-14.1.0-134-g9100e78ba28
releases/gcc-13.3.0-64-gdfab6851eb5
releases/gcc-12.3.0-1035-g3d9e4eedb6b
releases/gcc-11.4.0-650-gbf9c877c4c9
Kind regards,
Torbjörn
[PATCH v2] Test: Move target independent test cases to gcc.dg/torture
From: Pan Li
The test cases of pr115387 are target independent, at least x86
and riscv are able to reproduce. Thus, move these cases to
the gcc.dg/torture.
The below test suites are passed.
1. The rv64gcv fully regression test.
2. The x86 fully regression test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr115387-1.c: Move to...
* gcc.dg/torture/pr115387-1.c: ...here.
* gcc.target/riscv/pr115387-2.c: Move to...
* gcc.dg/torture/pr115387-2.c: ...here.
Signed-off-by: Pan Li
---
gcc/testsuite/{gcc.target/riscv => gcc.dg/torture}/pr115387-1.c | 1 -
gcc/testsuite/{gcc.target/riscv => gcc.dg/torture}/pr115387-2.c | 1 -
2 files changed, 2 deletions(-)
rename gcc/testsuite/{gcc.target/riscv => gcc.dg/torture}/pr115387-1.c (92%)
rename gcc/testsuite/{gcc.target/riscv => gcc.dg/torture}/pr115387-2.c (84%)
diff --git a/gcc/testsuite/gcc.target/riscv/pr115387-1.c
b/gcc/testsuite/gcc.dg/torture/pr115387-1.c
similarity index 92%
rename from gcc/testsuite/gcc.target/riscv/pr115387-1.c
rename to gcc/testsuite/gcc.dg/torture/pr115387-1.c
index a1c926977c4..d94e935fade 100644
--- a/gcc/testsuite/gcc.target/riscv/pr115387-1.c
+++ b/gcc/testsuite/gcc.dg/torture/pr115387-1.c
@@ -1,6 +1,5 @@
/* Test there is no ICE when compile. */
/* { dg-do compile } */
-/* { dg-options "-march=rv64gcv -mabi=lp64d -O3" } */
#define PRINTF_CHK 0x34
diff --git a/gcc/testsuite/gcc.target/riscv/pr115387-2.c
b/gcc/testsuite/gcc.dg/torture/pr115387-2.c
similarity index 84%
rename from gcc/testsuite/gcc.target/riscv/pr115387-2.c
rename to gcc/testsuite/gcc.dg/torture/pr115387-2.c
index 7183bf18dfd..9e93024b45c 100644
--- a/gcc/testsuite/gcc.target/riscv/pr115387-2.c
+++ b/gcc/testsuite/gcc.dg/torture/pr115387-2.c
@@ -1,6 +1,5 @@
/* Test there is no ICE when compile. */
/* { dg-do compile } */
-/* { dg-options "-march=rv64gcv -mabi=lp64d -O3" } */
#include
#include
--
2.34.1
