[PATCH] RISC-V: Add missing mode in bsetclr_zero_extract pattern
The following warning was encountered while building GCC, fix it: ../.././gcc/gcc/config/riscv/bitmanip.md:809:1: warning: source missing a mode? ../.././gcc/gcc/config/riscv/bitmanip.md:809:1: warning: source missing a mode? gcc/ChangeLog: * config/riscv/bitmanip.md (*bsetclr_zero_extract): (*bsetclr_zero_extract): Add missing mode in pattern. --- gcc/config/riscv/bitmanip.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/riscv/bitmanip.md b/gcc/config/riscv/bitmanip.md index 684e5d2ae8b6..1cc539a1729e 100644 --- a/gcc/config/riscv/bitmanip.md +++ b/gcc/config/riscv/bitmanip.md @@ -806,7 +806,7 @@ (match_dup 3)))]) ;; Yet another form of a bset/bclr that can be created by combine. -(define_insn "*bsetclr_zero_extract" +(define_insn "*bsetclr_zero_extract" [(set (zero_extract:X (match_operand:X 0 "register_operand" "+r") (const_int 1) (zero_extend:X -- 2.43.0
[PATCH] i386: Change RTL representation of bt[lq] [PR118623]
Hi!
The following testcase is miscompiled because of RTL represententation
of bt{l,q} insn followed by e.g. j{c,nc} being misleading to what it
actually does.
Let's look e.g. at
(define_insn_and_split "*jcc_bt"
[(set (pc)
(if_then_else (match_operator 0 "bt_comparison_operator"
[(zero_extract:SWI48
(match_operand:SWI48 1 "nonimmediate_operand")
(const_int 1)
(match_operand:QI 2 "nonmemory_operand"))
(const_int 0)])
(label_ref (match_operand 3))
(pc)))
(clobber (reg:CC FLAGS_REG))]
"(TARGET_USE_BT || optimize_function_for_size_p (cfun))
&& (CONST_INT_P (operands[2])
? (INTVAL (operands[2]) < GET_MODE_BITSIZE (mode)
&& INTVAL (operands[2])
>= (optimize_function_for_size_p (cfun) ? 8 : 32))
: !memory_operand (operands[1], mode))
&& ix86_pre_reload_split ()"
"#"
"&& 1"
[(set (reg:CCC FLAGS_REG)
(compare:CCC
(zero_extract:SWI48
(match_dup 1)
(const_int 1)
(match_dup 2))
(const_int 0)))
(set (pc)
(if_then_else (match_op_dup 0 [(reg:CCC FLAGS_REG) (const_int 0)])
(label_ref (match_dup 3))
(pc)))]
{
operands[0] = shallow_copy_rtx (operands[0]);
PUT_CODE (operands[0], reverse_condition (GET_CODE (operands[0])));
})
The define_insn part in RTL describes exactly what it does,
jumps to op3 if bit op2 in op1 is set (for op0 NE) or not set (for op0 EQ).
The problem is with what it splits into.
put_condition_code %C1 for CCCmode comparisons emits c for EQ and LTU,
nc for NE and GEU and ICEs otherwise.
CCCmode is used mainly for carry out of add/adc, borrow out of sub/sbb,
in those cases e.g. for add we have
(set (reg:CCC flags) (compare:CCC (plus:M x y) x))
and use (ltu (reg:CCC flags) (const_int 0)) for carry set and
(geu (reg:CCC flags) (const_int 0)) for carry not set. These cases
model in RTL what is actually happening, compare in infinite precision
x from the result of finite precision addition in M mode and if it is
less than unsigned (i.e. overflow happened), carry is set.
Another use of CCCmode is in UNSPEC_* patterns, those are used with
(eq (reg:CCC flags) (const_int 0)) for carry set and ne for unset,
given the UNSPEC no big deal, the middle-end doesn't know what means
set or unset.
But for the bt{l,q}; j{c,nc} case the above splits it into
(set (reg:CCC flags) (compare:CCC (zero_extract) (const_int 0)))
for bt and
(set (pc) (if_then_else (eq (reg:CCC flags) (const_int 0)) (label_ref) (pc)))
for the bit set case (so that the jump expands to jc) and ne for
the bit not set case (so that the jump expands to jnc).
Similarly for the different splitters for cmov and set{c,nc} etc.
The problem is that when the middle-end reads this RTL, it feels
the exact opposite to it. If zero_extract is 1, flags is set
to comparison of 1 and 0 and that would mean using ne ne in the
if_then_else, and vice versa.
So, in order to better describe in RTL what is actually happening,
one possibility would be to swap the behavior of put_condition_code
and use NE + LTU -> c and EQ + GEU -> nc rather than the current
EQ + LTU -> c and NE + GEU -> nc; and adjust everything. The
following patch uses a more limited approach, instead of representing
bt{l,q}; j{c,nc} case as written above it uses
(set (reg:CCC flags) (compare:CCC (const_int 0) (zero_extract)))
and
(set (pc) (if_then_else (ltu (reg:CCC flags) (const_int 0)) (label_ref) (pc)))
which uses the existing put_condition_code but describes what the
insns actually do in RTL clearly. If zero_extract is 1,
then flags are LTU, 0U < 1U, if zero_extract is 0, then flags are GEU,
0U >= 0U. The patch adjusts the *bt define_insn and all the
splitters to it and its comparisons/conditional moves/setXX.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-02-08 Jakub Jelinek
PR target/118623
* config/i386/i386.md (*bt): Represent bt as
compare:CCC of const0_rtx and zero_extract rather than
zero_extract and const0_rtx.
(*bt_mask): Likewise.
(*jcc_bt): Likewise. Use LTU and GEU as flags test
instead of EQ and NE.
(*jcc_bt_mask): Likewise.
(*jcc_bt_mask_1): Likewise.
(Help combine recognize bt followed by cmov splitter): Likewise.
(*bt_setcqi): Likewise.
(*bt_setncqi): Likewise.
(*bt_setnc): Likewise.
(*bt_setncqi_2): Likewise.
(*bt_setc_mask): Likewise.
* gcc.c-torture/execute/pr118623.c: New test.
--- gcc/config/i386/i386.md.jj 2025-02-07 22:11:49.444941171 +0100
+++ gcc/config/i386/i386.md 2025-02-07 22:32:19.640943663 +0100
@@ -19124,11 +19124,11 @@ (define_peephole2
(define_insn "*bt"
[(set (reg:CCC FLAGS_REG)
(compare:CCC
+ (const_int 0)
(zero_
'gcc.dg/pr88870.c': don't 'dg-require-effective-target nonlocal_goto' (was: [committed][testsuite] Add missing dg-require-effective-target nonlocal_goto)
Hi!
On 2019-06-20T12:39:48+0200, Tom de Vries wrote:
> Add missing dg-require-effective-target nonlocal_goto.
>
> Tested on nvptx.
> --- a/gcc/testsuite/gcc.dg/pr88870.c
> +++ b/gcc/testsuite/gcc.dg/pr88870.c
> @@ -1,5 +1,6 @@
> /* PR rtl-optimization/88870 */
> /* { dg-do compile } */
> +/* { dg-require-effective-target nonlocal_goto } */
> /* { dg-options "-O1 -fexceptions -fnon-call-exceptions -ftrapv
> -fno-tree-dominator-opts" } */
Pushed to trunk branch commit 0e602b2315f3cdf9a50441b28cabb8b204827492
"'gcc.dg/pr88870.c': don't 'dg-require-effective-target nonlocal_goto'",
see attached.
Grüße
Thomas
>From 0e602b2315f3cdf9a50441b28cabb8b204827492 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Thu, 6 Feb 2025 16:14:27 +0100
Subject: [PATCH] 'gcc.dg/pr88870.c': don't 'dg-require-effective-target
nonlocal_goto'
I confirm that back then, 'gcc.dg/pr88870.c' for nvptx failed due to
'sorry, unimplemented: target cannot support nonlocal goto', however at some
(indeterminate) point in time, that must've disappeared, and we now don't have
to 'dg-require-effective-target nonlocal_goto' anymore, and therefore get:
[-UNSUPPORTED:-]{+PASS:+} gcc.dg/pr88870.c {+(test for excess errors)+}
(And, if ever necessary again, this nowadays probably should
'dg-require-effective-target exceptions' instead of 'nonlocal_goto'.)
gcc/testsuite/
* gcc.dg/pr88870.c: Don't 'dg-require-effective-target nonlocal_goto'.
---
gcc/testsuite/gcc.dg/pr88870.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/pr88870.c b/gcc/testsuite/gcc.dg/pr88870.c
index 81f686bd972..3f46f32f3ee 100644
--- a/gcc/testsuite/gcc.dg/pr88870.c
+++ b/gcc/testsuite/gcc.dg/pr88870.c
@@ -1,6 +1,5 @@
/* PR rtl-optimization/88870 */
/* { dg-do compile } */
-/* { dg-require-effective-target nonlocal_goto } */
/* { dg-options "-O1 -fexceptions -fnon-call-exceptions -ftrapv -fno-tree-dominator-opts" } */
int a, b;
--
2.34.1
Clarify that effective-targets 'exceptions' and 'exceptions_enabled' are orthogonal (was: [PATCH v2][MSP430] -Add fno-exceptions multilib)
Hi!
On 2019-11-27T19:53:32+, Jozef Lawrynowicz wrote:
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
| # Return 1 if -fexceptions is supported.
|
| proc check_effective_target_exceptions {} {
| if { [istarget amdgcn*-*-*] } {
| return 0
| }
> return 1
> }
>
> +# Used to check if the testing configuration supports exceptions.
> +# Returns 0 if exceptions are unsupported or disabled (e.g. by passing
> +# -fno-exceptions). Returns 1 if exceptions are enabled.
> +proc check_effective_target_exceptions_enabled {} {
> +return [check_cached_effective_target exceptions_enabled {
> + if { [check_effective_target_exceptions] } {
> + return [check_no_compiler_messages exceptions_enabled assembly {
> + void foo (void)
> + {
> + throw 1;
> + }
> + }]
> + } else {
> + # If exceptions aren't supported, then they're not enabled.
> + return 0
> + }
> +}]
> +}
Pushed to trunk branch commit 9f4feba699f3b3fef29bc8199db69a8eb7d64d07
"Clarify that effective-targets 'exceptions' and 'exceptions_enabled' are
orthogonal",
see attached.
Grüße
Thomas
>From 9f4feba699f3b3fef29bc8199db69a8eb7d64d07 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Thu, 6 Feb 2025 22:46:51 +0100
Subject: [PATCH] Clarify that effective-targets 'exceptions' and
'exceptions_enabled' are orthogonal
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
In Subversion r268025 (Git commit 3f21b8e3f7be32dd2b3624a2ece12f84bed545bb)
"Add dg-require-effective-target exceptions", effective-target 'exceptions'
was added, which "says that AMD GCN does not support [exception handling]".
In Subversion r279246 (Git commit a9046e9853024206bec092dd63e21e152cb5cbca)
"MSP430: Add -fno-exceptions multilib", effective-target 'exceptions_enabled'
was added "to check if the testing configuration supports exceptions". Testing
"if exceptions are unsupported or disabled (e.g. by passing -fno-exceptions)"
works as expected if exception handling is disabled at the front-end level
('-fno-exceptions'; the "exceptions are [...] disabled" case):
exceptions_enabled2066068.cc: In function ‘void foo()’:
exceptions_enabled2066068.cc:3:27: error: exception handling disabled, use ‘-fexceptions’ to enable
However, effective-target 'exceptions_enabled' additionally assumes that
"If exceptions aren't supported [by the target], then they're not enabled".
This is not correct: it's not unlikely that, in presence of explicit/implicit
'-fexceptions', exception handling code gets fully optimized away by the
compiler, and therefore effective-target 'exceptions_enabled' test cases may
PASS even for targets that don't support effective-target 'exceptions'; these
two effective-targets are orthogonal concepts.
(For completeness: code with trivial instances of C++ exception handling may
translate into simple '__cxa_allocate_exception', '__cxa_throw' function calls
without requiring any back end-level "exceptions magic", and then trigger
unresolved symbols at link time, if these functions are not available.)
This change only affects GCN, as that one currently is the only target declared
as not supporting effective-target 'exceptions'.
gcc/
* doc/sourcebuild.texi (Effective-Target Keywords): Clarify that
effective-target 'exceptions' and 'exceptions_enabled' are
orthogonal.
gcc/testsuite/
* lib/gcc-dg.exp (gcc-dg-prune): Clarify effective-target
'exceptions_enabled'.
* lib/target-supports.exp
(check_effective_target_exceptions_enabled): Don't consider
effective-target 'exceptions'.
libstdc++-v3/
* testsuite/lib/prune.exp (libstdc++-dg-prune): Clarify
effective-target 'exceptions_enabled'.
---
gcc/doc/sourcebuild.texi | 7 ---
gcc/testsuite/lib/gcc-dg.exp | 3 +--
gcc/testsuite/lib/target-supports.exp | 30 +--
libstdc++-v3/testsuite/lib/prune.exp | 3 +--
4 files changed, 20 insertions(+), 23 deletions(-)
diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 98ede70f23c..797775e90de 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -2996,11 +2996,12 @@ Target uses @code{__cxa_atexit}.
Target has packed layout of structure members by default.
@item exceptions
-Target supports exceptions.
+Target supports exception handling.
+Note that this is orthogonal to effective-target @code{exceptions_enabled}.
@item exceptions_enabled
-Target supports exceptions and they are enabled in the current
-testing configuration.
+Testing configuration has exception handling enabled.
+Note that this is orthogonal to effective-target @code{exceptions}.
@item fgraphite
Target supports Graphite optimizations.
diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index 65a5f3f1dbe..07a996a4466 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/l
BPF doesn't actually support effective-target 'exceptions' [PR118772] (was: [PATCH 22/25] Add dg-require-effective-target exceptions)
Hi!
On 2018-09-05T12:52:10+0100, wrote:
> There are a number of tests that fail because they assume that exceptions are
> available, but GCN does not support them, yet.
Pushed to trunk branch commit e90276a4831553268f3dd4917d7b6ae9c08dbf0f
"BPF doesn't actually support effective-target 'exceptions' [PR118772]",
see attached.
Grüße
Thomas
> This patch adds "dg-require-effective-target exceptions" in all the affected
> tests. There's probably an automatic way to test for exceptions, but the
> current implementation simply says that AMD GCN does not support them. This
> should ensure that no other targets are affected by the change.
>
> 2018-09-05 Andrew Stubbs
> Kwok Cheung Yeung
> Julian Brown
> Tom de Vries
>
> gcc/testsuite/
> * c-c++-common/ubsan/pr71512-1.c: Require exceptions.
> * c-c++-common/ubsan/pr71512-2.c: Require exceptions.
> * gcc.c-torture/compile/pr34648.c: Require exceptions.
> * gcc.c-torture/compile/pr41469.c: Require exceptions.
> * gcc.dg/20111216-1.c: Require exceptions.
> * gcc.dg/cleanup-10.c: Require exceptions.
> * gcc.dg/cleanup-11.c: Require exceptions.
> * gcc.dg/cleanup-12.c: Require exceptions.
> * gcc.dg/cleanup-13.c: Require exceptions.
> * gcc.dg/cleanup-5.c: Require exceptions.
> * gcc.dg/cleanup-8.c: Require exceptions.
> * gcc.dg/cleanup-9.c: Require exceptions.
> * gcc.dg/gomp/pr29955.c: Require exceptions.
> * gcc.dg/lto/pr52097_0.c: Require exceptions.
> * gcc.dg/nested-func-5.c: Require exceptions.
> * gcc.dg/pch/except-1.c: Require exceptions.
> * gcc.dg/pch/valid-2.c: Require exceptions.
> * gcc.dg/pr41470.c: Require exceptions.
> * gcc.dg/pr42427.c: Require exceptions.
> * gcc.dg/pr44545.c: Require exceptions.
> * gcc.dg/pr47086.c: Require exceptions.
> * gcc.dg/pr51481.c: Require exceptions.
> * gcc.dg/pr51644.c: Require exceptions.
> * gcc.dg/pr52046.c: Require exceptions.
> * gcc.dg/pr54669.c: Require exceptions.
> * gcc.dg/pr56424.c: Require exceptions.
> * gcc.dg/pr64465.c: Require exceptions.
> * gcc.dg/pr65802.c: Require exceptions.
> * gcc.dg/pr67563.c: Require exceptions.
> * gcc.dg/tree-ssa/pr41469-1.c: Require exceptions.
> * gcc.dg/tree-ssa/ssa-dse-28.c: Require exceptions.
> * gcc.dg/vect/pr46663.c: Require exceptions.
> * lib/target-supports.exp (check_effective_target_exceptions): New.
> ---
> gcc/testsuite/c-c++-common/ubsan/pr71512-1.c | 1 +
> gcc/testsuite/c-c++-common/ubsan/pr71512-2.c | 1 +
> gcc/testsuite/gcc.c-torture/compile/pr34648.c | 1 +
> gcc/testsuite/gcc.c-torture/compile/pr41469.c | 1 +
> gcc/testsuite/gcc.dg/20111216-1.c | 1 +
> gcc/testsuite/gcc.dg/cleanup-10.c | 1 +
> gcc/testsuite/gcc.dg/cleanup-11.c | 1 +
> gcc/testsuite/gcc.dg/cleanup-12.c | 1 +
> gcc/testsuite/gcc.dg/cleanup-13.c | 1 +
> gcc/testsuite/gcc.dg/cleanup-5.c | 1 +
> gcc/testsuite/gcc.dg/cleanup-8.c | 1 +
> gcc/testsuite/gcc.dg/cleanup-9.c | 1 +
> gcc/testsuite/gcc.dg/gomp/pr29955.c | 1 +
> gcc/testsuite/gcc.dg/lto/pr52097_0.c | 1 +
> gcc/testsuite/gcc.dg/nested-func-5.c | 1 +
> gcc/testsuite/gcc.dg/pch/except-1.c | 1 +
> gcc/testsuite/gcc.dg/pch/valid-2.c| 2 +-
> gcc/testsuite/gcc.dg/pr41470.c| 1 +
> gcc/testsuite/gcc.dg/pr42427.c| 1 +
> gcc/testsuite/gcc.dg/pr44545.c| 1 +
> gcc/testsuite/gcc.dg/pr47086.c| 1 +
> gcc/testsuite/gcc.dg/pr51481.c| 1 +
> gcc/testsuite/gcc.dg/pr51644.c| 1 +
> gcc/testsuite/gcc.dg/pr52046.c| 1 +
> gcc/testsuite/gcc.dg/pr54669.c| 1 +
> gcc/testsuite/gcc.dg/pr56424.c| 1 +
> gcc/testsuite/gcc.dg/pr64465.c| 1 +
> gcc/testsuite/gcc.dg/pr65802.c| 1 +
> gcc/testsuite/gcc.dg/pr67563.c| 1 +
> gcc/testsuite/gcc.dg/tree-ssa/pr41469-1.c | 1 +
> gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-28.c| 1 +
> gcc/testsuite/gcc.dg/vect/pr46663.c | 1 +
> gcc/testsuite/lib/target-supports.exp | 10 ++
> 33 files changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/c-c++-common/ubsan/pr71512-1.c
> b/gcc/testsuite/c-c++-common/ubsan/pr71512-1.c
> index 2a90ab1..8af9365 100644
> --- a/gcc/testsuite/c-c++-common/ubsan/pr71512-1.c
> +++ b/gcc/testsuite/c-c++-common/ubsan/pr71512-1.c
> @@ -1,5 +1,6 @@
> /* PR c/71512 */
> /* { dg-do compile } */
> /* { dg-options "-O2 -fnon-call-exceptions -ftrapv -fexceptions
> -fsanitize=undefined" } */
> +/* { dg-require-effective-target exceptions } */
>
> #include "../../gcc.dg/pr44545.c"
> diff --git a/gcc/testsuite/c-c++-common
nvptx doesn't actually support effective-target 'exceptions' (was: [PATCH 22/25] Add dg-require-effective-target exceptions)
Hi!
On 2018-09-05T12:52:10+0100, wrote:
> There are a number of tests that fail because they assume that exceptions are
> available, but GCN does not support them, yet.
Pushed to trunk branch commit 2466b0b4d9bcfe51c1a049c3d7f6a8043d68630e
"nvptx doesn't actually support effective-target 'exceptions'", see
attached.
Grüße
Thomas
> This patch adds "dg-require-effective-target exceptions" in all the affected
> tests. There's probably an automatic way to test for exceptions, but the
> current implementation simply says that AMD GCN does not support them. This
> should ensure that no other targets are affected by the change.
>
> 2018-09-05 Andrew Stubbs
> Kwok Cheung Yeung
> Julian Brown
> Tom de Vries
>
> gcc/testsuite/
> * c-c++-common/ubsan/pr71512-1.c: Require exceptions.
> * c-c++-common/ubsan/pr71512-2.c: Require exceptions.
> * gcc.c-torture/compile/pr34648.c: Require exceptions.
> * gcc.c-torture/compile/pr41469.c: Require exceptions.
> * gcc.dg/20111216-1.c: Require exceptions.
> * gcc.dg/cleanup-10.c: Require exceptions.
> * gcc.dg/cleanup-11.c: Require exceptions.
> * gcc.dg/cleanup-12.c: Require exceptions.
> * gcc.dg/cleanup-13.c: Require exceptions.
> * gcc.dg/cleanup-5.c: Require exceptions.
> * gcc.dg/cleanup-8.c: Require exceptions.
> * gcc.dg/cleanup-9.c: Require exceptions.
> * gcc.dg/gomp/pr29955.c: Require exceptions.
> * gcc.dg/lto/pr52097_0.c: Require exceptions.
> * gcc.dg/nested-func-5.c: Require exceptions.
> * gcc.dg/pch/except-1.c: Require exceptions.
> * gcc.dg/pch/valid-2.c: Require exceptions.
> * gcc.dg/pr41470.c: Require exceptions.
> * gcc.dg/pr42427.c: Require exceptions.
> * gcc.dg/pr44545.c: Require exceptions.
> * gcc.dg/pr47086.c: Require exceptions.
> * gcc.dg/pr51481.c: Require exceptions.
> * gcc.dg/pr51644.c: Require exceptions.
> * gcc.dg/pr52046.c: Require exceptions.
> * gcc.dg/pr54669.c: Require exceptions.
> * gcc.dg/pr56424.c: Require exceptions.
> * gcc.dg/pr64465.c: Require exceptions.
> * gcc.dg/pr65802.c: Require exceptions.
> * gcc.dg/pr67563.c: Require exceptions.
> * gcc.dg/tree-ssa/pr41469-1.c: Require exceptions.
> * gcc.dg/tree-ssa/ssa-dse-28.c: Require exceptions.
> * gcc.dg/vect/pr46663.c: Require exceptions.
> * lib/target-supports.exp (check_effective_target_exceptions): New.
> ---
> gcc/testsuite/c-c++-common/ubsan/pr71512-1.c | 1 +
> gcc/testsuite/c-c++-common/ubsan/pr71512-2.c | 1 +
> gcc/testsuite/gcc.c-torture/compile/pr34648.c | 1 +
> gcc/testsuite/gcc.c-torture/compile/pr41469.c | 1 +
> gcc/testsuite/gcc.dg/20111216-1.c | 1 +
> gcc/testsuite/gcc.dg/cleanup-10.c | 1 +
> gcc/testsuite/gcc.dg/cleanup-11.c | 1 +
> gcc/testsuite/gcc.dg/cleanup-12.c | 1 +
> gcc/testsuite/gcc.dg/cleanup-13.c | 1 +
> gcc/testsuite/gcc.dg/cleanup-5.c | 1 +
> gcc/testsuite/gcc.dg/cleanup-8.c | 1 +
> gcc/testsuite/gcc.dg/cleanup-9.c | 1 +
> gcc/testsuite/gcc.dg/gomp/pr29955.c | 1 +
> gcc/testsuite/gcc.dg/lto/pr52097_0.c | 1 +
> gcc/testsuite/gcc.dg/nested-func-5.c | 1 +
> gcc/testsuite/gcc.dg/pch/except-1.c | 1 +
> gcc/testsuite/gcc.dg/pch/valid-2.c| 2 +-
> gcc/testsuite/gcc.dg/pr41470.c| 1 +
> gcc/testsuite/gcc.dg/pr42427.c| 1 +
> gcc/testsuite/gcc.dg/pr44545.c| 1 +
> gcc/testsuite/gcc.dg/pr47086.c| 1 +
> gcc/testsuite/gcc.dg/pr51481.c| 1 +
> gcc/testsuite/gcc.dg/pr51644.c| 1 +
> gcc/testsuite/gcc.dg/pr52046.c| 1 +
> gcc/testsuite/gcc.dg/pr54669.c| 1 +
> gcc/testsuite/gcc.dg/pr56424.c| 1 +
> gcc/testsuite/gcc.dg/pr64465.c| 1 +
> gcc/testsuite/gcc.dg/pr65802.c| 1 +
> gcc/testsuite/gcc.dg/pr67563.c| 1 +
> gcc/testsuite/gcc.dg/tree-ssa/pr41469-1.c | 1 +
> gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-28.c| 1 +
> gcc/testsuite/gcc.dg/vect/pr46663.c | 1 +
> gcc/testsuite/lib/target-supports.exp | 10 ++
> 33 files changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/c-c++-common/ubsan/pr71512-1.c
> b/gcc/testsuite/c-c++-common/ubsan/pr71512-1.c
> index 2a90ab1..8af9365 100644
> --- a/gcc/testsuite/c-c++-common/ubsan/pr71512-1.c
> +++ b/gcc/testsuite/c-c++-common/ubsan/pr71512-1.c
> @@ -1,5 +1,6 @@
> /* PR c/71512 */
> /* { dg-do compile } */
> /* { dg-options "-O2 -fnon-call-exceptions -ftrapv -fexceptions
> -fsanitize=undefined" } */
> +/* { dg-require-effective-target exceptions } */
>
> #include "../../gcc.dg/pr44545.c"
> diff --git a/gcc/testsuite/c-c++-common/ubsan/pr
[PUSHED] For a few test cases, clarify dependance on effective-target 'nonlocal_goto' into 'exceptions'
For example, for nvptx, these test cases currently indeed fail with
'sorry, unimplemented: target cannot support nonlocal goto'. However,
that's just an artefact of non-existing support for exception handling,
and these test cases already require effective-target 'exceptions'.
gcc/testsuite/
* gcc.dg/cleanup-12.c: Don't 'dg-skip-if "" { ! nonlocal_goto }'.
* gcc.dg/cleanup-13.c: Likewise.
* gcc.dg/cleanup-5.c: Likewise.
* gcc.dg/gimplefe-44.c: Don't
'dg-require-effective-target nonlocal_goto'.
---
gcc/testsuite/gcc.dg/cleanup-12.c | 1 -
gcc/testsuite/gcc.dg/cleanup-13.c | 1 -
gcc/testsuite/gcc.dg/cleanup-5.c | 1 -
gcc/testsuite/gcc.dg/gimplefe-44.c | 1 -
4 files changed, 4 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/cleanup-12.c
b/gcc/testsuite/gcc.dg/cleanup-12.c
index 2171e35de9d..5bc7216af67 100644
--- a/gcc/testsuite/gcc.dg/cleanup-12.c
+++ b/gcc/testsuite/gcc.dg/cleanup-12.c
@@ -3,7 +3,6 @@
/* { dg-do run } */
/* { dg-options "-O2 -fexceptions" } */
/* { dg-skip-if "" { "ia64-*-hpux11.*" } } */
-/* { dg-skip-if "" { ! nonlocal_goto } } */
/* { dg-require-effective-target exceptions } */
/* Verify unwind info in presence of alloca. */
diff --git a/gcc/testsuite/gcc.dg/cleanup-13.c
b/gcc/testsuite/gcc.dg/cleanup-13.c
index 86cfae09e77..6d2adcac430 100644
--- a/gcc/testsuite/gcc.dg/cleanup-13.c
+++ b/gcc/testsuite/gcc.dg/cleanup-13.c
@@ -6,7 +6,6 @@
/* { dg-do run } */
/* { dg-options "-fexceptions" } */
/* { dg-skip-if "" { "ia64-*-hpux11.*" } } */
-/* { dg-skip-if "" { ! nonlocal_goto } } */
/* { dg-require-effective-target exceptions } */
/* Verify DW_OP_* handling in the unwinder. */
diff --git a/gcc/testsuite/gcc.dg/cleanup-5.c b/gcc/testsuite/gcc.dg/cleanup-5.c
index 9ed2a7c95f5..43e8686ab2b 100644
--- a/gcc/testsuite/gcc.dg/cleanup-5.c
+++ b/gcc/testsuite/gcc.dg/cleanup-5.c
@@ -2,7 +2,6 @@
/* { dg-do run } */
/* { dg-options "-fexceptions" } */
/* { dg-skip-if "" { "ia64-*-hpux11.*" } } */
-/* { dg-skip-if "" { ! nonlocal_goto } } */
/* { dg-require-effective-target exceptions } */
/* Verify that cleanups work with exception handling. */
diff --git a/gcc/testsuite/gcc.dg/gimplefe-44.c
b/gcc/testsuite/gcc.dg/gimplefe-44.c
index 3c83d4946f2..a1e32ad6927 100644
--- a/gcc/testsuite/gcc.dg/gimplefe-44.c
+++ b/gcc/testsuite/gcc.dg/gimplefe-44.c
@@ -1,7 +1,6 @@
/* { dg-do compile } */
/* { dg-require-effective-target exceptions } */
/* { dg-options "-fexceptions -fgimple -fdump-tree-eh-eh" } */
-/* { dg-require-effective-target nonlocal_goto } */
void __GIMPLE foo()
{
--
2.34.1
Allow to build libgccjit with a soname bound to the GCC major version
When configuring GCC with --program-suffix=-$(BASE_VERSION) to allow installation multiple GCC versions in parallel, the executable of the driver (gcc-$(BASE_VERSION)) gets recorded in the libgccjit.so.0 library. Assuming, that you only install the libgccjit.so.0 library from the newest GCC, you have a libgccjit installed, which always calls back to the newest installed version of GCC. I'm not saying that the ABI is changing, but I'd like to see the libgccjit calling out to the corresponding compiler, and therefore installing a libgccjit with a soname that matches the GCC major version. The downside is having to rebuild packages built against libgccjit with each major GCC version, but looking at the reverse dependencies, at least for package builds, only emacs is using libgccjit. My plan to use this feature is to build a libgccjit0 using the default GCC (e.g. gcc-14), and a libgccjit15, when building a newer GCC. When changing the GCC default to 15, building a libgccjit0 from gcc-15, and a libgccjit14 from gcc-14. When configuring without --enable-versioned-jit, the behavior is unchanged. Ok for the trunk? Matthias * configure.ac: Add option --enable-versioned-jit. * jit/Make-lang.in (LIBGCCJIT_VERSION_NUM): Move to ... * Makefile.in: ... here, setting value from configure.ac. * doc/install.texi: Document option --enable-versioned-jit. --- a/src/gcc/configure.ac +++ b/src/gcc/configure.ac @@ -7738,6 +7738,21 @@ cat > gcc-driver-name.h <
Re: [committed][rtl-optimization/116244] Don't create bogus regs in alter_subreg
Am 08.02.25 um 18:23 schrieb Jeff Law:
On 2/8/25 3:04 AM, Georg-Johann Lay wrote:
That test case from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116389#c7
still ICEs with that change in http://gcc.gnu.org/r15-7428
pr116389-red.c: In function 'func':
pr116389-red.c:20:1: error: insn does not satisfy its constraints:
20 | }
| ^
(insn 27 69 28 5 (set (mem/c:SI (plus:HI (reg/f:HI 28 r28)
(const_int 2 [0x2])) [4 %sfp+2 S4 A8])
(reg:SI 30 r30)) "pr116389-red.c":16:19 146 {*movsi_split}
(nil))
during RTL pass: postreload
pr116389-red.c:20:1: internal compiler error: in
extract_constrain_insn, at recog.cc:2783
Reason is that R30 is the last GPR and can hold HImode at most,
but due to a paradoxical subreg, there is r30:SI.
Bummer as that was the kind of scenario it's supposed to fix.
What did that insn look like before IRA and for whatever pseudo was in
that operand, what hard register did IRA think it should be allocated to?
jeff
The .ira dump has several paradoxical subregs like:
(insn 22 21 60 4 (set (reg/v:SI 51 [ val32 ])
(subreg:SI (reg:HI 53 [ t$val ]) 0)) "pr116389-red.c":14:14 146
{*movsi_split}
(insn 27 26 28 5 (set (reg/v:SI 51 [ val32 ])
(subreg:SI (reg/v:HI 52 [ diff ]) 0)) "pr116389-red.c":16:19
146 {*movsi_split}
(insn 35 34 36 7 (set (reg:HI 54 [ _7 ])
(ashift:HI (subreg:HI (reg/v:SI 51 [ val32 ]) 0)
(const_int 1 [0x1]))) "pr116389-red.c":18:13 667 {ashlhi3}
I don't know which one is causing the trouble. Maybe the attached
dumps will help.
Johann
;; Function func (func, funcdef_no=0, decl_uid=1937, cgraph_uid=1,
symbol_order=0)
Starting decreasing number of live ranges...
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2 3 4 5 6 7 8
;; 2 succs { 3 8 }
;; 3 succs { 5 4 }
;; 4 succs { 6 }
;; 5 succs { 6 }
;; 6 succs { 7 8 }
;; 7 succs { 8 }
;; 8 succs { 1 }
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
Reg 56 uninteresting
Reg 53: def dominates all uses has unique first use
Reg 57: local to bb 2 def dominates all uses has unique first use
Reg 55 uninteresting
Reg 52: def dominates all uses has unique first use
Reg 58 uninteresting
Reg 59 uninteresting
Reg 54 uninteresting
Reg 52 not local to one basic block
Reg 53 not local to one basic block
Found def insn 57 for 57 to be not moveable
Building IRA IR
verify found no changes in insn with uid = 6.
verify found no changes in insn with uid = 9.
verify found no changes in insn with uid = 18.
verify found no changes in insn with uid = 30.
verify found no changes in insn with uid = 37.
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
init_insns for 55: (insn_list:REG_DEP_TRUE 62 (nil))
Reg 55 had equivalence, but can't be eliminated
Pass 0 for finding pseudo/allocno costs
a2 (r59,l0) best GENERAL_REGS, allocno GENERAL_REGS
a5 (r58,l0) best GENERAL_REGS, allocno GENERAL_REGS
a7 (r57,l0) best GENERAL_REGS, allocno GENERAL_REGS
a8 (r56,l0) best POINTER_REGS, allocno POINTER_REGS
a6 (r55,l0) best GENERAL_REGS, allocno GENERAL_REGS
a0 (r54,l0) best GENERAL_REGS, allocno GENERAL_REGS
a4 (r53,l0) best GENERAL_REGS, allocno GENERAL_REGS
a3 (r52,l0) best GENERAL_REGS, allocno GENERAL_REGS
a1 (r51,l0) best GENERAL_REGS, allocno GENERAL_REGS
a0(r54,l0) costs: POINTER_X_REGS:2000 POINTER_Z_REGS:2000 POINTER_REGS:2000
ADDW_REGS:2000 SIMPLE_LD_REGS:2000 GENERAL_REGS:2000 MEM:8000
a1(r51,l0) costs: ADDW_REGS:0 SIMPLE_LD_REGS:0 GENERAL_REGS:0 MEM:6000
a2(r59,l0) costs: POINTER_X_REGS:2000 POINTER_Z_REGS:2000 POINTER_REGS:2000
ADDW_REGS:2000 SIMPLE_LD_REGS:2000 GENERAL_REGS:2000 MEM:8000
a3(r52,l0) costs: ADDW_REGS:6000 SIMPLE_LD_REGS:6000 GENERAL_REGS:6000
MEM:11000
a4(r53,l0) costs: ADDW_REGS:0 SIMPLE_LD_REGS:0 GENERAL_REGS:0 MEM:5000
a5(r58,l0) costs: POINTER_X_REGS:2000 POINTER_Z_REGS:2000 POINTER_REGS:2000
ADDW_REGS:2000 SIMPLE_LD_REGS:2000 GENERAL_REGS:2000 MEM:8000
a6(r55,l0) costs: POINTER_X_REGS:8000 POINTER_Z_REGS:8000 POINTER_REGS:8000
ADDW_REGS:8000 SIMPLE_LD_REGS:8000 GENERAL_REGS:8000 MEM:2
a7(r57,l0) costs: POINTER_X_REGS:8000 POINTER_Z_REGS:8000 POINTER_REGS:8000
ADDW_REGS:8000 SIMPLE_LD_REGS:8000 GENERAL_REGS:8000 MEM:18000
a8(r56,l0) costs: POINTER_X_REGS:2000 POINTER_Z_REGS:2000 POINTER_REGS:2000
ADDW_REGS:4000 SIMPLE_LD_REGS:4000 GENERAL_REGS:4000 MEM:8000
Pass 1 for finding pseudo/allocno costs
r59: preferred GENERAL_REGS, alternative NO_REGS, allocno GENERAL_REGS
r58: preferred GENERAL_REGS, alternative NO_REGS, allocno GENERAL_REGS
r57: preferred GENERAL_REGS, alternative NO_REGS, allocno GENERAL_REGS
r56: preferred POINTER_REGS, alternative GENERAL_REGS, allocno GENERAL_REGS
r55: preferred GENERAL_REGS, alt
[patch,avr,applied] Fix typos in extend.texi
Fixed typos in extend.texi.
Applied as as obvious.
Johann
--
ad target/118764: Fix a typo in doc/extend.texi.
gcc/
PR target/118764
* doc/invoke.texi (AVR Options): Fix typos.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index c33eb4425de..0aef2abf05b 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -24394,12 +24394,12 @@ Apart from providing a compact vector table,
the startup code will set bit
@code{CPUINT_CTRLA.CPUINT_CVT} which enables the CVT on the device.
When you do not want the startup code to set
@code{CPUINT_CTRLA.CPUINT_CVT},
-then you can satisfy symbol @code{__do_cvt_init} so that the respective
+then you can satisfy symbol @code{__init_cvt} so that the respective
code is no more pulled in from @code{lib@var{mcu}.a}.
-For example, you can link with @code{-Wl,--defsym,__do_cvt_init=0}.
+For example, you can link with @code{-Wl,--defsym,__init_cvt=0}.
The CVT startup code is available since
-@w{@uref{https://github.com/avrdudes/avr-libc/issues/1010,AVR-LibC #1010}}.
+@w{@uref{https://github.com/avrdudes/avr-libc/issues/1010,AVR-LibC v2.3}}.
@opindex mfuse-add
@item -mfuse-add
Re: [committed][rtl-optimization/116244] Don't create bogus regs in alter_subreg
On 2/8/25 1:52 PM, Georg-Johann Lay wrote:
Am 08.02.25 um 18:23 schrieb Jeff Law:
On 2/8/25 3:04 AM, Georg-Johann Lay wrote:
That test case from https://gcc.gnu.org/bugzilla/show_bug.cgi?
id=116389#c7
still ICEs with that change in http://gcc.gnu.org/r15-7428
pr116389-red.c: In function 'func':
pr116389-red.c:20:1: error: insn does not satisfy its constraints:
20 | }
| ^
(insn 27 69 28 5 (set (mem/c:SI (plus:HI (reg/f:HI 28 r28)
(const_int 2 [0x2])) [4 %sfp+2 S4 A8])
(reg:SI 30 r30)) "pr116389-red.c":16:19 146 {*movsi_split}
(nil))
during RTL pass: postreload
pr116389-red.c:20:1: internal compiler error: in
extract_constrain_insn, at recog.cc:2783
Reason is that R30 is the last GPR and can hold HImode at most,
but due to a paradoxical subreg, there is r30:SI.
Bummer as that was the kind of scenario it's supposed to fix.
What did that insn look like before IRA and for whatever pseudo was in
that operand, what hard register did IRA think it should be allocated to?
jeff
The .ira dump has several paradoxical subregs like:
(insn 22 21 60 4 (set (reg/v:SI 51 [ val32 ])
(subreg:SI (reg:HI 53 [ t$val ]) 0)) "pr116389-red.c":14:14 146
{*movsi_split}
(insn 27 26 28 5 (set (reg/v:SI 51 [ val32 ])
(subreg:SI (reg/v:HI 52 [ diff ]) 0)) "pr116389-red.c":16:19
146 {*movsi_split}
(insn 35 34 36 7 (set (reg:HI 54 [ _7 ])
(ashift:HI (subreg:HI (reg/v:SI 51 [ val32 ]) 0)
(const_int 1 [0x1]))) "pr116389-red.c":18:13 667 {ashlhi3}
I don't know which one is causing the trouble. Maybe the attached
dumps will help.
I would suggest looking at the .IRA dump. You want to know what
register was assigned to pseudo 52. I'm guessing it'll be r30, at which
point you'll probably want to debug the same code I just changed to
figure out why it's not working in the expected manner.
jeff
[to-be-committed][RISC-V][PR target/118146] Fix ICE for unsupported modes
There's some special case code in the risc-v move expander to try and
optimize cases where the source is a subreg of a vector and the
destination is a scalar mode.
The code works fine except when we have no support for the given mode.
ie HF or BF when those extensions aren't enabled. We'll end up tripping
an assert in that case when we should have just let standard expansion
do its thing.
Tested in my system for rv32 and rv64, but I'll wait for the pre-commit
tester to render a verdict before moving forward.
JeffPR target/118146
gcc/
* config/riscv/riscv.cc (riscv_legitimize_move): Handle subreg
of vector source better to avoid ICE.
gcc/testsuite
* gcc.target/riscv/pr118146-1.c: New test.
* gcc.target/riscv/pr118146-2.c: New test.
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 819e1538741..6e14126e3a4 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -3587,6 +3587,9 @@ riscv_legitimize_move (machine_mode mode, rtx dest, rtx
src)
nunits = nunits * 2;
}
+ /* This test can fail if (for example) we want a HF and Z[v]fh is
+not enabled. In that case we just want to let the standard
+expansion path run. */
if (riscv_vector::get_vector_mode (smode, nunits).exists (&vmode))
{
rtx v = gen_lowpart (vmode, SUBREG_REG (src));
@@ -3636,12 +3639,10 @@ riscv_legitimize_move (machine_mode mode, rtx dest, rtx
src)
emit_move_insn (dest, gen_lowpart (GET_MODE (dest), int_reg));
else
emit_move_insn (dest, int_reg);
+ return true;
}
- else
- gcc_unreachable ();
-
- return true;
}
+
/* Expand
(set (reg:QI target) (mem:QI (address)))
to
diff --git a/gcc/testsuite/gcc.target/riscv/pr118146-1.c
b/gcc/testsuite/gcc.target/riscv/pr118146-1.c
new file mode 100644
index 000..f3a7c4d96d8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/pr118146-1.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d -O" { target { rv64 } } } */
+/* { dg-options "-march=rv32gcv -mabi=ilp32d -O" { target { rv32 } } } */
+
+
+
+typedef __attribute__((__vector_size__(sizeof(_Float16 short V;
+_Float16 f;
+
+void
+foo(V v)
+{
+ f -= *(_Float16 *)&v;
+}
diff --git a/gcc/testsuite/gcc.target/riscv/pr118146-2.c
b/gcc/testsuite/gcc.target/riscv/pr118146-2.c
new file mode 100644
index 000..e7a5f39fa86
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/pr118146-2.c
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d -std=gnu23 -O2" { target { rv64 }
} } */
+/* { dg-options "-march=rv32gcv -mabi=ilp32d -std=gnu23 -O2" { target { rv32 }
} } */
+
+long print_halffloat_j;
+int *print_halffloat_block;
+void ftoastr(float);
+enum { BFLOATING_POINTvoid } print_halffloat() {
+ union {
+_Float16 x;
+char b[];
+ } u;
+ print_halffloat_j = 0;
+ for (; print_halffloat_j < sizeof(_Float16); print_halffloat_j++)
+u.b[print_halffloat_j] = print_halffloat_block[print_halffloat_j];
+ ftoastr(u.x);
+}
[PATCH] RISC-V: unrecognizable insn ICE in xtheadvector/pr114194.c on 32bit targets
PR target/118601 gcc/ChangeLog: * config/riscv/riscv.cc (riscv_use_by_pieces_infrastructure_p): Exclude XTheadVector. Reported-by: Edwin Lu --- gcc/config/riscv/riscv.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc index 819e1538741..e5776aa0fbe 100644 --- a/gcc/config/riscv/riscv.cc +++ b/gcc/config/riscv/riscv.cc @@ -13826,7 +13826,7 @@ riscv_use_by_pieces_infrastructure_p (unsigned HOST_WIDE_INT size, /* For set/clear with size > UNITS_PER_WORD, by pieces uses vector broadcasts with UNITS_PER_WORD size pieces. Use setmem instead which can use bigger chunks. */ - if (TARGET_VECTOR && stringop_strategy & STRATEGY_VECTOR + if (TARGET_VECTOR && !TARGET_XTHEADVECTOR && stringop_strategy & STRATEGY_VECTOR && (op == CLEAR_BY_PIECES || op == SET_BY_PIECES) && speed_p && size > UNITS_PER_WORD) return false; -- 2.25.1
GCN, nvptx: 'sorry, unimplemented: exception handling not supported' (was: [PATCH 22/25] Add dg-require-effective-target exceptions)
Hi! On 2018-09-05T12:52:10+0100, wrote: > There are a number of tests that fail because they assume that exceptions are > available, but [BPF, GCN, nvptx] does not support them, yet. To make this explicit for GCN, nvptx (José: can BPF do the same?), I've pushed to trunk branch commit 6312165650091a4df34668d8e2aaa0bbc4008a66 "GCN, nvptx: 'sorry, unimplemented: exception handling not supported'", see attached. For GCN, this avoids ICEs further down the compilation pipeline. For nvptx, there's effectively no change: in presence of exception handling constructs, instead of 'sorry, unimplemented: target cannot support nonlocal goto', we now emit 'sorry, unimplemented: exception handling not supported'. > This patch adds "dg-require-effective-target exceptions" in all the affected > tests. There's probably an automatic way to test for exceptions, but the > current implementation simply says that AMD GCN does not support them. This > should ensure that no other targets are affected by the change. Via my commit's 'gcc/testsuite/lib/gcc-dg.exp:gcc-dg-prune' and corresponding libstdc++-v3 changes, we now also turn test cases into UNSUPPORTED if running into 'sorry, unimplemented: exception handling not supported'. José: if BPF also emitted this same diagnostic (I'm not set up for BPF target testing; probably just need to add the very same 'sorry' 'define_expand "exception_receiver"'?), we could go one step further, and again remove all the manual 'dg-require-effective-target exceptions' markup, and instead let 'gcc-dg-prune' handle that, automatically. Actually, for some test cases, 'dg-require-effective-target exceptions' should (nowadays) be removed either way, because they don't actually run into UNSUPPORTED exception handling constructs, but actually PASS. (I assume that GCC got smarter about optimizing away exception handling constructs.) Grüße Thomas > 2018-09-05 Andrew Stubbs > Kwok Cheung Yeung > Julian Brown > Tom de Vries > > gcc/testsuite/ > * c-c++-common/ubsan/pr71512-1.c: Require exceptions. > * c-c++-common/ubsan/pr71512-2.c: Require exceptions. > * gcc.c-torture/compile/pr34648.c: Require exceptions. > * gcc.c-torture/compile/pr41469.c: Require exceptions. > * gcc.dg/20111216-1.c: Require exceptions. > * gcc.dg/cleanup-10.c: Require exceptions. > * gcc.dg/cleanup-11.c: Require exceptions. > * gcc.dg/cleanup-12.c: Require exceptions. > * gcc.dg/cleanup-13.c: Require exceptions. > * gcc.dg/cleanup-5.c: Require exceptions. > * gcc.dg/cleanup-8.c: Require exceptions. > * gcc.dg/cleanup-9.c: Require exceptions. > * gcc.dg/gomp/pr29955.c: Require exceptions. > * gcc.dg/lto/pr52097_0.c: Require exceptions. > * gcc.dg/nested-func-5.c: Require exceptions. > * gcc.dg/pch/except-1.c: Require exceptions. > * gcc.dg/pch/valid-2.c: Require exceptions. > * gcc.dg/pr41470.c: Require exceptions. > * gcc.dg/pr42427.c: Require exceptions. > * gcc.dg/pr44545.c: Require exceptions. > * gcc.dg/pr47086.c: Require exceptions. > * gcc.dg/pr51481.c: Require exceptions. > * gcc.dg/pr51644.c: Require exceptions. > * gcc.dg/pr52046.c: Require exceptions. > * gcc.dg/pr54669.c: Require exceptions. > * gcc.dg/pr56424.c: Require exceptions. > * gcc.dg/pr64465.c: Require exceptions. > * gcc.dg/pr65802.c: Require exceptions. > * gcc.dg/pr67563.c: Require exceptions. > * gcc.dg/tree-ssa/pr41469-1.c: Require exceptions. > * gcc.dg/tree-ssa/ssa-dse-28.c: Require exceptions. > * gcc.dg/vect/pr46663.c: Require exceptions. > * lib/target-supports.exp (check_effective_target_exceptions): New. > --- > gcc/testsuite/c-c++-common/ubsan/pr71512-1.c | 1 + > gcc/testsuite/c-c++-common/ubsan/pr71512-2.c | 1 + > gcc/testsuite/gcc.c-torture/compile/pr34648.c | 1 + > gcc/testsuite/gcc.c-torture/compile/pr41469.c | 1 + > gcc/testsuite/gcc.dg/20111216-1.c | 1 + > gcc/testsuite/gcc.dg/cleanup-10.c | 1 + > gcc/testsuite/gcc.dg/cleanup-11.c | 1 + > gcc/testsuite/gcc.dg/cleanup-12.c | 1 + > gcc/testsuite/gcc.dg/cleanup-13.c | 1 + > gcc/testsuite/gcc.dg/cleanup-5.c | 1 + > gcc/testsuite/gcc.dg/cleanup-8.c | 1 + > gcc/testsuite/gcc.dg/cleanup-9.c | 1 + > gcc/testsuite/gcc.dg/gomp/pr29955.c | 1 + > gcc/testsuite/gcc.dg/lto/pr52097_0.c | 1 + > gcc/testsuite/gcc.dg/nested-func-5.c | 1 + > gcc/testsuite/gcc.dg/pch/except-1.c | 1 + > gcc/testsuite/gcc.dg/pch/valid-2.c| 2 +- > gcc/testsuite/gcc.dg/pr41470.c| 1 + > gcc/testsuite/gcc.dg/pr42427.c| 1 + > gcc/testsuite/gcc.dg/pr44545.c| 1 + > gcc/testsuite/gcc.dg/pr47086.c| 1 + > gcc/testsuite/gcc.dg/pr51481.c
Re: [PATCH] SFINAE check for floating point fetch_add builtins in libstdc++
Hi Jonathan! Many thanks! Will learn the libstdc++ style eventually. I've run bootstrap & regression test on this, and did the manual checks I mentioned before of compiling atomic_float/1.cc with clang and then adding `+ 1` on the builtin codepath to check that the clang binary aborts while the GCC built binary passes. Thanks again! Matthew On 2/7/25 15:33, Jonathan Wakely wrote: External email: Use caution opening links or attachments On 05/02/25 13:43 +, Jonathan Wakely wrote: On 28/10/24 17:15 +, mmalcom...@nvidia.com wrote: From: Matthew Malcomson I noticed that the libstdc++ patch is essentially separate and figured I could send it upstream earlier to give reviewers more time to look at it. I am still working on adding the ability to use floating point types in the __atomic_fetch_add builtins Review of current state and motivation (for anyone reading this that has not already seen the previous patches): - Some hardware has support for floating point atomic fetch_add (and similar). - There are existing compilers targetting this hardware that use libstdc++ -- e.g. NVC++. - Since the libstdc++ atomic::fetch_add and similar is written directly as a CAS loop these compilers can not emit optimal code when seeing such constructs. - I hope to use __atomic_fetch_add builtins on floating point types directly in libstdc++ so these compilers can emit better code. - Clang already handles some floating point types in the __atomic_fetch_add family of builtins. - In order to only use this when available, I originally thought I could check against the resolved versions of the builtin in a manner something like `__has_builtin(__atomic_fetch_add_)`. I then realised that clang does not expose resolved versions of these atomic builtins to the user. From the clang discourse it was suggested we instead use SFINAE (which clang already supports). - I have posted a patch for allowing the use of SFINAE on builtins (not yet reviewed). https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664999.html *This* patch builds and regtests on top of that patch. It does not change what happens for GCC, while it uses the builtin for codegen with clang. - I have previously sent a patchset upstream adding the ability to use __atomic_fetch_add and similar on floating point types. https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663355.html I hope to send a full patchset up soon including the suggestions given there. With that patchset included (plus the automatic linking of libatomic as Joseph pointed out in the email below https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665408.html ) then current GCC should start to use the builtin branch added in this patch. So *currently*, this patch allows external compilers (NVC++ in particular) to generate better code, and similarly lets clang understand the operation better since it maps to a known builtin. I hope that by GCC 15 this patch would also allow GCC to understand the operation better via mapping to a known builtin. - 8< --- >8 Points to question here are: 1) Is this the best approach for using SFINAE to check if this builtin has a particular overload? Don't know of a better approach, but not an expert in C++ templating. Concepts! We still need the CAS loop fallback for any compiler that doesn't implement this builtin. Once all compilers we care about implement this we can remove this special handling and merge the floating point and integral operations into the same template. Testing done: N.b. all testing done on top of the patch introducing SFINAE on builtins here, all testing done on AArch64: https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664999.html 1) No change seene in bootstrap & regression test on AArch64 2) Manually ran the atomic_float/1.cc testcase with clang++ 19 and things passed. With clang++ 18 there was a failure independent to this change where the use of `is_lock_free` in the testcase was not optimised away so we got a linker error. After editing the testcase it also passes with clang++ 18. 3) Manually checked that when compiling with clang we follow the branch that uses the builtin for `float` (because clang has already implemented these builtins for `float`). - Done by adding `+1` to the result of that branch and checking that we abort when running the result. 4) Manually checked that when compiling with GCC we follow the branch that does not use the builtin for `float`. - Done this by adding the same temporary bug to the header in the builtin branch, and re-running tests to see that we still pass with GCC. Ok for trunk? libstdc++-v3/ChangeLog: * include/bits/atomic_base.h (__atomic_impl::__is_atomic_fetch_add_available): Define new struct using SFINAE to check whether __atomic_fetch_add is implemented on floating point type. (std::__atomic_impl::__fetch_add_flt): `if constexpr` branch on the above SF
Re: [PATCH 3/3] c++/modules: Handle exposures of TU-local types in uninstantiated member templates
On Fri, Feb 07, 2025 at 11:11:21AM -0500, Jason Merrill wrote:
> On 2/7/25 9:28 AM, Nathaniel Shead wrote:
> > On Fri, Feb 07, 2025 at 08:14:23AM -0500, Jason Merrill wrote:
> > > On 1/31/25 8:46 AM, Nathaniel Shead wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> > > >
> > > > Happy to remove the custom inform for lambdas, but I felt that the
> > > > original message (which suggests that defining it within a class should
> > > > make it OK) was unhelpful here.
> > > >
> > > > Similarly the 'is_exposure_of_member_type' function is not necessary to
> > > > fix the bug, and is just for slightly nicer diagnostics.
> > > >
> > > > -- >8 --
> > > >
> > > > Previously, 'is_tu_local_entity' wouldn't detect the exposure of the (in
> > > > practice) TU-local lambda in the following example, unless instantiated:
> > > >
> > > > struct S {
> > > > template
> > > > static inline decltype([]{}) x = {};
> > > > };
> > > >
> > > > This is for two reasons. Firstly, when traversing the TYPE_FIELDS of S
> > > > we only see the TEMPLATE_DECL, and never end up building a dependency on
> > > > its DECL_TEMPLATE_RESULT (due to not being instantiated). This patch
> > > > fixes this by stripping any templates before checking for unnamed types.
> > > >
> > > > The second reason is that we currently assume all class-scope entities
> > > > are not TU-local. Despite this being unambiguous in the standard, this
> > > > is not actually true in our implementation just yet, due to issues with
> > > > mangling lambdas in some circumstances. Allowing these lambdas to be
> > > > exported can cause issues in importers with apparently conflicting
> > > > declarations, so this patch treats them as TU-local as well.
> > > >
> > > > After these changes, we now get double diagnostics from the two ways
> > > > that we can see the above lambda being exposed, via 'S' (through
> > > > TYPE_FIELDS) or via 'S::x'. To workaround this we hide diagnostics from
> > > > the first case, so we only get errors from 'S::x' which will be closer
> > > > to the point the offending lambda is declared.
> > > >
> > > > gcc/cp/ChangeLog:
> > > >
> > > > * module.cc (trees_out::type_node): Adjust assertion.
> > > > (depset::hash::is_tu_local_entity): Handle unnamed template
> > > > types, treat lambdas specially.
> > > > (is_exposure_of_member_type): New function.
> > > > (depset::hash::add_dependency): Use it.
> > > > (depset::hash::finalize_dependencies): Likewise.
> > > >
> > > > gcc/testsuite/ChangeLog:
> > > >
> > > > * g++.dg/modules/internal-10.C: New test.
> > > >
> > > > Signed-off-by: Nathaniel Shead
> > > > ---
> > > >gcc/cp/module.cc | 67
> > > > ++
> > > >gcc/testsuite/g++.dg/modules/internal-10.C | 25
> > > >2 files changed, 81 insertions(+), 11 deletions(-)
> > > >create mode 100644 gcc/testsuite/g++.dg/modules/internal-10.C
> > > >
> > > > diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> > > > index c89834c1abd..59b7270f4a5 100644
> > > > --- a/gcc/cp/module.cc
> > > > +++ b/gcc/cp/module.cc
> > > > @@ -9261,7 +9261,9 @@ trees_out::type_node (tree type)
> > > > /* We'll have either visited this type or have newly discovered
> > > >that it's TU-local; either way we won't need to visit it
> > > > again. */
> > > > - gcc_checking_assert (TREE_VISITED (type) || has_tu_local_dep
> > > > (name));
> > > > + gcc_checking_assert (TREE_VISITED (type)
> > > > +|| has_tu_local_dep (TYPE_NAME (type))
> > > > +|| has_tu_local_dep (TYPE_TI_TEMPLATE
> > > > (type)));
> > >
> > > Why doesn't the template having a TU-local dep imply that the TYPE_NAME
> > > does?
> >
> > I may not have written this the most clearly; the type doesn't
> > necessarily even have a template, but if it's not visited and its
> > TYPE_NAME hasn't had a TU-local dep made then we must instead have seen
> > a TYPE_TI_TEMPLATE that does have a TU-local dep.
>
> My question is why has_tu_local_dep (name) can be false while
> has_tu_local_dep (tmpl) is true.
In this case it's an early exit thing; when walking the TYPE_NAME, we
find that it's a TEMPLATE_DECL_RESULT in 'trees_out::decl_node', and
walk the TI_TEMPLATE of that decl there.
When walking this TEMPLATE_DECL we end up calling 'add_dependency' on
it, which creates the depset and adds it to the worklist. This doesn't
add the TYPE_DECL in this pass (we don't walk the TEMPLATE_DECL dep
we've just made yet, we're still walking whatever decl we were
processing when we saw this type), so when we come back to this checking
assertion we haven't made a dep for the TYPE_NAME yet.
> I notice that find_tu_local_decl doesn't walk into TYPE_TI_TEMPLATE.
So my thinking had been that 'find_tu_local_decl' doesn't need to handle
this case, because it's only ran wh
Re: [committed][rtl-optimization/116244] Don't create bogus regs in alter_subreg
Am 07.02.25 um 22:28 schrieb Jeff Law:
On 2/7/25 11:01 AM, Georg-Johann Lay wrote:
Am 07.02.25 um 17:12 schrieb Jeff Law:
On 2/3/25 2:09 AM, Richard Sandiford wrote:
Jeff Law writes:
So pulling on this thread leads me into the code that sets up
ALLOCNO_WMODE in create_insn_allocnos:
if ((a = ira_curr_regno_allocno_map[regno]) == NULL)
{
a = ira_create_allocno (regno, false,
ira_curr_loop_tree_node);
if (outer != NULL && GET_CODE (outer) == SUBREG)
{
machine_mode wmode = GET_MODE (outer);
if (partial_subreg_p (ALLOCNO_WMODE (a), wmode))
ALLOCNO_WMODE (a) = wmode;
}
}
Note how we only set ALLOCNO_MODE only at allocno creation, so it'll
work as intended if and only if the first reference is via a SUBREG.
Huh, yeah, I agree that that looks wrong.
ISTM the fix here is to always do the check and set ALLOCNO_WMODE.
[ Snipped discussion on a non-issue. ]
So ISTM that moving the code out of the "if (... == NULL)" should be
enough on its own.
And it all makes sense that you caught this. You and another
colleague
at ARM were trying to address this exact problem ~11 years ago ;-)
Heh, thought it sounded familiar :)
So attached is the updated patch that adjusts IRA to avoid this problem.
Georg-Johann, this may explain an issue you were running into as well
where you got an invalid allocation. I think yours was at the higher
end of the register file, but the core issue is potentially the same
(looking at the first use rather than all of them for paradoxical
subregs).
You mean https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116389 ?
As far as I can tell that only occurred with reload but not with LRA.
Right. The change is in IRA so it would affect reload targets as well
as LRA targets.
jeff
That test case from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116389#c7
still ICEs with that change in http://gcc.gnu.org/r15-7428
pr116389-red.c: In function 'func':
pr116389-red.c:20:1: error: insn does not satisfy its constraints:
20 | }
| ^
(insn 27 69 28 5 (set (mem/c:SI (plus:HI (reg/f:HI 28 r28)
(const_int 2 [0x2])) [4 %sfp+2 S4 A8])
(reg:SI 30 r30)) "pr116389-red.c":16:19 146 {*movsi_split}
(nil))
during RTL pass: postreload
pr116389-red.c:20:1: internal compiler error: in extract_constrain_insn,
at recog.cc:2783
Reason is that R30 is the last GPR and can hold HImode at most,
but due to a paradoxical subreg, there is r30:SI.
Johann
[PATCH] c++/modules: Better handle no-linkage decls in unnamed namespaces [PR118799]
Tested on x86_64-pc-linux-gnu, OK for trunk if full bootstrap + regtest
passes?
-- >8 --
There are two issues with no-linkage decls (e.g. explicit type aliases)
in unnamed namespaces that this patch fixes.
Firstly, we don't currently handle exporting no-linkage decls in unnamed
namespaces. This should be ill-formed in [module.export], since having
an exported declaration within a namespace-definition makes the
namespace definition exported (p2), but an unnamed namespace has
internal linkage thus violating p3.
Secondly, by the standard it appears to be possible to emit unnamed
namespaces from named modules in certain scenarios. This patch makes
the adjustments needed to ensure we don't error in this case.
PR c++/118799
gcc/cp/ChangeLog:
* module.cc (depset::hash::is_tu_local_entity): Only types,
functions, variables, and template (specialisations) can be
TU-local.
(module_state::write_namespaces): Allow unnamed namespaces in
named modules.
(check_module_decl_linkage): Error for all exported declarations
in an unnamed namespace.
gcc/testsuite/ChangeLog:
* g++.dg/modules/export-6.C: Adjust error message, add check for
no-linkage decls in namespace.
* g++.dg/modules/internal-4_b.C: Allow exposing a namespace with
internal linkage.
* g++.dg/modules/using-30_a.C: New test.
* g++.dg/modules/using-30_b.C: New test.
* g++.dg/modules/using-30_c.C: New test.
Signed-off-by: Nathaniel Shead
---
gcc/cp/module.cc| 35 -
gcc/testsuite/g++.dg/modules/export-6.C | 33 ++-
gcc/testsuite/g++.dg/modules/internal-4_b.C | 4 +--
gcc/testsuite/g++.dg/modules/using-30_a.C | 9 ++
gcc/testsuite/g++.dg/modules/using-30_b.C | 6
gcc/testsuite/g++.dg/modules/using-30_c.C | 13
6 files changed, 77 insertions(+), 23 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/modules/using-30_a.C
create mode 100644 gcc/testsuite/g++.dg/modules/using-30_b.C
create mode 100644 gcc/testsuite/g++.dg/modules/using-30_c.C
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 59716e1873e..21251f98a35 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -13332,6 +13332,14 @@ depset::hash::is_tu_local_entity (tree decl, bool
explain/*=false*/)
{
gcc_checking_assert (DECL_P (decl));
+ /* Only types, functions, variables, and template (specialisations)
+ can be TU-local. */
+ if (TREE_CODE (decl) != TYPE_DECL
+ && TREE_CODE (decl) != FUNCTION_DECL
+ && TREE_CODE (decl) != VAR_DECL
+ && TREE_CODE (decl) != TEMPLATE_DECL)
+return false;
+
/* An explicit type alias is not an entity, and so is never TU-local.
Neither are the built-in declarations of 'int' and such. */
if (TREE_CODE (decl) == TYPE_DECL
@@ -16433,8 +16441,9 @@ module_state::write_namespaces (elf_out *to, vec spaces,
depset *b = spaces[ix];
tree ns = b->get_entity ();
+ /* This could be an anonymous namespace even for a named module,
+since we can still emit no-linkage decls. */
gcc_checking_assert (TREE_CODE (ns) == NAMESPACE_DECL);
- gcc_checking_assert (TREE_PUBLIC (ns) || header_module_p ());
unsigned flags = 0;
if (TREE_PUBLIC (ns))
@@ -20394,13 +20403,25 @@ check_module_decl_linkage (tree decl)
/* An internal-linkage declaration cannot be generally be exported.
But it's OK to export any declaration from a header unit, including
internal linkage declarations. */
- if (!header_module_p ()
- && DECL_MODULE_EXPORT_P (decl)
- && decl_linkage (decl) == lk_internal)
+ if (!header_module_p () && DECL_MODULE_EXPORT_P (decl))
{
- error_at (DECL_SOURCE_LOCATION (decl),
- "exporting declaration %qD with internal linkage", decl);
- DECL_MODULE_EXPORT_P (decl) = false;
+ /* Let's additionally treat any exported declaration within an
+internal namespace as exporting a declaration with internal
+linkage, as this would implicitly also export the internal
+linkage namespace. */
+ if (decl_internal_context_p (decl))
+ {
+ error_at (DECL_SOURCE_LOCATION (decl),
+ "exporting declaration %qD declared in unnamed namespace",
+ decl);
+ DECL_MODULE_EXPORT_P (decl) = false;
+ }
+ else if (decl_linkage (decl) == lk_internal)
+ {
+ error_at (DECL_SOURCE_LOCATION (decl),
+ "exporting declaration %qD with internal linkage", decl);
+ DECL_MODULE_EXPORT_P (decl) = false;
+ }
}
}
diff --git a/gcc/testsuite/g++.dg/modules/export-6.C
b/gcc/testsuite/g++.dg/modules/export-6.C
index 460cdf08ea9..af54e5fbe87 100644
--- a/gcc/testsuite/g++.dg/modules/export-6.C
+++ b/gcc/testsuite/g++.dg/modules/export-6.C
@@ -16,27 +16,32 @@ export static auto [d] = S{}; // { dg-error "internal
Re: [PATCH] SFINAE check for floating point fetch_add builtins in libstdc++
On Sat, 8 Feb 2025 at 10:55, Matthew Malcomson wrote: > > Hi Jonathan! > > Many thanks! Will learn the libstdc++ style eventually. > > I've run bootstrap & regression test on this, and did the manual checks > I mentioned before of compiling atomic_float/1.cc with clang and then > adding `+ 1` on the builtin codepath to check that the clang binary > aborts while the GCC built binary passes. Great, thanks for checking it. I'll get this pushed early next week. > > Thanks again! > Matthew > > On 2/7/25 15:33, Jonathan Wakely wrote: > > External email: Use caution opening links or attachments > > > > > > On 05/02/25 13:43 +, Jonathan Wakely wrote: > >> On 28/10/24 17:15 +, mmalcom...@nvidia.com wrote: > >>> From: Matthew Malcomson > >>> > >>> I noticed that the libstdc++ patch is essentially separate and figured I > >>> could send it upstream earlier to give reviewers more time to look at > >>> it. > >>> I am still working on adding the ability to use floating point types in > >>> the __atomic_fetch_add builtins > >>> > >>> Review of current state and motivation (for anyone reading this that has > >>> not already seen the previous patches): > >>> - Some hardware has support for floating point atomic fetch_add (and > >>> similar). > >>> - There are existing compilers targetting this hardware that use > >>> libstdc++ -- e.g. NVC++. > >>> - Since the libstdc++ atomic::fetch_add and similar is written > >>> directly as a CAS loop these compilers can not emit optimal code when > >>> seeing such constructs. > >>> - I hope to use __atomic_fetch_add builtins on floating point types > >>> directly in libstdc++ so these compilers can emit better code. > >>> - Clang already handles some floating point types in the > >>> __atomic_fetch_add family of builtins. > >>> - In order to only use this when available, I originally thought I could > >>> check against the resolved versions of the builtin in a manner > >>> something like `__has_builtin(__atomic_fetch_add_)`. > >>> I then realised that clang does not expose resolved versions of these > >>> atomic builtins to the user. > >>> From the clang discourse it was suggested we instead use SFINAE (which > >>> clang already supports). > >>> - I have posted a patch for allowing the use of SFINAE on builtins (not > >>> yet reviewed). > >>> https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664999.html > >>> *This* patch builds and regtests on top of that patch. It does not > >>> change what happens for GCC, while it uses the builtin for codegen with > >>> clang. > >>> - I have previously sent a patchset upstream adding the ability to use > >>> __atomic_fetch_add and similar on floating point types. > >>> https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663355.html > >>> I hope to send a full patchset up soon including the suggestions given > >>> there. > >>> With that patchset included (plus the automatic linking of libatomic > >>> as Joseph pointed out in the email below > >>> https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665408.html ) > >>> then current GCC should start to use the builtin branch added in this > >>> patch. > >>> > >>> So *currently*, this patch allows external compilers (NVC++ in > >>> particular) to generate better code, and similarly lets clang understand > >>> the operation better since it maps to a known builtin. > >>> > >>> I hope that by GCC 15 this patch would also allow GCC to understand the > >>> operation better via mapping to a known builtin. > >>> > >>> - 8< --- >8 > >>> > >>> Points to question here are: > >>> 1) Is this the best approach for using SFINAE to check if this builtin > >>> has a particular overload? > >>> Don't know of a better approach, but not an expert in C++ templating. > >> > >> Concepts! > >> > >>> We still need the CAS loop fallback for any compiler that doesn't > >>> implement this builtin. Once all compilers we care about implement this > >>> we can remove this special handling and merge the floating point and > >>> integral operations into the same template. > >>> > >>> Testing done: > >>> N.b. all testing done on top of the patch introducing SFINAE on builtins > >>> here, all testing done on AArch64: > >>> https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664999.html > >>> > >>> 1) No change seene in bootstrap & regression test on AArch64 > >>> 2) Manually ran the atomic_float/1.cc testcase with clang++ 19 and > >>> things passed. With clang++ 18 there was a failure independent to > >>> this change where the use of `is_lock_free` in the testcase was not > >>> optimised away so we got a linker error. After editing the testcase > >>> it also passes with clang++ 18. > >>> 3) Manually checked that when compiling with clang we follow the branch > >>> that uses the builtin for `float` (because clang has already > >>> implemented these builtins for `float`). > >>> - Done by adding `+1` to the result of that branch and checking that > >>>we
[Patch, Fortran] Fix PR 24878, checking actual arguments against global symbols
Hello world,
this fixes a rather old PR from 2005, where a subroutine
could be passed and called as a function. This patch checks
for that, also for the reverse, and for wrong types of functions.
I expect that this will find a few bugs in dusty deck code...
Regression-tested. OK for trunk?
Best regards
Thomas
Test procedure dummy arguments against global symbols, if available.
gcc/fortran/ChangeLog:
PR fortran/24878
* interface.cc (compare_parameter): Check global subroutines
passed as actual arguments for subroutine / function and
function type.
gcc/testsuite/ChangeLog:
PR fortran/24878
* gfortran.dg/interface_51.f90: New test.
diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index 145f710563a..9ab5544454a 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -2423,6 +2423,7 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
gfc_component *ppc;
bool codimension = false;
gfc_array_spec *formal_as;
+ const char *actual_name;
/* If the formal arg has type BT_VOID, it's to one of the iso_c_binding
procs c_f_pointer or c_f_procpointer, and we need to accept most
@@ -2487,6 +2488,51 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
return false;
}
+ /* The actual symbol may disagree with a global symbol. If so, issue an
+ error, but only if no previous error has been reported on the formal
+ argument. */
+ actual_name = act_sym->name ? act_sym->name : act_sym->name;
+ if (!formal->error && actual_name)
+ {
+ gfc_gsymbol *gsym;
+ gsym = gfc_find_gsymbol (gfc_gsym_root, actual_name);
+ if (gsym != NULL)
+ {
+ if (gsym->type == GSYM_SUBROUTINE && formal->attr.function)
+ {
+ gfc_error ("Passing global subroutine %qs declared at %L "
+ "as function at %L", actual_name, &gsym->where,
+ &actual->where);
+ return false;
+ }
+ if (gsym->type == GSYM_FUNCTION && formal->attr.subroutine)
+ {
+ gfc_error ("Passing global function %qs declared at %L "
+ "as subroutine at %L", actual_name, &gsym->where,
+ &actual->where);
+ return false;
+ }
+ if (gsym->type == GSYM_FUNCTION)
+ {
+ gfc_symbol *global_asym;
+ gfc_find_symbol (actual_name, gsym->ns, 0, &global_asym);
+ if (global_asym != NULL)
+ {
+ gcc_assert (formal->attr.function);
+ if (!gfc_compare_types (&global_asym->ts, &formal->ts))
+ {
+ gfc_error ("Type mismatch passing global function %qs "
+ "declared at %L at %L (%s/%s)", actual_name,
+ &gsym->where, &actual->where,
+ gfc_typename (&global_asym->ts),
+ gfc_dummy_typename (&formal->ts));
+ return false;
+ }
+ }
+ }
+ }
+ }
+
if (formal->attr.function && !act_sym->attr.function)
{
gfc_add_function (&act_sym->attr, act_sym->name,
@@ -2501,7 +2547,6 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
return true;
}
-
ppc = gfc_get_proc_ptr_comp (actual);
if (ppc && ppc->ts.interface)
{
diff --git a/gcc/testsuite/gfortran.dg/interface_51.f90 b/gcc/testsuite/gfortran.dg/interface_51.f90
new file mode 100644
index 000..c8371e81ec9
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/interface_51.f90
@@ -0,0 +1,51 @@
+! { dg-do compile }
+
+! PR 24878 - passing a global subroutine as a function, or vice versa,
+! was not caught, nor were type mismatches. Original test case by
+! Uttam Pawar.
+
+program memain
+ implicit none
+ integer subr
+ external subr
+ external i4
+ external r4
+ integer r4
+
+ call foo(subr) ! { dg-error "Passing global subroutine" }
+ call bar(i4) ! { dg-error "Passing global function" }
+ call baz(r4) ! { dg-error "Type mismatch passing global function" }
+end program memain
+
+subroutine foo(ifun)
+ integer(kind=4) ifun
+ external ifun
+ integer y
+!---FNC is not a Function subprogram so calling it
+! as a function is an error.
+ Y=ifun(32)
+end subroutine foo
+
+subroutine bar(sub)
+ call sub
+end subroutine bar
+
+subroutine subr(X) ! { dg-error "Passing global subroutine" }
+ integer x
+ x = 12345
+end subroutine subr
+
+integer(kind=4) function i4() ! { dg-error "Passing global function" }
+ i4 = 42
+end function i4
+
+real(kind=4) function r4() ! { dg-error "Type mismatch passing global function" }
+ r4 = 1.0
+end function r4
+
+subroutine baz(ifun)
+ integer(kind=4) ifun
+ external ifun
+ integer y
+ y = ifun(32)
+end subroutine baz
Re: [PATCH] RISC-V: Add missing mode in bsetclr_zero_extract pattern
On 2/8/25 1:11 AM, Liao Shihua wrote: The following warning was encountered while building GCC, fix it: ../.././gcc/gcc/config/riscv/bitmanip.md:809:1: warning: source missing a mode? ../.././gcc/gcc/config/riscv/bitmanip.md:809:1: warning: source missing a mode? gcc/ChangeLog: * config/riscv/bitmanip.md (*bsetclr_zero_extract): (*bsetclr_zero_extract): Add missing mode in pattern. Umm, did you verify if that actually fixed the message? What you changed shouldn't impact that warning at all as it's just a name used in dump files. More likely it's warning about operand 2. And the lackof a mode for an immediate operand really isn't a problem. If you want to try and fix it, the most likely mode it should be using would be "X". jeff
Re: [PATCH] RISC-V: Vector pesudoinsns with x0 operand to use imm 0. (toggle)
On 2/7/25 6:34 PM, Andrew Waterman wrote: Replacing x0 with 0 when possible is fine; it should never hurt and might help on some uarches. (Of course, future versions of those uarches will eventually be forced to improve handling of x0, anyway, since as Vineet notes, some of the interesting cases don't have immediate forms.) Agreed. But I don't think offering the -mvec-elide-x0 option is beneficial. I'd just enable this change unconditionally. Or, in the unlikely event there's a uarch that benefits from the old code generation, this would be better handled as a consequence of -mtune than as a new top-level option. I don't see much value in having this be selectable until we see a uarch where it matters.I'd just use the immediate forms when we have them. Jeff
Re: [PATCH] config.host: add crtbeginT.o to extra_parts for FreeBSD [PR118685]
On Tue, 28 Jan 2025, Dimitry Andric wrote:
> Ref: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118685
>
> This ensures that gcc uses its own crt objects for static linking.
> Otherwise, it could mix the base system's crtbeginT.o with libgcc's
> crtend.o, leading to possible segfaults.
>
> Signed-off-by: Dimitry Andric
Thank you, Dim!
I ran a regression test and pushed this to trunk adding a ChangeLog entry
and adjusting the commit message a bit as follows. I plan to push back to
the gcc-14 branch shortly and the gcc-13 and gcc-12 branches gradually.
Gerald
commit 06e5b0b4a244090abfea333d91fc5963292cb41d
Author: Dimitry Andric
Date: Tue Jan 28 18:36:16 2025 +0100
libgcc: On FreeBSD use GCC's crt objects for static linking
Add crtbeginT.o to extra_parts on FreeBSD. This ensures we use GCC's
crt objects for static linking. Otherwise it could mix crtbeginT.o
from the base system with libgcc's crtend.o, possibly leading to
segfaults.
libgcc:
PR target/118685
* config.host (*-*-freebsd*): Add crtbeginT.o to extra_parts.
Signed-off-by: Dimitry Andric
diff --git a/libgcc/config.host b/libgcc/config.host
index 8930081069e..6a88ee5a2dd 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -292,7 +292,7 @@ case ${host} in
# machine-specific sections may refine and add to this
# configuration.
tmake_file="$tmake_file t-freebsd t-crtstuff-pic t-libgcc-pic t-eh-dw2-dip
t-slibgcc t-slibgcc-gld t-slibgcc-elf-ver"
- extra_parts="crtbegin.o crtend.o crtbeginS.o crtendS.o"
+ extra_parts="crtbegin.o crtend.o crtbeginS.o crtbeginT.o crtendS.o"
case ${target_thread_file} in
posix)
tmake_file="${tmake_file} t-freebsd-thread"
Re: [committed][rtl-optimization/116244] Don't create bogus regs in alter_subreg
On 2/8/25 3:04 AM, Georg-Johann Lay wrote:
That test case from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116389#c7
still ICEs with that change in http://gcc.gnu.org/r15-7428
pr116389-red.c: In function 'func':
pr116389-red.c:20:1: error: insn does not satisfy its constraints:
20 | }
| ^
(insn 27 69 28 5 (set (mem/c:SI (plus:HI (reg/f:HI 28 r28)
(const_int 2 [0x2])) [4 %sfp+2 S4 A8])
(reg:SI 30 r30)) "pr116389-red.c":16:19 146 {*movsi_split}
(nil))
during RTL pass: postreload
pr116389-red.c:20:1: internal compiler error: in extract_constrain_insn,
at recog.cc:2783
Reason is that R30 is the last GPR and can hold HImode at most,
but due to a paradoxical subreg, there is r30:SI.
Bummer as that was the kind of scenario it's supposed to fix.
What did that insn look like before IRA and for whatever pseudo was in
that operand, what hard register did IRA think it should be allocated to?
jeff
Re: [PATCH v2] RISC-V: Vector pesudoinsns with x0 operand to use imm 0
On 2/7/25 9:34 PM, Vineet Gupta wrote:
A couple of Vector pseudoinstructions use x0 scalar which being regfile
crosser could be inefficient on certain wider uarches.
Use the imm 0 form, which should be functionally equivalent.
pseudoinsnorig insn with x0 this patch
---
vneg.v vd,vs vrsub.vx vd,vs,x0 vrsub.vi vd,vs,0
vncvt.x.x.w vd,vs,vm vnsrl.wx vd,vs,x0,vm vnsrl.wi vd,vs,0,vm
vwcvt.x.x.v vd,vs,vm vwadd.vx vd,vs,x0,vm (imm not supported)
This passes my testsuite A/B run but obviously wait for the CI tester to
give a green light.
gcc/ChangeLog:
* config/riscv/vector.md: vncvt substitute vnsrl.
vnsrl with x0 replace with immediate 0.
vneg substitute vrsub.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/cond/cond_convert_int2int-rv32-1.c:
Change
expected pattern.
* gcc.target/riscv/rvv/autovec/cond/cond_convert_int2int-rv32-2.c:
Ditto.
* gcc.target/riscv/rvv/autovec/cond/cond_convert_int2int-rv64-1.c:
Ditto.
* gcc.target/riscv/rvv/autovec/cond/cond_convert_int2int-rv64-2.c:
Ditto.
* gcc.target/riscv/rvv/autovec/cond/cond_unary-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/cond/cond_unary-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/cond/cond_unary-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/cond/cond_unary-4.c: Ditto.
* gcc.target/riscv/rvv/autovec/cond/cond_unary-5.c: Ditto.
* gcc.target/riscv/rvv/autovec/cond/cond_unary-6.c: Ditto.
* gcc.target/riscv/rvv/autovec/cond/cond_unary-7.c: Ditto.
* gcc.target/riscv/rvv/autovec/cond/cond_unary-8.c: Ditto.
* gcc.target/riscv/rvv/autovec/conversions/vncvt-rv32gcv.c: Ditto.
* gcc.target/riscv/rvv/autovec/conversions/vncvt-rv64gcv.c: Ditto.
* gcc.target/riscv/rvv/autovec/sat/vec_sat_u_sub_trunc-1-u16.c: Ditto
* gcc.target/riscv/rvv/autovec/sat/vec_sat_u_sub_trunc-1-u32.c: Ditto.
* gcc.target/riscv/rvv/autovec/sat/vec_sat_u_sub_trunc-1-u8.c: Ditto.
* gcc.target/riscv/rvv/autovec/unop/abs-rv32gcv.c: Ditto.
* gcc.target/riscv/rvv/autovec/unop/abs-rv64gcv.c: Ditto.
* gcc.target/riscv/rvv/autovec/unop/vneg-rv32gcv.c: Ditto.
* gcc.target/riscv/rvv/autovec/unop/vneg-rv64gcv.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/abs-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/cond_convert-11.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/cond_convert-12.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/cond_neg-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/cond_trunc-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/cond_trunc-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/cond_trunc-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/convert-11.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/convert-12.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/neg-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/trunc-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/trunc-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/trunc-3.c: Ditto.
* gcc.target/riscv/rvv/base/simplify-vdiv.c: Ditto.
* gcc.target/riscv/rvv/base/unop_v_constraint-1.c: Ditto.
LGTM. I think the only question is whether or not to make an exception
for this or not. We are in stage4 after all ;-) Figure we can make a
decision on the Tues call if you're available.
jeff
Re: [PATCH] OpenMP: Improve Fortran metadirective diagnostics [PR107067]
On 2/4/25 01:49, Tobias Burnus wrote:
[snip]
To conclude: The patch LGTM but consider giving the user some hint
how to solve it, e.g. using one of the ideas above.
Thanks for the review. I've pushed the attached version of the patch,
which suggests using BLOCK or BEGIN/END METADIRECTIVE (but the latter
only if the error was not already diagnosed in BEGIN/END METADIRECTIVE).
-SandraFrom 5753f459444fa61a93d23325cd59467dc1838eef Mon Sep 17 00:00:00 2001
From: Sandra Loosemore
Date: Sat, 8 Feb 2025 17:44:55 +
Subject: [PATCH] [PATCH] OpenMP: Improve Fortran metadirective diagnostics
[PR107067]
The Fortran front end was giving an ICE instead of a user-friendly
diagnostic when variants of a metadirective variant had different
statement associations. The particular test case reported in the issue
also involved invalid placement of the "omp end metadirective" which
was not being diagnosed either.
gcc/fortran/ChangeLog
PR middle-end/107067
* parse.cc (parse_omp_do): Diagnose missing "OMP END METADIRECTIVE"
after loop.
(parse_omp_structured_block): Likewise for strictly structured block.
(parse_omp_metadirective_body): Use better test for variants ending
at different places. Issue a user diagnostic at the end if any
were inconsistent, instead of calling gcc_assert.
gcc/testsuite/ChangeLog
PR middle-end/107067
* gfortran.dg/gomp/metadirective-11.f90: Remove the dg-ice, update
for current behavior, and add more tests to exercise the new error
code.
---
gcc/fortran/parse.cc | 62 ++---
.../gfortran.dg/gomp/metadirective-11.f90 | 67 +--
2 files changed, 114 insertions(+), 15 deletions(-)
diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc
index 5094d9d3ead..336ea89c5a9 100644
--- a/gcc/fortran/parse.cc
+++ b/gcc/fortran/parse.cc
@@ -5804,9 +5804,20 @@ do_end:
/* If handling a metadirective variant, treat 'omp end metadirective'
as the expected end statement for the current construct. */
- if (st == ST_OMP_END_METADIRECTIVE
- && gfc_state_stack->state == COMP_OMP_BEGIN_METADIRECTIVE)
-st = omp_end_st;
+ if (gfc_state_stack->state == COMP_OMP_BEGIN_METADIRECTIVE)
+{
+ if (st == ST_OMP_END_METADIRECTIVE)
+ st = omp_end_st;
+ else
+ {
+ /* We have found some extra statements between the loop
+ and the "end metadirective" which is required in a
+ "begin metadirective" construct, or perhaps the
+ "end metadirective" is missing entirely. */
+ gfc_error_now ("Expected OMP END METADIRECTIVE at %C");
+ return st;
+ }
+}
if (st == omp_end_st)
{
@@ -6294,6 +6305,14 @@ parse_omp_structured_block (gfc_statement omp_st, bool workshare_stmts_only)
accept_statement (st);
st = next_statement ();
}
+ else if (omp_end_st == ST_OMP_END_METADIRECTIVE)
+ {
+ /* We have found some extra statements between the END BLOCK
+ and the "end metadirective" which is required in a
+ "begin metadirective" construct, or perhaps the
+ "end metadirective" is missing entirely. */
+ gfc_error_now ("Expected OMP END METADIRECTIVE at %C");
+ }
return st;
}
else if (st != omp_end_st || block_construct)
@@ -6409,10 +6428,12 @@ parse_omp_metadirective_body (gfc_statement omp_st)
gfc_omp_variant *variant
= new_st.ext.omp_variants;
locus body_locus = gfc_current_locus;
+ bool saw_error = false;
accept_statement (omp_st);
gfc_statement next_st = ST_NONE;
+ locus next_loc;
while (variant)
{
@@ -6470,8 +6491,24 @@ parse_omp_metadirective_body (gfc_statement omp_st)
reject_statement ();
st = next_statement ();
}
+
finish:
+ /* Sanity-check that each variant finishes parsing at the same place. */
+ if (next_st == ST_NONE)
+ {
+ next_st = st;
+ next_loc = gfc_current_locus;
+ }
+ else if (st != next_st
+ || next_loc.nextc != gfc_current_locus.nextc
+ || next_loc.u.lb != gfc_current_locus.u.lb)
+ {
+ saw_error = true;
+ next_st = st;
+ next_loc = gfc_current_locus;
+ }
+
gfc_in_omp_metadirective_body = old_in_metadirective_body;
if (gfc_state_stack->head)
@@ -6483,15 +6520,22 @@ parse_omp_metadirective_body (gfc_statement omp_st)
if (variant->next)
gfc_clear_new_st ();
- /* Sanity-check that each variant finishes parsing at the same place. */
- if (next_st == ST_NONE)
- next_st = st;
- else
- gcc_assert (st == next_st);
-
variant = variant->next;
}
+ if (saw_error)
+{
+ if (omp_st == ST_OMP_METADIRECTIVE)
+ gfc_error_now ("Variants in a metadirective at %L have "
+ "different associations; "
+ "consider using a BLOCK construct "
+ "or BEGIN/END METADIRECTIVE", &body_locus);
+ else
+ gfc_error_now ("Variants in a metadirective at %L have "
+ "different associations; "
+ "consider using a BLOCK construct", &body_locus);
+}
+
return next_st;
Re: [Patch, Fortran] Fix PR 24878, checking actual arguments against global symbols
Hi Thomas,
Am 08.02.25 um 15:31 schrieb Thomas Koenig:
Hello world,
this fixes a rather old PR from 2005, where a subroutine
could be passed and called as a function. This patch checks
for that, also for the reverse, and for wrong types of functions.
looks good, just two minor comments:
+ actual_name = act_sym->name ? act_sym->name : act_sym->name;
Why not just
+ actual_name = act_sym->name;
?
+ gfc_error ("Type mismatch passing global function %qs
"
+"declared at %L at %L (%s/%s)",
actual_name,
+&gsym->where, &actual->where,
+gfc_typename (&global_asym->ts),
+gfc_dummy_typename (&formal->ts));
These result in lines exceeding column 80.
I am also not a native speaker, but "at %L at %L" sounds strange to me.
Could you find a minor rewording?
I expect that this will find a few bugs in dusty deck code...
... we'll see ... ;-)
Regression-tested. OK for trunk?
OK. Thanks for the patch!
Harald
Best regards
Thomas
Test procedure dummy arguments against global symbols, if available.
gcc/fortran/ChangeLog:
PR fortran/24878
* interface.cc (compare_parameter): Check global subroutines
passed as actual arguments for subroutine / function and
function type.
gcc/testsuite/ChangeLog:
PR fortran/24878
* gfortran.dg/interface_51.f90: New test.
Re: [PATCH v2] RISC-V: Vector pesudoinsns with x0 operand to use imm 0
The code change looks good to me. I defer to y'all's judgment as to how it slots into the release. On Sat, Feb 8, 2025 at 9:33 AM Jeff Law wrote: > > > > On 2/7/25 9:34 PM, Vineet Gupta wrote: > > A couple of Vector pseudoinstructions use x0 scalar which being regfile > > crosser could be inefficient on certain wider uarches. > > > > Use the imm 0 form, which should be functionally equivalent. > > > > pseudoinsnorig insn with x0 this patch > > --- > > vneg.v vd,vs vrsub.vx vd,vs,x0 vrsub.vi vd,vs,0 > > vncvt.x.x.w vd,vs,vm vnsrl.wx vd,vs,x0,vm vnsrl.wi vd,vs,0,vm > > vwcvt.x.x.v vd,vs,vm vwadd.vx vd,vs,x0,vm (imm not supported) > > > > This passes my testsuite A/B run but obviously wait for the CI tester to > > give a green light. > > > > gcc/ChangeLog: > > * config/riscv/vector.md: vncvt substitute vnsrl. > > vnsrl with x0 replace with immediate 0. > > vneg substitute vrsub. > > > > gcc/testsuite/ChangeLog: > > > > * gcc.target/riscv/rvv/autovec/cond/cond_convert_int2int-rv32-1.c: > > Change > > expected pattern. > > * gcc.target/riscv/rvv/autovec/cond/cond_convert_int2int-rv32-2.c: > > Ditto. > > * gcc.target/riscv/rvv/autovec/cond/cond_convert_int2int-rv64-1.c: > > Ditto. > > * gcc.target/riscv/rvv/autovec/cond/cond_convert_int2int-rv64-2.c: > > Ditto. > > * gcc.target/riscv/rvv/autovec/cond/cond_unary-1.c: Ditto. > > * gcc.target/riscv/rvv/autovec/cond/cond_unary-2.c: Ditto. > > * gcc.target/riscv/rvv/autovec/cond/cond_unary-3.c: Ditto. > > * gcc.target/riscv/rvv/autovec/cond/cond_unary-4.c: Ditto. > > * gcc.target/riscv/rvv/autovec/cond/cond_unary-5.c: Ditto. > > * gcc.target/riscv/rvv/autovec/cond/cond_unary-6.c: Ditto. > > * gcc.target/riscv/rvv/autovec/cond/cond_unary-7.c: Ditto. > > * gcc.target/riscv/rvv/autovec/cond/cond_unary-8.c: Ditto. > > * gcc.target/riscv/rvv/autovec/conversions/vncvt-rv32gcv.c: Ditto. > > * gcc.target/riscv/rvv/autovec/conversions/vncvt-rv64gcv.c: Ditto. > > * gcc.target/riscv/rvv/autovec/sat/vec_sat_u_sub_trunc-1-u16.c: Ditto > > * gcc.target/riscv/rvv/autovec/sat/vec_sat_u_sub_trunc-1-u32.c: Ditto. > > * gcc.target/riscv/rvv/autovec/sat/vec_sat_u_sub_trunc-1-u8.c: Ditto. > > * gcc.target/riscv/rvv/autovec/unop/abs-rv32gcv.c: Ditto. > > * gcc.target/riscv/rvv/autovec/unop/abs-rv64gcv.c: Ditto. > > * gcc.target/riscv/rvv/autovec/unop/vneg-rv32gcv.c: Ditto. > > * gcc.target/riscv/rvv/autovec/unop/vneg-rv64gcv.c: Ditto. > > * gcc.target/riscv/rvv/autovec/vls/abs-2.c: Ditto. > > * gcc.target/riscv/rvv/autovec/vls/cond_convert-11.c: Ditto. > > * gcc.target/riscv/rvv/autovec/vls/cond_convert-12.c: Ditto. > > * gcc.target/riscv/rvv/autovec/vls/cond_neg-1.c: Ditto. > > * gcc.target/riscv/rvv/autovec/vls/cond_trunc-1.c: Ditto. > > * gcc.target/riscv/rvv/autovec/vls/cond_trunc-2.c: Ditto. > > * gcc.target/riscv/rvv/autovec/vls/cond_trunc-3.c: Ditto. > > * gcc.target/riscv/rvv/autovec/vls/convert-11.c: Ditto. > > * gcc.target/riscv/rvv/autovec/vls/convert-12.c: Ditto. > > * gcc.target/riscv/rvv/autovec/vls/neg-1.c: Ditto. > > * gcc.target/riscv/rvv/autovec/vls/trunc-1.c: Ditto. > > * gcc.target/riscv/rvv/autovec/vls/trunc-2.c: Ditto. > > * gcc.target/riscv/rvv/autovec/vls/trunc-3.c: Ditto. > > * gcc.target/riscv/rvv/base/simplify-vdiv.c: Ditto. > > * gcc.target/riscv/rvv/base/unop_v_constraint-1.c: Ditto. > LGTM. I think the only question is whether or not to make an exception > for this or not. We are in stage4 after all ;-) Figure we can make a > decision on the Tues call if you're available. > > jeff >
