Re: [PATCH v2] C, ObjC: Add -Wunterminated-string-initialization
Hi David,
Sorry for the half-year delay! I have some update. :)
On Fri, Mar 24, 2023 at 10:53:22AM -0400, David Malcolm wrote:
> On Fri, 2023-03-24 at 14:39 +0100, Alejandro Colomar via Gcc-patches
> wrote:
> > Warn about the following:
> >
> > char s[3] = "foo";
> >
> > Initializing a char array with a string literal of the same length as
> > the size of the array is usually a mistake. Rarely is the case where
> > one wants to create a non-terminated character sequence from a string
> > literal.
> >
> > In some cases, for writing faster code, one may want to use arrays
> > instead of pointers, since that removes the need for storing an array
> > of
> > pointers apart from the strings themselves.
> >
> > char *log_levels[] = { "info", "warning", "err" };
> > vs.
> > char log_levels[][7] = { "info", "warning", "err" };
> >
> > This forces the programmer to specify a size, which might change if a
> > new entry is later added. Having no way to enforce null termination
> > is
> > very dangerous, however, so it is useful to have a warning for this,
> > so
> > that the compiler can make sure that the programmer didn't make any
> > mistakes. This warning catches the bug above, so that the programmer
> > will be able to fix it and write:
> >
> > char log_levels[][8] = { "info", "warning", "err" };
> >
> > This warning already existed as part of -Wc++-compat, but this patch
> > allows enabling it separately. It is also included in -Wextra, since
> > it may not always be desired (when unterminated character sequences
> > are
> > wanted), but it's likely to be desired in most cases.
> >
> > Link:
> >
> > Link:
> >
> > Link:
> > > 3...@gmail.com/T/>
> > Acked-by: Doug McIlroy
> > Cc: "G. Branden Robinson"
> > Cc: Ralph Corderoy
> > Cc: Dave Kemper
> > Cc: Larry McVoy
> > Cc: Andrew Pinski
> > Cc: Jonathan Wakely
> > Cc: Andrew Clayton
> > Cc: Martin Uecker
> > Signed-off-by: Alejandro Colomar
> > ---
> >
> > Hi,
>
> Hi Alex, thanks for the patch.
>
> >
> > I sent v1 to the wrong list. This time I've made sure to write to
> > gcc-patches@.
>
> Note that right now we're deep in bug-fixing/stabilization for GCC 13
> (and trunk is still tracking that effort), so your patch might be more
> suitable for GCC 14.
>
> >
> > v2 adds some draft of a test, as suggested by Martin. However, I
> > don't
> > know yet how to write those, so the test is just a draft. But I did
> > test the feature, by compiling GCC and compiling some small program
> > with
> > it.
>
> Unfortunately the answer to the question "how do I run just one
> testcase in GCC's testsuite" is rather non-trivial; FWIW I've written
> up some notes on working with the GCC testsuite here:
> https://gcc-newbies-guide.readthedocs.io/en/latest/working-with-the-testsuite.html
>
> Hope this is helpful
> Dave
>
>
> [...snip...]
>
I ran the tests, and get some unexpected failure. I used dg-warning,
but maybe I used it wrong? Here's the output:
```
output is:
/home/alx/src/gnu/gcc/wustr/gcc/testsuite/gcc.dg/Wunterminated-string-initialization.c:5:14:
warning: initializer-string for array of 'char' is too long
[-Wunterminated-string-initi
alization]
FAIL: gcc.dg/Wunterminated-string-initialization.c (test for warnings, line 5)
```
And here's the test:
```
/* { dg-do compile } */
/* { dg-options "-Wunterminated-string-initialization" } */
char a1[] = "a";
char a2[1] = "a"; /* { dg-warning "unterminated char sequence" } */
char a3[2] = "a";
```
Why isn't it expecting the warning?
Thanks,
Alex
signature.asc
Description: PGP signature
Re: [PATCH] Cleanup: Replace UNSPEC_COPYSIGN with copysign RTL
On Fri, Sep 29, 2023 at 02:09:12PM -0400, Michael Meissner wrote: > * config/rs6000/rs6000.md (UNSPEC_COPYSIGN): Delete. > (copysign3_fcpsg): Use copysign RTL instead of UNSPEC. (typo, it is _fcpsgn) Nice to see unnecessary unspecs going away :-) Segher
[Committed] RISC-V: Use safe_grow_cleared for vector info [PR111469]
Committed. Thanks Juzhe!
I had to adjust the changelog's PR formatting to get the pre-commit
hooks to accept it.
Here's the committed patch:
From f446cf5d58568e406cc81f434a63b3045942e9a9 Mon Sep 17 00:00:00 2001
From: Patrick O'Neill
Date: Sat, 30 Sep 2023 15:50:11 -0700
Subject: [PATCH] RISC-V: Use safe_grow_cleared for vector info [PR111649]
Resolves a riscv*-*-* bootstrap failure due to a newly-turned-on assert.
2023-09-30 Jakub Jelinek
gcc/ChangeLog:
PR target/111649
* config/riscv/riscv-vsetvl.cc
(vector_infos_manager::vector_infos_manager):
Replace safe_grow with safe_grow_cleared.
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649
Fix authored by Jakub Jelinek.
Tested for regressions using multilib riscv glibc rv32gcv, rv64gcv
---
gcc/config/riscv/riscv-vsetvl.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/config/riscv/riscv-vsetvl.cc
b/gcc/config/riscv/riscv-vsetvl.cc
index af8c31d873c..4b06d93e7f9 100644
--- a/gcc/config/riscv/riscv-vsetvl.cc
+++ b/gcc/config/riscv/riscv-vsetvl.cc
@@ -2417,8 +2417,8 @@ vector_infos_manager::vector_infos_manager ()
vector_antin = nullptr;
vector_antout = nullptr;
vector_earliest = nullptr;
- vector_insn_infos.safe_grow (get_max_uid ());
- vector_block_infos.safe_grow (last_basic_block_for_fn (cfun));
+ vector_insn_infos.safe_grow_cleared (get_max_uid ());
+ vector_block_infos.safe_grow_cleared (last_basic_block_for_fn (cfun));
if (!optimize)
{
basic_block cfg_bb;
--
2.34.1
On 9/30/23 16:03, 钟居哲 wrote:
LGTM.
juzhe.zh...@rivai.ai
*From:* Patrick O'Neill
*Date:* 2023-10-01 07:00
*To:* gcc-patches ; juzhe.zhong
*CC:* jakub ; pinskia
; JeffreyALaw
; gnu-toolchain
; Patrick O'Neill
*Subject:* [PATCH] RISC-V: Use safe_grow_cleared for vector info
[PR111469]
Resolves a riscv*-*-* bootstrap failure due to a newly-turned-on
assert.
2023-09-30 Jakub Jelinek
PR target/111649
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc
(vector_infos_manager::vector_infos_manager):
Replace safe_grow with safe_grow_cleared.
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649
Fix authored by Jakub Jelinek.
Tested for regressions using multilib riscv glibc rv32gcv, rv64gcv
---
gcc/config/riscv/riscv-vsetvl.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/config/riscv/riscv-vsetvl.cc
b/gcc/config/riscv/riscv-vsetvl.cc
index af8c31d873c..4b06d93e7f9 100644
--- a/gcc/config/riscv/riscv-vsetvl.cc
+++ b/gcc/config/riscv/riscv-vsetvl.cc
@@ -2417,8 +2417,8 @@ vector_infos_manager::vector_infos_manager ()
vector_antin = nullptr;
vector_antout = nullptr;
vector_earliest = nullptr;
- vector_insn_infos.safe_grow (get_max_uid ());
- vector_block_infos.safe_grow (last_basic_block_for_fn (cfun));
+ vector_insn_infos.safe_grow_cleared (get_max_uid ());
+ vector_block_infos.safe_grow_cleared (last_basic_block_for_fn
(cfun));
if (!optimize)
{
basic_block cfg_bb;
--
2.34.1
Re: [PATCH] RISC-V: Use safe_grow_cleared for vector info [PR111469]
LGTM.
juzhe.zh...@rivai.ai
From: Patrick O'Neill
Date: 2023-10-01 07:00
To: gcc-patches; juzhe.zhong
CC: jakub; pinskia; JeffreyALaw; gnu-toolchain; Patrick O'Neill
Subject: [PATCH] RISC-V: Use safe_grow_cleared for vector info [PR111469]
Resolves a riscv*-*-* bootstrap failure due to a newly-turned-on assert.
2023-09-30 Jakub Jelinek
PR target/111649
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (vector_infos_manager::vector_infos_manager):
Replace safe_grow with safe_grow_cleared.
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649
Fix authored by Jakub Jelinek.
Tested for regressions using multilib riscv glibc rv32gcv, rv64gcv
---
gcc/config/riscv/riscv-vsetvl.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/config/riscv/riscv-vsetvl.cc b/gcc/config/riscv/riscv-vsetvl.cc
index af8c31d873c..4b06d93e7f9 100644
--- a/gcc/config/riscv/riscv-vsetvl.cc
+++ b/gcc/config/riscv/riscv-vsetvl.cc
@@ -2417,8 +2417,8 @@ vector_infos_manager::vector_infos_manager ()
vector_antin = nullptr;
vector_antout = nullptr;
vector_earliest = nullptr;
- vector_insn_infos.safe_grow (get_max_uid ());
- vector_block_infos.safe_grow (last_basic_block_for_fn (cfun));
+ vector_insn_infos.safe_grow_cleared (get_max_uid ());
+ vector_block_infos.safe_grow_cleared (last_basic_block_for_fn (cfun));
if (!optimize)
{
basic_block cfg_bb;
--
2.34.1
[PATCH] RISC-V: Use safe_grow_cleared for vector info [PR111469]
Resolves a riscv*-*-* bootstrap failure due to a newly-turned-on assert.
2023-09-30 Jakub Jelinek
PR target/111649
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc
(vector_infos_manager::vector_infos_manager):
Replace safe_grow with safe_grow_cleared.
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649
Fix authored by Jakub Jelinek.
Tested for regressions using multilib riscv glibc rv32gcv, rv64gcv
---
gcc/config/riscv/riscv-vsetvl.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/config/riscv/riscv-vsetvl.cc b/gcc/config/riscv/riscv-vsetvl.cc
index af8c31d873c..4b06d93e7f9 100644
--- a/gcc/config/riscv/riscv-vsetvl.cc
+++ b/gcc/config/riscv/riscv-vsetvl.cc
@@ -2417,8 +2417,8 @@ vector_infos_manager::vector_infos_manager ()
vector_antin = nullptr;
vector_antout = nullptr;
vector_earliest = nullptr;
- vector_insn_infos.safe_grow (get_max_uid ());
- vector_block_infos.safe_grow (last_basic_block_for_fn (cfun));
+ vector_insn_infos.safe_grow_cleared (get_max_uid ());
+ vector_block_infos.safe_grow_cleared (last_basic_block_for_fn (cfun));
if (!optimize)
{
basic_block cfg_bb;
--
2.34.1
Re: Re: [PATCH] RISC-V: Enable RVV scalable vectorization by default[PR111311]
Trunk GCC still has some bugs need to be addressed. A few issues are middld-end related to COND_LEN_xxx (Robin has sent a patch but waiting for Richard's review). A few issues are VSETVL PASS (Lehua is working on refactoring and cleanup up the VSETVL PASS to address all potential issues of VSETVL PASS). Li Pan @intel plans to start to run various benchmark (Eigen,mlpef, SPEC,...etc) to fix issues. Also, we are planning to enable full coverage of ”vect.exp“ to see whether there are still some other bugs. We are on long vacation (Chinese) and we will start to do after the vacation. Thanks. juzhe.zh...@rivai.ai From: Vineet Gupta Date: 2023-10-01 06:42 To: Jeff Law; juzhe.zh...@rivai.ai; gcc-patches CC: Kito.cheng; kito.cheng Subject: Re: [PATCH] RISC-V: Enable RVV scalable vectorization by default[PR111311] On 9/11/23 06:12, Jeff Law via Gcc-patches wrote: > > > On 9/10/23 21:42, juzhe.zh...@rivai.ai wrote: >> Ping this patch. >> >> I think it's time to enable scalable vectorization by default and do >> the whole regression every time (except vect.exp that we didn't >> enable yet) >> >> Update current FAILs status: >> >> Real FAILS (ICE and execution FAIL): >> >> FAIL: gcc.dg/pr70252.c (internal compiler error: in >> gimple_expand_vec_cond_expr, at gimple-isel.cc:284) >> FAIL: gcc.dg/pr70252.c (test for excess errors) >> FAIL: gcc.dg/pr92301.c execution test >> >> Robin is working on these 3 issues and will be solved soon. >> >> FAIL: g++.dg/torture/vshuf-v4df.C -O2 -flto -fno-use-linker-plugin >> -flto-partition=none (internal compiler error: in as_a, at >> machmode.h:381) >> FAIL: g++.dg/torture/vshuf-v4df.C -O2 -flto -fno-use-linker-plugin >> -flto-partition=none (test for excess errors) >> FAIL: g++.dg/torture/vshuf-v4df.C -O2 -flto -fuse-linker-plugin >> -fno-fat-lto-objects (internal compiler error: in as_a, at >> machmode.h:381) >> FAIL: g++.dg/torture/vshuf-v4df.C -O2 -flto -fuse-linker-plugin >> -fno-fat-lto-objects (test for excess errors) >> >> This is a long time known issue I have mentioned many times, we need >> help for LTO since it's caused by mode bits extension. >> >> The rest bogus FAILs: >> FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "Not unrolling >> loop, doesn't roll" >> FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "likely upper >> bound: 6" >> FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "realistic bound: -1" >> FAIL: gcc.dg/var-expand1.c scan-rtl-dump loop2_unroll "Expanding >> Accumulator" >> FAIL: gcc.dg/tree-ssa/cunroll-16.c scan-tree-dump cunroll "optimized: >> loop with [0-9]+ iterations completely unrolled" >> FAIL: gcc.dg/tree-ssa/cunroll-16.c scan-tree-dump-not optimized "foo" >> FAIL: gcc.dg/tree-ssa/forwprop-40.c scan-tree-dump-times optimized >> "BIT_FIELD_REF" 0 >> FAIL: gcc.dg/tree-ssa/forwprop-40.c scan-tree-dump-times optimized >> "BIT_INSERT_EXPR" 0 >> FAIL: gcc.dg/tree-ssa/forwprop-41.c scan-tree-dump-times optimized >> "BIT_FIELD_REF" 0 >> FAIL: gcc.dg/tree-ssa/forwprop-41.c scan-tree-dump-times optimized >> "BIT_INSERT_EXPR" 1 >> FAIL: gcc.dg/tree-ssa/gen-vect-11b.c scan-tree-dump-times vect >> "vectorized 0 loops" 1 >> FAIL: gcc.dg/tree-ssa/gen-vect-11c.c scan-tree-dump-times vect >> "vectorized 0 loops" 1 >> FAIL: gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect >> "Alignment of access forced using peeling" 1 >> FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect >> "Alignment of access forced using peeling" 1 >> FAIL: gcc.dg/tree-ssa/loop-bound-1.c scan-tree-dump ivopts "bounded >> by 254" >> FAIL: gcc.dg/tree-ssa/loop-bound-2.c scan-tree-dump ivopts "bounded >> by 254" >> FAIL: gcc.dg/tree-ssa/predcom-2.c scan-tree-dump-times pcom >> "Unrolling 2 times." 2 >> FAIL: gcc.dg/tree-ssa/predcom-4.c scan-tree-dump-times pcom >> "Combination" 1 >> FAIL: gcc.dg/tree-ssa/predcom-4.c scan-tree-dump-times pcom >> "Unrolling 3 times." 1 >> FAIL: gcc.dg/tree-ssa/predcom-5.c scan-tree-dump-times pcom >> "Combination" 2 >> FAIL: gcc.dg/tree-ssa/predcom-5.c scan-tree-dump-times pcom >> "Unrolling 3 times." 1 >> FAIL: gcc.dg/tree-ssa/predcom-9.c scan-tree-dump pcom "Executing >> predictive commoning without unrolling" >> FAIL: gcc.dg/tree-ssa/reassoc-46.c scan-tree-dump-times optimized >> "(?:vect_)?sum_[\\d._]+ = (?:(?:vect_)?_[\\d._]+ \\+ >> (?:vect_)?sum_[\\d._]+|(?:v ect_)?sum_[\\d._]+ \\+ >> (?:vect_)?_[\\d._]+)" 1 >> FAIL: gcc.dg/tree-ssa/scev-10.c scan-tree-dump-times ivopts " >> Type:\\tREFERENCE ADDRESS\n" 1 >> FAIL: gcc.dg/tree-ssa/scev-11.c scan-tree-dump-times ivopts " >> Type:\\tREFERENCE ADDRESS\n" 2 >> FAIL: gcc.dg/tree-ssa/scev-14.c scan-tree-dump ivopts "Overflowness >> wrto loop niter:\tNo-overflow" >> FAIL: gcc.dg/tree-ssa/scev-9.c scan-tree-dump-times ivopts " >> Type:\\tREFERENCE ADDRESS\n" 1 >> FAIL: gcc.dg/tree-ssa/split-path-11.c scan-tree-dump-times >> split-paths "join point for if-convertable half-diamond" 1 >> >> These are bogus dump FAILs
Re: RFA: RISC-V: Make riscv_vector::legitimize_move adjust SRC in the caller. (Was: Remove mem-to-mem VLS move pattern[PR111566])
Great! Thanks for fixing it. LGTM. juzhe.zh...@rivai.ai From: Joern Rennecke Date: 2023-10-01 04:30 To: GCC Patches CC: Jeff Law; 钟居哲 Subject: RFA: RISC-V: Make riscv_vector::legitimize_move adjust SRC in the caller. (Was: Remove mem-to-mem VLS move pattern[PR111566]) >On 9/27/23 03:38, juzhe.zh...@rivai.ai wrote: >> >> Why add `can_create_pseudo_p ()` here? this will split after reload, but we forbid that pattern between reload and split2? >> >> I have no ideal. Some fortran tests just need recognization of >> mem-to-mem pattern before RA >> I don't know the reason. >But isn't that the key to understanding what's going on here? Jeff law: >There is nothing special about Fortran here. Whatever problem this is >working around will almost certainly show up again in other, >non-Fortran, contexts. I also ran into the problem of the mov_mem_to_mem pattern making ira combine the instructions output by my cpymem patch into an unsplittable must-split pattern. And just plain removing the mem-to-mem pattern gives a newlib build failure. The underlying problem is in the declaration of riscv_vector::legitimize_move . The function gets passed by value a source and destination, and it either emits (instructions for) a move and returns true, or does checks and/or preparation statements and a modifications of its *copy of* src and returns. IIRC, we don't want C++ pass-by-reference syntax in GCC source, so the solution should be the tried-and trusted method of passing an explicit pointer to rtl that we want modified. I have attached a patch, regression tested for: riscv-sim riscv-sim/-march=rv32gcv_zfh/-mabi=ilp32d/-ftree-vectorize/--param=riscv-autovec-preference=scalable riscv-sim/-march=rv32imac/-mabi=ilp32 riscv-sim/-march=rv64gcv_zfh_zvfh_zba_zbb_zbc_zicond_zicboz_zawrs/-mabi=lp64d/-ftree-vectorize/--param=riscv-autovec-preference=scalable riscv-sim/-march=rv64imac/-mabi=lp64 Incidentally, the optimization that the mov_mem_to_mem made was invalid, as it didn't check alignments, nor that the target supports unaligned accesses with a fast hardware implementation. I think this optimization - with the appropriate check for hardware support - should be put into the non-vector path of the cpymem expander, simply as a relaxation of the alignment test for using scalars values spanning multiple addressable units.
Re: [PATCH] RISC-V: Enable RVV scalable vectorization by default[PR111311]
On 9/11/23 06:12, Jeff Law via Gcc-patches wrote: On 9/10/23 21:42, juzhe.zh...@rivai.ai wrote: Ping this patch. I think it's time to enable scalable vectorization by default and do the whole regression every time (except vect.exp that we didn't enable yet) Update current FAILs status: Real FAILS (ICE and execution FAIL): FAIL: gcc.dg/pr70252.c (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:284) FAIL: gcc.dg/pr70252.c (test for excess errors) FAIL: gcc.dg/pr92301.c execution test Robin is working on these 3 issues and will be solved soon. FAIL: g++.dg/torture/vshuf-v4df.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error: in as_a, at machmode.h:381) FAIL: g++.dg/torture/vshuf-v4df.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: g++.dg/torture/vshuf-v4df.C -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error: in as_a, at machmode.h:381) FAIL: g++.dg/torture/vshuf-v4df.C -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) This is a long time known issue I have mentioned many times, we need help for LTO since it's caused by mode bits extension. The rest bogus FAILs: FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "Not unrolling loop, doesn't roll" FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "likely upper bound: 6" FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "realistic bound: -1" FAIL: gcc.dg/var-expand1.c scan-rtl-dump loop2_unroll "Expanding Accumulator" FAIL: gcc.dg/tree-ssa/cunroll-16.c scan-tree-dump cunroll "optimized: loop with [0-9]+ iterations completely unrolled" FAIL: gcc.dg/tree-ssa/cunroll-16.c scan-tree-dump-not optimized "foo" FAIL: gcc.dg/tree-ssa/forwprop-40.c scan-tree-dump-times optimized "BIT_FIELD_REF" 0 FAIL: gcc.dg/tree-ssa/forwprop-40.c scan-tree-dump-times optimized "BIT_INSERT_EXPR" 0 FAIL: gcc.dg/tree-ssa/forwprop-41.c scan-tree-dump-times optimized "BIT_FIELD_REF" 0 FAIL: gcc.dg/tree-ssa/forwprop-41.c scan-tree-dump-times optimized "BIT_INSERT_EXPR" 1 FAIL: gcc.dg/tree-ssa/gen-vect-11b.c scan-tree-dump-times vect "vectorized 0 loops" 1 FAIL: gcc.dg/tree-ssa/gen-vect-11c.c scan-tree-dump-times vect "vectorized 0 loops" 1 FAIL: gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1 FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1 FAIL: gcc.dg/tree-ssa/loop-bound-1.c scan-tree-dump ivopts "bounded by 254" FAIL: gcc.dg/tree-ssa/loop-bound-2.c scan-tree-dump ivopts "bounded by 254" FAIL: gcc.dg/tree-ssa/predcom-2.c scan-tree-dump-times pcom "Unrolling 2 times." 2 FAIL: gcc.dg/tree-ssa/predcom-4.c scan-tree-dump-times pcom "Combination" 1 FAIL: gcc.dg/tree-ssa/predcom-4.c scan-tree-dump-times pcom "Unrolling 3 times." 1 FAIL: gcc.dg/tree-ssa/predcom-5.c scan-tree-dump-times pcom "Combination" 2 FAIL: gcc.dg/tree-ssa/predcom-5.c scan-tree-dump-times pcom "Unrolling 3 times." 1 FAIL: gcc.dg/tree-ssa/predcom-9.c scan-tree-dump pcom "Executing predictive commoning without unrolling" FAIL: gcc.dg/tree-ssa/reassoc-46.c scan-tree-dump-times optimized "(?:vect_)?sum_[\\d._]+ = (?:(?:vect_)?_[\\d._]+ \\+ (?:vect_)?sum_[\\d._]+|(?:v ect_)?sum_[\\d._]+ \\+ (?:vect_)?_[\\d._]+)" 1 FAIL: gcc.dg/tree-ssa/scev-10.c scan-tree-dump-times ivopts " Type:\\tREFERENCE ADDRESS\n" 1 FAIL: gcc.dg/tree-ssa/scev-11.c scan-tree-dump-times ivopts " Type:\\tREFERENCE ADDRESS\n" 2 FAIL: gcc.dg/tree-ssa/scev-14.c scan-tree-dump ivopts "Overflowness wrto loop niter:\tNo-overflow" FAIL: gcc.dg/tree-ssa/scev-9.c scan-tree-dump-times ivopts " Type:\\tREFERENCE ADDRESS\n" 1 FAIL: gcc.dg/tree-ssa/split-path-11.c scan-tree-dump-times split-paths "join point for if-convertable half-diamond" 1 These are bogus dump FAILs and I have 100% confirm each of them, we are having same behavior as SVE. So is this patch ok for trunk ? Yes, this is OK for the trunk. Our internal SPEC regressions as of yesterday's tip are still failing due to this commit. 2023-09-28 8552dcd8e444 Revert "[RA]: Improve cost calculation of pseudos with equivalences" Is there a plan for addressing the blocker issues above anytime soon ? Thx, -Vineet
Re: committed [RISC-V]: Harden test scan patterns
On Fri, 29 Sept 2023 at 14:54, Jeff Law wrote: > So I recommend we go forward with Joern's approach (so consider that an > ACK for the trunk). Joern can you post a follow-up manual twiddle so > that other ports can follow your example and avoid this problem? The manual... so not in the general web pages, but the stuff under gcc/doc ? I see that we have a description of scan-assembler* directives in sourcebuild.texi , so I suppose that it should go there. I suppose the advice should also apply to scan-assembler-dem(-not), but not to scan-symbol-section . The more I think about this, the more it feels like we are providing the wrong tools and then are telling users they're using it incorrectly (like "You're holding it wrong."). Quoting dots with \. is not much of an issue, but prepending \t or \m impairs legibility. I like the obsoleted word-start/end markers \< / \> much better, as they don't blend in with text. ^ as start-of-line marker is nice for legibility, but it will generally not work with common semantics, as it'll be thrown off by white space, and even more, by labels. Also, we might have different directives for not scanning in LTO sections - or just ignoring .ascii . Or maybe the other way round - you have to do something special if you want to scan inside strings, and by default we don't look inside strings? LTO information uses ascii, and ISTR sometimes also a zero-terminated variant (asciiz?); There might also some string constant outputs, or stabs information. One possible rule I think might work is: if the RE doesn't mention a quote, don't scan what's quoted inside double quotes. Although we might to have to look out for backslash-escaped quotes to find the proper end of a quoted string. Or should we instead make assembly scans specific to sections in which assembly output goes, like text sections? The danger is that we might miss a text section by another name. We can give an error if we find no text section, but there might be a recognizable text section which is a red herring besides the one that's hidden by some unusual name.
[PATCH v2] rtl: fix build failure on -fchecking=2 [PR111642]
From: Sergei Trofimovich
Before the change `make bootstrap4` (or `make profiledbootstrap`) failed
as:
gcc/rtl-tests.cc:249:25: in ‘constexpr’ expansion of ‘poly_int<1, long
int>(1, 1)’
gcc/poly-int.h:453:5: error: too many initializers for ‘long int [1]’
The failure happened only in stage4 due to a gcc bug which accepts
invalid C++ without `-fchecking=2`: https://gcc.gnu.org/PR111647#c1.
The change hides tests that rely on 2 and more polynomials under `#if`.
gcc/
PR bootstrap/111642
* rtl-tests.cc (const_poly_int_tests): Guard tests with
NUM_POLY_INT_COEFFS > 1.
* simplify-rtx.cc (simplify_const_poly_int_tests): Ditto.
---
gcc/rtl-tests.cc| 23 +++
gcc/simplify-rtx.cc | 21 ++---
2 files changed, 13 insertions(+), 31 deletions(-)
diff --git a/gcc/rtl-tests.cc b/gcc/rtl-tests.cc
index ae8669419b6..d4130572501 100644
--- a/gcc/rtl-tests.cc
+++ b/gcc/rtl-tests.cc
@@ -228,24 +228,14 @@ test_uncond_jump ()
jump_insn);
}
-template
-struct const_poly_int_tests
-{
- static void run ();
-};
-
-template<>
-struct const_poly_int_tests<1>
-{
- static void run () {}
-};
-
/* Test various CONST_POLY_INT properties. */
-template
-void
-const_poly_int_tests::run ()
+static void
+const_poly_int_tests ()
{
+ /* `poly_int64` call with two parameters requires target with at
+ least 2 COEFFs. */
+#if NUM_POLY_INT_COEFFS > 1
rtx x1 = gen_int_mode (poly_int64 (1, 1), QImode);
rtx x255 = gen_int_mode (poly_int64 (1, 255), QImode);
@@ -282,6 +272,7 @@ const_poly_int_tests::run ()
gen_int_mode (poly_int64 (5, -2), QImode));
ASSERT_EQ (plus_constant (QImode, x1, poly_int64 (4, -2)),
gen_int_mode (poly_int64 (5, -1), QImode));
+#endif
}
/* Check dumping of repeated RTL vectors. */
@@ -317,7 +308,7 @@ rtl_tests_cc_tests ()
test_dumping_rtx_reuse ();
test_single_set ();
test_uncond_jump ();
- const_poly_int_tests::run ();
+ const_poly_int_tests ();
test_dumping_repeat ();
/* Purge state. */
diff --git a/gcc/simplify-rtx.cc b/gcc/simplify-rtx.cc
index 170406aa28b..39361b11b1a 100644
--- a/gcc/simplify-rtx.cc
+++ b/gcc/simplify-rtx.cc
@@ -8671,24 +8671,14 @@ test_vector_ops ()
}
}
-template
-struct simplify_const_poly_int_tests
-{
- static void run ();
-};
-
-template<>
-struct simplify_const_poly_int_tests<1>
-{
- static void run () {}
-};
-
/* Test various CONST_POLY_INT properties. */
-template
void
-simplify_const_poly_int_tests::run ()
+simplify_const_poly_int_tests ()
{
+ /* `poly_int64` call with two parameters requires target with at
+ least 2 COEFFs. */
+#if NUM_POLY_INT_COEFFS > 1
rtx x1 = gen_int_mode (poly_int64 (1, 1), QImode);
rtx x2 = gen_int_mode (poly_int64 (-80, 127), QImode);
rtx x3 = gen_int_mode (poly_int64 (-79, -128), QImode);
@@ -8716,6 +8706,7 @@ simplify_const_poly_int_tests::run ()
ASSERT_EQ (simplify_binary_operation (IOR, QImode, x4, two), x7);
ASSERT_EQ (simplify_subreg (HImode, x5, QImode, 0), x8);
ASSERT_EQ (simplify_subreg (QImode, x8, HImode, offset), x5);
+#endif
}
/* Run all of the selftests within this file. */
@@ -8725,7 +8716,7 @@ simplify_rtx_cc_tests ()
{
test_scalar_ops ();
test_vector_ops ();
- simplify_const_poly_int_tests::run ();
+ simplify_const_poly_int_tests ();
}
} // namespace selftest
--
2.42.0
Re: [PATCH] arm: add -static-pie support
On Tue, Jul 19, 2022 at 02:21:05PM -0600, lancethepants wrote:
> The commit mirros code from aarch64 to handle -static-pie.
> Tested with uclibc-ng and musl c-standard libraries.
>
> Signed-off-by: Lance Fredrickson
> ---
> gcc/config/arm/linux-elf.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/config/arm/linux-elf.h b/gcc/config/arm/linux-elf.h
> index df3da67c4f0..70f71b051a3 100644
> --- a/gcc/config/arm/linux-elf.h
> +++ b/gcc/config/arm/linux-elf.h
> @@ -66,9 +66,10 @@
> %{static:-Bstatic} \
> %{shared:-shared} \
> %{symbolic:-Bsymbolic} \
> - %{!static: \
> + %{!static:%{!static-pie: \
> %{rdynamic:-export-dynamic} \
> - %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}} \
> + %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}} \
> + %{static-pie:-Bstatic -pie --no-dynamic-linker -z text} \
> -X \
> %{mbig-endian:-EB} %{mlittle-endian:-EL}" \
> SUBTARGET_EXTRA_LINK_SPEC
Hi,
This patch seems to have gotten a bit mangled when it was submitted,
so perhaps that's why it was ignored, but it would be great to get this
functionality in gcc.
In particular, systemd has begun relying on -static-pie for EFI
support, and has to implement workarounds (manually passing these flags
to the linker) for architectures that don't support -static-pie (see
[1], [2]).
Thanks, Ben
[1] https://github.com/NixOS/nixpkgs/pull/243242#issuecomment-1741835837
[2] https://github.com/systemd/systemd/issues/29381
Re: [PATCH] rtl: fix buidl failure on -fchecking=2 [PR111642]
On Sep 30 2023, Sergei Trofimovich wrote: > @@ -263,7 +253,7 @@ const_poly_int_tests::run () >ASSERT_KNOWN_EQ (rtx_to_poly_int64 (x255), poly_int64 (1, -1)); >ASSERT_MAYBE_NE (rtx_to_poly_int64 (x255), poly_int64 (1, 255)); > > - /* Test plus_constant of a symbol. */ > + /* Test plus_consctant of a symbol. */ Spurious change. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
[PATCH] rtl: fix buidl failure on -fchecking=2 [PR111642]
From: Sergei Trofimovich
Before the change `make bootstrap4` (or `make profiledbootstrap`) failed
as:
gcc/rtl-tests.cc:249:25: in ‘constexpr’ expansion of ‘poly_int<1, long
int>(1, 1)’
gcc/poly-int.h:453:5: error: too many initializers for ‘long int [1]’
The failure happened only in stage4 due to a gcc bug which accepts
invalid C++ without `-fchecking=2`: https://gcc.gnu.org/PR111647#c1.
The change hides tests that rely on 2 and more polynomials under `#if`.
gcc/
PR bootstrap/111642
* rtl-tests.cc (const_poly_int_tests): Guard tests with
NUM_POLY_INT_COEFFS > 1.
* simplify-rtx.cc (simplify_const_poly_int_tests): Ditto.
---
gcc/rtl-tests.cc| 25 -
gcc/simplify-rtx.cc | 21 ++---
2 files changed, 14 insertions(+), 32 deletions(-)
diff --git a/gcc/rtl-tests.cc b/gcc/rtl-tests.cc
index ae8669419b6..85c1e56048d 100644
--- a/gcc/rtl-tests.cc
+++ b/gcc/rtl-tests.cc
@@ -228,24 +228,14 @@ test_uncond_jump ()
jump_insn);
}
-template
-struct const_poly_int_tests
-{
- static void run ();
-};
-
-template<>
-struct const_poly_int_tests<1>
-{
- static void run () {}
-};
-
/* Test various CONST_POLY_INT properties. */
-template
-void
-const_poly_int_tests::run ()
+static void
+const_poly_int_tests ()
{
+ /* `poly_int64` call with two parameters requires target with at
+ least 2 COEFFs. */
+#if NUM_POLY_INT_COEFFS > 1
rtx x1 = gen_int_mode (poly_int64 (1, 1), QImode);
rtx x255 = gen_int_mode (poly_int64 (1, 255), QImode);
@@ -263,7 +253,7 @@ const_poly_int_tests::run ()
ASSERT_KNOWN_EQ (rtx_to_poly_int64 (x255), poly_int64 (1, -1));
ASSERT_MAYBE_NE (rtx_to_poly_int64 (x255), poly_int64 (1, 255));
- /* Test plus_constant of a symbol. */
+ /* Test plus_consctant of a symbol. */
rtx symbol = gen_rtx_SYMBOL_REF (Pmode, "foo");
rtx offset1 = gen_int_mode (poly_int64 (9, 11), Pmode);
rtx sum1 = gen_rtx_CONST (Pmode, gen_rtx_PLUS (Pmode, symbol, offset1));
@@ -282,6 +272,7 @@ const_poly_int_tests::run ()
gen_int_mode (poly_int64 (5, -2), QImode));
ASSERT_EQ (plus_constant (QImode, x1, poly_int64 (4, -2)),
gen_int_mode (poly_int64 (5, -1), QImode));
+#endif
}
/* Check dumping of repeated RTL vectors. */
@@ -317,7 +308,7 @@ rtl_tests_cc_tests ()
test_dumping_rtx_reuse ();
test_single_set ();
test_uncond_jump ();
- const_poly_int_tests::run ();
+ const_poly_int_tests ();
test_dumping_repeat ();
/* Purge state. */
diff --git a/gcc/simplify-rtx.cc b/gcc/simplify-rtx.cc
index 170406aa28b..39361b11b1a 100644
--- a/gcc/simplify-rtx.cc
+++ b/gcc/simplify-rtx.cc
@@ -8671,24 +8671,14 @@ test_vector_ops ()
}
}
-template
-struct simplify_const_poly_int_tests
-{
- static void run ();
-};
-
-template<>
-struct simplify_const_poly_int_tests<1>
-{
- static void run () {}
-};
-
/* Test various CONST_POLY_INT properties. */
-template
void
-simplify_const_poly_int_tests::run ()
+simplify_const_poly_int_tests ()
{
+ /* `poly_int64` call with two parameters requires target with at
+ least 2 COEFFs. */
+#if NUM_POLY_INT_COEFFS > 1
rtx x1 = gen_int_mode (poly_int64 (1, 1), QImode);
rtx x2 = gen_int_mode (poly_int64 (-80, 127), QImode);
rtx x3 = gen_int_mode (poly_int64 (-79, -128), QImode);
@@ -8716,6 +8706,7 @@ simplify_const_poly_int_tests::run ()
ASSERT_EQ (simplify_binary_operation (IOR, QImode, x4, two), x7);
ASSERT_EQ (simplify_subreg (HImode, x5, QImode, 0), x8);
ASSERT_EQ (simplify_subreg (QImode, x8, HImode, offset), x5);
+#endif
}
/* Run all of the selftests within this file. */
@@ -8725,7 +8716,7 @@ simplify_rtx_cc_tests ()
{
test_scalar_ops ();
test_vector_ops ();
- simplify_const_poly_int_tests::run ();
+ simplify_const_poly_int_tests ();
}
} // namespace selftest
--
2.42.0
Re: gcc-patches From rewriting mailman settings
Hi, On Sun, Sep 17, 2023 at 10:04:37PM +0200, Mark Wielaard wrote: > On Tue, Sep 12, 2023 at 05:00:07PM +0200, Mark Wielaard wrote: > > We (Jeff or anyone else with mailman admin privs) could use the same > > settings for gcc-patches. The settings that need to be set are in that > > bug: > > > > - subject_prefix (general): (empty) > > - from_is_list (general): No > > - anonymous_list (general): No > > - first_strip_reply_to (general): No > > - reply_goes_to_list (general): Poster > > - reply_to_address (general): (empty) > > - include_sender_header (general): No > > - drop_cc (general): No > > - msg_header (nondigest): (empty) > > - msg_footer (nondigest): (empty) > > - scrub_nondigest (nondigest): No > > - dmarc_moderation_action (privacy): Accept > > - filter_content (contentfilter): No > > > > The only visible change (apart from no more From rewriting) is that > > HTML multi-parts aren't scrubbed anymore (that would be a message > > altering issue). The html part is still scrubbed from the > > inbox.sourceware.org archive, so b4 works just fine. But I don't know > > what patchwork.sourceware.org does with HTML attachements. Of course > > people really shouldn't sent HTML attachments to gcc-patches, so maybe > > this is no real problem. > > Although there were some positive responses (on list and on irc) it is > sometimes hard to know if there really is consensus for these kind of > infrastructure tweaks. But I believe there is at least no sustained > opposition to changing the gcc-patches mailman setting as proposed > above. > > So unless someone objects I like to make this change Tuesday September > 19 around 08:00 UTC. > > And if there are no complaints at Cauldron we could do the same for > the other patch lists the week after. Since there were no complaints (and some happy users) and we didn't real issues (there was an issue when using the Errors-To header, which might break your dkim signature, but the only user of Errors-To has dropped it) the jit, libstdc++, fortran and gcc-rust lists now also have the above mailman settings. The admin email address for fortran was updated to Toon's new address and the one for libstdc++ was changed from bkoz to jwakely. If there are any issues with the list settings please discuss on the overse...@sourceware.org mailinglist. Cheers, Mark > > > [1] https://patchwork.sourceware.org/project/gcc/list/ > > > [2] https://sourceware.org/bugzilla/show_bug.cgi?id=29713
Re: [PATCH v2] ARM: Block predication on atomics [PR111235]
+ linaro-toolchain as I don't understand the CI issues on patchwork. On Wed, Sep 27, 2023 at 8:40 PM Wilco Dijkstra wrote: > > Hi Ramana, > > > Hope this helps. > > Yes definitely! > > >> Passes regress/bootstrap, OK for commit? > > > > Target ? armhf ? --with-arch , -with-fpu , -with-float parameters ? > > Please be specific. > > I used --target=arm-none-linux-gnueabihf --host=arm-none-linux-gnueabihf > --build=arm-none-linux-gnueabihf --with-float=hard. However it seems that the > default armhf settings are incorrect. I shouldn't need the --with-float=hard > since > that is obviously implied by armhf, and they should also imply armv7-a with > vfpv3 > according to documentation. It seems to get confused and skip some tests. I > tried > using --with-fpu=auto, but that doesn't work at all, so in the end I forced > it like: > --with-arch=armv8-a --with-fpu=neon-fp-armv8. With this it runs a few more > tests. Yeah that's a wart that I don't like. armhf just implies the hard float ABI and came into being to help distinguish from the Base PCS for some of the distros at the time (2010s). However we didn't want to set a baseline arch at that time given the imminent arrival of v8-a and thus the specification of --with-arch , --with-fpu and --with-float became second nature to many of us working on it at that time. I can see how it can be confusing. With the advent of fpu=auto , I thought this could be made better but that is a matter for another patch and another discussion. However until then do remember to baseline to --with-arch , --with-fpu and --with-float . Unfortunate but needed. If there is a bug with --with-fpu=auto , good to articulate it as I understand that to be the state of the art. Thank you for working through it. > > > Since these patterns touch armv8m.baseline can you find all the > > testcases in the testsuite and ensure no change in code for > > armv8m.baseline as that's unpredicated already and this patch brings > > this in line with the same ? Does the testsuite already cover these > > arch variants and are you satisfied that the tests in the testsuite > > can catch / don't make any additional code changes to the other > > architectures affected by this ? > > There are various v8-m(.base/.main) tests and they all pass. The generated > code is generally unchanged if there was no conditional execution. I made > the new UNSPEC_LDR/STR patterns support offsets so there is no difference > in generated code for relaxed loads/stores (since they used to use a plain > load/store which has an immediate offset). > > >> * onfig/arm/sync.md (arm_atomic_load): Add new pattern. > > > > Nit: s/onfig/config > > Fixed. Thanks > > >> (atomic_load): Always expand atomic loads explicitly. > >> (atomic_store): Always expand atomic stores explicitly. > > > > Nit: Change message to : > > Switch patterns to define_expand. > > Fixed. Thanks. > > > Largely looks ok though I cannot work out tonight if we need more v8-a > > or v8m-baseline specific tests for scan-assembler patterns. > > > > Clearly our testsuite doesn't catch it , so perhaps the OP could help > > validate this patch with their formal models to see if this fixes > > these set of issues and creates no new regressions ? Is that feasible > > to do ? > > Disabling conditional execution avoids the issue. It's trivial to verify that > atomics can no longer be conditionally executed (no "%?"). When this is > committed, we can run the random testing again to confirm the issue > is no longer present. Ok, thanks for promising to do so - I trust you to get it done. Please try out various combinations of -march v7ve, v7-a , v8-a with the tool as each of them have slightly different rules. For instance v7ve allows LDREXD and STREXD to be single copy atomic for 64 bit loads whereas v7-a did not . > > > -(define_insn "atomic_load" > > - [(set (match_operand:QHSI 0 "register_operand" "=r,r,l") > > +(define_insn "arm_atomic_load" > > + [(set (match_operand:QHSI 0 "register_operand" "=r,l") > > (unspec_volatile:QHSI > > - [(match_operand:QHSI 1 "arm_sync_memory_operand" "Q,Q,Q") > > - (match_operand:SI 2 "const_int_operand" "n,Pf,n")] ;; model > > + [(match_operand:QHSI 1 "memory_operand" "m,m")] > > > > Remind me again why is it safe to go from the Q constraint to the m > > constraint here and everywhere else you've done this ? > > That's because the relaxed loads/stores use LDR/STR wrapped in an > UNSPEC. To avoid regressions we have to use 'm' so that an immediate > offset can be merged into the memory access. This is because the instructions used here are ldr and str and the use of the 'm' constraint is considered safe. > > >> - VUNSPEC_LDA ; Represent a store-register-acquire. > >> + VUNSPEC_LDR ; Represent a load-register-relaxed. > >> + VUNSPEC_LDA ; Represent a load-register-acquire. > > > > Nit: LDA before LDR ? Though I suspect this list can be alphabetically
Re: Ping^2 [PATCH V5 1/4] rs6000: build constant via li;rotldi
On Mon, Sep 25, 2023 at 10:52 PM Jiufu Guo wrote:
> Hi,
>
> Gentle ping...
>
> BR,
> Jeff (Jiufu Guo)
>
This is okay.
Thanks, David
>
> Jiufu Guo via Gcc-patches writes:
>
> > Hi,
> >
> > Gentle ping...
> >
> > BR,
> > Jeff (Jiufu Guo)
> >
> > Jiufu Guo writes:
> >
> >> Hi,
> >>
> >> If a constant is possible to be rotated to/from a positive or negative
> >> value which "li" can generated, then "li;rotldi" can be used to build
> >> the constant.
> >>
> >> Compare with the previous version:
> >> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623528.html
> >> This patch just did minor changes to the comments according to previous
> >> review.
> >>
> >> Bootstrap and regtest pass on ppc64{,le}.
> >>
> >> Is this ok for trunk?
> >>
> >>
> >> BR,
> >> Jeff (Jiufu)
> >>
> >> gcc/ChangeLog:
> >>
> >> * config/rs6000/rs6000.cc (can_be_built_by_li_and_rotldi): New
> function.
> >> (rs6000_emit_set_long_const): Call can_be_built_by_li_and_rotldi.
> >>
> >> gcc/testsuite/ChangeLog:
> >>
> >> * gcc.target/powerpc/const-build.c: New test.
> >> ---
> >> gcc/config/rs6000/rs6000.cc | 47 +--
> >> .../gcc.target/powerpc/const-build.c | 57 +++
> >> 2 files changed, 98 insertions(+), 6 deletions(-)
> >> create mode 100644 gcc/testsuite/gcc.target/powerpc/const-build.c
> >>
> >> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
> >> index 42f49e4a56b..acc332acc05 100644
> >> --- a/gcc/config/rs6000/rs6000.cc
> >> +++ b/gcc/config/rs6000/rs6000.cc
> >> @@ -10258,6 +10258,31 @@ rs6000_emit_set_const (rtx dest, rtx source)
> >>return true;
> >> }
> >>
> >> +/* Check if value C can be built by 2 instructions: one is 'li',
> another is
> >> + 'rotldi'.
> >> +
> >> + If so, *SHIFT is set to the shift operand of rotldi(rldicl), and
> *MASK
> >> + is set to the mask operand of rotldi(rldicl), and return true.
> >> + Return false otherwise. */
> >> +
> >> +static bool
> >> +can_be_built_by_li_and_rotldi (HOST_WIDE_INT c, int *shift,
> >> + HOST_WIDE_INT *mask)
> >> +{
> >> + /* If C or ~C contains at least 49 successive zeros, then C can be
> rotated
> >> + to/from a positive or negative value that 'li' is able to load.
> */
> >> + int n;
> >> + if (can_be_rotated_to_lowbits (c, 15, )
> >> + || can_be_rotated_to_lowbits (~c, 15, ))
> >> +{
> >> + *mask = HOST_WIDE_INT_M1;
> >> + *shift = HOST_BITS_PER_WIDE_INT - n;
> >> + return true;
> >> +}
> >> +
> >> + return false;
> >> +}
> >> +
> >> /* Subroutine of rs6000_emit_set_const, handling PowerPC64 DImode.
> >> Output insns to set DEST equal to the constant C as a series of
> >> lis, ori and shl instructions. */
> >> @@ -10266,15 +10291,14 @@ static void
> >> rs6000_emit_set_long_const (rtx dest, HOST_WIDE_INT c)
> >> {
> >>rtx temp;
> >> + int shift;
> >> + HOST_WIDE_INT mask;
> >>HOST_WIDE_INT ud1, ud2, ud3, ud4;
> >>
> >>ud1 = c & 0x;
> >> - c = c >> 16;
> >> - ud2 = c & 0x;
> >> - c = c >> 16;
> >> - ud3 = c & 0x;
> >> - c = c >> 16;
> >> - ud4 = c & 0x;
> >> + ud2 = (c >> 16) & 0x;
> >> + ud3 = (c >> 32) & 0x;
> >> + ud4 = (c >> 48) & 0x;
> >>
> >>if ((ud4 == 0x && ud3 == 0x && ud2 == 0x && (ud1 &
> 0x8000))
> >>|| (ud4 == 0 && ud3 == 0 && ud2 == 0 && ! (ud1 & 0x8000)))
> >> @@ -10305,6 +10329,17 @@ rs6000_emit_set_long_const (rtx dest,
> HOST_WIDE_INT c)
> >>emit_move_insn (dest, gen_rtx_XOR (DImode, temp,
> >> GEN_INT ((ud2 ^ 0x) << 16)));
> >> }
> >> + else if (can_be_built_by_li_and_rotldi (c, , ))
> >> +{
> >> + temp = !can_create_pseudo_p () ? dest : gen_reg_rtx (DImode);
> >> + unsigned HOST_WIDE_INT imm = (c | ~mask);
> >> + imm = (imm >> shift) | (imm << (HOST_BITS_PER_WIDE_INT - shift));
> >> +
> >> + emit_move_insn (temp, GEN_INT (imm));
> >> + if (shift != 0)
> >> +temp = gen_rtx_ROTATE (DImode, temp, GEN_INT (shift));
> >> + emit_move_insn (dest, temp);
> >> +}
> >>else if (ud3 == 0 && ud4 == 0)
> >> {
> >>temp = !can_create_pseudo_p () ? dest : gen_reg_rtx (DImode);
> >> diff --git a/gcc/testsuite/gcc.target/powerpc/const-build.c
> b/gcc/testsuite/gcc.target/powerpc/const-build.c
> >> new file mode 100644
> >> index 000..69b37e2bb53
> >> --- /dev/null
> >> +++ b/gcc/testsuite/gcc.target/powerpc/const-build.c
> >> @@ -0,1 +1,57 @@
> >> +/* { dg-do run } */
> >> +/* { dg-options "-O2 -save-temps" } */
> >> +/* { dg-require-effective-target has_arch_ppc64 } */
> >> +
> >> +/* Verify that two instructions are successfully used to build
> constants.
> >> + One insn is li, another is rotate: rldicl. */
> >> +
> >> +#define NOIPA __attribute__ ((noipa))
> >> +
> >> +struct fun
> >> +{
> >> + long long (*f) (void);
> >> + long long val;
> >> +};
> >> +
> >> +long long NOIPA
> >>
RFA: RISC-V: Make riscv_vector::legitimize_move adjust SRC in the caller. (Was: Remove mem-to-mem VLS move pattern[PR111566])
>On 9/27/23 03:38, juzhe.zh...@rivai.ai wrote:
>> >> Why add `can_create_pseudo_p ()` here? this will split after reload,
but we forbid that pattern between reload and split2?
>>
>> I have no ideal. Some fortran tests just need recognization of
>> mem-to-mem pattern before RA
>> I don't know the reason.
>But isn't that the key to understanding what's going on here?
Jeff law:
>There is nothing special about Fortran here. Whatever problem this is
>working around will almost certainly show up again in other,
>non-Fortran, contexts.
I also ran into the problem of the mov_mem_to_mem pattern
making ira combine the instructions output by my cpymem patch into
an unsplittable must-split pattern. And just plain removing the mem-to-mem
pattern gives a newlib build failure.
The underlying problem is in the declaration of riscv_vector::legitimize_move .
The function gets passed by value a source and destination, and it either
emits (instructions for) a move and returns true, or does checks and/or
preparation statements and a modifications of its *copy of* src and returns.
IIRC, we don't want C++ pass-by-reference syntax in GCC source, so the
solution should be the tried-and trusted method of passing an explicit pointer
to rtl that we want modified.
I have attached a patch, regression tested for:
riscv-sim
riscv-sim/-march=rv32gcv_zfh/-mabi=ilp32d/-ftree-vectorize/--param=riscv-autovec-preference=scalable
riscv-sim/-march=rv32imac/-mabi=ilp32
riscv-sim/-march=rv64gcv_zfh_zvfh_zba_zbb_zbc_zicond_zicboz_zawrs/-mabi=lp64d/-ftree-vectorize/--param=riscv-autovec-preference=scalable
riscv-sim/-march=rv64imac/-mabi=lp64
Incidentally, the optimization that the mov_mem_to_mem made was invalid,
as it didn't check alignments, nor that the target supports unaligned
accesses with
a fast hardware implementation. I think this optimization - with the
appropriate check
for hardware support - should be put into the non-vector path of the
cpymem expander,
simply as a relaxation of the alignment test for using scalars values
spanning multiple
addressable units.
Make riscv_vector::legitimize_move adjust SRC in the caller.
2023-09-29 Joern Rennecke
Juzhe-Zhong
PR target/111566
gcc/
* config/riscv/riscv-protos.h (riscv_vector::legitimize_move):
Change second parameter to rtx *.
* config/riscv/riscv-v.cc (risv_vector::legitimize_move): Likewise.
* config/riscv/vector.md: Changed callers of
riscv_vector::legitimize_move.
* config/riscv/vector.md (*mov_mem_to_mem): Remove.
gcc/testsuite/
* gcc.target/riscv/rvv/autovec/vls/mov-1.c: Adapt test.
* gcc.target/riscv/rvv/autovec/vls/mov-10.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/mov-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/mov-5.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/mov-7.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/mov-8.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/mov-9.c: Ditto.1
* gcc.target/riscv/rvv/autovec/vls/mov-2.c: Removed.
* gcc.target/riscv/rvv/autovec/vls/mov-4.c: Removed.
* gcc.target/riscv/rvv/autovec/vls/mov-6.c: Removed.
* gcc.target/riscv/rvv/fortran/pr111566.f90: New test.
Co-Authored-By: Juzhe-Zhong
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index 368982a447b..af5baf37e6a 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -421,7 +421,7 @@ rtx expand_builtin (unsigned int, tree, rtx);
bool check_builtin_call (location_t, vec, unsigned int,
tree, unsigned int, tree *);
bool const_vec_all_same_in_range_p (rtx, HOST_WIDE_INT, HOST_WIDE_INT);
-bool legitimize_move (rtx, rtx);
+bool legitimize_move (rtx, rtx *);
void emit_vlmax_vsetvl (machine_mode, rtx);
void emit_hard_vlmax_vsetvl (machine_mode, rtx);
void emit_vlmax_insn (unsigned, unsigned, rtx *);
diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index 26700cfc732..097457562bd 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -1217,10 +1217,12 @@ get_frm_mode (rtx operand)
}
/* Expand a pre-RA RVV data move from SRC to DEST.
- It expands move for RVV fractional vector modes. */
+ It expands move for RVV fractional vector modes.
+ Return true if the move as already been emitted. */
bool
-legitimize_move (rtx dest, rtx src)
+legitimize_move (rtx dest, rtx *srcp)
{
+ rtx src = *srcp;
machine_mode mode = GET_MODE (dest);
if (CONST_VECTOR_P (src))
{
@@ -1238,7 +1240,7 @@ legitimize_move (rtx dest, rtx src)
{
/* Need to force register if mem <- !reg. */
if (MEM_P (dest) && !REG_P (src))
- src = force_reg (mode, src);
+ *srcp = force_reg (mode, src);
return false;
}
@@ -1269,7 +1271,7 @@ legitimize_move (rtx dest, rtx src)
{
/*
Re: [PATCH] vec.h: Guard most of static assertions for GCC >= 5
Hi Jakub,
A follow-up commit of yours (9d249b7e31e) is causing bootstrap failures
for riscv*-*-* targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649
Patrick
On 9/29/23 03:42, Jakub Jelinek wrote:
Hi!
As reported by Jonathan on IRC, my vec.h patch broke build with GCC 4.8.x
or 4.9.x as system compiler, e.g. on CFarm.
The problem is that while all of
std::is_trivially_{destructible,copyable,default_constructible} traits
are in C++, only std::is_trivially_destructible has been implemented in GCC
4.8, the latter two were added only in GCC 5.
Only std::is_trivially_destructible is the really important one though,
which is used to decide what pop returns and whether to invoke the
destructors or not. The rest are solely used in static_asserts and as such
I think it is acceptable if we don't assert those when built with GCC 4.8
or 4.9, anybody doing bootstrap from those system compilers or doing builds
with newer GCC will catch that.
So, the following patch guards those for 5+.
If we switch to C++14 later on and start requiring newer version of system
GCC as well (do we require GCC >= 5 which claims the last C++14 language
features, or what provides all C++14 library features, or GCC >= 6 which
uses -std=c++14 by default?), this patch then can be reverted.
Ok for trunk?
2023-09-29 Jakub Jelinek
* vec.h (quick_insert, ordered_remove, unordered_remove,
block_remove, qsort, sort, stablesort, quick_grow): Guard
std::is_trivially_{copyable,default_constructible} and
vec_detail::is_trivially_copyable_or_pair static assertions
with GCC_VERSION >= 5000.
(vec_detail::is_trivially_copyable_or_pair): Guard definition
with GCC_VERSION >= 5000.
--- gcc/vec.h.jj2023-09-29 10:59:09.830551963 +0200
+++ gcc/vec.h 2023-09-29 12:29:32.676428677 +0200
@@ -1086,7 +1086,12 @@ vec::quick_insert (unsig
{
gcc_checking_assert (length () < allocated ());
gcc_checking_assert (ix <= length ());
+#if GCC_VERSION >= 5000
+ /* GCC 4.8 and 4.9 only implement std::is_trivially_destructible,
+ but not std::is_trivially_copyable nor
+ std::is_trivially_default_constructible. */
static_assert (std::is_trivially_copyable ::value, "");
+#endif
T *slot = ()[ix];
memmove (slot + 1, slot, (m_vecpfx.m_num++ - ix) * sizeof (T));
*slot = obj;
@@ -1102,7 +1107,9 @@ inline void
vec::ordered_remove (unsigned ix)
{
gcc_checking_assert (ix < length ());
+#if GCC_VERSION >= 5000
static_assert (std::is_trivially_copyable ::value, "");
+#endif
T *slot = ()[ix];
memmove (slot, slot + 1, (--m_vecpfx.m_num - ix) * sizeof (T));
}
@@ -1150,7 +1157,9 @@ inline void
vec::unordered_remove (unsigned ix)
{
gcc_checking_assert (ix < length ());
+#if GCC_VERSION >= 5000
static_assert (std::is_trivially_copyable ::value, "");
+#endif
T *p = address ();
p[ix] = p[--m_vecpfx.m_num];
}
@@ -1164,13 +1173,16 @@ inline void
vec::block_remove (unsigned ix, unsigned len)
{
gcc_checking_assert (ix + len <= length ());
+#if GCC_VERSION >= 5000
static_assert (std::is_trivially_copyable ::value, "");
+#endif
T *slot = ()[ix];
m_vecpfx.m_num -= len;
memmove (slot, slot + len, (m_vecpfx.m_num - ix) * sizeof (T));
}
+#if GCC_VERSION >= 5000
namespace vec_detail
{
/* gcc_{qsort,qsort_r,stablesort_r} implementation under the hood
@@ -1189,6 +1201,7 @@ namespace vec_detail
: std::integral_constant::value
&& std::is_trivially_copyable::value> { };
}
+#endif
/* Sort the contents of this vector with qsort. CMP is the comparison
function to pass to qsort. */
@@ -1197,7 +1210,9 @@ template
inline void
vec::qsort (int (*cmp) (const void *, const void *))
{
+#if GCC_VERSION >= 5000
static_assert (vec_detail::is_trivially_copyable_or_pair ::value, "");
+#endif
if (length () > 1)
gcc_qsort (address (), length (), sizeof (T), cmp);
}
@@ -1210,7 +1225,9 @@ inline void
vec::sort (int (*cmp) (const void *, const void *, void *),
void *data)
{
+#if GCC_VERSION >= 5000
static_assert (vec_detail::is_trivially_copyable_or_pair ::value, "");
+#endif
if (length () > 1)
gcc_sort_r (address (), length (), sizeof (T), cmp, data);
}
@@ -1223,7 +1240,9 @@ inline void
vec::stablesort (int (*cmp) (const void *, const void *,
void *), void *data)
{
+#if GCC_VERSION >= 5000
static_assert (vec_detail::is_trivially_copyable_or_pair ::value, "");
+#endif
if (length () > 1)
gcc_stablesort_r (address (), length (), sizeof (T), cmp, data);
}
@@ -1396,7 +1415,9 @@ inline void
vec::quick_grow (unsigned len)
{
gcc_checking_assert (length () <= len && len <= m_vecpfx.m_alloc);
+#if GCC_VERSION >= 5000
// static_assert (std::is_trivially_default_constructible ::value, "");
+#endif
m_vecpfx.m_num = len;
}
Jakub
Re: [Fortran, Patch, Coarray, PR 37336] Fix crash in finalizer when derived type coarray is already freed.
Hi all, back porting to gcc-13 unfortunately caused a regression due to gfc_deallocate_with_status() having a different parameter count. This is fixed as obvious by 874b895fffd921659b37dc05bc94eea48e9a0157. Sorry for breaking gfortran-13. I still don't know why it checkout fine on my system in the beginning. I must have done something wrong. Please accept my apologies and regards, Andre On Fri, 29 Sep 2023 15:13:56 +0200 Andre Vehreschild via Fortran wrote: > Hi Paul, > > thanks. Commit to trunk as a680274616ec6b26ccfdcee400ed7f54e341d40c > and backported to gcc-13 as d9b3269bdccac2db9200303494c4e82f2aeb7bbc > > Thanks for the fast review. > > Regards, > Andre > > On Fri, 29 Sep 2023 13:38:57 +0100 > Paul Richard Thomas wrote: > > > Hi Andre, > > > > Yes indeed - it's fine for trunk and, I would suggest, 13-branch. > > > > Cheers > > > > Paul > > > > On Fri, 29 Sept 2023 at 11:01, Andre Vehreschild wrote: > > > > > > Hi Paul, > > > > > > thanks for the quick review. I've added a testcase with a module and a > > > finalizer in the derived type. This also is no problem. > > > > > > Regtests ok on x86_64_linux_gnu/f37. Ok for trunk? > > > > > > Regards, > > > Andre > > > > > > On Thu, 28 Sep 2023 19:21:12 +0100 > > > Paul Richard Thomas wrote: > > > > > > > Hi Andre, > > > > > > > > The patch looks fine to me. Since you mention it in the comment, is it > > > > worth declaring the derived type 'foo' in a module and giving it a > > > > final routine? > > > > > > > > Thanks for the patch. > > > > > > > > Paul > > > > > > > > On Thu, 28 Sept 2023 at 13:45, Andre Vehreschild via Fortran > > > > wrote: > > > > > > > > > > Hi all, > > > > > > > > > > attached patch fixes a crash in coarray programs when an allocatable > > > > > derived typed coarray was freed explicitly. The generated cleanup code > > > > > did not take into account, that the coarray may have been deallocated > > > > > already. The patch fixes this by moving the statements accessing > > > > > components inside the derived type into the block guard by its > > > > > allocated check. > > > > > > > > > > Regtested ok on f37/x86_64. Ok for master? > > > > > > > > > > Regards, > > > > > Andre > > > > > -- > > > > > Andre Vehreschild * Email: vehre ad gmx dot de > > > > > > > > > -- > > > Andre Vehreschild * Email: vehre ad gmx dot de > > > -- > Andre Vehreschild * Email: vehre ad gmx dot de -- Andre Vehreschild * Email: vehre ad gmx dot de
[PATCH] mingw-w64: avoid undefining _REENTRANT
When pthread is used by default, _REENTRANT should be defined in all
cases except -no-pthread. When pthread is not used by default,
_REENTRANT should only be defined with -pthread.
The current spec for mingw-w64 for default pthread is
%{!no-pthread:-D_REENTRANT} %{pthread:-U_REENTRANT}
and for non-default pthread is
%{pthread:-D_REENTRANT} %{!no-pthread:-U_REENTRANT}
This means that when pthread is used by default, specifying -pthread
undefines _REENTRANT! Applying the mingw32 specs instead produces the
desired result,
%{!no-pthread:-D_REENTRANT} %{pthread: }
for default pthread, and
%{pthread:-D_REENTRANT} %{!no-pthread: }
for non-default pthread.
gcc/ChangeLog:
* config/i386/mingw-w64.h (CPP_SPEC): Never undefine
_REENTRANT, only define it when appropriate.
Signed-off-by: Stephen Kitt
---
gcc/config/i386/mingw-w64.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/i386/mingw-w64.h b/gcc/config/i386/mingw-w64.h
index 0146ed4f793..39e7ec2ea1e 100644
--- a/gcc/config/i386/mingw-w64.h
+++ b/gcc/config/i386/mingw-w64.h
@@ -25,7 +25,7 @@ along with GCC; see the file COPYING3. If not see
#define CPP_SPEC "%{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} " \
"%{municode:-DUNICODE} " \
"%{" SPEC_PTHREAD1 ":-D_REENTRANT} " \
-"%{" SPEC_PTHREAD2 ":-U_REENTRANT} " \
+"%{" SPEC_PTHREAD2 ": } " \
"%{mcrtdll=crtdll*:-U__MSVCRT__ -D__CRTDLL__} " \
"%{mcrtdll=msvcrt10*:-D__MSVCRT_VERSION__=0x100} " \
"%{mcrtdll=msvcrt20*:-D__MSVCRT_VERSION__=0x200} " \
base-commit: 1e6815071fd137424f79ca79a6ba66b776a98778
--
2.30.2
[PATCH v3 2/2] RISC-V: Add support for XCValu extension in CV32E40P
Spec:
github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md
Contributors:
Mary Bennett
Nandni Jamnadas
Pietra Ferreira
Charlie Keaney
Jessica Mills
Craig Blackmore
Simon Cook
Jeremy Bennett
Helene Chelin
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: Add the XCValu
extension.
* config/riscv/constraints.md: Add builtins for the XCValu
extension.
* config/riscv/predicates.md (immediate_register_operand):
Likewise.
* config/riscv/corev.def: Likewise.
* config/riscv/corev.md: Likewise.
* config/riscv/riscv-builtins.cc (AVAIL): Likewise.
(RISCV_ATYPE_UHI): Likewise.
* config/riscv/riscv-ftypes.def: Likewise.
* config/riscv/riscv-opts.h: Likewise.
* config/riscv/riscv.opt: Likewise.
* config/riscv/riscv.cc (riscv_print_operand): Likewise.
* doc/extend.texi: Add XCValu documentation.
* doc/sourcebuild.texi: Likewise.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Add proc for the XCValu extension.
* gcc.target/riscv/cv-alu-compile.c: New test.
* gcc.target/riscv/cv-alu-fail-compile-addn.c: New test.
* gcc.target/riscv/cv-alu-fail-compile-addrn.c: New test.
* gcc.target/riscv/cv-alu-fail-compile-addun.c: New test.
* gcc.target/riscv/cv-alu-fail-compile-addurn.c: New test.
* gcc.target/riscv/cv-alu-fail-compile-clip.c: New test.
* gcc.target/riscv/cv-alu-fail-compile-clipu.c: New test.
* gcc.target/riscv/cv-alu-fail-compile-subn.c: New test.
* gcc.target/riscv/cv-alu-fail-compile-subrn.c: New test.
* gcc.target/riscv/cv-alu-fail-compile-subun.c: New test.
* gcc.target/riscv/cv-alu-fail-compile-suburn.c: New test.
* gcc.target/riscv/cv-alu-fail-compile.c: New test.
---
gcc/common/config/riscv/riscv-common.cc | 2 +
gcc/config/riscv/constraints.md | 7 +
gcc/config/riscv/corev.def| 24 ++
gcc/config/riscv/corev.md | 303 ++
gcc/config/riscv/predicates.md| 5 +
gcc/config/riscv/riscv-builtins.cc| 3 +
gcc/config/riscv/riscv-ftypes.def | 6 +
gcc/config/riscv/riscv-opts.h | 2 +
gcc/config/riscv/riscv.cc | 7 +
gcc/doc/extend.texi | 94 ++
gcc/doc/sourcebuild.texi | 3 +
.../gcc.target/riscv/cv-alu-compile.c | 252 +++
.../riscv/cv-alu-fail-compile-addn.c | 11 +
.../riscv/cv-alu-fail-compile-addrn.c | 11 +
.../riscv/cv-alu-fail-compile-addun.c | 11 +
.../riscv/cv-alu-fail-compile-addurn.c| 11 +
.../riscv/cv-alu-fail-compile-clip.c | 11 +
.../riscv/cv-alu-fail-compile-clipu.c | 11 +
.../riscv/cv-alu-fail-compile-subn.c | 11 +
.../riscv/cv-alu-fail-compile-subrn.c | 11 +
.../riscv/cv-alu-fail-compile-subun.c | 11 +
.../riscv/cv-alu-fail-compile-suburn.c| 11 +
.../gcc.target/riscv/cv-alu-fail-compile.c| 32 ++
gcc/testsuite/lib/target-supports.exp | 13 +
24 files changed, 863 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/cv-alu-compile.c
create mode 100644 gcc/testsuite/gcc.target/riscv/cv-alu-fail-compile-addn.c
create mode 100644 gcc/testsuite/gcc.target/riscv/cv-alu-fail-compile-addrn.c
create mode 100644 gcc/testsuite/gcc.target/riscv/cv-alu-fail-compile-addun.c
create mode 100644 gcc/testsuite/gcc.target/riscv/cv-alu-fail-compile-addurn.c
create mode 100644 gcc/testsuite/gcc.target/riscv/cv-alu-fail-compile-clip.c
create mode 100644 gcc/testsuite/gcc.target/riscv/cv-alu-fail-compile-clipu.c
create mode 100644 gcc/testsuite/gcc.target/riscv/cv-alu-fail-compile-subn.c
create mode 100644 gcc/testsuite/gcc.target/riscv/cv-alu-fail-compile-subrn.c
create mode 100644 gcc/testsuite/gcc.target/riscv/cv-alu-fail-compile-subun.c
create mode 100644 gcc/testsuite/gcc.target/riscv/cv-alu-fail-compile-suburn.c
create mode 100644 gcc/testsuite/gcc.target/riscv/cv-alu-fail-compile.c
diff --git a/gcc/common/config/riscv/riscv-common.cc
b/gcc/common/config/riscv/riscv-common.cc
index 53e21fa4bce..e7c1a99fbd2 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -311,6 +311,7 @@ static const struct riscv_ext_version
riscv_ext_version_table[] =
{"svpbmt", ISA_SPEC_CLASS_NONE, 1, 0},
{"xcvmac", ISA_SPEC_CLASS_NONE, 1, 0},
+ {"xcvalu", ISA_SPEC_CLASS_NONE, 1, 0},
{"xtheadba", ISA_SPEC_CLASS_NONE, 1, 0},
{"xtheadbb", ISA_SPEC_CLASS_NONE, 1, 0},
@@ -1483,6 +1484,7 @@ static const riscv_ext_flag_table_t
riscv_ext_flag_table[] =
{"ztso", _options::x_riscv_ztso_subext, MASK_ZTSO},
{"xcvmac",_options::x_riscv_xcv_flags, MASK_XCVMAC},
+ {"xcvalu",
[PATCH v3 1/2] RISC-V: Add support for XCVmac extension in CV32E40P
Spec: github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md Contributors: Mary Bennett Nandni Jamnadas Pietra Ferreira Charlie Keaney Jessica Mills Craig Blackmore Simon Cook Jeremy Bennett Helene Chelin gcc/ChangeLog: * common/config/riscv/riscv-common.cc: Add XCVmac. * config/riscv/riscv-ftypes.def: Add XCVmac builtins. * config/riscv/riscv-opts.h: Likewise. * config/riscv/riscv.md: Likewise. * config/riscv/riscv.opt: Likewise. * doc/extend.texi: Add XCVmac builtin documentation. * doc/sourcebuild.texi: Likewise. * config/riscv/corev.def: New file. * config/riscv/corev.md: New file. gcc/testsuite/ChangeLog: * lib/target-supports.exp: Add new effective target check. * gcc.target/riscv/cv-mac-compile.c: New test. * gcc.target/riscv/cv-mac-fail-compile-mac.c: New test. * gcc.target/riscv/cv-mac-fail-compile-machhsn.c: New test. * gcc.target/riscv/cv-mac-fail-compile-machhsrn.c: New test. * gcc.target/riscv/cv-mac-fail-compile-machhun.c: New test. * gcc.target/riscv/cv-mac-fail-compile-machhurn.c: New test. * gcc.target/riscv/cv-mac-fail-compile-macsn.c: New test. * gcc.target/riscv/cv-mac-fail-compile-macsrn.c: New test. * gcc.target/riscv/cv-mac-fail-compile-macun.c: New test. * gcc.target/riscv/cv-mac-fail-compile-macurn.c: New test. * gcc.target/riscv/cv-mac-fail-compile-msu.c: New test. * gcc.target/riscv/cv-mac-fail-compile-mulhhsn.c: New test. * gcc.target/riscv/cv-mac-fail-compile-mulhhsrn.c: New test. * gcc.target/riscv/cv-mac-fail-compile-mulhhun.c: New test. * gcc.target/riscv/cv-mac-fail-compile-mulhhurn.c: New test. * gcc.target/riscv/cv-mac-fail-compile-mulsn.c: New test. * gcc.target/riscv/cv-mac-fail-compile-mulsrn.c: New test. * gcc.target/riscv/cv-mac-fail-compile-mulun.c: New test. * gcc.target/riscv/cv-mac-fail-compile-mulurn.c: New test. * gcc.target/riscv/cv-mac-test-autogeneration.c: New test. --- gcc/common/config/riscv/riscv-common.cc | 4 + gcc/config/riscv/corev.def| 19 + gcc/config/riscv/corev.md | 390 ++ gcc/config/riscv/riscv-builtins.cc| 10 + gcc/config/riscv/riscv-ftypes.def | 5 + gcc/config/riscv/riscv-opts.h | 5 + gcc/config/riscv/riscv.md | 1 + gcc/config/riscv/riscv.opt| 3 + gcc/doc/extend.texi | 80 gcc/doc/sourcebuild.texi | 9 + .../gcc.target/riscv/cv-mac-compile.c | 198 + .../riscv/cv-mac-fail-compile-mac.c | 25 ++ .../riscv/cv-mac-fail-compile-machhsn.c | 24 ++ .../riscv/cv-mac-fail-compile-machhsrn.c | 24 ++ .../riscv/cv-mac-fail-compile-machhun.c | 24 ++ .../riscv/cv-mac-fail-compile-machhurn.c | 24 ++ .../riscv/cv-mac-fail-compile-macsn.c | 24 ++ .../riscv/cv-mac-fail-compile-macsrn.c| 24 ++ .../riscv/cv-mac-fail-compile-macun.c | 24 ++ .../riscv/cv-mac-fail-compile-macurn.c| 24 ++ .../riscv/cv-mac-fail-compile-msu.c | 25 ++ .../riscv/cv-mac-fail-compile-mulhhsn.c | 24 ++ .../riscv/cv-mac-fail-compile-mulhhsrn.c | 24 ++ .../riscv/cv-mac-fail-compile-mulhhun.c | 24 ++ .../riscv/cv-mac-fail-compile-mulhhurn.c | 24 ++ .../riscv/cv-mac-fail-compile-mulsn.c | 24 ++ .../riscv/cv-mac-fail-compile-mulsrn.c| 24 ++ .../riscv/cv-mac-fail-compile-mulun.c | 24 ++ .../riscv/cv-mac-fail-compile-mulurn.c| 24 ++ .../riscv/cv-mac-test-autogeneration.c| 18 + gcc/testsuite/lib/target-supports.exp | 13 + 31 files changed, 1189 insertions(+) create mode 100644 gcc/config/riscv/corev.def create mode 100644 gcc/config/riscv/corev.md create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mac-compile.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mac-fail-compile-mac.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mac-fail-compile-machhsn.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mac-fail-compile-machhsrn.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mac-fail-compile-machhun.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mac-fail-compile-machhurn.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mac-fail-compile-macsn.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mac-fail-compile-macsrn.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mac-fail-compile-macun.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mac-fail-compile-macurn.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mac-fail-compile-msu.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mac-fail-compile-mulhhsn.c create mode
[PATCH v3 0/2] RISC-V: Support CORE-V XCVMAC and XCVALU extensions
Thank you for reviewing this patch. v1->v2: * Add XCValu RTL. * Change assembly mnemonics from mixed case to lower case. v2->v3: * Change commit message from past tense to present. * Add documentation for new dg-effective-targets. This patch series presents the comprehensive implementation of the MAC and ALU extension for CORE-V. Tested with riscv-gnu-toolchain on binutils, ld, gas and gcc testsuites to ensure its correctness and compatibility with the existing codebase. However, your input, reviews, and suggestions are invaluable in making this extension even more robust. The CORE-V builtins are described in the specification [1] and work can be found in the OpenHW group's Github repository [2]. [1] github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md [2] github.com/openhwgroup/corev-gcc Contributors: Mary Bennett Nandni Jamnadas Pietra Ferreira Charlie Keaney Jessica Mills Craig Blackmore Simon Cook Jeremy Bennett Helene Chelin RISC-V: Add support for XCValu extension in CV32E40P RISC-V: Add support for XCVmac extension in CV32E40P gcc/common/config/riscv/riscv-common.cc | 6 + gcc/config/riscv/constraints.md | 7 + gcc/config/riscv/corev.def| 43 ++ gcc/config/riscv/corev.md | 693 ++ gcc/config/riscv/predicates.md| 5 + gcc/config/riscv/riscv-builtins.cc| 13 + gcc/config/riscv/riscv-ftypes.def | 11 + gcc/config/riscv/riscv-opts.h | 7 + gcc/config/riscv/riscv.cc | 7 + gcc/config/riscv/riscv.md | 1 + gcc/config/riscv/riscv.opt| 3 + gcc/doc/extend.texi | 174 + gcc/doc/sourcebuild.texi | 12 + .../gcc.target/riscv/cv-alu-compile.c | 252 +++ .../riscv/cv-alu-fail-compile-addn.c | 11 + .../riscv/cv-alu-fail-compile-addrn.c | 11 + .../riscv/cv-alu-fail-compile-addun.c | 11 + .../riscv/cv-alu-fail-compile-addurn.c| 11 + .../riscv/cv-alu-fail-compile-clip.c | 11 + .../riscv/cv-alu-fail-compile-clipu.c | 11 + .../riscv/cv-alu-fail-compile-subn.c | 11 + .../riscv/cv-alu-fail-compile-subrn.c | 11 + .../riscv/cv-alu-fail-compile-subun.c | 11 + .../riscv/cv-alu-fail-compile-suburn.c| 11 + .../gcc.target/riscv/cv-alu-fail-compile.c| 32 + .../gcc.target/riscv/cv-mac-compile.c | 198 + .../riscv/cv-mac-fail-compile-mac.c | 25 + .../riscv/cv-mac-fail-compile-machhsn.c | 24 + .../riscv/cv-mac-fail-compile-machhsrn.c | 24 + .../riscv/cv-mac-fail-compile-machhun.c | 24 + .../riscv/cv-mac-fail-compile-machhurn.c | 24 + .../riscv/cv-mac-fail-compile-macsn.c | 24 + .../riscv/cv-mac-fail-compile-macsrn.c| 24 + .../riscv/cv-mac-fail-compile-macun.c | 24 + .../riscv/cv-mac-fail-compile-macurn.c| 24 + .../riscv/cv-mac-fail-compile-msu.c | 25 + .../riscv/cv-mac-fail-compile-mulhhsn.c | 24 + .../riscv/cv-mac-fail-compile-mulhhsrn.c | 24 + .../riscv/cv-mac-fail-compile-mulhhun.c | 24 + .../riscv/cv-mac-fail-compile-mulhhurn.c | 24 + .../riscv/cv-mac-fail-compile-mulsn.c | 24 + .../riscv/cv-mac-fail-compile-mulsrn.c| 24 + .../riscv/cv-mac-fail-compile-mulun.c | 24 + .../riscv/cv-mac-fail-compile-mulurn.c| 24 + .../riscv/cv-mac-test-autogeneration.c| 18 + gcc/testsuite/lib/target-supports.exp | 26 + 46 files changed, 2052 insertions(+) create mode 100644 gcc/config/riscv/corev.def create mode 100644 gcc/config/riscv/corev.md create mode 100644 gcc/testsuite/gcc.target/riscv/cv-alu-compile.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-alu-fail-compile-addn.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-alu-fail-compile-addrn.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-alu-fail-compile-addun.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-alu-fail-compile-addurn.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-alu-fail-compile-clip.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-alu-fail-compile-clipu.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-alu-fail-compile-subn.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-alu-fail-compile-subrn.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-alu-fail-compile-subun.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-alu-fail-compile-suburn.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-alu-fail-compile.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mac-compile.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mac-fail-compile-mac.c create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mac-fail-compile-machhsn.c
Re: [PATCH] match.pd: Avoid another build_nonstandard_integer_type call [PR111369]
On Sat, Sep 30, 2023 at 11:44:59AM +0200, Jakub Jelinek wrote:
> I really can't figure out why one would need to add extra casts.
> type must be an integral type which has BIT_NOT_EXPR applied on it
> which yields all ones and we need a type in which negating 0 or 1
> range will yield 0 or all ones, I think all integral types satisfy
> that.
> This fixes PR111369, where one of the bitint*.c tests FAILs with
> GCC_TEST_RUN_EXPENSIVE=1.
Though, I think there is an preexisting issue which the
build_nonstandard_integer_type didn't help with; if type is signed 1-bit
precision, then I think a ? ~t : t could be valid, but -(type)a would invoke
UB if a is 1 - the cast would make it -1 and negation of -1 in signed 1-bit
invokes UB.
So perhaps we should guard this optimization on type having element precision >
1
or being unsigned. Plus the (convert:type @2) didn't make sense, @2 already
must have TREE_TYPE type.
So untested patch would be then:
2023-09-29 Jakub Jelinek
PR middle-end/111369
* match.pd (a?~t:t -> (-(a))^t): Always convert to type rather
than using build_nonstandard_integer_type. Punt if type is
signed 1-bit precision type.
--- gcc/match.pd.jj 2023-09-29 18:58:42.724956659 +0200
+++ gcc/match.pd2023-09-30 11:54:16.603280666 +0200
@@ -6741,13 +6741,9 @@ (define_operator_list SYNC_FETCH_AND_AND
(with { bool wascmp; }
(if (INTEGRAL_TYPE_P (type)
&& bitwise_inverted_equal_p (@1, @2, wascmp)
- && (!wascmp || element_precision (type) == 1))
- (with {
- auto prec = TYPE_PRECISION (type);
- auto unsign = TYPE_UNSIGNED (type);
- tree inttype = build_nonstandard_integer_type (prec, unsign);
-}
-(convert (bit_xor (negate (convert:inttype @0)) (convert:inttype @2)))
+ && (!wascmp || element_precision (type) == 1)
+ && (!TYPE_OVERFLOW_WRAPS (type) || element_precision (type) > 1))
+ (bit_xor (negate (convert:type @0)) @2
#endif
/* Simplify pointer equality compares using PTA. */
Jakub
[PATCH] match.pd: Avoid another build_nonstandard_integer_type call [PR111369]
Hi!
I really can't figure out why one would need to add extra casts.
type must be an integral type which has BIT_NOT_EXPR applied on it
which yields all ones and we need a type in which negating 0 or 1
range will yield 0 or all ones, I think all integral types satisfy
that.
This fixes PR111369, where one of the bitint*.c tests FAILs with
GCC_TEST_RUN_EXPENSIVE=1.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2023-09-30 Jakub Jelinek
PR middle-end/111369
* match.pd (a?~t:t -> (-(a))^t): Always convert to type rather
than using build_nonstandard_integer_type.
--- gcc/match.pd.jj 2023-09-28 11:32:16.122434235 +0200
+++ gcc/match.pd2023-09-29 18:05:50.554640268 +0200
@@ -6742,12 +6742,7 @@ (define_operator_list SYNC_FETCH_AND_AND
(if (INTEGRAL_TYPE_P (type)
&& bitwise_inverted_equal_p (@1, @2, wascmp)
&& (!wascmp || element_precision (type) == 1))
- (with {
- auto prec = TYPE_PRECISION (type);
- auto unsign = TYPE_UNSIGNED (type);
- tree inttype = build_nonstandard_integer_type (prec, unsign);
-}
-(convert (bit_xor (negate (convert:inttype @0)) (convert:inttype @2)))
+ (bit_xor (negate (convert:type @0)) (convert:type @2)
#endif
/* Simplify pointer equality compares using PTA. */
Jakub
[committed] gimple-match-head: Fix a pasto in function comment
Hi! This function comment has been pasted from gimple_bitwise_equal_p and haven't been adjusted for different function name. Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as obvious. 2023-09-30 Jakub Jelinek * gimple-match-head.cc (gimple_bitwise_inverted_equal_p): Fix a pasto in function comment. --- gcc/gimple-match-head.cc.jj 2023-08-11 09:27:36.292378545 +0200 +++ gcc/gimple-match-head.cc2023-09-29 18:03:34.535495052 +0200 @@ -274,7 +274,7 @@ gimple_bitwise_equal_p (tree expr1, tree bool gimple_bit_not_with_nop (tree, tree *, tree (*) (tree)); bool gimple_maybe_cmp (tree, tree *, tree (*) (tree)); -/* Helper function for bitwise_equal_p macro. */ +/* Helper function for bitwise_inverted_equal_p macro. */ static inline bool gimple_bitwise_inverted_equal_p (tree expr1, tree expr2, bool , tree (*valueize) (tree)) Jakub
[committed] lowerbitint: Fix 2 bitint lowering bugs [PR111625]
Hi!
This patch fixes 2 issues. One is when we want to get address of
an uninitialized large/huge bitint SSA_NAME for multiplication/division/modulo
or conversion to floating point (binary or decimal), the code just creates
an uninitialized limb sized variable and passes address of that, but I forgot
to initialize *prec in that case, so it invoked UB at compile time rather
than at runtime. As it is UB, we could use anything valid as precision there,
say 2 bits for signed, 1 bit for unsigned as smallest possible set of values,
or full bitint precision as full random value. Though, because we only pass
address to a single limb, I think it is best to pass the bitsize of the limb.
And the other issue is that when ranger in range_to_prec finds some range
is undefined_p (), it will assert {lower,upper}_bound () method isn't called
on it, but we were. So, the patch adjusts range_to_proc to treat it like
the !optimized case, full bitint precision.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2023-09-30 Jakub Jelinek
PR middle-end/111625
PR middle-end/111637
* gimple-lower-bitint.cc (range_to_prec): Use prec or -prec if
r.undefined_p ().
(bitint_large_huge::handle_operand_addr): For uninitialized operands
use limb_prec or -limb_prec precision.
--- gcc/gimple-lower-bitint.cc.jj 2023-09-20 09:45:39.0 +0200
+++ gcc/gimple-lower-bitint.cc 2023-09-29 16:29:36.541473743 +0200
@@ -1932,7 +1932,8 @@ range_to_prec (tree op, gimple *stmt)
unsigned int prec = TYPE_PRECISION (type);
if (!optimize
- || !get_range_query (cfun)->range_of_expr (r, op, stmt))
+ || !get_range_query (cfun)->range_of_expr (r, op, stmt)
+ || r.undefined_p ())
{
if (TYPE_UNSIGNED (type))
return prec;
@@ -2066,6 +2067,9 @@ bitint_large_huge::handle_operand_addr (
}
else if (gimple_code (g) == GIMPLE_NOP)
{
+ *prec = TYPE_UNSIGNED (TREE_TYPE (op)) ? limb_prec : -limb_prec;
+ if (prec_stored)
+ *prec_stored = *prec;
tree var = create_tmp_var (m_limb_type);
TREE_ADDRESSABLE (var) = 1;
ret = build_fold_addr_expr (var);
Jakub
