[RFC/RFA] [PATCH v4 07/12] aarch64: Add CRC built-ins test for the target AES.

2024-09-13 Thread Mariam Arutunian
  gcc/testsuite/gcc.target/aarch64/

* crc-builtin-pmul64.c: New test.

Signed-off-by: Mariam Arutunian 
---
 .../gcc.target/aarch64/crc-builtin-pmul64.c   | 61 +++
 1 file changed, 61 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/crc-builtin-pmul64.c

diff --git a/gcc/testsuite/gcc.target/aarch64/crc-builtin-pmul64.c b/gcc/testsuite/gcc.target/aarch64/crc-builtin-pmul64.c
new file mode 100644
index 000..d8bb1724a65
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/crc-builtin-pmul64.c
@@ -0,0 +1,61 @@
+/* { dg-options "-march=armv8-a+crypto" } */
+
+#include 
+int8_t crc8_data8 ()
+{
+  return __builtin_crc8_data8 ('a', 0xff, 0x12);
+}
+int16_t crc16_data8 ()
+{
+  return __builtin_crc16_data8 (0x1234, 'a', 0x1021);
+}
+
+int16_t crc16_data16 ()
+{
+  return __builtin_crc16_data16 (0x1234, 0x3214, 0x1021);
+}
+
+int32_t crc32_data8 ()
+{
+  return __builtin_crc32_data8 (0x, 0x32, 0x4002123);
+}
+int32_t crc32_data16 ()
+{
+  return __builtin_crc32_data16 (0x, 0x3232, 0x4002123);
+}
+
+int32_t crc32_data32 ()
+{
+  return __builtin_crc32_data32 (0x, 0x123546ff, 0x4002123);
+}
+
+int8_t rev_crc8_data8 ()
+{
+  return __builtin_rev_crc8_data8 (0x34, 'a', 0x12);
+}
+
+int16_t rev_crc16_data8 ()
+{
+  return __builtin_rev_crc16_data8 (0x1234, 'a', 0x1021);
+}
+
+int16_t rev_crc16_data16 ()
+{
+  return __builtin_rev_crc16_data16 (0x1234, 0x3214, 0x1021);
+}
+
+int32_t rev_crc32_data8 ()
+{
+  return __builtin_rev_crc32_data8 (0x, 0x32, 0x4002123);
+}
+
+int32_t rev_crc32_data16 ()
+{
+  return __builtin_rev_crc32_data16 (0x, 0x3232, 0x4002123);
+}
+
+int32_t rev_crc32_data32 ()
+{
+  return __builtin_rev_crc32_data32 (0x, 0x123546ff, 0x4002123);
+} 
+/* { dg-final { scan-assembler-times "pmull" 24 } } */
\ No newline at end of file
-- 
2.25.1



Re: [PATCH 04/11] AArch64: Test OpenMP lastprivate clause for various constructs.

2024-09-13 Thread Tejas Belagod

On 8/6/24 4:59 PM, Jakub Jelinek wrote:

On Mon, May 27, 2024 at 10:36:19AM +0530, Tejas Belagod wrote:

This patch tests various OpenMP lastprivate clause with SVE object types in
various construct contexts.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/sve/omp/lastprivate.c: New test.


This is a dg-do compile test, so it could be in gcc.target/aarch64/sve/gomp/

Generally I'd suggest not to mix erroneous constructs with correct ones,
so that the correct ones can be tested up to assembly generation (or runtime
if needed), which might not be the case when there are errors in the same
testcase.
Furethermore, I think it would be useful to actually test the behavior
of lastprviate even for the constructs where you have error now, so
in lastprivate-1.c include say #pragma omp parallel sections lastprivate (va)
rather than just #pragma omp sections lastprivate (va) or the latter
if it is nested inside of #pragma omp parallel (and va is shared there).



Thanks for the reviews.


+/* This worksharing construct binds to an implicit outer parallel region in
+whose scope va is declared and therefore is default private.  This causes
+the lastprivate clause list item va to be diagnosed as private in the outer
+context.  Similarly for constructs for and distribute.  */
+#pragma omp sections lastprivate (va) /* { dg-error {lastprivate variable 'va' 
is private in outer context} } */
+{
+  #pragma omp section
+  vb = svld1_s32 (svptrue_b32 (), b);
+  #pragma omp section
+  vc = svld1_s32 (svptrue_b32 (), c);
+  #pragma omp section
+  va = svadd_s32_z (svptrue_b32 (), vb, vc);
+}


Note, unless you know this is included in implicit parallel region with a
single thread, this isn't really valid.  The sections directive is user
explicitly saying that there are no dependencies between the 3 sections
here, which is clearly not the case, the first two compute variables which
the third one uses.


So without being enclosed in a 'parallel', the compiler complains that 
va is private in outer context. Why is the outer region an implicit 
parallel? I tried looking for it in the spec, but failed to locate much 
about implicit parallel enclosures.


Sorry, yes I misread the OMP spec where it says there's an implicit 
barrier at the end of sections construct as section directive block! 
Thanks for the correction.





+  int a[N], b[N], c[N];
+  svint32_t va, vb, vc;
+  int i;
+
+#pragma omp parallel for
+  for (i = 0; i < N; i++)
+{
+  b[i] = i;
+  c[i] = i + 1;
+}
+
+#pragma omp for lastprivate (va) /* { dg-error {lastprivate variable 'va' is 
private in outer context} } */
+  for (i = 0; i < 1; i++)
+{
+  vb = svld1_s32 (svptrue_b32 (), b);
+  vc = svld1_s32 (svptrue_b32 (), c);
+  va = svadd_s32_z (svptrue_b32 (), vb, vc);
+}


vb and vc are shared, so if this was inside of a parallel, it wouldn't be
valid again, there would be a data race (assuming more than one iteration,
a single iteration is kind of weird).

+
+  return va;
+}
+
+svint32_t __attribute__ ((noinline))
+omp_lastprivate_simd ()
+{
+
+  int a[N], b[N], c[N];
+  svint32_t va, vb, vc;
+  int i;
+
+#pragma omp parallel for
+  for (i = 0; i < N; i++)
+{
+  b[i] = i;
+  c[i] = i + 1;
+}
+
+#pragma omp simd lastprivate (va)
+  for (i = 0; i < 1; i++)
+{
+  vb = svld1_s32 (svptrue_b32 (), b);
+  vc = svld1_s32 (svptrue_b32 (), c);
+  va = svadd_s32_z (svptrue_b32 (), vb, vc);
+}


Similarly, these really aren't good examples IMHO on what user should
actually write.



I'm rewriting lastprivate tests to be more realistic - its better to 
make it an execution test.


Thanks,
Tejas.


Jakub





[patch, teststuite, Fortran, committed] Fix endianness issue on test case

2024-09-12 Thread Thomas Koenig

I just committed the fix for PR 116653 as obvious.

Unfortunately, I left out the description in the ChangeLog, I hope it
is clear enough.

Best regards

Thomas

https://gcc.gnu.org/g:5d9486c29938d79beb798dce1a5509da54fe8c9f

commit r15-3619-g5d9486c29938d79beb798dce1a5509da54fe8c9f
Author: Thomas Koenig 
Date:   Fri Sep 13 07:47:24 2024 +0200

Fix endianness issue on unsigned_21.f90.

gcc/testsuite/ChangeLog:

PR fortran/116653
* gfortran.dg/unsigned_21.f90:
* gfortran.dg/unsigned_21_be.f90: New test.

diff --git a/gcc/testsuite/gfortran.dg/unsigned_21.f90 
b/gcc/testsuite/gfortran.dg/unsigned_21.f90

index 23302c7eabe..c3f65a469dc 100644
--- a/gcc/testsuite/gfortran.dg/unsigned_21.f90
+++ b/gcc/testsuite/gfortran.dg/unsigned_21.f90
@@ -1,5 +1,6 @@
 ! { dg-do run }
 ! { dg-options "-funsigned" }
+! { dg-require-effective-target le }
 program main
   integer :: i
   integer(2) :: j
diff --git a/gcc/testsuite/gfortran.dg/unsigned_21_be.f90 
b/gcc/testsuite/gfortran.dg/unsigned_21_be.f90

new file mode 100644
index 000..64fecd9cd4a
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/unsigned_21_be.f90
@@ -0,0 +1,14 @@
+! { dg-do run }
+! { dg-options "-funsigned" }
+! { dg-require-effective-target be }
+program main
+  integer :: i
+  integer(2) :: j
+  unsigned :: u
+  i = -1
+  u = transfer(i,u)
+  if (u /= huge(u)) error stop 1
+  u = 4278058235u
+  j = transfer(u,j)
+  if (j /= -259) error stop 2
+end program main


[PATCH v1] RISC-V: Fix signed SAT_ADD test case for int64_t

2024-09-12 Thread pan2 . li
From: Pan Li 

The int8_t test for signed SAT_ADD is sat_s_add-1.c, the sat_s_add-4.c
should be for int64_t.  Thus, update sat_s_add-4.c for int64_t type.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/sat_s_add-4.c: Update test for int64_t
instead of int8_t.

Signed-off-by: Pan Li 
---
 gcc/testsuite/gcc.target/riscv/sat_s_add-4.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/gcc/testsuite/gcc.target/riscv/sat_s_add-4.c 
b/gcc/testsuite/gcc.target/riscv/sat_s_add-4.c
index f85675c1a05..12c9540eaec 100644
--- a/gcc/testsuite/gcc.target/riscv/sat_s_add-4.c
+++ b/gcc/testsuite/gcc.target/riscv/sat_s_add-4.c
@@ -5,26 +5,25 @@
 #include "sat_arith.h"
 
 /*
-** sat_s_add_int8_t_fmt_1:
+** sat_s_add_int64_t_fmt_1:
 ** add\s+[atx][0-9]+,\s*a0,\s*a1
 ** xor\s+[atx][0-9]+,\s*a0,\s*a1
 ** xor\s+[atx][0-9]+,\s*a0,\s*[atx][0-9]+
-** srli\s+[atx][0-9]+,\s*[atx][0-9]+,\s*7
-** srli\s+[atx][0-9]+,\s*[atx][0-9]+,\s*7
+** srli\s+[atx][0-9]+,\s*[atx][0-9]+,\s*63
+** srli\s+[atx][0-9]+,\s*[atx][0-9]+,\s*63
 ** xori\s+[atx][0-9]+,\s*[atx][0-9]+,\s*1
 ** and\s+[atx][0-9]+,\s*[atx][0-9]+,\s*[atx][0-9]+
-** andi\s+[atx][0-9]+,\s*[atx][0-9]+,\s*1
 ** srai\s+[atx][0-9]+,\s*[atx][0-9]+,\s*63
-** xori\s+[atx][0-9]+,\s*[atx][0-9]+,\s*127
+** li\s+[atx][0-9]+,\s*-1
+** srli\s+[atx][0-9]+,\s*[atx][0-9]+,\s*1
+** xor\s+[atx][0-9]+,\s*[atx][0-9]+,\s*[atx][0-9]+
 ** neg\s+[atx][0-9]+,\s*[atx][0-9]+
 ** and\s+[atx][0-9]+,\s*[atx][0-9]+,\s*[atx][0-9]+
 ** addi\s+[atx][0-9]+,\s*[atx][0-9]+,\s*-1
 ** and\s+[atx][0-9]+,\s*[atx][0-9]+,\s*[atx][0-9]+
 ** or\s+a0,\s*[atx][0-9]+,\s*[atx][0-9]+
-** slliw\s+a0,\s*a0,\s*24
-** sraiw\s+a0,\s*a0,\s*24
 ** ret
 */
-DEF_SAT_S_ADD_FMT_1(int8_t, uint8_t, INT8_MIN, INT8_MAX)
+DEF_SAT_S_ADD_FMT_1(int64_t, uint64_t, INT64_MIN, INT64_MAX)
 
 /* { dg-final { scan-rtl-dump-times ".SAT_ADD " 2 "expand" } } */
-- 
2.43.0



Re: [PATCH] testsuite: Sanitize pacbti test cases for Cortex-M

2024-09-12 Thread Richard Earnshaw (lists)
On 03/09/2024 13:57, Christophe Lyon wrote:
> Hi Torbjörn,
> 
> 
> On 9/3/24 11:30, Torbjörn SVENSSON wrote:
>>
>> Ok for trunk and releases/gcc-14?
>>
>> -- 
>>
>> Some of the test cases were scanning for "bti", but it would,
>> incorrectly, match the ".arch_extenssion pacbti".
>> Also, keep test cases active if a supported Cortex-M core is supplied.
>>
>> gcc/testsuite/ChangeLog:
>>
>> * gcc.target/arm/bti-1.c: Enable for Cortex-M(52|55|85) and
>> check for \tbti.
>> * gcc.target/arm/bti-2.c: Likewise.
>> * gcc.target/arm/pac-15.c: Likewise.
> For pac-15.c, your patch only enables the test for cortex-m{52|55|85}, 
> there's not scan-assembler for bti :-)
> 
>> * gcc.target/arm/pac-4.c: Check for \tbti.
>> * gcc.target/arm/pac-6.c: Likewise.
>>
>> Signed-off-by: Torbjörn SVENSSON 
>> Co-authored-by: Yvan ROUX 
>> ---
>>   gcc/testsuite/gcc.target/arm/bti-1.c  | 4 ++--
>>   gcc/testsuite/gcc.target/arm/bti-2.c  | 4 ++--
>>   gcc/testsuite/gcc.target/arm/pac-15.c | 2 +-
>>   gcc/testsuite/gcc.target/arm/pac-4.c  | 2 +-
>>   gcc/testsuite/gcc.target/arm/pac-6.c  | 2 +-
>>   5 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/gcc/testsuite/gcc.target/arm/bti-1.c 
>> b/gcc/testsuite/gcc.target/arm/bti-1.c
>> index 79dd8010d2d..70a62b5a70c 100644
>> --- a/gcc/testsuite/gcc.target/arm/bti-1.c
>> +++ b/gcc/testsuite/gcc.target/arm/bti-1.c
>> @@ -1,6 +1,6 @@
>>   /* Check that GCC does bti instruction.  */
>>   /* { dg-do compile } */
>> -/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
>> "-mcpu=*" } } */
>> +/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
>> "-mcpu=*" } { "-mcpu=cortex-m52*" "-mcpu=cortex-m55*" "-mcpu=cortex-m85*" } 
>> } */
> I'm not sure this is the way forward, but I'll let Richard comment.

We shouldn't need to do this now, but this test will need some reworking to use 
the new feature that I've added today.

> 
>>   /* { dg-options "-march=armv8.1-m.main -mthumb -mfloat-abi=softfp 
>> -mbranch-protection=bti --save-temps" } 

I think we can replace the dg-skip-if and dg-options with
/* { dg-require-effective-target arm_arch_v8_1m_main_ok } */
/* { dg-options "-mfloat-abi=softfp -mbranch-protection=bti --save-temps" } */
/* { dg-add-options arm_arch_v8_1m_main } */

And now the framework knows how to correctly override any -mcpu= option passed 
from the test run configuration.

*/
>>     int
>> @@ -9,4 +9,4 @@ main (void)
>>     return 0;
>>   }
>>   -/* { dg-final { scan-assembler "bti" } } */
>> +/* { dg-final { scan-assembler "\tbti" } } */
>> diff --git a/gcc/testsuite/gcc.target/arm/bti-2.c 
>> b/gcc/testsuite/gcc.target/arm/bti-2.c
>> index 33910563849..44c04d3df68 100644
>> --- a/gcc/testsuite/gcc.target/arm/bti-2.c
>> +++ b/gcc/testsuite/gcc.target/arm/bti-2.c
>> @@ -1,7 +1,7 @@
>>   /* { dg-do compile } */
>>   /* -Os to create jump table.  */
>>   /* { dg-options "-Os" } */
>> -/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
>> "-mcpu=*" } } */
>> +/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
>> "-mcpu=*" } { "-mcpu=cortex-m52*" "-mcpu=cortex-m55*" "-mcpu=cortex-m85*" } 
>> } */
>>   /* { dg-options "-march=armv8.1-m.main -mthumb -mfloat-abi=softfp 
>> -mbranch-protection=bti --save-temps" } */
>>     extern int f1 (void);
>> @@ -55,4 +55,4 @@ lab2:
>>     return 2;
>>   }
>>   -/* { dg-final { scan-assembler-times "bti" 15 } } */
>> +/* { dg-final { scan-assembler-times "\tbti" 15 } } */
>> diff --git a/gcc/testsuite/gcc.target/arm/pac-15.c 
>> b/gcc/testsuite/gcc.target/arm/pac-15.c
>> index e1054902955..a2582e64d0a 100644
>> --- a/gcc/testsuite/gcc.target/arm/pac-15.c
>> +++ b/gcc/testsuite/gcc.target/arm/pac-15.c
>> @@ -1,7 +1,7 @@
>>   /* Check that GCC does .save and .cfi_offset directives with RA_AUTH_CODE 
>> pseudo hard-register.  */
>>   /* { dg-do compile } */
>>   /* { dg-require-effective-target mbranch_protection_ok } */
>> -/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
>> "-mcpu=*" } } */
>> +/* { dg-skip-if "avoid conflicting mul

[r15-3596 Regression] FAIL: gcc.target/i386/part-vect-vec_cmpbf.c (test for excess errors) on Linux/x86_64

2024-09-12 Thread haochen.jiang
On Linux/x86_64,

89d50c45048e5d7230ddde9afc8fbc83143e34cb is the first bad commit
commit 89d50c45048e5d7230ddde9afc8fbc83143e34cb
Author: Levy Hsu 
Date:   Wed Sep 4 16:34:04 2024 +0930

i386: Enable V2BF/V4BF vec_cmp with AVX10.2 vcmppbf16

caused

FAIL: gcc.target/i386/part-vect-vec_cmpbf.c (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-3596/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/part-vect-vec_cmpbf.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.)


[r15-3581 Regression] FAIL: gfortran.dg/gomp/interop-1.f90 -O (test for excess errors) on Linux/x86_64

2024-09-11 Thread haochen.jiang
On Linux/x86_64,

4e9265a474def98cb6cdb59c15fbcb7630ba330e is the first bad commit
commit 4e9265a474def98cb6cdb59c15fbcb7630ba330e
Author: Tobias Burnus 
Date:   Wed Sep 11 09:25:47 2024 +0200

fortran/openmp.cc: Fix var init and locus use to avoid uninit values [PR 
fortran/116661]

caused

FAIL: gfortran.dg/gomp/interop-1.f90   -O  (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-3581/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="gomp.exp=gfortran.dg/gomp/interop-1.f90 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="gomp.exp=gfortran.dg/gomp/interop-1.f90 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="gomp.exp=gfortran.dg/gomp/interop-1.f90 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="gomp.exp=gfortran.dg/gomp/interop-1.f90 
--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.)


[committed] testsuite: Fix up pr116588.c test [PR116588]

2024-09-09 Thread Jakub Jelinek
On Sat, Sep 07, 2024 at 01:58:46PM -0400, Andrew MacLeod wrote:
The test as committed without the tree-vrp.cc change only FAILs with
FAIL: gcc.dg/pr116588.c scan-tree-dump-not vrp2 "0 != 0"
The DEBUG code in there was just to make it easier to debug, but doesn't
actually fail when the test is miscompiled.
We don't need such debugging code in simple tests like that, but it is
useful if they abort when miscompiled.

With this patch without the tree-vrp.cc change I see
FAIL: gcc.dg/pr116588.c execution test
FAIL: gcc.dg/pr116588.c scan-tree-dump-not vrp2 "0 != 0"
and with it it passes.

Tested on x86_64-linux with
make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} dg.exp=pr116588.c'
and committed to trunk as obvious.

2024-09-09  Jakub Jelinek  

PR tree-optimization/116588
* gcc.dg/pr116588.c: Remove -DDEBUG from dg-options.
(main): Remove debugging code and simplify.

--- gcc/testsuite/gcc.dg/pr116588.c.jj  2024-09-09 09:27:39.155082488 +0200
+++ gcc/testsuite/gcc.dg/pr116588.c 2024-09-09 09:31:37.951970837 +0200
@@ -1,7 +1,7 @@
 /* PR tree-optimization/116588 */
 /* { dg-do run { target bitint575 } } */
 /* { dg-require-effective-target int128 } */
-/* { dg-options "-O2 -fno-vect-cost-model -fno-tree-dominator-opts 
-fno-tree-fre --param=vrp-block-limit=0  -DDEBUG -fdump-tree-vrp2-details" } */
+/* { dg-options "-O2 -fno-vect-cost-model -fno-tree-dominator-opts 
-fno-tree-fre --param=vrp-block-limit=0 -fdump-tree-vrp2-details" } */
 
 int a;
 __int128 b, c;
@@ -18,15 +18,8 @@ foo (_BitInt (129) e)
 int
 main ()
 {
-  __int128 x = foo (0);
-#ifdef DEBUG
-  for (unsigned i = 0; i < sizeof (x); i++)
-__builtin_printf ("%02x", i[(volatile unsigned char *) &x]);
-  __builtin_printf("\n");
-#else
-  if (x)
-__builtin_abort();
-#endif
+  if (foo (0))
+__builtin_abort ();
 }
 
 /* { dg-final { scan-tree-dump-not "0 != 0" "vrp2" } } */


Jakub



Re: [r15-3529 Regression] FAIL: gcc.dg/pr116588.c (test for excess errors) on Linux/x86_64

2024-09-07 Thread Andrew Pinski
On Sat, Sep 7, 2024 at 4:11 PM haochen.jiang  wrote:
>
> On Linux/x86_64,
>
> 506417dbc8b1cbc1133a5322572cf94b671aadf6 is the first bad commit
> commit 506417dbc8b1cbc1133a5322572cf94b671aadf6
> Author: Andrew MacLeod 
> Date:   Fri Sep 6 11:42:14 2024 -0400
>
> Before running fast VRP, make sure all edges have EXECUTABLE set.
>
> caused
>
> FAIL: gcc.dg/pr116588.c (test for excess errors)

Fixed with r15-3533-g35c2bcb2389d34 .

Thanks,
Andrew Pinski

>
> with GCC configured with
>
> ../../gcc/configure 
> --prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-3529/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/pr116588.c 
> --target_board='unix{-m32}'"
> $ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/pr116588.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.)


[r15-3529 Regression] FAIL: gcc.dg/pr116588.c (test for excess errors) on Linux/x86_64

2024-09-07 Thread haochen.jiang
On Linux/x86_64,

506417dbc8b1cbc1133a5322572cf94b671aadf6 is the first bad commit
commit 506417dbc8b1cbc1133a5322572cf94b671aadf6
Author: Andrew MacLeod 
Date:   Fri Sep 6 11:42:14 2024 -0400

Before running fast VRP, make sure all edges have EXECUTABLE set.

caused

FAIL: gcc.dg/pr116588.c (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-3529/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/pr116588.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/pr116588.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 v2] testsuite: Sanitize pacbti test cases for Cortex-M

2024-09-06 Thread Christophe Lyon




On 9/6/24 11:17, Torbjörn SVENSSON wrote:

Ok for trunk and releases/gcc-14?

Changes since v1:

- Corrected changelog entry for pac-15.c
- Added a tab before all the asm instructions in the pac-*.c and bti-*.c tests
- Corrected the expected number of bti instructions for bti-2.c as it 
previously counted the .file directive


Thanks, this LGTM, but you'll have to wait for approval from a maintainer.

Christophe



--

Some of the test cases were scanning for "bti", but it would,
incorrectly, match the ".arch_extenssion pacbti".
Also, keep test cases active if a supported Cortex-M core is supplied.

gcc/testsuite/ChangeLog:

* gcc.target/arm/bti-1.c: Enable for Cortex-M(52|55|85) and
check for asm instructions starting with a tab.
* gcc.target/arm/bti-2.c: Likewise.
* gcc.target/arm/pac-1.c: Check for asm instructions starting
with a tab.
* gcc.target/arm/pac-2.c: Likewise.
* gcc.target/arm/pac-3.c: Likewise.
* gcc.target/arm/pac-6.c: Likewise.
* gcc.target/arm/pac-7.c: Likewise.
* gcc.target/arm/pac-8.c: Likewise.
* gcc.target/arm/pac-9.c: Likewise.
* gcc.target/arm/pac-10.c: Likewise.
* gcc.target/arm/pac-11.c: Likewise.
* gcc.target/arm/pac-sibcall.c: Likewise.
* gcc.target/arm/pac-15.c: Enable for Cortex-M(52|55|85).

Signed-off-by: Torbjörn SVENSSON 
Co-authored-by: Yvan ROUX 
---
  gcc/testsuite/gcc.target/arm/bti-1.c   | 4 ++--
  gcc/testsuite/gcc.target/arm/bti-2.c   | 4 ++--
  gcc/testsuite/gcc.target/arm/pac-1.c   | 4 ++--
  gcc/testsuite/gcc.target/arm/pac-10.c  | 4 ++--
  gcc/testsuite/gcc.target/arm/pac-11.c  | 4 ++--
  gcc/testsuite/gcc.target/arm/pac-15.c  | 4 ++--
  gcc/testsuite/gcc.target/arm/pac-2.c   | 4 ++--
  gcc/testsuite/gcc.target/arm/pac-3.c   | 4 ++--
  gcc/testsuite/gcc.target/arm/pac-4.c   | 2 +-
  gcc/testsuite/gcc.target/arm/pac-6.c   | 6 +++---
  gcc/testsuite/gcc.target/arm/pac-7.c   | 4 ++--
  gcc/testsuite/gcc.target/arm/pac-8.c   | 4 ++--
  gcc/testsuite/gcc.target/arm/pac-9.c   | 4 ++--
  gcc/testsuite/gcc.target/arm/pac-sibcall.c | 2 +-
  14 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/bti-1.c 
b/gcc/testsuite/gcc.target/arm/bti-1.c
index 79dd8010d2d..70a62b5a70c 100644
--- a/gcc/testsuite/gcc.target/arm/bti-1.c
+++ b/gcc/testsuite/gcc.target/arm/bti-1.c
@@ -1,6 +1,6 @@
  /* Check that GCC does bti instruction.  */
  /* { dg-do compile } */
-/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } } */
+/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" "-mcpu=*" } { 
"-mcpu=cortex-m52*" "-mcpu=cortex-m55*" "-mcpu=cortex-m85*" } } */
  /* { dg-options "-march=armv8.1-m.main -mthumb -mfloat-abi=softfp 
-mbranch-protection=bti --save-temps" } */
  
  int

@@ -9,4 +9,4 @@ main (void)
return 0;
  }
  
-/* { dg-final { scan-assembler "bti" } } */

+/* { dg-final { scan-assembler "\tbti" } } */
diff --git a/gcc/testsuite/gcc.target/arm/bti-2.c 
b/gcc/testsuite/gcc.target/arm/bti-2.c
index 33910563849..7c901d06967 100644
--- a/gcc/testsuite/gcc.target/arm/bti-2.c
+++ b/gcc/testsuite/gcc.target/arm/bti-2.c
@@ -1,7 +1,7 @@
  /* { dg-do compile } */
  /* -Os to create jump table.  */
  /* { dg-options "-Os" } */
-/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } } */
+/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" "-mcpu=*" } { 
"-mcpu=cortex-m52*" "-mcpu=cortex-m55*" "-mcpu=cortex-m85*" } } */
  /* { dg-options "-march=armv8.1-m.main -mthumb -mfloat-abi=softfp 
-mbranch-protection=bti --save-temps" } */
  
  extern int f1 (void);

@@ -55,4 +55,4 @@ lab2:
return 2;
  }
  
-/* { dg-final { scan-assembler-times "bti" 15 } } */

+/* { dg-final { scan-assembler-times "\tbti" 14 } } */
diff --git a/gcc/testsuite/gcc.target/arm/pac-1.c 
b/gcc/testsuite/gcc.target/arm/pac-1.c
index 9b26f62b65f..e0eea0858e0 100644
--- a/gcc/testsuite/gcc.target/arm/pac-1.c
+++ b/gcc/testsuite/gcc.target/arm/pac-1.c
@@ -6,6 +6,6 @@
  
  #include "pac.h"
  
-/* { dg-final { scan-assembler-times "pac\tip, lr, sp" 2 } } */

-/* { dg-final { scan-assembler-times "aut\tip, lr, sp" 2 } } */
+/* { dg-final { scan-assembler-times "\tpac\tip, lr, sp" 2 } } */
+/* { dg-final { scan-assembler-times "\taut\tip, lr, sp" 2 } } */
  /* { dg-final { scan-assembler-not "\tbti" } } */
diff --git a/gcc/testsuite/gcc.target/arm/pac-10.c 
b/gcc/testsuite/gcc.target/arm/pac-10.c
index a794195e8f6..6da8434aeaf 100644
--- a/gcc/testsuite/gcc.target/arm/pac-10.

[PATCH v2] testsuite: Sanitize pacbti test cases for Cortex-M

2024-09-06 Thread Torbjörn SVENSSON
Ok for trunk and releases/gcc-14?

Changes since v1:

- Corrected changelog entry for pac-15.c
- Added a tab before all the asm instructions in the pac-*.c and bti-*.c tests
- Corrected the expected number of bti instructions for bti-2.c as it 
previously counted the .file directive

--

Some of the test cases were scanning for "bti", but it would,
incorrectly, match the ".arch_extenssion pacbti".
Also, keep test cases active if a supported Cortex-M core is supplied.

gcc/testsuite/ChangeLog:

* gcc.target/arm/bti-1.c: Enable for Cortex-M(52|55|85) and
check for asm instructions starting with a tab.
* gcc.target/arm/bti-2.c: Likewise.
* gcc.target/arm/pac-1.c: Check for asm instructions starting
with a tab.
* gcc.target/arm/pac-2.c: Likewise.
* gcc.target/arm/pac-3.c: Likewise.
* gcc.target/arm/pac-6.c: Likewise.
* gcc.target/arm/pac-7.c: Likewise.
* gcc.target/arm/pac-8.c: Likewise.
* gcc.target/arm/pac-9.c: Likewise.
* gcc.target/arm/pac-10.c: Likewise.
* gcc.target/arm/pac-11.c: Likewise.
* gcc.target/arm/pac-sibcall.c: Likewise.
* gcc.target/arm/pac-15.c: Enable for Cortex-M(52|55|85).

Signed-off-by: Torbjörn SVENSSON 
Co-authored-by: Yvan ROUX 
---
 gcc/testsuite/gcc.target/arm/bti-1.c   | 4 ++--
 gcc/testsuite/gcc.target/arm/bti-2.c   | 4 ++--
 gcc/testsuite/gcc.target/arm/pac-1.c   | 4 ++--
 gcc/testsuite/gcc.target/arm/pac-10.c  | 4 ++--
 gcc/testsuite/gcc.target/arm/pac-11.c  | 4 ++--
 gcc/testsuite/gcc.target/arm/pac-15.c  | 4 ++--
 gcc/testsuite/gcc.target/arm/pac-2.c   | 4 ++--
 gcc/testsuite/gcc.target/arm/pac-3.c   | 4 ++--
 gcc/testsuite/gcc.target/arm/pac-4.c   | 2 +-
 gcc/testsuite/gcc.target/arm/pac-6.c   | 6 +++---
 gcc/testsuite/gcc.target/arm/pac-7.c   | 4 ++--
 gcc/testsuite/gcc.target/arm/pac-8.c   | 4 ++--
 gcc/testsuite/gcc.target/arm/pac-9.c   | 4 ++--
 gcc/testsuite/gcc.target/arm/pac-sibcall.c | 2 +-
 14 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/bti-1.c 
b/gcc/testsuite/gcc.target/arm/bti-1.c
index 79dd8010d2d..70a62b5a70c 100644
--- a/gcc/testsuite/gcc.target/arm/bti-1.c
+++ b/gcc/testsuite/gcc.target/arm/bti-1.c
@@ -1,6 +1,6 @@
 /* Check that GCC does bti instruction.  */
 /* { dg-do compile } */
-/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } } */
+/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } { "-mcpu=cortex-m52*" "-mcpu=cortex-m55*" "-mcpu=cortex-m85*" } } */
 /* { dg-options "-march=armv8.1-m.main -mthumb -mfloat-abi=softfp 
-mbranch-protection=bti --save-temps" } */
 
 int
@@ -9,4 +9,4 @@ main (void)
   return 0;
 }
 
-/* { dg-final { scan-assembler "bti" } } */
+/* { dg-final { scan-assembler "\tbti" } } */
diff --git a/gcc/testsuite/gcc.target/arm/bti-2.c 
b/gcc/testsuite/gcc.target/arm/bti-2.c
index 33910563849..7c901d06967 100644
--- a/gcc/testsuite/gcc.target/arm/bti-2.c
+++ b/gcc/testsuite/gcc.target/arm/bti-2.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* -Os to create jump table.  */
 /* { dg-options "-Os" } */
-/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } } */
+/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } { "-mcpu=cortex-m52*" "-mcpu=cortex-m55*" "-mcpu=cortex-m85*" } } */
 /* { dg-options "-march=armv8.1-m.main -mthumb -mfloat-abi=softfp 
-mbranch-protection=bti --save-temps" } */
 
 extern int f1 (void);
@@ -55,4 +55,4 @@ lab2:
   return 2;
 }
 
-/* { dg-final { scan-assembler-times "bti" 15 } } */
+/* { dg-final { scan-assembler-times "\tbti" 14 } } */
diff --git a/gcc/testsuite/gcc.target/arm/pac-1.c 
b/gcc/testsuite/gcc.target/arm/pac-1.c
index 9b26f62b65f..e0eea0858e0 100644
--- a/gcc/testsuite/gcc.target/arm/pac-1.c
+++ b/gcc/testsuite/gcc.target/arm/pac-1.c
@@ -6,6 +6,6 @@
 
 #include "pac.h"
 
-/* { dg-final { scan-assembler-times "pac\tip, lr, sp" 2 } } */
-/* { dg-final { scan-assembler-times "aut\tip, lr, sp" 2 } } */
+/* { dg-final { scan-assembler-times "\tpac\tip, lr, sp" 2 } } */
+/* { dg-final { scan-assembler-times "\taut\tip, lr, sp" 2 } } */
 /* { dg-final { scan-assembler-not "\tbti" } } */
diff --git a/gcc/testsuite/gcc.target/arm/pac-10.c 
b/gcc/testsuite/gcc.target/arm/pac-10.c
index a794195e8f6..6da8434aeaf 100644
--- a/gcc/testsuite/gcc.target/arm/pac-10.c
+++ b/gcc/testsuite/gcc.target/arm/pac-10.c
@@ -5,6 +5,6 @@
 
 #include "pac.h"
 
-/* { dg-final { scan-assembler "pac\tip, lr, sp" } } */
-/* { dg-final 

Re: [RFC PATCH] c++: Add alignas further test coverage [PR110345]

2024-09-05 Thread Jason Merrill

On 9/5/24 9:03 AM, Jakub Jelinek wrote:

Hi!

I've tried to do the same thing I did for normal standard attributes
also for alignas, but there are way too many cases which are silently
accepted although my reading of:

"An alignment-specifier may be applied to a variable or to a class data member,
but it shall not be applied to a bit-field, a function parameter, or an
exception-declaration ([except.handle]).
An alignment-specifier may also be applied to the declaration of a class (in
an elaborated-type-specifier ([dcl.type.elab]) or class-head ([class]),
respectively)."

I've marked the spots where I'd expect some pedwarn with // FIXME.
Clearly we accept it e.g. on bit-fields, exception-declarations, enum
declarations, functions, to e.g. array/reference etc. types, ...

Is some of this intentional?


Allowing it for functions and enums seems consistent with the GNU 
aligned attribute, I'd complain only when -pedantic.


I think we might want to pedwarn about standard attribute syntax 
appertaining to a type (other than between the class/enum key and name) 
when !affects_type_identity.  But that seems like a separate issue.


Does GNU aligned on a bit-field do anything useful?

Allowing it on an exception-declaration is a bug, those should be 
treated the same as parameters.



Though, trying clang trunk, it diagnoses all the // FIXME lines.

2024-09-05  Jakub Jelinek  

PR c++/110345
* g++.dg/cpp0x/alignas21.C: New test.

--- gcc/testsuite/g++.dg/cpp0x/alignas21.C.jj   2024-09-05 14:16:44.366395041 
+0200
+++ gcc/testsuite/g++.dg/cpp0x/alignas21.C  2024-09-05 14:42:42.690465771 
+0200
@@ -0,0 +1,156 @@
+// C++ 26 P2552R3 - On the ignorability of standard attributes
+// { dg-do compile { target c++11 } }
+
+int arr[2];
+struct S { int a, b; };
+S arr2[2];
+
+void
+foo (int n)
+{
+  alignas (int) int x1;
+  alignas ("foobar") int x2; // { dg-error "'alignas' argument has 
non-integral type 'const char \\\[7\\\]'" }
+  alignas (0) int x3;  // { dg-warning "requested alignment 
'0' is not a positive power of 2" }
+  alignas ("foo", "bar", "baz") int x4;  // { dg-error "'alignas' argument 
has non-integral type 'const char \\\[4\\\]'" }
+   // { dg-error "expected '\\\)' before ',' 
token" "" { target *-*-* } .-1 }
+   // { dg-error "expected declaration before ',' 
token" "" { target *-*-* } .-2 }
+   // { dg-error "expected primary-expression 
before ',' token" "" { target *-*-* } .-3 }
+  alignas (0, 1, 2) int x5;// { dg-error "expected '\\\)' 
before ',' token" }
+   // { dg-error "expected declaration before ',' 
token" "" { target *-*-* } .-1 }
+   // { dg-error "expected primary-expression 
before ',' token" "" { target *-*-* } .-2 }
+
+  auto a = [] alignas (int) () {}; // FIXME
+  auto b = [] constexpr alignas (int) {};  // FIXME
+   // { dg-error "parameter declaration before 
lambda declaration specifiers only optional with" "" { target c++20_down } .-1 }
+   // { dg-error "'constexpr' lambda only 
available with" "" { target c++14_down } .-2 }
+  auto c = [] noexcept alignas (int) {};   // FIXME
+   // { dg-error "parameter declaration before 
lambda exception specification only optional with" "" { target c++20_down } .-1 }
+  auto d = [] () alignas (int) {}; // FIXME
+  auto e = new int [n] alignas (int);  // { dg-warning "attributes ignored 
on outermost array type in new expression" }
+  auto e2 = new int [n] alignas (int) [42];// { dg-warning "attributes ignored 
on outermost array type in new expression" }
+  auto f = new int [n][42] alignas (int);  // FIXME
+  alignas (int);   // { dg-warning "attributes at the 
beginning of statement are ignored" }
+  alignas (int) {} // { dg-warning "attributes at the 
beginning of statement are ignored" }
+  alignas (int) if (true) {}   // { dg-warning "attributes at the 
beginning of statement are ignored" }
+  alignas (int) while (false) {}   // { dg-warning "attributes at the 
beginning of statement are ignored" }
+  alignas (in

[RFC PATCH] c++: Add alignas further test coverage [PR110345]

2024-09-05 Thread Jakub Jelinek
Hi!

I've tried to do the same thing I did for normal standard attributes
also for alignas, but there are way too many cases which are silently
accepted although my reading of:

"An alignment-specifier may be applied to a variable or to a class data member,
but it shall not be applied to a bit-field, a function parameter, or an
exception-declaration ([except.handle]).
An alignment-specifier may also be applied to the declaration of a class (in
an elaborated-type-specifier ([dcl.type.elab]) or class-head ([class]),
respectively)."

I've marked the spots where I'd expect some pedwarn with // FIXME.
Clearly we accept it e.g. on bit-fields, exception-declarations, enum
declarations, functions, to e.g. array/reference etc. types, ...

Is some of this intentional?

Though, trying clang trunk, it diagnoses all the // FIXME lines.

2024-09-05  Jakub Jelinek  

PR c++/110345
* g++.dg/cpp0x/alignas21.C: New test.

--- gcc/testsuite/g++.dg/cpp0x/alignas21.C.jj   2024-09-05 14:16:44.366395041 
+0200
+++ gcc/testsuite/g++.dg/cpp0x/alignas21.C  2024-09-05 14:42:42.690465771 
+0200
@@ -0,0 +1,156 @@
+// C++ 26 P2552R3 - On the ignorability of standard attributes
+// { dg-do compile { target c++11 } }
+
+int arr[2];
+struct S { int a, b; };
+S arr2[2];
+
+void
+foo (int n)
+{
+  alignas (int) int x1;
+  alignas ("foobar") int x2;   // { dg-error "'alignas' 
argument has non-integral type 'const char \\\[7\\\]'" }
+  alignas (0) int x3;  // { dg-warning "requested 
alignment '0' is not a positive power of 2" }
+  alignas ("foo", "bar", "baz") int x4;// { dg-error 
"'alignas' argument has non-integral type 'const char \\\[4\\\]'" }
+   // { dg-error "expected '\\\)' 
before ',' token" "" { target *-*-* } .-1 }
+   // { dg-error "expected 
declaration before ',' token" "" { target *-*-* } .-2 }
+   // { dg-error "expected 
primary-expression before ',' token" "" { target *-*-* } .-3 }
+  alignas (0, 1, 2) int x5;// { dg-error "expected '\\\)' 
before ',' token" }
+   // { dg-error "expected 
declaration before ',' token" "" { target *-*-* } .-1 }
+   // { dg-error "expected 
primary-expression before ',' token" "" { target *-*-* } .-2 }
+
+  auto a = [] alignas (int) () {}; // FIXME
+  auto b = [] constexpr alignas (int) {};  // FIXME
+   // { dg-error "parameter 
declaration before lambda declaration specifiers only optional with" "" { 
target c++20_down } .-1 }
+   // { dg-error "'constexpr' 
lambda only available with" "" { target c++14_down } .-2 }
+  auto c = [] noexcept alignas (int) {};   // FIXME
+   // { dg-error "parameter 
declaration before lambda exception specification only optional with" "" { 
target c++20_down } .-1 }
+  auto d = [] () alignas (int) {}; // FIXME
+  auto e = new int [n] alignas (int);  // { dg-warning "attributes 
ignored on outermost array type in new expression" }
+  auto e2 = new int [n] alignas (int) [42];// { dg-warning "attributes 
ignored on outermost array type in new expression" }
+  auto f = new int [n][42] alignas (int);  // FIXME
+  alignas (int);   // { dg-warning "attributes at 
the beginning of statement are ignored" }
+  alignas (int) {} // { dg-warning "attributes at 
the beginning of statement are ignored" }
+  alignas (int) if (true) {}   // { dg-warning "attributes at 
the beginning of statement are ignored" }
+  alignas (int) while (false) {}   // { dg-warning "attributes at 
the beginning of statement are ignored" }
+  alignas (int) goto lab;  // { dg-warning "attributes at 
the beginning of statement are ignored" }
+  alignas (int) lab:;  // { dg-error "alignment may 
not be specified for 'lab'" }
+  alignas (int) try {} catch (int) {}  // { dg-warning "attributes at 
the beginning of statement are ignored" }
+  if (alignas (int) int x = 0) {}
+  switch (n)
+{
+alignas (int) case 1:  // { dg-error "alignment may 
not be 

c++: Add no_unique_address attribute further test coverage [PR110345]

2024-09-05 Thread Jakub Jelinek
Hi!

Another non-problematic attribute.

Tested on x86_64-linux and i686-linux, ok for trunk?

2024-09-05  Jakub Jelinek  

PR c++/110345
* g++.dg/cpp0x/attr-no_unique_address1.C: New test.

--- gcc/testsuite/g++.dg/cpp0x/attr-no_unique_address1.C.jj 2024-09-05 
14:01:00.396886959 +0200
+++ gcc/testsuite/g++.dg/cpp0x/attr-no_unique_address1.C2024-09-05 
14:11:04.710883438 +0200
@@ -0,0 +1,151 @@
+// C++ 26 P2552R3 - On the ignorability of standard attributes
+// { dg-do compile { target c++11 } }
+
+int arr[2];
+struct S { int a, b; };
+S arr2[2];
+
+struct S2 {
+  [[no_unique_address]] struct {} a;
+  [[no_unique_address ("foobar")]] struct {} b;// { dg-error 
"'no_unique_address' attribute does not take any arguments" }
+  [[no_unique_address (0)]] struct {} c;   // { dg-error 
"'no_unique_address' attribute does not take any arguments" }
+  struct {} d [[no_unique_address]];
+};
+
+void
+foo (int n)
+{
+  auto a = [] [[no_unique_address]] () { };// { dg-warning 
"'no_unique_address' attribute can only be applied to non-static data members" }
+  auto b = [] constexpr [[no_unique_address]] {};  // { dg-warning 
"'no_unique_address' attribute does not apply to types" }
+   // { dg-error 
"parameter declaration before lambda declaration specifiers only optional with" 
"" { target c++20_down } .-1 }
+   // { dg-error 
"'constexpr' lambda only available with" "" { target c++14_down } .-2 }
+  auto c = [] noexcept [[no_unique_address]] {};   // { dg-warning 
"'no_unique_address' attribute does not apply to types" }
+   // { dg-error 
"parameter declaration before lambda exception specification only optional 
with" "" { target c++20_down } .-1 }
+  auto d = [] () [[no_unique_address]] {}; // { dg-warning 
"'no_unique_address' attribute does not apply to types" }
+  auto e = new int [n] [[no_unique_address]];  // { dg-warning 
"attributes ignored on outermost array type in new expression" }
+  auto e2 = new int [n] [[no_unique_address]] [42];// { dg-warning 
"attributes ignored on outermost array type in new expression" }
+  auto f = new int [n][42] [[no_unique_address]];  // { dg-warning 
"'no_unique_address' attribute does not apply to types" }
+  [[no_unique_address]];   // { dg-warning 
"attributes at the beginning of statement are ignored" }
+  [[no_unique_address]] {} // { dg-warning 
"attributes at the beginning of statement are ignored" }
+  [[no_unique_address]] if (true) {}   // { dg-warning 
"attributes at the beginning of statement are ignored" }
+  [[no_unique_address]] while (false) {}   // { dg-warning 
"attributes at the beginning of statement are ignored" }
+  [[no_unique_address]] goto lab;  // { dg-warning 
"attributes at the beginning of statement are ignored" }
+  [[no_unique_address]] lab:;  // { dg-warning 
"'no_unique_address' attribute can only be applied to non-static data members" }
+  [[no_unique_address]] try {} catch (int) {}  // { dg-warning 
"attributes at the beginning of statement are ignored" }
+  if ([[no_unique_address]] int x = 0) {}  // { dg-warning 
"'no_unique_address' attribute can only be applied to non-static data members" }
+  switch (n)
+{
+[[no_unique_address]] case 1:  // { dg-warning 
"'no_unique_address' attribute can only be applied to non-static data members" }
+[[no_unique_address]] break;   // { dg-warning 
"attributes at the beginning of statement are ignored" }
+[[no_unique_address]] default: // { dg-warning 
"'no_unique_address' attribute can only be applied to non-static data members" }
+break;
+}
+  for ([[no_unique_address]] auto a : arr) {}  // { dg-warning 
"'no_unique_address' attribute can only be applied to non-static data members" }
+  for ([[no_unique_address]] auto [a, b] : arr2) {}// { dg-warning 
"'no_unique_address' attribute can only be applied to non-static data members" }
+   // { dg-error 
"structured bindings only available with" "" { target c++14_down } .-1 }
+  [[no_unique_address]] asm ("");  // { dg-warning 

c++: Add noreturn attribute further test coverage [PR110345]

2024-09-05 Thread Jakub Jelinek
Hi!

Another non-problematic attribute.

Tested on x86_64-linux and i686-linux, ok for trunk?

2024-09-05  Jakub Jelinek  

PR c++/110345
* g++.dg/cpp0x/attr-noreturn1.C: New test.

--- gcc/testsuite/g++.dg/cpp0x/attr-noreturn1.C.jj  2024-09-05 
13:45:58.193567109 +0200
+++ gcc/testsuite/g++.dg/cpp0x/attr-noreturn1.C 2024-09-05 13:57:50.457348169 
+0200
@@ -0,0 +1,160 @@
+// C++ 26 P2552R3 - On the ignorability of standard attributes
+// { dg-do compile { target c++11 } }
+
+int arr[2];
+struct S { int a, b; };
+S arr2[2];
+
+[[noreturn]] void foo1 ();
+[[noreturn ("foobar")]] void foo2 ();  // { dg-error "'noreturn' 
attribute does not take any arguments" }
+[[noreturn (0)]] void foo3 (); // { dg-error "'noreturn' 
attribute does not take any arguments" }
+
+void
+foo (int n)
+{
+  auto a = [] [[noreturn]] () { do { } while (true); };
+  auto b = [] constexpr [[noreturn]] {};   // { dg-warning "'noreturn' 
attribute does not apply to types" }
+   // { dg-error "parameter 
declaration before lambda declaration specifiers only optional with" "" { 
target c++20_down } .-1 }
+   // { dg-error "'constexpr' 
lambda only available with" "" { target c++14_down } .-2 }
+  auto c = [] noexcept [[noreturn]] {};// { dg-warning 
"'noreturn' attribute does not apply to types" }
+   // { dg-error "parameter 
declaration before lambda exception specification only optional with" "" { 
target c++20_down } .-1 }
+  auto d = [] () [[noreturn]] {};  // { dg-warning "'noreturn' 
attribute does not apply to types" }
+  auto e = new int [n] [[noreturn]];   // { dg-warning "attributes 
ignored on outermost array type in new expression" }
+  auto e2 = new int [n] [[noreturn]] [42]; // { dg-warning "attributes 
ignored on outermost array type in new expression" }
+  auto f = new int [n][42] [[noreturn]];   // { dg-warning "'noreturn' 
attribute does not apply to types" }
+  [[noreturn]];// { dg-warning 
"attributes at the beginning of statement are ignored" }
+  [[noreturn]] {}  // { dg-warning "attributes at 
the beginning of statement are ignored" }
+  [[noreturn]] if (true) {}// { dg-warning "attributes at 
the beginning of statement are ignored" }
+  [[noreturn]] while (false) {}// { dg-warning 
"attributes at the beginning of statement are ignored" }
+  [[noreturn]] goto lab;   // { dg-warning "attributes at 
the beginning of statement are ignored" }
+  [[noreturn]] lab:;   // { dg-warning "'noreturn' 
attribute ignored" }
+  [[noreturn]] try {} catch (int) {}   // { dg-warning "attributes at 
the beginning of statement are ignored" }
+  if ([[noreturn]] int x = 0) {}   // { dg-warning "'noreturn' 
attribute ignored" }
+  switch (n)
+{
+[[noreturn]] case 1:   // { dg-warning "'noreturn' 
attribute ignored" }
+[[noreturn]] break;// { dg-warning 
"attributes at the beginning of statement are ignored" }
+[[noreturn]] default:  // { dg-warning "'noreturn' 
attribute ignored" }
+break;
+}
+  for ([[noreturn]] auto a : arr) {}   // { dg-warning "'noreturn' 
attribute ignored" }
+  for ([[noreturn]] auto [a, b] : arr2) {} // { dg-warning "'noreturn' 
attribute ignored" }
+   // { dg-error "structured 
bindings only available with" "" { target c++14_down } .-1 }
+  [[noreturn]] asm ("");   // { dg-warning "attributes 
ignored on 'asm' declaration" }
+  try {} catch ([[noreturn]] int x) {} // { dg-warning "'noreturn' 
attribute ignored" }
+  try {} catch ([[noreturn]] int) {}   // { dg-warning "'noreturn' 
attribute ignored" }
+  try {} catch (int [[noreturn]] x) {} // { dg-warning "attribute 
ignored" }
+  try {} catch (int [[noreturn]]) {}   // { dg-warning "attribute 
ignored" }
+  try {} catch (int x [[noreturn]]) {} // { dg-warning "'noreturn' 
attribute ignored" }
+}
+
+[[noreturn]] int bar ();
+using foobar [[noreturn]] = int;   // { dg-warning &quo

c++: Add nodiscard attribute further test coverage [PR110345]

2024-09-05 Thread Jakub Jelinek
Hi!

Fairly non-problematic attribute, again on top of the whole series.

Tested on x86_64-linux, ok for trunk?

2024-09-05  Jakub Jelinek  

PR c++/110345
* g++.dg/cpp0x/attr-nodiscard1.C: New test.

--- gcc/testsuite/g++.dg/cpp0x/attr-nodiscard1.C.jj 2024-09-05 
13:11:26.914049570 +0200
+++ gcc/testsuite/g++.dg/cpp0x/attr-nodiscard1.C2024-09-05 
13:38:05.456626161 +0200
@@ -0,0 +1,155 @@
+// C++ 26 P2552R3 - On the ignorability of standard attributes
+// { dg-do compile { target c++11 } }
+
+int arr[2];
+struct S { int a, b; };
+S arr2[2];
+
+void
+foo (int n)
+{
+  struct [[nodiscard]] S1 {};
+  struct [[nodiscard ("foobar")]] S2 {};
+  struct [[nodiscard (0)]] S3 {};  // { dg-error "'nodiscard' 
attribute argument must be a string constant" }
+  struct [[nodiscard ("foo", "bar", "baz")]] S4 {};// { dg-error "wrong 
number of arguments specified for 'nodiscard' attribute" }
+  struct [[nodiscard (0, 1, 2)]] S5 {};// { dg-error "wrong 
number of arguments specified for 'nodiscard' attribute" }
+
+  auto a = [] [[nodiscard]] () {};
+  auto b = [] constexpr [[nodiscard]] {};  // { dg-warning "'nodiscard' 
attribute can only be applied to functions or to class or enumeration types" }
+   // { dg-error "parameter 
declaration before lambda declaration specifiers only optional with" "" { 
target c++20_down } .-1 }
+   // { dg-error "'constexpr' 
lambda only available with" "" { target c++14_down } .-2 }
+  auto c = [] noexcept [[nodiscard]] {};   // { dg-warning "'nodiscard' 
attribute can only be applied to functions or to class or enumeration types" }
+   // { dg-error "parameter 
declaration before lambda exception specification only optional with" "" { 
target c++20_down } .-1 }
+  auto d = [] () [[nodiscard]] {}; // { dg-warning "'nodiscard' 
attribute can only be applied to functions or to class or enumeration types" }
+  auto e = new int [n] [[nodiscard]];  // { dg-warning "attributes 
ignored on outermost array type in new expression" }
+  auto e2 = new int [n] [[nodiscard]] [42];// { dg-warning "attributes 
ignored on outermost array type in new expression" }
+  auto f = new int [n][42] [[nodiscard]];  // { dg-warning "'nodiscard' 
attribute can only be applied to functions or to class or enumeration types" }
+  [[nodiscard]];   // { dg-warning "attributes at 
the beginning of statement are ignored" }
+  [[nodiscard]] {} // { dg-warning "attributes at 
the beginning of statement are ignored" }
+  [[nodiscard]] if (true) {}   // { dg-warning "attributes at 
the beginning of statement are ignored" }
+  [[nodiscard]] while (false) {}   // { dg-warning "attributes at 
the beginning of statement are ignored" }
+  [[nodiscard]] goto lab;  // { dg-warning "attributes at 
the beginning of statement are ignored" }
+  [[nodiscard]] lab:;  // { dg-warning "'nodiscard' 
attribute can only be applied to functions or to class or enumeration types" }
+  [[nodiscard]] try {} catch (int) {}  // { dg-warning "attributes at 
the beginning of statement are ignored" }
+  if ([[nodiscard]] int x = 0) {}  // { dg-warning "'nodiscard' 
attribute can only be applied to functions or to class or enumeration types" }
+  switch (n)
+{
+[[nodiscard]] case 1:  // { dg-warning "'nodiscard' 
attribute can only be applied to functions or to class or enumeration types" }
+[[nodiscard]] break;   // { dg-warning "attributes at 
the beginning of statement are ignored" }
+[[nodiscard]] default: // { dg-warning "'nodiscard' 
attribute can only be applied to functions or to class or enumeration types" }
+break;
+}
+  for ([[nodiscard]] auto a : arr) {}  // { dg-warning "'nodiscard' 
attribute can only be applied to functions or to class or enumeration types" }
+  for ([[nodiscard]] auto [a, b] : arr2) {}// { dg-warning "'nodiscard' 
attribute can only be applied to functions or to class or enumeration types" }
+   // { dg-error "structured 
bindings only available with" "" { target c++14_down } .-1 }
+  [[nodiscard]] asm (""); 

[PATCH V4 10/10] autovectorizer: Test autovectorization of different dot-prod modes.

2024-09-05 Thread Victor Do Nascimento
Changes from previous revision:

Rename new `check_effective_target' and tests to make their intent
clearer.

  * lib/target-supports.exp: For new `check_effective_target',
s/vect_dotprod_twoway/vect_dotprod_hisi/.
  * One test is renamed to `vect-dotprod-conv-optab.c' to emphasize
aim of checking the new dotprod convert optab allows
autovectorization of a given datatype to distinct target
data-types.
  * The aarch64 runtime-correctness check has had the mode supported
for its two-way dot-product added to the test name, resulting in
the new `vect-dotprod-twoway-hisi.c' name.

--

Given the novel treatment of the dot product optab as a conversion, we
are now able to target 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
+#include 
+#pragma GCC target "+sme2"
+
+uint32_t
+udot2 (int n, uint16_t* data)  __arm_streaming
+{
+  uint32_t sum = 0;
+  for (int i=0; i

[PATCH] c++: Add {,un}likely attribute further test coverage [PR110345]

2024-09-05 Thread Jakub Jelinek
Hi!

Similarly for likely/unlikely attributes.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2024-09-05  Jakub Jelinek  

PR c++/110345
* g++.dg/cpp0x/attr-likely1.C: New test.
* g++.dg/cpp0x/attr-unlikely1.C: New test.

--- gcc/testsuite/g++.dg/cpp0x/attr-likely1.C.jj2024-09-04 
16:53:59.829472783 +0200
+++ gcc/testsuite/g++.dg/cpp0x/attr-likely1.C   2024-09-04 17:04:52.566048248 
+0200
@@ -0,0 +1,149 @@
+// C++ 26 P2552R3 - On the ignorability of standard attributes
+// { dg-do compile { target c++11 } }
+
+int arr[2];
+struct S { int a, b; };
+S arr2[2];
+
+void
+foo (int n)
+{
+  [[likely]];
+  [[likely (1)]];  // { dg-error "'likely' attribute does 
not take any arguments" }
+  [[likely]] ++n;
+  [[likely]] int x1;   // { dg-warning "'likely' attribute 
ignored" }
+
+  auto a = [] [[likely]] () {};// { dg-warning "ISO C\\\+\\\+ 
'likely' attribute does not apply to functions; treating as 
'\\\[\\\[gnu::hot\\\]\\\]'" }
+  auto b = [] constexpr [[likely]] {}; // { dg-warning "'likely' attribute 
ignored" }
+   // { dg-error "parameter declaration 
before lambda declaration specifiers only optional with" "" { target c++20_down 
} .-1 }
+   // { dg-error "'constexpr' lambda only 
available with" "" { target c++14_down } .-2 }
+  auto c = [] noexcept [[likely]] {};  // { dg-warning "'likely' attribute 
ignored" }
+   // { dg-error "parameter declaration 
before lambda exception specification only optional with" "" { target 
c++20_down } .-1 }
+  auto d = [] () [[likely]] {};// { dg-warning "'likely' 
attribute ignored" }
+  auto e = new int [n] [[likely]]; // { dg-warning "attributes ignored on 
outermost array type in new expression" }
+  auto e2 = new int [n] [[likely]] [42];// { dg-warning "attributes ignored on 
outermost array type in new expression" }
+  auto f = new int [n][42] [[likely]]; // { dg-warning "'likely' attribute 
ignored" }
+  [[likely]];
+  [[likely]] {}
+  [[likely]] if (true) {}
+  [[likely]] while (false) {}
+  [[likely]] goto lab;
+  [[likely]] lab:;
+  [[likely]] try {} catch (int) {}
+  if ([[likely]] int x = 0) {} // { dg-warning "'likely' attribute 
ignored" }
+  switch (n)
+{
+[[likely]] case 1:
+[[likely]] break;
+[[likely]] default:
+break;
+}
+  for ([[likely]] auto a : arr) {} // { dg-warning "'likely' attribute 
ignored" }
+  for ([[likely]] auto [a, b] : arr2) {}// { dg-warning "'likely' attribute 
ignored" }
+   // { dg-error "structured bindings only 
available with" "" { target c++14_down } .-1 }
+  [[likely]] asm (""); // { dg-warning "attributes ignored on 
'asm' declaration" }
+  try {} catch ([[likely]] int x) {}   // { dg-warning "'likely' attribute 
ignored" }
+  try {} catch ([[likely]] int) {} // { dg-warning "'likely' attribute 
ignored" }
+  try {} catch (int [[likely]] x) {}   // { dg-warning "attribute ignored" }
+  try {} catch (int [[likely]]) {} // { dg-warning "attribute ignored" }
+  try {} catch (int x [[likely]]) {}   // { dg-warning "'likely' attribute 
ignored" }
+}
+
+[[likely]] int bar (); // { dg-warning "ISO C\\\+\\\+ 'likely' 
attribute does not apply to functions; treating as '\\\[\\\[gnu::hot\\\]\\\]'" }
+using foobar [[likely]] = int; // { dg-warning "'likely' attribute 
ignored" }
+[[likely]] int a;  // { dg-warning "'likely' attribute 
ignored" }
+[[likely]] auto [b, c] = arr;  // { dg-warning "'likely' attribute 
ignored" }
+   // { dg-error "structured bindings only 
available with" "" { target c++14_down } .-1 }
+[[likely]];// { dg-warning "attribute ignored" }
+inline [[likely]] void baz () {}   // { dg-warning "attribute ignored" }
+   // { dg-error "standard attributes in 
middle of decl-specifiers" "" { target *-*-* } .-1 }
+constexpr [[likely]] int qux () { return 0; }  // { dg-warning "attribute 
ignored" }
+   // { dg-error "standard attributes in 
middle of decl-specifiers" "" { target *-*-* } .-1 }
+int [

[PATCH] c++: Add fallthrough attribute further test coverage [PR110345]

2024-09-05 Thread Jakub Jelinek
Hi!

Similarly for fallthrough attribute.  Had to add a second testcase because
the diagnostics for fallthrough not used within switch at all is done during
expansion and expansion won't happen if there are other errors in the
testcase.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2024-09-05  Jakub Jelinek  

PR c++/110345
* g++.dg/cpp0x/attr-fallthrough1.C: New test.
* g++.dg/cpp0x/attr-fallthrough2.C: New test.

--- gcc/testsuite/g++.dg/cpp0x/attr-fallthrough1.C.jj   2024-09-04 
16:27:52.786654084 +0200
+++ gcc/testsuite/g++.dg/cpp0x/attr-fallthrough1.C  2024-09-04 
16:44:41.879666097 +0200
@@ -0,0 +1,169 @@
+// C++ 26 P2552R3 - On the ignorability of standard attributes
+// { dg-do compile { target c++11 } }
+
+int arr[2];
+struct S { int a, b; };
+S arr2[2];
+
+void
+foo (int n)
+{
+  switch (n)
+{
+case 1:
+  [[fallthrough (n > 0)]]; // { dg-error "'fallthrough' 
attribute does not take any arguments" }
+case 2:
+  break;
+case 3:
+  [[fallthrough]];
+case 4:
+  break;
+case 5:
+  [[fallthrough ("abc")]]; // { dg-error "'fallthrough' 
attribute does not take any arguments" }
+case 6:
+  break;
+case 7:
+  [[fallthrough (1, 2, 3)]];   // { dg-error "'fallthrough' 
attribute does not take any arguments" }
+case 8:
+  [[fallthrough]]; // { dg-error "attribute 
'fallthrough' not preceding a case label or default label" }
+  foo (n - 1);
+  break;
+default:
+  break;
+}
+
+  [[fallthrough]] int x1;  // { dg-error "'fallthrough' 
attribute ignored" }
+
+  auto a = [] [[fallthrough]] () {};   // { dg-error "'fallthrough' 
attribute ignored" }
+  auto b = [] constexpr [[fallthrough]] {};// { dg-error "'fallthrough' 
attribute ignored" }
+   // { dg-error "parameter 
declaration before lambda declaration specifiers only optional with" "" { 
target c++20_down } .-1 }
+   // { dg-error "'constexpr' 
lambda only available with" "" { target c++14_down } .-2 }
+  auto c = [] noexcept [[fallthrough]] {}; // { dg-error "'fallthrough' 
attribute ignored" }
+   // { dg-error "parameter 
declaration before lambda exception specification only optional with" "" { 
target c++20_down } .-1 }
+  auto d = [] () [[fallthrough]] {};   // { dg-error "'fallthrough' 
attribute ignored" }
+  auto e = new int [n] [[fallthrough]];// { dg-warning 
"attributes ignored on outermost array type in new expression" }
+  auto e2 = new int [n] [[fallthrough]] [42];  // { dg-warning "attributes 
ignored on outermost array type in new expression" }
+  auto f = new int [n][42] [[fallthrough]];// { dg-error "'fallthrough' 
attribute ignored" }
+  [[fallthrough]] {}   // { dg-warning "attributes at 
the beginning of statement are ignored" }
+  [[fallthrough]] if (true) {} // { dg-warning "attributes at 
the beginning of statement are ignored" }
+  [[fallthrough]] while (false) {} // { dg-warning "attributes at 
the beginning of statement are ignored" }
+  [[fallthrough]] goto lab;// { dg-warning "attributes at 
the beginning of statement are ignored" }
+  [[fallthrough]] lab:;// { dg-error 
"'fallthrough' attribute ignored" }
+  [[fallthrough]] try {} catch (int) {}// { dg-warning 
"attributes at the beginning of statement are ignored" }
+  if ([[fallthrough]] int x = 0) {}// { dg-error "'fallthrough' 
attribute ignored" }
+  switch (n)
+{
+[[fallthrough]] case 1:// { dg-error "'fallthrough' 
attribute ignored" }
+[[fallthrough]] break; // { dg-warning "attributes at 
the beginning of statement are ignored" }
+[[fallthrough]] default:   // { dg-error "'fallthrough' 
attribute ignored" }
+break;
+}
+  for ([[fallthrough]] auto a : arr) {}// { dg-error 
"'fallthrough' attribute ignored" }
+  for ([[fallthrough]] auto [a, b] : arr2) {}  // { dg-error "'fallthrough' 
attribute ignored" }
+   // { dg-error "structured 
bindings only available with" "" { target c++14_down } .-1 }
+  [

[PATCH] c++: Add carries_dependency further test coverage [PR110345]

2024-09-05 Thread Jakub Jelinek
Hi!

This patch adds additional test coverage for the carries_dependency
attribute (unlike other attributes, the attribute actually isn't implemented
for real, so we warn even in the cases of valid uses because we ignore those
as well).

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2024-09-05  Jakub Jelinek  

PR c++/110345
* g++.dg/cpp0x/attr-carries_dependency2.C: New test.

--- gcc/testsuite/g++.dg/cpp0x/attr-carries_dependency2.C.jj2024-09-04 
15:42:01.250738751 +0200
+++ gcc/testsuite/g++.dg/cpp0x/attr-carries_dependency2.C   2024-09-04 
16:21:50.416239580 +0200
@@ -0,0 +1,152 @@
+// C++ 26 P2552R3 - On the ignorability of standard attributes
+// { dg-do compile { target c++11 } }
+
+int arr[2];
+struct S { int a, b; };
+S arr2[2];
+
+void
+xyzzy (int *a [[carries_dependency]],  // { dg-warning 
"'carries_dependency' attribute ignored" }
+   int *b [[carries_dependency (1)]])  // { dg-error 
"'carries_dependency' attribute does not take any arguments" }
+{  // { dg-error "expected 
',' or '...' before 'b'" "" { target *-*-* } .-1 }
+}
+
+void
+foo (int n)
+{
+  [[carries_dependency]] int x1;   // { dg-warning 
"'carries_dependency' attribute can only be applied to functions or parameters" 
}
+
+  auto a = [] [[carries_dependency]] () {};// { dg-warning 
"'carries_dependency' attribute ignored" }
+  auto b = [] constexpr [[carries_dependency]] {}; // { dg-warning 
"'carries_dependency' attribute does not apply to types" }
+   // { dg-error 
"parameter declaration before lambda declaration specifiers only optional with" 
"" { target c++20_down } .-1 }
+   // { dg-error 
"'constexpr' lambda only available with" "" { target c++14_down } .-2 }
+  auto c = [] noexcept [[carries_dependency]] {};  // { dg-warning 
"'carries_dependency' attribute does not apply to types" }
+   // { dg-error 
"parameter declaration before lambda exception specification only optional 
with" "" { target c++20_down } .-1 }
+  auto d = [] () [[carries_dependency]] {};// { dg-warning 
"'carries_dependency' attribute does not apply to types" }
+  auto e = new int [n] [[carries_dependency]]; // { dg-warning 
"attributes ignored on outermost array type in new expression" }
+  auto e2 = new int [n] [[carries_dependency]] [42];   // { dg-warning 
"attributes ignored on outermost array type in new expression" }
+  auto f = new int [n][42] [[carries_dependency]]; // { dg-warning 
"'carries_dependency' attribute does not apply to types" }
+  [[carries_dependency]];  // { dg-warning 
"attributes at the beginning of statement are ignored" }
+  [[carries_dependency]] {}// { dg-warning 
"attributes at the beginning of statement are ignored" }
+  [[carries_dependency]] if (true) {}  // { dg-warning 
"attributes at the beginning of statement are ignored" }
+  [[carries_dependency]] while (false) {}  // { dg-warning 
"attributes at the beginning of statement are ignored" }
+  [[carries_dependency]] goto lab; // { dg-warning 
"attributes at the beginning of statement are ignored" }
+  [[carries_dependency]] lab:; // { dg-warning 
"'carries_dependency' attribute can only be applied to functions or parameters" 
}
+  [[carries_dependency]] try {} catch (int) {} // { dg-warning 
"attributes at the beginning of statement are ignored" }
+  if ([[carries_dependency]] int x = 0) {} // { dg-warning 
"'carries_dependency' attribute can only be applied to functions or parameters" 
}
+  switch (n)
+{
+[[carries_dependency]] case 1: // { dg-warning 
"'carries_dependency' attribute can only be applied to functions or parameters" 
}
+[[carries_dependency]] break;  // { dg-warning 
"attributes at the beginning of statement are ignored" }
+[[carries_dependency]] default:// { dg-warning 
"'carries_dependency' attribute can only be applied to functions or parameters" 
}
+break;
+}
+  for ([[carries_dependency]] auto a : arr) {} // { dg-warning 
"'carries_dependency' attribute can only be applied to functions or paramet

[committed][RISC-V] Fix scan test output after recent path-splitting changes

2024-09-04 Thread Jeff Law


The recent path splitting changes from Andrew result in identifying more 
saturation idioms instead of just identifying an overflow check.  As a 
result many of the tests in the RISC-V port started failing a scan check 
on the .expand output.


As expected, identifying a saturation idiom is more helpful than 
identifying an overflow check and the resultant code is better based on 
my spot checks.


So the right thing to do is to expect more saturation intrinsics in the 
.expand output.


I've verified this fixes the regressions for riscv32-elf and 
riscv64-elf.  Pushing to the trunk.


Jeffcommit 0455e85e4eda7d80bda967914d634fe5b71b7ffc
Author: Jeff Law 
Date:   Wed Sep 4 12:07:09 2024 -0600

[RISC-V] Fix scan test output after recent path-splitting changes

The recent path splitting changes from Andrew result in identifying more
saturation idioms instead of just identifying an overflow check.  As a 
result
many of the tests in the RISC-V port started failing a scan check on the
.expand output.

As expected, identifying a saturation idiom is more helpful than 
identifying an
overflow check and the resultant code is better based on my spot checks.

So the right thing to do is to expect more saturation intrinsics in the 
.expand
output.

I've verified this fixes the regressions for riscv32-elf and riscv64-elf.
Pushing to the trunk.

gcc/testsuite
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-13.c: Adjust
expected output.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-14.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-15.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-16.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-17.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-18.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-19.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-20.c: Likewise.
* 
gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add_imm_reconcile-1.c:
Likewise.
* 
gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add_imm_reconcile-2.c:
Likewise.
* 
gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add_imm_reconcile-5.c:
Likewise.
* 
gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add_imm_reconcile-6.c:
Likewise.
* 
gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add_imm_reconcile-9.c:
Likewise.
* 
gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add_imm_reconcile-10.c:
Likewise.
* 
gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add_imm_reconcile-13.c:
Likewise.
* 
gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add_imm_reconcile-14.c:
Likewise.
* 
gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add_imm_reconcile-15.c:
Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-9.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-10.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-11.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-12.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-13.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-14.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-15.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-16.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-17.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-18.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-19.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-20.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-21.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-22.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-23.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-24.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-33.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-34.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-35.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-36.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-37.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-38.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-39.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-40.c: Likewise.

diff --git 
a/gcc/testsuite/gcc.target/riscv/r

RE: [r15-3359 Regression] FAIL: gcc.target/i386/avx10_2-bf-vector-cmpp-1.c (test for excess errors) on Linux/x86_64

2024-09-04 Thread Jiang, Haochen
> -Original Message-
> From: Richard Biener 
> Sent: Tuesday, September 3, 2024 2:40 PM
> 
> On Tue, Sep 3, 2024 at 7:36 AM Jiang, Haochen 
> wrote:
> >
> >
> >
> > > From: Hongtao Liu 
> > > Sent: Tuesday, September 3, 2024 1:47 PM
> > >
> > > On Tue, Sep 3, 2024 at 9:45 AM Jiang, Haochen via Gcc-regression
> > >  wrote:
> > > >
> > > > As each AVX10.2 testcases previously, this is caused by option
> combination
> > > warning,
> > > > which is expected.
> > > >
> > > Can we put the warning for mix usage of mavx10 and -mavx512f under -
> > > Wpsabi
> > > And add -Wno-psabi in addition to -march=cascadelake to avoid the
> > > false positive?
> >
> > We could do that if nobody has objection to that.
> 
> But mixing both doesn't do anything to the ABI so -Wpsabi sounds like the
> wrong bucket to me.  Instead we have to solve the issue at hand - I would
> expect users to run into this warning as well if we do within our testsuite?

If we can bear that "false positive", I suppose it is ok.

l will change the -march=cascadelake to the future CPU contains AVX10.2
when it is doable to eliminate them.

Thx,
Haochen

> 
> Richard.
> 
> > Thx,
> > Haochen
> >
> > >
> > > --
> > > BR,
> > > Hongtao


Re: [PING^3] [PATCH] PR116080: Fix test suite checks for musttail

2024-09-03 Thread Mike Stump
On Sep 2, 2024, at 4:23 PM, Andi Kleen  wrote:
> 
> Andi Kleen  writes:
> 
> PING^3

Ok.

>> Andi Kleen  writes:
>> 
>> PING^2 for https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658602.html
>> 
>> This fixes some musttail related test suite failures that cause noise on
>> various targets.
>> 
>>> Andi Kleen  writes:
>>> 
>>> I wanted to ping this patch. It fixes test suite noise on various
>>> targets.
>>> 
>>> https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658602.html
>>> 
>>> 
>>>> From: Andi Kleen 
>>>> 
>>>> This is a new attempt to fix PR116080. The previous try was reverted
>>>> because it just broke a bunch of tests, hiding the problem.
>>>> 
>>>> - musttail behaves differently than tailcall at -O0. Some of the test
>>>> run at -O0, so add separate effective target tests for musttail.
>>>> - New effective target tests need to use unique file names
>>>> to make dejagnu caching work
>>>> - Change the tests to use new targets
>>>> - Add a external_musttail test to check for target's ability
>>>> to do tail calls between translation units. This covers some powerpc
>>>> ABIs.
>>>> 
>>>> gcc/testsuite/ChangeLog:
>>>> 
>>>>PR testsuite/116080
>>>>* c-c++-common/musttail1.c: Use musttail target.
>>>>* c-c++-common/musttail12.c: Use struct_musttail target.
>>>>* c-c++-common/musttail2.c: Use musttail target.
>>>>* c-c++-common/musttail3.c: Likewise.
>>>>* c-c++-common/musttail4.c: Likewise.
>>>>* c-c++-common/musttail7.c: Likewise.
>>>>* c-c++-common/musttail8.c: Likewise.
>>>>* g++.dg/musttail10.C: Likewise. Replace powerpc checks with
>>>>external_musttail.
>>>>* g++.dg/musttail11.C: Use musttail target.
>>>>* g++.dg/musttail6.C: Use musttail target. Replace powerpc
>>>>checks with external_musttail.
>>>>* g++.dg/musttail9.C: Use musttail target.
>>>>* lib/target-supports.exp: Add musttail, struct_musttail,
>>>>external_musttail targets. Remove optimization for musttail.
>>>>Use unique file names for musttail.
>>>> ---
>>>> gcc/testsuite/c-c++-common/musttail1.c  |  2 +-
>>>> gcc/testsuite/c-c++-common/musttail12.c |  2 +-
>>>> gcc/testsuite/c-c++-common/musttail2.c  |  2 +-
>>>> gcc/testsuite/c-c++-common/musttail3.c  |  2 +-
>>>> gcc/testsuite/c-c++-common/musttail4.c  |  2 +-
>>>> gcc/testsuite/c-c++-common/musttail7.c  |  2 +-
>>>> gcc/testsuite/c-c++-common/musttail8.c  |  2 +-
>>>> gcc/testsuite/g++.dg/musttail10.C   |  4 ++--
>>>> gcc/testsuite/g++.dg/musttail11.C   |  2 +-
>>>> gcc/testsuite/g++.dg/musttail6.C|  4 ++--
>>>> gcc/testsuite/g++.dg/musttail9.C|  2 +-
>>>> gcc/testsuite/lib/target-supports.exp   | 30 -
>>>> 12 files changed, 37 insertions(+), 19 deletions(-)
>>>> 
>>>> diff --git a/gcc/testsuite/c-c++-common/musttail1.c 
>>>> b/gcc/testsuite/c-c++-common/musttail1.c
>>>> index 74efcc2a0bc6..51549672e02a 100644
>>>> --- a/gcc/testsuite/c-c++-common/musttail1.c
>>>> +++ b/gcc/testsuite/c-c++-common/musttail1.c
>>>> @@ -1,4 +1,4 @@
>>>> -/* { dg-do compile { target { tail_call && { c || c++11 } } } } */
>>>> +/* { dg-do compile { target { musttail && { c || c++11 } } } } */
>>>> /* { dg-additional-options "-fdelayed-branch" { target sparc*-*-* } } */
>>>> 
>>>> int __attribute__((noinline,noclone,noipa))
>>>> diff --git a/gcc/testsuite/c-c++-common/musttail12.c 
>>>> b/gcc/testsuite/c-c++-common/musttail12.c
>>>> index 4140bcd00950..475afc5af3f3 100644
>>>> --- a/gcc/testsuite/c-c++-common/musttail12.c
>>>> +++ b/gcc/testsuite/c-c++-common/musttail12.c
>>>> @@ -1,4 +1,4 @@
>>>> -/* { dg-do compile { target { struct_tail_call && { c || c++11 } } } } */
>>>> +/* { dg-do compile { target { struct_musttail && { c || c++11 } } } } */
>>>> /* { dg-additional-options "-fdelayed-branch" { target sparc*-*-* } } */
>>>> 
>>>> struct str
>>>> diff --git a/gcc/testsuite/c-c++-common/musttail2.c 
>>>> b/gcc/testsuite/c-c++-common/musttail2.c
>

[pushed] c++: add fixed test [PR109095]

2024-09-03 Thread Marek Polacek
Tested x86_64-pc-linux-gnu, applying to trunk.

-- >8 --
Fixed by r13-6693.

PR c++/109095

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/nontype-class66.C: New test.
---
 gcc/testsuite/g++.dg/cpp2a/nontype-class66.C | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/nontype-class66.C

diff --git a/gcc/testsuite/g++.dg/cpp2a/nontype-class66.C 
b/gcc/testsuite/g++.dg/cpp2a/nontype-class66.C
new file mode 100644
index 000..385b290521f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/nontype-class66.C
@@ -0,0 +1,19 @@
+// PR c++/109095
+// { dg-do compile { target c++20 } }
+
+template< typename T >
+struct bar
+{};
+
+template< int X >
+struct baz
+{};
+
+template< auto N, template< auto N2 > typename TT >
+struct foo;
+
+template< typename T, bar< T > B, template< T N2 > typename TT >
+struct foo< B, TT >
+{};
+
+foo< bar< int >{}, baz > x;

base-commit: f0ab3de6ec0e3540f2e57f3f5628005f0a4e3fa5
-- 
2.46.0



Re: [PATCH] testsuite: Sanitize pacbti test cases for Cortex-M

2024-09-03 Thread Christophe Lyon

Hi Torbjörn,


On 9/3/24 11:30, Torbjörn SVENSSON wrote:


Ok for trunk and releases/gcc-14?

--

Some of the test cases were scanning for "bti", but it would,
incorrectly, match the ".arch_extenssion pacbti".
Also, keep test cases active if a supported Cortex-M core is supplied.

gcc/testsuite/ChangeLog:

* gcc.target/arm/bti-1.c: Enable for Cortex-M(52|55|85) and
check for \tbti.
* gcc.target/arm/bti-2.c: Likewise.
* gcc.target/arm/pac-15.c: Likewise.
For pac-15.c, your patch only enables the test for cortex-m{52|55|85}, 
there's not scan-assembler for bti :-)



* gcc.target/arm/pac-4.c: Check for \tbti.
* gcc.target/arm/pac-6.c: Likewise.

Signed-off-by: Torbjörn SVENSSON 
Co-authored-by: Yvan ROUX 
---
  gcc/testsuite/gcc.target/arm/bti-1.c  | 4 ++--
  gcc/testsuite/gcc.target/arm/bti-2.c  | 4 ++--
  gcc/testsuite/gcc.target/arm/pac-15.c | 2 +-
  gcc/testsuite/gcc.target/arm/pac-4.c  | 2 +-
  gcc/testsuite/gcc.target/arm/pac-6.c  | 2 +-
  5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/bti-1.c 
b/gcc/testsuite/gcc.target/arm/bti-1.c
index 79dd8010d2d..70a62b5a70c 100644
--- a/gcc/testsuite/gcc.target/arm/bti-1.c
+++ b/gcc/testsuite/gcc.target/arm/bti-1.c
@@ -1,6 +1,6 @@
  /* Check that GCC does bti instruction.  */
  /* { dg-do compile } */
-/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } } */
+/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" "-mcpu=*" } { 
"-mcpu=cortex-m52*" "-mcpu=cortex-m55*" "-mcpu=cortex-m85*" } } */

I'm not sure this is the way forward, but I'll let Richard comment.


  /* { dg-options "-march=armv8.1-m.main -mthumb -mfloat-abi=softfp 
-mbranch-protection=bti --save-temps" } */
  
  int

@@ -9,4 +9,4 @@ main (void)
return 0;
  }
  
-/* { dg-final { scan-assembler "bti" } } */

+/* { dg-final { scan-assembler "\tbti" } } */
diff --git a/gcc/testsuite/gcc.target/arm/bti-2.c 
b/gcc/testsuite/gcc.target/arm/bti-2.c
index 33910563849..44c04d3df68 100644
--- a/gcc/testsuite/gcc.target/arm/bti-2.c
+++ b/gcc/testsuite/gcc.target/arm/bti-2.c
@@ -1,7 +1,7 @@
  /* { dg-do compile } */
  /* -Os to create jump table.  */
  /* { dg-options "-Os" } */
-/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } } */
+/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" "-mcpu=*" } { 
"-mcpu=cortex-m52*" "-mcpu=cortex-m55*" "-mcpu=cortex-m85*" } } */
  /* { dg-options "-march=armv8.1-m.main -mthumb -mfloat-abi=softfp 
-mbranch-protection=bti --save-temps" } */
  
  extern int f1 (void);

@@ -55,4 +55,4 @@ lab2:
return 2;
  }
  
-/* { dg-final { scan-assembler-times "bti" 15 } } */

+/* { dg-final { scan-assembler-times "\tbti" 15 } } */
diff --git a/gcc/testsuite/gcc.target/arm/pac-15.c 
b/gcc/testsuite/gcc.target/arm/pac-15.c
index e1054902955..a2582e64d0a 100644
--- a/gcc/testsuite/gcc.target/arm/pac-15.c
+++ b/gcc/testsuite/gcc.target/arm/pac-15.c
@@ -1,7 +1,7 @@
  /* Check that GCC does .save and .cfi_offset directives with RA_AUTH_CODE 
pseudo hard-register.  */
  /* { dg-do compile } */
  /* { dg-require-effective-target mbranch_protection_ok } */
-/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } } */
+/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" "-mcpu=*" } { 
"-mcpu=cortex-m52*" "-mcpu=cortex-m55*" "-mcpu=cortex-m85*" } } */
  /* { dg-options "-march=armv8.1-m.main+mve+pacbti -mbranch-protection=pac-ret 
-mthumb -mfloat-abi=hard -fasynchronous-unwind-tables -g -O0" } */
  
  #include "stdio.h"

How about
-/* { dg-final { scan-assembler-times "pac   ip, lr, sp" 3 } } */
+/* { dg-final { scan-assembler-times "\tpac\tip, lr, sp" 3 } } */
?


diff --git a/gcc/testsuite/gcc.target/arm/pac-4.c 
b/gcc/testsuite/gcc.target/arm/pac-4.c
index cf915cdba50..81907079d77 100644
--- a/gcc/testsuite/gcc.target/arm/pac-4.c
+++ b/gcc/testsuite/gcc.target/arm/pac-4.c
@@ -5,6 +5,6 @@
  
  #include "pac.h"
  
-/* { dg-final { scan-assembler-not "\tbti\t" } } */

+/* { dg-final { scan-assembler-not "\tbti" } } */
  /* { dg-final { scan-assembler-not "\tpac\t" } } */
  /* { dg-final { scan-assembler-not "\tpacbti\t" } } */
diff --git a/gcc/testsuite/gcc.target/arm/pac-6.c 
b/gcc/testsuite/gcc.target/arm/pac-6.c
index c5329f0ef48..15260c5c028 100644
--- a/gcc/testsuite/gcc.target/arm/pac-6.c
+++ b/gcc/testsuite/gcc.target/arm/pac-6.c
@@ -15,4 +15,4 @@ int bar()
  
  /* { dg-final { scan-assembler "pac\tip, lr, sp" } } */

  /* { dg-final { scan-assembler "aut\tip, lr, sp" } } */

Why not prefix those two with '\t' too?


-/* { dg-final { scan-assembler-not "bti" } } */
+/* { dg-final { scan-assembler-not "\tbti" } } */


In all pac-*.c tests, I noticed many scan-assembler directives without 
leading '\t' (for pac, aut, pacbti instructions for instance).


Shouldn't we add it there too?

Thanks,

Christophe


[PATCH] testsuite: Sanitize pacbti test cases for Cortex-M

2024-09-03 Thread Torbjörn SVENSSON


Ok for trunk and releases/gcc-14?

--

Some of the test cases were scanning for "bti", but it would,
incorrectly, match the ".arch_extenssion pacbti".
Also, keep test cases active if a supported Cortex-M core is supplied.

gcc/testsuite/ChangeLog:

* gcc.target/arm/bti-1.c: Enable for Cortex-M(52|55|85) and
check for \tbti.
* gcc.target/arm/bti-2.c: Likewise.
* gcc.target/arm/pac-15.c: Likewise.
* gcc.target/arm/pac-4.c: Check for \tbti.
* gcc.target/arm/pac-6.c: Likewise.

Signed-off-by: Torbjörn SVENSSON 
Co-authored-by: Yvan ROUX 
---
 gcc/testsuite/gcc.target/arm/bti-1.c  | 4 ++--
 gcc/testsuite/gcc.target/arm/bti-2.c  | 4 ++--
 gcc/testsuite/gcc.target/arm/pac-15.c | 2 +-
 gcc/testsuite/gcc.target/arm/pac-4.c  | 2 +-
 gcc/testsuite/gcc.target/arm/pac-6.c  | 2 +-
 5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/bti-1.c 
b/gcc/testsuite/gcc.target/arm/bti-1.c
index 79dd8010d2d..70a62b5a70c 100644
--- a/gcc/testsuite/gcc.target/arm/bti-1.c
+++ b/gcc/testsuite/gcc.target/arm/bti-1.c
@@ -1,6 +1,6 @@
 /* Check that GCC does bti instruction.  */
 /* { dg-do compile } */
-/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } } */
+/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } { "-mcpu=cortex-m52*" "-mcpu=cortex-m55*" "-mcpu=cortex-m85*" } } */
 /* { dg-options "-march=armv8.1-m.main -mthumb -mfloat-abi=softfp 
-mbranch-protection=bti --save-temps" } */
 
 int
@@ -9,4 +9,4 @@ main (void)
   return 0;
 }
 
-/* { dg-final { scan-assembler "bti" } } */
+/* { dg-final { scan-assembler "\tbti" } } */
diff --git a/gcc/testsuite/gcc.target/arm/bti-2.c 
b/gcc/testsuite/gcc.target/arm/bti-2.c
index 33910563849..44c04d3df68 100644
--- a/gcc/testsuite/gcc.target/arm/bti-2.c
+++ b/gcc/testsuite/gcc.target/arm/bti-2.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* -Os to create jump table.  */
 /* { dg-options "-Os" } */
-/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } } */
+/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } { "-mcpu=cortex-m52*" "-mcpu=cortex-m55*" "-mcpu=cortex-m85*" } } */
 /* { dg-options "-march=armv8.1-m.main -mthumb -mfloat-abi=softfp 
-mbranch-protection=bti --save-temps" } */
 
 extern int f1 (void);
@@ -55,4 +55,4 @@ lab2:
   return 2;
 }
 
-/* { dg-final { scan-assembler-times "bti" 15 } } */
+/* { dg-final { scan-assembler-times "\tbti" 15 } } */
diff --git a/gcc/testsuite/gcc.target/arm/pac-15.c 
b/gcc/testsuite/gcc.target/arm/pac-15.c
index e1054902955..a2582e64d0a 100644
--- a/gcc/testsuite/gcc.target/arm/pac-15.c
+++ b/gcc/testsuite/gcc.target/arm/pac-15.c
@@ -1,7 +1,7 @@
 /* Check that GCC does .save and .cfi_offset directives with RA_AUTH_CODE 
pseudo hard-register.  */
 /* { dg-do compile } */
 /* { dg-require-effective-target mbranch_protection_ok } */
-/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } } */
+/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } { "-mcpu=cortex-m52*" "-mcpu=cortex-m55*" "-mcpu=cortex-m85*" } } */
 /* { dg-options "-march=armv8.1-m.main+mve+pacbti -mbranch-protection=pac-ret 
-mthumb -mfloat-abi=hard -fasynchronous-unwind-tables -g -O0" } */
 
 #include "stdio.h"
diff --git a/gcc/testsuite/gcc.target/arm/pac-4.c 
b/gcc/testsuite/gcc.target/arm/pac-4.c
index cf915cdba50..81907079d77 100644
--- a/gcc/testsuite/gcc.target/arm/pac-4.c
+++ b/gcc/testsuite/gcc.target/arm/pac-4.c
@@ -5,6 +5,6 @@
 
 #include "pac.h"
 
-/* { dg-final { scan-assembler-not "\tbti\t" } } */
+/* { dg-final { scan-assembler-not "\tbti" } } */
 /* { dg-final { scan-assembler-not "\tpac\t" } } */
 /* { dg-final { scan-assembler-not "\tpacbti\t" } } */
diff --git a/gcc/testsuite/gcc.target/arm/pac-6.c 
b/gcc/testsuite/gcc.target/arm/pac-6.c
index c5329f0ef48..15260c5c028 100644
--- a/gcc/testsuite/gcc.target/arm/pac-6.c
+++ b/gcc/testsuite/gcc.target/arm/pac-6.c
@@ -15,4 +15,4 @@ int bar()
 
 /* { dg-final { scan-assembler "pac\tip, lr, sp" } } */
 /* { dg-final { scan-assembler "aut\tip, lr, sp" } } */
-/* { dg-final { scan-assembler-not "bti" } } */
+/* { dg-final { scan-assembler-not "\tbti" } } */
-- 
2.25.1



[r15-3392 Regression] FAIL: gcc.target/i386/avx10_2-partial-bf-vector-smaxmin-1.c (test for excess errors) on Linux/x86_64

2024-09-03 Thread haochen.jiang
On Linux/x86_64,

62df24e50039ae04aa3b940e680cffd9041ef5bf is the first bad commit
commit 62df24e50039ae04aa3b940e680cffd9041ef5bf
Author: Levy Hsu 
Date:   Tue Aug 27 14:22:20 2024 +0930

i386: Support partial vectorized V2BF/V4BF smaxmin

caused

FAIL: gcc.target/i386/avx10_2-512-bf-vector-smaxmin-1.c scan-assembler-times 
vmaxpbf16 1
FAIL: gcc.target/i386/avx10_2-512-bf-vector-smaxmin-1.c scan-assembler-times 
vminpbf16 1
FAIL: gcc.target/i386/avx10_2-bf-vector-smaxmin-1.c scan-assembler-times 
vmaxpbf16 2
FAIL: gcc.target/i386/avx10_2-bf-vector-smaxmin-1.c scan-assembler-times 
vminpbf16 2
FAIL: gcc.target/i386/avx10_2-bf-vector-smaxmin-1.c (test for excess errors)
FAIL: gcc.target/i386/avx10_2-partial-bf-vector-smaxmin-1.c (test for excess 
errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-3392/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/avx10_2-512-bf-vector-smaxmin-1.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-512-bf-vector-smaxmin-1.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-512-bf-vector-smaxmin-1.c 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-512-bf-vector-smaxmin-1.c 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-bf-vector-smaxmin-1.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-bf-vector-smaxmin-1.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-bf-vector-smaxmin-1.c 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-bf-vector-smaxmin-1.c 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-partial-bf-vector-smaxmin-1.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.)


[r15-3391 Regression] FAIL: gcc.target/i386/avx10_2-partial-bf-vector-operations-1.c (test for excess errors) on Linux/x86_64

2024-09-03 Thread haochen.jiang
On Linux/x86_64,

8e16f26ca9fad685b9b723da7112ffcc99e81593 is the first bad commit
commit 8e16f26ca9fad685b9b723da7112ffcc99e81593
Author: Levy Hsu 
Date:   Mon Aug 26 10:46:30 2024 +0930

i386: Support partial vectorized V2BF/V4BF plus/minus/mult/div/sqrt

caused

FAIL: gcc.target/i386/avx10_2-partial-bf-vector-fast-math-1.c (test for excess 
errors)
FAIL: gcc.target/i386/avx10_2-partial-bf-vector-operations-1.c (test for excess 
errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-3391/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/avx10_2-partial-bf-vector-fast-math-1.c 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-partial-bf-vector-operations-1.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: [r15-3359 Regression] FAIL: gcc.target/i386/avx10_2-bf-vector-cmpp-1.c (test for excess errors) on Linux/x86_64

2024-09-02 Thread Richard Biener
On Tue, Sep 3, 2024 at 7:36 AM Jiang, Haochen  wrote:
>
>
>
> > -Original Message-
> > From: Hongtao Liu 
> > Sent: Tuesday, September 3, 2024 1:47 PM
> > To: Jiang, Haochen 
> > Cc: haochen.jiang ; ad...@levyhsu.com; gcc-
> > regress...@gcc.gnu.org; gcc-patches@gcc.gnu.org
> > Subject: Re: [r15-3359 Regression] FAIL: gcc.target/i386/avx10_2-bf-vector-
> > cmpp-1.c (test for excess errors) on Linux/x86_64
> >
> > On Tue, Sep 3, 2024 at 9:45 AM Jiang, Haochen via Gcc-regression
> >  wrote:
> > >
> > > As each AVX10.2 testcases previously, this is caused by option combination
> > warning,
> > > which is expected.
> > >
> > Can we put the warning for mix usage of mavx10 and -mavx512f under -
> > Wpsabi
> > And add -Wno-psabi in addition to -march=cascadelake to avoid the
> > false positive?
>
> We could do that if nobody has objection to that.

But mixing both doesn't do anything to the ABI so -Wpsabi sounds like the
wrong bucket to me.  Instead we have to solve the issue at hand - I would
expect users to run into this warning as well if we do within our testsuite?

Richard.

> Thx,
> Haochen
>
> >
> > --
> > BR,
> > Hongtao


RE: [r15-3359 Regression] FAIL: gcc.target/i386/avx10_2-bf-vector-cmpp-1.c (test for excess errors) on Linux/x86_64

2024-09-02 Thread Jiang, Haochen


> -Original Message-
> From: Hongtao Liu 
> Sent: Tuesday, September 3, 2024 1:47 PM
> To: Jiang, Haochen 
> Cc: haochen.jiang ; ad...@levyhsu.com; gcc-
> regress...@gcc.gnu.org; gcc-patches@gcc.gnu.org
> Subject: Re: [r15-3359 Regression] FAIL: gcc.target/i386/avx10_2-bf-vector-
> cmpp-1.c (test for excess errors) on Linux/x86_64
> 
> On Tue, Sep 3, 2024 at 9:45 AM Jiang, Haochen via Gcc-regression
>  wrote:
> >
> > As each AVX10.2 testcases previously, this is caused by option combination
> warning,
> > which is expected.
> >
> Can we put the warning for mix usage of mavx10 and -mavx512f under -
> Wpsabi
> And add -Wno-psabi in addition to -march=cascadelake to avoid the
> false positive?

We could do that if nobody has objection to that.

Thx,
Haochen

> 
> --
> BR,
> Hongtao


Re: [r15-3359 Regression] FAIL: gcc.target/i386/avx10_2-bf-vector-cmpp-1.c (test for excess errors) on Linux/x86_64

2024-09-02 Thread Hongtao Liu
On Tue, Sep 3, 2024 at 9:45 AM Jiang, Haochen via Gcc-regression
 wrote:
>
> As each AVX10.2 testcases previously, this is caused by option combination 
> warning,
> which is expected.
>
Can we put the warning for mix usage of mavx10 and -mavx512f under -Wpsabi
And add -Wno-psabi in addition to -march=cascadelake to avoid the
false positive?

-- 
BR,
Hongtao


RE: [r15-3359 Regression] FAIL: gcc.target/i386/avx10_2-bf-vector-cmpp-1.c (test for excess errors) on Linux/x86_64

2024-09-02 Thread Jiang, Haochen
As each AVX10.2 testcases previously, this is caused by option combination 
warning,
which is expected.

> From: haochen.jiang 
> Sent: Monday, September 2, 2024 9:06 PM
> 
> On Linux/x86_64,
> 
> f77435aa3911c437cba71991509eee57b333b3ce is the first bad commit commit
> f77435aa3911c437cba71991509eee57b333b3ce
> Author: Levy Hsu 
> Date:   Mon Sep 2 10:24:49 2024 +0800
> 
> i386: Support vec_cmp for V8BF/V16BF/V32BF in AVX10.2
> 
> caused
> 
> FAIL: gcc.target/i386/avx10_2-bf-vector-cmpp-1.c (test for excess errors)
> 
> with GCC configured with
> 
> ../../gcc/configure --prefix=/export/users/haochenj/src/gcc-
> bisect/master/master/r15-3359/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/avx10_2-bf-vector-cmpp-1.c --
> target_board='unix{-m32\ -march=cascadelake}'"
> $ cd {build_dir}/gcc && make check
> RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-bf-vector-cmpp-1.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.)


[PING^3] [PATCH] PR116080: Fix test suite checks for musttail

2024-09-02 Thread Andi Kleen
Andi Kleen  writes:

PING^3

> Andi Kleen  writes:
>
> PING^2 for https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658602.html
>
> This fixes some musttail related test suite failures that cause noise on
> various targets.
>
>> Andi Kleen  writes:
>>
>> I wanted to ping this patch. It fixes test suite noise on various
>> targets.
>>
>> https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658602.html
>>
>>
>>> From: Andi Kleen 
>>>
>>> This is a new attempt to fix PR116080. The previous try was reverted
>>> because it just broke a bunch of tests, hiding the problem.
>>>
>>> - musttail behaves differently than tailcall at -O0. Some of the test
>>> run at -O0, so add separate effective target tests for musttail.
>>> - New effective target tests need to use unique file names
>>> to make dejagnu caching work
>>> - Change the tests to use new targets
>>> - Add a external_musttail test to check for target's ability
>>> to do tail calls between translation units. This covers some powerpc
>>> ABIs.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> PR testsuite/116080
>>> * c-c++-common/musttail1.c: Use musttail target.
>>> * c-c++-common/musttail12.c: Use struct_musttail target.
>>> * c-c++-common/musttail2.c: Use musttail target.
>>> * c-c++-common/musttail3.c: Likewise.
>>> * c-c++-common/musttail4.c: Likewise.
>>> * c-c++-common/musttail7.c: Likewise.
>>> * c-c++-common/musttail8.c: Likewise.
>>> * g++.dg/musttail10.C: Likewise. Replace powerpc checks with
>>> external_musttail.
>>> * g++.dg/musttail11.C: Use musttail target.
>>> * g++.dg/musttail6.C: Use musttail target. Replace powerpc
>>> checks with external_musttail.
>>> * g++.dg/musttail9.C: Use musttail target.
>>> * lib/target-supports.exp: Add musttail, struct_musttail,
>>> external_musttail targets. Remove optimization for musttail.
>>> Use unique file names for musttail.
>>> ---
>>>  gcc/testsuite/c-c++-common/musttail1.c  |  2 +-
>>>  gcc/testsuite/c-c++-common/musttail12.c |  2 +-
>>>  gcc/testsuite/c-c++-common/musttail2.c  |  2 +-
>>>  gcc/testsuite/c-c++-common/musttail3.c  |  2 +-
>>>  gcc/testsuite/c-c++-common/musttail4.c  |  2 +-
>>>  gcc/testsuite/c-c++-common/musttail7.c  |  2 +-
>>>  gcc/testsuite/c-c++-common/musttail8.c  |  2 +-
>>>  gcc/testsuite/g++.dg/musttail10.C   |  4 ++--
>>>  gcc/testsuite/g++.dg/musttail11.C   |  2 +-
>>>  gcc/testsuite/g++.dg/musttail6.C|  4 ++--
>>>  gcc/testsuite/g++.dg/musttail9.C|  2 +-
>>>  gcc/testsuite/lib/target-supports.exp   | 30 -
>>>  12 files changed, 37 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/gcc/testsuite/c-c++-common/musttail1.c 
>>> b/gcc/testsuite/c-c++-common/musttail1.c
>>> index 74efcc2a0bc6..51549672e02a 100644
>>> --- a/gcc/testsuite/c-c++-common/musttail1.c
>>> +++ b/gcc/testsuite/c-c++-common/musttail1.c
>>> @@ -1,4 +1,4 @@
>>> -/* { dg-do compile { target { tail_call && { c || c++11 } } } } */
>>> +/* { dg-do compile { target { musttail && { c || c++11 } } } } */
>>>  /* { dg-additional-options "-fdelayed-branch" { target sparc*-*-* } } */
>>>  
>>>  int __attribute__((noinline,noclone,noipa))
>>> diff --git a/gcc/testsuite/c-c++-common/musttail12.c 
>>> b/gcc/testsuite/c-c++-common/musttail12.c
>>> index 4140bcd00950..475afc5af3f3 100644
>>> --- a/gcc/testsuite/c-c++-common/musttail12.c
>>> +++ b/gcc/testsuite/c-c++-common/musttail12.c
>>> @@ -1,4 +1,4 @@
>>> -/* { dg-do compile { target { struct_tail_call && { c || c++11 } } } } */
>>> +/* { dg-do compile { target { struct_musttail && { c || c++11 } } } } */
>>>  /* { dg-additional-options "-fdelayed-branch" { target sparc*-*-* } } */
>>>  
>>>  struct str
>>> diff --git a/gcc/testsuite/c-c++-common/musttail2.c 
>>> b/gcc/testsuite/c-c++-common/musttail2.c
>>> index 86f2c3d77404..1970c4edd670 100644
>>> --- a/gcc/testsuite/c-c++-common/musttail2.c
>>> +++ b/gcc/testsuite/c-c++-common/musttail2.c
>>> @@ -1,4 +1,4 @@
>>> -/* { dg-do compile { target { tail_call && { c || c++11 } } } } */
>>> +/* { dg-do compile { target { musttail && { c || c++11 } } } } */
>>>  
>>&g

[r15-3355 Regression] FAIL: gcc.target/i386/avx10_2-bf-vector-operations-1.c (test for excess errors) on Linux/x86_64

2024-09-02 Thread haochen.jiang
On Linux/x86_64,

f82fa0da4d9e1fdaf5e4edd70364d5781534ce11 is the first bad commit
commit f82fa0da4d9e1fdaf5e4edd70364d5781534ce11
Author: Levy Hsu 
Date:   Mon Sep 2 10:24:45 2024 +0800

i386: Support vectorized BF16 add/sub/mul/div with AVX10.2 instructions

caused

FAIL: gcc.target/i386/avx10_2-bf-vector-operations-1.c (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-3355/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/avx10_2-bf-vector-operations-1.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-bf-vector-operations-1.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.)


[r15-3357 Regression] FAIL: gcc.target/i386/avx10_2-bf-vector-smaxmin-1.c (test for excess errors) on Linux/x86_64

2024-09-02 Thread haochen.jiang
On Linux/x86_64,

29ef601973d7b79338694e59581d4c24bcd07f69 is the first bad commit
commit 29ef601973d7b79338694e59581d4c24bcd07f69
Author: Levy Hsu 
Date:   Mon Sep 2 10:24:47 2024 +0800

i386: Support vectorized BF16 smaxmin with AVX10.2 instructions

caused

FAIL: gcc.target/i386/avx10_2-bf-vector-smaxmin-1.c (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-3357/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/avx10_2-bf-vector-smaxmin-1.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-bf-vector-smaxmin-1.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.)


[r15-3359 Regression] FAIL: gcc.target/i386/avx10_2-bf-vector-cmpp-1.c (test for excess errors) on Linux/x86_64

2024-09-02 Thread haochen.jiang
On Linux/x86_64,

f77435aa3911c437cba71991509eee57b333b3ce is the first bad commit
commit f77435aa3911c437cba71991509eee57b333b3ce
Author: Levy Hsu 
Date:   Mon Sep 2 10:24:49 2024 +0800

i386: Support vec_cmp for V8BF/V16BF/V32BF in AVX10.2

caused

FAIL: gcc.target/i386/avx10_2-bf-vector-cmpp-1.c (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-3359/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/avx10_2-bf-vector-cmpp-1.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-bf-vector-cmpp-1.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.)


[r15-3354 Regression] FAIL: gcc.target/i386/avx10_2-compare-1b.c (test for excess errors) on Linux/x86_64

2024-09-02 Thread haochen.jiang
On Linux/x86_64,

3b1decef83003db9cf8667977c293435c0f3d024 is the first bad commit
commit 3b1decef83003db9cf8667977c293435c0f3d024
Author: Hu, Lin1 
Date:   Mon Sep 2 10:24:36 2024 +0800

i386: Optimize generate insn for AVX10.2 compare

caused

FAIL: gcc.target/i386/avx10_2-compare-1b.c (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-3354/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/avx10_2-compare-1b.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-compare-1b.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.)


[r15-3352 Regression] FAIL: gcc.target/i386/vnniint8-auto-vectorize-3.c (test for excess errors) on Linux/x86_64

2024-09-02 Thread haochen.jiang
On Linux/x86_64,

b1f9fbb6da1a3ced57c3668cecc9f9449e1b237e is the first bad commit
commit b1f9fbb6da1a3ced57c3668cecc9f9449e1b237e
Author: Haochen Jiang 
Date:   Mon Sep 2 10:24:29 2024 +0800

i386: Auto vectorize sdot_prod, usdot_prod, udot_prod with AVX10.2 
instructions

caused

FAIL: gcc.target/i386/vnniint16-auto-vectorize-3.c (test for excess errors)
FAIL: gcc.target/i386/vnniint8-auto-vectorize-3.c (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-3352/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/vnniint16-auto-vectorize-3.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/vnniint16-auto-vectorize-3.c 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/vnniint8-auto-vectorize-3.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/vnniint8-auto-vectorize-3.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.)


[r15-3356 Regression] FAIL: gcc.target/i386/avx10_2-bf-vector-fma-1.c (test for excess errors) on Linux/x86_64

2024-09-02 Thread haochen.jiang
On Linux/x86_64,

6d294fb8ac9baf2624446deaa4c995b7a7719823 is the first bad commit
commit 6d294fb8ac9baf2624446deaa4c995b7a7719823
Author: Levy Hsu 
Date:   Mon Sep 2 10:24:46 2024 +0800

i386: Support vectorized BF16 FMA with AVX10.2 instructions

caused

FAIL: gcc.target/i386/avx10_2-bf-vector-fma-1.c (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-3356/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/avx10_2-bf-vector-fma-1.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-bf-vector-fma-1.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.)


[committed][PR rtl-optimization/116544] Fix test for promoted subregs

2024-09-01 Thread Jeff Law

This is a small bug in the ext-dce code's handling of promoted subregs.

Essentially when we see a promoted subreg we need to make additional bit 
groups live as various parts of the RTL path know that an extension of a 
suitably promoted subreg can be trivially eliminated.


When I added support for dealing with this quirk I failed to account for 
the larger modes properly and it ignored the case when the size of the 
inner object was > 32 bits.  Opps.


This does _not_ fix the outstanding x86 issue.  That's caused by 
something completely different and more concerning ;(


Bootstrapped and regression tested on x86.  Obviously fixes the testcase 
on riscv as well.


Pushing to the trunk.

jeffcommit 0562976d62e095f3a00c799288dee4e5b20114e2
Author: Jeff Law 
Date:   Sun Sep 1 22:16:04 2024 -0600

[committed][PR rtl-optimization/116544] Fix test for promoted subregs

This is a small bug in the ext-dce code's handling of promoted subregs.

Essentially when we see a promoted subreg we need to make additional bit 
groups
live as various parts of the RTL path know that an extension of a suitably
promoted subreg can be trivially eliminated.

When I added support for dealing with this quirk I failed to account for the
larger modes properly and it ignored the case when the size of the inner 
object
was > 32 bits.  Opps.

This does _not_ fix the outstanding x86 issue.  That's caused by something
completely different and more concerning ;(

Bootstrapped and regression tested on x86.  Obviously fixes the testcase on
riscv as well.

Pushing to the trunk.

PR rtl-optimization/116544
gcc/
* ext-dce.cc (ext_dce_process_uses): Fix thinko in promoted subreg
handling.

gcc/testsuite/
* gcc.dg/torture/pr116544.c: New test.

diff --git a/gcc/ext-dce.cc b/gcc/ext-dce.cc
index 4a2503f1831..2f3514ae797 100644
--- a/gcc/ext-dce.cc
+++ b/gcc/ext-dce.cc
@@ -846,7 +846,7 @@ ext_dce_process_uses (rtx_insn *insn, rtx obj,
bitmap_set_bit (livenow, rn + 1);
  if (size > 16)
bitmap_set_bit (livenow, rn + 2);
- if (size == 32)
+ if (size >= 32)
bitmap_set_bit (livenow, rn + 3);
  iter.skip_subrtxes ();
}
diff --git a/gcc/testsuite/gcc.dg/torture/pr116544.c 
b/gcc/testsuite/gcc.dg/torture/pr116544.c
new file mode 100644
index 000..15f52fecb3b
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr116544.c
@@ -0,0 +1,22 @@
+/* { dg-options "-fno-strict-aliasing -fwrapv" }
+/* { dg-do run { target longlong64 } } */
+
+extern void abort (void);
+long long a;
+signed char b[60];
+signed char c;
+long long d[60];
+int e[30];
+long long *f = d;
+static void g(long long *j, long k) { *j = k; }
+int main() {
+  d[5] = 0x1;
+  for (int h = 2; h < 7; h += 3)
+for (int i = 0; i < (c || b[h]) + 10; i += 11)
+  e[2] = f[h];
+  g(&a, e[2]);
+  if (a != 0)
+abort ();
+  return 0;
+}
+


[pushed] testsuite, c++, coroutines: Correct a test intent.

2024-08-31 Thread Iain Sandoe
tested on x86_64-darwin/linux powerpc64le-linux, pushed to trunk,
thanks
Iain

--- 8< ---

The intention of the series of tests numberef pr95615-* is to
verify that entities created by the ramp and potentially needing
destruction are correctly handled when exceptions are thrown.
Because of a typo, one case was not being checked correctly (the
return object).  This patch amends the check to test that the
returned object is properly deleted.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/torture/pr95615.inc: Check tha the
task object produced by get_return_object is correctly
deleted on exception.

Signed-off-by: Iain Sandoe 
---
 .../g++.dg/coroutines/torture/pr95615.inc | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/gcc/testsuite/g++.dg/coroutines/torture/pr95615.inc 
b/gcc/testsuite/g++.dg/coroutines/torture/pr95615.inc
index 5fc22430e99..b6f78fb15b9 100644
--- a/gcc/testsuite/g++.dg/coroutines/torture/pr95615.inc
+++ b/gcc/testsuite/g++.dg/coroutines/torture/pr95615.inc
@@ -12,11 +12,11 @@ namespace std {
 
 bool frame_live = false;
 bool promise_live = false;
-bool gro_live = false;
 
 struct X {};
 
 int Y_live = 0;
+int task_live = 0;
 
 struct Y
 {
@@ -85,7 +85,6 @@ struct task {
 #if GET_RETURN_OBJECT_THROWS
 throw X{};
 #endif
-   bool gro_live = true;
 return task{};
 }
 
@@ -96,12 +95,12 @@ struct task {
 }
 };
 
-task() { std::puts("task()"); }
-~task() { std::puts("~task()"); }
-task(task&&) { std::puts("task(task&&)"); }
+task() { std::puts("task()");  task_live++; }
+~task() { std::puts("~task()"); task_live--; }
+task(task&&) { std::puts("task(task&&)"); task_live++;  }
 };
 
-task f(Y Val) {
+task f(Y Val __attribute__((__unused__))) {
 co_return;
 }
 
@@ -112,8 +111,8 @@ int main() {
 f(Val);
 } catch (X) {
 std::puts("caught X");
-if (gro_live)
-  std::puts("gro live"), failed = true;
+if (task_live)
+  std::puts("task live"), failed = true;
 if (promise_live)
   std::puts("promise live"), failed = true;
 if (frame_live)
-- 
2.39.2 (Apple Git-143)



[pushed] c++: add fixed test [PR101099]

2024-08-30 Thread Marek Polacek
Tested x86_64-pc-linux-gnu, applying to trunk.

-- >8 --
-fconcepts-ts is no longer supported so this can't be made to ICE
anymore.

PR c++/101099

gcc/testsuite/ChangeLog:

* g++.dg/concepts/pr101099.C: New test.
---
 gcc/testsuite/g++.dg/concepts/pr101099.C | 6 ++
 1 file changed, 6 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/concepts/pr101099.C

diff --git a/gcc/testsuite/g++.dg/concepts/pr101099.C 
b/gcc/testsuite/g++.dg/concepts/pr101099.C
new file mode 100644
index 000..82fd87c843b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/pr101099.C
@@ -0,0 +1,6 @@
+// PR c++/101099
+// { dg-do compile { target c++11 } }
+// { dg-options "-fconcepts" }
+
+#include 
+constexpr auto list = { 1, 2, 3 };

base-commit: ffd56dcc11e32033a1f3a964af584dc32321a125
-- 
2.46.0



[pushed] c++: add fixed test [PR115616]

2024-08-30 Thread Marek Polacek
Tested x86_64-pc-linux-gnu, applying to trunk.

-- >8 --
This got fixed by r15-2120.

PR c++/115616

gcc/testsuite/ChangeLog:

* g++.dg/template/friend83.C: New test.
---
 gcc/testsuite/g++.dg/template/friend83.C | 24 
 1 file changed, 24 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/template/friend83.C

diff --git a/gcc/testsuite/g++.dg/template/friend83.C 
b/gcc/testsuite/g++.dg/template/friend83.C
new file mode 100644
index 000..edd29614b31
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/friend83.C
@@ -0,0 +1,24 @@
+// PR c++/115616
+// { dg-do compile { target c++20 } }
+
+template  void bar() {}
+
+template 
+struct Reader
+{
+template 
+friend void foo(Reader);
+};
+
+template 
+struct Writer
+{
+template 
+friend void foo(Reader) {bar();}
+};
+
+int main()
+{
+foo<10>(Reader{});
+Writer{};
+}

base-commit: f93a38f3fc8b20942896d037f3833d6b383dd3d8
-- 
2.46.0



Re: [PATCH] libstdc++: Add missing feature-test macro in various headers

2024-08-29 Thread Jonathan Wakely
On Thu, 29 Aug 2024 at 09:12, Dhruv Chawla  wrote:
>
> On 28/08/24 15:40, Jonathan Wakely wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On Wed, 28 Aug 2024 at 06:47, Dhruv Chawla  wrote:
> >>
> >> version.syn#2 requires  to define
> >> __cpp_lib_allocator_traits_is_always_equal.
> >>
> >> The attached patch therefore defines the
> >> __glibcxx_want_allocator_traits_is_always_equal macro to get the
> >> definition of the feature-test macro from .
> >>
> >> This is not isolated only to  though. The standard requires the
> >> following (as per version.syn#2):
> >>
> >> #define __cpp_lib_allocator_traits_is_always_equal  201411L
> >> // freestanding, also in , , , 
> >> ,
> >> // , , , , , ,
> >> // 
> >>
> >> After fixing , all the above headers except  still fail to
> >> define the macro. Should similar fixes be created for these headers as 
> >> well?
> >
> > Yes please, this is a regression since GCC 13. It was previously
> > defined in  which is included by all the headers
> > above. In GCC 14 we changed how we define feature test macros, and we
> > accidentally stopped defining it in all those headers.
> >
>
> I have updated the headers now, please have a look.
>
> Bootstrapped and regtested on aarch64-linux-gnu.

Tests added for all headers, regtested successfully, DCO sign-off
present - this looks great, thanks.

I'll push it to trunk and gcc-14.


>
> >>
> >> Signed-off-by: Dhruv Chawla 
> >>
> >> --
> >> Regards,
> >> Dhruv
> >
>
> --
> Regards,
> Dhruv



[PATCH] libstdc++: Add missing feature-test macro in various headers

2024-08-29 Thread Dhruv Chawla

On 28/08/24 15:40, Jonathan Wakely wrote:

External email: Use caution opening links or attachments


On Wed, 28 Aug 2024 at 06:47, Dhruv Chawla  wrote:


version.syn#2 requires  to define
__cpp_lib_allocator_traits_is_always_equal.

The attached patch therefore defines the
__glibcxx_want_allocator_traits_is_always_equal macro to get the
definition of the feature-test macro from .

This is not isolated only to  though. The standard requires the
following (as per version.syn#2):

#define __cpp_lib_allocator_traits_is_always_equal  201411L
// freestanding, also in , , , ,
// , , , , , ,
// 

After fixing , all the above headers except  still fail to
define the macro. Should similar fixes be created for these headers as well?


Yes please, this is a regression since GCC 13. It was previously
defined in  which is included by all the headers
above. In GCC 14 we changed how we define feature test macros, and we
accidentally stopped defining it in all those headers.



I have updated the headers now, please have a look.

Bootstrapped and regtested on aarch64-linux-gnu.



Signed-off-by: Dhruv Chawla 

--
Regards,
Dhruv




--
Regards,
Dhruv
From 20ed439aab6532c0d8c66772df0341a4c8c7af4b Mon Sep 17 00:00:00 2001
From: Dhruv Chawla 
Date: Mon, 26 Aug 2024 11:09:19 +0530
Subject: [PATCH] libstdc++: Add missing feature-test macro in various headers

version.syn#2 requires various headers to define
__cpp_lib_allocator_traits_is_always_equal. Currently, only  was
defining this macro. Implement fixes for the other headers as well.

Signed-off-by: Dhruv Chawla 

libstdc++-v3/ChangeLog:

* include/std/deque: Define macro
__glibcxx_want_allocator_traits_is_always_equal.
* include/std/forward_list: Likewise.
* include/std/list: Likewise.
* include/std/map: Likewise.
* include/std/scoped_allocator: Likewise.
* include/std/set: Likewise.
* include/std/string: Likewise.
* include/std/unordered_map: Likewise.
* include/std/unordered_set: Likewise.
* include/std/vector: Likewise.
* testsuite/20_util/headers/memory/version.cc: New test.
* testsuite/20_util/scoped_allocator/version.cc: Likewise.
* testsuite/21_strings/headers/string/version.cc: Likewise.
* testsuite/23_containers/deque/version.cc: Likewise.
* testsuite/23_containers/forward_list/version.cc: Likewise.
* testsuite/23_containers/list/version.cc: Likewise.
* testsuite/23_containers/map/version.cc: Likewise.
* testsuite/23_containers/set/version.cc: Likewise.
* testsuite/23_containers/unordered_map/version.cc: Likewise.
* testsuite/23_containers/unordered_set/version.cc: Likewise.
* testsuite/23_containers/vector/version.cc: Likewise.
---
 libstdc++-v3/include/std/deque| 1 +
 libstdc++-v3/include/std/forward_list | 1 +
 libstdc++-v3/include/std/list | 1 +
 libstdc++-v3/include/std/map  | 1 +
 libstdc++-v3/include/std/scoped_allocator | 3 +++
 libstdc++-v3/include/std/set  | 1 +
 libstdc++-v3/include/std/string   | 1 +
 libstdc++-v3/include/std/unordered_map| 1 +
 libstdc++-v3/include/std/unordered_set| 1 +
 libstdc++-v3/include/std/vector   | 1 +
 libstdc++-v3/testsuite/20_util/headers/memory/version.cc  | 8 
 .../testsuite/20_util/scoped_allocator/version.cc | 8 
 .../testsuite/21_strings/headers/string/version.cc| 8 
 libstdc++-v3/testsuite/23_containers/deque/version.cc | 8 
 .../testsuite/23_containers/forward_list/version.cc   | 8 
 libstdc++-v3/testsuite/23_containers/list/version.cc  | 8 
 libstdc++-v3/testsuite/23_containers/map/version.cc   | 8 
 libstdc++-v3/testsuite/23_containers/set/version.cc   | 8 
 .../testsuite/23_containers/unordered_map/version.cc  | 8 
 .../testsuite/23_containers/unordered_set/version.cc  | 8 
 libstdc++-v3/testsuite/23_containers/vector/version.cc| 8 
 21 files changed, 100 insertions(+)
 create mode 100644 libstdc++-v3/testsuite/20_util/headers/memory/version.cc
 create mode 100644 libstdc++-v3/testsuite/20_util/scoped_allocator/version.cc
 create mode 100644 libstdc++-v3/testsuite/21_strings/headers/string/version.cc
 create mode 100644 libstdc++-v3/testsuite/23_containers/deque/version.cc
 create mode 100644 libstdc++-v3/testsuite/23_containers/forward_list/version.cc
 create mode 100644 libstdc++-v3/testsuite/23_containers/list/version.cc
 create mode 100644 libstdc++-v3/testsuite/23_containers/map/version.cc
 create mode 100644 libstdc++-v3/testsuite/23_containers/set/version.cc
 create mode 100644 
libstdc++-v3/testsuite/23_containers/unordered_map/version.cc
 create mode

[pushed] aarch64: Add a test for zeroing <64bits>x2_t structures

2024-08-28 Thread Richard Sandiford
g:8d6c6fbc5271dde433998c09407b30e2cf195420 improved the code
generated for functions like:

  void test_s8 (int8x8x2_t *ptr) { *ptr = (int8x8x2_t) {}; }

Previously we would load zero from the constant pool, whereas
now we just use "stp xzr, xzr".  This patch adds a test for
this improvement.

Tested on aarch64-linux-gnu & pushed.

Richard


gcc/testsuite/
* gcc.target/aarch64/struct_zero.c: New test.
---
 .../gcc.target/aarch64/struct_zero.c  | 21 +++
 1 file changed, 21 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/struct_zero.c

diff --git a/gcc/testsuite/gcc.target/aarch64/struct_zero.c 
b/gcc/testsuite/gcc.target/aarch64/struct_zero.c
new file mode 100644
index 000..13f7236a4d2
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/struct_zero.c
@@ -0,0 +1,21 @@
+/* { dg-options "-O2" } */
+
+#include 
+
+void test_s8 (int8x8x2_t *ptr) { *ptr = (int8x8x2_t) {}; }
+void test_u8 (uint8x8x2_t *ptr) { *ptr = (uint8x8x2_t) {}; }
+void test_p8 (poly8x8x2_t *ptr) { *ptr = (poly8x8x2_t) {}; }
+void test_s16 (int16x4x2_t *ptr) { *ptr = (int16x4x2_t) {}; }
+void test_u16 (uint16x4x2_t *ptr) { *ptr = (uint16x4x2_t) {}; }
+void test_p16 (poly16x4x2_t *ptr) { *ptr = (poly16x4x2_t) {}; }
+void test_bf16 (bfloat16x4x2_t *ptr) { *ptr = (bfloat16x4x2_t) {}; }
+void test_f16 (float16x4x2_t *ptr) { *ptr = (float16x4x2_t) {}; }
+void test_s32 (int32x2x2_t *ptr) { *ptr = (int32x2x2_t) {}; }
+void test_u32 (uint32x2x2_t *ptr) { *ptr = (uint32x2x2_t) {}; }
+void test_f32 (float32x2x2_t *ptr) { *ptr = (float32x2x2_t) {}; }
+void test_s64 (int64x1x2_t *ptr) { *ptr = (int64x1x2_t) {}; }
+void test_u64 (uint64x1x2_t *ptr) { *ptr = (uint64x1x2_t) {}; }
+void test_p64 (poly64x1x2_t *ptr) { *ptr = (poly64x1x2_t) {}; }
+void test_f64 (float64x1x2_t *ptr) { *ptr = (float64x1x2_t) {}; }
+
+/* { dg-final { scan-assembler-times {\tstp\txzr, xzr, \[x0\]\n} 15 } } */
-- 
2.25.1



Re: [PATCH] libstdc++: Add missing feature-test macro in

2024-08-28 Thread Jonathan Wakely
On Wed, 28 Aug 2024 at 06:47, Dhruv Chawla  wrote:
>
> version.syn#2 requires  to define
> __cpp_lib_allocator_traits_is_always_equal.
>
> The attached patch therefore defines the
> __glibcxx_want_allocator_traits_is_always_equal macro to get the
> definition of the feature-test macro from .
>
> This is not isolated only to  though. The standard requires the
> following (as per version.syn#2):
>
> #define __cpp_lib_allocator_traits_is_always_equal  201411L
>// freestanding, also in , , , ,
>// , , , , , ,
>// 
>
> After fixing , all the above headers except  still fail to
> define the macro. Should similar fixes be created for these headers as well?

Yes please, this is a regression since GCC 13. It was previously
defined in  which is included by all the headers
above. In GCC 14 we changed how we define feature test macros, and we
accidentally stopped defining it in all those headers.

>
> Signed-off-by: Dhruv Chawla 
>
> --
> Regards,
> Dhruv



RE: [PATCH v2] Test: Move pr116278 run test to dg/torture [NFC]

2024-08-28 Thread Li, Pan2
Noted with thanks, will commit with that change if no surprise from test.

Pan

-Original Message-
From: Richard Biener  
Sent: Wednesday, August 28, 2024 3:24 PM
To: Li, Pan2 
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@gmail.com; 
jeffreya...@gmail.com; rdapp@gmail.com
Subject: Re: [PATCH v2] Test: Move pr116278 run test to dg/torture [NFC]

On Wed, Aug 28, 2024 at 3:18 AM Li, Pan2  wrote:
>
> Kindly ping.

Please do not include stdint-gcc.h but stdint.h.

otherwise OK.

Richard.

> Pan
>
> -Original Message-
> From: Li, Pan2 
> Sent: Monday, August 19, 2024 10:05 AM
> To: gcc-patches@gcc.gnu.org
> Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; jeffreya...@gmail.com; 
> rdapp@gmail.com; Li, Pan2 
> Subject: [PATCH v2] Test: Move pr116278 run test to dg/torture [NFC]
>
> From: Pan Li 
>
> Move the run test of pr116278 to dg/torture and leave the risc-v the
> asm check under risc-v part.
>
> PR target/116278
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/pr116278-run-1.c: Take compile instead of run.
> * gcc.target/riscv/pr116278-run-2.c: Ditto.
> * gcc.dg/torture/pr116278-run-1.c: New test.
> * gcc.dg/torture/pr116278-run-2.c: New test.
>
> Signed-off-by: Pan Li 
> ---
>  gcc/testsuite/gcc.dg/torture/pr116278-run-1.c | 19 +++
>  gcc/testsuite/gcc.dg/torture/pr116278-run-2.c | 19 +++
>  .../gcc.target/riscv/pr116278-run-1.c |  2 +-
>  .../gcc.target/riscv/pr116278-run-2.c |  2 +-
>  4 files changed, 40 insertions(+), 2 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/torture/pr116278-run-1.c
>  create mode 100644 gcc/testsuite/gcc.dg/torture/pr116278-run-2.c
>
> diff --git a/gcc/testsuite/gcc.dg/torture/pr116278-run-1.c 
> b/gcc/testsuite/gcc.dg/torture/pr116278-run-1.c
> new file mode 100644
> index 000..8e07fb6af29
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/torture/pr116278-run-1.c
> @@ -0,0 +1,19 @@
> +/* { dg-do run } */
> +/* { dg-require-effective-target int32 } */
> +/* { dg-options "-O2" } */
> +
> +#include 
> +
> +int8_t b[1];
> +int8_t *d = b;
> +int32_t c;
> +
> +int main() {
> +  b[0] = -40;
> +  uint16_t t = (uint16_t)d[0];
> +
> +  c = (t < 0xFFF6 ? t : 0xFFF6) + 9;
> +
> +  if (c != 65505)
> +__builtin_abort ();
> +}
> diff --git a/gcc/testsuite/gcc.dg/torture/pr116278-run-2.c 
> b/gcc/testsuite/gcc.dg/torture/pr116278-run-2.c
> new file mode 100644
> index 000..d85e21531e1
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/torture/pr116278-run-2.c
> @@ -0,0 +1,19 @@
> +/* { dg-do run } */
> +/* { dg-require-effective-target int32 } */
> +/* { dg-options "-O2" } */
> +
> +#include 
> +
> +int16_t b[1];
> +int16_t *d = b;
> +int64_t c;
> +
> +int main() {
> +  b[0] = -40;
> +  uint32_t t = (uint32_t)d[0];
> +
> +  c = (t < 0xFFF6u ? t : 0xFFF6u) + 9;
> +
> +  if (c != 4294967265)
> +__builtin_abort ();
> +}
> diff --git a/gcc/testsuite/gcc.target/riscv/pr116278-run-1.c 
> b/gcc/testsuite/gcc.target/riscv/pr116278-run-1.c
> index d3812bdcdfb..c758fca7975 100644
> --- a/gcc/testsuite/gcc.target/riscv/pr116278-run-1.c
> +++ b/gcc/testsuite/gcc.target/riscv/pr116278-run-1.c
> @@ -1,4 +1,4 @@
> -/* { dg-do run { target { riscv_v } } } */
> +/* { dg-do compile } */
>  /* { dg-options "-O2 -fdump-rtl-expand-details" } */
>
>  #include 
> diff --git a/gcc/testsuite/gcc.target/riscv/pr116278-run-2.c 
> b/gcc/testsuite/gcc.target/riscv/pr116278-run-2.c
> index 669cd4f003f..a4da8a323f0 100644
> --- a/gcc/testsuite/gcc.target/riscv/pr116278-run-2.c
> +++ b/gcc/testsuite/gcc.target/riscv/pr116278-run-2.c
> @@ -1,4 +1,4 @@
> -/* { dg-do run { target { riscv_v } } } */
> +/* { dg-do compile } */
>  /* { dg-options "-O2 -fdump-rtl-expand-details" } */
>
>  #include 
> --
> 2.43.0
>


Re: [PATCH v2] Test: Move pr116278 run test to dg/torture [NFC]

2024-08-28 Thread Richard Biener
On Wed, Aug 28, 2024 at 3:18 AM Li, Pan2  wrote:
>
> Kindly ping.

Please do not include stdint-gcc.h but stdint.h.

otherwise OK.

Richard.

> Pan
>
> -Original Message-
> From: Li, Pan2 
> Sent: Monday, August 19, 2024 10:05 AM
> To: gcc-patches@gcc.gnu.org
> Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; jeffreya...@gmail.com; 
> rdapp@gmail.com; Li, Pan2 
> Subject: [PATCH v2] Test: Move pr116278 run test to dg/torture [NFC]
>
> From: Pan Li 
>
> Move the run test of pr116278 to dg/torture and leave the risc-v the
> asm check under risc-v part.
>
> PR target/116278
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/pr116278-run-1.c: Take compile instead of run.
> * gcc.target/riscv/pr116278-run-2.c: Ditto.
> * gcc.dg/torture/pr116278-run-1.c: New test.
> * gcc.dg/torture/pr116278-run-2.c: New test.
>
> Signed-off-by: Pan Li 
> ---
>  gcc/testsuite/gcc.dg/torture/pr116278-run-1.c | 19 +++
>  gcc/testsuite/gcc.dg/torture/pr116278-run-2.c | 19 +++
>  .../gcc.target/riscv/pr116278-run-1.c |  2 +-
>  .../gcc.target/riscv/pr116278-run-2.c |  2 +-
>  4 files changed, 40 insertions(+), 2 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/torture/pr116278-run-1.c
>  create mode 100644 gcc/testsuite/gcc.dg/torture/pr116278-run-2.c
>
> diff --git a/gcc/testsuite/gcc.dg/torture/pr116278-run-1.c 
> b/gcc/testsuite/gcc.dg/torture/pr116278-run-1.c
> new file mode 100644
> index 000..8e07fb6af29
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/torture/pr116278-run-1.c
> @@ -0,0 +1,19 @@
> +/* { dg-do run } */
> +/* { dg-require-effective-target int32 } */
> +/* { dg-options "-O2" } */
> +
> +#include 
> +
> +int8_t b[1];
> +int8_t *d = b;
> +int32_t c;
> +
> +int main() {
> +  b[0] = -40;
> +  uint16_t t = (uint16_t)d[0];
> +
> +  c = (t < 0xFFF6 ? t : 0xFFF6) + 9;
> +
> +  if (c != 65505)
> +__builtin_abort ();
> +}
> diff --git a/gcc/testsuite/gcc.dg/torture/pr116278-run-2.c 
> b/gcc/testsuite/gcc.dg/torture/pr116278-run-2.c
> new file mode 100644
> index 000..d85e21531e1
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/torture/pr116278-run-2.c
> @@ -0,0 +1,19 @@
> +/* { dg-do run } */
> +/* { dg-require-effective-target int32 } */
> +/* { dg-options "-O2" } */
> +
> +#include 
> +
> +int16_t b[1];
> +int16_t *d = b;
> +int64_t c;
> +
> +int main() {
> +  b[0] = -40;
> +  uint32_t t = (uint32_t)d[0];
> +
> +  c = (t < 0xFFF6u ? t : 0xFFF6u) + 9;
> +
> +  if (c != 4294967265)
> +__builtin_abort ();
> +}
> diff --git a/gcc/testsuite/gcc.target/riscv/pr116278-run-1.c 
> b/gcc/testsuite/gcc.target/riscv/pr116278-run-1.c
> index d3812bdcdfb..c758fca7975 100644
> --- a/gcc/testsuite/gcc.target/riscv/pr116278-run-1.c
> +++ b/gcc/testsuite/gcc.target/riscv/pr116278-run-1.c
> @@ -1,4 +1,4 @@
> -/* { dg-do run { target { riscv_v } } } */
> +/* { dg-do compile } */
>  /* { dg-options "-O2 -fdump-rtl-expand-details" } */
>
>  #include 
> diff --git a/gcc/testsuite/gcc.target/riscv/pr116278-run-2.c 
> b/gcc/testsuite/gcc.target/riscv/pr116278-run-2.c
> index 669cd4f003f..a4da8a323f0 100644
> --- a/gcc/testsuite/gcc.target/riscv/pr116278-run-2.c
> +++ b/gcc/testsuite/gcc.target/riscv/pr116278-run-2.c
> @@ -1,4 +1,4 @@
> -/* { dg-do run { target { riscv_v } } } */
> +/* { dg-do compile } */
>  /* { dg-options "-O2 -fdump-rtl-expand-details" } */
>
>  #include 
> --
> 2.43.0
>


[PATCH] libstdc++: Add missing feature-test macro in

2024-08-27 Thread Dhruv Chawla

version.syn#2 requires  to define
__cpp_lib_allocator_traits_is_always_equal.

The attached patch therefore defines the
__glibcxx_want_allocator_traits_is_always_equal macro to get the
definition of the feature-test macro from .

This is not isolated only to  though. The standard requires the
following (as per version.syn#2):

#define __cpp_lib_allocator_traits_is_always_equal  201411L
  // freestanding, also in , , , ,
  // , , , , , ,
  // 

After fixing , all the above headers except  still fail to
define the macro. Should similar fixes be created for these headers as well?

Signed-off-by: Dhruv Chawla 

--
Regards,
Dhruv
From 40c0b154f2ef11a18fd318008ae366560d4c8d79 Mon Sep 17 00:00:00 2001
From: Dhruv Chawla 
Date: Mon, 26 Aug 2024 11:09:19 +0530
Subject: [PATCH] libstdc++: Add missing feature-test macro in 

version.syn#2 requires  to define
__cpp_lib_allocator_traits_is_always_equal.

The attached patch therefore defines the
__glibcxx_want_allocator_traits_is_always_equal macro to get the
definition of the feature-test macro from .

This is not isolated only to  though. The standard requires the
following (as per version.syn#2):

#define __cpp_lib_allocator_traits_is_always_equal  201411L
  // freestanding, also in , , , ,
  // , , , , , ,
  // 

After fixing , all the above headers except  still fail to
define the macro. Should similar fixes be created for these headers as well?

Signed-off-by: Dhruv Chawla 

libstdc++-v3/ChangeLog:

* include/std/string: Define macro
__glibcxx_want_allocator_traits_is_always_equal.
---
 libstdc++-v3/include/std/string   | 1 +
 .../testsuite/21_strings/headers/string/version.cc| 8 
 2 files changed, 9 insertions(+)
 create mode 100644 libstdc++-v3/testsuite/21_strings/headers/string/version.cc

diff --git a/libstdc++-v3/include/std/string b/libstdc++-v3/include/std/string
index 55144409cca..8db0802a282 100644
--- a/libstdc++-v3/include/std/string
+++ b/libstdc++-v3/include/std/string
@@ -54,6 +54,7 @@
 #include 
 #include 
 
+#define __glibcxx_want_allocator_traits_is_always_equal
 #define __glibcxx_want_constexpr_char_traits
 #define __glibcxx_want_constexpr_string
 #define __glibcxx_want_erase_if
diff --git a/libstdc++-v3/testsuite/21_strings/headers/string/version.cc 
b/libstdc++-v3/testsuite/21_strings/headers/string/version.cc
new file mode 100644
index 000..a546b75b3fe
--- /dev/null
+++ b/libstdc++-v3/testsuite/21_strings/headers/string/version.cc
@@ -0,0 +1,8 @@
+// { dg-do preprocess { target c++17 } }
+// { dg-add-options no_pch }
+
+#include 
+
+#if __cpp_lib_allocator_traits_is_always_equal != 201411L
+# error "Feature-test macro __cpp_lib_allocator_traits_is_always_equal has 
wrong value in "
+#endif
-- 
2.25.1



RE: [PATCH v2] Test: Move pr116278 run test to dg/torture [NFC]

2024-08-27 Thread Li, Pan2
Kindly ping.

Pan

-Original Message-
From: Li, Pan2  
Sent: Monday, August 19, 2024 10:05 AM
To: gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; jeffreya...@gmail.com; 
rdapp@gmail.com; Li, Pan2 
Subject: [PATCH v2] Test: Move pr116278 run test to dg/torture [NFC]

From: Pan Li 

Move the run test of pr116278 to dg/torture and leave the risc-v the
asm check under risc-v part.

PR target/116278

gcc/testsuite/ChangeLog:

* gcc.target/riscv/pr116278-run-1.c: Take compile instead of run.
* gcc.target/riscv/pr116278-run-2.c: Ditto.
* gcc.dg/torture/pr116278-run-1.c: New test.
* gcc.dg/torture/pr116278-run-2.c: New test.

Signed-off-by: Pan Li 
---
 gcc/testsuite/gcc.dg/torture/pr116278-run-1.c | 19 +++
 gcc/testsuite/gcc.dg/torture/pr116278-run-2.c | 19 +++
 .../gcc.target/riscv/pr116278-run-1.c |  2 +-
 .../gcc.target/riscv/pr116278-run-2.c |  2 +-
 4 files changed, 40 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr116278-run-1.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr116278-run-2.c

diff --git a/gcc/testsuite/gcc.dg/torture/pr116278-run-1.c 
b/gcc/testsuite/gcc.dg/torture/pr116278-run-1.c
new file mode 100644
index 000..8e07fb6af29
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr116278-run-1.c
@@ -0,0 +1,19 @@
+/* { dg-do run } */
+/* { dg-require-effective-target int32 } */
+/* { dg-options "-O2" } */
+
+#include 
+
+int8_t b[1];
+int8_t *d = b;
+int32_t c;
+
+int main() {
+  b[0] = -40;
+  uint16_t t = (uint16_t)d[0];
+
+  c = (t < 0xFFF6 ? t : 0xFFF6) + 9;
+
+  if (c != 65505)
+__builtin_abort ();
+}
diff --git a/gcc/testsuite/gcc.dg/torture/pr116278-run-2.c 
b/gcc/testsuite/gcc.dg/torture/pr116278-run-2.c
new file mode 100644
index 000..d85e21531e1
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr116278-run-2.c
@@ -0,0 +1,19 @@
+/* { dg-do run } */
+/* { dg-require-effective-target int32 } */
+/* { dg-options "-O2" } */
+
+#include 
+
+int16_t b[1];
+int16_t *d = b;
+int64_t c;
+
+int main() {
+  b[0] = -40;
+  uint32_t t = (uint32_t)d[0];
+
+  c = (t < 0xFFF6u ? t : 0xFFF6u) + 9;
+
+  if (c != 4294967265)
+__builtin_abort ();
+}
diff --git a/gcc/testsuite/gcc.target/riscv/pr116278-run-1.c 
b/gcc/testsuite/gcc.target/riscv/pr116278-run-1.c
index d3812bdcdfb..c758fca7975 100644
--- a/gcc/testsuite/gcc.target/riscv/pr116278-run-1.c
+++ b/gcc/testsuite/gcc.target/riscv/pr116278-run-1.c
@@ -1,4 +1,4 @@
-/* { dg-do run { target { riscv_v } } } */
+/* { dg-do compile } */
 /* { dg-options "-O2 -fdump-rtl-expand-details" } */
 
 #include 
diff --git a/gcc/testsuite/gcc.target/riscv/pr116278-run-2.c 
b/gcc/testsuite/gcc.target/riscv/pr116278-run-2.c
index 669cd4f003f..a4da8a323f0 100644
--- a/gcc/testsuite/gcc.target/riscv/pr116278-run-2.c
+++ b/gcc/testsuite/gcc.target/riscv/pr116278-run-2.c
@@ -1,4 +1,4 @@
-/* { dg-do run { target { riscv_v } } } */
+/* { dg-do compile } */
 /* { dg-options "-O2 -fdump-rtl-expand-details" } */
 
 #include 
-- 
2.43.0



[PATCH] Fix test failing on sparc

2024-08-27 Thread Andi Kleen
From: Andi Kleen 

SPARC does not support vectorizing conditions, which this test relies
on. Use vect_condition as effective target.

Committed as obvious.

PR testsuite/116500

gcc/testsuite/ChangeLog:

* gcc.dg/vect/vect-switch-ifcvt-1.c: Use vect_condition to
check if vectorizing conditions is supported for target.
---
 gcc/testsuite/gcc.dg/vect/vect-switch-ifcvt-1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/vect/vect-switch-ifcvt-1.c 
b/gcc/testsuite/gcc.dg/vect/vect-switch-ifcvt-1.c
index f5352ef8ed7a..2e3a9ae3c249 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-switch-ifcvt-1.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-switch-ifcvt-1.c
@@ -1,4 +1,4 @@
-/* { dg-require-effective-target vect_int } */
+/* { dg-require-effective-target vect_condition } */
 #include "tree-vect.h"
 
 extern void abort (void);
-- 
2.45.2



Re: [PATCH] testsuite: Avoid running neon test on Cortex-M55

2024-08-27 Thread Richard Earnshaw (lists)
On 13/08/2024 17:18, Andre Vieira (lists) wrote:
> I'm not a maintainer but I'd argue the entire test is bogus.
> 
> The error reporting in this area seems to be somewhat fragile, if you compile 
> it with '-march=armv7-a -mfloat-abi=soft', you also don't get the error this 
> is testing for.  I'd argue this kind of user friendly error message should 
> just go through the #include  and if a user is using __builtin's 
> directly like this then they better know what they are doing and so 'useful' 
> errors are probably less of a priority.
> 
> In case you are wondering: no we don't offer nice errors when '#include 
> ' is compiled with a MVE enabled combination of march/mcpu, but 
> the errors are somewhat friendlier if you compile a '#include ' 
> with a NEON enabled command line.
> 
> Anyway, lets see what Richard says.

I'm inclined to agree.  Unfortunately, we have quite a few suspicious tests: 
it's the downside of a convention that all patches should be accompanied by 
tests - if the tests aren't up to much then often cause more problems than they 
are worth.  I'd be happy for this one to go.

If you really think it ought to be kept for some reason, then the 
dg-add-options directive should be updated to match the require effective 
target (ie 'arm_neon').

R.

> 
> On 13/08/2024 12:15, Torbjörn SVENSSON wrote:
>> Ok for trunk and releases/gcc-14?
>>
>> -- 
>>
>> Cortex-M55 supports VFP, but does not contain neon, so the test is
>> invalid in this context.
>>
>> Without this patch, the following error can be seen in the logs:
>>
>> .../attr-neon-builtin-fail2.c: In function 'foo':
>> .../attr-neon-builtin-fail2.c:13:27: error: implicit declaration of function 
>> '__builtin_neon_vaddlsv8qi'; did you mean '__builtin_neon_vabshf'? 
>> [-Wimplicit-function-declaration]
>> .../attr-neon-builtin-fail2.c:13:3: error: cannot convert a value of type 
>> 'int' to vector type '__simd128_int16_t' which has different size
>>
>> gcc/testsuite/ChangeLog:
>>
>> * attr-neon-builtin-fail2.c: Check ET neon.
>>
>> Signed-off-by: Torbjörn SVENSSON 
>> Co-authored-by: Yvan ROUX 
>> ---
>>   gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail2.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail2.c 
>> b/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail2.c
>> index 9cb5a2ebb90..8942b0d68f1 100644
>> --- a/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail2.c
>> +++ b/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail2.c
>> @@ -1,6 +1,7 @@
>>   /* Check that calling a neon builtin from a function compiled with vfp 
>> fails.  */
>>   /* { dg-do compile } */
>>   /* { dg-require-effective-target arm_vfp_ok } */
>> +/* { dg-require-effective-target arm_neon_ok } */
>>   /* { dg-options "-O2" } */
>>   /* { dg-add-options arm_vfp } */
>>   



[pushed] [PATCH] testsuite: Fix ending of comment in test cases

2024-08-27 Thread Torbjörn SVENSSON
Found a few more places that had similar issue with the termination of the 
comment, so fixed them all.

Pushed below patch as obvious (r15-3215).

--


gcc/testsuite/ChangeLog:

* gcc.dg/pr108757-1.c: Fixed dg-comment.
* gcc.dg/pr71071.c: Likewise.
* gcc.dg/tree-ssa/noreturn-1.c: Likewise.
* gcc.dg/tree-ssa/pr56727.c: Likewise.
* gcc.target/arc/loop-2.cpp: Likewise.
* gcc.target/arc/loop-3.c: Likewise.
* gcc.target/arc/pr9001107555.c: Likewise.
* gcc.target/arm/armv8_1m-fp16-move-1.c: Likewise.
* gcc.target/arm/armv8_1m-fp32-move-1.c: Likewise.
* gcc.target/arm/armv8_1m-fp64-move-1.c: Likewise.
* gcc.target/i386/amxint8-asmatt-1.c: Likewise.
* gcc.target/i386/amxint8-asmintel-1.c: Likewise.
* gcc.target/i386/avx512bw-vpermt2w-1.c: Likewise.
* gcc.target/i386/avx512vbmi-vpermt2b-1.c: Likewise.
* gcc.target/i386/endbr_immediate.c: Likewise.
* gcc.target/i386/pr96539.c: Likewise.
* gcc.target/i386/sse2-pr98461-2.c: Likewise.
* gcc.target/m68k/pr39726.c: Likewise.
* gcc.target/m68k/pr52076-1.c: Likewise.
* gcc.target/m68k/pr52076-2.c: Likewise.
* gcc.target/nvptx/v2si-vec-set-extract.c: Likewise.

Signed-off-by: Torbjörn SVENSSON 
---
 gcc/testsuite/gcc.dg/pr108757-1.c | 2 +-
 gcc/testsuite/gcc.dg/pr71071.c| 2 +-
 gcc/testsuite/gcc.dg/tree-ssa/noreturn-1.c| 2 +-
 gcc/testsuite/gcc.dg/tree-ssa/pr56727.c   | 2 +-
 gcc/testsuite/gcc.target/arc/loop-2.cpp   | 2 +-
 gcc/testsuite/gcc.target/arc/loop-3.c | 2 +-
 gcc/testsuite/gcc.target/arc/pr9001107555.c   | 2 +-
 gcc/testsuite/gcc.target/arm/armv8_1m-fp16-move-1.c   | 2 +-
 gcc/testsuite/gcc.target/arm/armv8_1m-fp32-move-1.c   | 2 +-
 gcc/testsuite/gcc.target/arm/armv8_1m-fp64-move-1.c   | 2 +-
 gcc/testsuite/gcc.target/i386/amxint8-asmatt-1.c  | 2 +-
 gcc/testsuite/gcc.target/i386/amxint8-asmintel-1.c| 2 +-
 gcc/testsuite/gcc.target/i386/avx512bw-vpermt2w-1.c   | 2 +-
 gcc/testsuite/gcc.target/i386/avx512vbmi-vpermt2b-1.c | 2 +-
 gcc/testsuite/gcc.target/i386/endbr_immediate.c   | 2 +-
 gcc/testsuite/gcc.target/i386/pr96539.c   | 2 +-
 gcc/testsuite/gcc.target/i386/sse2-pr98461-2.c| 2 +-
 gcc/testsuite/gcc.target/m68k/pr39726.c   | 2 +-
 gcc/testsuite/gcc.target/m68k/pr52076-1.c | 2 +-
 gcc/testsuite/gcc.target/m68k/pr52076-2.c | 2 +-
 gcc/testsuite/gcc.target/nvptx/v2si-vec-set-extract.c | 2 +-
 21 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/pr108757-1.c 
b/gcc/testsuite/gcc.dg/pr108757-1.c
index 7908f4bdcb8..712dc4c30e9 100644
--- a/gcc/testsuite/gcc.dg/pr108757-1.c
+++ b/gcc/testsuite/gcc.dg/pr108757-1.c
@@ -13,6 +13,6 @@ typedef int INT;
 #define IMIN INT_MIN
 #include "pr108757.h"
 
-/* { dg-final { scan-tree-dump-not " = x_\[0-9\]+\\(D\\) \\+ " "optimized" } } 
*
+/* { dg-final { scan-tree-dump-not " = x_\[0-9\]+\\(D\\) \\+ " "optimized" } } 
*/
 /* { dg-final { scan-tree-dump-not " = x_\[0-9\]+\\(D\\) \\- " "optimized" } } 
*/
 /* { dg-final { scan-tree-dump-not " = b_\[0-9\]+ \\+ " "optimized" } } */
diff --git a/gcc/testsuite/gcc.dg/pr71071.c b/gcc/testsuite/gcc.dg/pr71071.c
index 582f1f15a43..3e83dc9f1b7 100644
--- a/gcc/testsuite/gcc.dg/pr71071.c
+++ b/gcc/testsuite/gcc.dg/pr71071.c
@@ -1,5 +1,5 @@
 /* PR bootstrap/71071 */
-/* { dg-do compile } *
+/* { dg-do compile } */
 /* { dg-options "-O2" } */
 
 struct S { unsigned b : 1; } a;
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/noreturn-1.c 
b/gcc/testsuite/gcc.dg/tree-ssa/noreturn-1.c
index ae7ee42fabc..35f3d980217 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/noreturn-1.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/noreturn-1.c
@@ -1,4 +1,4 @@
-/* { dg-do compile } *
+/* { dg-do compile } */
 /* { dg-options "-O2 -fdump-tree-ssa -std=gnu11" } */
 /* { dg-final { scan-tree-dump-times "__builtin_unreachable" 4 "ssa" } } */
 
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr56727.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr56727.c
index 3080ce183b8..da2c9ab31f2 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr56727.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr56727.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target fpic } } *
+/* { dg-do compile { target fpic } } */
 /* { dg-require-alias "" } */
 /* { dg-options "-O2 -fPIC -fdump-tree-optimized" } */
 void do_not_optimize(int b)
diff --git a/gcc/testsuite/gcc.target/arc/loop-2.cpp 
b/gcc/testsuite/gcc.target/arc/loop-2.cpp
index d1dc917ba47..9cfb3274e21 100644
--- a/gcc/testsuite/gcc.target/arc/loop-2.cpp
+++ b/gcc/testsuite/gcc.target/arc/loop-2.cpp
@@ -1,4 +1,4 @@
-/* { dg-options "-O2" } *
+/* { dg-options "-O2" } */
 /* { dg-do assemble } */
 
 /* This file fails to assemble if we forgot to increase the number of
diff --git a/gcc/testsuite/gcc.target/arc/loop-3.c 
b/gcc/testsuite/gcc.target/arc/loop-3.c
index a

Re: [PATCH] Fix another inline7.c test failure on sparc targets

2024-08-26 Thread Richard Biener



> Am 27.08.2024 um 06:12 schrieb Bernd Edlinger :
> 
> This new test was reported to be still failing on sparc targets.
> Here the number of DW_AT_ranges dropped to zero.
> The test should pass on this architecture with -Os, -O2 and -O3.
> I tried to improve also different known problematic targets,
> where only one subroutine had DW_AT_ranges:
> Those are armhf (arm with hard float), powerpc and powerpc64.
> The best option is to use -Os: So far the only one, where
> all two inline instances in this test had two DW_AT_ranges.

Ok

Richard 

> gcc/testsuite/ChangeLog:
> 
>PR other/116462
>* gcc.dg/debug/dwarf2/inline7.c: Switch to -Os optimization.
> ---
> Hopefully this will be the final act, OK for trunk?
> 
> gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c 
> b/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c
> index 083df5b586c..8b2fa1210ad 100644
> --- a/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c
> +++ b/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c
> @@ -1,6 +1,6 @@
> /* Verify that at least one of both inline instances have
>a DW_AT_ranges but no extra DW_TAG_lexical_block.  */
> -/* { dg-options "-O -gdwarf -dA" } */
> +/* { dg-options "-Os -gdwarf -dA" } */
> /* { dg-do compile } */
> /* { dg-final { scan-assembler-times "\\(DIE \\(\[^\n\]*\\) 
> DW_TAG_inlined_subroutine" 2 } } */
> /* { dg-final { scan-assembler " DW_AT_ranges" } } */
> --
> 2.39.2
> 


[PATCH] Fix another inline7.c test failure on sparc targets

2024-08-26 Thread Bernd Edlinger
This new test was reported to be still failing on sparc targets.
Here the number of DW_AT_ranges dropped to zero.
The test should pass on this architecture with -Os, -O2 and -O3.
I tried to improve also different known problematic targets,
where only one subroutine had DW_AT_ranges:
Those are armhf (arm with hard float), powerpc and powerpc64.
The best option is to use -Os: So far the only one, where
all two inline instances in this test had two DW_AT_ranges.

gcc/testsuite/ChangeLog:

PR other/116462
* gcc.dg/debug/dwarf2/inline7.c: Switch to -Os optimization.
---
Hopefully this will be the final act, OK for trunk?

 gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c 
b/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c
index 083df5b586c..8b2fa1210ad 100644
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c
@@ -1,6 +1,6 @@
 /* Verify that at least one of both inline instances have
a DW_AT_ranges but no extra DW_TAG_lexical_block.  */
-/* { dg-options "-O -gdwarf -dA" } */
+/* { dg-options "-Os -gdwarf -dA" } */
 /* { dg-do compile } */
 /* { dg-final { scan-assembler-times "\\(DIE \\(\[^\n\]*\\) 
DW_TAG_inlined_subroutine" 2 } } */
 /* { dg-final { scan-assembler " DW_AT_ranges" } } */
-- 
2.39.2



RE: [r15-3185 Regression] FAIL: gcc.target/i386/avx10_2-compare-1.c (test for excess errors) on Linux/x86_64

2024-08-26 Thread Jiang, Haochen
As applied to all AVX10.2 patches, it is caused by vector size warning
mentioned previously.

Thx,
Haochen

> -Original Message-
> From: haochen.jiang 
> Sent: Monday, August 26, 2024 11:54 PM
> To: jun.zh...@intel.com; gcc-regress...@gcc.gnu.org; gcc-
> patc...@gcc.gnu.org; Jiang, Haochen 
> Subject: [r15-3185 Regression] FAIL: gcc.target/i386/avx10_2-compare-1.c
> (test for excess errors) on Linux/x86_64
> 
> On Linux/x86_64,
> 
> 576bd309ded9dfe258023f26924c064a7bf12875 is the first bad commit
> commit 576bd309ded9dfe258023f26924c064a7bf12875
> Author: Zhang, Jun 
> Date:   Mon Aug 26 10:53:54 2024 +0800
> 
> AVX10.2: Support compare instructions
> 
> caused
> 
> FAIL: gcc.target/i386/avx10_2-compare-1.c (test for excess errors)
> 
> with GCC configured with
> 
> ../../gcc/configure --prefix=/export/users/haochenj/src/gcc-
> bisect/master/master/r15-3185/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/avx10_2-compare-1.c --
> target_board='unix{-m32\ -march=cascadelake}'"
> $ cd {build_dir}/gcc && make check
> RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-compare-1.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.)


[pushed] testsuite: add event IDs to multithreaded event plugin test

2024-08-26 Thread David Malcolm
Add test coverage of "%@" in event messages in a multithreaded
execution path.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-3199-g6a1c359e28442c.

gcc/testsuite/ChangeLog:
* gcc.dg/plugin/diagnostic-test-paths-multithreaded-inline-events.c:
Update expected output.
* gcc.dg/plugin/diagnostic-test-paths-multithreaded-sarif.py:
Likewise.
* gcc.dg/plugin/diagnostic-test-paths-multithreaded-separate-events.c:
Likewise.
* gcc.dg/plugin/diagnostic_plugin_test_paths.c
(test_diagnostic_path::add_event_2): Return the id of the added
event.
(test_diagnostic_path::add_event_2_with_event_id): New.
(example_4): Add event IDs to the deadlock messages indicating
where the locks where acquired.

Signed-off-by: David Malcolm 
---
 ...c-test-paths-multithreaded-inline-events.c |  4 +-
 ...agnostic-test-paths-multithreaded-sarif.py |  4 +-
 ...test-paths-multithreaded-separate-events.c |  4 +-
 .../plugin/diagnostic_plugin_test_paths.c | 46 +--
 4 files changed, 38 insertions(+), 20 deletions(-)

diff --git 
a/gcc/testsuite/gcc.dg/plugin/diagnostic-test-paths-multithreaded-inline-events.c
 
b/gcc/testsuite/gcc.dg/plugin/diagnostic-test-paths-multithreaded-inline-events.c
index 333ef7359440..b306bcc1a0f3 100644
--- 
a/gcc/testsuite/gcc.dg/plugin/diagnostic-test-paths-multithreaded-inline-events.c
+++ 
b/gcc/testsuite/gcc.dg/plugin/diagnostic-test-paths-multithreaded-inline-events.c
@@ -58,7 +58,7 @@ Thread: 'Thread 1'
|   NN |   acquire_lock_b ();
|  |   ^
|  |   |
-   |  |   (5) deadlocked due to waiting for lock b in thread 1...
+   |  |   (5) deadlocked due to waiting for lock b in thread 1 
(acquired by thread 2 at (4))...
|
 
 Thread: 'Thread 2'
@@ -67,6 +67,6 @@ Thread: 'Thread 2'
|   NN |   acquire_lock_a ();
|  |   ^
|  |   |
-   |  |   (6) ...whilst waiting for lock a in thread 2
+   |  |   (6) ...whilst waiting for lock a in thread 2 (acquired 
by thread 1 at (2))
|
  { dg-end-multiline-output "" } */
diff --git 
a/gcc/testsuite/gcc.dg/plugin/diagnostic-test-paths-multithreaded-sarif.py 
b/gcc/testsuite/gcc.dg/plugin/diagnostic-test-paths-multithreaded-sarif.py
index cff78aa8ac8e..cb00faf1532a 100644
--- a/gcc/testsuite/gcc.dg/plugin/diagnostic-test-paths-multithreaded-sarif.py
+++ b/gcc/testsuite/gcc.dg/plugin/diagnostic-test-paths-multithreaded-sarif.py
@@ -95,7 +95,7 @@ def test_result(sarif):
 == "lock a is now held by thread 1"
 assert tf0['locations'][2]['executionOrder'] == 5
 assert tf0['locations'][2]['location']['message']['text'] \
-== "deadlocked due to waiting for lock b in thread 1..."
+== "deadlocked due to waiting for lock b in thread 1 (acquired by 
thread 2 at (4))..."
 
 assert len(tf1['locations']) == 3
 assert tf1['locations'][0]['executionOrder'] == 3
@@ -106,4 +106,4 @@ def test_result(sarif):
 == "lock b is now held by thread 2"
 assert tf1['locations'][2]['executionOrder'] == 6
 assert tf1['locations'][2]['location']['message']['text'] \
-== "...whilst waiting for lock a in thread 2"
+== "...whilst waiting for lock a in thread 2 (acquired by thread 1 at 
(2))"
diff --git 
a/gcc/testsuite/gcc.dg/plugin/diagnostic-test-paths-multithreaded-separate-events.c
 
b/gcc/testsuite/gcc.dg/plugin/diagnostic-test-paths-multithreaded-separate-events.c
index 914918bb9e16..90464320b8e7 100644
--- 
a/gcc/testsuite/gcc.dg/plugin/diagnostic-test-paths-multithreaded-separate-events.c
+++ 
b/gcc/testsuite/gcc.dg/plugin/diagnostic-test-paths-multithreaded-separate-events.c
@@ -7,12 +7,12 @@ extern void acquire_lock_b(void);
 void foo ()
 { /* { dg-message "\\(1\\) entering 'foo'" } */
   acquire_lock_a (); /* { dg-message "\\(2\\) lock a is now held by thread 1" 
} */
-  acquire_lock_b (); /* { dg-message "\\(5\\) deadlocked due to waiting for 
lock b in thread 1\.\.\." } */
+  acquire_lock_b (); /* { dg-message "\\(5\\) deadlocked due to waiting for 
lock b in thread 1 \\(acquired by thread 2 at \\(4\\)\\)\.\.\." } */
 }
 
 void bar ()
 { /* { dg-message "\\(3\\) entering 'bar'" } */
   acquire_lock_b (); /* { dg-message "\\(4\\) lock b is now held by thread 2" 
} */
   acquire_lock_a (); /* { dg-warning "deadlock due to inconsistent lock 
acquisition order" } */
-  /* { dg-message "\\(6\\) \.\.\.whilst waiting for lock a in thread 2

[r15-3183 Regression] FAIL: gcc.target/i386/avx10_2-minmax-1.c (test for excess errors) on Linux/x86_64

2024-08-26 Thread haochen.jiang
On Linux/x86_64,

889f6dd0d8c7317f62578c900c0f662e919786a2 is the first bad commit
commit 889f6dd0d8c7317f62578c900c0f662e919786a2
Author: Mo, Zewei 
Date:   Mon Aug 26 10:53:50 2024 +0800

AVX10.2: Support minmax instructions

caused

FAIL: gcc.target/i386/avx10_2-minmax-1.c (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-3183/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/avx10_2-minmax-1.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-minmax-1.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.)


[r15-3184 Regression] FAIL: gcc.target/i386/avx10_2-vmovw-1.c (test for excess errors) on Linux/x86_64

2024-08-26 Thread haochen.jiang
On Linux/x86_64,

f6fe2962daf7b8d8532c768c3b9eab00f99cce5b is the first bad commit
commit f6fe2962daf7b8d8532c768c3b9eab00f99cce5b
Author: Zhang, Jun 
Date:   Mon Aug 26 10:53:52 2024 +0800

AVX10.2: Support vector copy instructions

caused

FAIL: gcc.target/i386/avx10_2-vmovd-1.c (test for excess errors)
FAIL: gcc.target/i386/avx10_2-vmovw-1.c (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-3184/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/avx10_2-vmovd-1.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-vmovd-1.c 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-vmovw-1.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-vmovw-1.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.)


[r15-3178 Regression] FAIL: gcc.target/i386/avx10_2-convert-1.c (test for excess errors) on Linux/x86_64

2024-08-26 Thread haochen.jiang
On Linux/x86_64,

2a046117a8376578337dc385f171e908155782b7 is the first bad commit
commit 2a046117a8376578337dc385f171e908155782b7
Author: Levy Hsu 
Date:   Mon Aug 26 10:53:41 2024 +0800

AVX10.2: Support convert instructions

caused

FAIL: gcc.target/i386/avx10_2-convert-1.c (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-3178/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/avx10_2-convert-1.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-convert-1.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.)


[r15-3185 Regression] FAIL: gcc.target/i386/avx10_2-compare-1.c (test for excess errors) on Linux/x86_64

2024-08-26 Thread haochen.jiang
On Linux/x86_64,

576bd309ded9dfe258023f26924c064a7bf12875 is the first bad commit
commit 576bd309ded9dfe258023f26924c064a7bf12875
Author: Zhang, Jun 
Date:   Mon Aug 26 10:53:54 2024 +0800

AVX10.2: Support compare instructions

caused

FAIL: gcc.target/i386/avx10_2-compare-1.c (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-3185/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/avx10_2-compare-1.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-compare-1.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.)


[r15-3179 Regression] FAIL: gcc.target/i386/avx10_2-bf16-1.c (test for excess errors) on Linux/x86_64

2024-08-26 Thread haochen.jiang
On Linux/x86_64,

9023662464ac7a0bbac72d94078ea0845bf99c86 is the first bad commit
commit 9023662464ac7a0bbac72d94078ea0845bf99c86
Author: konglin1 
Date:   Mon Aug 26 10:53:43 2024 +0800

[PATCH 1/2] AVX10.2: Support BF16 instructions

caused

FAIL: gcc.target/i386/avx10_2-bf16-1.c (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-3179/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/avx10_2-bf16-1.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-bf16-1.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-bf16-1.c 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-bf16-1.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.)


[r15-3177 Regression] FAIL: gcc.target/i386/avx10_2-builtin-2.c (test for excess errors) on Linux/x86_64

2024-08-26 Thread haochen.jiang
On Linux/x86_64,

af0a06274fce2ca64456f5b13b4bc8ff864a45e4 is the first bad commit
commit af0a06274fce2ca64456f5b13b4bc8ff864a45e4
Author: Haochen Jiang 
Date:   Mon Aug 26 10:53:39 2024 +0800

[PATCH 2/2] AVX10.2: Support media instructions

caused

FAIL: gcc.target/i386/avx10_2-builtin-2.c (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-3177/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/avx10_2-builtin-2.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-builtin-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.)


[r15-3176 Regression] FAIL: gcc.target/i386/funcspec-6.c (test for excess errors) on Linux/x86_64

2024-08-26 Thread haochen.jiang
On Linux/x86_64,

8db80b2735782d793a83a9ef7eb012d83be7660d is the first bad commit
commit 8db80b2735782d793a83a9ef7eb012d83be7660d
Author: Hongyu Wang 
Date:   Mon Aug 26 10:53:37 2024 +0800

[PATCH 1/2] AVX10.2: Support media instructions

caused

FAIL: gcc.target/i386/avx10_2-builtin-1.c (test for excess errors)
FAIL: gcc.target/i386/avx10_2-media-1.c (test for excess errors)
FAIL: gcc.target/i386/funcspec-5.c (test for excess errors)
FAIL: gcc.target/i386/funcspec-6.c (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-3176/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/avx10_2-builtin-1.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-builtin-1.c 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-media-1.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-media-1.c 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/funcspec-5.c --target_board='unix{-m32\ 
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/funcspec-6.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: [PING^2] [PATCH] PR116080: Fix test suite checks for musttail

2024-08-25 Thread Andi Kleen
Andi Kleen  writes:

PING^2 for https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658602.html

This fixes some musttail related test suite failures that cause noise on
various targets.

> Andi Kleen  writes:
>
> I wanted to ping this patch. It fixes test suite noise on various
> targets.
>
> https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658602.html
>
>
>> From: Andi Kleen 
>>
>> This is a new attempt to fix PR116080. The previous try was reverted
>> because it just broke a bunch of tests, hiding the problem.
>>
>> - musttail behaves differently than tailcall at -O0. Some of the test
>> run at -O0, so add separate effective target tests for musttail.
>> - New effective target tests need to use unique file names
>> to make dejagnu caching work
>> - Change the tests to use new targets
>> - Add a external_musttail test to check for target's ability
>> to do tail calls between translation units. This covers some powerpc
>> ABIs.
>>
>> gcc/testsuite/ChangeLog:
>>
>>  PR testsuite/116080
>>  * c-c++-common/musttail1.c: Use musttail target.
>>  * c-c++-common/musttail12.c: Use struct_musttail target.
>>  * c-c++-common/musttail2.c: Use musttail target.
>>  * c-c++-common/musttail3.c: Likewise.
>>  * c-c++-common/musttail4.c: Likewise.
>>  * c-c++-common/musttail7.c: Likewise.
>>  * c-c++-common/musttail8.c: Likewise.
>>  * g++.dg/musttail10.C: Likewise. Replace powerpc checks with
>>  external_musttail.
>>  * g++.dg/musttail11.C: Use musttail target.
>>  * g++.dg/musttail6.C: Use musttail target. Replace powerpc
>>  checks with external_musttail.
>>  * g++.dg/musttail9.C: Use musttail target.
>>  * lib/target-supports.exp: Add musttail, struct_musttail,
>>  external_musttail targets. Remove optimization for musttail.
>>  Use unique file names for musttail.
>> ---
>>  gcc/testsuite/c-c++-common/musttail1.c  |  2 +-
>>  gcc/testsuite/c-c++-common/musttail12.c |  2 +-
>>  gcc/testsuite/c-c++-common/musttail2.c  |  2 +-
>>  gcc/testsuite/c-c++-common/musttail3.c  |  2 +-
>>  gcc/testsuite/c-c++-common/musttail4.c  |  2 +-
>>  gcc/testsuite/c-c++-common/musttail7.c  |  2 +-
>>  gcc/testsuite/c-c++-common/musttail8.c  |  2 +-
>>  gcc/testsuite/g++.dg/musttail10.C   |  4 ++--
>>  gcc/testsuite/g++.dg/musttail11.C   |  2 +-
>>  gcc/testsuite/g++.dg/musttail6.C|  4 ++--
>>  gcc/testsuite/g++.dg/musttail9.C|  2 +-
>>  gcc/testsuite/lib/target-supports.exp   | 30 -
>>  12 files changed, 37 insertions(+), 19 deletions(-)
>>
>> diff --git a/gcc/testsuite/c-c++-common/musttail1.c 
>> b/gcc/testsuite/c-c++-common/musttail1.c
>> index 74efcc2a0bc6..51549672e02a 100644
>> --- a/gcc/testsuite/c-c++-common/musttail1.c
>> +++ b/gcc/testsuite/c-c++-common/musttail1.c
>> @@ -1,4 +1,4 @@
>> -/* { dg-do compile { target { tail_call && { c || c++11 } } } } */
>> +/* { dg-do compile { target { musttail && { c || c++11 } } } } */
>>  /* { dg-additional-options "-fdelayed-branch" { target sparc*-*-* } } */
>>  
>>  int __attribute__((noinline,noclone,noipa))
>> diff --git a/gcc/testsuite/c-c++-common/musttail12.c 
>> b/gcc/testsuite/c-c++-common/musttail12.c
>> index 4140bcd00950..475afc5af3f3 100644
>> --- a/gcc/testsuite/c-c++-common/musttail12.c
>> +++ b/gcc/testsuite/c-c++-common/musttail12.c
>> @@ -1,4 +1,4 @@
>> -/* { dg-do compile { target { struct_tail_call && { c || c++11 } } } } */
>> +/* { dg-do compile { target { struct_musttail && { c || c++11 } } } } */
>>  /* { dg-additional-options "-fdelayed-branch" { target sparc*-*-* } } */
>>  
>>  struct str
>> diff --git a/gcc/testsuite/c-c++-common/musttail2.c 
>> b/gcc/testsuite/c-c++-common/musttail2.c
>> index 86f2c3d77404..1970c4edd670 100644
>> --- a/gcc/testsuite/c-c++-common/musttail2.c
>> +++ b/gcc/testsuite/c-c++-common/musttail2.c
>> @@ -1,4 +1,4 @@
>> -/* { dg-do compile { target { tail_call && { c || c++11 } } } } */
>> +/* { dg-do compile { target { musttail && { c || c++11 } } } } */
>>  
>>  struct box { char field[256]; int i; };
>>  
>> diff --git a/gcc/testsuite/c-c++-common/musttail3.c 
>> b/gcc/testsuite/c-c++-common/musttail3.c
>> index ea9589c59ef2..7499fd6460b4 100644
>> --- a/gcc/testsuite/c-c++-common/musttail3.c
>> +++ b/gcc/testsuite/c-c++-common/musttail3.c
>> @@ -1,4 +1,4 @@
>> -/* { dg-do compile { target { tail

[committed] Disable late-combine in another RISC-V test

2024-08-25 Thread Jeff Law
Another test where the output was slightly twiddled by late-combine in 
which simply disabling late-combine seems to be the best option.



Running /home/jlaw/test/gcc/gcc/testsuite/gcc.target/riscv/riscv.exp ...
FAIL: gcc.target/riscv/cm_mv_rv32.c   -Os   check-function-bodies sum



Pushing to the trunk.

Jeffcommit 70edccf88738ec204036e498a4a50c46e5e4f0c0
Author: Jeff Law 
Date:   Sun Aug 25 07:24:56 2024 -0600

Disable late-combine in another RISC-V test

Another test where the output was slightly twiddled by late-combine in which
simply disabling late-combine seems to be the best option.

> Running /home/jlaw/test/gcc/gcc/testsuite/gcc.target/riscv/riscv.exp ...
> FAIL: gcc.target/riscv/cm_mv_rv32.c   -Os   check-function-bodies sum

Pushing to the trunk.

gcc/testsuite
* gcc.target/riscv/cm_mv_rv32.c: Disable late-combine.

diff --git a/gcc/testsuite/gcc.target/riscv/cm_mv_rv32.c 
b/gcc/testsuite/gcc.target/riscv/cm_mv_rv32.c
index 2c1b3f9cabf..e2369fc4d2d 100644
--- a/gcc/testsuite/gcc.target/riscv/cm_mv_rv32.c
+++ b/gcc/testsuite/gcc.target/riscv/cm_mv_rv32.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options " -Os -march=rv32i_zca_zcmp -mabi=ilp32 " } */
+/* { dg-options " -Os -march=rv32i_zca_zcmp -mabi=ilp32 
-fno-late-combine-instructions " } */
 /* { dg-skip-if "" { *-*-* } {"-O0" "-O1" "-O2" "-Og" "-O3" "-Oz" "-flto"} } */
 /* { dg-final { check-function-bodies "**" "" } } */
 


Re: [PATCH] Fix test failure on powerpc targets

2024-08-23 Thread Richard Biener



> Am 23.08.2024 um 06:42 schrieb Bernd Edlinger :
> 
> Apparently due to slightly different optimization levels
> not always both subroutines have multiple subranges,
> but having at least one such, and no lexical blocks
> is sufficient to prove that the fix worked.  Q.E.D.
> So reduce the test expectations to only at least one
> inlined subroutine with multiple subranges.

Ok

Richard 

> gcc/testsuite/ChangeLog:
> 
>PR 116462
>* gcc.dg/debug/dwarf2/inline7.c: Reduce test expectations.
> ---
> gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
> 
> fix was confirmed by reporter, OK for trunk?
> 
> diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c 
> b/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c
> index 48d457216b1..083df5b586c 100644
> --- a/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c
> +++ b/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c
> @@ -1,9 +1,9 @@
> -/* Verify that both inline instances have a DW_AT_ranges but
> -   no extra DW_TAG_lexical_block.  */
> +/* Verify that at least one of both inline instances have
> +   a DW_AT_ranges but no extra DW_TAG_lexical_block.  */
> /* { dg-options "-O -gdwarf -dA" } */
> /* { dg-do compile } */
> /* { dg-final { scan-assembler-times "\\(DIE \\(\[^\n\]*\\) 
> DW_TAG_inlined_subroutine" 2 } } */
> -/* { dg-final { scan-assembler-times " DW_AT_ranges" 2 } } */
> +/* { dg-final { scan-assembler " DW_AT_ranges" } } */
> /* { dg-final { scan-assembler-times "\\(DIE \\(\[^\n\]*\\) 
> DW_TAG_lexical_block" 0 } } */
> 
> static int foo (int i)
> --
> 2.39.2
> 


[PATCH] Fix test failure on powerpc targets

2024-08-22 Thread Bernd Edlinger
Apparently due to slightly different optimization levels
not always both subroutines have multiple subranges,
but having at least one such, and no lexical blocks
is sufficient to prove that the fix worked.  Q.E.D.
So reduce the test expectations to only at least one
inlined subroutine with multiple subranges.

gcc/testsuite/ChangeLog:

PR 116462
* gcc.dg/debug/dwarf2/inline7.c: Reduce test expectations.
---
 gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

fix was confirmed by reporter, OK for trunk?

diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c 
b/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c
index 48d457216b1..083df5b586c 100644
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c
@@ -1,9 +1,9 @@
-/* Verify that both inline instances have a DW_AT_ranges but
-   no extra DW_TAG_lexical_block.  */
+/* Verify that at least one of both inline instances have
+   a DW_AT_ranges but no extra DW_TAG_lexical_block.  */
 /* { dg-options "-O -gdwarf -dA" } */
 /* { dg-do compile } */
 /* { dg-final { scan-assembler-times "\\(DIE \\(\[^\n\]*\\) 
DW_TAG_inlined_subroutine" 2 } } */
-/* { dg-final { scan-assembler-times " DW_AT_ranges" 2 } } */
+/* { dg-final { scan-assembler " DW_AT_ranges" } } */
 /* { dg-final { scan-assembler-times "\\(DIE \\(\[^\n\]*\\) 
DW_TAG_lexical_block" 0 } } */
 
 static int foo (int i)
-- 
2.39.2



Re: [PATCH] libstdc++: Add some missing ranges feature-test macro tests

2024-08-22 Thread Jonathan Wakely
On Thu, 22 Aug 2024 at 14:31, Patrick Palka  wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and
> perhaps 14?

OK for trunk and gcc-14.

We didn't backport the fix to move ranges::iota to , so the
iota.cc test will need adjustment on the branch.


>
> -- >8 --
>
> libstdc++-v3/ChangeLog:
>
> * testsuite/25_algorithms/contains/1.cc: Verify value of
> __cpp_lib_ranges_contains.
> * testsuite/25_algorithms/find_last/1.cc: Verify value of
> __cpp_lib_ranges_find_last.
> * testsuite/26_numerics/iota/2.cc: Verify value of
> __cpp_lib_ranges_iota.
> ---
>  libstdc++-v3/testsuite/25_algorithms/contains/1.cc  | 4 
>  libstdc++-v3/testsuite/25_algorithms/find_last/1.cc | 4 
>  libstdc++-v3/testsuite/26_numerics/iota/2.cc| 4 
>  3 files changed, 12 insertions(+)
>
> diff --git a/libstdc++-v3/testsuite/25_algorithms/contains/1.cc 
> b/libstdc++-v3/testsuite/25_algorithms/contains/1.cc
> index 7d3fa048ef6..b44c06032e8 100644
> --- a/libstdc++-v3/testsuite/25_algorithms/contains/1.cc
> +++ b/libstdc++-v3/testsuite/25_algorithms/contains/1.cc
> @@ -4,6 +4,10 @@
>  #include 
>  #include 
>
> +#if __cpp_lib_ranges_contains != 202207L
> +# error "Feature-test macro __cpp_lib_ranges_contains has wrong value in 
> "
> +#endif
> +
>  namespace ranges = std::ranges;
>
>  void
> diff --git a/libstdc++-v3/testsuite/25_algorithms/find_last/1.cc 
> b/libstdc++-v3/testsuite/25_algorithms/find_last/1.cc
> index 911e22887d1..8a40bb1a6b3 100644
> --- a/libstdc++-v3/testsuite/25_algorithms/find_last/1.cc
> +++ b/libstdc++-v3/testsuite/25_algorithms/find_last/1.cc
> @@ -4,6 +4,10 @@
>  #include 
>  #include 
>
> +#if __cpp_lib_ranges_find_last != 202207L
> +# error "Feature-test macro __cpp_lib_ranges_find_last has wrong value in 
> "
> +#endif
> +
>  namespace ranges = std::ranges;
>
>  constexpr bool
> diff --git a/libstdc++-v3/testsuite/26_numerics/iota/2.cc 
> b/libstdc++-v3/testsuite/26_numerics/iota/2.cc
> index 040c48d91ce..b14580b8be1 100644
> --- a/libstdc++-v3/testsuite/26_numerics/iota/2.cc
> +++ b/libstdc++-v3/testsuite/26_numerics/iota/2.cc
> @@ -4,6 +4,10 @@
>  #include 
>  #include 
>
> +#if __cpp_lib_ranges_iota != 202202L
> +# error "Feature-test macro __cpp_lib_ranges_iota has wrong value in 
> "
> +#endif
> +
>  namespace ranges = std::ranges;
>
>  void
> --
> 2.46.0.288.g3a7362eb9f
>



[PATCH] libstdc++: Add some missing ranges feature-test macro tests

2024-08-22 Thread Patrick Palka
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and
perhaps 14?

-- >8 --

libstdc++-v3/ChangeLog:

* testsuite/25_algorithms/contains/1.cc: Verify value of
__cpp_lib_ranges_contains.
* testsuite/25_algorithms/find_last/1.cc: Verify value of
__cpp_lib_ranges_find_last.
* testsuite/26_numerics/iota/2.cc: Verify value of
__cpp_lib_ranges_iota.
---
 libstdc++-v3/testsuite/25_algorithms/contains/1.cc  | 4 
 libstdc++-v3/testsuite/25_algorithms/find_last/1.cc | 4 
 libstdc++-v3/testsuite/26_numerics/iota/2.cc| 4 
 3 files changed, 12 insertions(+)

diff --git a/libstdc++-v3/testsuite/25_algorithms/contains/1.cc 
b/libstdc++-v3/testsuite/25_algorithms/contains/1.cc
index 7d3fa048ef6..b44c06032e8 100644
--- a/libstdc++-v3/testsuite/25_algorithms/contains/1.cc
+++ b/libstdc++-v3/testsuite/25_algorithms/contains/1.cc
@@ -4,6 +4,10 @@
 #include 
 #include 
 
+#if __cpp_lib_ranges_contains != 202207L
+# error "Feature-test macro __cpp_lib_ranges_contains has wrong value in 
"
+#endif
+
 namespace ranges = std::ranges;
 
 void
diff --git a/libstdc++-v3/testsuite/25_algorithms/find_last/1.cc 
b/libstdc++-v3/testsuite/25_algorithms/find_last/1.cc
index 911e22887d1..8a40bb1a6b3 100644
--- a/libstdc++-v3/testsuite/25_algorithms/find_last/1.cc
+++ b/libstdc++-v3/testsuite/25_algorithms/find_last/1.cc
@@ -4,6 +4,10 @@
 #include 
 #include 
 
+#if __cpp_lib_ranges_find_last != 202207L
+# error "Feature-test macro __cpp_lib_ranges_find_last has wrong value in 
"
+#endif
+
 namespace ranges = std::ranges;
 
 constexpr bool
diff --git a/libstdc++-v3/testsuite/26_numerics/iota/2.cc 
b/libstdc++-v3/testsuite/26_numerics/iota/2.cc
index 040c48d91ce..b14580b8be1 100644
--- a/libstdc++-v3/testsuite/26_numerics/iota/2.cc
+++ b/libstdc++-v3/testsuite/26_numerics/iota/2.cc
@@ -4,6 +4,10 @@
 #include 
 #include 
 
+#if __cpp_lib_ranges_iota != 202202L
+# error "Feature-test macro __cpp_lib_ranges_iota has wrong value in "
+#endif
+
 namespace ranges = std::ranges;
 
 void
-- 
2.46.0.288.g3a7362eb9f



[r15-3080 Regression] FAIL: gfortran.dg/sizeof_6.f90 -O1 execution test on Linux/x86_64

2024-08-22 Thread haochen.jiang
On Linux/x86_64,

c1aba5e7e7da5f2bd75873d3853f1de85addc2ac is the first bad commit
commit c1aba5e7e7da5f2bd75873d3853f1de85addc2ac
Author: Sam James 
Date:   Wed Aug 14 13:25:01 2024 +0100

Makefile.tpl: fix whitespace in licence header

caused

FAIL: gfortran.dg/sizeof_6.f90   -O1  execution test

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-3080/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=gfortran.dg/sizeof_6.f90 --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.)


[r15-3052 Regression] FAIL: gfortran.dg/sizeof_6.f90 -O1 execution test on Linux/x86_64

2024-08-21 Thread haochen.jiang
On Linux/x86_64,

c7b76a076cb2c6ded7ae208464019b04cb0531a2 is the first bad commit
commit c7b76a076cb2c6ded7ae208464019b04cb0531a2
Author: Andrew Pinski 
Date:   Mon Aug 19 08:06:36 2024 -0700

match: Reject non-ssa name/min invariants in gimple_extract [PR116412]

caused

FAIL: gfortran.dg/sizeof_6.f90   -O1  execution test

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-3052/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=gfortran.dg/sizeof_6.f90 --target_board='unix{-m64}'"

(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: [r15-3000 Regression] FAIL: gcc.target/i386/avx10_2-rounding-3.c (test for excess errors) on Linux/x86_64

2024-08-20 Thread Jiang, Haochen
The three avx10.2 related test regression are all related to the usage of
-mavx10.2 -march=cascadelake, which is unavoidable warning.

I am considering to change -march=cascadelake to a arch with AVX10 in
the future to avoid these false alarms.

Thx,
Haochen

> -Original Message-
> From: haochen.jiang 
> Sent: Tuesday, August 20, 2024 11:59 PM
> To: Hu, Lin1 ; gcc-regress...@gcc.gnu.org; gcc-
> patc...@gcc.gnu.org; Jiang, Haochen 
> Subject: [r15-3000 Regression] FAIL: gcc.target/i386/avx10_2-rounding-3.c
> (test for excess errors) on Linux/x86_64
> 
> On Linux/x86_64,
> 
> 3d1b5530ea1d23e26dc5ab70aa4a2e7b9dc19b50 is the first bad commit
> commit 3d1b5530ea1d23e26dc5ab70aa4a2e7b9dc19b50
> Author: Hu, Lin1 
> Date:   Mon Aug 19 10:09:03 2024 +0800
> 
> AVX10.2 ymm rounding: Support vcvt{,u}w2ph and vdivp{s,d,h} intrins
> 
> caused
> 
> FAIL: gcc.target/i386/avx10_2-rounding-3.c (test for excess errors)
> 
> with GCC configured with
> 
> ../../gcc/configure --prefix=/export/users/haochenj/src/gcc-
> bisect/master/master/r15-3000/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/avx10_2-rounding-3.c --
> target_board='unix{-m32\ -march=cascadelake}'"
> $ cd {build_dir}/gcc && make check
> RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-rounding-3.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.)


[r15-2997 Regression] FAIL: gcc.target/i386/avx10_2-rounding-2.c (test for excess errors) on Linux/x86_64

2024-08-20 Thread haochen.jiang
On Linux/x86_64,

6e231f8504874828b23bbe89f3ef4086dcc15a44 is the first bad commit
commit 6e231f8504874828b23bbe89f3ef4086dcc15a44
Author: Hu, Lin1 
Date:   Mon Aug 19 10:08:59 2024 +0800

AVX10.2 ymm rounding: Support vcvtqq2p{s,d,h} and vcvttpd2{,u}{dq,qq} 
intrins

caused

FAIL: gcc.target/i386/avx10_2-rounding-2.c (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-2997/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/avx10_2-rounding-2.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-rounding-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.)


[r15-3000 Regression] FAIL: gcc.target/i386/avx10_2-rounding-3.c (test for excess errors) on Linux/x86_64

2024-08-20 Thread haochen.jiang
On Linux/x86_64,

3d1b5530ea1d23e26dc5ab70aa4a2e7b9dc19b50 is the first bad commit
commit 3d1b5530ea1d23e26dc5ab70aa4a2e7b9dc19b50
Author: Hu, Lin1 
Date:   Mon Aug 19 10:09:03 2024 +0800

AVX10.2 ymm rounding: Support vcvt{,u}w2ph and vdivp{s,d,h} intrins

caused

FAIL: gcc.target/i386/avx10_2-rounding-3.c (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-3000/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/avx10_2-rounding-3.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-rounding-3.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.)


[r15-2991 Regression] FAIL: gcc.target/i386/avx10_2-rounding-1.c (test for excess errors) on Linux/x86_64

2024-08-20 Thread haochen.jiang
On Linux/x86_64,

e22e3af1954469c40b139b7cfa8e7708592f4bfd is the first bad commit
commit e22e3af1954469c40b139b7cfa8e7708592f4bfd
Author: Hu, Lin1 
Date:   Mon Aug 19 10:08:51 2024 +0800

AVX10.2 ymm rounding: Support vadd{s,d,h} and vcmp{s,d,h} intrins

caused

FAIL: gcc.target/i386/avx10_2-rounding-1.c scan-assembler-times vcmppd[ 
\\t]+[^{\n]*{sae}[^\n]*%ymm[0-9]+[^\n^k]*%k[0-7](?:\n|[ \\t]+#) 1
FAIL: gcc.target/i386/avx10_2-rounding-1.c scan-assembler-times vcmppd[ 
\\t]+[^{\n]*{sae}[^\n]*%ymm[0-9]+[^\n^k]*%k[0-7]{%k[1-7]}(?:\n|[ \\t]+#) 1
FAIL: gcc.target/i386/avx10_2-rounding-1.c scan-assembler-times vcmpph[ 
\\t]+\\$3[^\n\r]*{sae}[^\n\r]*%ymm[0-9]+[^\n\r]*%ymm[0-9]+[^\n\r]*%k[0-9][^\n\r]*(?:\n|[
 \\t]+#) 1
FAIL: gcc.target/i386/avx10_2-rounding-1.c scan-assembler-times vcmpph[ 
\\t]+[^{\n]*\\$4[^\n\r]*%ymm[0-9]+[^\n\r]*%ymm[0-9]+[^\n\r]*%k[0-9]{%k[0-9]}[^\n\r]*(?:\n|[
 \\t]+#) 1
FAIL: gcc.target/i386/avx10_2-rounding-1.c scan-assembler-times vcmpps[ 
\\t]+[^{\n]*{sae}[^\n]*%ymm[0-9]+[^\n^k]*%k[0-7](?:\n|[ \\t]+#) 1
FAIL: gcc.target/i386/avx10_2-rounding-1.c scan-assembler-times vcmpps[ 
\\t]+[^{\n]*{sae}[^\n]*%ymm[0-9]+[^\n^k]*%k[0-7]{%k[1-7]}(?:\n|[ \\t]+#) 1
FAIL: gcc.target/i386/avx10_2-rounding-1.c (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-2991/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/avx10_2-rounding-1.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-rounding-1.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 v1] RISC-V: Fix one typo in .SAT_TRUNC test func name [NFC]

2024-08-20 Thread Jeff Law




On 8/20/24 7:11 AM, pan2...@intel.com wrote:

From: Pan Li 

Fix one typo `sat_truc` to `sat_trunc`, as well as `SAT_TRUC` to `SAT_TRUNC`.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/sat_arith.h: Fix SAT_TRUNC typo.
* gcc.target/riscv/sat_u_trunc-1.c: Ditto.
* gcc.target/riscv/sat_u_trunc-13.c: Ditto.
* gcc.target/riscv/sat_u_trunc-14.c: Ditto.
* gcc.target/riscv/sat_u_trunc-15.c: Ditto.
* gcc.target/riscv/sat_u_trunc-2.c: Ditto.
* gcc.target/riscv/sat_u_trunc-3.c: Ditto.
* gcc.target/riscv/sat_u_trunc-4.c: Ditto.
* gcc.target/riscv/sat_u_trunc-5.c: Ditto.
* gcc.target/riscv/sat_u_trunc-6.c: Ditto.
* gcc.target/riscv/sat_u_trunc-7.c: Ditto.
* gcc.target/riscv/sat_u_trunc-8.c: Ditto.
* gcc.target/riscv/sat_u_trunc-9.c: Ditto.
* gcc.target/riscv/sat_u_trunc-run-1.c: Ditto.
* gcc.target/riscv/sat_u_trunc-run-13.c: Ditto.
* gcc.target/riscv/sat_u_trunc-run-14.c: Ditto.
* gcc.target/riscv/sat_u_trunc-run-15.c: Ditto.
* gcc.target/riscv/sat_u_trunc-run-2.c: Ditto.
* gcc.target/riscv/sat_u_trunc-run-3.c: Ditto.
* gcc.target/riscv/sat_u_trunc-run-4.c: Ditto.
* gcc.target/riscv/sat_u_trunc-run-5.c: Ditto.
* gcc.target/riscv/sat_u_trunc-run-6.c: Ditto.
* gcc.target/riscv/sat_u_trunc-run-7.c: Ditto.
* gcc.target/riscv/sat_u_trunc-run-8.c: Ditto.
* gcc.target/riscv/sat_u_trunc-run-9.c: Ditto.

OK
jeff



[PATCH v1] RISC-V: Fix one typo in .SAT_TRUNC test func name [NFC]

2024-08-20 Thread pan2 . li
From: Pan Li 

Fix one typo `sat_truc` to `sat_trunc`, as well as `SAT_TRUC` to `SAT_TRUNC`.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/sat_arith.h: Fix SAT_TRUNC typo.
* gcc.target/riscv/sat_u_trunc-1.c: Ditto.
* gcc.target/riscv/sat_u_trunc-13.c: Ditto.
* gcc.target/riscv/sat_u_trunc-14.c: Ditto.
* gcc.target/riscv/sat_u_trunc-15.c: Ditto.
* gcc.target/riscv/sat_u_trunc-2.c: Ditto.
* gcc.target/riscv/sat_u_trunc-3.c: Ditto.
* gcc.target/riscv/sat_u_trunc-4.c: Ditto.
* gcc.target/riscv/sat_u_trunc-5.c: Ditto.
* gcc.target/riscv/sat_u_trunc-6.c: Ditto.
* gcc.target/riscv/sat_u_trunc-7.c: Ditto.
* gcc.target/riscv/sat_u_trunc-8.c: Ditto.
* gcc.target/riscv/sat_u_trunc-9.c: Ditto.
* gcc.target/riscv/sat_u_trunc-run-1.c: Ditto.
* gcc.target/riscv/sat_u_trunc-run-13.c: Ditto.
* gcc.target/riscv/sat_u_trunc-run-14.c: Ditto.
* gcc.target/riscv/sat_u_trunc-run-15.c: Ditto.
* gcc.target/riscv/sat_u_trunc-run-2.c: Ditto.
* gcc.target/riscv/sat_u_trunc-run-3.c: Ditto.
* gcc.target/riscv/sat_u_trunc-run-4.c: Ditto.
* gcc.target/riscv/sat_u_trunc-run-5.c: Ditto.
* gcc.target/riscv/sat_u_trunc-run-6.c: Ditto.
* gcc.target/riscv/sat_u_trunc-run-7.c: Ditto.
* gcc.target/riscv/sat_u_trunc-run-8.c: Ditto.
* gcc.target/riscv/sat_u_trunc-run-9.c: Ditto.

Signed-off-by: Pan Li 
---
 gcc/testsuite/gcc.target/riscv/sat_arith.h| 30 +--
 .../gcc.target/riscv/sat_u_trunc-1.c  |  4 +--
 .../gcc.target/riscv/sat_u_trunc-13.c |  4 +--
 .../gcc.target/riscv/sat_u_trunc-14.c |  4 +--
 .../gcc.target/riscv/sat_u_trunc-15.c |  4 +--
 .../gcc.target/riscv/sat_u_trunc-2.c  |  4 +--
 .../gcc.target/riscv/sat_u_trunc-3.c  |  4 +--
 .../gcc.target/riscv/sat_u_trunc-4.c  |  4 +--
 .../gcc.target/riscv/sat_u_trunc-5.c  |  4 +--
 .../gcc.target/riscv/sat_u_trunc-6.c  |  4 +--
 .../gcc.target/riscv/sat_u_trunc-7.c  |  4 +--
 .../gcc.target/riscv/sat_u_trunc-8.c  |  4 +--
 .../gcc.target/riscv/sat_u_trunc-9.c  |  4 +--
 .../gcc.target/riscv/sat_u_trunc-run-1.c  |  4 +--
 .../gcc.target/riscv/sat_u_trunc-run-13.c |  4 +--
 .../gcc.target/riscv/sat_u_trunc-run-14.c |  4 +--
 .../gcc.target/riscv/sat_u_trunc-run-15.c |  4 +--
 .../gcc.target/riscv/sat_u_trunc-run-2.c  |  4 +--
 .../gcc.target/riscv/sat_u_trunc-run-3.c  |  4 +--
 .../gcc.target/riscv/sat_u_trunc-run-4.c  |  4 +--
 .../gcc.target/riscv/sat_u_trunc-run-5.c  |  4 +--
 .../gcc.target/riscv/sat_u_trunc-run-6.c  |  4 +--
 .../gcc.target/riscv/sat_u_trunc-run-7.c  |  4 +--
 .../gcc.target/riscv/sat_u_trunc-run-8.c  |  4 +--
 .../gcc.target/riscv/sat_u_trunc-run-9.c  |  4 +--
 25 files changed, 63 insertions(+), 63 deletions(-)

diff --git a/gcc/testsuite/gcc.target/riscv/sat_arith.h 
b/gcc/testsuite/gcc.target/riscv/sat_arith.h
index cf055410fd1..91853b60f59 100644
--- a/gcc/testsuite/gcc.target/riscv/sat_arith.h
+++ b/gcc/testsuite/gcc.target/riscv/sat_arith.h
@@ -218,40 +218,40 @@ sat_u_sub_##T##_fmt_12 (T x, T y)  \
 /* Saturation Truncate (unsigned and signed)  
*/
 
/**/
 
-#define DEF_SAT_U_TRUC_FMT_1(NT, WT) \
+#define DEF_SAT_U_TRUNC_FMT_1(NT, WT)\
 NT __attribute__((noinline)) \
-sat_u_truc_##WT##_to_##NT##_fmt_1 (WT x) \
+sat_u_trunc_##WT##_to_##NT##_fmt_1 (WT x) \
 {\
   bool overflow = x > (WT)(NT)(-1);  \
   return ((NT)x) | (NT)-overflow;\
 }
-#define DEF_SAT_U_TRUC_FMT_1_WRAP(NT, WT) DEF_SAT_U_TRUC_FMT_1(NT, WT)
+#define DEF_SAT_U_TRUNC_FMT_1_WRAP(NT, WT) DEF_SAT_U_TRUNC_FMT_1(NT, WT)
 
-#define DEF_SAT_U_TRUC_FMT_2(NT, WT) \
+#define DEF_SAT_U_TRUNC_FMT_2(NT, WT)\
 NT __attribute__((noinline)) \
-sat_u_truc_##WT##_to_##NT##_fmt_2 (WT x) \
+sat_u_trunc_##WT##_to_##NT##_fmt_2 (WT x) \
 {\
   WT max = (WT)(NT)-1;   \
   return x > max ? (NT) max : (NT)x; \
 }
-#define DEF_SAT_U_TRUC_FMT_2_WRAP(NT, WT) DEF_SAT_U_TRUC_FMT_2(NT, WT)
+#define DEF_SAT_U_TRUNC_FMT_2_WRAP(NT, WT) DEF_SAT_U_TRUNC_FMT_2(NT, WT)
 
-#define DEF_SAT_U_TRUC_FMT_3(NT, WT) \
+#define DEF_SAT_U_TRUNC_FMT_3(NT, WT)\
 NT __attribute__((noinline)) \
-sat_u_truc_##WT##_to_##NT##_fmt_3 (WT x) \
+sat_u_trunc_##WT##_to_##NT##_fmt_3 (WT x) \
 {\
   WT max = (WT)(NT)-1;   \
   return x <= max ? (NT)x : (NT) max;\
 }
-#define DEF_SAT_U_TRUC_FMT_3_WRAP(NT, WT) DEF_SAT_U_TRUC_FMT_3(NT, WT)
+#define DEF_SAT_U_TRUNC_FMT_3_WRAP(NT, WT) DEF_SAT_U_TRUNC_FMT_3(NT, WT)
 
-#define RUN_SAT_U_TRUC_FMT_1(NT, WT, x) sat_u

RE: [PATCH V3 10/10] autovectorizer: Test autovectorization of different dot-prod modes.

2024-08-20 Thread Tamar Christina
> -Original Message-
> From: Richard Biener 
> Sent: Tuesday, August 20, 2024 1:54 PM
> To: Tamar Christina 
> Cc: Victor Do Nascimento ; gcc-
> patc...@gcc.gnu.org; claz...@gmail.com; hongtao@intel.com;
> s...@gcc.gnu.org; bernds_...@t-online.de; al...@redhat.com; Victor Do
> Nascimento 
> Subject: Re: [PATCH V3 10/10] autovectorizer: Test autovectorization of 
> different
> dot-prod modes.
> 
> On Tue, Aug 20, 2024 at 12:04 PM Tamar Christina
>  wrote:
> >
> > > -Original Message-
> > > From: Richard Biener 
> > > Sent: Tuesday, August 20, 2024 10:37 AM
> > > To: Victor Do Nascimento 
> > > Cc: gcc-patches@gcc.gnu.org; Tamar Christina ;
> > > claz...@gmail.com; hongtao@intel.com; s...@gcc.gnu.org; bernds_cb1@t-
> > > online.de; al...@redhat.com; Victor Do Nascimento
> > > 
> > > Subject: Re: [PATCH V3 10/10] autovectorizer: Test autovectorization of
> different
> > > dot-prod modes.
> > >
> > > On Thu, Aug 15, 2024 at 10:46 AM Victor Do Nascimento
> > >  wrote:
> > > >
> > > > From: Victor Do Nascimento 
> > > >
> > > > Given the novel treatment of the dot product optab as a conversion, we
> > > > are now able to targe 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 was not:
> > > >
> > > > 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, gated behind the new check_effective_target
> > > > `vect_dotprod_twoway' as well a runtime check targetting aarch64.
> > >
> > > I think vect_dotprod_twoway is not clear - does aarch64 now support
> > > all of qi->hi, hi->si, si->di variants while formerly only "fourway"
> > > qi->si and hi->di?
> > >
> > > If it's just hi->si that's now supported please use vect_dotprod_hisi
> > > to be specific as to what is required/supported.
> >
> > At the moment we support only H->S, but other variants are being considered.
> > So perhaps vect_dotprod_single_step or something to make it clearer what it
> > does but still be general?
> 
> But to be useful in the testsuite it has to be specific, not general.

Oh I see, you were talking specifically about the testsuite function and not the
optab itself.  Yes, agreed. Sorry misunderstood!

Tamar
> 
> > Thanks,
> > Tamar
> >
> > >
> > > Richard.
> > >
> > > > gcc/testsuite/ChangeLog:
> > > >
> > > > * lib/target-supports.exp
> (check_effective_target_vect_dotprod_twoway):
> > > > New.
> > > > * gcc.dg/vect/vect-dotprod-twoway.c: Likewise.
> > > > * gcc.target/aarch64/vect-dotprod-twoway.c: Likewise.
> > > > ---
> > > >  .../gcc.dg/vect/vect-dotprod-twoway.c | 39 +++
> > > >  .../gcc.target/aarch64/vect-dotprod-twoway.c  | 65
> +++
> > > >  gcc/testsuite/lib/target-supports.exp |  8 +++
> > > >  3 files changed, 112 insertions(+)
> > > >  create mode 100644 gcc/testsuite/gcc.dg/vect/vect-dotprod-twoway.c
> > > >  create mode 100644 gcc/testsuite/gcc.target/aarch64/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..ff6a2559dee
> > > > --- /dev/null
> > > > +++ b/gcc/testsuite/gcc.dg/vect/vect-dotprod-twoway.c
> > > > @@ -0,0 +1,39 @@
> > > > +/* { dg-do compile } */
> > > > +/* { dg-require-effectiv

Re: [PATCH V3 10/10] autovectorizer: Test autovectorization of different dot-prod modes.

2024-08-20 Thread Richard Biener
On Tue, Aug 20, 2024 at 12:04 PM Tamar Christina
 wrote:
>
> > -Original Message-
> > From: Richard Biener 
> > Sent: Tuesday, August 20, 2024 10:37 AM
> > To: Victor Do Nascimento 
> > Cc: gcc-patches@gcc.gnu.org; Tamar Christina ;
> > claz...@gmail.com; hongtao@intel.com; s...@gcc.gnu.org; bernds_cb1@t-
> > online.de; al...@redhat.com; Victor Do Nascimento
> > 
> > Subject: Re: [PATCH V3 10/10] autovectorizer: Test autovectorization of 
> > different
> > dot-prod modes.
> >
> > On Thu, Aug 15, 2024 at 10:46 AM Victor Do Nascimento
> >  wrote:
> > >
> > > From: Victor Do Nascimento 
> > >
> > > Given the novel treatment of the dot product optab as a conversion, we
> > > are now able to targe 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 was not:
> > >
> > > 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, gated behind the new check_effective_target
> > > `vect_dotprod_twoway' as well a runtime check targetting aarch64.
> >
> > I think vect_dotprod_twoway is not clear - does aarch64 now support
> > all of qi->hi, hi->si, si->di variants while formerly only "fourway"
> > qi->si and hi->di?
> >
> > If it's just hi->si that's now supported please use vect_dotprod_hisi
> > to be specific as to what is required/supported.
>
> At the moment we support only H->S, but other variants are being considered.
> So perhaps vect_dotprod_single_step or something to make it clearer what it
> does but still be general?

But to be useful in the testsuite it has to be specific, not general.

> Thanks,
> Tamar
>
> >
> > Richard.
> >
> > > gcc/testsuite/ChangeLog:
> > >
> > > * lib/target-supports.exp 
> > > (check_effective_target_vect_dotprod_twoway):
> > > New.
> > > * gcc.dg/vect/vect-dotprod-twoway.c: Likewise.
> > > * gcc.target/aarch64/vect-dotprod-twoway.c: Likewise.
> > > ---
> > >  .../gcc.dg/vect/vect-dotprod-twoway.c | 39 +++
> > >  .../gcc.target/aarch64/vect-dotprod-twoway.c  | 65 +++
> > >  gcc/testsuite/lib/target-supports.exp |  8 +++
> > >  3 files changed, 112 insertions(+)
> > >  create mode 100644 gcc/testsuite/gcc.dg/vect/vect-dotprod-twoway.c
> > >  create mode 100644 gcc/testsuite/gcc.target/aarch64/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..ff6a2559dee
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.dg/vect/vect-dotprod-twoway.c
> > > @@ -0,0 +1,39 @@
> > > +/* { dg-do compile } */
> > > +/* { dg-require-effective-target vect_dotprod_twoway } */
> > > +/* 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 s

RE: [PATCH V3 10/10] autovectorizer: Test autovectorization of different dot-prod modes.

2024-08-20 Thread Tamar Christina
> -Original Message-
> From: Richard Biener 
> Sent: Tuesday, August 20, 2024 10:37 AM
> To: Victor Do Nascimento 
> Cc: gcc-patches@gcc.gnu.org; Tamar Christina ;
> claz...@gmail.com; hongtao@intel.com; s...@gcc.gnu.org; bernds_cb1@t-
> online.de; al...@redhat.com; Victor Do Nascimento
> 
> Subject: Re: [PATCH V3 10/10] autovectorizer: Test autovectorization of 
> different
> dot-prod modes.
> 
> On Thu, Aug 15, 2024 at 10:46 AM Victor Do Nascimento
>  wrote:
> >
> > From: Victor Do Nascimento 
> >
> > Given the novel treatment of the dot product optab as a conversion, we
> > are now able to targe 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 was not:
> >
> > 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, gated behind the new check_effective_target
> > `vect_dotprod_twoway' as well a runtime check targetting aarch64.
> 
> I think vect_dotprod_twoway is not clear - does aarch64 now support
> all of qi->hi, hi->si, si->di variants while formerly only "fourway"
> qi->si and hi->di?
> 
> If it's just hi->si that's now supported please use vect_dotprod_hisi
> to be specific as to what is required/supported.

At the moment we support only H->S, but other variants are being considered.
So perhaps vect_dotprod_single_step or something to make it clearer what it
does but still be general?

Thanks,
Tamar

> 
> Richard.
> 
> > gcc/testsuite/ChangeLog:
> >
> > * lib/target-supports.exp 
> > (check_effective_target_vect_dotprod_twoway):
> > New.
> > * gcc.dg/vect/vect-dotprod-twoway.c: Likewise.
> > * gcc.target/aarch64/vect-dotprod-twoway.c: Likewise.
> > ---
> >  .../gcc.dg/vect/vect-dotprod-twoway.c | 39 +++
> >  .../gcc.target/aarch64/vect-dotprod-twoway.c  | 65 +++
> >  gcc/testsuite/lib/target-supports.exp |  8 +++
> >  3 files changed, 112 insertions(+)
> >  create mode 100644 gcc/testsuite/gcc.dg/vect/vect-dotprod-twoway.c
> >  create mode 100644 gcc/testsuite/gcc.target/aarch64/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..ff6a2559dee
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/vect/vect-dotprod-twoway.c
> > @@ -0,0 +1,39 @@
> > +/* { dg-do compile } */
> > +/* { dg-require-effective-target vect_dotprod_twoway } */
> > +/* 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" } } */
> > +/* { dg-final { scan-tree-dump-times "vect_recog_dot_prod_pattern: 
> > detected"
> 4 "vect" } } */
> > diff --git a/gcc/testsuite/gcc.target/aarch64/vect-dotprod-twoway.c
> b/gcc/testsuite/gcc.target/aarch64/vect-dotprod-twoway.c
> > new file mode 100644
> > index 000..bac1e1846da
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/aarch64/vect-dotprod-twoway.c
> > @@ -0,0 +1,65 @

Re: [PATCH V3 10/10] autovectorizer: Test autovectorization of different dot-prod modes.

2024-08-20 Thread Richard Biener
On Thu, Aug 15, 2024 at 10:46 AM Victor Do Nascimento
 wrote:
>
> From: Victor Do Nascimento 
>
> Given the novel treatment of the dot product optab as a conversion, we
> are now able to targe 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 was not:
>
> 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, gated behind the new check_effective_target
> `vect_dotprod_twoway' as well a runtime check targetting aarch64.

I think vect_dotprod_twoway is not clear - does aarch64 now support
all of qi->hi, hi->si, si->di variants while formerly only "fourway"
qi->si and hi->di?

If it's just hi->si that's now supported please use vect_dotprod_hisi
to be specific as to what is required/supported.

Richard.

> gcc/testsuite/ChangeLog:
>
> * lib/target-supports.exp 
> (check_effective_target_vect_dotprod_twoway):
> New.
> * gcc.dg/vect/vect-dotprod-twoway.c: Likewise.
> * gcc.target/aarch64/vect-dotprod-twoway.c: Likewise.
> ---
>  .../gcc.dg/vect/vect-dotprod-twoway.c | 39 +++
>  .../gcc.target/aarch64/vect-dotprod-twoway.c  | 65 +++
>  gcc/testsuite/lib/target-supports.exp |  8 +++
>  3 files changed, 112 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.dg/vect/vect-dotprod-twoway.c
>  create mode 100644 gcc/testsuite/gcc.target/aarch64/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..ff6a2559dee
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/vect/vect-dotprod-twoway.c
> @@ -0,0 +1,39 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target vect_dotprod_twoway } */
> +/* 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" } } */
> +/* { dg-final { scan-tree-dump-times "vect_recog_dot_prod_pattern: detected" 
> 4 "vect" } } */
> diff --git a/gcc/testsuite/gcc.target/aarch64/vect-dotprod-twoway.c 
> b/gcc/testsuite/gcc.target/aarch64/vect-dotprod-twoway.c
> new file mode 100644
> index 000..bac1e1846da
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/vect-dotprod-twoway.c
> @@ -0,0 +1,65 @@
> +/* { dg-do run } */
> +/* { dg-require-effective-target vect_dotprod_twoway } */
> +/* { dg-options "-march=armv8-a+sme2 -static -O3 -ftree-vectorize 
> -fdump-tree-vect-details -save-temps" } */
> +/* Ensure runtime correctness in the autovectorized two-way dot product 
> operations.  */
> +
> +#include 
> +#include 
> +
> +uint32_t
> +udot2 (int n, uint16_t* data)  __arm_streaming
> +{
> +  uint32_t sum = 0;
> +  for (int i=0; i +sum += data[i] * data[i];
> +  }
> +  return sum;
> +}
> +
> +int32_t
> +sdot2 (int n, int16_t* data)  __arm_streaming
> +{
> +  int32_t sum = 0;
> +  for (int i=0; i +sum += data[i] * data[i];
> +  }
> +  return sum;
> +}
> +
> +int
> +main ()
> +{
> +
> +  uint16_t u_input_nil[] = { [0 ... 3] = 0 };
> +  uint16_t u_input_min[] = { [0 ... 3] = 1 };
> +  uint16_t u_input_max[] = { [0 ... 3] = 32767};
> +
> +  uint32_t u_nil_dotprod = udot2 (4, u_input_nil);
> +  uint32_t u_min_dotprod = udot2 (4, u_input_min);
> +  uint32_t u_max_dotprod = udot2 (4, u_input_max);
> +
> +  if (u_nil_dotprod != 0
> +  || u_min_dotprod != 4
> +  || u_max_dotprod != 4294705156)
> +abort ();
> +
> +  int16_t s_input_nil[] = { [0 ... 3] = 0 };
> +  int16_t s_input_min[] = { [0 ... 3] = -23170 };
> +  int16_t s_input_max[] = { [0 ... 3] =  23170 };
> +
> +  int32_t s_nil_dotprod = sdot2 (4, s_input_nil);
> +  int32_t s_min_dotprod = sdot2 (4, s_input_min);
> +  int32_t s_max_dotprod = sdot2 (4, s_input_max);
> +
> +  if (s_nil_dotprod != 0
> +  || s_min_dotprod != 2147395600
> +  || s_max_dotprod != 2147395600)
> +  abort ();
> +
> + 

[PATCH v2] Test: Move pr116278 run test to dg/torture [NFC]

2024-08-18 Thread pan2 . li
From: Pan Li 

Move the run test of pr116278 to dg/torture and leave the risc-v the
asm check under risc-v part.

PR target/116278

gcc/testsuite/ChangeLog:

* gcc.target/riscv/pr116278-run-1.c: Take compile instead of run.
* gcc.target/riscv/pr116278-run-2.c: Ditto.
* gcc.dg/torture/pr116278-run-1.c: New test.
* gcc.dg/torture/pr116278-run-2.c: New test.

Signed-off-by: Pan Li 
---
 gcc/testsuite/gcc.dg/torture/pr116278-run-1.c | 19 +++
 gcc/testsuite/gcc.dg/torture/pr116278-run-2.c | 19 +++
 .../gcc.target/riscv/pr116278-run-1.c |  2 +-
 .../gcc.target/riscv/pr116278-run-2.c |  2 +-
 4 files changed, 40 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr116278-run-1.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr116278-run-2.c

diff --git a/gcc/testsuite/gcc.dg/torture/pr116278-run-1.c 
b/gcc/testsuite/gcc.dg/torture/pr116278-run-1.c
new file mode 100644
index 000..8e07fb6af29
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr116278-run-1.c
@@ -0,0 +1,19 @@
+/* { dg-do run } */
+/* { dg-require-effective-target int32 } */
+/* { dg-options "-O2" } */
+
+#include 
+
+int8_t b[1];
+int8_t *d = b;
+int32_t c;
+
+int main() {
+  b[0] = -40;
+  uint16_t t = (uint16_t)d[0];
+
+  c = (t < 0xFFF6 ? t : 0xFFF6) + 9;
+
+  if (c != 65505)
+__builtin_abort ();
+}
diff --git a/gcc/testsuite/gcc.dg/torture/pr116278-run-2.c 
b/gcc/testsuite/gcc.dg/torture/pr116278-run-2.c
new file mode 100644
index 000..d85e21531e1
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr116278-run-2.c
@@ -0,0 +1,19 @@
+/* { dg-do run } */
+/* { dg-require-effective-target int32 } */
+/* { dg-options "-O2" } */
+
+#include 
+
+int16_t b[1];
+int16_t *d = b;
+int64_t c;
+
+int main() {
+  b[0] = -40;
+  uint32_t t = (uint32_t)d[0];
+
+  c = (t < 0xFFF6u ? t : 0xFFF6u) + 9;
+
+  if (c != 4294967265)
+__builtin_abort ();
+}
diff --git a/gcc/testsuite/gcc.target/riscv/pr116278-run-1.c 
b/gcc/testsuite/gcc.target/riscv/pr116278-run-1.c
index d3812bdcdfb..c758fca7975 100644
--- a/gcc/testsuite/gcc.target/riscv/pr116278-run-1.c
+++ b/gcc/testsuite/gcc.target/riscv/pr116278-run-1.c
@@ -1,4 +1,4 @@
-/* { dg-do run { target { riscv_v } } } */
+/* { dg-do compile } */
 /* { dg-options "-O2 -fdump-rtl-expand-details" } */
 
 #include 
diff --git a/gcc/testsuite/gcc.target/riscv/pr116278-run-2.c 
b/gcc/testsuite/gcc.target/riscv/pr116278-run-2.c
index 669cd4f003f..a4da8a323f0 100644
--- a/gcc/testsuite/gcc.target/riscv/pr116278-run-2.c
+++ b/gcc/testsuite/gcc.target/riscv/pr116278-run-2.c
@@ -1,4 +1,4 @@
-/* { dg-do run { target { riscv_v } } } */
+/* { dg-do compile } */
 /* { dg-options "-O2 -fdump-rtl-expand-details" } */
 
 #include 
-- 
2.43.0



RE: [PATCH v1] Test: Move pr116278 run test to c-torture [NFC]

2024-08-18 Thread Li, Pan2
Sure, will send v2 for this.

Pan

-Original Message-
From: Jeff Law  
Sent: Sunday, August 18, 2024 11:19 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: richard.guent...@gmail.com; juzhe.zh...@rivai.ai; kito.ch...@gmail.com; 
rdapp@gmail.com; s...@gentoo.org
Subject: Re: [PATCH v1] Test: Move pr116278 run test to c-torture [NFC]



On 8/18/24 1:13 AM, pan2...@intel.com wrote:
> From: Pan Li 
> 
> Move the run test of pr116278 to c-torture and leave the risc-v the
> asm check under risc-v part.
> 
>   PR target/116278
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/riscv/pr116278-run-1.c: Take compile instead of
>   run test.
>   * gcc.target/riscv/pr116278-run-2.c: Ditto.
>   * gcc.c-torture/execute/pr116278-run-1.c: New test.
>   * gcc.c-torture/execute/pr116278-run-2.c: New test.
We should be using the dg-torture framework, so the right directory for 
the test is gcc.dg/torture.

I suspect these tests (just based on the constants that appear) may not 
work on the 16 bit integer targets.  So we may need

/* { dg-require-effective-target int32 } */

But I don't mind faulting that in if/when we see the 16bit int targets 
complain.

So OK in the right directory (gcc.dg/torture).

Jeff



Re: [PATCH v1] Test: Move pr116278 run test to c-torture [NFC]

2024-08-18 Thread Jeff Law




On 8/18/24 1:13 AM, pan2...@intel.com wrote:

From: Pan Li 

Move the run test of pr116278 to c-torture and leave the risc-v the
asm check under risc-v part.

PR target/116278

gcc/testsuite/ChangeLog:

* gcc.target/riscv/pr116278-run-1.c: Take compile instead of
run test.
* gcc.target/riscv/pr116278-run-2.c: Ditto.
* gcc.c-torture/execute/pr116278-run-1.c: New test.
* gcc.c-torture/execute/pr116278-run-2.c: New test.
We should be using the dg-torture framework, so the right directory for 
the test is gcc.dg/torture.


I suspect these tests (just based on the constants that appear) may not 
work on the 16 bit integer targets.  So we may need


/* { dg-require-effective-target int32 } */

But I don't mind faulting that in if/when we see the 16bit int targets 
complain.


So OK in the right directory (gcc.dg/torture).

Jeff



[PATCH v1] Test: Move pr116278 run test to c-torture [NFC]

2024-08-18 Thread pan2 . li
From: Pan Li 

Move the run test of pr116278 to c-torture and leave the risc-v the
asm check under risc-v part.

PR target/116278

gcc/testsuite/ChangeLog:

* gcc.target/riscv/pr116278-run-1.c: Take compile instead of
run test.
* gcc.target/riscv/pr116278-run-2.c: Ditto.
* gcc.c-torture/execute/pr116278-run-1.c: New test.
* gcc.c-torture/execute/pr116278-run-2.c: New test.

Signed-off-by: Pan Li 
---
 .../gcc.c-torture/execute/pr116278-run-1.c | 18 ++
 .../gcc.c-torture/execute/pr116278-run-2.c | 18 ++
 .../gcc.target/riscv/pr116278-run-1.c  |  2 +-
 .../gcc.target/riscv/pr116278-run-2.c  |  2 +-
 4 files changed, 38 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.c-torture/execute/pr116278-run-1.c
 create mode 100644 gcc/testsuite/gcc.c-torture/execute/pr116278-run-2.c

diff --git a/gcc/testsuite/gcc.c-torture/execute/pr116278-run-1.c 
b/gcc/testsuite/gcc.c-torture/execute/pr116278-run-1.c
new file mode 100644
index 000..fa5340c9d58
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr116278-run-1.c
@@ -0,0 +1,18 @@
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+#include 
+
+int8_t b[1];
+int8_t *d = b;
+int32_t c;
+
+int main() {
+  b[0] = -40;
+  uint16_t t = (uint16_t)d[0];
+
+  c = (t < 0xFFF6 ? t : 0xFFF6) + 9;
+
+  if (c != 65505)
+__builtin_abort ();
+}
diff --git a/gcc/testsuite/gcc.c-torture/execute/pr116278-run-2.c 
b/gcc/testsuite/gcc.c-torture/execute/pr116278-run-2.c
new file mode 100644
index 000..65439d614a1
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr116278-run-2.c
@@ -0,0 +1,18 @@
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+#include 
+
+int16_t b[1];
+int16_t *d = b;
+int64_t c;
+
+int main() {
+  b[0] = -40;
+  uint32_t t = (uint32_t)d[0];
+
+  c = (t < 0xFFF6u ? t : 0xFFF6u) + 9;
+
+  if (c != 4294967265)
+__builtin_abort ();
+}
diff --git a/gcc/testsuite/gcc.target/riscv/pr116278-run-1.c 
b/gcc/testsuite/gcc.target/riscv/pr116278-run-1.c
index d3812bdcdfb..c758fca7975 100644
--- a/gcc/testsuite/gcc.target/riscv/pr116278-run-1.c
+++ b/gcc/testsuite/gcc.target/riscv/pr116278-run-1.c
@@ -1,4 +1,4 @@
-/* { dg-do run { target { riscv_v } } } */
+/* { dg-do compile } */
 /* { dg-options "-O2 -fdump-rtl-expand-details" } */
 
 #include 
diff --git a/gcc/testsuite/gcc.target/riscv/pr116278-run-2.c 
b/gcc/testsuite/gcc.target/riscv/pr116278-run-2.c
index 669cd4f003f..a4da8a323f0 100644
--- a/gcc/testsuite/gcc.target/riscv/pr116278-run-2.c
+++ b/gcc/testsuite/gcc.target/riscv/pr116278-run-2.c
@@ -1,4 +1,4 @@
-/* { dg-do run { target { riscv_v } } } */
+/* { dg-do compile } */
 /* { dg-options "-O2 -fdump-rtl-expand-details" } */
 
 #include 
-- 
2.43.0



[pushed] c++: fix up cpp23/consteval-if3.C test [PR115583]

2024-08-15 Thread Patrick Palka
Compiling with optimizations is needed to trigger the bug fixed
by r15-2369.

PR c++/115583

gcc/testsuite/ChangeLog:

* g++.dg/cpp23/consteval-if13.C: Compile with -O.
---
 gcc/testsuite/g++.dg/cpp23/consteval-if13.C | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/g++.dg/cpp23/consteval-if13.C 
b/gcc/testsuite/g++.dg/cpp23/consteval-if13.C
index b98bbc33d13..b10ec18b3c6 100644
--- a/gcc/testsuite/g++.dg/cpp23/consteval-if13.C
+++ b/gcc/testsuite/g++.dg/cpp23/consteval-if13.C
@@ -1,5 +1,6 @@
 // PR c++/115583
 // { dg-do compile { target c++23 } }
+// { dg-additional-options -O }
 
 consteval int f(int i) {
   return i;
-- 
2.46.0.164.g477ce5ccd6



[PATCH 5/7] libdiagnostics v3: test suite

2024-08-15 Thread David Malcolm
Changed in v3:
* split out the C and C++ API tests into this patch
* heavily rewritten libdiagnostics.exp; added support for Python tests
* tests updated for API changes, rewritten and extended

gcc/testsuite/ChangeLog:
* libdiagnostics.dg/libdiagnostics.exp: New, adapted from jit.exp.
* libdiagnostics.dg/sarif.py: New.
* libdiagnostics.dg/test-dump.c: New test.
* libdiagnostics.dg/test-error-c.py: New test.
* libdiagnostics.dg/test-error-with-note-c.py: New test.
* libdiagnostics.dg/test-error-with-note.c: New test.
* libdiagnostics.dg/test-error-with-note.cc: New test.
* libdiagnostics.dg/test-error.c: New test.
* libdiagnostics.dg/test-error.cc: New test.
* libdiagnostics.dg/test-fix-it-hint-c.py: New test.
* libdiagnostics.dg/test-fix-it-hint.c: New test.
* libdiagnostics.dg/test-fix-it-hint.cc: New test.
* libdiagnostics.dg/test-helpers++.h: New test.
* libdiagnostics.dg/test-helpers.h: New test.
* libdiagnostics.dg/test-labelled-ranges.c: New test.
* libdiagnostics.dg/test-labelled-ranges.cc: New test.
* libdiagnostics.dg/test-labelled-ranges.py: New test.
* libdiagnostics.dg/test-logical-location-c.py: New test.
* libdiagnostics.dg/test-logical-location.c: New test.
* libdiagnostics.dg/test-metadata-c.py: New test.
* libdiagnostics.dg/test-metadata.c: New test.
* libdiagnostics.dg/test-multiple-lines-c.py: New test.
* libdiagnostics.dg/test-multiple-lines.c: New test.
* libdiagnostics.dg/test-no-column-c.py: New test.
* libdiagnostics.dg/test-no-column.c: New test.
* libdiagnostics.dg/test-no-diagnostics-c.py: New test.
* libdiagnostics.dg/test-no-diagnostics.c: New test.
* libdiagnostics.dg/test-note-with-fix-it-hint-c.py: New test.
* libdiagnostics.dg/test-note-with-fix-it-hint.c: New test.
* libdiagnostics.dg/test-text-sink-options.c: New test.
* libdiagnostics.dg/test-warning-c.py: New test.
* libdiagnostics.dg/test-warning-with-path-c.py: New test.
* libdiagnostics.dg/test-warning-with-path.c: New test.
* libdiagnostics.dg/test-warning.c: New test.
* libdiagnostics.dg/test-write-sarif-to-file-c.py: New test.
* libdiagnostics.dg/test-write-sarif-to-file.c: New test.
* libdiagnostics.dg/test-write-text-to-file.c: New test.

Signed-off-by: David Malcolm 
---
 .../libdiagnostics.dg/libdiagnostics.exp  | 296 ++
 gcc/testsuite/libdiagnostics.dg/sarif.py  |  23 ++
 gcc/testsuite/libdiagnostics.dg/test-dump.c   |  69 
 .../libdiagnostics.dg/test-error-c.py |  54 
 .../test-error-with-note-c.py |  50 +++
 .../libdiagnostics.dg/test-error-with-note.c  |  74 +
 .../libdiagnostics.dg/test-error-with-note.cc |  55 
 gcc/testsuite/libdiagnostics.dg/test-error.c  |  59 
 gcc/testsuite/libdiagnostics.dg/test-error.cc |  47 +++
 .../libdiagnostics.dg/test-fix-it-hint-c.py   |  46 +++
 .../libdiagnostics.dg/test-fix-it-hint.c  |  81 +
 .../libdiagnostics.dg/test-fix-it-hint.cc |  74 +
 .../libdiagnostics.dg/test-helpers++.h|  28 ++
 .../libdiagnostics.dg/test-helpers.h  |  72 +
 .../libdiagnostics.dg/test-labelled-ranges.c  |  69 
 .../libdiagnostics.dg/test-labelled-ranges.cc |  64 
 .../libdiagnostics.dg/test-labelled-ranges.py |  48 +++
 .../test-logical-location-c.py|  37 +++
 .../libdiagnostics.dg/test-logical-location.c |  79 +
 .../libdiagnostics.dg/test-metadata-c.py  |  45 +++
 .../libdiagnostics.dg/test-metadata.c |  61 
 .../test-multiple-lines-c.py  |  83 +
 .../libdiagnostics.dg/test-multiple-lines.c   |  76 +
 .../libdiagnostics.dg/test-no-column-c.py |  35 +++
 .../libdiagnostics.dg/test-no-column.c|  52 +++
 .../test-no-diagnostics-c.py  |  42 +++
 .../libdiagnostics.dg/test-no-diagnostics.c   |  25 ++
 .../test-note-with-fix-it-hint-c.py   |  54 
 .../test-note-with-fix-it-hint.c  |  69 
 .../test-text-sink-options.c  |  59 
 .../libdiagnostics.dg/test-warning-c.py   |  54 
 .../test-warning-with-path-c.py   | 108 +++
 .../test-warning-with-path.c  | 125 
 .../libdiagnostics.dg/test-warning.c  |  65 
 .../test-write-sarif-to-file-c.py |  55 
 .../test-write-sarif-to-file.c|  55 
 .../test-write-text-to-file.c |  47 +++
 37 files changed, 2435 insertions(+)
 create mode 100644 gcc/testsuite/libdiagnostics.dg/libdiagnostics.exp
 create mode 100644 gcc/testsuite/libdiagnostics.dg/sarif.py
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-dump.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-error-c.py
 create mode 100644 gcc/testsuite

[PATCH 4/7] testsuite: move dg-test cleanup code from gcc-dg.exp to its own file

2024-08-15 Thread David Malcolm
I need to use this cleanup logic for the testsuite for libdiagnostics
where it's too awkward to directly use gcc-dg.exp itself.

No functional change intended.

gcc/testsuite/ChangeLog:
* lib/dg-test-cleanup.exp: New file, from material moved from
lib/gcc-dg.exp.
* lib/gcc-dg.exp: Add load_lib of dg-test-cleanup.exp.
(cleanup-after-saved-dg-test): Move to lib/dg-test-cleanup.exp.
    (dg-test): Likewise for override.
(initialize_prune_notes): Likewise.

libatomic/ChangeLog:
* testsuite/lib/libatomic.exp: Add
"load_gcc_lib dg-test-cleanup.exp".

libgomp/ChangeLog:
* testsuite/lib/libgomp.exp: Add
"load_gcc_lib dg-test-cleanup.exp".
libitm/ChangeLog:
* testsuite/lib/libitm.exp: Add
"load_gcc_lib dg-test-cleanup.exp".

libphobos/ChangeLog:
* testsuite/lib/libphobos-dg.exp: Add
"load_gcc_lib dg-test-cleanup.exp".

libstdc++-v3/ChangeLog:
* testsuite/lib/libstdc++.exp: Add
"load_gcc_lib dg-test-cleanup.exp".

libvtv/ChangeLog:
* testsuite/lib/libvtv.exp: Add
"load_gcc_lib dg-test-cleanup.exp".

Signed-off-by: David Malcolm 
---
 gcc/testsuite/lib/dg-test-cleanup.exp| 116 +++
 gcc/testsuite/lib/gcc-dg.exp | 102 +---
 libatomic/testsuite/lib/libatomic.exp|   1 +
 libgomp/testsuite/lib/libgomp.exp|   1 +
 libitm/testsuite/lib/libitm.exp  |   1 +
 libphobos/testsuite/lib/libphobos-dg.exp |   1 +
 libstdc++-v3/testsuite/lib/libstdc++.exp |   1 +
 libvtv/testsuite/lib/libvtv.exp  |   1 +
 8 files changed, 123 insertions(+), 101 deletions(-)
 create mode 100644 gcc/testsuite/lib/dg-test-cleanup.exp

diff --git a/gcc/testsuite/lib/dg-test-cleanup.exp 
b/gcc/testsuite/lib/dg-test-cleanup.exp
new file mode 100644
index 0000..b2b8507a0320
--- /dev/null
+++ b/gcc/testsuite/lib/dg-test-cleanup.exp
@@ -0,0 +1,116 @@
+#   Copyright (C) 1997-2024 Free Software Foundation, Inc.
+
+# This program 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 of the License, or
+# (at your option) any later version.
+#
+# This program 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 GCC; see the file COPYING3.  If not see
+# <http://www.gnu.org/licenses/>.
+
+# We need to make sure that additional_* are cleared out after every
+# test.  It is not enough to clear them out *before* the next test run
+# because gcc-target-compile gets run directly from some .exp files
+# (outside of any test).  (Those uses should eventually be eliminated.)
+
+# Because the DG framework doesn't provide a hook that is run at the
+# end of a test, we must replace dg-test with a wrapper.
+
+if { [info procs saved-dg-test] == [list] } {
+rename dg-test saved-dg-test
+
+# Helper function for cleanups that should happen after the call
+# to the real dg-test, whether or not it returns normally, or
+# fails with an error.
+proc cleanup-after-saved-dg-test { } {
+   global additional_files
+   global additional_sources
+   global additional_sources_used
+   global additional_prunes
+   global compiler_conditional_xfail_data
+   global shouldfail
+   global expect_ice
+   global testname_with_flags
+   global set_target_env_var
+   global set_compiler_env_var
+   global saved_compiler_env_var
+   global keep_saved_temps_suffixes
+   global nn_line_numbers_enabled
+   global multiline_expected_outputs
+   global freeform_regexps
+   global save_linenr_varnames
+
+   set additional_files ""
+   set additional_sources ""
+   set additional_sources_used ""
+   set additional_prunes ""
+   set shouldfail 0
+   set expect_ice 0
+   if [info exists set_target_env_var] {
+   unset set_target_env_var
+   }
+   if [info exists set_compiler_env_var] {
+   restore-compiler-env-var
+   unset set_compiler_env_var
+   unset saved_compiler_env_var
+   }
+   if [info exists keep_saved_temps_suffixes] {
+   unset keep_saved_temps_suffixes
+   }
+   unset_timeout_vars
+   if [info exists compiler_conditional_xfail_data] {
+   unset compiler_conditional_xfail_data
+   }
+   if [info exists testname_with_flags] {
+   unset testname_with_flags
+   }
+   set nn_line_numbers_enabled 0
+   set multiline_expected_outputs []
+   set freefor

[PATCH V3 10/10] autovectorizer: Test autovectorization of different dot-prod modes.

2024-08-15 Thread Victor Do Nascimento
From: Victor Do Nascimento 

Given the novel treatment of the dot product optab as a conversion, we
are now able to targe 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
+#include 
+
+uint32_t
+udot2 (int n, uint16_t* data)  __arm_streaming
+{
+  uint32_t sum = 0;
+  for (int i=0; i

Re: [PATCH] Restrict pr116202-run-1.c test to riscv_v target

2024-08-13 Thread Jeff Law




On 8/12/24 2:31 PM, Mark Wielaard wrote:

The testcase uses -march=rv64gcv and dg-do run, so should be
restricted to a riscv_v target.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr116202-run-1.c (dg-do run):
Add target riscv_v.

OK
jeff



Re: [PATCH] testsuite: Avoid running neon test on Cortex-M55

2024-08-13 Thread Andre Vieira (lists)

I'm not a maintainer but I'd argue the entire test is bogus.

The error reporting in this area seems to be somewhat fragile, if you 
compile it with '-march=armv7-a -mfloat-abi=soft', you also don't get 
the error this is testing for.  I'd argue this kind of user friendly 
error message should just go through the #include  and if a 
user is using __builtin's directly like this then they better know what 
they are doing and so 'useful' errors are probably less of a priority.


In case you are wondering: no we don't offer nice errors when '#include 
' is compiled with a MVE enabled combination of march/mcpu, 
but the errors are somewhat friendlier if you compile a '#include 
' with a NEON enabled command line.


Anyway, lets see what Richard says.

On 13/08/2024 12:15, Torbjörn SVENSSON wrote:

Ok for trunk and releases/gcc-14?

--

Cortex-M55 supports VFP, but does not contain neon, so the test is
invalid in this context.

Without this patch, the following error can be seen in the logs:

.../attr-neon-builtin-fail2.c: In function 'foo':
.../attr-neon-builtin-fail2.c:13:27: error: implicit declaration of function 
'__builtin_neon_vaddlsv8qi'; did you mean '__builtin_neon_vabshf'? 
[-Wimplicit-function-declaration]
.../attr-neon-builtin-fail2.c:13:3: error: cannot convert a value of type 'int' 
to vector type '__simd128_int16_t' which has different size

gcc/testsuite/ChangeLog:

* attr-neon-builtin-fail2.c: Check ET neon.

Signed-off-by: Torbjörn SVENSSON 
Co-authored-by: Yvan ROUX 
---
  gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail2.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail2.c 
b/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail2.c
index 9cb5a2ebb90..8942b0d68f1 100644
--- a/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail2.c
+++ b/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail2.c
@@ -1,6 +1,7 @@
  /* Check that calling a neon builtin from a function compiled with vfp fails. 
 */
  /* { dg-do compile } */
  /* { dg-require-effective-target arm_vfp_ok } */
+/* { dg-require-effective-target arm_neon_ok } */
  /* { dg-options "-O2" } */
  /* { dg-add-options arm_vfp } */
  


[PATCH V2 10/10] autovectorizer: Test autovectorization of different dot-prod modes.

2024-08-13 Thread Victor Do Nascimento
From: Victor Do Nascimento 

Given the novel treatment of the dot product optab as a conversion, we
are now able to targe 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
+#include 
+
+uint32_t
+udot2 (int n, uint16_t* data)  __arm_streaming
+{
+  uint32_t sum = 0;
+  for (int i=0; i

[PATCH] testsuite: Avoid running neon test on Cortex-M55

2024-08-13 Thread Torbjörn SVENSSON
Ok for trunk and releases/gcc-14?

--

Cortex-M55 supports VFP, but does not contain neon, so the test is
invalid in this context.

Without this patch, the following error can be seen in the logs:

.../attr-neon-builtin-fail2.c: In function 'foo':
.../attr-neon-builtin-fail2.c:13:27: error: implicit declaration of function 
'__builtin_neon_vaddlsv8qi'; did you mean '__builtin_neon_vabshf'? 
[-Wimplicit-function-declaration]
.../attr-neon-builtin-fail2.c:13:3: error: cannot convert a value of type 'int' 
to vector type '__simd128_int16_t' which has different size

gcc/testsuite/ChangeLog:

* attr-neon-builtin-fail2.c: Check ET neon.

Signed-off-by: Torbjörn SVENSSON 
Co-authored-by: Yvan ROUX 
---
 gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail2.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail2.c 
b/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail2.c
index 9cb5a2ebb90..8942b0d68f1 100644
--- a/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail2.c
+++ b/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail2.c
@@ -1,6 +1,7 @@
 /* Check that calling a neon builtin from a function compiled with vfp fails.  
*/
 /* { dg-do compile } */
 /* { dg-require-effective-target arm_vfp_ok } */
+/* { dg-require-effective-target arm_neon_ok } */
 /* { dg-options "-O2" } */
 /* { dg-add-options arm_vfp } */
 
-- 
2.25.1



[PATCH] Restrict pr116202-run-1.c test to riscv_v target

2024-08-12 Thread Mark Wielaard
The testcase uses -march=rv64gcv and dg-do run, so should be
restricted to a riscv_v target.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr116202-run-1.c (dg-do run):
Add target riscv_v.
---
 gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c
index 02814183dbb9..979989f8a857 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c
@@ -1,4 +1,4 @@
-/* { dg-do run } */
+/* { dg-do run { target { riscv_v } } } */
 /* { dg-options "-O3 -march=rv64gcv_zvl256b -mabi=lp64d 
-fdump-rtl-expand-details" } */
 
 int b[24];
-- 
2.45.2



Re: [Committed] RISC-V: Fix missing abi arg in test

2024-08-12 Thread Edwin Lu

Thanks!

Edwin

On 8/8/2024 12:24 AM, Robin Dapp wrote:

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c
index d150f20b5d9..02814183dbb 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c
@@ -1,5 +1,5 @@
  /* { dg-do run } */
-/* { dg-options "-O3 -march=rv64gcv_zvl256b -fdump-rtl-expand-details" } */
+/* { dg-options "-O3 -march=rv64gcv_zvl256b -mabi=lp64d 
-fdump-rtl-expand-details" } */
  
  int b[24];

  _Bool c[24];

OK.

We really want to have an march imply an mabi, especially if there's no other
choice anyway.



[PING] [PATCH] PR116080: Fix test suite checks for musttail

2024-08-12 Thread Andi Kleen
Andi Kleen  writes:

I wanted to ping this patch. It fixes test suite noise on various
targets.

https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658602.html


> From: Andi Kleen 
>
> This is a new attempt to fix PR116080. The previous try was reverted
> because it just broke a bunch of tests, hiding the problem.
>
> - musttail behaves differently than tailcall at -O0. Some of the test
> run at -O0, so add separate effective target tests for musttail.
> - New effective target tests need to use unique file names
> to make dejagnu caching work
> - Change the tests to use new targets
> - Add a external_musttail test to check for target's ability
> to do tail calls between translation units. This covers some powerpc
> ABIs.
>
> gcc/testsuite/ChangeLog:
>
>   PR testsuite/116080
>   * c-c++-common/musttail1.c: Use musttail target.
>   * c-c++-common/musttail12.c: Use struct_musttail target.
>   * c-c++-common/musttail2.c: Use musttail target.
>   * c-c++-common/musttail3.c: Likewise.
>   * c-c++-common/musttail4.c: Likewise.
>   * c-c++-common/musttail7.c: Likewise.
>   * c-c++-common/musttail8.c: Likewise.
>   * g++.dg/musttail10.C: Likewise. Replace powerpc checks with
>   external_musttail.
>   * g++.dg/musttail11.C: Use musttail target.
>   * g++.dg/musttail6.C: Use musttail target. Replace powerpc
>   checks with external_musttail.
>   * g++.dg/musttail9.C: Use musttail target.
>   * lib/target-supports.exp: Add musttail, struct_musttail,
>   external_musttail targets. Remove optimization for musttail.
>   Use unique file names for musttail.
> ---
>  gcc/testsuite/c-c++-common/musttail1.c  |  2 +-
>  gcc/testsuite/c-c++-common/musttail12.c |  2 +-
>  gcc/testsuite/c-c++-common/musttail2.c  |  2 +-
>  gcc/testsuite/c-c++-common/musttail3.c  |  2 +-
>  gcc/testsuite/c-c++-common/musttail4.c  |  2 +-
>  gcc/testsuite/c-c++-common/musttail7.c  |  2 +-
>  gcc/testsuite/c-c++-common/musttail8.c  |  2 +-
>  gcc/testsuite/g++.dg/musttail10.C   |  4 ++--
>  gcc/testsuite/g++.dg/musttail11.C   |  2 +-
>  gcc/testsuite/g++.dg/musttail6.C|  4 ++--
>  gcc/testsuite/g++.dg/musttail9.C|  2 +-
>  gcc/testsuite/lib/target-supports.exp   | 30 -
>  12 files changed, 37 insertions(+), 19 deletions(-)
>
> diff --git a/gcc/testsuite/c-c++-common/musttail1.c 
> b/gcc/testsuite/c-c++-common/musttail1.c
> index 74efcc2a0bc6..51549672e02a 100644
> --- a/gcc/testsuite/c-c++-common/musttail1.c
> +++ b/gcc/testsuite/c-c++-common/musttail1.c
> @@ -1,4 +1,4 @@
> -/* { dg-do compile { target { tail_call && { c || c++11 } } } } */
> +/* { dg-do compile { target { musttail && { c || c++11 } } } } */
>  /* { dg-additional-options "-fdelayed-branch" { target sparc*-*-* } } */
>  
>  int __attribute__((noinline,noclone,noipa))
> diff --git a/gcc/testsuite/c-c++-common/musttail12.c 
> b/gcc/testsuite/c-c++-common/musttail12.c
> index 4140bcd00950..475afc5af3f3 100644
> --- a/gcc/testsuite/c-c++-common/musttail12.c
> +++ b/gcc/testsuite/c-c++-common/musttail12.c
> @@ -1,4 +1,4 @@
> -/* { dg-do compile { target { struct_tail_call && { c || c++11 } } } } */
> +/* { dg-do compile { target { struct_musttail && { c || c++11 } } } } */
>  /* { dg-additional-options "-fdelayed-branch" { target sparc*-*-* } } */
>  
>  struct str
> diff --git a/gcc/testsuite/c-c++-common/musttail2.c 
> b/gcc/testsuite/c-c++-common/musttail2.c
> index 86f2c3d77404..1970c4edd670 100644
> --- a/gcc/testsuite/c-c++-common/musttail2.c
> +++ b/gcc/testsuite/c-c++-common/musttail2.c
> @@ -1,4 +1,4 @@
> -/* { dg-do compile { target { tail_call && { c || c++11 } } } } */
> +/* { dg-do compile { target { musttail && { c || c++11 } } } } */
>  
>  struct box { char field[256]; int i; };
>  
> diff --git a/gcc/testsuite/c-c++-common/musttail3.c 
> b/gcc/testsuite/c-c++-common/musttail3.c
> index ea9589c59ef2..7499fd6460b4 100644
> --- a/gcc/testsuite/c-c++-common/musttail3.c
> +++ b/gcc/testsuite/c-c++-common/musttail3.c
> @@ -1,4 +1,4 @@
> -/* { dg-do compile { target { tail_call && { c || c++11 } } } } */
> +/* { dg-do compile { target { struct_musttail && { c || c++11 } } } } */
>  
>  extern int foo2 (int x, ...);
>  
> diff --git a/gcc/testsuite/c-c++-common/musttail4.c 
> b/gcc/testsuite/c-c++-common/musttail4.c
> index 23f4b5e1cd68..bd6effa4b931 100644
> --- a/gcc/testsuite/c-c++-common/musttail4.c
> +++ b/gcc/testsuite/c-c++-common/musttail4.c
> @@ -1,4 +1,4 @@
> -/* { dg-do compile { target { tail_call && { c || c++11 } } } } */
> +/* { dg-do compile { target {

Re: Ping^6: [PATCH 0/2] Fix two test failures with --enable-default-pie [PR70150]

2024-08-10 Thread Xi Ruoyao
On Wed, 2024-07-31 at 21:58 +, Joseph Myers wrote:
> On Mon, 22 Jul 2024, Xi Ruoyao wrote:
> 
> > 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(-)
> 
> OK in the absence of i386 maintainer objections within 72 hours.

Pushed to trunk.  Will wait for another 3-work-day period before
backporting to 14.

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University


  1   2   3   4   5   6   7   8   9   10   >