[PATCH v4 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

[Tsukasa OI via Gcc-patches]

From: Tsukasa OI 

'XVentanaCondOps' is a vendor extension from Ventana Micro Systems
containing two instructions for conditional move and will be supported on
their Veyron V1 CPU.

And most notably (for historical reasons), 'XVentanaCondOps' and the
standard 'Zicond' extension are functionally equivalent (only encodings and
instruction names are different).

*   czero.eqz == vt.maskc
*   czero.nez == vt.maskcn

This commit adds support for the 'XVentanaCondOps' extension by extending
'Zicond' extension support.  With this, we can now reuse the optimization
using the 'Zicond' extension for the 'XVentanaCondOps' extension.

The specification for the 'XVentanaCondOps' extension is based on:


gcc/ChangeLog:

* common/config/riscv/riscv-common.cc (riscv_ext_flag_table):
Parse 'XVentanaCondOps' extension.
* config/riscv/riscv-opts.h (MASK_XVENTANACONDOPS): New.
(TARGET_XVENTANACONDOPS): Ditto.
(TARGET_ZICOND_LIKE): New to represent targets with conditional
moves like 'Zicond'.  It includes RV64 + 'XVentanaCondOps'.
* config/riscv/riscv.cc (riscv_rtx_costs): Replace TARGET_ZICOND
with TARGET_ZICOND_LIKE.
(riscv_expand_conditional_move): Ditto.
* config/riscv/riscv.md (movcc): Replace TARGET_ZICOND with
TARGET_ZICOND_LIKE.
* config/riscv/riscv.opt: Add new riscv_xventana_subext.
* config/riscv/zicond.md: Modify description.
(eqz_ventana): New to match corresponding czero instructions.
(nez_ventana): Ditto.
(*czero..): Emit a 'XVentanaCondOps' instruction if
'Zicond' is not available but 'XVentanaCondOps' + RV64 is.
(*czero..): Ditto.
(*czero.eqz..opt1): Ditto.
(*czero.nez..opt2): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/xventanacondops-primitiveSemantics.c: New test,
* gcc.target/riscv/xventanacondops-primitiveSemantics-rv32.c: New
test to make sure that XVentanaCondOps instructions are disabled
on RV32.
* gcc.target/riscv/xventanacondops-xor-01.c: New test,
---
 gcc/common/config/riscv/riscv-common.cc   |  2 +
 gcc/config/riscv/riscv-opts.h |  6 +++
 gcc/config/riscv/riscv.cc |  4 +-
 gcc/config/riscv/riscv.md |  2 +-
 gcc/config/riscv/riscv.opt|  3 ++
 gcc/config/riscv/zicond.md| 53 +++
 .../xventanacondops-primitiveSemantics-rv32.c |  8 +++
 .../xventanacondops-primitiveSemantics.c  | 10 
 .../gcc.target/riscv/xventanacondops-xor-01.c |  8 +++
 9 files changed, 82 insertions(+), 14 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.target/riscv/xventanacondops-primitiveSemantics-rv32.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/xventanacondops-primitiveSemantics.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/xventanacondops-xor-01.c

diff --git a/gcc/common/config/riscv/riscv-common.cc 
b/gcc/common/config/riscv/riscv-common.cc
index f142212f2edc..9a0a68fe5db3 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -1493,6 +1493,8 @@ static const riscv_ext_flag_table_t 
riscv_ext_flag_table[] =
   {"xtheadmempair", _options::x_riscv_xthead_subext, MASK_XTHEADMEMPAIR},
   {"xtheadsync",_options::x_riscv_xthead_subext, MASK_XTHEADSYNC},
 
+  {"xventanacondops", _options::x_riscv_xventana_subext, 
MASK_XVENTANACONDOPS},
+
   {NULL, NULL, 0}
 };
 
diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
index b6b5907e111b..a525f679683c 100644
--- a/gcc/config/riscv/riscv-opts.h
+++ b/gcc/config/riscv/riscv-opts.h
@@ -321,6 +321,12 @@ enum riscv_entity
 #define TARGET_XTHEADMEMPAIR ((riscv_xthead_subext & MASK_XTHEADMEMPAIR) != 0)
 #define TARGET_XTHEADSYNC((riscv_xthead_subext & MASK_XTHEADSYNC) != 0)
 
+#define MASK_XVENTANACONDOPS  (1 << 0)
+
+#define TARGET_XVENTANACONDOPS ((riscv_xventana_subext & MASK_XVENTANACONDOPS) 
!= 0)
+
+#define TARGET_ZICOND_LIKE (TARGET_ZICOND || (TARGET_XVENTANACONDOPS && 
TARGET_64BIT))
+
 /* We only enable VLS modes for VLA vectorization since fixed length VLMAX mode
is the highest priority choice and should not conflict with VLS modes.  */
 #define TARGET_VECTOR_VLS  
\
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 475fb2841427..a6e58e4f1159 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -2744,7 +2744,7 @@ riscv_rtx_costs (rtx x, machine_mode mode, int 
outer_code, int opno ATTRIBUTE_UN
  *total = COSTS_N_INSNS (1);
  return true;
}
-  else if (TARGET_ZICOND
+  else if (TARGET_ZICOND_LIKE
   && outer_code == SET
   && ((GET_CODE (XEXP (x, 1)) == REG
&& XEXP (x, 

[PATCH v4 0/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

[Tsukasa OI via Gcc-patches]

PATCH v1:

PATCH v2:

PATCH v3:


Changes: v1 -> v2
*   Removed bogus opt2 pattern as pointed out in:

note that this is not in the ChangeLog expecting the patch above
applies first.

Changes: v2 -> v3
*   Instead of removing opt2 pattern, fix opt2 pattern:


Changes: v3 -> v4
*   Leave only specific condition on {eq,ne}z_ventana code_attr.
(eqz_ventana, nez_ventana): "maskcn" -> "n", "maskc" -> ""
(*czero..) "vt." -> "vt.maskc"
(*czero..) "vt." -> "vt.maskc"
*   Testsuite:
Reuse "zicond-*.c" (#include from "xventanacondops-*.c")
*   Minor Comment: ";; Zicond" -> ";; Zicond / XVentanaCondOps"
*   Rebase against commit e87212ead5e9 ("RISC-V: zicond: Fix opt2 pattern")


On 2023/09/06 12:07, Jeff Law wrote:
> You actually don't even have to break out the common parts.  The dg-
> directives in an included file aren't parsed by the dg framework.

Wow, that was right.  It can be sometimes confusing but very useful
in this case.  Thanks for the info!


Sincerely,
Tsukasa




Tsukasa OI (1):
  RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

 gcc/common/config/riscv/riscv-common.cc   |  2 +
 gcc/config/riscv/riscv-opts.h |  6 +++
 gcc/config/riscv/riscv.cc |  4 +-
 gcc/config/riscv/riscv.md |  2 +-
 gcc/config/riscv/riscv.opt|  3 ++
 gcc/config/riscv/zicond.md| 53 +++
 .../xventanacondops-primitiveSemantics-rv32.c |  8 +++
 .../xventanacondops-primitiveSemantics.c  | 10 
 .../gcc.target/riscv/xventanacondops-xor-01.c |  8 +++
 9 files changed, 82 insertions(+), 14 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.target/riscv/xventanacondops-primitiveSemantics-rv32.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/xventanacondops-primitiveSemantics.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/xventanacondops-xor-01.c


base-commit: c1597e7fb9f9ecb9d7c33b5afa48031f284375de
-- 
2.42.0

Re: [PATCH] xtensa: Optimize boolean evaluation when SImode EQ/NE to zero if TARGET_MINMAX

[Takayuki 'January June' Suwa via Gcc-patches]

On 2023/09/06 8:01, Max Filippov wrote:
> Hi Suwa-san,
Hi!

> 
> On Tue, Sep 5, 2023 at 2:29 AM Takayuki 'January June' Suwa
>  wrote:
>>
>> This patch optimizes the boolean evaluation for equality to 0 in SImode
>> using the MINU (Minimum Value Unsigned) machine instruction available
>> when TARGET_MINMAX is configured, for example, (x != 0) to MINU(x, 1)
>> and (x == 0) to (MINU(x, 1) ^ 1).
>>
>> /* example */
>> int test0(int x) {
>>   return x == 0;
>> }
>> int test1(int x) {
>>   return x != 0;
>> }
>>
>> ;; before
>> test0:
>> mov.n   a10, a2
>> movi.n  a9, 1
>> movi.n  a2, 0
>> moveqz  a2, a9, a10
>> ret.n
>> test1:
>> mov.n   a10, a2
>> movi.n  a9, 1
>> movi.n  a2, 0
>> movnez  a2, a9, a10
>> ret.n
>>
>> ;; after (prereq. TARGET_MINMAX)
>> test0:
>> movi.n  a9, 1
>> minua2, a2, a9
>> xor a2, a2, a9
>> ret.n
> 
> ISTM that test0 could be done with movnez in the same three instructions:
> 
>   movi a9, 1
>   movnez a2, a9, a2
>   xor a2, a2, a9

Unfortunately, the MOV[EQ/NE]Z machine instruction can only be used to 
implement the functionality if the input and output physical registers are the 
same (a2 in the example).
In fact, when modified to use MOV[EQ/NE]Z, GCC register allocator often 
prepends a register move instruction to satisfy the above constraint (and thus 
often does not save instruction count).

I'm currently trying to see if I can somehow follow up after the physical 
register is determined (around split2 or peephole2).

> 
>> test1:
>> movi.n  a9, 1
>> minua2, a2, a9
>> ret.n
> 
> ISTM that test1 could be done with movnez in the same two instructions:
> 
>   movi a9, 1
>   movnez a2, a9, a2
> 

Re: [PATCH] RISC-V: Add conditional sqrt autovec pattern

[Lehua Ding]

On 2023/9/6 8:31, Jeff Law wrote:



On 9/3/23 22:49, Lehua Ding wrote:

This patch adds a combined pattern for combining vfsqrt.v and vcond_mask.

gcc/ChangeLog:

* config/riscv/autovec-opt.md (*cond_):
Add sqrt + vcond_mask combine pattern.
* config/riscv/autovec.md (2):
Change define_expand to define_insn_and_split.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_sqrt_run-1.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_sqrt_run-2.c: New test.

OK.  Thanks.

FWIW, I thought we only had the reciprocal sqrt estimator, but in fact 
rvv does define a real vector sqrt.   So the concerns we kicked around 
in the meeting this morning turned out not be warranted.


This raises one of the very interesting questions in this space, 
specifically whether or not we should be using the rsqrt estimator with 
correction steps.   Unless the vfsqrt latency is really bad, it's going 
to be hard to make a vfrsqrt7 based sequence faster -- but the vfrsqrt7 
sequences will be pipelinable while vfsqrt almost certainly isn't.


Sadly we don't have a scalar FP rsqrt estimator.  Though I certainly 
ponder using the vector one -- there's a neat trick you can do with the 
nab benchmark from spec and produce sqrt and rsqrt at the same time with 
a Goldschmidt sequence.  It requires a bit of hackery to make new tree 
nodes, but it was definitely worth it on other targets I've worked on.


Committed, thank Jeff.

--
Best,
Lehua

Re: [PATCH v3] RISC-V:Optimize the MASK opt generation

[Kito Cheng via Gcc-patches]

Reading the manual again, it seems I missed something in the manual
before, the MASK syntax already says we can specify Var to select the
variable other than target_flags, but I tried that not work when we
only declare Mask with Var (e.g. "Mask(VECTOR_ELEN_32)
Var(riscv_vector_elen_flags)" still using target_flags)

So maybe we should just fix that instead of extending the syntax?
e.g.
Mask(VECTOR_ELEN_32)Var(riscv_vector_elen_flags)
rather than
Mask(VECTOR_ELEN_32)in TargetVariable(riscv_vector_elen_flags)


On Wed, Sep 6, 2023 at 10:03 AM Feng Wang  wrote:
>
> This patch rebases the change of "[PATCH] RISC-V: Optimize the MASK opt
> generation" and add the new explanation in the options.texi.
> Please check the detail info on the
> "https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg302295.html;
> gcc/ChangeLog:
>
> * config/riscv/riscv-opts.h (MASK_ZICSR):
> (MASK_ZIFENCEI): Delete;
> (MASK_ZIHINTNTL):Ditto;
> (MASK_ZIHINTPAUSE):  Ditto;
> (TARGET_ZICSR):  Ditto;
> (TARGET_ZIFENCEI):   Ditto;
> (TARGET_ZIHINTNTL):  Ditto;
> (TARGET_ZIHINTPAUSE):Ditto;
> (MASK_ZAWRS):Ditto;
> (TARGET_ZAWRS):  Ditto;
> (MASK_ZBA):  Ditto;
> (MASK_ZBB):  Ditto;
> (MASK_ZBC):  Ditto;
> (MASK_ZBS):  Ditto;
> (TARGET_ZBA):Ditto;
> (TARGET_ZBB):Ditto;
> (TARGET_ZBC):Ditto;
> (TARGET_ZBS):Ditto;
> (MASK_ZFINX):Ditto;
> (MASK_ZDINX):Ditto;
> (MASK_ZHINX):Ditto;
> (MASK_ZHINXMIN): Ditto;
> (TARGET_ZFINX):  Ditto;
> (TARGET_ZDINX):  Ditto;
> (TARGET_ZHINX):  Ditto;
> (TARGET_ZHINXMIN):   Ditto;
> (MASK_ZBKB): Ditto;
> (MASK_ZBKC): Ditto;
> (MASK_ZBKX): Ditto;
> (MASK_ZKNE): Ditto;
> (MASK_ZKND): Ditto;
> (MASK_ZKNH): Ditto;
> (MASK_ZKR):  Ditto;
> (MASK_ZKSED):Ditto;
> (MASK_ZKSH): Ditto;
> (MASK_ZKT):  Ditto;
> (TARGET_ZBKB):   Ditto;
> (TARGET_ZBKC):   Ditto;
> (TARGET_ZBKX):   Ditto;
> (TARGET_ZKNE):   Ditto;
> (TARGET_ZKND):   Ditto;
> (TARGET_ZKNH):   Ditto;
> (TARGET_ZKR):Ditto;
> (TARGET_ZKSED):  Ditto;
> (TARGET_ZKSH):   Ditto;
> (TARGET_ZKT):Ditto;
> (MASK_ZTSO): Ditto;
> (TARGET_ZTSO):   Ditto;
> (MASK_VECTOR_ELEN_32):   Ditto;
> (MASK_VECTOR_ELEN_64):   Ditto;
> (MASK_VECTOR_ELEN_FP_32):Ditto;
> (MASK_VECTOR_ELEN_FP_64):Ditto;
> (MASK_VECTOR_ELEN_FP_16):Ditto;
> (TARGET_VECTOR_ELEN_32): Ditto;
> (TARGET_VECTOR_ELEN_64): Ditto;
> (TARGET_VECTOR_ELEN_FP_32):Ditto;
> (TARGET_VECTOR_ELEN_FP_64):Ditto;
> (TARGET_VECTOR_ELEN_FP_16):Ditto;
>  (MASK_ZVBB):   Ditto;
> (MASK_ZVBC):   Ditto;
> (TARGET_ZVBB): Ditto;
> (TARGET_ZVBC): Ditto;
> (MASK_ZVKG):   Ditto;
> (MASK_ZVKNED): Ditto;
> (MASK_ZVKNHA): Ditto;
> (MASK_ZVKNHB): Ditto;
> (MASK_ZVKSED): Ditto;
> (MASK_ZVKSH):  Ditto;
> (MASK_ZVKN):   Ditto;
> (MASK_ZVKNC):  Ditto;
> (MASK_ZVKNG):  Ditto;
> (MASK_ZVKS):   Ditto;
> (MASK_ZVKSC):  Ditto;
> (MASK_ZVKSG):  Ditto;
> (MASK_ZVKT):   Ditto;
> (TARGET_ZVKG): Ditto;
> (TARGET_ZVKNED):   Ditto;
> (TARGET_ZVKNHA):   Ditto;
> (TARGET_ZVKNHB):   Ditto;
> (TARGET_ZVKSED):   Ditto;
> (TARGET_ZVKSH):Ditto;
> (TARGET_ZVKN): Ditto;
> (TARGET_ZVKNC):Ditto;
> (TARGET_ZVKNG):Ditto;
> (TARGET_ZVKS): Ditto;
> (TARGET_ZVKSC):Ditto;
> (TARGET_ZVKSG):Ditto;
> (TARGET_ZVKT): Ditto;
> (MASK_ZVL32B): Ditto;
> (MASK_ZVL64B): Ditto;
> (MASK_ZVL128B):Ditto;
> (MASK_ZVL256B):Ditto;
> (MASK_ZVL512B):Ditto;
> (MASK_ZVL1024B):   Ditto;
> (MASK_ZVL2048B):   Ditto;
> (MASK_ZVL4096B):   Ditto;
> (MASK_ZVL8192B):   Ditto;
> (MASK_ZVL16384B):  Ditto;
> (MASK_ZVL32768B):  Ditto;
> (MASK_ZVL65536B):  Ditto;
> (TARGET_ZVL32B):   Ditto;
> (TARGET_ZVL64B):   Ditto;
> (TARGET_ZVL128B):  Ditto;
> (TARGET_ZVL256B):  Ditto;
> (TARGET_ZVL512B):  Ditto;
> 

[pushed] c++: [[no_unique_address]] and cv-qualified type

[Jason Merrill via Gcc-patches]

Tested x86_64-pc-linux-gnu, applying to trunk.

-- 8< --

We were checking for overlap using same_type_p and therefore allocating two
Empty subobjects at the same offset because one was cv-qualified.

This gives the warning at the location of the class name rather than the
member declaration, but this should be a rare enough issue that it doesn't
seem worth trying to be more precise.

gcc/ChangeLog:

* common.opt: Update -fabi-version=19.

gcc/cp/ChangeLog:

* class.cc (check_subobject_offset): Check
same_type_ignoring_top_level_qualifiers_p.

gcc/testsuite/ChangeLog:

* g++.dg/abi/no_unique_address8.C: New test.
* g++.dg/abi/no_unique_address8a.C: New test.
---
 gcc/common.opt|  1 +
 gcc/cp/class.cc   | 28 +++--
 gcc/testsuite/g++.dg/abi/no_unique_address8.C | 30 ++
 .../g++.dg/abi/no_unique_address8a.C  | 31 +++
 4 files changed, 88 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/abi/no_unique_address8.C
 create mode 100644 gcc/testsuite/g++.dg/abi/no_unique_address8a.C

diff --git a/gcc/common.opt b/gcc/common.opt
index 3e1939293e8..f137a1f81ac 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1011,6 +1011,7 @@ Driver Undocumented
 ; Default in G++ 13.
 ;
 ; 19: Emits ABI tags if needed in structured binding mangled names.
+; Ignores cv-quals on [[no_unique_object]] members.
 ; Default in G++ 14.
 ;
 ; Additional positive integers will be assigned as new versions of
diff --git a/gcc/cp/class.cc b/gcc/cp/class.cc
index 778759237dc..9139a0075ab 100644
--- a/gcc/cp/class.cc
+++ b/gcc/cp/class.cc
@@ -4053,9 +4053,33 @@ check_subobject_offset (tree type, tree offset, 
splay_tree offsets)
   if (!n)
 return 0;
 
+  enum { ignore, fast, slow, warn }
+  cv_check = (abi_version_crosses (19) ? slow
+ : abi_version_at_least (19) ? fast
+ : ignore);
   for (t = (tree) n->value; t; t = TREE_CHAIN (t))
-if (same_type_p (TREE_VALUE (t), type))
-  return 1;
+{
+  tree elt = TREE_VALUE (t);
+
+  if (same_type_p (elt, type))
+   return 1;
+
+  if (cv_check != ignore
+ && same_type_ignoring_top_level_qualifiers_p (elt, type))
+   {
+ if (cv_check == fast)
+   return 1;
+ cv_check = warn;
+   }
+}
+
+  if (cv_check == warn)
+{
+  warning (OPT_Wabi, "layout of %qs member of type %qT changes in %qs",
+  "[[no_unique_address]]", type, "-fabi-version=19");
+  if (abi_version_at_least (19))
+   return 1;
+}
 
   return 0;
 }
diff --git a/gcc/testsuite/g++.dg/abi/no_unique_address8.C 
b/gcc/testsuite/g++.dg/abi/no_unique_address8.C
new file mode 100644
index 000..6aa2bba7810
--- /dev/null
+++ b/gcc/testsuite/g++.dg/abi/no_unique_address8.C
@@ -0,0 +1,30 @@
+// { dg-do compile { target c++11 } }
+// { dg-options "-fabi-version=19 -Wabi=18" }
+
+#include 
+
+#define NOUNIQUE [[no_unique_address]]
+
+struct Empty { };
+#define CHECK_DISTINCT(type, field1, field2) static_assert(offsetof(type, 
field1) != offsetof(type, field2))
+
+struct A1 {
+NOUNIQUE Empty a;
+Empty b;
+};
+CHECK_DISTINCT(A1, a, b);
+struct A2 {
+NOUNIQUE const Empty a;
+const Empty b;
+};
+CHECK_DISTINCT(A2, a, b);
+struct A3 {// { dg-warning "layout" }
+NOUNIQUE const Empty a;
+Empty b;
+};
+CHECK_DISTINCT(A3, a, b);
+struct A4 {// { dg-warning "layout" }
+NOUNIQUE Empty a;
+const Empty b;
+};
+CHECK_DISTINCT(A4, a, b);
diff --git a/gcc/testsuite/g++.dg/abi/no_unique_address8a.C 
b/gcc/testsuite/g++.dg/abi/no_unique_address8a.C
new file mode 100644
index 000..c5d48088529
--- /dev/null
+++ b/gcc/testsuite/g++.dg/abi/no_unique_address8a.C
@@ -0,0 +1,31 @@
+// { dg-do compile { target c++11 } }
+// { dg-options "-fabi-version=18 -Wabi=19" }
+
+#include 
+
+#define NOUNIQUE [[no_unique_address]]
+
+struct Empty { };
+#define CHECK_DISTINCT(type, field1, field2) static_assert(offsetof(type, 
field1) != offsetof(type, field2))
+#define CHECK_SAME(type, field1, field2) static_assert(offsetof(type, field1) 
== offsetof(type, field2))
+
+struct A1 {
+NOUNIQUE Empty a;
+Empty b;
+};
+CHECK_DISTINCT(A1, a, b);
+struct A2 {
+NOUNIQUE const Empty a;
+const Empty b;
+};
+CHECK_DISTINCT(A2, a, b);
+struct A3 {// { dg-warning "layout" }
+NOUNIQUE const Empty a;
+Empty b;
+};
+CHECK_SAME(A3, a, b);
+struct A4 {// { dg-warning "layout" }
+NOUNIQUE Empty a;
+const Empty b;
+};
+CHECK_SAME(A4, a, b);

base-commit: 244d1321340116b7780e78096356f69662fd0e18
-- 
2.39.3

Re: [PATCH v3 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

[Palmer Dabbelt]

On Tue, 05 Sep 2023 20:07:16 PDT (-0700), gcc-patches@gcc.gnu.org wrote:



On 9/5/23 20:33, Tsukasa OI wrote:


Internally we have this as:


(TARGET_ZICOND || TARGET_XVENTANACONDOPS)

I don't really care, so I'm happy to go with yours.



Because XVentanaCondOps instructions are only available on 64-bit target
(I wanted to prevent misuses because we don't reject XVentanaCondOps on
RV32), the target expression would be:

(a) (TARGT_ZICOND || (TARGET_XVENTANACONDOPS && TARGET_64BIT))

and I had three options to deal with it.

1.  Use the plain expression (a)
2.  Name te expression (a)
3.  Enable TARGET_XVENTANACONDOPS only on 64-bit target

I think option 2 is the simplest yet understandable.

Sure.  It may also give us the option to roll in some of the thead code
at some point.  Their conditional move support seems to line up pretty
well with zicond/xventanacondops too, though I haven't looked at it very
deeply yet.


IIUC the T-Head stuff is actually a conditional move, so it's a little 
different than the conditional move/zero extensions (which IIUC have 
exactly the same semantics, just different encodings).   Hopefully the 
cmov fits in a bit easier, we shouldn't need to juggle the extra 0 
input.



I'm happy to hear that because I had no confidence so whether we can use
#include to share common parts.  I haven't tried yet but I believe we
have to #include only common parts (not including dg instructions
containing -march=..._zicond) so I will likely required to modify zicond
tests as well.

You actually don't even have to break out the common parts.  The dg-
directives in an included file aren't parsed by the dg framework.




I'll submit PATCH v4 (not committing directly) as changes will be a bit
larger (and Jeff's words seem "near approval" even after fixing the
tests, not complete approval).

Sounds perfect.  Given the bulk of the review work is already done, the
final review ack will be easy.

jeff

Re: [PATCH v3 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

[Jeff Law via Gcc-patches]

On 9/5/23 20:33, Tsukasa OI wrote:


Internally we have this as:

(TARGET_ZICOND || TARGET_XVENTANACONDOPS)

I don't really care, so I'm happy to go with yours.


Because XVentanaCondOps instructions are only available on 64-bit target
(I wanted to prevent misuses because we don't reject XVentanaCondOps on
RV32), the target expression would be:

(a) (TARGET_ZICOND || (TARGET_XVENTANACONDOPS && TARGET_64BIT))

and I had three options to deal with it.

1.  Use the plain expression (a)
2.  Name the expression (a)
3.  Enable TARGET_XVENTANACONDOPS only on 64-bit target

I think option 2 is the simplest yet understandable.
Sure.  It may also give us the option to roll in some of the thead code 
at some point.  Their conditional move support seems to line up pretty 
well with zicond/xventanacondops too, though I haven't looked at it very 
deeply yet.






I'm happy to hear that because I had no confidence so whether we can use
#include to share common parts.  I haven't tried yet but I believe we
have to #include only common parts (not including dg instructions
containing -march=..._zicond) so I will likely required to modify zicond
tests as well.
You actually don't even have to break out the common parts.  The dg- 
directives in an included file aren't parsed by the dg framework.





I'll submit PATCH v4 (not committing directly) as changes will be a bit
larger (and Jeff's words seem "near approval" even after fixing the
tests, not complete approval).
Sounds perfect.  Given the bulk of the review work is already done, the 
final review ack will be easy.


jeff

Re: [PATCH] RISC-V: Emit .note.GNU-stack for non-linux target as well

[Kito Cheng via Gcc-patches]

RISC-V qemu default that to false, which mean stack can't execute anything
by default, that's match RISC-V linux kernel behaviour, but the problem is
risc-v bare metal toolchain may execute code on stack *without* that tag,
that does not cause problems before for running tests on qemu user mode,
but...it causes problems once using newer qemu (with that patch).

Fangrui Song  於 2023年9月6日 週三 04:53 寫道：

> On Tue, Sep 5, 2023 at 5:14 AM Kito Cheng via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
>
>> committed, thanks :)
>>
>> On Tue, Sep 5, 2023 at 3:18 PM Jeff Law via Gcc-patches
>>  wrote:
>> >
>> >
>> >
>> > On 8/31/23 03:05, Kito Cheng wrote:
>> > > We only emit that on linux target before, that not problem before,
>> > > however Qemu has fix a bug to make qemu user mode honor
>> PT_GNU_STACK[1],
>> > > that will cause problem when we test baremetal with qemu.
>> > >
>> > > So the straightforward is enable that as well for non-linux toolchian,
>> > > the price is that will increase few bytes for each binary.
>> > >
>> > > [1]
>> https://github.com/qemu/qemu/commit/872f3d046f2381e3f416519e82df96bd60818311
>> > >
>> > > gcc/ChangeLog:
>> > >
>> > >   * config/riscv/linux.h (TARGET_ASM_FILE_END): Move ...
>> > >   * config/riscv/riscv.cc (TARGET_ASM_FILE_END): to here.
>> > OK.
>> > jeff
>>
>
> Does
> https://github.com/qemu/qemu/commit/872f3d046f2381e3f416519e82df96bd60818311
> use #define EXSTACK_DEFAULT true
> for riscv?
>
>
>
>
> --
> 宋方睿
>

[COMMITTED] RISC-V: typo: add closing paren to a comment

[Tsukasa OI via Gcc-patches]

From: Tsukasa OI 

gcc/ChangeLog:

* config/riscv/zicond.md: Add closing parent to a comment.
---
 gcc/config/riscv/zicond.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/riscv/zicond.md b/gcc/config/riscv/zicond.md
index 1721e1011ea8..c28bee5d5709 100644
--- a/gcc/config/riscv/zicond.md
+++ b/gcc/config/riscv/zicond.md
@@ -64,7 +64,7 @@
 )
 
 ;; Combine creates this form in some cases (particularly the coremark
-;; CRC loop.
+;; CRC loop).
 (define_split
   [(set (match_operand:X 0 "register_operand")
(and:X (sign_extract:X (match_operand:X 1 "register_operand")

base-commit: ce65641354d98fc80912d5516b7fea87c344c2cc
-- 
2.42.0

Re: [PATCH v3 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

[Tsukasa OI via Gcc-patches]

On 2023/09/06 9:17, Jeff Law wrote:
> 
> 
> On 9/5/23 06:10, Tsukasa OI wrote:
>> From: Tsukasa OI 
>>
>> 'XVentanaCondOps' is a vendor extension from Ventana Micro Systems
>> containing two instructions for conditional move and will be supported on
>> their Veyron V1 CPU.
>>
>> And most notably (for historical reasons), 'XVentanaCondOps' and the
>> standard 'Zicond' extension are functionally equivalent (only
>> encodings and
>> instruction names are different).
>>
>> *   czero.eqz == vt.maskc
>> *   czero.nez == vt.maskcn
>>
>> This commit adds support for the 'XVentanaCondOps' extension by extending
>> 'Zicond' extension support.  With this, we can now reuse the optimization
>> using the 'Zicond' extension for the 'XVentanaCondOps' extension.
>>
>> The specification for the 'XVentanaCondOps' extension is based on:
>> 
>>
>> gcc/ChangeLog:
>>
>> * common/config/riscv/riscv-common.cc (riscv_ext_flag_table):
>> Parse 'XVentanaCondOps' extension.
>> * config/riscv/riscv-opts.h (MASK_XVENTANACONDOPS): New.
>> (TARGET_XVENTANACONDOPS): Ditto.
>> (TARGET_ZICOND_LIKE): New to represent targets with conditional
>> moves like 'Zicond'.  It includes RV64 + 'XVentanaCondOps'.
>> * config/riscv/riscv.cc (riscv_rtx_costs): Replace TARGET_ZICOND
>> with TARGET_ZICOND_LIKE.
>> (riscv_expand_conditional_move): Ditto.
>> * config/riscv/riscv.md (movcc): Replace TARGET_ZICOND with
>> TARGET_ZICOND_LIKE.
>> * config/riscv/riscv.opt: Add new riscv_xventana_subext.
>> * config/riscv/zicond.md: Modify description.
>> (eqz_ventana): New to match corresponding czero instructions.
>> (nez_ventana): Ditto.
>> (*czero..): Emit a 'XVentanaCondOps' instruction if
>> 'Zicond' is not available but 'XVentanaCondOps' + RV64 is.
>> (*czero..): Ditto.
>> (*czero.eqz..opt1): Ditto.
>> (*czero.nez..opt2): Ditto.
>>
>> gcc/testsuite/ChangeLog:
>>
>> * gcc.target/riscv/xventanacondops-primitiveSemantics.c: New test,
>> modified from zicond-primitiveSemantics.c.
>> * gcc.target/riscv/xventanacondops-primitiveSemantics-rv32.c: New
>> test to make sure that XVentanaCondOps instructions are disabled
>> on RV32.
>> * gcc.target/riscv/xventanacondops-xor-01.c: New test, modified
>> from zicond-xor-01.c.
>> ---
>>   gcc/common/config/riscv/riscv-common.cc   |  2 +
>   \
>> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
>> index 8d8f7b4f16ed..eb10f4a3323f 100644
>> --- a/gcc/config/riscv/riscv.cc
>> +++ b/gcc/config/riscv/riscv.cc
>> @@ -2745,7 +2745,7 @@ riscv_rtx_costs (rtx x, machine_mode mode, int
>> outer_code, int opno ATTRIBUTE_UN
>>     *total = COSTS_N_INSNS (1);
>>     return true;
>>   }
>> -  else if (TARGET_ZICOND
>> +  else if (TARGET_ZICOND_LIKE
> Internally we have this as:
> 
> (TARGET_ZICOND || TARGET_XVENTANACONDOPS)
> 
> I don't really care, so I'm happy to go with yours.

Because XVentanaCondOps instructions are only available on 64-bit target
(I wanted to prevent misuses because we don't reject XVentanaCondOps on
RV32), the target expression would be:

(a) (TARGET_ZICOND || (TARGET_XVENTANACONDOPS && TARGET_64BIT))

and I had three options to deal with it.

1.  Use the plain expression (a)
2.  Name the expression (a)
3.  Enable TARGET_XVENTANACONDOPS only on 64-bit target

I think option 2 is the simplest yet understandable.

> 
> 
>> +(define_code_attr eqz_ventana [(eq "maskcn") (ne "maskc")])
>> +(define_code_attr nez_ventana [(eq "maskc") (ne "maskcn")])
> We did these as N/n which output n or nothing:
> 
> (define_code_attr n [(eq "n") (ne "")])
> (define_code_attr N [(eq "") (ne "n")])

That's a great idea.  I will stick to "eqz_ventana" and "nez_ventana"
but will change the contents to "n" and "".

> 
> 
>>     ;; Zicond
>>   (define_insn "*czero.."
>> @@ -28,8 +31,15 @@
>>   (const_int 0))
>>     (match_operand:GPR 2 "register_operand"   
>> "r")
>>     (const_int 0)))]
>> -  "TARGET_ZICOND"
>> -  "czero.\t%0,%2,%1"
>> +  "TARGET_ZICOND_LIKE"
>> +  {
>> +    if (TARGET_ZICOND)
>> +  return "czero.\t%0,%2,%1";
>> +    else if (TARGET_XVENTANACONDOPS && TARGET_64BIT)
>> +  return "vt.\t%0,%2,%1";
>> +    else
>> +  gcc_unreachable ();
>> +  }
>>   )
> And so the output template ends up like this:
> 
>>   "* return TARGET_ZICOND ? \"czero.\t%0,%2,%1\" :
>> \"vt.maskc\t%0,%2,%1\"; "
> 
> But again, I don't care enough about this to make it a big deal and I'm
> happy to go with your approach.
> 
> 
> 
>> diff --git
>> a/gcc/testsuite/gcc.target/riscv/xventanacondops-primitiveSemantics-rv32.c 
>> b/gcc/testsuite/gcc.target/riscv/xventanacondops-primitiveSemantics-rv32.c
>> new file mode 100644
>> index ..992f1425c54f
>> --- /dev/null
>> +++
>> 

[PATCH v3] RISC-V:Optimize the MASK opt generation

[Feng Wang]

This patch rebases the change of "[PATCH] RISC-V: Optimize the MASK opt
generation" and add the new explanation in the options.texi.
Please check the detail info on the
"https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg302295.html;
gcc/ChangeLog:

* config/riscv/riscv-opts.h (MASK_ZICSR):
(MASK_ZIFENCEI): Delete;
(MASK_ZIHINTNTL):Ditto;
(MASK_ZIHINTPAUSE):  Ditto;
(TARGET_ZICSR):  Ditto;
(TARGET_ZIFENCEI):   Ditto;
(TARGET_ZIHINTNTL):  Ditto;
(TARGET_ZIHINTPAUSE):Ditto;
(MASK_ZAWRS):Ditto;
(TARGET_ZAWRS):  Ditto;
(MASK_ZBA):  Ditto;
(MASK_ZBB):  Ditto;
(MASK_ZBC):  Ditto;
(MASK_ZBS):  Ditto;
(TARGET_ZBA):Ditto;
(TARGET_ZBB):Ditto;
(TARGET_ZBC):Ditto;
(TARGET_ZBS):Ditto;
(MASK_ZFINX):Ditto;
(MASK_ZDINX):Ditto;
(MASK_ZHINX):Ditto;
(MASK_ZHINXMIN): Ditto;
(TARGET_ZFINX):  Ditto;
(TARGET_ZDINX):  Ditto;
(TARGET_ZHINX):  Ditto;
(TARGET_ZHINXMIN):   Ditto;
(MASK_ZBKB): Ditto;
(MASK_ZBKC): Ditto;
(MASK_ZBKX): Ditto;
(MASK_ZKNE): Ditto;
(MASK_ZKND): Ditto;
(MASK_ZKNH): Ditto;
(MASK_ZKR):  Ditto;
(MASK_ZKSED):Ditto;
(MASK_ZKSH): Ditto;
(MASK_ZKT):  Ditto;
(TARGET_ZBKB):   Ditto;
(TARGET_ZBKC):   Ditto;
(TARGET_ZBKX):   Ditto;
(TARGET_ZKNE):   Ditto;
(TARGET_ZKND):   Ditto;
(TARGET_ZKNH):   Ditto;
(TARGET_ZKR):Ditto;
(TARGET_ZKSED):  Ditto;
(TARGET_ZKSH):   Ditto;
(TARGET_ZKT):Ditto;
(MASK_ZTSO): Ditto;
(TARGET_ZTSO):   Ditto;
(MASK_VECTOR_ELEN_32):   Ditto;
(MASK_VECTOR_ELEN_64):   Ditto;
(MASK_VECTOR_ELEN_FP_32):Ditto;
(MASK_VECTOR_ELEN_FP_64):Ditto;
(MASK_VECTOR_ELEN_FP_16):Ditto;
(TARGET_VECTOR_ELEN_32): Ditto;
(TARGET_VECTOR_ELEN_64): Ditto;
(TARGET_VECTOR_ELEN_FP_32):Ditto;
(TARGET_VECTOR_ELEN_FP_64):Ditto;
(TARGET_VECTOR_ELEN_FP_16):Ditto;
 (MASK_ZVBB):   Ditto;
(MASK_ZVBC):   Ditto;
(TARGET_ZVBB): Ditto;
(TARGET_ZVBC): Ditto;
(MASK_ZVKG):   Ditto;
(MASK_ZVKNED): Ditto;
(MASK_ZVKNHA): Ditto;
(MASK_ZVKNHB): Ditto;
(MASK_ZVKSED): Ditto;
(MASK_ZVKSH):  Ditto;
(MASK_ZVKN):   Ditto;
(MASK_ZVKNC):  Ditto;
(MASK_ZVKNG):  Ditto;
(MASK_ZVKS):   Ditto;
(MASK_ZVKSC):  Ditto;
(MASK_ZVKSG):  Ditto;
(MASK_ZVKT):   Ditto;
(TARGET_ZVKG): Ditto;
(TARGET_ZVKNED):   Ditto;
(TARGET_ZVKNHA):   Ditto;
(TARGET_ZVKNHB):   Ditto;
(TARGET_ZVKSED):   Ditto;
(TARGET_ZVKSH):Ditto;
(TARGET_ZVKN): Ditto;
(TARGET_ZVKNC):Ditto;
(TARGET_ZVKNG):Ditto;
(TARGET_ZVKS): Ditto;
(TARGET_ZVKSC):Ditto;
(TARGET_ZVKSG):Ditto;
(TARGET_ZVKT): Ditto;
(MASK_ZVL32B): Ditto;
(MASK_ZVL64B): Ditto;
(MASK_ZVL128B):Ditto;
(MASK_ZVL256B):Ditto;
(MASK_ZVL512B):Ditto;
(MASK_ZVL1024B):   Ditto;
(MASK_ZVL2048B):   Ditto;
(MASK_ZVL4096B):   Ditto;
(MASK_ZVL8192B):   Ditto;
(MASK_ZVL16384B):  Ditto;
(MASK_ZVL32768B):  Ditto;
(MASK_ZVL65536B):  Ditto;
(TARGET_ZVL32B):   Ditto;
(TARGET_ZVL64B):   Ditto;
(TARGET_ZVL128B):  Ditto;
(TARGET_ZVL256B):  Ditto;
(TARGET_ZVL512B):  Ditto;
(TARGET_ZVL1024B): Ditto;
(TARGET_ZVL2048B): Ditto;
(TARGET_ZVL4096B): Ditto;
(TARGET_ZVL8192B): Ditto;
(TARGET_ZVL16384B):Ditto;
(TARGET_ZVL32768B):Ditto;
(TARGET_ZVL65536B):Ditto;
(MASK_ZICBOZ): Ditto;
(MASK_ZICBOM): Ditto;
(MASK_ZICBOP): Ditto;
(TARGET_ZICBOZ):   Ditto;
(TARGET_ZICBOM):   Ditto;
(TARGET_ZICBOP):   Ditto;
(MASK_ZICOND): Ditto;
(TARGET_ZICOND):   Ditto;
(MASK_ZFA):Ditto;
(TARGET_ZFA):  Ditto;
(MASK_ZFHMIN): Ditto;
(MASK_ZFH):Ditto;
(MASK_ZVFHMIN):Ditto;
(MASK_ZVFH):   Ditto;

Re: [PATCH v2] RISC-V: Fix Zicond ICE on large constants

[Tsukasa OI via Gcc-patches]

On 2023/09/06 10:22, Jeff Law wrote:
> 
> 
> On 9/5/23 06:08, Tsukasa OI wrote:
>> From: Tsukasa OI 
>>
>> Large constant cons and/or alt will trigger ICEs building GCC target
>> libraries (libgomp and libatomic) when the 'Zicond' extension is enabled.
>>
>> For instance, zicond-ice-2.c (new test case in this commit) will cause
>> an ICE when SOME_NUMBER is 0x1000 or larger.  While opposite numbers
>> corresponding cons/alt (two temp2 variables) are checked, cons/alt
>> themselves are not checked and causing 2 ICEs building
>> GCC target libraries as of this writing:
>>
>> 1.  gcc/libatomic/config/posix/lock.c
>> 2.  gcc/libgomp/fortran.c
>>
>> Coercing a large value into a register will fix the issue.
>>
>> It also coerce a large cons into a register on "imm, imm" case (the
>> author
>> could not reproduce but possible to cause an ICE).
>>
>> gcc/ChangeLog:
>>
>> * config/riscv/riscv.cc (riscv_expand_conditional_move): Force
>> large constant cons/alt into a register.
>>
>> gcc/testsuite/ChangeLog:
>>
>> * gcc.target/riscv/zicond-ice-2.c: New test.  This is based on
>> an ICE at libat_lock_n func on gcc/libatomic/config/posix/lock.c
>> but heavily minimized.
> "New test." is sufficient.  No need to change it, just a note going
> forward.
> 
> OK.  Thanks for taking care of this.
> 
> jeff
> 

Thanks for reviewing.  I'll remember that for the next time (I am adding
brief description in Binutils but not *that* long compared to this).

Committing.

Tsukasa

Re: Re: [PATCH 2/2] [RISC-V] Enalble zcmp for -Os

[Fei Gao]

On 2023-09-05 20:02  Kito Cheng  wrote:
>
>> @@ -5569,7 +5571,9 @@ riscv_avoid_multi_push (const struct riscv_frame_info 
>> *frame)
>>  {
>>    if (!TARGET_ZCMP || crtl->calls_eh_return || frame_pointer_needed
>>    || cfun->machine->interrupt_handler_p || cfun->machine->varargs_size 
>>!= 0
>> -  || crtl->args.pretend_args_size != 0 || flag_shrink_wrap_separate
>> +  || crtl->args.pretend_args_size != 0
>> +  || (use_shrink_wrapping_separate ()
>> + && !riscv_avoid_shrink_wrapping_separate ())
>
>I think we should also check "!optimize_function_for_size_p (cfun)"
>here, otherwise that does not really match what we claim in the commit
>message.
> 
A similar check optimize_function_for_speed_p is included in 
use_shrink_wrapping_separate of [1/2] allow targets to check
shrink-wrap-separate enabled or not.

>e.g. it still will enable with -O2 -fno-shrink-wrap-separate 
It's intentional to enable zcmp with -O2 -fno-shrink-wrap-separate. 
Maybe I should have given a better commit message saying
"enable muti push and pop for Zcmp extension when
shrink-wrap-separate is inactive".

Would you like a new patch from me or agree with my
explanation and modify commit message in your side?

BR
Fei
>
>>    || (frame->mask & ~MULTI_PUSH_GPR_MASK))
>>  return true;
>> 

Re: [PATCH v2] RISC-V: Fix Zicond ICE on large constants

[Jeff Law via Gcc-patches]

On 9/5/23 06:08, Tsukasa OI wrote:

From: Tsukasa OI 

Large constant cons and/or alt will trigger ICEs building GCC target
libraries (libgomp and libatomic) when the 'Zicond' extension is enabled.

For instance, zicond-ice-2.c (new test case in this commit) will cause
an ICE when SOME_NUMBER is 0x1000 or larger.  While opposite numbers
corresponding cons/alt (two temp2 variables) are checked, cons/alt
themselves are not checked and causing 2 ICEs building
GCC target libraries as of this writing:

1.  gcc/libatomic/config/posix/lock.c
2.  gcc/libgomp/fortran.c

Coercing a large value into a register will fix the issue.

It also coerce a large cons into a register on "imm, imm" case (the author
could not reproduce but possible to cause an ICE).

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_expand_conditional_move): Force
large constant cons/alt into a register.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/zicond-ice-2.c: New test.  This is based on
an ICE at libat_lock_n func on gcc/libatomic/config/posix/lock.c
but heavily minimized.

"New test." is sufficient.  No need to change it, just a note going forward.

OK.  Thanks for taking care of this.

jeff

Re: [PATCH v3 1/4] LoongArch: improved target configuration interface

[Yang Yujie]

On Tue, Sep 05, 2023 at 09:31:56PM +0800, Xi Ruoyao wrote:
> On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote:
> > * Support options for LoongArch SIMD extensions:
> >   new configure options --with-simd={none,lsx,lasx};
> >   new compiler option -msimd={none,lsx,lasx};
> >   new driver options -m[no]-l[a]sx.
> 
> Hmm... In my build (a cross compiler configured with ../gcc/configure --
> target=loongarch64-linux-gnu --with-system-zlib) I have:
> 
> $ cat lasx.c
> int x __attribute__((vector_size(32)));
> int y __attribute__((vector_size(32)));
> void test(void) { x += y; }
> $ gcc/cc1 lasx.c -msimd=lasx -o- -nostdinc -mexplicit-relocs -O2
> 
> ... ...
> 
>   pcalau12i   $r12,%pc_hi20(.LANCHOR0)
>   addi.d  $r12,$r12,%pc_lo12(.LANCHOR0)
>   xvld$xr0,$r12,0
>   xvld$xr1,$r12,32
>   xvadd.w $xr0,$xr0,$xr1
>   xvst$xr0,$r12,0
>   jr  $r1
> 
> ... ...
> 
> This seems perfectly fine.  But:
> 
> $ gcc/xgcc -B gcc lasx.c -mlasx -o- -nostdinc -mexplicit-relocs -O2 -S
> 
> ... ...
> 
> test:
> .LFB0 = .
>   pcalau12i   $r12,%pc_hi20(.LANCHOR0)
>   addi.d  $r12,$r12,%pc_lo12(.LANCHOR0)
>   addi.d  $r3,$r3,-16
> .LCFI0 = .
>   st.d$r23,$r3,8
> .LCFI1 = .
>   ldptr.w $r7,$r12,0
>   ldptr.w $r23,$r12,32
>   ldptr.w $r6,$r12,8
> 
> ... ... (no SIMD instructions)
> 
> Is this a bug in the driver or I missed something?
> 
> -- 
> Xi Ruoyao 
> School of Aerospace Science and Technology, Xidian University

Maybe you can try deleting gcc/specs first.

It contains a modified version of self_specs that is used for building
the libraries, which purges all user-specified "-m" options.
This file is automatically restored prior to "make check*".

Yujie

Re: [PATCH] RISC-V: Add conditional sqrt autovec pattern

[Jeff Law via Gcc-patches]

On 9/3/23 22:49, Lehua Ding wrote:

This patch adds a combined pattern for combining vfsqrt.v and vcond_mask.

gcc/ChangeLog:

* config/riscv/autovec-opt.md (*cond_):
Add sqrt + vcond_mask combine pattern.
* config/riscv/autovec.md (2):
Change define_expand to define_insn_and_split.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_sqrt_run-1.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_sqrt_run-2.c: New test.

OK.  Thanks.

FWIW, I thought we only had the reciprocal sqrt estimator, but in fact 
rvv does define a real vector sqrt.   So the concerns we kicked around 
in the meeting this morning turned out not be warranted.


This raises one of the very interesting questions in this space, 
specifically whether or not we should be using the rsqrt estimator with 
correction steps.   Unless the vfsqrt latency is really bad, it's going 
to be hard to make a vfrsqrt7 based sequence faster -- but the vfrsqrt7 
sequences will be pipelinable while vfsqrt almost certainly isn't.


Sadly we don't have a scalar FP rsqrt estimator.  Though I certainly 
ponder using the vector one -- there's a neat trick you can do with the 
nab benchmark from spec and produce sqrt and rsqrt at the same time with 
a Goldschmidt sequence.  It requires a bit of hackery to make new tree 
nodes, but it was definitely worth it on other targets I've worked on.



Jeff

Re: [PATCH v3 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

[Jeff Law via Gcc-patches]

On 9/5/23 06:10, Tsukasa OI wrote:

From: Tsukasa OI 

'XVentanaCondOps' is a vendor extension from Ventana Micro Systems
containing two instructions for conditional move and will be supported on
their Veyron V1 CPU.

And most notably (for historical reasons), 'XVentanaCondOps' and the
standard 'Zicond' extension are functionally equivalent (only encodings and
instruction names are different).

*   czero.eqz == vt.maskc
*   czero.nez == vt.maskcn

This commit adds support for the 'XVentanaCondOps' extension by extending
'Zicond' extension support.  With this, we can now reuse the optimization
using the 'Zicond' extension for the 'XVentanaCondOps' extension.

The specification for the 'XVentanaCondOps' extension is based on:


gcc/ChangeLog:

* common/config/riscv/riscv-common.cc (riscv_ext_flag_table):
Parse 'XVentanaCondOps' extension.
* config/riscv/riscv-opts.h (MASK_XVENTANACONDOPS): New.
(TARGET_XVENTANACONDOPS): Ditto.
(TARGET_ZICOND_LIKE): New to represent targets with conditional
moves like 'Zicond'.  It includes RV64 + 'XVentanaCondOps'.
* config/riscv/riscv.cc (riscv_rtx_costs): Replace TARGET_ZICOND
with TARGET_ZICOND_LIKE.
(riscv_expand_conditional_move): Ditto.
* config/riscv/riscv.md (movcc): Replace TARGET_ZICOND with
TARGET_ZICOND_LIKE.
* config/riscv/riscv.opt: Add new riscv_xventana_subext.
* config/riscv/zicond.md: Modify description.
(eqz_ventana): New to match corresponding czero instructions.
(nez_ventana): Ditto.
(*czero..): Emit a 'XVentanaCondOps' instruction if
'Zicond' is not available but 'XVentanaCondOps' + RV64 is.
(*czero..): Ditto.
(*czero.eqz..opt1): Ditto.
(*czero.nez..opt2): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/xventanacondops-primitiveSemantics.c: New test,
modified from zicond-primitiveSemantics.c.
* gcc.target/riscv/xventanacondops-primitiveSemantics-rv32.c: New
test to make sure that XVentanaCondOps instructions are disabled
on RV32.
* gcc.target/riscv/xventanacondops-xor-01.c: New test, modified
from zicond-xor-01.c.
---
  gcc/common/config/riscv/riscv-common.cc   |  2 +

  \

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 8d8f7b4f16ed..eb10f4a3323f 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -2745,7 +2745,7 @@ riscv_rtx_costs (rtx x, machine_mode mode, int 
outer_code, int opno ATTRIBUTE_UN
  *total = COSTS_N_INSNS (1);
  return true;
}
-  else if (TARGET_ZICOND
+  else if (TARGET_ZICOND_LIKE

Internally we have this as:

(TARGET_ZICOND || TARGET_XVENTANACONDOPS)

I don't really care, so I'm happy to go with yours.



+(define_code_attr eqz_ventana [(eq "maskcn") (ne "maskc")])
+(define_code_attr nez_ventana [(eq "maskc") (ne "maskcn")])

We did these as N/n which output n or nothing:

(define_code_attr n [(eq "n") (ne "")])
(define_code_attr N [(eq "") (ne "n")])


  
  ;; Zicond

  (define_insn "*czero.."
@@ -28,8 +31,15 @@
  (const_int 0))
(match_operand:GPR 2 "register_operand""r")
(const_int 0)))]
-  "TARGET_ZICOND"
-  "czero.\t%0,%2,%1"
+  "TARGET_ZICOND_LIKE"
+  {
+if (TARGET_ZICOND)
+  return "czero.\t%0,%2,%1";
+else if (TARGET_XVENTANACONDOPS && TARGET_64BIT)
+  return "vt.\t%0,%2,%1";
+else
+  gcc_unreachable ();
+  }
  )

And so the output template ends up like this:


  "* return TARGET_ZICOND ? \"czero.\t%0,%2,%1\" : \"vt.maskc\t%0,%2,%1\"; 
"


But again, I don't care enough about this to make it a big deal and I'm 
happy to go with your approach.





diff --git 
a/gcc/testsuite/gcc.target/riscv/xventanacondops-primitiveSemantics-rv32.c 
b/gcc/testsuite/gcc.target/riscv/xventanacondops-primitiveSemantics-rv32.c
new file mode 100644
index ..992f1425c54f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/xventanacondops-primitiveSemantics-rv32.c
So we're never going to have an rv32 variant.  So I don't think we need 
rv32 xventanacondops tests.


For the tests we keep, the right way to do them is with #includes.

ie start with this:




+/* { dg-do compile } */
+/* { dg-options "-march=rv64gc_xventanacondops -mabi=lp64d" } */
+/* { dg-skip-if "" { *-*-* } {"-O0" "-Og"} } */


Then #include the zicond variant of the test



+
+/* { dg-final { scan-assembler-times "vt\\.maskc\t" 6 } } */
+/* { dg-final { scan-assembler-times "vt\\.maskcn\t" 6 } } */
+/* { dg-final { scan-assembler-not "beq" } } */
+/* { dg-final { scan-assembler-not "bne" } } */

Then you have the assembly scan strings.

That way we don't duplicate the actual test code.

If you could fixup the tests, then I think 

Re: [PATCH] xtensa: Optimize boolean evaluation when SImode EQ/NE to zero if TARGET_MINMAX

[Max Filippov via Gcc-patches]

Hi Suwa-san,

On Tue, Sep 5, 2023 at 2:29 AM Takayuki 'January June' Suwa
 wrote:
>
> This patch optimizes the boolean evaluation for equality to 0 in SImode
> using the MINU (Minimum Value Unsigned) machine instruction available
> when TARGET_MINMAX is configured, for example, (x != 0) to MINU(x, 1)
> and (x == 0) to (MINU(x, 1) ^ 1).
>
> /* example */
> int test0(int x) {
>   return x == 0;
> }
> int test1(int x) {
>   return x != 0;
> }
>
> ;; before
> test0:
> mov.n   a10, a2
> movi.n  a9, 1
> movi.n  a2, 0
> moveqz  a2, a9, a10
> ret.n
> test1:
> mov.n   a10, a2
> movi.n  a9, 1
> movi.n  a2, 0
> movnez  a2, a9, a10
> ret.n
>
> ;; after (prereq. TARGET_MINMAX)
> test0:
> movi.n  a9, 1
> minua2, a2, a9
> xor a2, a2, a9
> ret.n

ISTM that test0 could be done with movnez in the same three instructions:

  movi a9, 1
  movnez a2, a9, a2
  xor a2, a2, a9

> test1:
> movi.n  a9, 1
> minua2, a2, a9
> ret.n

ISTM that test1 could be done with movnez in the same two instructions:

  movi a9, 1
  movnez a2, a9, a2

-- 
Thanks.
-- Max

Re: [PATCH] c: Don't pedwarn on _FloatN{,x} or {f,F}N{,x} suffixes for C2X

[Joseph Myers]

On Tue, 5 Sep 2023, Jakub Jelinek via Gcc-patches wrote:

> Hi!
> 
> Now that _Float{16,32,64,128,32x,64x,128x} and
> {f,F}{16,32,64,128,32x,64x,128x} literal suffixes are in C23 standard,
> I think it is undesirable to pedwarn about these for -std=c2x, so this
> patch uses pedwarn_c11 instead.  In c-family/, we don't have that function
> and am not sure it would be very clean to define dummy pedwarn_c11 in the
> C++ FE, so the patch just does what pedwarn_c11 does using pedwarn/warning.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH 13/12 v2] C _BitInt incremental fixes [PR102989]

[Joseph Myers]

On Thu, 10 Aug 2023, Jakub Jelinek via Gcc-patches wrote:

> On Thu, Aug 10, 2023 at 12:10:07PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > Here is an incremental patch which does that:
> 
> Bootstrap/regtest on i686-linux (next to x86_64-linux where it went fine)
> revealed I forgot to add { target bitint } to dg-do compile lines.
> 
> Here is an updated patch which does that and passes even on i686-linux.

This incremental patch is OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH 10/12] C _BitInt support [PR102989]

[Joseph Myers]

On Wed, 9 Aug 2023, Jakub Jelinek via Gcc-patches wrote:

> Hi!
> 
> This patch adds the C FE support, c-family support, small libcpp change
> so that 123wb and 42uwb suffixes are handled plus glimits.h change
> to define BITINT_MAXWIDTH macro.
> 
> The previous patches really do nothing without this, which enables
> all the support.

Additional tests I think should be added (for things I expect should 
already work):

* Tests for BITINT_MAXWIDTH in .  Test that it's defined for 
C2x, but not defined for C11/C17 (the latter independent of whether the 
target has _BitInt support).  Test the value as well: _BitInt 
(BITINT_MAXWIDTH) should be OK (both signed and unsigned) but _BitInt 
(BITINT_MAXWIDTH + 1) should not be OK.  Also test that BITINT_MAXWIDTH >= 
ULLONG_MAX.

* Test _BitInt (N) where N is a constexpr variable or enum constant (I 
expect these should work - the required call to convert_lvalue_to_rvalue 
for constexpr to work is present - but I don't see such tests in the 
testsuite).

* Test that -funsigned-bitfields does not affect the signedness of _BitInt 
(N) bit-fields (the standard wording isn't entirely clear, but that's 
what's implemented in the patches).

* Test the errors for _Sat used with _BitInt (though such a test might not 
actually run at present because no target supports both features).

I looked at places in c-family/ and c/ that refer to INTEGER_TYPE to 
consider whether they should handle BITINT_TYPE and whether that matches 
what the patch does there.  I think the following places that don't handle 
it probably should (with appropriate testcases added for the relevant 
functionality, e.g. warnings) unless there is some specific reason in each 
case why that's unnecessary or incorrect.  c-pretty-print.cc: 
c_pretty_printer::direct_declarator and c_pretty_printer::declarator.  
c-warn.cc throughout.  Maybe c-ada-spec.cc, though it might be best to ask 
the Ada maintainers there.  c-common.cc: unsafe_conversion_p, 
c_common_truthvalue_conversion warnings, c_common_get_alias_set, 
check_builtin_function_arguments BUILT_IN_ASSUME_ALIGNED case.  
c-aux-info.cc (might need other support for generating appropriate names 
in output).  c-parser.cc:c_parser_omp_clause_schedule.  c-fold.cc 
throughout.  c-typeck.c: the build_conditional_expr case where one operand 
is EXCESS_PRECISION_EXPR; build_c_cast; convert_for_assignment checks for 
integer/pointer conversions.

In the parser, the syntax comment on c_parser_declspecs should have 
_BitInt syntax added.

> +   error_at (loc, "%<_BitInt%> argument %qE is not "
> +  "positive integer constant expression",

"is not positive" should be "is not a positive" here.

> --- gcc/c/c-typeck.cc.jj  2023-08-08 15:54:33.822622158 +0200
> +++ gcc/c/c-typeck.cc 2023-08-08 16:15:41.008877766 +0200
> @@ -413,10 +413,14 @@ composite_type (tree t1, tree t2)
>   the composite type.  */
>  
>if (code1 == ENUMERAL_TYPE
> -  && (code2 == INTEGER_TYPE || code2 == BOOLEAN_TYPE))
> +  && (code2 == INTEGER_TYPE
> +   || code2 == BOOLEAN_TYPE
> +   || code2 == BITINT_TYPE))
>  return t1;
>if (code2 == ENUMERAL_TYPE
> -  && (code1 == INTEGER_TYPE || code1 == BOOLEAN_TYPE))
> +  && (code1 == INTEGER_TYPE
> +   || code1 == BOOLEAN_TYPE
> +   || code1 == BITINT_TYPE))
>  return t2;

I think these changes to handle BITINT_TYPE are unnecessary (don't do 
anything), since enumerated types can't have bit-precise underlying type 
(this code is about making a predictable choice of the enumerated type as 
the composite of an enumerated type and its underlying integer type).

OK with those fixes.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH 17/12] _BitInt a ? ~b : b match.pd fix [PR102989]

[Andrew Pinski via Gcc-patches]

On Tue, Sep 5, 2023 at 2:51 PM Jakub Jelinek  wrote:
>
> On Tue, Sep 05, 2023 at 02:27:10PM -0700, Andrew Pinski wrote:
> > > I admit it isn't really clear to me what do you want to achieve by the
> > > above build_nonstandard_integer_type.  Is it because of BOOLEAN_TYPE
> > > or perhaps ENUMERAL_TYPE as well?
> >
> > Yes I was worried about types where the precision was set but MIN/MAX
> > of that type was not over the full precision and would not include
> > both 0 and allones in that range.
> > There is another match.pd pattern where we do a similar thing with
> > calling build_nonstandard_integer_type for a similar reason but
> > because we don't know if the type includes 0, 1, and allones in their
> > range.
>
> Ah, in that case you should use range_check_type, that is used already
> in multiple spots in match.pd for the same purpose.  It can return NULL and
> in that case one should punt on the optimization.  Otherwise, that is the
> function which ensures that the type is unsigned and max + 1 is min and min
> - 1 is max.
> And for me, I should add BITINT_TYPE handling to that function.

Hmm maybe range_check_type is the correct one here.


>
> > > If type is INTEGER_TYPE or BITINT_TYPE, one doesn't really need to create 
> > > a
> > > new type, type already is an integral type with that precision and
> > > signedness.  In other places using unsigned_type_for or signed_type_for
> > > might be better than using build_nonstandard_integer_type if that is what
> > > one wants to achieve, those functions handle BITINT_TYPE.
> >
> > Maybe here we should just use `signed_or_unsigned_type_for (type,
> > TYPE_SIGN (type));`
> > instead of build_nonstandard_integer_type.
>
> No, signed_or_unsigned_type_for (TYPE_UNSIGNED (type), type) will just return
> type.
>   if (ANY_INTEGRAL_TYPE_P (type) && TYPE_UNSIGNED (type) == unsignedp)
> return type;

Oh I missed that.

Note I notice another all to build_nonstandard_integer_type in this
match pattern which might also need to be fixed:
/* For (x << c) >> c, optimize into x & ((unsigned)-1 >> c) for
   unsigned x OR truncate into the precision(type) - c lowest bits
   of signed x (if they have mode precision or a precision of 1).  */
(simplify
 (rshift (nop_convert? (lshift @0 INTEGER_CST@1)) @@1)
 (if (wi::ltu_p (wi::to_wide (@1), element_precision (type)))
  (if (TYPE_UNSIGNED (type))
   (bit_and (convert @0) (rshift { build_minus_one_cst (type); } @1))
   (if (INTEGRAL_TYPE_P (type))
(with {
  int width = element_precision (type) - tree_to_uhwi (@1);
  tree stype = build_nonstandard_integer_type (width, 0);
 }
 (if (width == 1 || type_has_mode_precision_p (stype))
  (convert (convert:stype @0

Do we have ranges on BITINT_TYPEs? If so the two_value_replacement
pattern in match.pd has a similar issue too.
(that is where I copied the code to use build_nonstandard_integer_type
from originally too.

Thanks,
Andrew


>
> Jakub
>

Re: [PATCH] riscv: Synthesize all 11-bit-rotate constants with rori

[Philipp Tomsich]

Applied to master. Thanks!
Philipp.

On Tue, 5 Sept 2023 at 23:57, Jeff Law  wrote:

>
>
> On 9/5/23 15:15, Christoph Muellner wrote:
> > From: Christoph Müllner 
> >
> > Some constants can be built up using LI+RORI instructions.
> > The current implementation requires one of the upper 32-bits
> > to be a zero bit, which is not neccesary.
> > Let's drop this requirement in order to be able to synthesize
> > a constant like 0x00ffL.
> >
> > The tests for LI+RORI are made more strict to detect regression
> > in the calculation of the LI constant and the rotation amount.
> >
> > Signed-off-by: Christoph Müllner 
> >
> > gcc/ChangeLog:
> >
> >   * config/riscv/riscv.cc (riscv_build_integer_1): Don't
> >   require one zero bit in the upper 32 bits for LI+RORI synthesis.
> >
> > gcc/testsuite/ChangeLog:
> >
> >   * gcc.target/riscv/xtheadbb-li-rotr.c: New tests.
> >   * gcc.target/riscv/zbb-li-rotr.c: Likewise.
> OK
> jeff
>

Re: [PATCH] riscv: Synthesize all 11-bit-rotate constants with rori

[Jeff Law via Gcc-patches]

On 9/5/23 15:15, Christoph Muellner wrote:

From: Christoph Müllner 

Some constants can be built up using LI+RORI instructions.
The current implementation requires one of the upper 32-bits
to be a zero bit, which is not neccesary.
Let's drop this requirement in order to be able to synthesize
a constant like 0x00ffL.

The tests for LI+RORI are made more strict to detect regression
in the calculation of the LI constant and the rotation amount.

Signed-off-by: Christoph Müllner 

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_build_integer_1): Don't
require one zero bit in the upper 32 bits for LI+RORI synthesis.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/xtheadbb-li-rotr.c: New tests.
* gcc.target/riscv/zbb-li-rotr.c: Likewise.

OK
jeff

Re: [PATCH V2] RISC-V: Support Dynamic LMUL Cost model

[Jeff Law via Gcc-patches]

On 9/5/23 15:39, 钟居哲 wrote:

- Why don't we use the normal reverse postorder (or postorder) approach of
    computing live ranges?  Is that because we don't really need full global
    live ranges?

Yes. We don't need global live ranges.

- Why can't we use existing code i.e. tree-ssa-live?  I suspect I already
    know the answer but an explanation (in a comment) would still be useful.

The existing code can't help I have tried many times.
I would expect it to be fairly hard to use for this purpose.  I've tried 
to use it in other contexts as well without success.


Jeff

Re: [PATCH 18/12] Handle BITINT_TYPE in build_{, minus_}one_cst [PR102989]

[Jakub Jelinek via Gcc-patches]

On Tue, Sep 05, 2023 at 02:42:39PM -0700, Andrew Pinski wrote:
> On Tue, Sep 5, 2023 at 12:31 AM Jakub Jelinek via Gcc-patches
> > Recent match.pd changes trigger ICE in build_minus_one_cst, apparently
> > I forgot to handle BITINT_TYPE in these (while I've handled it in
> > build_zero_cst).
> >
> > Will commit as obvious together with the rest of the series when the last
> > patches are approved.
> 
> I assume there was a testcase that will be added when _BitInt
> front-end support gets added.

After working around the build_nonstandard_integer_type in match.pd (in that
case the single one, I know there are some others) the ICE was on
dg-torture/bitint-42.c at -O1/-Os, so no new testcase needs to be added.

Jakub

Re: [PATCH 17/12] _BitInt a ? ~b : b match.pd fix [PR102989]

[Jakub Jelinek via Gcc-patches]

On Tue, Sep 05, 2023 at 02:27:10PM -0700, Andrew Pinski wrote:
> > I admit it isn't really clear to me what do you want to achieve by the
> > above build_nonstandard_integer_type.  Is it because of BOOLEAN_TYPE
> > or perhaps ENUMERAL_TYPE as well?
> 
> Yes I was worried about types where the precision was set but MIN/MAX
> of that type was not over the full precision and would not include
> both 0 and allones in that range.
> There is another match.pd pattern where we do a similar thing with
> calling build_nonstandard_integer_type for a similar reason but
> because we don't know if the type includes 0, 1, and allones in their
> range.

Ah, in that case you should use range_check_type, that is used already
in multiple spots in match.pd for the same purpose.  It can return NULL and
in that case one should punt on the optimization.  Otherwise, that is the
function which ensures that the type is unsigned and max + 1 is min and min
- 1 is max.
And for me, I should add BITINT_TYPE handling to that function.

> > If type is INTEGER_TYPE or BITINT_TYPE, one doesn't really need to create a
> > new type, type already is an integral type with that precision and
> > signedness.  In other places using unsigned_type_for or signed_type_for
> > might be better than using build_nonstandard_integer_type if that is what
> > one wants to achieve, those functions handle BITINT_TYPE.
> 
> Maybe here we should just use `signed_or_unsigned_type_for (type,
> TYPE_SIGN (type));`
> instead of build_nonstandard_integer_type.

No, signed_or_unsigned_type_for (TYPE_UNSIGNED (type), type) will just return
type.
  if (ANY_INTEGRAL_TYPE_P (type) && TYPE_UNSIGNED (type) == unsignedp)
return type;

Jakub

Re: [PATCH 18/12] Handle BITINT_TYPE in build_{, minus_}one_cst [PR102989]

[Andrew Pinski via Gcc-patches]

On Tue, Sep 5, 2023 at 12:31 AM Jakub Jelinek via Gcc-patches
 wrote:
>
> Hi!
>
> Recent match.pd changes trigger ICE in build_minus_one_cst, apparently
> I forgot to handle BITINT_TYPE in these (while I've handled it in
> build_zero_cst).
>
> Will commit as obvious together with the rest of the series when the last
> patches are approved.

I assume there was a testcase that will be added when _BitInt
front-end support gets added.

Thanks,
Andrew

>
> 2023-09-05  Jakub Jelinek  
>
> PR c/102989
> * tree.cc (build_one_cst, build_minus_one_cst): Handle BITINT_TYPE
> like INTEGER_TYPE.
>
> --- gcc/tree.cc.jj  2023-09-04 09:45:33.444059843 +0200
> +++ gcc/tree.cc 2023-09-05 08:57:31.420059962 +0200
> @@ -2546,7 +2546,7 @@ build_one_cst (tree type)
>  {
>  case INTEGER_TYPE: case ENUMERAL_TYPE: case BOOLEAN_TYPE:
>  case POINTER_TYPE: case REFERENCE_TYPE:
> -case OFFSET_TYPE:
> +case OFFSET_TYPE: case BITINT_TYPE:
>return build_int_cst (type, 1);
>
>  case REAL_TYPE:
> @@ -2599,7 +2599,7 @@ build_minus_one_cst (tree type)
>  {
>  case INTEGER_TYPE: case ENUMERAL_TYPE: case BOOLEAN_TYPE:
>  case POINTER_TYPE: case REFERENCE_TYPE:
> -case OFFSET_TYPE:
> +case OFFSET_TYPE: case BITINT_TYPE:
>return build_int_cst (type, -1);
>
>  case REAL_TYPE:
>
> Jakub
>

[committed] RISC-V: Expose bswapsi for TARGET_64BIT

[Jeff Law via Gcc-patches]

Various bswapsi tests are failing for rv64.  More importantly, we're 
generating crappy code.


Let's take the first test from bswapsi-1.c as an example.


typedef unsigned int uint32_t;

#define __const_swab32(x) ((uint32_t)(\
(((uint32_t)(x) & (uint32_t)0x00ffUL) << 24) |\
(((uint32_t)(x) & (uint32_t)0xff00UL) <<  8) |\
(((uint32_t)(x) & (uint32_t)0x00ffUL) >>  8) |\
(((uint32_t)(x) & (uint32_t)0xff00UL) >> 24)))

/* This byte swap implementation is used by the Linux kernel and the
   GNU C library.  */

uint32_t
swap32_a (uint32_t in)
{
  return __const_swab32 (in);
}






We generate this for rv64gc_zba_zbb_zbs:


srliw   a1,a0,24
slliw   a5,a0,24
slliw   a3,a0,8
li  a2,16711680
li  a4,65536
or  a5,a5,a1
and a3,a3,a2
addia4,a4,-256
srliw   a0,a0,8
or  a5,a5,a3
and a0,a0,a4
or  a0,a5,a0
ret

Urgh!

After this patch we generate:


rev8a0,a0
sraia0,a0,32
ret


Clearly better.


The stated rationale behind not exposing bswapsi2 for TARGET_64BIT is 
that the RTL expanders already know how to widen a bswap, which is 
definitely true.  But it's the case that failure to expose a bswapsi 
will cause the 32bit bswap optimizations in gimple store merging to not 
trigger.  Thus we get crappy code.


To fix this we expose bswapsi on TARGET_64BIT.  gimple-store-merging 
then detects the 32bit bswap idioms and generates suitable __builtin 
calls.  The expander will "FAIL" expansion for TARGET_64BIT which forces 
the generic expander code to synthesize the operation (we could 
synthesize in here, but that'd result in duplicate code).


Tested on rv64gc_zba_zbb_zbs, fixes all the bswapsi failures in the 
testsuite without any regressions.


Pushed to the trunk,

Jeff


commit fbc01748ba46eb26074388a8fb7b44d25a414a72
Author: Jeff Law 
Date:   Tue Sep 5 15:39:16 2023 -0600

RISC-V: Expose bswapsi for TARGET_64BIT

Various bswapsi tests are failing for rv64.  More importantly, we're 
generating
crappy code.

Let's take the first test from bswapsi-1.c as an example.

> typedef unsigned int uint32_t;
>
> #define __const_swab32(x) ((uint32_t)(\
> (((uint32_t)(x) & (uint32_t)0x00ffUL) << 24) |\
> (((uint32_t)(x) & (uint32_t)0xff00UL) <<  8) |\
> (((uint32_t)(x) & (uint32_t)0x00ffUL) >>  8) |\
> (((uint32_t)(x) & (uint32_t)0xff00UL) >> 24)))
>
> /* This byte swap implementation is used by the Linux kernel and the
>GNU C library.  */
>
> uint32_t
> swap32_a (uint32_t in)
> {
>   return __const_swab32 (in);
> }
>
>
>

We generate this for rv64gc_zba_zbb_zbs:

> srliw   a1,a0,24
> slliw   a5,a0,24
> slliw   a3,a0,8
> li  a2,16711680
> li  a4,65536
> or  a5,a5,a1
> and a3,a3,a2
> addia4,a4,-256
> srliw   a0,a0,8
> or  a5,a5,a3
> and a0,a0,a4
> or  a0,a5,a0
> retUrgh!

After this patch we generate:

> rev8a0,a0
> sraia0,a0,32
> ret
Clearly better.

The stated rationale behind not exposing bswapsi2 for TARGET_64BIT is that 
the
RTL expanders already know how to widen a bswap, which is definitely true.  
But
it's the case that failure to expose a bswapsi will cause the 32bit bswap
optimizations in gimple store merging to not trigger.  Thus we get crappy 
code.

To fix this we expose bswapsi on TARGET_64BIT.  gimple-store-merging then
detects the 32bit bswap idioms and generates suitable __builtin calls.  The
expander will "FAIL" expansion for TARGET_64BIT which forces the generic
expander code to synthesize the operation (we could synthesize in here, but
that'd result in duplicate code).

Tested on rv64gc_zba_zbb_zbs, fixes all the bswapsi failures in the 
testsuite
without any regressions.

gcc/
* config/riscv/bitmanip.md (bswapsi2): Expose for TARGET_64BIT.

diff --git a/gcc/config/riscv/bitmanip.md b/gcc/config/riscv/bitmanip.md
index 7b55528ee49..1544ef4e125 100644
--- a/gcc/config/riscv/bitmanip.md
+++ b/gcc/config/riscv/bitmanip.md
@@ -454,7 +454,16 @@ (define_expand "bswapdi2"
 (define_expand "bswapsi2"
   [(set (match_operand:SI 0 "register_operand")
(bswap:SI (match_operand:SI 1 "register_operand")))]
-  "(!TARGET_64BIT && (TARGET_ZBB || TARGET_ZBKB)) || TARGET_XTHEADBB")
+  "TARGET_ZBB || TARGET_ZBKB || TARGET_XTHEADBB"
+{
+  /* Expose bswapsi2 on TARGET_64BIT so that the gimple store
+ 

Re: Re: [PATCH V2] RISC-V: Support Dynamic LMUL Cost model

[钟居哲]

- Why don't we use the normal reverse postorder (or postorder) approach of
   computing live ranges?  Is that because we don't really need full global
   live ranges?

Yes. We don't need global live ranges.

- Why can't we use existing code i.e. tree-ssa-live?  I suspect I already
   know the answer but an explanation (in a comment) would still be useful.

The existing code can't help I have tried many times.

- Do we really need get_all_predecessors/get_all_successors?  As they're
   only used for "defined before" and "used after", at first glance it
   looks like some kind of dominance info could help there but I didn't
   really check in detail.

Yes. At the first time, I want to use dominance analysis but I am not sure 
whether
we can use df_analyze () in COST model framwork. It worth trying.

- Why don't we use bitmaps/sbitmaps like in vsetvl.cc and other related
   passes?  I don't mind maps but just wonder if it's on purpose, for
   convenience or something else.

I don't know how to use bitmap to substitue the current approach of using map.

Besides, it might help to rename program_points_map (into program_points_per_bb
or so).  At first it looked quadratic to me but we're just iterating over
the program points of a BB.

Ok.


juzhe.zh...@rivai.ai
 
From: Robin Dapp
Date: 2023-09-06 05:02
To: Juzhe-Zhong; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; jeffreyalaw
Subject: Re: [PATCH V2] RISC-V: Support Dynamic LMUL Cost model
Hi Juzhe,
 
I think the general approach makes sense and it doesn't need to be perfect
from the beginning as we can always iterate on it.  Before continuing with a
more detailed review (hopefully tomorrow) some high-level questions upfront.
It would help to document some of these choices so it's easier to understand
the rationale.
 
- Why don't we use the normal reverse postorder (or postorder) approach of
   computing live ranges?  Is that because we don't really need full global
   live ranges?
 
- Why can't we use existing code i.e. tree-ssa-live?  I suspect I already
   know the answer but an explanation (in a comment) would still be useful.
 
- Do we really need get_all_predecessors/get_all_successors?  As they're
   only used for "defined before" and "used after", at first glance it
   looks like some kind of dominance info could help there but I didn't
   really check in detail.
 
- Why don't we use bitmaps/sbitmaps like in vsetvl.cc and other related
   passes?  I don't mind maps but just wonder if it's on purpose, for
   convenience or something else. 
 
Besides, it might help to rename program_points_map (into program_points_per_bb
or so).  At first it looked quadratic to me but we're just iterating over
the program points of a BB.
 
Regards
Robin
 
 

Re: [PATCH 17/12] _BitInt a ? ~b : b match.pd fix [PR102989]

[Andrew Pinski via Gcc-patches]

On Tue, Sep 5, 2023 at 12:28 AM Jakub Jelinek via Gcc-patches
 wrote:
>
> On Wed, Aug 09, 2023 at 12:19:54PM -0700, Andrew Pinski via Gcc-patches wrote:
> >   PR tree-optimization/110937
> >   PR tree-optimization/100798
> > --- a/gcc/match.pd
> > +++ b/gcc/match.pd
> > @@ -6460,6 +6460,20 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >(if (cmp == NE_EXPR)
> > { constant_boolean_node (true, type); })))
> >
> > +#if GIMPLE
> > +/* a?~t:t -> (-(a))^t */
> > +(simplify
> > + (cond @0 @1 @2)
> > + (if (INTEGRAL_TYPE_P (type)
> > +  && bitwise_inverted_equal_p (@1, @2))
> > +  (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))
> > +#endif
>
> This broke one bitint test - bitint-42.c for -O1 and -Os (in admittedly not 
> yet
> committed series).
> Using build_nonstandard_integer_type this way doesn't work well for larger
> precision BITINT_TYPEs, because it always creates an INTEGER_TYPE and
> say 467-bit INTEGER_TYPE doesn't work very well.  To get a BITINT_TYPE, one
> needs to use build_bitint_type instead (but similarly to
> build_nonstandard_integer_type one should first make sure such a type
> actually can be created).
>
> I admit it isn't really clear to me what do you want to achieve by the
> above build_nonstandard_integer_type.  Is it because of BOOLEAN_TYPE
> or perhaps ENUMERAL_TYPE as well?

Yes I was worried about types where the precision was set but MIN/MAX
of that type was not over the full precision and would not include
both 0 and allones in that range.
There is another match.pd pattern where we do a similar thing with
calling build_nonstandard_integer_type for a similar reason but
because we don't know if the type includes 0, 1, and allones in their
range.

>
> If type is INTEGER_TYPE or BITINT_TYPE, one doesn't really need to create a
> new type, type already is an integral type with that precision and
> signedness.  In other places using unsigned_type_for or signed_type_for
> might be better than using build_nonstandard_integer_type if that is what
> one wants to achieve, those functions handle BITINT_TYPE.

Maybe here we should just use `signed_or_unsigned_type_for (type,
TYPE_SIGN (type));`
instead of build_nonstandard_integer_type.

Thanks,
Andrew

>
> Or shall we instead test for == BOOLEAN_TYPE (or if ENUMERAL_TYPE for
> some reason needs the same treatment also || == ENUMERAL_TYPE)?
>
> 2023-09-05  Jakub Jelinek  
>
> PR c/102989
> * match.pd (a ? ~b : b): Don't use build_nonstandard_integer_type
> for INTEGER_TYPE or BITINT_TYPE.
>
> --- gcc/match.pd.jj 2023-09-04 09:45:33.553058301 +0200
> +++ gcc/match.pd2023-09-05 08:45:53.258078971 +0200
> @@ -6631,7 +6631,9 @@ (define_operator_list SYNC_FETCH_AND_AND
> (with {
>   auto prec = TYPE_PRECISION (type);
>   auto unsign = TYPE_UNSIGNED (type);
> - tree inttype = build_nonstandard_integer_type (prec, unsign);
> + tree inttype = type;
> + if (TREE_CODE (type) != INTEGER_TYPE && TREE_CODE (type) != BITINT_TYPE)
> +   inttype = build_nonstandard_integer_type (prec, unsign);
>  }
>  (convert (bit_xor (negate (convert:inttype @0)) (convert:inttype 
> @2)))
>  #endif
>
>
> Jakub
>

[PATCH] riscv: Synthesize all 11-bit-rotate constants with rori

[Christoph Muellner]

From: Christoph Müllner 

Some constants can be built up using LI+RORI instructions.
The current implementation requires one of the upper 32-bits
to be a zero bit, which is not neccesary.
Let's drop this requirement in order to be able to synthesize
a constant like 0x00ffL.

The tests for LI+RORI are made more strict to detect regression
in the calculation of the LI constant and the rotation amount.

Signed-off-by: Christoph Müllner 

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_build_integer_1): Don't
require one zero bit in the upper 32 bits for LI+RORI synthesis.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/xtheadbb-li-rotr.c: New tests.
* gcc.target/riscv/zbb-li-rotr.c: Likewise.
---
 gcc/config/riscv/riscv.cc |  7 +-
 .../gcc.target/riscv/xtheadbb-li-rotr.c   | 66 +--
 gcc/testsuite/gcc.target/riscv/zbb-li-rotr.c  | 57 +++-
 3 files changed, 118 insertions(+), 12 deletions(-)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index ef63079de8e..d8917d75087 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -572,10 +572,9 @@ riscv_build_integer_1 (struct riscv_integer_op 
codes[RISCV_MAX_INTEGER_OPS],
   int trailing_ones = ctz_hwi (~value);
 
   /* If all bits are one except a few that are zero, and the zero bits
-are within a range of 11 bits, and at least one of the upper 32-bits
-is a zero, then we can generate a constant by loading a small
-negative constant and rotating.  */
-  if (leading_ones < 32
+are within a range of 11 bits, then we can synthesize a constant
+by loading a small negative constant and rotating.  */
+  if (leading_ones < 64
  && ((64 - leading_ones - trailing_ones) < 12))
{
  codes[0].code = UNKNOWN;
diff --git a/gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c 
b/gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c
index ecd50448d77..136dcb01cf4 100644
--- a/gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c
+++ b/gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c
@@ -1,34 +1,88 @@
 /* { dg-do compile } */
 /* { dg-options "-march=rv64gc_xtheadbb" } */
+/* { dg-skip-if "" { *-*-* } {"-O0" "-Os" "-Og" "-Oz" "-flto" } } */
+/* { dg-final { check-function-bodies "**" "" } } */
 
+/*
+**li_th_srri_1:
+** li  a[0-9]+,-18
+** th.srri a[0-9]+,a[0-9]+,21
+** ret
+*/
 long
-li_rori (void)
+li_th_srri_1 (void)
 {
   return 0x77ffL;
 }
 
+/*
+**li_th_srri_2:
+** li  a[0-9]+,-18
+** th.srri a[0-9]+,a[0-9]+,5
+** ret
+*/
 long
-li_rori_2 (void)
+li_th_srri_2 (void)
 {
   return 0x77ffL;
 }
 
+/*
+**li_th_srri_3:
+** li  a[0-9]+,-18
+** th.srri a[0-9]+,a[0-9]+,36
+** ret
+*/
 long
-li_rori_3 (void)
+li_th_srri_3 (void)
 {
   return 0xfffeefffL;
 }
 
+/*
+**li_th_srri_4:
+** li  a[0-9]+,-86
+** th.srri a[0-9]+,a[0-9]+,3
+** ret
+*/
 long
-li_rori_4 (void)
+li_th_srri_4 (void)
 {
   return 0x5ff5L;
 }
 
+/*
+**li_th_srri_5:
+** li  a[0-9]+,-86
+** th.srri a[0-9]+,a[0-9]+,4
+** ret
+*/
 long
-li_rori_5 (void)
+li_th_srri_5 (void)
 {
   return 0xaffaL;
 }
 
-/* { dg-final { scan-assembler-times "th.srri\t" 5 } } */
+/*
+**li_th_srri_6:
+** li  a[0-9]+,-256
+** th.srri a[0-9]+,a[0-9]+,40
+** ret
+*/
+long
+li_th_srri_6 (void)
+{
+  return 0x00ffL;
+}
+
+/*
+**li_th_srri_7:
+** li  a[0-9]+,-2048
+** th.srri a[0-9]+,a[0-9]+,16
+** ret
+*/
+long
+li_th_srri_7 (void)
+{
+  return 0xf800L;
+}
diff --git a/gcc/testsuite/gcc.target/riscv/zbb-li-rotr.c 
b/gcc/testsuite/gcc.target/riscv/zbb-li-rotr.c
index 500264a49dd..594c3dcaa49 100644
--- a/gcc/testsuite/gcc.target/riscv/zbb-li-rotr.c
+++ b/gcc/testsuite/gcc.target/riscv/zbb-li-rotr.c
@@ -1,35 +1,88 @@
 /* { dg-do compile } */
 /* { dg-options "-march=rv64gc_zbb -mabi=lp64" } */
+/* { dg-skip-if "" { *-*-* } {"-O0" "-Os" "-Og" "-Oz" "-flto" } } */
+/* { dg-final { check-function-bodies "**" "" } } */
 
+/*
+**li_rori_1:
+** li  a[0-9]+,-18
+** roria[0-9]+,a[0-9]+,21
+** ret
+*/
 long
-li_rori (void)
+li_rori_1 (void)
 {
   return 0x77ffL;
 }
 
+/*
+**li_rori_2:
+** li  a[0-9]+,-18
+** roria[0-9]+,a[0-9]+,5
+** ret
+*/
 long
 li_rori_2 (void)
 {
   return 0x77ffL;
 }
 
+/*
+**li_rori_3:
+** li  a[0-9]+,-18
+** roria[0-9]+,a[0-9]+,36
+** ret
+*/
 long
 li_rori_3 (void)
 {
   return 0xfffeefffL;
 }
 
+/*
+**li_rori_4:
+** li  a[0-9]+,-86
+** roria[0-9]+,a[0-9]+,3
+** ret
+*/
 long
 li_rori_4 (void)
 {
   return 0x5ff5L;
 }
 
+/*
+**li_rori_5:
+** li  a[0-9]+,-86
+** roria[0-9]+,a[0-9]+,4
+** ret
+*/
 long
 li_rori_5 (void)
 {
   return 0xaffaL;
 }
 
+/*
+**li_rori_6:
+** li  a[0-9]+,-256
+**  

Re: [PATCH V2] RISC-V: Support Dynamic LMUL Cost model

[Robin Dapp via Gcc-patches]

Hi Juzhe,

I think the general approach makes sense and it doesn't need to be perfect
from the beginning as we can always iterate on it.  Before continuing with a
more detailed review (hopefully tomorrow) some high-level questions upfront.
It would help to document some of these choices so it's easier to understand
the rationale.

 - Why don't we use the normal reverse postorder (or postorder) approach of
   computing live ranges?  Is that because we don't really need full global
   live ranges?

 - Why can't we use existing code i.e. tree-ssa-live?  I suspect I already
   know the answer but an explanation (in a comment) would still be useful.

 - Do we really need get_all_predecessors/get_all_successors?  As they're
   only used for "defined before" and "used after", at first glance it
   looks like some kind of dominance info could help there but I didn't
   really check in detail.

 - Why don't we use bitmaps/sbitmaps like in vsetvl.cc and other related
   passes?  I don't mind maps but just wonder if it's on purpose, for
   convenience or something else. 

Besides, it might help to rename program_points_map (into program_points_per_bb
or so).  At first it looked quadratic to me but we're just iterating over
the program points of a BB.

Regards
 Robin

Re: [PATCH] RISC-V: Emit .note.GNU-stack for non-linux target as well

[Fangrui Song via Gcc-patches]

On Tue, Sep 5, 2023 at 5:14 AM Kito Cheng via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:

> committed, thanks :)
>
> On Tue, Sep 5, 2023 at 3:18 PM Jeff Law via Gcc-patches
>  wrote:
> >
> >
> >
> > On 8/31/23 03:05, Kito Cheng wrote:
> > > We only emit that on linux target before, that not problem before,
> > > however Qemu has fix a bug to make qemu user mode honor
> PT_GNU_STACK[1],
> > > that will cause problem when we test baremetal with qemu.
> > >
> > > So the straightforward is enable that as well for non-linux toolchian,
> > > the price is that will increase few bytes for each binary.
> > >
> > > [1]
> https://github.com/qemu/qemu/commit/872f3d046f2381e3f416519e82df96bd60818311
> > >
> > > gcc/ChangeLog:
> > >
> > >   * config/riscv/linux.h (TARGET_ASM_FILE_END): Move ...
> > >   * config/riscv/riscv.cc (TARGET_ASM_FILE_END): to here.
> > OK.
> > jeff
>

Does
https://github.com/qemu/qemu/commit/872f3d046f2381e3f416519e82df96bd60818311
use #define EXSTACK_DEFAULT true
for riscv?




-- 
宋方睿

Re: [PATCH] c++: Additional warning for name-hiding [PR12341]

[Jason Merrill via Gcc-patches]

On 9/4/23 13:18, priour...@gmail.com wrote:

From: benjamin priour 

Hi,

This patch was the first I wrote and had been
at that time returned to me because ill-formatted.

Getting busy with other things, I forgot about it.
I've now fixed the formatting.

Succesfully regstrapped on x86_64-linux-gnu off trunk
a7d052b3200c7928d903a0242b8cfd75d131e374.
Is it OK for trunk ?

Thanks,
Benjamin.

Patch below.
---

Add a new warning for name-hiding. When a class's field
is named similarly to one inherited, a warning should
be issued.
This new warning is controlled by the existing Wshadow.

gcc/cp/ChangeLog:

PR c++/12341
* search.cc (lookup_member):
New optional parameter to preempt processing the
inheritance tree deeper than necessary.
(lookup_field): Likewise.
(dfs_walk_all): Likewise.
* cp-tree.h: Update the above declarations.
* class.cc: (warn_name_hiding): New function.
(finish_struct_1): Call warn_name_hiding if -Wshadow.

gcc/testsuite/ChangeLog:

PR c++/12341
* g++.dg/pr12341-1.C: New file.
* g++.dg/pr12341-2.C: New file.

Signed-off-by: benjamin priour 
---
  gcc/cp/class.cc  | 75 
  gcc/cp/cp-tree.h |  9 ++--
  gcc/cp/search.cc | 28 
  gcc/testsuite/g++.dg/pr12341-1.C | 65 +++
  gcc/testsuite/g++.dg/pr12341-2.C | 34 +++
  5 files changed, 200 insertions(+), 11 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/pr12341-1.C
  create mode 100644 gcc/testsuite/g++.dg/pr12341-2.C

diff --git a/gcc/cp/class.cc b/gcc/cp/class.cc
index 778759237dc..b1c59c392a0 100644
--- a/gcc/cp/class.cc
+++ b/gcc/cp/class.cc
@@ -3080,6 +3080,79 @@ warn_hidden (tree t)
}
  }
  
+/* Warn about non-static fields name hiding.  */

+
+static void
+warn_name_hiding (tree t)
+{
+  if (is_empty_class (t) || CLASSTYPE_NEARLY_EMPTY_P (t))
+return;
+
+  for (tree field = TYPE_FIELDS (t); field; field = DECL_CHAIN (field))
+{
+  /* Skip if field is not an user-defined non-static data member.  */
+  if (TREE_CODE (field) != FIELD_DECL || DECL_ARTIFICIAL (field))
+   continue;
+
+  unsigned j;
+  tree name = DECL_NAME (field);
+  /* Skip if field is anonymous.  */
+  if (!name || !identifier_p (name))
+   continue;
+
+  auto_vec base_vardecls;
+  tree binfo;
+  tree base_binfo;
+  /* Iterate through all of the base classes looking for possibly
+shadowed non-static data members.  */
+  for (binfo = TYPE_BINFO (t), j = 0;
+  BINFO_BASE_ITERATE (binfo, j, base_binfo); j++)


Rather than iterate through the bases here, maybe add a mode to 
lookup_member/lookup_field_r that skips the most derived type, e.g. by 
adding that as a flag in lookup_field_info?


Probably instead of the once_suffices stuff?


+ if (base_vardecl)
+   {
+ auto_diagnostic_group d;
+ if (warning_at (location_of (field), OPT_Wshadow,
+ "%qD might shadow %qD", field, base_vardecl))


Why "might"?  We can give a correct answer, we shouldn't settle for an 
approximation.


Jason

Re: [PATCH] c++: Move consteval folding to cp_fold_r

[Jason Merrill via Gcc-patches]

On 9/5/23 15:59, Marek Polacek wrote:

On Tue, Sep 05, 2023 at 10:52:04AM -0400, Jason Merrill wrote:

On 9/1/23 13:23, Marek Polacek wrote:

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

-- >8 --

In the review of P2564:

it turned out that in order to correctly handle an example in the paper,
we should stop doing immediate evaluation in build_over_call and
bot_replace, and instead do it in cp_fold_r.  This patch does that.

Another benefit is that this is a pretty significant simplification, at
least in my opinion.  Also, this fixes the c++/110997 ICE (but the test
doesn't compile yet).

The main drawback seems to be that cp_fold_r doesn't process as much
code as we did before: uninstantiated templates


That's acceptable, it's an optional diagnostic.


and things like "false ? foo () : 1".


This is a problem.  Maybe we want cp_fold_r to recurse into the arms of a
COND_EXPR before folding them away?  Maybe only if we know we've seen an
immediate function?


Unfortunately we had already thrown the dead branch away when we got to
cp_fold_r.  I wonder if we have to adjust cxx_eval_conditional_expression
to call cp_fold_r on the dead branch too,


Hmm, I guess so.


perhaps with a new ff_ flag to skip the whole second switch in cp_fold_r?


Or factor out the immediate function handling to a separate walk 
function that cp_fold_r also calls?



But then it's possible that the in_immediate_context checks have to stay.


We can just not do the walk in immediate (or mce_true) context, like we 
currently avoid calling cp_fold_function.  For mce_unknown I guess we'd 
want to set *non_constant_p instead of giving an error.


Jason

Re: [PATCH] c++: Move consteval folding to cp_fold_r

[Marek Polacek via Gcc-patches]

On Tue, Sep 05, 2023 at 10:52:04AM -0400, Jason Merrill wrote:
> On 9/1/23 13:23, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > 
> > -- >8 --
> > 
> > In the review of P2564:
> > 
> > it turned out that in order to correctly handle an example in the paper,
> > we should stop doing immediate evaluation in build_over_call and
> > bot_replace, and instead do it in cp_fold_r.  This patch does that.
> > 
> > Another benefit is that this is a pretty significant simplification, at
> > least in my opinion.  Also, this fixes the c++/110997 ICE (but the test
> > doesn't compile yet).
> > 
> > The main drawback seems to be that cp_fold_r doesn't process as much
> > code as we did before: uninstantiated templates
> 
> That's acceptable, it's an optional diagnostic.
> 
> > and things like "false ? foo () : 1".
> 
> This is a problem.  Maybe we want cp_fold_r to recurse into the arms of a
> COND_EXPR before folding them away?  Maybe only if we know we've seen an
> immediate function?

Unfortunately we had already thrown the dead branch away when we got to
cp_fold_r.  I wonder if we have to adjust cxx_eval_conditional_expression
to call cp_fold_r on the dead branch too, perhaps with a new ff_ flag
to skip the whole second switch in cp_fold_r?  But then it's possible
that the in_immediate_context checks have to stay.

[ I'll address the rest later. ]

Marek

[PATCH 8/8] OpenMP: Fortran "!$omp declare mapper" support

[Julian Brown]

This patch implements "omp declare mapper" functionality for Fortran,
following the equivalent support for C and C++.  This version of the
patch is based on the version posted for the og13 branch:

  https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623357.html

and contains some significant changes from the version last posted for
mainline, here:

  https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609042.html

In particular, mappers are resolved during resolution in the Fortran
FE, rather than directly at parse time, and there are improvements to
diagnostics.  Each of 'target', 'target data', 'target enter data', and
'target exit data' directives are supported for mappers.  The following
patches from the og13 branch have also been incorporated into this one:

"OpenMP: Reprocess expanded clauses after 'declare mapper' instantiation":

  https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627006.html

"OpenMP: Look up 'declare mapper' definitions at resolution time not
parse time":

  https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627007.html

2023-09-05  Julian Brown  

gcc/fortran/
* dump-parse-tree.cc (show_attr): Show omp_udm_artificial_var flag.
(show_omp_namelist): Support OMP_MAP_POINTER_ONLY and OMP_MAP_UNSET.
* f95-lang.cc (LANG_HOOKS_OMP_FINISH_MAPPER_CLAUSES,
LANG_HOOKS_OMP_EXTRACT_MAPPER_DIRECTIVE,
LANG_HOOKS_OMP_MAP_ARRAY_SECTION): Define language hooks.
* gfortran.h (gfc_statement): Add ST_OMP_DECLARE_MAPPER.
(symbol_attribute): Add omp_udm_artificial_var attribute.
(gfc_omp_map_op): Add OMP_MAP_POINTER_ONLY and OMP_MAP_UNSET.
(gfc_omp_namelist): Add udm pointer to u2 union.
(gfc_omp_clauses): Add gfc_namespace pointer field 'ns'.
(gfc_omp_udm): New struct.
(gfc_omp_namelist_udm): New struct.
(gfc_symtree): Add omp_udm pointer.
(gfc_namespace): Add omp_udm_root symtree. Add omp_udm_ns flag.
(toc_directive): Add TOC_OPENMP_DECLARE_MAPPER value.
(gfc_free_omp_udm, gfc_omp_udm_find, gfc_find_omp_udm,
gfc_resolve_omp_udms, gfc_omp_instantiate_mappers): Add prototypes.
* match.cc (gfc_free_omp_namelist): Add support for freeing
user-defined 'declare mapper' definitions safely.
* match.h (gfc_match_omp_declare_mapper): Add prototype.
* module.cc (ab_attribute): Add AB_OMP_DECLARE_MAPPER_VAR.
(attr_bits): Add OMP_DECLARE_MAPPER_VAR.
(mio_symbol_attribute): Read/write AB_OMP_DECLARE_MAPPER_VAR attribute.
Set referenced attr on read.
(omp_map_clause_ops, omp_map_cardinality): New arrays.
(load_omp_udms, check_omp_declare_mappers): New functions.
(read_module): Load and check OMP declare mappers.
(write_omp_udm, write_omp_udms): New functions.
(write_module): Write OMP declare mappers.
* openmp.cc (gfc_match_omp_clauses): Add DEFAULT_MAP_OP parameter.  Add
declare mapper support.
(gfc_free_omp_udm, gfc_find_omp_udm, gfc_omp_udm_find,
gfc_match_omp_declare_mapper): New functions.
(omp_verify_clauses_symbol_dups, omp_verify_map_motion_clauses): Update
function comments.
(resolve_omp_clauses): Record namespace for 'declare mapper'
definitions.  Resolve mappers.
(resolve_omp_mapper_clauses): New function.
(resolve_omp_directive): Pass namespace to resolve_omp_clauses.
(omp_split_map_op, omp_join_map_op, omp_map_decayed_kind,
omp_basic_map_kind_name): New functions.
(gfc_subst_replace, gfc_subst_prepend_ref): New static globals.
(gfc_subst_in_expr_1, gfc_subst_in_expr, gfc_subst_mapper_var,
gfc_omp_instantiate_mapper, gfc_omp_instantiate_mappers,
gfc_resolve_omp_udm, gfc_resolve_omp_udms): New functions.
* parse.cc (decode_omp_directive): Add declare mapper support.
(case_omp_decl): Add ST_OMP_DECLARE_MAPPER case.
(gfc_ascii_statement): Add ST_OMP_DECLARE_MAPPER case.
* resolve.cc (resolve_types): Call gfc_resolve_omp_udms.
* symbol.cc (free_omp_udm_tree): New function.
(gfc_free_namespace): Call above.
* trans-decl.cc (omp_declare_mapper_ns): New global.
(gfc_finish_var_decl, gfc_generate_function_code): Support declare
mappers.
(gfc_trans_deferred_vars): Ignore artificial declare-mapper vars.
* trans-openmp.cc (tree-iterator.h): Include.
(gfc_omp_finish_mapper_clauses, gfc_omp_extract_mapper_directive,
gfc_omp_map_array_section): New functions.
(gfc_trans_omp_clauses): Add declare mapper support and
OMP_MAP_POINTER_ONLY support.
(gfc_record_mapper_bindings_code_fn, gfc_record_mapper_bindings_expr_fn,
gfc_find_nested_mappers, gfc_record_mapper_bindings): New functions.
(gfc_typespec * hash traits): New template.
(omp_declare_mapper_ns): Extern declaration.

[PATCH 7/8] OpenMP, Fortran: Split out OMP clause checking

[Julian Brown]

This patch breaks out two helper functions from
openmp.cc:resolve_omp_clauses, so those parts can be reused in order
to improve diagnostics (duplicate clause checking, etc.) after "declare
mapper" instantiation in the patch later in this series.  This is pretty
mechanical -- most previous lines are still executed in the same order,
though there is a little harmless reshuffling in a couple of places to
make things fit.

There shouldn't be any behavioural changes introduced by this patch.

2023-09-05  Julian Brown  

gcc/fortran/
* openmp.cc (omp_verify_clauses_symbol_dups,
omp_verify_map_motion_clauses): New helper functions, broken out of...
(resolve_omp_clauses): Here.  Call above.
---
 gcc/fortran/openmp.cc | 1229 +
 1 file changed, 629 insertions(+), 600 deletions(-)

diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
index 576b6784b441..1e0da61e9693 100644
--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -7314,6 +7314,631 @@ gfc_resolve_omp_assumptions (gfc_omp_assumptions 
*assume)
 >expr->where);
 }
 
+/* Check OMP_CLAUSES for duplicate symbols and various other constraints.
+   Helper function for resolve_omp_clauses.  */
+
+static void
+omp_verify_clauses_symbol_dups (gfc_code *code, gfc_omp_clauses *omp_clauses,
+   gfc_namespace *ns, bool openacc)
+{
+  gfc_omp_namelist *n;
+  int list;
+
+  /* Check that no symbol appears on multiple clauses, except that a symbol
+ can appear on both firstprivate and lastprivate.  */
+  for (list = 0; list < OMP_LIST_NUM; list++)
+for (n = omp_clauses->lists[list]; n; n = n->next)
+  {
+   if (!n->sym)  /* omp_all_memory.  */
+ continue;
+   n->sym->mark = 0;
+   n->sym->comp_mark = 0;
+   n->sym->data_mark = 0;
+   n->sym->dev_mark = 0;
+   n->sym->gen_mark = 0;
+   n->sym->reduc_mark = 0;
+   if (n->sym->attr.flavor == FL_VARIABLE
+   || n->sym->attr.proc_pointer
+   || (!code
+   && !ns->omp_udm_ns
+   && (!n->sym->attr.dummy || n->sym->ns != ns)))
+ {
+   if (!code
+   && !ns->omp_udm_ns
+   && (!n->sym->attr.dummy || n->sym->ns != ns))
+ gfc_error ("Variable %qs is not a dummy argument at %L",
+n->sym->name, >where);
+   continue;
+ }
+   if (n->sym->attr.flavor == FL_PROCEDURE
+   && n->sym->result == n->sym
+   && n->sym->attr.function)
+ {
+   if (gfc_current_ns->proc_name == n->sym
+   || (gfc_current_ns->parent
+   && gfc_current_ns->parent->proc_name == n->sym))
+ continue;
+   if (gfc_current_ns->proc_name->attr.entry_master)
+ {
+   gfc_entry_list *el = gfc_current_ns->entries;
+   for (; el; el = el->next)
+ if (el->sym == n->sym)
+   break;
+   if (el)
+ continue;
+ }
+   if (gfc_current_ns->parent
+   && gfc_current_ns->parent->proc_name->attr.entry_master)
+ {
+   gfc_entry_list *el = gfc_current_ns->parent->entries;
+   for (; el; el = el->next)
+ if (el->sym == n->sym)
+   break;
+   if (el)
+ continue;
+ }
+ }
+   if (list == OMP_LIST_MAP
+   && n->sym->attr.flavor == FL_PARAMETER)
+ {
+   if (openacc)
+ gfc_error ("Object %qs is not a variable at %L; parameters"
+" cannot be and need not be copied", n->sym->name,
+>where);
+   else
+ gfc_error ("Object %qs is not a variable at %L; parameters"
+" cannot be and need not be mapped", n->sym->name,
+>where);
+ }
+   else if (list != OMP_LIST_USES_ALLOCATORS)
+ gfc_error ("Object %qs is not a variable at %L", n->sym->name,
+>where);
+  }
+  if (omp_clauses->lists[OMP_LIST_REDUCTION_INSCAN]
+  && code->op != EXEC_OMP_DO
+  && code->op != EXEC_OMP_SIMD
+  && code->op != EXEC_OMP_DO_SIMD
+  && code->op != EXEC_OMP_PARALLEL_DO
+  && code->op != EXEC_OMP_PARALLEL_DO_SIMD)
+gfc_error ("% REDUCTION clause on construct other than DO, SIMD, "
+  "DO SIMD, PARALLEL DO, PARALLEL DO SIMD at %L",
+  _clauses->lists[OMP_LIST_REDUCTION_INSCAN]->where);
+
+  for (list = 0; list < OMP_LIST_NUM; list++)
+if (list != OMP_LIST_FIRSTPRIVATE
+   && list != OMP_LIST_LASTPRIVATE
+   && list != OMP_LIST_ALIGNED
+   && list != OMP_LIST_DEPEND
+   && list != OMP_LIST_FROM
+   && list != OMP_LIST_TO
+   && (list != OMP_LIST_REDUCTION || !openacc)
+   && list != OMP_LIST_ALLOCATE)
+  for (n = omp_clauses->lists[list]; n; 

[PATCH 6/8] OpenMP, Fortran: Per-directive control for gfc_trans_omp_clauses

[Julian Brown]

Some of the processing done by gfc_trans_omp_clauses depends on the
directive that that clause is attached to.  This patch refactors two
booleans and one gfc_exec_op parameter for gfc_trans_omp_clauses into
a single parameter of (new) enumerated type 'toc_directive'.  The same
parameter is also passed to gfc_trans_omp_array_section instead of a
gfc_exec_op type parameter and an 'openmp' boolean.

This is mostly done in aid of the patch later in the series implementing
"declare mapper" support for Fortran.

There shouldn't be any behavioural changes introduced by this patch.

2023-09-05  Julian Brown  

gcc/fortran/
* gfortran.h (toc_directive): New enum.
* trans-openmp.cc (gfc_trans_omp_array_section): Take toc_directive
parameter instead of gfc_exec_op and 'openmp' boolean.
(gfc_trans_omp_clauses): Take toc_directive parameter instead of
'declare_simd', 'openacc' and gfc_exec_op 'op' parameters.
(gfc_trans_oacc_construct, gfc_trans_oacc_executable_directive,
gfc_trans_oacc_combined_directive, gfc_trans_omp_target_exit_data,
gfc_trans_oacc_declare, gfc_trans_omp_declare_simd,
gfc_trans_omp_declare_variant): Update calls to gfc_trans_omp_clauses.
---
 gcc/fortran/gfortran.h  | 11 ++
 gcc/fortran/trans-openmp.cc | 77 +++--
 2 files changed, 50 insertions(+), 38 deletions(-)

diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 34ee800668ca..3070b4675e8e 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3180,6 +3180,17 @@ typedef struct gfc_finalizer
 gfc_finalizer;
 #define gfc_get_finalizer() XCNEW (gfc_finalizer)
 
+/* Control clause translation per-directive for gfc_trans_omp_clauses.  Also
+   used for gfc_omp_instantiate_mappers.  */
+
+enum toc_directive
+{
+  TOC_OPENMP,
+  TOC_OPENMP_DECLARE_SIMD,
+  TOC_OPENMP_EXIT_DATA,
+  TOC_OPENACC,
+  TOC_OPENACC_DECLARE
+};
 
 / Function prototypes */
 
diff --git a/gcc/fortran/trans-openmp.cc b/gcc/fortran/trans-openmp.cc
index a9dc1a617be5..829b28b24c79 100644
--- a/gcc/fortran/trans-openmp.cc
+++ b/gcc/fortran/trans-openmp.cc
@@ -2404,11 +2404,13 @@ static vec *doacross_steps;
 /* Translate an array section or array element.  */
 
 static void
-gfc_trans_omp_array_section (stmtblock_t *block, gfc_exec_op op,
+gfc_trans_omp_array_section (stmtblock_t *block, toc_directive cd,
 gfc_omp_namelist *n, tree decl, bool element,
-bool openmp, gomp_map_kind ptr_kind, tree ,
+gomp_map_kind ptr_kind, tree ,
 tree , tree , tree )
 {
+  bool openmp = (cd < TOC_OPENACC);
+  bool omp_exit_data = (cd == TOC_OPENMP_EXIT_DATA);
   gfc_se se;
   tree ptr, ptr2;
   tree elemsz = NULL_TREE;
@@ -2460,7 +2462,7 @@ gfc_trans_omp_array_section (stmtblock_t *block, 
gfc_exec_op op,
   if (POINTER_TYPE_P (TREE_TYPE (decl))
   && GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (TREE_TYPE (decl)))
   && ptr_kind == GOMP_MAP_POINTER
-  && op != EXEC_OMP_TARGET_EXIT_DATA
+  && !omp_exit_data
   && OMP_CLAUSE_MAP_KIND (node) != GOMP_MAP_RELEASE
   && OMP_CLAUSE_MAP_KIND (node) != GOMP_MAP_DELETE)
 
@@ -2479,8 +2481,7 @@ gfc_trans_omp_array_section (stmtblock_t *block, 
gfc_exec_op op,
   gomp_map_kind map_kind;
   if (OMP_CLAUSE_MAP_KIND (node) == GOMP_MAP_DELETE)
map_kind = OMP_CLAUSE_MAP_KIND (node);
-  else if (op == EXEC_OMP_TARGET_EXIT_DATA
-  || OMP_CLAUSE_MAP_KIND (node) == GOMP_MAP_RELEASE)
+  else if (omp_exit_data || OMP_CLAUSE_MAP_KIND (node) == GOMP_MAP_RELEASE)
map_kind = GOMP_MAP_RELEASE;
   else
map_kind = GOMP_MAP_TO;
@@ -2499,11 +2500,10 @@ gfc_trans_omp_array_section (stmtblock_t *block, 
gfc_exec_op op,
   OMP_CLAUSE_SIZE (node2) = TYPE_SIZE_UNIT (type);
   if (OMP_CLAUSE_MAP_KIND (node) == GOMP_MAP_DELETE
  || OMP_CLAUSE_MAP_KIND (node) == GOMP_MAP_RELEASE
- || op == EXEC_OMP_TARGET_EXIT_DATA)
+ || omp_exit_data)
{
- gomp_map_kind map_kind
-   = (op == EXEC_OMP_TARGET_EXIT_DATA) ? GOMP_MAP_RELEASE
-   : OMP_CLAUSE_MAP_KIND (node);
+ gomp_map_kind map_kind = omp_exit_data ? GOMP_MAP_RELEASE
+: OMP_CLAUSE_MAP_KIND (node);
  OMP_CLAUSE_SET_MAP_KIND (node2, map_kind);
  OMP_CLAUSE_RELEASE_DESCRIPTOR (node2) = 1;
}
@@ -2681,9 +2681,11 @@ get_symbol_rooted_namelist (hash_map= TOC_OPENACC);
+  bool omp_exit_data = (cd == TOC_OPENMP_EXIT_DATA);
   tree omp_clauses = NULL_TREE, prev_clauses, chunk_size, c;
   tree iterator = NULL_TREE;
   tree tree_block = NULL_TREE;
@@ -3250,7 +3252,7 @@ gfc_trans_omp_clauses (stmtblock_t *block, 
gfc_omp_clauses *clauses,
  && n->sym->ts.deferred
  && 

[PATCH 5/8] OpenMP, Fortran: Pass list number to gfc_free_omp_namelist

[Julian Brown]

This is a cleanup to avoid passing an ever-longer list of boolean
arguments to gfc_free_omp_namelist, in support of the Fortran "declare
mapper" implementation further along this patch series.

This patch isn't intended to cause any behavioural changes.

2023-09-05  Julian Brown  

gcc/fortran/
* gfortran.h (gfc_free_omp_namelist): Update prototype.
* match.cc (gfc_free_omp_namelist): Remove FREE_NS,
FREE_ALIGN_ALLOCATOR, FREE_MEM_TRAITS_SPACE parameters and replace
with LIST.
* openmp.cc (gfc_free_omp_clauses, gfc_match_omp_clause_reduction,
gfc_match_omp_clause_uses_allocators, gfc_match_omp_clauses,
gfc_match_omp_allocate, gfc_match_omp_flush, resolve_omp_clauses):
Update calls to gfc_free_omp_namelist.
* st.cc (gfc_free_statement): Update call to gfc_free_omp_namelist.
---
 gcc/fortran/gfortran.h |  2 +-
 gcc/fortran/match.cc   |  7 ---
 gcc/fortran/openmp.cc  | 31 ++-
 gcc/fortran/st.cc  |  2 +-
 4 files changed, 20 insertions(+), 22 deletions(-)

diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 3c8270a0f83a..34ee800668ca 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3605,7 +3605,7 @@ void gfc_free_iterator (gfc_iterator *, int);
 void gfc_free_forall_iterator (gfc_forall_iterator *);
 void gfc_free_alloc_list (gfc_alloc *);
 void gfc_free_namelist (gfc_namelist *);
-void gfc_free_omp_namelist (gfc_omp_namelist *, bool, bool, bool);
+void gfc_free_omp_namelist (gfc_omp_namelist *, int = OMP_LIST_NUM);
 void gfc_free_equiv (gfc_equiv *);
 void gfc_free_equiv_until (gfc_equiv *, gfc_equiv *);
 void gfc_free_data (gfc_data *);
diff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
index ba23bcd96923..dd72a03027a1 100644
--- a/gcc/fortran/match.cc
+++ b/gcc/fortran/match.cc
@@ -5536,10 +5536,11 @@ gfc_free_namelist (gfc_namelist *name)
 /* Free an OpenMP namelist structure.  */
 
 void
-gfc_free_omp_namelist (gfc_omp_namelist *name, bool free_ns,
-  bool free_align_allocator,
-  bool free_mem_traits_space)
+gfc_free_omp_namelist (gfc_omp_namelist *name, int list)
 {
+  bool free_ns = (list == OMP_LIST_AFFINITY || list == OMP_LIST_DEPEND);
+  bool free_align_allocator = (list == OMP_LIST_ALLOCATE);
+  bool free_mem_traits_space = (list == OMP_LIST_USES_ALLOCATORS);
   gfc_omp_namelist *n;
 
   for (; name; name = n)
diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
index 234d896b2ce2..576b6784b441 100644
--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -186,10 +186,7 @@ gfc_free_omp_clauses (gfc_omp_clauses *c)
   gfc_free_expr (c->num_workers_expr);
   gfc_free_expr (c->vector_length_expr);
   for (i = 0; i < OMP_LIST_NUM; i++)
-gfc_free_omp_namelist (c->lists[i],
-  i == OMP_LIST_AFFINITY || i == OMP_LIST_DEPEND,
-  i == OMP_LIST_ALLOCATE,
-  i == OMP_LIST_USES_ALLOCATORS);
+gfc_free_omp_namelist (c->lists[i], i);
   gfc_free_expr_list (c->wait_list);
   gfc_free_expr_list (c->tile_list);
   free (CONST_CAST (char *, c->critical_name));
@@ -554,7 +551,7 @@ syntax:
   gfc_error ("Syntax error in OpenMP variable list at %C");
 
 cleanup:
-  gfc_free_omp_namelist (head, false, false, false);
+  gfc_free_omp_namelist (head);
   gfc_current_locus = old_loc;
   return MATCH_ERROR;
 }
@@ -644,7 +641,7 @@ syntax:
   gfc_error ("Syntax error in OpenMP variable list at %C");
 
 cleanup:
-  gfc_free_omp_namelist (head, false, false, false);
+  gfc_free_omp_namelist (head);
   gfc_current_locus = old_loc;
   return MATCH_ERROR;
 }
@@ -753,7 +750,7 @@ syntax:
   gfc_error ("Syntax error in OpenMP SINK dependence-type list at %C");
 
 cleanup:
-  gfc_free_omp_namelist (head, false, false, false);
+  gfc_free_omp_namelist (head);
   gfc_current_locus = old_loc;
   return MATCH_ERROR;
 }
@@ -1504,7 +1501,7 @@ gfc_match_omp_clause_reduction (char pc, gfc_omp_clauses 
*c, bool openacc,
   *head = NULL;
   gfc_error_now ("!$OMP DECLARE REDUCTION %s not found at %L",
 buffer, _loc);
-  gfc_free_omp_namelist (n, false, false, false);
+  gfc_free_omp_namelist (n, list_idx);
 }
   else
 for (n = *head; n; n = n->next)
@@ -1795,7 +1792,7 @@ gfc_match_omp_clause_uses_allocators (gfc_omp_clauses *c)
   return MATCH_YES;
 
 error:
-  gfc_free_omp_namelist (head, false, false, true);
+  gfc_free_omp_namelist (head, OMP_LIST_USES_ALLOCATORS);
   return MATCH_ERROR;
 }
 
@@ -1922,7 +1919,7 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, const 
omp_mask mask,
 
  if (end_colon && gfc_match (" %e )", ) != MATCH_YES)
{
- gfc_free_omp_namelist (*head, false, false, false);
+ gfc_free_omp_namelist (*head);
  gfc_current_locus = old_loc;
  *head = NULL;
  break;
@@ -2865,7 +2862,7 @@ gfc_match_omp_clauses 

[PATCH 4/8] OpenMP: Support OpenMP 5.0 "declare mapper" directives for C

[Julian Brown]

This patch adds support for "declare mapper" directives (and the "mapper"
modifier on "map" clauses) for C.  It was previously posted for mainline
here:

  https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609041.html

and for the og13 branch here:

  https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623356.html

This version supports mappers on "target data", "target enter data" and
"target exit data" directives as well as on "target" directives.

2023-09-05  Julian Brown  

gcc/c/
* c-decl.cc (c_omp_mapper_id, c_omp_mapper_decl, c_omp_mapper_lookup,
c_omp_extract_mapper_directive, c_omp_map_array_section,
c_omp_scan_mapper_bindings_r, c_omp_scan_mapper_bindings): New
functions.
* c-objc-common.h (LANG_HOOKS_OMP_FINISH_MAPPER_CLAUSES,
LANG_HOOKS_OMP_MAPPER_LOOKUP, LANG_HOOKS_OMP_EXTRACT_MAPPER_DIRECTIVE,
LANG_HOOKS_OMP_MAP_ARRAY_SECTION): Define langhooks for C.
* c-parser.cc (c_parser_omp_clause_map): Add KIND parameter.  Handle
mapper modifier.
(c_parser_omp_all_clauses): Update call to c_parser_omp_clause_map with
new kind argument.
(c_parser_omp_target_data, c_parser_omp_target_enter_data,
c_parser_omp_target_exit_data): Instantiate explicit mappers.
(c_parser_omp_target): Instantiate explicit mappers and record bindings
for implicit mappers.
(c_parser_omp_declare_mapper): Parse "declare mapper" directives.
(c_parser_omp_declare): Support "declare mapper".
* c-tree.h (c_omp_finish_mapper_clauses, c_omp_mapper_lookup,
c_omp_extract_mapper_directive, c_omp_map_array_section,
c_omp_mapper_id, c_omp_mapper_decl, c_omp_scan_mapper_bindings): Add
prototypes.
* c-typeck.cc (c_finish_omp_clauses): Handle GOMP_MAP_PUSH_MAPPER_NAME
and GOMP_MAP_POP_MAPPER_NAME.
(c_omp_finish_mapper_clauses): New function (langhook).

gcc/testsuite/
* c-c++-common/gomp/declare-mapper-3.c: Enable for C.
* c-c++-common/gomp/declare-mapper-4.c: Likewise.
* c-c++-common/gomp/declare-mapper-5.c: Likewise.
* c-c++-common/gomp/declare-mapper-6.c: Likewise.
* c-c++-common/gomp/declare-mapper-7.c: Likewise.
* c-c++-common/gomp/declare-mapper-8.c: Likewise.
* c-c++-common/gomp/declare-mapper-9.c: Likewise.
* c-c++-common/gomp/declare-mapper-12.c: Likewise.
* c-c++-common/gomp/declare-mapper-15.c: Likewise.
* c-c++-common/gomp/declare-mapper-16.c: Likewise.
* gcc.dg/gomp/declare-mapper-10.c: New test.
* gcc.dg/gomp/declare-mapper-11.c: New test.

libgomp/
* testsuite/libgomp.c-c++-common/declare-mapper-9.c: Enable for C.
* testsuite/libgomp.c-c++-common/declare-mapper-10.c: Likewise.
* testsuite/libgomp.c-c++-common/declare-mapper-11.c: Likewise.
* testsuite/libgomp.c-c++-common/declare-mapper-12.c: Likewise.
* testsuite/libgomp.c-c++-common/declare-mapper-13.c: Likewise.
* testsuite/libgomp.c-c++-common/declare-mapper-14.c: Likewise.
---
 gcc/c/c-decl.cc   | 169 ++
 gcc/c/c-objc-common.h |  12 +
 gcc/c/c-parser.cc | 291 --
 gcc/c/c-tree.h|   7 +
 gcc/c/c-typeck.cc |  15 +
 .../c-c++-common/gomp/declare-mapper-12.c |   2 +-
 .../c-c++-common/gomp/declare-mapper-15.c |   2 +-
 .../c-c++-common/gomp/declare-mapper-16.c |   2 +-
 .../c-c++-common/gomp/declare-mapper-3.c  |   2 +-
 .../c-c++-common/gomp/declare-mapper-4.c  |   2 +-
 .../c-c++-common/gomp/declare-mapper-5.c  |   2 +-
 .../c-c++-common/gomp/declare-mapper-6.c  |   2 +-
 .../c-c++-common/gomp/declare-mapper-7.c  |   2 +-
 .../c-c++-common/gomp/declare-mapper-8.c  |   2 +-
 .../c-c++-common/gomp/declare-mapper-9.c  |   2 +-
 gcc/testsuite/gcc.dg/gomp/declare-mapper-10.c |  61 
 gcc/testsuite/gcc.dg/gomp/declare-mapper-11.c |  33 ++
 .../libgomp.c-c++-common/declare-mapper-10.c  |   2 +-
 .../libgomp.c-c++-common/declare-mapper-11.c  |   2 +-
 .../libgomp.c-c++-common/declare-mapper-12.c  |   2 +-
 .../libgomp.c-c++-common/declare-mapper-13.c  |   2 +-
 .../libgomp.c-c++-common/declare-mapper-14.c  |   2 +-
 .../libgomp.c-c++-common/declare-mapper-9.c   |   2 +-
 23 files changed, 584 insertions(+), 36 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/gomp/declare-mapper-10.c
 create mode 100644 gcc/testsuite/gcc.dg/gomp/declare-mapper-11.c

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 1f9eb44dbaa2..ac71092fcad6 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -13144,6 +13144,175 @@ c_check_omp_declare_reduction_r (tree *tp, int *, 
void *data)
   return NULL_TREE;
 }
 
+/* Return identifier to look up for omp declare reduction.  */
+
+tree
+c_omp_mapper_id (tree mapper_id)
+{
+  const char *p = NULL;
+
+  const char 

[PATCH 3/8] OpenMP: C++ "declare mapper" support

[Julian Brown]

This patch adds support for OpenMP 5.0 "declare mapper" functionality
for C++.  This is based on the version of the patch posted for the og13
branch here:

  https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623353.html

The following follow up patches/fixes have also been incorporated into
this version:

"OpenMP: Expand "declare mapper" mappers for target {enter,exit,}
data directives":

  https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623780.html

"OpenMP: Introduce C_ORT_{,OMP_}DECLARE_MAPPER c_omp_region_type types":

  https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627005.html

2023-09-05  Julian Brown  

gcc/c-family/
* c-common.h (c_omp_region_type): Add C_ORT_EXIT_DATA,
C_ORT_DECLARE_MAPPER, C_ORT_OMP_EXIT_DATA, C_ORT_OMP_DECLARE_MAPPER
values.
(omp_mapper_list): Add forward declaration.
(c_omp_find_nested_mappers, c_omp_instantiate_mappers): Add prototypes.
* c-omp.cc (c_omp_find_nested_mappers): New function.
(remap_mapper_decl_info): New struct.
(remap_mapper_decl_1, omp_split_map_kind, omp_join_map_kind,
omp_map_decayed_kind, omp_instantiate_mapper,
c_omp_instantiate_mappers): New functions.

gcc/cp/
* constexpr.cc (reduced_constant_expression_p): Add OMP_DECLARE_MAPPER
case.
(cxx_eval_constant_expression, potential_constant_expression_1):
Likewise.
* cp-gimplify.cc (cxx_omp_finish_mapper_clauses): New function.
* cp-objcp-common.h (LANG_HOOKS_OMP_FINISH_MAPPER_CLAUSES,
LANG_HOOKS_OMP_MAPPER_LOOKUP, LANG_HOOKS_OMP_EXTRACT_MAPPER_DIRECTIVE,
LANG_HOOKS_OMP_MAP_ARRAY_SECTION): Define langhooks.
* cp-tree.h (lang_decl_base): Add omp_declare_mapper_p field.  Recount
spare bits comment.
(DECL_OMP_DECLARE_MAPPER_P): New macro.
(omp_mapper_id, cp_check_omp_declare_mapper, omp_instantiate_mappers,
cxx_omp_finish_mapper_clauses, cxx_omp_mapper_lookup,
cxx_omp_extract_mapper_directive, cxx_omp_map_array_section): Add
prototypes.
* decl.cc (check_initializer): Add OpenMP declare mapper support.
(cp_finish_decl): Set DECL_INITIAL for OpenMP declare mapper var decls
as appropriate.
* decl2.cc (mark_used): Instantiate OpenMP "declare mapper" magic var
decls.
* error.cc (dump_omp_declare_mapper): New function.
(dump_simple_decl): Use above.
* parser.cc (cp_parser_omp_clause_map): Add KIND parameter.  Support
"mapper" modifier.
(cp_parser_omp_all_clauses): Add KIND argument to
cp_parser_omp_clause_map call.
(cp_parser_omp_target): Call omp_instantiate_mappers before
finish_omp_clauses.
(cp_parser_omp_declare_mapper): New function.
(cp_parser_omp_declare): Add "declare mapper" support.
* pt.cc (tsubst_decl): Adjust name of "declare mapper" magic var decls
once we know their type.
(tsubst_omp_clauses): Call omp_instantiate_mappers before
finish_omp_clauses, for target regions.
(tsubst_expr): Support OMP_DECLARE_MAPPER nodes.
(instantiate_decl): Instantiate initialiser (i.e definition) for OpenMP
declare mappers.
* semantics.cc (gimplify.h): Include.
(omp_mapper_id, cxx_omp_mapper_lookup, cxx_omp_extract_mapper_directive,
cxx_omp_map_array_section, cp_check_omp_declare_mapper): New functions.
(finish_omp_clauses): Delete GOMP_MAP_PUSH_MAPPER_NAME and
GOMP_MAP_POP_MAPPER_NAME artificial clauses.
(omp_target_walk_data): Add MAPPERS field.
(finish_omp_target_clauses_r): Scan for uses of struct/union/class type
variables.
(finish_omp_target_clauses): Create artificial mapper binding clauses
for used structs/unions/classes in offload region.

gcc/fortran/
* parse.cc (tree.h, fold-const.h, tree-hash-traits.h): Add includes
(for additions to omp-general.h).

gcc/
* gimplify.cc (gimplify_omp_ctx): Add IMPLICIT_MAPPERS field.
(new_omp_context): Initialise IMPLICIT_MAPPERS hash map.
(delete_omp_context): Delete IMPLICIT_MAPPERS hash map.
(instantiate_mapper_info): New structs.
(remap_mapper_decl_1, omp_mapper_copy_decl, omp_instantiate_mapper,
omp_instantiate_implicit_mappers): New functions.
(gimplify_scan_omp_clauses): Handle MAPPER_BINDING clauses.
(gimplify_adjust_omp_clauses): Instantiate implicit declared mappers.
(gimplify_omp_declare_mapper): New function.
(gimplify_expr): Call above function.
* langhooks-def.h (lhd_omp_finish_mapper_clauses,
lhd_omp_mapper_lookup, lhd_omp_extract_mapper_directive,
lhd_omp_map_array_section): Add prototypes.
(LANG_HOOKS_OMP_FINISH_MAPPER_CLAUSES,
LANG_HOOKS_OMP_MAPPER_LOOKUP, LANG_HOOKS_OMP_EXTRACT_MAPPER_DIRECTIVE,
LANG_HOOKS_OMP_MAP_ARRAY_SECTION): Define macros.

[PATCH 2/8] OpenMP: lvalue parsing for map/to/from clauses (C)

[Julian Brown]

This patch adds support for parsing general lvalues ("locator list item
types") for OpenMP "map", "to" and "from" clauses to the C front-end,
similar to the previously-posted patch for C++.  Such syntax is permitted
for OpenMP 5.0 and above.  It was previously posted for mainline here:

  https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609038.html

and for the og13 branch here:

  https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623355.html

2023-09-05  Julian Brown  

gcc/c/
* c-pretty-print.cc (c_pretty_printer::postfix_expression,
c_pretty_printer::expression): Add OMP_ARRAY_SECTION support.
* c-parser.cc (c_parser_braced_init, c_parser_conditional_expression):
Don't allow OpenMP array section.
(c_parser_postfix_expression): Don't allow array section in statement
expression.
(c_parser_postfix_expression_after_primary): Add support for OpenMP
array section parsing.
(c_parser_expr_list): Don't allow OpenMP array section here.
(c_parser_omp_variable_list): Change ALLOW_DEREF parameter to
MAP_LVALUE.  Support parsing of general lvalues in "map", "to" and
"from" clauses.
(c_parser_omp_var_list_parens): Change ALLOW_DEREF parameter to
MAP_LVALUE.  Update call to c_parser_omp_variable_list.
(c_parser_oacc_data_clause): Update calls to
c_parser_omp_var_list_parens.
(c_parser_omp_clause_reduction): Use OMP_ARRAY_SECTION tree node
instead of TREE_LIST for array sections.
(c_parser_omp_target): Allow GOMP_MAP_ATTACH.
* c-tree.h (c_omp_array_section_p): Add extern declaration.
(build_omp_array_section): Add prototype.
* c-typeck.c (c_omp_array_section_p): Add flag.
(mark_exp_read): Support OMP_ARRAY_SECTION.
(build_omp_array_section): Add function.
(build_external_ref): Tweak error path for OpenMP array sections.
(handle_omp_array_sections_1): Use OMP_ARRAY_SECTION tree code instead
of TREE_LIST.  Handle more kinds of expressions.
(c_oacc_check_attachments): Use OMP_ARRAY_SECTION instead of TREE_LIST
for array sections.
(c_finish_omp_clauses): Use OMP_ARRAY_SECTION instead of TREE_LIST.
Check for supported expression types.

gcc/testsuite/
* gcc.dg/gomp/bad-array-section-c-1.c: New test.
* gcc.dg/gomp/bad-array-section-c-2.c: New test.
* gcc.dg/gomp/bad-array-section-c-3.c: New test.
* gcc.dg/gomp/bad-array-section-c-4.c: New test.
* gcc.dg/gomp/bad-array-section-c-5.c: New test.
* gcc.dg/gomp/bad-array-section-c-6.c: New test.
* gcc.dg/gomp/bad-array-section-c-7.c: New test.
* gcc.dg/gomp/bad-array-section-c-8.c: New test.

libgomp/
* testsuite/libgomp.c-c++-common/ind-base-4.c: New test.
* testsuite/libgomp.c-c++-common/unary-ptr-1.c: New test.
---
 gcc/c-family/c-pretty-print.cc|  12 ++
 gcc/c/c-parser.cc | 181 +++---
 gcc/c/c-tree.h|   2 +
 gcc/c/c-typeck.cc | 109 +--
 .../gcc.dg/gomp/bad-array-section-c-1.c   |  16 ++
 .../gcc.dg/gomp/bad-array-section-c-2.c   |  13 ++
 .../gcc.dg/gomp/bad-array-section-c-3.c   |  24 +++
 .../gcc.dg/gomp/bad-array-section-c-4.c   |  26 +++
 .../gcc.dg/gomp/bad-array-section-c-5.c   |  15 ++
 .../gcc.dg/gomp/bad-array-section-c-6.c   |  16 ++
 .../gcc.dg/gomp/bad-array-section-c-7.c   |  26 +++
 .../gcc.dg/gomp/bad-array-section-c-8.c   |  21 ++
 .../libgomp.c-c++-common/ind-base-4.c |  50 +
 .../libgomp.c-c++-common/unary-ptr-1.c|  16 ++
 14 files changed, 482 insertions(+), 45 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/gomp/bad-array-section-c-1.c
 create mode 100644 gcc/testsuite/gcc.dg/gomp/bad-array-section-c-2.c
 create mode 100644 gcc/testsuite/gcc.dg/gomp/bad-array-section-c-3.c
 create mode 100644 gcc/testsuite/gcc.dg/gomp/bad-array-section-c-4.c
 create mode 100644 gcc/testsuite/gcc.dg/gomp/bad-array-section-c-5.c
 create mode 100644 gcc/testsuite/gcc.dg/gomp/bad-array-section-c-6.c
 create mode 100644 gcc/testsuite/gcc.dg/gomp/bad-array-section-c-7.c
 create mode 100644 gcc/testsuite/gcc.dg/gomp/bad-array-section-c-8.c
 create mode 100644 libgomp/testsuite/libgomp.c-c++-common/ind-base-4.c
 create mode 100644 libgomp/testsuite/libgomp.c-c++-common/unary-ptr-1.c

diff --git a/gcc/c-family/c-pretty-print.cc b/gcc/c-family/c-pretty-print.cc
index 7536a7c471ff..225ac7ef2851 100644
--- a/gcc/c-family/c-pretty-print.cc
+++ b/gcc/c-family/c-pretty-print.cc
@@ -1615,6 +1615,17 @@ c_pretty_printer::postfix_expression (tree e)
   pp_c_right_bracket (this);
   break;
 
+case OMP_ARRAY_SECTION:
+  postfix_expression (TREE_OPERAND (e, 0));
+  pp_c_left_bracket (this);
+  if (TREE_OPERAND (e, 1))
+   expression (TREE_OPERAND (e, 1));
+  

[PATCH 0/8] OpenMP: lvalue parsing and "declare mapper" support

[Julian Brown]

This series implements "lvalue" parsing for C and C++ map/to/from clauses,
and "declare mapper" support for C, C++ and Fortran.  This is the latter
part of the series that was previously posted for mainline here:

  https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609031.html

and is approximately equivalent to the series posted for the og13
branch here:

  https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623352.html

though with several follow-up patches rolled in (as mentioned on the
following patch-specific emails).

This series applies on top of the infrastructural support series posted
here:

  https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627895.html

Tested with offloading to NVPTX and bootstrapped. OK?

Julian Brown (8):
  OpenMP: lvalue parsing for map/to/from clauses (C++)
  OpenMP: lvalue parsing for map/to/from clauses (C)
  OpenMP: C++ "declare mapper" support
  OpenMP: Support OpenMP 5.0 "declare mapper" directives for C
  OpenMP, Fortran: Pass list number to gfc_free_omp_namelist
  OpenMP, Fortran: Per-directive control for gfc_trans_omp_clauses
  OpenMP, Fortran: Split out OMP clause checking
  OpenMP: Fortran "!$omp declare mapper" support

 gcc/c-family/c-common.h   |   11 +-
 gcc/c-family/c-omp.cc |  500 ++-
 gcc/c-family/c-pretty-print.cc|   12 +
 gcc/c/c-decl.cc   |  169 +
 gcc/c/c-objc-common.h |   12 +
 gcc/c/c-parser.cc |  472 ++-
 gcc/c/c-tree.h|9 +
 gcc/c/c-typeck.cc |  124 +-
 gcc/cp/constexpr.cc   |   10 +
 gcc/cp/cp-gimplify.cc |6 +
 gcc/cp/cp-objcp-common.h  |9 +
 gcc/cp/cp-tree.h  |   19 +-
 gcc/cp/decl.cc|   27 +-
 gcc/cp/decl2.cc   |   54 +-
 gcc/cp/error.cc   |   34 +
 gcc/cp/parser.cc  |  514 ++-
 gcc/cp/parser.h   |3 +
 gcc/cp/pt.cc  |   84 +-
 gcc/cp/semantics.cc   |  260 +-
 gcc/cp/typeck.cc  |   50 +
 gcc/fortran/dump-parse-tree.cc|4 +
 gcc/fortran/f95-lang.cc   |7 +
 gcc/fortran/gfortran.h|   76 +-
 gcc/fortran/match.cc  |   14 +-
 gcc/fortran/match.h   |1 +
 gcc/fortran/module.cc |  257 +-
 gcc/fortran/openmp.cc | 2026 +++
 gcc/fortran/parse.cc  |   13 +-
 gcc/fortran/resolve.cc|2 +
 gcc/fortran/st.cc |2 +-
 gcc/fortran/symbol.cc |   16 +
 gcc/fortran/trans-decl.cc |   33 +-
 gcc/fortran/trans-openmp.cc   |  592 ++-
 gcc/fortran/trans-stmt.h  |1 +
 gcc/fortran/trans.h   |3 +
 gcc/gimplify.cc   |  560 ++-
 gcc/langhooks-def.h   |   13 +
 gcc/langhooks.cc  |   35 +
 gcc/langhooks.h   |   16 +
 gcc/omp-general.h |   86 +
 .../c-c++-common/gomp/declare-mapper-12.c |   22 +
 .../c-c++-common/gomp/declare-mapper-15.c |   59 +
 .../c-c++-common/gomp/declare-mapper-16.c |   39 +
 .../c-c++-common/gomp/declare-mapper-3.c  |   30 +
 .../c-c++-common/gomp/declare-mapper-4.c  |   78 +
 .../c-c++-common/gomp/declare-mapper-5.c  |   26 +
 .../c-c++-common/gomp/declare-mapper-6.c  |   23 +
 .../c-c++-common/gomp/declare-mapper-7.c  |   29 +
 .../c-c++-common/gomp/declare-mapper-8.c  |   43 +
 .../c-c++-common/gomp/declare-mapper-9.c  |   34 +
 gcc/testsuite/c-c++-common/gomp/map-6.c   |   14 +-
 gcc/testsuite/g++.dg/gomp/array-section-1.C   |   38 +
 gcc/testsuite/g++.dg/gomp/array-section-2.C   |   63 +
 .../g++.dg/gomp/bad-array-section-1.C |   35 +
 .../g++.dg/gomp/bad-array-section-10.C|   35 +
 .../g++.dg/gomp/bad-array-section-11.C|   36 +
 .../g++.dg/gomp/bad-array-section-2.C |   33 +
 .../g++.dg/gomp/bad-array-section-3.C |   28 +
 .../g++.dg/gomp/bad-array-section-4.C |   50 +
 .../g++.dg/gomp/bad-array-section-5.C |   50 +
 .../g++.dg/gomp/bad-array-section-6.C |   24 +
 .../g++.dg/gomp/bad-array-section-7.C |   36 +
 .../g++.dg/gomp/bad-array-section-8.C |   53 +
 .../g++.dg/gomp/bad-array-section-9.C |   39 +
 gcc/testsuite/g++.dg/gomp/declare-mapper-1.C  |   58 +
 gcc/testsuite/g++.dg/gomp/declare-mapper-2.C  |   30 +
 .../gomp/has_device_addr-non-lvalue-1.C   |   36 +
 

Re: [Committed] RISC-V: Add Types to Un-Typed Risc-v Instructions:

[Edwin Lu]

On 9/1/2023 11:02 AM, Jeff Law wrote:



On 8/31/23 11:32, Edwin Lu wrote:

Related Discussion:
https://inbox.sourceware.org/gcc-patches/12fb5088-3f28-0a69-de1e-f387371a5...@gmail.com/ 



This patch updates the riscv instructions to ensure that no insn is left
without a type attribute. Added new types: "trap" (self explanatory) 
and "cbo"

(for cache related instructions)

Tested for regressions using rv32/64 multilib for linux/newlib. Also 
tested

rv32/64 gcv for linux.

gcc/Changelog:

* config/riscv/riscv.md: Update/Add types

OK.

jeff


Committed!

Edwin

Re: [Committed] Add Types to Un-Typed Pic Instructions:

[Edwin Lu]

On 9/1/2023 6:15 AM, Jeff Law wrote:



On 8/31/23 17:01, Edwin Lu wrote:

Related Discussion:
https://inbox.sourceware.org/gcc-patches/12fb5088-3f28-0a69-de1e-f387371a5...@gmail.com/ 



This patch updates the pic instructions to ensure that no insn is left
without a type attribute.

Tested for regressions using rv32/64 multilib with newlib/linux.

gcc/Changelog:

* config/riscv/pic.md: Update types

OK.  THanks.
jeff


Committed!

Edwin

Re: [PATCH] riscv: xtheadbb: Enable constant synthesis with th.srri

[Philipp Tomsich]

Applied to master. Thanks!
Philipp.

On Tue, 5 Sept 2023 at 18:10, Jeff Law  wrote:

>
>
> On 9/5/23 09:42, Christoph Muellner wrote:
> > From: Christoph Müllner 
> >
> > Some constants can be built up using rotate-right instructions.
> > The code that enables this can be found in riscv_build_integer_1().
> > However, this functionality is only available for Zbb, which
> > includes the rori instruction.  This patch enables this also for
> > XTheadBb, which includes the th.srri instruction.
> >
> > Signed-off-by: Christoph Müllner 
> >
> > gcc/ChangeLog:
> >
> >   * config/riscv/riscv.cc (riscv_build_integer_1): Enable constant
> >   synthesis with rotate-right for XTheadBb.
> OK
> Jeff
>

Re: [PATCH] riscv: xtheadbb: Enable constant synthesis with th.srri

[Jeff Law via Gcc-patches]

On 9/5/23 09:42, Christoph Muellner wrote:

From: Christoph Müllner 

Some constants can be built up using rotate-right instructions.
The code that enables this can be found in riscv_build_integer_1().
However, this functionality is only available for Zbb, which
includes the rori instruction.  This patch enables this also for
XTheadBb, which includes the th.srri instruction.

Signed-off-by: Christoph Müllner 

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_build_integer_1): Enable constant
synthesis with rotate-right for XTheadBb.

OK
Jeff

[PATCH] riscv: xtheadbb: Enable constant synthesis with th.srri

[Christoph Muellner]

From: Christoph Müllner 

Some constants can be built up using rotate-right instructions.
The code that enables this can be found in riscv_build_integer_1().
However, this functionality is only available for Zbb, which
includes the rori instruction.  This patch enables this also for
XTheadBb, which includes the th.srri instruction.

Signed-off-by: Christoph Müllner 

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_build_integer_1): Enable constant
synthesis with rotate-right for XTheadBb.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/xtheadbb-li-rotr.c: New test.
---
 gcc/config/riscv/riscv.cc |  2 +-
 .../gcc.target/riscv/xtheadbb-li-rotr.c   | 34 +++
 2 files changed, 35 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 2db9c81ac8b..ef63079de8e 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -566,7 +566,7 @@ riscv_build_integer_1 (struct riscv_integer_op 
codes[RISCV_MAX_INTEGER_OPS],
}
 }
 
-  if (cost > 2 && TARGET_64BIT && TARGET_ZBB)
+  if (cost > 2 && TARGET_64BIT && (TARGET_ZBB || TARGET_XTHEADBB))
 {
   int leading_ones = clz_hwi (~value);
   int trailing_ones = ctz_hwi (~value);
diff --git a/gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c 
b/gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c
new file mode 100644
index 000..ecd50448d77
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c
@@ -0,0 +1,34 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gc_xtheadbb" } */
+
+long
+li_rori (void)
+{
+  return 0x77ffL;
+}
+
+long
+li_rori_2 (void)
+{
+  return 0x77ffL;
+}
+
+long
+li_rori_3 (void)
+{
+  return 0xfffeefffL;
+}
+
+long
+li_rori_4 (void)
+{
+  return 0x5ff5L;
+}
+
+long
+li_rori_5 (void)
+{
+  return 0xaffaL;
+}
+
+/* { dg-final { scan-assembler-times "th.srri\t" 5 } } */
-- 
2.41.0

Re: [Patch] contrib/gcc-changelog: Check whether revert-commit exists

[Arsen Arsenović via Gcc-patches]

Tobias Burnus  writes:

> Attached an old patch. See attached patch for the current one.
>
> Difference is one line: the warning that is shown in the example output
> below.

Python-wise, the changes seem fine.  Unsure if it does the right thing,
though, since I'm not familiar with the full script.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

[Committed] RISC-V: zicond: Fix opt2 pattern

[Vineet Gupta]

Fixes: 1d5bc3285e8a ("[committed][RISC-V] Fix 20010221-1.c with zicond")

This was tripping up gcc.c-torture/execute/pr60003.c at -O1 since in
failing case, pattern semantics were not matching with asm czero.nez

We start with the following src code snippet:

  if (a == 0)
return 0;
  else
return x;
}

which is equivalent to:  "x = (a != 0) ? x : a" where x is NOT 0.


and matches define_insn "*czero.nez..opt2"

| (insn 41 20 38 3 (set (reg/v:DI 136 [ x ])
|(if_then_else:DI (ne (reg/v:DI 134 [ a ])
|(const_int 0 [0]))
|(reg/v:DI 136 [ x ])
|(reg/v:DI 134 [ a ]))) {*czero.nez.didi.opt2}

The corresponding asm pattern generates
czero.nez x, x, a   ; %0, %2, %1

which implies
"x = (a != 0) ? 0 : a"

clearly not what the pattern wants to do.

Essentially "(a != 0) ? x : a" cannot be expressed with CZERO.nez if X
is not guaranteed to be 0.

However this can be fixed with a small tweak

"x = (a != 0) ? x : a"

   is same as

"x = (a == 0) ? a : x"

and since middle operand is 0 when a == 0, it is equivalent to

"x = (a == 0) ? 0 : x"

which can be expressed with CZERO.eqz

before fix  after fix
-   -
lia5,1  lia5,1
lda4,8(sp)  lda4,8(sp)
czero.nez a0,a4,a5  czero.eqz a0,a4,a5

The issue only happens at -O1 as at higher optimization levels, the
whole conditional move gets optimized away.

This fixes 4 testsuite failues in a zicond build:

FAIL: gcc.c-torture/execute/pr60003.c   -O1  execution test
FAIL: gcc.dg/setjmp-3.c execution test
FAIL: gcc.dg/torture/stackalign/setjmp-3.c   -O1  execution test
FAIL: gcc.dg/torture/stackalign/setjmp-3.c   -O1 -fpic execution test

gcc/ChangeLog:
* config/riscv/zicond.md: Fix op2 pattern.

Signed-off-by: Vineet Gupta 
---
 gcc/config/riscv/zicond.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/riscv/zicond.md b/gcc/config/riscv/zicond.md
index 4619220ef8ac..1721e1011ea8 100644
--- a/gcc/config/riscv/zicond.md
+++ b/gcc/config/riscv/zicond.md
@@ -60,7 +60,7 @@
   (match_operand:GPR 2 "register_operand" "r")
   (match_operand:GPR 3 "register_operand" "1")))]
   "TARGET_ZICOND && rtx_equal_p (operands[1], operands[3])"
-  "czero.nez\t%0,%2,%1"
+  "czero.eqz\t%0,%2,%1"
 )
 
 ;; Combine creates this form in some cases (particularly the coremark
-- 
2.34.1

Re: [PATCH 10/11] aarch64: Fix branch-protection error message tests

[Richard Sandiford via Gcc-patches]

Szabolcs Nagy  writes:
> Update tests for the new branch-protection parser errors.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.target/aarch64/branch-protection-attr.c: Update.
>   * gcc.target/aarch64/branch-protection-option.c: Update.

OK, thanks.  (And I agree these are better messages. :))

I think that's the last of the AArch64-specific ones.  The others
will need to be reviewed by Kyrill or Richard.

Richard

> ---
>  gcc/testsuite/gcc.target/aarch64/branch-protection-attr.c   | 6 +++---
>  gcc/testsuite/gcc.target/aarch64/branch-protection-option.c | 2 +-
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/aarch64/branch-protection-attr.c 
> b/gcc/testsuite/gcc.target/aarch64/branch-protection-attr.c
> index 272000c2747..dae2a758a56 100644
> --- a/gcc/testsuite/gcc.target/aarch64/branch-protection-attr.c
> +++ b/gcc/testsuite/gcc.target/aarch64/branch-protection-attr.c
> @@ -4,19 +4,19 @@ void __attribute__ ((target("branch-protection=leaf")))
>  foo1 ()
>  {
>  }
> -/* { dg-error {invalid protection type 'leaf' in 
> 'target\("branch-protection="\)' pragma or attribute} "" { target *-*-* } 5 } 
> */
> +/* { dg-error {invalid argument 'leaf' for 'target\("branch-protection="\)'} 
> "" { target *-*-* } 5 } */
>  /* { dg-error {pragma or attribute 'target\("branch-protection=leaf"\)' is 
> not valid} "" { target *-*-* } 5 } */
>  
>  void __attribute__ ((target("branch-protection=none+pac-ret")))
>  foo2 ()
>  {
>  }
> -/* { dg-error "unexpected 'pac-ret' after 'none'" "" { target *-*-* } 12 } */
> +/* { dg-error {argument 'none' can only appear alone in 
> 'target\("branch-protection="\)'} "" { target *-*-* } 12 } */
>  /* { dg-error {pragma or attribute 
> 'target\("branch-protection=none\+pac-ret"\)' is not valid} "" { target *-*-* 
> } 12 } */
>  
>  void __attribute__ ((target("branch-protection=")))
>  foo3 ()
>  {
>  }
> -/* { dg-error {missing argument to 'target\("branch-protection="\)' pragma 
> or attribute} "" { target *-*-* } 19 } */
> +/* { dg-error {invalid argument '' for 'target\("branch-protection="\)'} "" 
> { target *-*-* } 19 } */
>  /* { dg-error {pragma or attribute 'target\("branch-protection="\)' is not 
> valid} "" { target *-*-* } 19 } */
> diff --git a/gcc/testsuite/gcc.target/aarch64/branch-protection-option.c 
> b/gcc/testsuite/gcc.target/aarch64/branch-protection-option.c
> index 1b3bf4ee2b8..e2f847a31c4 100644
> --- a/gcc/testsuite/gcc.target/aarch64/branch-protection-option.c
> +++ b/gcc/testsuite/gcc.target/aarch64/branch-protection-option.c
> @@ -1,4 +1,4 @@
>  /* { dg-do "compile" } */
>  /* { dg-options "-mbranch-protection=leaf -mbranch-protection=none+pac-ret" 
> } */
>  
> -/* { dg-error "unexpected 'pac-ret' after 'none'"  "" { target *-*-* } 0 } */
> +/* { dg-error "argument 'none' can only appear alone in 
> '-mbranch-protection='" "" { target *-*-* } 0 } */

Re: [PATCH] c++: improve verify_constant diagnostic [PR91483]

[Jason Merrill via Gcc-patches]

On 9/1/23 20:00, Marek Polacek wrote:

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

-- >8 --

When verify_constant complains, it's pretty terse.  Consider

   void test ()
   {
 constexpr int i = 42;
 constexpr const int *p = 
   }

where it says "'& i' is not a constant expression".  OK, but why?

With this patch, we say:

b.C:5:28: error: '& i' is not a constant expression
 5 |   constexpr const int *p = 
   |^~
b.C:5:28: note: pointer to 'i' is not a constant expression
b.C:4:17: note: address of non-static constexpr variable 'i' may differ on each 
invocation of the enclosing function; add 'static' to give it a constant address
 4 |   constexpr int i = 42;
   | ^
   | static

which brings g++ on par with clang++.

gcc/cp/ChangeLog:

* constexpr.cc (verify_constant_explain_r): New.
(verify_constant): Call it.

gcc/testsuite/ChangeLog:

* g++.dg/diagnostic/constexpr3.C: New test.
---
  gcc/cp/constexpr.cc  | 56 +++-
  gcc/testsuite/g++.dg/diagnostic/constexpr3.C | 32 +++
  2 files changed, 87 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/diagnostic/constexpr3.C

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index 8bd5c4a47f8..6d5aed82377 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -3381,6 +3381,54 @@ ok:
  }
  }
  
+/* *TP was not deemed constant by reduced_constant_expression_p.  Explain

+   why and suggest what could be done about it.  */
+
+static tree
+verify_constant_explain_r (tree *tp, int *, void *)
+{
+  bool ref_p = false;


I think you'll want something along the lines of

  /* No need to look into types or unevaluated operands.  */
  if (TYPE_P (init) || unevaluated_p (code))
{
  *walk_subtrees = false;
  return NULL_TREE;
}

(from find_uninit_fields_r).

OK with that change.

Jason

Re: [PATCH 07/11] aarch64: Disable branch-protection for pcs tests

[Richard Sandiford via Gcc-patches]

Szabolcs Nagy  writes:
> The tests manipulate the return address in abitest-2.h and thus not
> compatible with -mbranch-protection=pac-ret+leaf or
> -mbranch-protection=gcs.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.target/aarch64/aapcs64/func-ret-1.c: Disable branch-protection.
>   * gcc.target/aarch64/aapcs64/func-ret-2.c: Likewise.
>   * gcc.target/aarch64/aapcs64/func-ret-3.c: Likewise.
>   * gcc.target/aarch64/aapcs64/func-ret-4.c: Likewise.
>   * gcc.target/aarch64/aapcs64/func-ret-64x1_1.c: Likewise.

OK, thanks.

Richard

> ---
>  gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-1.c  | 1 +
>  gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-2.c  | 1 +
>  gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-3.c  | 1 +
>  gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-4.c  | 1 +
>  gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-64x1_1.c | 1 +
>  5 files changed, 5 insertions(+)
>
> diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-1.c 
> b/gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-1.c
> index 5405e1e4920..7bd7757efe6 100644
> --- a/gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-1.c
> +++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-1.c
> @@ -4,6 +4,7 @@
> AAPCS64 \S 4.1.  */
>  
>  /* { dg-do run { target aarch64*-*-* } } */
> +/* { dg-additional-options "-mbranch-protection=none" } */
>  /* { dg-additional-sources "abitest.S" } */
>  
>  #ifndef IN_FRAMEWORK
> diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-2.c 
> b/gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-2.c
> index 6b171c46fbb..85a822ace4a 100644
> --- a/gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-2.c
> +++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-2.c
> @@ -4,6 +4,7 @@
> Homogeneous floating-point aggregate types are covered in func-ret-3.c.  
> */
>  
>  /* { dg-do run { target aarch64*-*-* } } */
> +/* { dg-additional-options "-mbranch-protection=none" } */
>  /* { dg-additional-sources "abitest.S" } */
>  
>  #ifndef IN_FRAMEWORK
> diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-3.c 
> b/gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-3.c
> index ad312b675b9..1d35ebf14b4 100644
> --- a/gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-3.c
> +++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-3.c
> @@ -4,6 +4,7 @@
> in AAPCS64 \S 4.3.5.  */
>  
>  /* { dg-do run { target aarch64-*-* } } */
> +/* { dg-additional-options "-mbranch-protection=none" } */
>  /* { dg-additional-sources "abitest.S" } */
>  /* { dg-require-effective-target aarch64_big_endian } */
>  
> diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-4.c 
> b/gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-4.c
> index af05fbe9fdf..15e1408c62d 100644
> --- a/gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-4.c
> +++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-4.c
> @@ -5,6 +5,7 @@
> are treated as general composite types.  */
>  
>  /* { dg-do run { target aarch64*-*-* } } */
> +/* { dg-additional-options "-mbranch-protection=none" } */
>  /* { dg-additional-sources "abitest.S" } */
>  /* { dg-require-effective-target aarch64_big_endian } */
>  
> diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-64x1_1.c 
> b/gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-64x1_1.c
> index 05957e2dcae..fe7bbb6a835 100644
> --- a/gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-64x1_1.c
> +++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/func-ret-64x1_1.c
> @@ -3,6 +3,7 @@
>Test 64-bit singleton vector types which should be in FP/SIMD registers.  
> */
>  
>  /* { dg-do run { target aarch64*-*-* } } */
> +/* { dg-additional-options "-mbranch-protection=none" } */
>  /* { dg-additional-sources "abitest.S" } */
>  
>  #ifndef IN_FRAMEWORK

Re: [PATCH 06/11] aarch64: Fix pac-ret eh_return tests

[Richard Sandiford via Gcc-patches]

Szabolcs Nagy  writes:
> This is needed since eh_return no longer prevents pac-ret in the
> normal return path.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.target/aarch64/return_address_sign_1.c: Move func4 to ...
>   * gcc.target/aarch64/return_address_sign_2.c: ... here and fix the
>   scan asm check.
>   * gcc.target/aarch64/return_address_sign_b_1.c: Move func4 to ...
>   * gcc.target/aarch64/return_address_sign_b_2.c: ... here and fix the
>   scan asm check.
> ---
>  .../gcc.target/aarch64/return_address_sign_1.c  | 13 +
>  .../gcc.target/aarch64/return_address_sign_2.c  | 17 +++--
>  .../aarch64/return_address_sign_b_1.c   | 11 ---
>  .../aarch64/return_address_sign_b_2.c   | 17 +++--
>  4 files changed, 31 insertions(+), 27 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/aarch64/return_address_sign_1.c 
> b/gcc/testsuite/gcc.target/aarch64/return_address_sign_1.c
> index 232ba67ade0..114a9dacb3f 100644
> --- a/gcc/testsuite/gcc.target/aarch64/return_address_sign_1.c
> +++ b/gcc/testsuite/gcc.target/aarch64/return_address_sign_1.c
> @@ -37,16 +37,5 @@ func3 (int a, int b, int c)
>/* autiasp */
>  }
>  
> -/* eh_return.  */
> -void __attribute__ ((target ("arch=armv8.3-a")))
> -func4 (long offset, void *handler, int *ptr, int imm1, int imm2)
> -{
> -  /* no paciasp */
> -  *ptr = imm1 + foo (imm1) + imm2;
> -  __builtin_eh_return (offset, handler);
> -  /* no autiasp */
> -  return;
> -}
> -
> -/* { dg-final { scan-assembler-times "autiasp" 3 } } */
>  /* { dg-final { scan-assembler-times "paciasp" 3 } } */
> +/* { dg-final { scan-assembler-times "autiasp" 3 } } */

I suppose there is no normal return path here.  I don't know how quickly
we'd realise that though, in the sense that the flag register becomes known-1.
But a quick-and-dirty check would be whether the exit block has a single
predecessor, which in a function that calls eh_return should mean
that the eh_return is unconditional.

But that might not be worth worrying about, given the builtin's limited
use case.  And even if it is worth worrying about, keeping the test in
this file would mix correctness with optimisation, which isn't a good
thing for scan-assembler-times.

So yeah, I agree this is OK.  It should probably be part of 03 though,
so that no individual commit causes a regression.

Thanks,
Richard

> diff --git a/gcc/testsuite/gcc.target/aarch64/return_address_sign_2.c 
> b/gcc/testsuite/gcc.target/aarch64/return_address_sign_2.c
> index a4bc5b45333..d93492c3c43 100644
> --- a/gcc/testsuite/gcc.target/aarch64/return_address_sign_2.c
> +++ b/gcc/testsuite/gcc.target/aarch64/return_address_sign_2.c
> @@ -14,5 +14,18 @@ func1 (int a, int b, int c)
>/* retaa */
>  }
>  
> -/* { dg-final { scan-assembler-times "paciasp" 1 } } */
> -/* { dg-final { scan-assembler-times "retaa" 1 } } */
> +/* eh_return.  */
> +void __attribute__ ((target ("arch=armv8.3-a")))
> +func4 (long offset, void *handler, int *ptr, int imm1, int imm2)
> +{
> +  /* paciasp */
> +  *ptr = imm1 + foo (imm1) + imm2;
> +  if (handler)
> +/* br */
> +__builtin_eh_return (offset, handler);
> +  /* retaa */
> +  return;
> +}
> +
> +/* { dg-final { scan-assembler-times "paciasp" 2 } } */
> +/* { dg-final { scan-assembler-times "retaa" 2 } } */
> diff --git a/gcc/testsuite/gcc.target/aarch64/return_address_sign_b_1.c 
> b/gcc/testsuite/gcc.target/aarch64/return_address_sign_b_1.c
> index 43e32ab6cb7..697fa30dc5a 100644
> --- a/gcc/testsuite/gcc.target/aarch64/return_address_sign_b_1.c
> +++ b/gcc/testsuite/gcc.target/aarch64/return_address_sign_b_1.c
> @@ -37,16 +37,5 @@ func3 (int a, int b, int c)
>/* autibsp */
>  }
>  
> -/* eh_return.  */
> -void __attribute__ ((target ("arch=armv8.3-a")))
> -func4 (long offset, void *handler, int *ptr, int imm1, int imm2)
> -{
> -  /* no pacibsp */
> -  *ptr = imm1 + foo (imm1) + imm2;
> -  __builtin_eh_return (offset, handler);
> -  /* no autibsp */
> -  return;
> -}
> -
>  /* { dg-final { scan-assembler-times "pacibsp" 3 } } */
>  /* { dg-final { scan-assembler-times "autibsp" 3 } } */
> diff --git a/gcc/testsuite/gcc.target/aarch64/return_address_sign_b_2.c 
> b/gcc/testsuite/gcc.target/aarch64/return_address_sign_b_2.c
> index 9ed64ce0591..748924c72f3 100644
> --- a/gcc/testsuite/gcc.target/aarch64/return_address_sign_b_2.c
> +++ b/gcc/testsuite/gcc.target/aarch64/return_address_sign_b_2.c
> @@ -14,5 +14,18 @@ func1 (int a, int b, int c)
>/* retab */
>  }
>  
> -/* { dg-final { scan-assembler-times "pacibsp" 1 } } */
> -/* { dg-final { scan-assembler-times "retab" 1 } } */
> +/* eh_return.  */
> +void __attribute__ ((target ("arch=armv8.3-a")))
> +func4 (long offset, void *handler, int *ptr, int imm1, int imm2)
> +{
> +  /* paciasp */
> +  *ptr = imm1 + foo (imm1) + imm2;
> +  if (handler)
> +/* br */
> +__builtin_eh_return (offset, handler);
> +  /* retab */
> +  return;
> +}
> +
> +/* { dg-final { 

[committed] OpenMP: Avoid ICE in c_parser_omp_clause_allocate with invalid expr

[Tobias Burnus]

I encountered an ICE when playing around. As allocate clauses
are a bit separate from the allocate directive, I decided to
fix it separately.

Note: The check also handles alignment expression (no testcases)
and C++ already checked for error_mark_node, i.e. it wasn't affected.

Committed as Rev. r14-3711-g55243898f8f956

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
commit 55243898f8f9560371f258fe0c6ca202ab7b2085
Author: Tobias Burnus 
Date:   Tue Sep 5 14:57:01 2023 +0200

OpenMP: Avoid ICE in c_parser_omp_clause_allocate with invalid expr

gcc/c/ChangeLog:

* c-parser.cc (c_parser_omp_clause_allocate): Handle
error_mark_node.

gcc/testsuite/ChangeLog:

* c-c++-common/gomp/allocate-13.c: New test.
---
 gcc/c/c-parser.cc |  4 +++-
 gcc/testsuite/c-c++-common/gomp/allocate-13.c | 28 +++
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index cae10ba9c80..c8d285fbda1 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -16676,7 +16676,9 @@ c_parser_omp_clause_allocate (c_parser *parser, tree list)
 	  location_t expr_loc = c_parser_peek_token (parser)->location;
 	  c_expr expr = c_parser_expr_no_commas (parser, NULL);
 	  expr = convert_lvalue_to_rvalue (expr_loc, expr, false, true);
-	  if (strcmp (p, "allocator") == 0)
+	  if (expr.value == error_mark_node)
+		;
+	  else if (strcmp (p, "allocator") == 0)
 		{
 		  allocator = expr.value;
 		  allocator = c_fully_fold (allocator, false, NULL);
diff --git a/gcc/testsuite/c-c++-common/gomp/allocate-13.c b/gcc/testsuite/c-c++-common/gomp/allocate-13.c
new file mode 100644
index 000..847fe55ea2a
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/gomp/allocate-13.c
@@ -0,0 +1,28 @@
+typedef enum omp_allocator_handle_t
+#if __cplusplus >= 201103L
+: __UINTPTR_TYPE__
+#endif
+{
+  omp_null_allocator = 0,
+  omp_default_mem_alloc = 1,
+  omp_large_cap_mem_alloc = 2,
+  omp_const_mem_alloc = 3,
+  omp_high_bw_mem_alloc = 4,
+  omp_low_lat_mem_alloc = 5,
+  omp_cgroup_mem_alloc = 6,
+  omp_pteam_mem_alloc = 7,
+  omp_thread_mem_alloc = 8,
+  __omp_allocator_handle_t_max__ = __UINTPTR_MAX__
+} omp_allocator_handle_t;
+
+void
+f ()
+{
+  int i;
+  #pragma omp parallel firstprivate(i) \
+allocate(allocator(omp_low_latency_mem_alloc): i)
+/* { dg-error "'omp_low_latency_mem_alloc' undeclared \\(first use in this function\\); did you mean 'omp_low_lat_mem_alloc'\\\?" "" { target c } .-1 } */
+/* { dg-error "'omp_low_latency_mem_alloc' was not declared in this scope; did you mean 'omp_low_lat_mem_alloc'\\\?" "" { target c++ } .-2 } */
+/* { dg-note "each undeclared identifier is reported only once for each function it appears in" "" { target c } .-3 } */
+   i = 4;
+}

Re: [PATCH] c++: Move consteval folding to cp_fold_r

[Jason Merrill via Gcc-patches]

On 9/1/23 13:23, Marek Polacek wrote:

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

-- >8 --

In the review of P2564:

it turned out that in order to correctly handle an example in the paper,
we should stop doing immediate evaluation in build_over_call and
bot_replace, and instead do it in cp_fold_r.  This patch does that.

Another benefit is that this is a pretty significant simplification, at
least in my opinion.  Also, this fixes the c++/110997 ICE (but the test
doesn't compile yet).

The main drawback seems to be that cp_fold_r doesn't process as much
code as we did before: uninstantiated templates


That's acceptable, it's an optional diagnostic.


and things like "false ? foo () : 1".


This is a problem.  Maybe we want cp_fold_r to recurse into the arms of 
a COND_EXPR before folding them away?  Maybe only if we know we've seen 
an immediate function?



diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index 8bd5c4a47f8..af4f98b1fe1 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -3135,6 +3135,11 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree 
t,
  unsigned save_heap_alloc_count = ctx->global->heap_vars.length ();
  unsigned save_heap_dealloc_count = ctx->global->heap_dealloc_count;
  
+	  /* Make sure we fold std::is_constant_evaluated to true in an

+immediate function.  */
+ if (immediate_invocation_p (fun))


I think this should just check DECL_IMMEDIATE_FUNCTION_P, the context 
doesn't matter.



+   call_ctx.manifestly_const_eval = mce_true;
+
diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc
index 206e791fcfd..29132aad158 100644
--- a/gcc/cp/cp-gimplify.cc
+++ b/gcc/cp/cp-gimplify.cc
@@ -1058,9 +1058,21 @@ cp_fold_r (tree *stmt_p, int *walk_subtrees, void *data_)
}
break;
  
+/* Expand immediate invocations.  */

+case CALL_EXPR:
+case AGGR_INIT_EXPR:
+  if (!in_immediate_context ())


As you mentioned in your followup, we shouldn't need to check this 
because we don't call cp_fold_r in immediate context.



+   if (tree fn = cp_get_callee (stmt))
+ if (TREE_CODE (fn) != ADDR_EXPR || ADDR_EXPR_DENOTES_CALL_P (fn))
+   if (tree fndecl = cp_get_fndecl_from_callee (fn, /*fold*/false))
+ if (DECL_IMMEDIATE_FUNCTION_P (fndecl))
+   *stmt_p = stmt = cxx_constant_value (stmt);
+  break;
+
  case ADDR_EXPR:
if (TREE_CODE (TREE_OPERAND (stmt, 0)) == FUNCTION_DECL
- && DECL_IMMEDIATE_FUNCTION_P (TREE_OPERAND (stmt, 0)))
+ && DECL_IMMEDIATE_FUNCTION_P (TREE_OPERAND (stmt, 0))
+ && !in_immediate_context ())


Likewise.


diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc
index 799183dc646..7dfb6de2da3 100644
--- a/gcc/cp/tree.cc
+++ b/gcc/cp/tree.cc
@@ -3254,7 +3254,7 @@ bot_manip (tree* tp, int* walk_subtrees, void* data_)
 variables.  */
  
  static tree

-bot_replace (tree* t, int* walk_subtrees, void* data_)
+bot_replace (tree* t, int*, void* data_)


Generally we keep the parameter name as a comment like
int */*walk_subtrees*/


diff --git a/gcc/testsuite/g++.dg/cpp23/consteval-if2.C 
b/gcc/testsuite/g++.dg/cpp23/consteval-if2.C
index d1845da9e58..9fa95295c43 100644
--- a/gcc/testsuite/g++.dg/cpp23/consteval-if2.C
+++ b/gcc/testsuite/g++.dg/cpp23/consteval-if2.C
@@ -65,7 +65,7 @@ qux (int x)
int r = 0;
if not consteval// { dg-warning "'if consteval' only available with" "" 
{ target c++20_only } }
  {
-  r += foo (x);// { dg-error "'x' is not a constant expression" }
+  r += foo (x);// { dg-error "'x' is not a constant expression" "" { 
xfail *-*-* } }


This whole function should have a comment that these errors are not 
required because qux is never instantiated.



diff --git a/gcc/testsuite/g++.dg/cpp2a/consteval11.C 
b/gcc/testsuite/g++.dg/cpp2a/consteval11.C
index 2f68ec0f892..9fd32dcab7b 100644
--- a/gcc/testsuite/g++.dg/cpp2a/consteval11.C
+++ b/gcc/testsuite/g++.dg/cpp2a/consteval11.C
@@ -5,25 +5,25 @@ consteval int bar (int i) { if (i != 1) throw 1; return 0; }  // { 
dg-error "is n
  
  constexpr int a = bar (1);

  constexpr int b = bar (2);// { dg-message "in 'constexpr' expansion 
of" }
-constexpr int c = 0 ? bar (3) : 1; // { dg-message "in 'constexpr' expansion 
of" }
+constexpr int c = 0 ? bar (3) : 1;


As discussed above, we need to keep this diagnostic and the others like it.

Let's also add a test with the

template 
constexpr bool is_not(T t, F f) {
return not f(t);
}

consteval bool is_even(int i) { return i % 2 == 0; }

static_assert(is_not(5, is_even)); // ok

example from the paper.

Jason

Re: [Patch] contrib/gcc-changelog: Check whether revert-commit exists

[Tobias Burnus]

Attached an old patch. See attached patch for the current one.

Difference is one line: the warning that is shown in the example output
below.

On 05.09.23 16:37, Tobias Burnus wrote:

That's based on the fail
https://gcc.gnu.org/pipermail/gccadmin/2023q3/020349.html
and on the discussion on IRC.

The problem in for the cron job was that
r14-3661-g084a7cf9fb2d9cb98dfbe7d91602c840ec50b002
referenced a commit that did not exist.

This was temporarily fixed by Jakub, but it makes sense to detect this
in the pre-commit hook.


With the patch,
  contrib/gcc-changelog/git_email.py
0001-Revert-libstdc-Use-GLIBCXX_CHECK_LINKER_FEATURES-for.patch
now prints:
OK
Warnings:
Cannot obtain info about reverted commit
'46c2e94ca66ed9991c45a6ba6204ed02869efc39'

while
  contrib/gcc-changelog/git_check_commit.py
084a7cf9fb2d9cb98dfbe7d91602c840ec50b002
now fails with:
  Checking 084a7cf9fb2d9cb98dfbe7d91602c840ec50b002: FAILED
  ERR: Cannot find to-be-reverted commit:
"46c2e94ca66ed9991c45a6ba6204ed02869efc39"

(check_email.py always shows the warning, git_check_commit.py only
with '-v')

Notes:
- I am not sure whether a sensible testcase can be added - and, hence,
I have not added one.
- I have run "pytest-3' but my python is too old and thus might miss
some checks which
  newer pytest/flake8 will find. But at least it did pass here.
- I have not tested the cherry-pick + commit does not exist case,
  which now creates a warning as I did not quickly find a testcase.

Comments, remarks, suggestions, approval?

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
contrib/gcc-changelog: Check whether revert-commit exists

contrib/ChangeLog:

	* gcc-changelog/git_commit.py (GitCommit.__init__):
	Handle commit_to_info_hook = None; otherwise, if None,
	regard it as error.
	(to_changelog_entries): Handle commit_to_info_hook = None;
	if info is None, create a warning for it.
	* gcc-changelog/git_email.py (GitEmail.__init__):
	call super() with commit_to_info_hook=None instead
	of a lamda function.

 contrib/gcc-changelog/git_commit.py | 14 +-
 contrib/gcc-changelog/git_email.py  |  3 +--
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/contrib/gcc-changelog/git_commit.py b/contrib/gcc-changelog/git_commit.py
index 4f3131021f2..99e40c3c0d4 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -329,11 +329,14 @@ class GitCommit:
 self.revert_commit = m.group('hash')
 break
 if self.revert_commit:
+# The following happens for get_email.py:
+if not self.commit_to_info_hook:
+self.warnings.append(f"Cannot obtain info about reverted commit '{self.revert_commit}'")
+return
 self.info = self.commit_to_info_hook(self.revert_commit)
-
-# The following happens for get_email.py:
-if not self.info:
-return
+if not self.info:
+self.errors.append(Error('Cannot find to-be-reverted commit', self.revert_commit))
+return
 
 self.check_commit_email()
 
@@ -796,12 +799,14 @@ class GitCommit:
 orig_date = self.original_info.date
 current_timestamp = orig_date.strftime(DATE_FORMAT)
 elif self.cherry_pick_commit:
-info = self.commit_to_info_hook(self.cherry_pick_commit)
+info = (self.commit_to_info_hook
+and self.commit_to_info_hook(self.cherry_pick_commit))
 # it can happen that it is a cherry-pick for a different
 # repository
 if info:
 timestamp = info.date.strftime(DATE_FORMAT)
 else:
+self.warnings.append(f"Cherry-picked commit not found: '{self.cherry_pick_commit}'")
 timestamp = current_timestamp
 elif not timestamp or use_commit_ts:
 timestamp = current_timestamp
diff --git a/contrib/gcc-changelog/git_email.py b/contrib/gcc-changelog/git_email.py
index 49f41f2ec99..93808dfabb6 100755
--- a/contrib/gcc-changelog/git_email.py
+++ b/contrib/gcc-changelog/git_email.py
@@ -89,8 +89,7 @@ class GitEmail(GitCommit):
 t = 'M'
 modified_files.append((target if t != 'D' else source, t))
 git_info = GitInfo(None, date, author, message, modified_files)
-super().__init__(git_info,
- commit_to_info_hook=lambda x: None)
+super().__init__(git_info, commit_to_info_hook=None)
 
 
 def show_help():

Re: [PATCH 05/11] aarch64: Add eh_return compile tests

[Richard Sandiford via Gcc-patches]

Szabolcs Nagy  writes:
> gcc/testsuite/ChangeLog:
>
>   * gcc.target/aarch64/eh_return-2.c: New test.
>   * gcc.target/aarch64/eh_return-3.c: New test.

OK.

I wonder if it's worth using check-function-bodies for -3.c though.
It would then be easy to verify that the autiasp only occurs on the
normal return path.

Just a suggestion -- the current test is fine too.

Thanks,
Richard

> ---
>  gcc/testsuite/gcc.target/aarch64/eh_return-2.c |  9 +
>  gcc/testsuite/gcc.target/aarch64/eh_return-3.c | 14 ++
>  2 files changed, 23 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/aarch64/eh_return-2.c
>  create mode 100644 gcc/testsuite/gcc.target/aarch64/eh_return-3.c
>
> diff --git a/gcc/testsuite/gcc.target/aarch64/eh_return-2.c 
> b/gcc/testsuite/gcc.target/aarch64/eh_return-2.c
> new file mode 100644
> index 000..4a9d124e891
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/eh_return-2.c
> @@ -0,0 +1,9 @@
> +/* { dg-do compile } */
> +/* { dg-final { scan-assembler "add\tsp, sp, x5" } } */
> +/* { dg-final { scan-assembler "br\tx6" } } */
> +
> +void
> +foo (unsigned long off, void *handler)
> +{
> +  __builtin_eh_return (off, handler);
> +}
> diff --git a/gcc/testsuite/gcc.target/aarch64/eh_return-3.c 
> b/gcc/testsuite/gcc.target/aarch64/eh_return-3.c
> new file mode 100644
> index 000..35989eee806
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/eh_return-3.c
> @@ -0,0 +1,14 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -mbranch-protection=pac-ret+leaf" } */
> +/* { dg-final { scan-assembler "add\tsp, sp, x5" } } */
> +/* { dg-final { scan-assembler "br\tx6" } } */
> +/* { dg-final { scan-assembler "hint\t25 // paciasp" } } */
> +/* { dg-final { scan-assembler "hint\t29 // autiasp" } } */
> +
> +void
> +foo (unsigned long off, void *handler, int c)
> +{
> +  if (c)
> +return;
> +  __builtin_eh_return (off, handler);
> +}

[Patch] contrib/gcc-changelog: Check whether revert-commit exists

[Tobias Burnus]

That's based on the fail 
https://gcc.gnu.org/pipermail/gccadmin/2023q3/020349.html
and on the discussion on IRC.

The problem in for the cron job was that 
r14-3661-g084a7cf9fb2d9cb98dfbe7d91602c840ec50b002
referenced a commit that did not exist.

This was temporarily fixed by Jakub, but it makes sense to detect this
in the pre-commit hook.


With the patch,
  contrib/gcc-changelog/git_email.py 
0001-Revert-libstdc-Use-GLIBCXX_CHECK_LINKER_FEATURES-for.patch
now prints:
OK
Warnings:
Cannot obtain info about reverted commit 
'46c2e94ca66ed9991c45a6ba6204ed02869efc39'

while
  contrib/gcc-changelog/git_check_commit.py 
084a7cf9fb2d9cb98dfbe7d91602c840ec50b002
now fails with:
  Checking 084a7cf9fb2d9cb98dfbe7d91602c840ec50b002: FAILED
  ERR: Cannot find to-be-reverted commit: 
"46c2e94ca66ed9991c45a6ba6204ed02869efc39"

(check_email.py always shows the warning, git_check_commit.py only with '-v')

Notes:
- I am not sure whether a sensible testcase can be added - and, hence, I have 
not added one.
- I have run "pytest-3' but my python is too old and thus might miss some 
checks which
  newer pytest/flake8 will find. But at least it did pass here.
- I have not tested the cherry-pick + commit does not exist case,
  which now creates a warning as I did not quickly find a testcase.

Comments, remarks, suggestions, approval?

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
contrib/gcc-changelog: Check whether revert-commit exists

contrib/ChangeLog:

	* gcc-changelog/git_commit.py (GitCommit.__init__):
	Handle commit_to_info_hook = None; otherwise, if None,
	regard it as error.
	(to_changelog_entries): Handle commit_to_info_hook = None;
	if info is None, create a warning for it.
	* gcc-changelog/git_email.py (GitEmail.__init__):
	call super() with commit_to_info_hook=None instead
	of a lamda function.

 contrib/gcc-changelog/git_commit.py | 14 +-
 contrib/gcc-changelog/git_email.py  |  3 +--
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/contrib/gcc-changelog/git_commit.py b/contrib/gcc-changelog/git_commit.py
index 4f3131021f2..4d024026f2b 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -329,11 +329,13 @@ class GitCommit:
 self.revert_commit = m.group('hash')
 break
 if self.revert_commit:
+# The following happens for get_email.py:
+if not self.commit_to_info_hook:
+return
 self.info = self.commit_to_info_hook(self.revert_commit)
-
-# The following happens for get_email.py:
-if not self.info:
-return
+if not self.info:
+self.errors.append(Error('Cannot find to-be-reverted commit', self.revert_commit))
+return
 
 self.check_commit_email()
 
@@ -796,12 +798,14 @@ class GitCommit:
 orig_date = self.original_info.date
 current_timestamp = orig_date.strftime(DATE_FORMAT)
 elif self.cherry_pick_commit:
-info = self.commit_to_info_hook(self.cherry_pick_commit)
+info = (self.commit_to_info_hook
+and self.commit_to_info_hook(self.cherry_pick_commit))
 # it can happen that it is a cherry-pick for a different
 # repository
 if info:
 timestamp = info.date.strftime(DATE_FORMAT)
 else:
+self.warnings.append(f"Cherry-picked commit not found: '{self.cherry_pick_commit}'")
 timestamp = current_timestamp
 elif not timestamp or use_commit_ts:
 timestamp = current_timestamp
diff --git a/contrib/gcc-changelog/git_email.py b/contrib/gcc-changelog/git_email.py
index 49f41f2ec99..93808dfabb6 100755
--- a/contrib/gcc-changelog/git_email.py
+++ b/contrib/gcc-changelog/git_email.py
@@ -89,8 +89,7 @@ class GitEmail(GitCommit):
 t = 'M'
 modified_files.append((target if t != 'D' else source, t))
 git_info = GitInfo(None, date, author, message, modified_files)
-super().__init__(git_info,
- commit_to_info_hook=lambda x: None)
+super().__init__(git_info, commit_to_info_hook=None)
 
 
 def show_help():

Re: [PATCH 04/11] aarch64: Do not force a stack frame for EH returns

[Richard Sandiford via Gcc-patches]

Szabolcs Nagy  writes:
> EH returns no longer rely on clobbering the return address on the stack
> so forcing a stack frame is not necessary.
>
> This does not actually change the code gen for the unwinder since there
> are calls before the EH return.
>
> gcc/ChangeLog:
>
>   * config/aarch64/aarch64.cc (aarch64_needs_frame_chain): Do not
>   force frame chain for eh_return.

OK once we've agreed on something for 03/11.

Thanks,
Richard

> ---
>  gcc/config/aarch64/aarch64.cc | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
> index 36cd172d182..afdbf4213c1 100644
> --- a/gcc/config/aarch64/aarch64.cc
> +++ b/gcc/config/aarch64/aarch64.cc
> @@ -8417,8 +8417,7 @@ aarch64_output_probe_sve_stack_clash (rtx base, rtx 
> adjustment,
>  static bool
>  aarch64_needs_frame_chain (void)
>  {
> -  /* Force a frame chain for EH returns so the return address is at FP+8.  */
> -  if (frame_pointer_needed || crtl->calls_eh_return)
> +  if (frame_pointer_needed)
>  return true;
>  
>/* A leaf function cannot have calls or write LR.  */

Re: [PATCH 01/11] aarch64: AARCH64_ISA_RCPC was defined twice

[Richard Sandiford via Gcc-patches]

Szabolcs Nagy  writes:
> gcc/ChangeLog:
>
>   * config/aarch64/aarch64.h (AARCH64_ISA_RCPC): Remove dup.

OK, thanks.

Richard

> ---
>  gcc/config/aarch64/aarch64.h | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
> index 2b0fc97bb71..c783cb96c48 100644
> --- a/gcc/config/aarch64/aarch64.h
> +++ b/gcc/config/aarch64/aarch64.h
> @@ -222,7 +222,6 @@ enum class aarch64_feature : unsigned char {
>  #define AARCH64_ISA_MOPS(aarch64_isa_flags & AARCH64_FL_MOPS)
>  #define AARCH64_ISA_LS64(aarch64_isa_flags & AARCH64_FL_LS64)
>  #define AARCH64_ISA_CSSC(aarch64_isa_flags & AARCH64_FL_CSSC)
> -#define AARCH64_ISA_RCPC   (aarch64_isa_flags & AARCH64_FL_RCPC)
>  
>  /* Crypto is an optional extension to AdvSIMD.  */
>  #define TARGET_CRYPTO (AARCH64_ISA_CRYPTO)

Re: testsuite: Port 'check-function-bodies' to nvptx

[Richard Sandiford via Gcc-patches]

Thomas Schwinge  writes:
> Hi!
>
> On 2023-09-04T23:05:05+0200, I wrote:
>> On 2019-07-16T15:04:49+0100, Richard Sandiford  
>> wrote:
>>> This patch therefore adds a new check-function-bodies dg-final test
>
>>> The regexps in parse_function_bodies are fairly general, but might
>>> still need to be extended in future for targets like Darwin or AIX.
>>
>> ..., or nvptx.  [...]
>
>> number of TODO items.
>>
>> In particular how to parameterize regular expressions for the different
>> syntax used by nvptx: for example, parameterize via global variables,
>> initialized accordingly (where?)?  Thinking about it, maybe simply
>> conditionalizing the current local initializations by
>> 'if { [istarget nvptx-*-*] } { [...] } else { [...] }' will do, simple
>> enough!
>
> Indeed that works fine.
>
>> Regarding whitespace prefixed, I think I'll go with the current
>> 'append function_regexp "\t" $line "\n"', that is, prefix expected output
>> lines with '\t' (as done in 'gcc.target/nvptx/abort.c'), and also for
>> nvptx handle labels as "fluff" (until we solve that issue generally).
>
> I changed my mind about that: instead of '\t', use '\t*' for nvptx, which
> means that both instructions emitted with additional whitespace prefixed
> and labels in column zero work nicely.
>
>> --- a/gcc/testsuite/lib/scanasm.exp
>> +++ b/gcc/testsuite/lib/scanasm.exp
>
>> @@ -907,7 +911,8 @@ proc check-function-bodies { args } {
>>
>>  set count 0
>>  set function_regexp ""
>> -set label {^(\S+):$}
>> +#TODO
>> +set label {^// BEGIN GLOBAL FUNCTION DEF: ([a-zA-Z_]\S+)$}
>
> There's actually no reason that the expected output syntax (this one) has
> to match the assembly -- so I restored that, to use the same syntax for
> nvptx here, too.
>
> Any comments before I push the attached
> "testsuite: Port 'check-function-bodies' to nvptx"?
>
>
> Grüße
>  Thomas
>
>
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
> München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
> Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
> München, HRB 106955
>
> From bdaf7572d9d4c1988274405840de4071ded3733f Mon Sep 17 00:00:00 2001
> From: Thomas Schwinge 
> Date: Mon, 4 Sep 2023 22:28:12 +0200
> Subject: [PATCH] testsuite: Port 'check-function-bodies' to nvptx
>
> This extends commit 4d706ff86ea86868615558e92407674a4f4b4af9
> "Add dg test for matching function bodies" for nvptx.
>
>   gcc/testsuite/
>   * lib/scanasm.exp (configure_check-function-bodies): New proc.
>   (parse_function_bodies, check-function-bodies): Use it.
>   * gcc.target/nvptx/abort.c: Use 'check-function-bodies'.
>   gcc/
>   * doc/sourcebuild.texi (check-function-bodies): Update.

LGTM.  Just a minor comment:

> ---
>  gcc/doc/sourcebuild.texi   |  9 ++-
>  gcc/testsuite/gcc.target/nvptx/abort.c | 19 ++-
>  gcc/testsuite/lib/scanasm.exp  | 76 --
>  3 files changed, 83 insertions(+), 21 deletions(-)
>
> diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
> index 1a78b3c1abb..8aec6b6592c 100644
> --- a/gcc/doc/sourcebuild.texi
> +++ b/gcc/doc/sourcebuild.texi
> @@ -3327,9 +3327,12 @@ The first line of the expected output for a function 
> @var{fn} has the form:
>  Subsequent lines of the expected output also start with @var{prefix}.
>  In both cases, whitespace after @var{prefix} is not significant.
>  
> -The test discards assembly directives such as @code{.cfi_startproc}
> -and local label definitions such as @code{.LFB0} from the compiler's
> -assembly output.  It then matches the result against the expected
> +Depending on the configuration (see
> +@code{gcc/testsuite/lib/scanasm.exp:configure_check-function-bodies}),

I can imagine such a long string wouldn't format well in the output.
How about: @code{configure_check-function-bodies} in
@filename{gcc/testsuite/lib/scanasm.exp}?

OK from my POV with that change.

Thanks,
Richard

> +the test may discard from the compiler's assembly output
> +directives such as @code{.cfi_startproc},
> +local label definitions such as @code{.LFB0}, and more.
> +It then matches the result against the expected
>  output for a function as a single regular expression.  This means that
>  later lines can use backslashes to refer back to @samp{(@dots{})}
>  captures on earlier lines.  For example:
> diff --git a/gcc/testsuite/gcc.target/nvptx/abort.c 
> b/gcc/testsuite/gcc.target/nvptx/abort.c
> index d3220687400..ae9dbf45a9b 100644
> --- a/gcc/testsuite/gcc.target/nvptx/abort.c
> +++ b/gcc/testsuite/gcc.target/nvptx/abort.c
> @@ -1,4 +1,6 @@
>  /* { dg-do compile} */
> +/* { dg-final { check-function-bodies {**} {} } } */
> +
>  /* Annotate no return functions with a trailing 'trap'.  */
>  
>  extern void abort ();
> @@ -9,5 +11,18 @@ int main (int argc, char **argv)
>  abort ();
>return 0;
>  }
> -
> -/* { dg-final { scan-assembler "call 

Re: [PATCH] c++, v2: Diagnose [basic.scope.block]/2 violations even in compound-stmt of function-try-block [PR52953]

[Jason Merrill via Gcc-patches]

On 9/1/23 09:24, Jakub Jelinek wrote:

On Thu, Aug 31, 2023 at 03:52:22PM -0400, Jason Merrill wrote:

On 8/31/23 03:20, Jakub Jelinek wrote:

As the following testcase shows, while check_local_shadow diagnoses most of
the [basic.scope.block]/2 violations, it doesn't diagnose when parameter's
name is redeclared inside of the compound-stmt of a function-try-block.

There is in that case an extra scope (sk_try with parent artificial
sk_block with for FUNCTION_NEEDS_BODY_BLOCK another sk_block and only then
sk_function_param).

The following patch fixes that.

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

2023-08-31  Jakub Jelinek  

PR c++/52953
* cp-tree.h (struct language_function): Add x_in_function_try_block
member.


How about adding a flag to cp_binding_level instead?  Maybe to mark the
artificial sk_block level as such, which we could use for both this case and
the FUNCTION_NEEDS_BODY_BLOCK cases.


So like this?

It actually changes behaviour on the
void foo (int x) try {} catch (int x) {} case, where previously
this triggered the
|| (TREE_CODE (old) == PARM_DECL
&& (current_binding_level->kind == sk_catch
|| current_binding_level->level_chain->kind == sk_catch)
&& in_function_try_handler))
 {
   auto_diagnostic_group d;
   if (permerror (DECL_SOURCE_LOCATION (decl),
  "redeclaration of %q#D", decl))
 inform (DECL_SOURCE_LOCATION (old),
 "%q#D previously declared here", old);
diagnostics (note, just the current_binding_level->kind == sk_catch
case), while now it triggers already the earlier
   if (b->kind == sk_function_parms)
 {
   error_at (DECL_SOURCE_LOCATION (decl),
 "declaration of %q#D shadows a parameter", decl);
   inform (DECL_SOURCE_LOCATION (old),
   "%q#D previously declared here", old);
error.  If you think it is important to differentiate that,
I guess I could guard the while (b->artificial) loop with say
+ if (!in_function_try_handler
+ || current_binding_level->kind != sk_catch)
while (b->artificial)
  b = b->level_chain;
and adjust the 2 testcases.


I don't mind the change of diagnostic.  Can we remove the 
in_function_try_handler test, then, if it's no longer reachable?  OK 
with that change.



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

2023-09-01  Jakub Jelinek  

PR c++/52953
* name-lookup.h (struct cp_binding_level): Add artificial bit-field.
Formatting fixes.
* name-lookup.cc (check_local_shadow): Skip artificial bindings when
checking if parameter scope is parent scope.  Don't special case
FUNCTION_NEEDS_BODY_BLOCK.
* decl.cc (begin_function_body): Set
current_binding_level->artificial.
* semantics.cc (begin_function_try_block): Likewise.

* g++.dg/diagnostic/redeclaration-3.C: New test.
* g++.dg/parse/pr31952-3.C: Expect different diagnostic wording.

--- gcc/cp/name-lookup.h.jj 2023-08-21 11:57:33.105460770 +0200
+++ gcc/cp/name-lookup.h2023-09-01 10:15:20.137943395 +0200
@@ -292,11 +292,11 @@ struct GTY(()) cp_binding_level {
only valid if KIND == SK_TEMPLATE_PARMS.  */
BOOL_BITFIELD explicit_spec_p : 1;
  
-  /* true means make a BLOCK for this level regardless of all else.  */

+  /* True means make a BLOCK for this level regardless of all else.  */
unsigned keep : 1;
  
/* Nonzero if this level can safely have additional

-  cleanup-needing variables added to it.  */
+ cleanup-needing variables added to it.  */
unsigned more_cleanups_ok : 1;
unsigned have_cleanups : 1;
  
@@ -308,9 +308,13 @@ struct GTY(()) cp_binding_level {

unsigned defining_class_p : 1;
  
/* True for SK_FUNCTION_PARMS of a requires-expression.  */

-  unsigned requires_expression: 1;
+  unsigned requires_expression : 1;
  
-  /* 22 bits left to fill a 32-bit word.  */

+  /* True for artificial blocks which should be ignored when finding
+ parent scope.  */
+  unsigned artificial : 1;
+
+  /* 21 bits left to fill a 32-bit word.  */
  };
  
  /* The binding level currently in effect.  */

--- gcc/cp/name-lookup.cc.jj2023-08-31 14:31:06.055762306 +0200
+++ gcc/cp/name-lookup.cc   2023-09-01 10:21:03.658118594 +0200
@@ -3146,8 +3146,10 @@ check_local_shadow (tree decl)
 them there.  */
  cp_binding_level *b = current_binding_level->level_chain;
  
-	  if (FUNCTION_NEEDS_BODY_BLOCK (current_function_decl))

-   /* Skip the ctor/dtor cleanup level.  */
+ /* Skip artificially added scopes which aren't present
+in the C++ standard, e.g. for function-try-block or
+ctor/dtor cleanups.  */
+ while 

Re: [PATCH] c++, v2: Diagnose [basic.scope.block]/2 violations even for block externs [PR52953]

[Jason Merrill via Gcc-patches]

On 9/1/23 09:34, Jakub Jelinek wrote:

On Thu, Aug 31, 2023 at 05:46:28PM -0400, Jason Merrill wrote:

I've suggested this to Core.


Thanks.


So, I'm not really sure what to do.  Intuitively the patch seems right
because even block externs redeclare stuff and change meaning of the
identifiers and void foo () { int i; extern int i (int); } is rejected
by all compilers.


I think this direction makes sense, though we might pedwarn on these rather
than error to reduce possible breakage.


It wasn't clear to me whether you want to make those pedwarns just for the
DECL_EXTERNAL cases, ones that actually changed, or all others as well
(which were errors or permerrors depending on the case).
I've implemented the former, kept existing behavior of !DECL_EXTERNAL.


2023-08-31  Jakub Jelinek  

PR c++/52953
* name-lookup.cc (check_local_shadow): Defer punting on
DECL_EXTERNAL (decl) from the start of function to right before
the -Wshadow* checks.


Don't we want to consider externs for the -Wshadow* checks as well?


I think that is a good idea (though dunno how much it will trigger in
real-world), but there is one case I've excluded, the global variable
shadowing case, because warning that
int z;
void foo () { extern int z; z = 1; }
shadows the global var would be incorrect, it is the same var.
It is true that
int y; namespace N { void bar () { extern int y; y = 1; } }
shadows ::y but it is unclear how to differentiate those two cases with
the information we have at check_local_shadow time.

I've also found one spot which wasn't using auto_diagnostic_group d;
on a pair of error_at/inform.

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


OK.


2023-09-01  Jakub Jelinek  

PR c++/52953
* name-lookup.cc (check_local_shadow): Don't punt early for
DECL_EXTERNAL decls, instead just disable the shadowing of namespace
decls check for those and emit a pedwarn rather than error_at for
those.  Add missing auto_diagnostic_group.  Formatting fix.

* g++.dg/diagnostic/redeclaration-4.C: New test.
* g++.dg/diagnostic/redeclaration-5.C: New test.
* g++.dg/warn/Wshadow-19.C: New test.

--- gcc/cp/name-lookup.cc.jj2023-09-01 10:21:03.658118594 +0200
+++ gcc/cp/name-lookup.cc   2023-09-01 11:30:10.868516494 +0200
@@ -3096,10 +3096,6 @@ check_local_shadow (tree decl)
if (TREE_CODE (decl) == PARM_DECL && !DECL_CONTEXT (decl))
  return;
  
-  /* External decls are something else.  */

-  if (DECL_EXTERNAL (decl))
-return;
-
tree old = NULL_TREE;
cp_binding_level *old_scope = NULL;
if (cxx_binding *binding = outer_binding (DECL_NAME (decl), NULL, true))
@@ -3130,11 +3126,9 @@ check_local_shadow (tree decl)
  && DECL_CONTEXT (old) == lambda_function (current_lambda_expr ())
  && TREE_CODE (old) == PARM_DECL
  && DECL_NAME (decl) != this_identifier)
-   {
- error_at (DECL_SOURCE_LOCATION (old),
-   "lambda parameter %qD "
-   "previously declared as a capture", old);
-   }
+   error_at (DECL_SOURCE_LOCATION (old),
+ "lambda parameter %qD "
+ "previously declared as a capture", old);
  return;
}
/* Don't complain if it's from an enclosing function.  */
@@ -3156,10 +3150,18 @@ check_local_shadow (tree decl)
 in the outermost block of the function definition.  */
  if (b->kind == sk_function_parms)
{
- error_at (DECL_SOURCE_LOCATION (decl),
-   "declaration of %q#D shadows a parameter", decl);
- inform (DECL_SOURCE_LOCATION (old),
- "%q#D previously declared here", old);
+ auto_diagnostic_group d;
+ bool emit = true;
+ if (DECL_EXTERNAL (decl))
+   emit = pedwarn (DECL_SOURCE_LOCATION (decl), OPT_Wpedantic,
+   "declaration of %q#D shadows a parameter",
+   decl);
+ else
+   error_at (DECL_SOURCE_LOCATION (decl),
+ "declaration of %q#D shadows a parameter", decl);
+ if (emit)
+   inform (DECL_SOURCE_LOCATION (old),
+   "%q#D previously declared here", old);
  return;
}
}
@@ -3185,10 +3187,16 @@ check_local_shadow (tree decl)
   && (old_scope->kind == sk_cond || old_scope->kind == sk_for))
{
  auto_diagnostic_group d;
- error_at (DECL_SOURCE_LOCATION (decl),
-   "redeclaration of %q#D", decl);
- inform (DECL_SOURCE_LOCATION (old),
- "%q#D previously declared here", old);
+ bool emit = true;
+ if (DECL_EXTERNAL (decl))
+   emit = pedwarn (DECL_SOURCE_LOCATION (decl), OPT_Wpedantic,
+  

[PATCH] c: Don't pedwarn on _FloatN{,x} or {f,F}N{,x} suffixes for C2X

[Jakub Jelinek via Gcc-patches]

Hi!

Now that _Float{16,32,64,128,32x,64x,128x} and
{f,F}{16,32,64,128,32x,64x,128x} literal suffixes are in C23 standard,
I think it is undesirable to pedwarn about these for -std=c2x, so this
patch uses pedwarn_c11 instead.  In c-family/, we don't have that function
and am not sure it would be very clean to define dummy pedwarn_c11 in the
C++ FE, so the patch just does what pedwarn_c11 does using pedwarn/warning.

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

2023-09-05  Jakub Jelinek  

gcc/c-family/
* c-lex.cc (interpret_float): For C diagnostics on FN and FNx suffixes
append " before C2X" to diagnostics text and follow behavior of
pedwarn_c11.
gcc/c/
* c-decl.cc (declspecs_add_type): Use pedwarn_c11 rather than pedwarn
for _FloatN{,x} diagnostics and append " before C2X" to the diagnostic
text.
gcc/testsuite/
* gcc.dg/c11-floatn-1.c: New test.
* gcc.dg/c11-floatn-2.c: New test.
* gcc.dg/c11-floatn-3.c: New test.
* gcc.dg/c11-floatn-4.c: New test.
* gcc.dg/c11-floatn-5.c: New test.
* gcc.dg/c11-floatn-6.c: New test.
* gcc.dg/c11-floatn-7.c: New test.
* gcc.dg/c11-floatn-8.c: New test.
* gcc.dg/c2x-floatn-1.c: New test.
* gcc.dg/c2x-floatn-2.c: New test.
* gcc.dg/c2x-floatn-3.c: New test.
* gcc.dg/c2x-floatn-4.c: New test.
* gcc.dg/c2x-floatn-5.c: New test.
* gcc.dg/c2x-floatn-6.c: New test.
* gcc.dg/c2x-floatn-7.c: New test.
* gcc.dg/c2x-floatn-8.c: New test.

--- gcc/c-family/c-lex.cc.jj2023-09-04 09:45:44.528902928 +0200
+++ gcc/c-family/c-lex.cc   2023-09-05 09:54:29.060725832 +0200
@@ -1185,7 +1185,25 @@ interpret_float (const cpp_token *token,
error ("unsupported non-standard suffix on floating constant");
return error_mark_node;
  }
-   else if (c_dialect_cxx () && !extended)
+   else if (!c_dialect_cxx ())
+ {
+   if (warn_c11_c2x_compat > 0)
+ {
+   if (pedantic && !flag_isoc2x)
+ pedwarn (input_location, OPT_Wc11_c2x_compat,
+  "non-standard suffix on floating constant "
+  "before C2X");
+   else
+ warning (OPT_Wc11_c2x_compat,
+  "non-standard suffix on floating constant "
+  "before C2X");
+ }
+   else if (warn_c11_c2x_compat != 0 && pedantic && !flag_isoc2x)
+ pedwarn (input_location, OPT_Wpedantic,
+  "non-standard suffix on floating constant "
+  "before C2X");
+ }
+   else if (!extended)
  {
if (cxx_dialect < cxx23)
  pedwarn (input_location, OPT_Wpedantic,
--- gcc/c/c-decl.cc.jj  2023-09-04 09:45:47.998853807 +0200
+++ gcc/c/c-decl.cc 2023-09-05 09:43:28.384918043 +0200
@@ -12140,12 +12140,13 @@ declspecs_add_type (location_t loc, stru
CASE_RID_FLOATN_NX:
  specs->u.floatn_nx_idx = i - RID_FLOATN_NX_FIRST;
  if (!in_system_header_at (input_location))
-   pedwarn (loc, OPT_Wpedantic,
-"ISO C does not support the %<_Float%d%s%> type",
-floatn_nx_types[specs->u.floatn_nx_idx].n,
-(floatn_nx_types[specs->u.floatn_nx_idx].extended
- ? "x"
- : ""));
+   pedwarn_c11 (loc, OPT_Wpedantic,
+"ISO C does not support the %<_Float%d%s%> type"
+" before C2X",
+floatn_nx_types[specs->u.floatn_nx_idx].n,
+(floatn_nx_types[specs->u.floatn_nx_idx].extended
+ ? "x"
+ : ""));
 
  if (specs->long_p)
error_at (loc,
--- gcc/testsuite/gcc.dg/c11-floatn-1.c.jj  2023-09-05 10:07:09.062110156 
+0200
+++ gcc/testsuite/gcc.dg/c11-floatn-1.c 2023-09-05 10:10:57.288912286 +0200
@@ -0,0 +1,21 @@
+/* { dg-do compile } */
+/* { dg-options "-std=c11 -pedantic-errors" } */
+/* { dg-add-options float32 } */
+/* { dg-add-options float64 } */
+/* { dg-add-options float32x } */
+/* { dg-require-effective-target float32 } */
+/* { dg-require-effective-target float32x } */
+/* { dg-require-effective-target float64 } */
+
+_Float32 a /* { dg-error "ISO C does not support the '_Float32' 
type before C2X" } */
+  = 1.0F32;/* { dg-error "non-standard suffix on floating constant 
before C2X" } */
+_Float64 b /* { dg-error "ISO C does not support the '_Float64' 
type before C2X" } */
+  = 1.0F64;/* { dg-error "non-standard suffix on floating constant 
before C2X" } */
+_Float32x c/* { dg-error "ISO C does not support the '_Float32x' 
type before C2X" } */
+  = 

Re: [PATCH v3 1/4] LoongArch: improved target configuration interface

[Xi Ruoyao via Gcc-patches]

On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote:
> * Support options for LoongArch SIMD extensions:
>   new configure options --with-simd={none,lsx,lasx};
>   new compiler option -msimd={none,lsx,lasx};
>   new driver options -m[no]-l[a]sx.

Hmm... In my build (a cross compiler configured with ../gcc/configure --
target=loongarch64-linux-gnu --with-system-zlib) I have:

$ cat lasx.c
int x __attribute__((vector_size(32)));
int y __attribute__((vector_size(32)));
void test(void) { x += y; }
$ gcc/cc1 lasx.c -msimd=lasx -o- -nostdinc -mexplicit-relocs -O2

... ...

pcalau12i   $r12,%pc_hi20(.LANCHOR0)
addi.d  $r12,$r12,%pc_lo12(.LANCHOR0)
xvld$xr0,$r12,0
xvld$xr1,$r12,32
xvadd.w $xr0,$xr0,$xr1
xvst$xr0,$r12,0
jr  $r1

... ...

This seems perfectly fine.  But:

$ gcc/xgcc -B gcc lasx.c -mlasx -o- -nostdinc -mexplicit-relocs -O2 -S

... ...

test:
.LFB0 = .
pcalau12i   $r12,%pc_hi20(.LANCHOR0)
addi.d  $r12,$r12,%pc_lo12(.LANCHOR0)
addi.d  $r3,$r3,-16
.LCFI0 = .
st.d$r23,$r3,8
.LCFI1 = .
ldptr.w $r7,$r12,0
ldptr.w $r23,$r12,32
ldptr.w $r6,$r12,8

... ... (no SIMD instructions)

Is this a bug in the driver or I missed something?

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

Re: [PATCH V2] Emit funcall external declarations only if actually used.

[Jose E. Marchesi via Gcc-patches]

ping^

> ping
>
>> [Differences from V1:
>> - Prototype for call_from_call_insn moved before comment block.
>> - Reuse the `call' flag for SYMBOL_REF_LIBCALL.
>> - Fallback to check REG_CALL_DECL in non-direct calls.
>> - New test to check correct behavior for non-direct calls.]
>>
>> There are many places in GCC where alternative local sequences are
>> tried in order to determine what is the cheapest or best alternative
>> to use in the current target.  When any of these sequences involve a
>> libcall, the current implementation of emit_library_call_value_1
>> introduce a side-effect consisting on emitting an external declaration
>> for the funcall (such as __divdi3) which is thus emitted even if the
>> sequence that does the libcall is not retained.
>>
>> This is problematic in targets such as BPF, because the kernel loader
>> chokes on the spurious symbol __divdi3 and makes the resulting BPF
>> object unloadable.  Note that BPF objects are not linked before being
>> loaded.
>>
>> This patch changes emit_library_call_value_1 to mark the target
>> SYMBOL_REF as a libcall.  Then, the emission of the external
>> declaration is done in the first loop of final.cc:shorten_branches.
>> This happens only if the corresponding sequence has been kept.
>>
>> Regtested in x86_64-linux-gnu.
>> Tested with host x86_64-linux-gnu with target bpf-unknown-none.
>>
>> gcc/ChangeLog
>>
>>  * rtl.h (SYMBOL_REF_LIBCALL): Define.
>>  * calls.cc (emit_library_call_value_1): Do not emit external
>>  libcall declaration here.
>>  * final.cc (shorten_branches): Do it here.
>>
>> gcc/testsuite/ChangeLog
>>
>>  * gcc.target/bpf/divmod-libcall-1.c: New test.
>>  * gcc.target/bpf/divmod-libcall-2.c: Likewise.
>>  * gcc.c-torture/compile/libcall-2.c: Likewise.
>> ---
>>  gcc/calls.cc  |  9 +++---
>>  gcc/final.cc  | 30 +++
>>  gcc/rtl.h |  5 
>>  .../gcc.c-torture/compile/libcall-2.c |  8 +
>>  .../gcc.target/bpf/divmod-libcall-1.c | 19 
>>  .../gcc.target/bpf/divmod-libcall-2.c | 16 ++
>>  6 files changed, 83 insertions(+), 4 deletions(-)
>>  create mode 100644 gcc/testsuite/gcc.c-torture/compile/libcall-2.c
>>  create mode 100644 gcc/testsuite/gcc.target/bpf/divmod-libcall-1.c
>>  create mode 100644 gcc/testsuite/gcc.target/bpf/divmod-libcall-2.c
>>
>> diff --git a/gcc/calls.cc b/gcc/calls.cc
>> index 1f3a6d5c450..219ea599b16 100644
>> --- a/gcc/calls.cc
>> +++ b/gcc/calls.cc
>> @@ -4388,9 +4388,10 @@ emit_library_call_value_1 (int retval, rtx orgfun, 
>> rtx value,
>>  || argvec[i].partial != 0)
>>update_stack_alignment_for_call ([i].locate);
>>  
>> -  /* If this machine requires an external definition for library
>> - functions, write one out.  */
>> -  assemble_external_libcall (fun);
>> +  /* Mark the emitted target as a libcall.  This will be used by final
>> + in order to emit an external symbol declaration if the libcall is
>> + ever used.  */
>> +  SYMBOL_REF_LIBCALL (fun) = 1;
>>  
>>original_args_size = args_size;
>>args_size.constant = (aligned_upper_bound (args_size.constant
>> @@ -4735,7 +4736,7 @@ emit_library_call_value_1 (int retval, rtx orgfun, rtx 
>> value,
>> valreg,
>> old_inhibit_defer_pop + 1, call_fusage, flags, args_so_far);
>>  
>> -  if (flag_ipa_ra)
>> +  if (flag_ipa_ra || SYMBOL_REF_LIBCALL (orgfun))
>>  {
>>rtx datum = orgfun;
>>gcc_assert (GET_CODE (datum) == SYMBOL_REF);
>> diff --git a/gcc/final.cc b/gcc/final.cc
>> index dd3e22547ac..2041e43fdd1 100644
>> --- a/gcc/final.cc
>> +++ b/gcc/final.cc
>> @@ -804,6 +804,8 @@ make_pass_compute_alignments (gcc::context *ctxt)
>>  }
>>  
>>  
>> +static rtx call_from_call_insn (rtx_call_insn *insn);
>> +
>>  /* Make a pass over all insns and compute their actual lengths by shortening
>> any branches of variable length if possible.  */
>>  
>> @@ -850,6 +852,34 @@ shorten_branches (rtx_insn *first)
>>for (insn = get_insns (), i = 1; insn; insn = NEXT_INSN (insn))
>>  {
>>INSN_SHUID (insn) = i++;
>> +
>> +  /* If this is a `call' instruction implementing a libcall, and
>> + this machine requires an external definition for library
>> + functions, write one out.  */
>> +  if (CALL_P (insn))
>> +{
>> +  rtx x;
>> +
>> +  if ((x = call_from_call_insn (dyn_cast  (insn)))
>> +  && (x = XEXP (x, 0))
>> +  && MEM_P (x)
>> +  && (x = XEXP (x, 0))
>> +  && SYMBOL_REF_P (x)
>> +  && SYMBOL_REF_LIBCALL (x))
>> +{
>> +  /* Direct call.  */
>> +  assemble_external_libcall (x);
>> +}
>> +  else if ((x = find_reg_note (insn, REG_CALL_DECL, NULL_RTX))
>> +   && (x = XEXP (x, 0)))
>> +{
>> +  

Re: [PATCH v3 1/4] LoongArch: improved target configuration interface

[chenglulu]

在 2023/9/5 下午8:17, Xi Ruoyao 写道:

On Tue, 2023-09-05 at 20:01 +0800, chenglulu wrote:

在 2023/9/5 下午7:51, Xi Ruoyao 写道:

On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote:

   /* Note: optimize_size may vary across functions,
  while -m[no]-memcpy imposes a global constraint.  */
   #define TARGET_DO_OPTIMIZE_BLOCK_MOVE_P
loongarch_do_optimize_block_move_p()
   
-#ifndef HAVE_AS_EXPLICIT_RELOCS

-#define HAVE_AS_EXPLICIT_RELOCS 0
-#endif
-

This causes a build failure with older assembler:

options.cc:3040:3: error: 'HAVE_AS_EXPLICIT_RELOCS' was not declared in this 
scope; did you mean 'TARGET_EXPLICIT_RELOCS'?
   3040 |   HAVE_AS_EXPLICIT_RELOCS, /* TARGET_EXPLICIT_RELOCS */
    |   ^~~
    |   TARGET_EXPLICIT_RELOCS

Why this is removed?  If this is an unintentionally change I'll add it
back.


Sorry, this was deleted accidentally.

Thanks!

Added the 3 lines back at r14-3706.


Ok. Thanks!

testsuite: Port 'check-function-bodies' to nvptx (was: Add dg test for matching function bodies)

[Thomas Schwinge]

Hi!

On 2023-09-04T23:05:05+0200, I wrote:
> On 2019-07-16T15:04:49+0100, Richard Sandiford  
> wrote:
>> This patch therefore adds a new check-function-bodies dg-final test

>> The regexps in parse_function_bodies are fairly general, but might
>> still need to be extended in future for targets like Darwin or AIX.
>
> ..., or nvptx.  [...]

> number of TODO items.
>
> In particular how to parameterize regular expressions for the different
> syntax used by nvptx: for example, parameterize via global variables,
> initialized accordingly (where?)?  Thinking about it, maybe simply
> conditionalizing the current local initializations by
> 'if { [istarget nvptx-*-*] } { [...] } else { [...] }' will do, simple
> enough!

Indeed that works fine.

> Regarding whitespace prefixed, I think I'll go with the current
> 'append function_regexp "\t" $line "\n"', that is, prefix expected output
> lines with '\t' (as done in 'gcc.target/nvptx/abort.c'), and also for
> nvptx handle labels as "fluff" (until we solve that issue generally).

I changed my mind about that: instead of '\t', use '\t*' for nvptx, which
means that both instructions emitted with additional whitespace prefixed
and labels in column zero work nicely.

> --- a/gcc/testsuite/lib/scanasm.exp
> +++ b/gcc/testsuite/lib/scanasm.exp

> @@ -907,7 +911,8 @@ proc check-function-bodies { args } {
>
>  set count 0
>  set function_regexp ""
> -set label {^(\S+):$}
> +#TODO
> +set label {^// BEGIN GLOBAL FUNCTION DEF: ([a-zA-Z_]\S+)$}

There's actually no reason that the expected output syntax (this one) has
to match the assembly -- so I restored that, to use the same syntax for
nvptx here, too.

Any comments before I push the attached
"testsuite: Port 'check-function-bodies' to nvptx"?


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From bdaf7572d9d4c1988274405840de4071ded3733f Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 4 Sep 2023 22:28:12 +0200
Subject: [PATCH] testsuite: Port 'check-function-bodies' to nvptx

This extends commit 4d706ff86ea86868615558e92407674a4f4b4af9
"Add dg test for matching function bodies" for nvptx.

	gcc/testsuite/
	* lib/scanasm.exp (configure_check-function-bodies): New proc.
	(parse_function_bodies, check-function-bodies): Use it.
	* gcc.target/nvptx/abort.c: Use 'check-function-bodies'.
	gcc/
	* doc/sourcebuild.texi (check-function-bodies): Update.
---
 gcc/doc/sourcebuild.texi   |  9 ++-
 gcc/testsuite/gcc.target/nvptx/abort.c | 19 ++-
 gcc/testsuite/lib/scanasm.exp  | 76 --
 3 files changed, 83 insertions(+), 21 deletions(-)

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 1a78b3c1abb..8aec6b6592c 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -3327,9 +3327,12 @@ The first line of the expected output for a function @var{fn} has the form:
 Subsequent lines of the expected output also start with @var{prefix}.
 In both cases, whitespace after @var{prefix} is not significant.
 
-The test discards assembly directives such as @code{.cfi_startproc}
-and local label definitions such as @code{.LFB0} from the compiler's
-assembly output.  It then matches the result against the expected
+Depending on the configuration (see
+@code{gcc/testsuite/lib/scanasm.exp:configure_check-function-bodies}),
+the test may discard from the compiler's assembly output
+directives such as @code{.cfi_startproc},
+local label definitions such as @code{.LFB0}, and more.
+It then matches the result against the expected
 output for a function as a single regular expression.  This means that
 later lines can use backslashes to refer back to @samp{(@dots{})}
 captures on earlier lines.  For example:
diff --git a/gcc/testsuite/gcc.target/nvptx/abort.c b/gcc/testsuite/gcc.target/nvptx/abort.c
index d3220687400..ae9dbf45a9b 100644
--- a/gcc/testsuite/gcc.target/nvptx/abort.c
+++ b/gcc/testsuite/gcc.target/nvptx/abort.c
@@ -1,4 +1,6 @@
 /* { dg-do compile} */
+/* { dg-final { check-function-bodies {**} {} } } */
+
 /* Annotate no return functions with a trailing 'trap'.  */
 
 extern void abort ();
@@ -9,5 +11,18 @@ int main (int argc, char **argv)
 abort ();
   return 0;
 }
-
-/* { dg-final { scan-assembler "call abort;\[\r\n\t \]+trap;" } } */
+/*
+** main:
+**	...
+**	\.reg\.pred (%r[0-9]+);
+**	...
+**	@\1	bra	(\$L[0-9]+);
+**	{
+**		call abort;
+**		trap; // \(noreturn\)
+**		exit; // \(noreturn\)
+**	}
+**	\2:
+**	\tmov\.u32	%r[0-9]+, 0;
+**	...
+*/
diff --git a/gcc/testsuite/lib/scanasm.exp b/gcc/testsuite/lib/scanasm.exp
index 0685de1d641..5df80325dff 100644
--- a/gcc/testsuite/lib/scanasm.exp
+++ b/gcc/testsuite/lib/scanasm.exp
@@ -777,33 +777,73 @@ proc scan-lto-assembler { args } {
 dg-scan 

Re: [PATCH v3 1/4] LoongArch: improved target configuration interface

[Xi Ruoyao via Gcc-patches]

On Tue, 2023-09-05 at 20:01 +0800, chenglulu wrote:
> 
> 在 2023/9/5 下午7:51, Xi Ruoyao 写道:
> > On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote:
> > >   /* Note: optimize_size may vary across functions,
> > >  while -m[no]-memcpy imposes a global constraint.  */
> > >   #define TARGET_DO_OPTIMIZE_BLOCK_MOVE_P
> > > loongarch_do_optimize_block_move_p()
> > >   
> > > -#ifndef HAVE_AS_EXPLICIT_RELOCS
> > > -#define HAVE_AS_EXPLICIT_RELOCS 0
> > > -#endif
> > > -
> > This causes a build failure with older assembler:
> > 
> > options.cc:3040:3: error: 'HAVE_AS_EXPLICIT_RELOCS' was not declared in 
> > this scope; did you mean 'TARGET_EXPLICIT_RELOCS'?
> >   3040 |   HAVE_AS_EXPLICIT_RELOCS, /* TARGET_EXPLICIT_RELOCS */
> >    |   ^~~
> >    |   TARGET_EXPLICIT_RELOCS
> > 
> > Why this is removed?  If this is an unintentionally change I'll add it
> > back.
> > 
> Sorry, this was deleted accidentally.
> 
> Thanks!

Added the 3 lines back at r14-3706.

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

Re: [PATCH] RISC-V: Emit .note.GNU-stack for non-linux target as well

[Kito Cheng via Gcc-patches]

committed, thanks :)

On Tue, Sep 5, 2023 at 3:18 PM Jeff Law via Gcc-patches
 wrote:
>
>
>
> On 8/31/23 03:05, Kito Cheng wrote:
> > We only emit that on linux target before, that not problem before,
> > however Qemu has fix a bug to make qemu user mode honor PT_GNU_STACK[1],
> > that will cause problem when we test baremetal with qemu.
> >
> > So the straightforward is enable that as well for non-linux toolchian,
> > the price is that will increase few bytes for each binary.
> >
> > [1] 
> > https://github.com/qemu/qemu/commit/872f3d046f2381e3f416519e82df96bd60818311
> >
> > gcc/ChangeLog:
> >
> >   * config/riscv/linux.h (TARGET_ASM_FILE_END): Move ...
> >   * config/riscv/riscv.cc (TARGET_ASM_FILE_END): to here.
> OK.
> jeff

RE: [PATCH v1] RISC-V: Support FP SGNJ autovec for VLS mode

[Li, Pan2 via Gcc-patches]

Committed, thanks Juzhe.

Pan

From: juzhe.zh...@rivai.ai 
Sent: Tuesday, September 5, 2023 7:14 PM
To: Li, Pan2 ; gcc-patches 
Cc: Li, Pan2 ; Wang, Yanzhang ; 
kito.cheng 
Subject: Re: [PATCH v1] RISC-V: Support FP SGNJ autovec for VLS mode

LGTM


juzhe.zh...@rivai.ai

From: pan2.li
Date: 2023-09-05 18:32
To: gcc-patches
CC: juzhe.zhong; 
pan2.li; 
yanzhang.wang; 
kito.cheng
Subject: [PATCH v1] RISC-V: Support FP SGNJ autovec for VLS mode
From: Pan Li mailto:pan2...@intel.com>>

This patch would like to allow the VLS mode autovec for the
floating-point binary operation MAX/MIN.

Given below code example:

void test(float * restrict out, float * restrict in1, float * restrict in2)
{
  for (int i = 0; i < 128; i++)
out[i] = __builtin_copysignf (in1[i], in2[i]);
}

Before this patch:
test:
  csrra4,vlenb
  sllia4,a4,1
  li  a5,128
  bleua5,a4,.L2
  mv  a5,a4
.L2:
  vsetvli zero,a5,e32,m8,ta,ma
  vle32.v v8,0(a1)
  vle32.v v16,0(a2)
  vsetvli a4,zero,e32,m8,ta,ma
  vfsgnj.vv   v8,v8,v16
  vsetvli zero,a5,e32,m8,ta,ma
  vse32.v v8,0(a0)
  ret

After this patch:
test:
  li  a5,128
  vsetvli zero,a5,e32,m1,ta,ma
  vle32.v v1,0(a1)
  vle32.v v2,0(a2)
  vfsgnj.vv   v1,v1,v2
  vse32.v v1,0(a0)
  ret

Signed-off-by: Pan Li mailto:pan2...@intel.com>>

gcc/ChangeLog:

* config/riscv/autovec-vls.md (copysign3): New pattern.
* config/riscv/vector.md: Extend iterator for VLS.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/vls/def.h: New macro.
* gcc.target/riscv/rvv/autovec/vls/floating-point-sgnj-1.c: New test.
* gcc.target/riscv/rvv/autovec/vls/floating-point-sgnj-2.c: New test.
---
gcc/config/riscv/autovec-vls.md   | 22 ++
gcc/config/riscv/vector.md| 24 +--
.../gcc.target/riscv/rvv/autovec/vls/def.h|  8 
.../rvv/autovec/vls/floating-point-sgnj-1.c   | 43 +++
.../rvv/autovec/vls/floating-point-sgnj-2.c   | 43 +++
5 files changed, 128 insertions(+), 12 deletions(-)
create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/floating-point-sgnj-1.c
create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/floating-point-sgnj-2.c

diff --git a/gcc/config/riscv/autovec-vls.md b/gcc/config/riscv/autovec-vls.md
index 7ef29637e33..31b6c4ae714 100644
--- a/gcc/config/riscv/autovec-vls.md
+++ b/gcc/config/riscv/autovec-vls.md
@@ -255,6 +255,28 @@ (define_insn_and_split "3"
[(set_attr "type" "vector")]
)
+;; -
+;; Includes:
+;; - vfsgnj.vv
+;; - vfsgnj.vf
+;; -
+(define_insn_and_split "copysign3"
+  [(set (match_operand:VLSF 0 "register_operand")
+(unspec:VLSF
+  [(match_operand:VLSF  1 "register_operand")
+   (match_operand:VLSF  2 "register_operand")] UNSPEC_VCOPYSIGN))]
+  "TARGET_VECTOR && can_create_pseudo_p ()"
+  "#"
+  "&& 1"
+  [(const_int 0)]
+  {
+riscv_vector::emit_vlmax_insn (code_for_pred (UNSPEC_VCOPYSIGN, 
mode),
+riscv_vector::BINARY_OP, operands);
+DONE;
+  }
+  [(set_attr "type" "vector")]
+)
+
;; 
---
;;  [INT] Unary operations
;; 
---
diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md
index 9d7b4bbe1d4..fc985ff6a01 100644
--- a/gcc/config/riscv/vector.md
+++ b/gcc/config/riscv/vector.md
@@ -6166,8 +6166,8 @@ (define_insn "@pred__reverse_scalar"
(symbol_ref "riscv_vector::get_frm_mode (operands[9])"))])
(define_insn "@pred_"
-  [(set (match_operand:VF 0 "register_operand"   "=vd, vd, vr, vr")
- (if_then_else:VF
+  [(set (match_operand:V_VLSF 0 "register_operand"   "=vd, vd, vr, vr")
+ (if_then_else:V_VLSF
  (unspec:
[(match_operand: 1 "vector_mask_operand" " vm, vm,Wc1,Wc1")
 (match_operand 5 "vector_length_operand"" rK, rK, rK, rK")
@@ -6176,10 +6176,10 @@ (define_insn "@pred_"
 (match_operand 8 "const_int_operand""  i,  i,  i,  i")
 (reg:SI VL_REGNUM)
 (reg:SI VTYPE_REGNUM)] UNSPEC_VPREDICATE)
-   (unspec:VF
- [(match_operand:VF 3 "register_operand"   " vr, vr, vr, vr")
-  (match_operand:VF 4 "register_operand"   " vr, vr, vr, vr")] 
VCOPYSIGNS)
-   (match_operand:VF 2 "vector_merge_operand" " vu,  0, vu,  0")))]
+   (unspec:V_VLSF
+ [(match_operand:V_VLSF 3 "register_operand"  " vr, vr, vr, vr")
+  (match_operand:V_VLSF 4 "register_operand"  " vr, vr, vr, vr")] 
VCOPYSIGNS)
+   (match_operand:V_VLSF 2 "vector_merge_operand" " vu,  0, vu,  0")))]
   "TARGET_VECTOR"
   "vfsgnj.vv\t%0,%3,%4%p1"
   [(set_attr "type" 

[PATCH v3 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

[Tsukasa OI via Gcc-patches]

From: Tsukasa OI 

'XVentanaCondOps' is a vendor extension from Ventana Micro Systems
containing two instructions for conditional move and will be supported on
their Veyron V1 CPU.

And most notably (for historical reasons), 'XVentanaCondOps' and the
standard 'Zicond' extension are functionally equivalent (only encodings and
instruction names are different).

*   czero.eqz == vt.maskc
*   czero.nez == vt.maskcn

This commit adds support for the 'XVentanaCondOps' extension by extending
'Zicond' extension support.  With this, we can now reuse the optimization
using the 'Zicond' extension for the 'XVentanaCondOps' extension.

The specification for the 'XVentanaCondOps' extension is based on:


gcc/ChangeLog:

* common/config/riscv/riscv-common.cc (riscv_ext_flag_table):
Parse 'XVentanaCondOps' extension.
* config/riscv/riscv-opts.h (MASK_XVENTANACONDOPS): New.
(TARGET_XVENTANACONDOPS): Ditto.
(TARGET_ZICOND_LIKE): New to represent targets with conditional
moves like 'Zicond'.  It includes RV64 + 'XVentanaCondOps'.
* config/riscv/riscv.cc (riscv_rtx_costs): Replace TARGET_ZICOND
with TARGET_ZICOND_LIKE.
(riscv_expand_conditional_move): Ditto.
* config/riscv/riscv.md (movcc): Replace TARGET_ZICOND with
TARGET_ZICOND_LIKE.
* config/riscv/riscv.opt: Add new riscv_xventana_subext.
* config/riscv/zicond.md: Modify description.
(eqz_ventana): New to match corresponding czero instructions.
(nez_ventana): Ditto.
(*czero..): Emit a 'XVentanaCondOps' instruction if
'Zicond' is not available but 'XVentanaCondOps' + RV64 is.
(*czero..): Ditto.
(*czero.eqz..opt1): Ditto.
(*czero.nez..opt2): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/xventanacondops-primitiveSemantics.c: New test,
modified from zicond-primitiveSemantics.c.
* gcc.target/riscv/xventanacondops-primitiveSemantics-rv32.c: New
test to make sure that XVentanaCondOps instructions are disabled
on RV32.
* gcc.target/riscv/xventanacondops-xor-01.c: New test, modified
from zicond-xor-01.c.
---
 gcc/common/config/riscv/riscv-common.cc   |  2 +
 gcc/config/riscv/riscv-opts.h |  6 +++
 gcc/config/riscv/riscv.cc |  4 +-
 gcc/config/riscv/riscv.md |  2 +-
 gcc/config/riscv/riscv.opt|  3 ++
 gcc/config/riscv/zicond.md| 51 +++
 .../xventanacondops-primitiveSemantics-rv32.c | 45 
 .../xventanacondops-primitiveSemantics.c  | 48 +
 .../gcc.target/riscv/xventanacondops-xor-01.c | 14 +
 9 files changed, 162 insertions(+), 13 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.target/riscv/xventanacondops-primitiveSemantics-rv32.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/xventanacondops-primitiveSemantics.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/xventanacondops-xor-01.c

diff --git a/gcc/common/config/riscv/riscv-common.cc 
b/gcc/common/config/riscv/riscv-common.cc
index f142212f2edc..9a0a68fe5db3 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -1493,6 +1493,8 @@ static const riscv_ext_flag_table_t 
riscv_ext_flag_table[] =
   {"xtheadmempair", _options::x_riscv_xthead_subext, MASK_XTHEADMEMPAIR},
   {"xtheadsync",_options::x_riscv_xthead_subext, MASK_XTHEADSYNC},
 
+  {"xventanacondops", _options::x_riscv_xventana_subext, 
MASK_XVENTANACONDOPS},
+
   {NULL, NULL, 0}
 };
 
diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
index b6b5907e111b..a525f679683c 100644
--- a/gcc/config/riscv/riscv-opts.h
+++ b/gcc/config/riscv/riscv-opts.h
@@ -321,6 +321,12 @@ enum riscv_entity
 #define TARGET_XTHEADMEMPAIR ((riscv_xthead_subext & MASK_XTHEADMEMPAIR) != 0)
 #define TARGET_XTHEADSYNC((riscv_xthead_subext & MASK_XTHEADSYNC) != 0)
 
+#define MASK_XVENTANACONDOPS  (1 << 0)
+
+#define TARGET_XVENTANACONDOPS ((riscv_xventana_subext & MASK_XVENTANACONDOPS) 
!= 0)
+
+#define TARGET_ZICOND_LIKE (TARGET_ZICOND || (TARGET_XVENTANACONDOPS && 
TARGET_64BIT))
+
 /* We only enable VLS modes for VLA vectorization since fixed length VLMAX mode
is the highest priority choice and should not conflict with VLS modes.  */
 #define TARGET_VECTOR_VLS  
\
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 8d8f7b4f16ed..eb10f4a3323f 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -2745,7 +2745,7 @@ riscv_rtx_costs (rtx x, machine_mode mode, int 
outer_code, int opno ATTRIBUTE_UN
  *total = COSTS_N_INSNS (1);
  return true;
}
-  else if (TARGET_ZICOND
+  else if 

[PATCH v3 0/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

[Tsukasa OI via Gcc-patches]

PATCH v1:

PATCH v2:


Changes: v1 -> v2
*   Removed bogus opt2 pattern as pointed out in:

note that this is not in the ChangeLog expecting the patch above
applies first.

Changes: v2 -> v3
*   Instead of removing opt2 pattern, fix opt2 pattern:





Tsukasa OI (1):
  RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

 gcc/common/config/riscv/riscv-common.cc   |  2 +
 gcc/config/riscv/riscv-opts.h |  6 +++
 gcc/config/riscv/riscv.cc |  4 +-
 gcc/config/riscv/riscv.md |  2 +-
 gcc/config/riscv/riscv.opt|  3 ++
 gcc/config/riscv/zicond.md| 51 +++
 .../xventanacondops-primitiveSemantics-rv32.c | 45 
 .../xventanacondops-primitiveSemantics.c  | 48 +
 .../gcc.target/riscv/xventanacondops-xor-01.c | 14 +
 9 files changed, 162 insertions(+), 13 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.target/riscv/xventanacondops-primitiveSemantics-rv32.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/xventanacondops-primitiveSemantics.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/xventanacondops-xor-01.c


base-commit: 72b639760a891c406725854bfb08132c83f0761a
-- 
2.42.0

[PATCH v2] RISC-V: Fix Zicond ICE on large constants

[Tsukasa OI via Gcc-patches]

From: Tsukasa OI 

Large constant cons and/or alt will trigger ICEs building GCC target
libraries (libgomp and libatomic) when the 'Zicond' extension is enabled.

For instance, zicond-ice-2.c (new test case in this commit) will cause
an ICE when SOME_NUMBER is 0x1000 or larger.  While opposite numbers
corresponding cons/alt (two temp2 variables) are checked, cons/alt
themselves are not checked and causing 2 ICEs building
GCC target libraries as of this writing:

1.  gcc/libatomic/config/posix/lock.c
2.  gcc/libgomp/fortran.c

Coercing a large value into a register will fix the issue.

It also coerce a large cons into a register on "imm, imm" case (the author
could not reproduce but possible to cause an ICE).

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_expand_conditional_move): Force
large constant cons/alt into a register.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/zicond-ice-2.c: New test.  This is based on
an ICE at libat_lock_n func on gcc/libatomic/config/posix/lock.c
but heavily minimized.
---
 gcc/config/riscv/riscv.cc | 21 +--
 gcc/testsuite/gcc.target/riscv/zicond-ice-2.c | 11 ++
 2 files changed, 26 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/zicond-ice-2.c

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 8d8f7b4f16ed..e306d57814be 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -3917,6 +3917,11 @@ riscv_expand_conditional_move (rtx dest, rtx op, rtx 
cons, rtx alt)
  gen_rtx_IF_THEN_ELSE (mode, cond,
CONST0_RTX (mode),
alt)));
+ /* CONS might not fit into a signed 12 bit immediate suitable
+for an addi instruction.  If that's the case, force it
+into a register.  */
+ if (!SMALL_OPERAND (INTVAL (cons)))
+   cons = force_reg (mode, cons);
  riscv_emit_binary (PLUS, dest, dest, cons);
  return true;
}
@@ -3940,11 +3945,13 @@ riscv_expand_conditional_move (rtx dest, rtx op, rtx 
cons, rtx alt)
  rtx temp1 = gen_reg_rtx (mode);
  rtx temp2 = gen_int_mode (-1 * INTVAL (cons), mode);
 
- /* TEMP2 might not fit into a signed 12 bit immediate suitable
-for an addi instruction.  If that's the case, force it into
-a register.  */
+ /* TEMP2 and/or CONS might not fit into a signed 12 bit immediate
+suitable for an addi instruction.  If that's the case, force it
+into a register.  */
  if (!SMALL_OPERAND (INTVAL (temp2)))
temp2 = force_reg (mode, temp2);
+ if (!SMALL_OPERAND (INTVAL (cons)))
+   cons = force_reg (mode, cons);
 
  riscv_emit_binary (PLUS, temp1, alt, temp2);
  emit_insn (gen_rtx_SET (dest,
@@ -3986,11 +3993,13 @@ riscv_expand_conditional_move (rtx dest, rtx op, rtx 
cons, rtx alt)
  rtx temp1 = gen_reg_rtx (mode);
  rtx temp2 = gen_int_mode (-1 * INTVAL (alt), mode);
 
- /* TEMP2 might not fit into a signed 12 bit immediate suitable
-for an addi instruction.  If that's the case, force it into
-a register.  */
+ /* TEMP2 and/or ALT might not fit into a signed 12 bit immediate
+suitable for an addi instruction.  If that's the case, force it
+into a register.  */
  if (!SMALL_OPERAND (INTVAL (temp2)))
temp2 = force_reg (mode, temp2);
+ if (!SMALL_OPERAND (INTVAL (alt)))
+   alt = force_reg (mode, alt);
 
  riscv_emit_binary (PLUS, temp1, cons, temp2);
  emit_insn (gen_rtx_SET (dest,
diff --git a/gcc/testsuite/gcc.target/riscv/zicond-ice-2.c 
b/gcc/testsuite/gcc.target/riscv/zicond-ice-2.c
new file mode 100644
index ..ffd8dcb5814e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/zicond-ice-2.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gc_zicond -mabi=lp64d" { target { rv64 } } } */
+/* { dg-options "-march=rv32gc_zicond -mabi=ilp32d" { target { rv32 } } } */
+
+#define SOME_NUMBER 0x1000
+
+unsigned long
+d (unsigned long n)
+{
+  return n > SOME_NUMBER ? SOME_NUMBER : n;
+}

base-commit: 72b639760a891c406725854bfb08132c83f0761a
-- 
2.42.0

Re: [PATCH 2/2] [RISC-V] Enalble zcmp for -Os

[Kito Cheng via Gcc-patches]

> @@ -5569,7 +5571,9 @@ riscv_avoid_multi_push (const struct riscv_frame_info 
> *frame)
>  {
>if (!TARGET_ZCMP || crtl->calls_eh_return || frame_pointer_needed
>|| cfun->machine->interrupt_handler_p || cfun->machine->varargs_size 
> != 0
> -  || crtl->args.pretend_args_size != 0 || flag_shrink_wrap_separate
> +  || crtl->args.pretend_args_size != 0
> +  || (use_shrink_wrapping_separate ()
> + && !riscv_avoid_shrink_wrapping_separate ())

I think we should also check "!optimize_function_for_size_p (cfun)"
here, otherwise that does not really match what we claim in the commit
message.

e.g. it still will enable with -O2 -fno-shrink-wrap-separate

>|| (frame->mask & ~MULTI_PUSH_GPR_MASK))
>  return true;
>

Re: [PATCH v3 1/4] LoongArch: improved target configuration interface

[chenglulu]

在 2023/9/5 下午7:51, Xi Ruoyao 写道:

On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote:

  /* Note: optimize_size may vary across functions,
     while -m[no]-memcpy imposes a global constraint.  */
  #define TARGET_DO_OPTIMIZE_BLOCK_MOVE_P
loongarch_do_optimize_block_move_p()
  
-#ifndef HAVE_AS_EXPLICIT_RELOCS

-#define HAVE_AS_EXPLICIT_RELOCS 0
-#endif
-

This causes a build failure with older assembler:

options.cc:3040:3: error: 'HAVE_AS_EXPLICIT_RELOCS' was not declared in this 
scope; did you mean 'TARGET_EXPLICIT_RELOCS'?
  3040 |   HAVE_AS_EXPLICIT_RELOCS, /* TARGET_EXPLICIT_RELOCS */
   |   ^~~
   |   TARGET_EXPLICIT_RELOCS

Why this is removed?  If this is an unintentionally change I'll add it
back.


Sorry, this was deleted accidentally.

Thanks!

Re: [PATCH] analyzer: Move gcc.dg/analyzer tests to c-c++-common (2) [PR96395]

[David Malcolm via Gcc-patches]

On Mon, 2023-09-04 at 20:00 +0200, priour...@gmail.com wrote:


> Hi,
> 
> The second patch of this serie.
> Regstrapped on x86_64-linux-gnu off trunk 
> a7d052b3200c7928d903a0242b8cfd75d131e374.

Thanks for the patch.

Overall, looks like great work, but there are a few nitpicks to be
fixed, see below...

[...snip...]
 
> Second batch of moving tests from under gcc.dg/analyzer into
> c-c++-common/analyzer.
> 
> Prior to this patch the analyzer was not unwrapping ordering
> binop_svalue, such as LT_EXPR, when evaluating conditions.
> 
> Therefore when an ordering conditional was stored, the analyzer
> was missing out on some constraints, which led to false positives.
> 
> Signed-off-by: benjamin priour 

[...snip...]

>   * gcc.dg/analyzer/inlining-7.c: Moved to...
>   * c-c++-common/analyzer/inlining-7.c: ...here.
>   * c-c++-common/analyzer/compound-assignment-1.c: New test.

All of these "new" tests (apart from the "-noexcept" ones) look like
they're meant to be existing tests that were moved, but where the copy
of the test in gcc.dg/analyzer didn't get deleted, so they show up as a
duplicate.  See the details below.

>   * c-c++-common/analyzer/file-pr58237-noexcept.c: New test.

When duplicating a test like this, the test isn't entirely "new", so
please say something like this in the ChangeLog entry, to make it clear
where it came from:

* c-c++-common/analyzer/file-pr58237-noexcept.c: New test,
based on gcc.dg/analyzer/file-pr58237.c.

>   * c-c++-common/analyzer/fopen-2.c: New test.

Looks fopen-2.c is a move of the parts of gcc.dg/analyzer/fopen-1.c
that can also be C++, so please state that in the ChangeLog.

>   * c-c++-common/analyzer/infinite-recursion.c: New test.
>   * c-c++-common/analyzer/malloc-paths-9-noexcept.c: New test.

Likewise, please say where the -noexcept.c test came from.


>   * c-c++-common/analyzer/pr109577-noexcept.c: New test.

Likewise for this -noexcept test.

>   * c-c++-common/analyzer/pr93355-localealias-feasibility-noexcept.c: New 
> test.

Likewise for this -noexcept test.

>   * c-c++-common/analyzer/pr94362-1.c: New test.
>   * c-c++-common/analyzer/pr99193-1-noexcept.c: New test.

Likewise for this -noexcept test.

>   * c-c++-common/analyzer/scope-1.c: New test.
>   * c-c++-common/analyzer/setjmp-2.c: New test.
>   * c-c++-common/analyzer/setjmp-5.c: New test.
>   * c-c++-common/analyzer/setjmp-9.c: New test.
>   * c-c++-common/analyzer/signal-4a.c: New test.
>   * c-c++-common/analyzer/signal-4b.c: New test.

[...snip...]

> diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
> index 82bc3b2c382..43b4bc1cc5b 100644
> --- a/gcc/analyzer/region-model.cc
> +++ b/gcc/analyzer/region-model.cc
> @@ -4486,6 +4486,14 @@ region_model::add_constraints_from_binop (const svalue 
> *outer_lhs,
> return true;
>   }
>return false;
> +case GE_EXPR:
> +case GT_EXPR:
> +case LE_EXPR:
> +case LT_EXPR:
> +  if (!is_true)
> + inner_op = invert_tree_comparison (inner_op, false /* honor_nans */);
> +  *out = add_constraint (inner_lhs, inner_op, inner_rhs, ctxt);
> +  return true;
>  }
>  }
>  

Nice - thanks.

Can this be combined with the EQ_EXPR and NE_EXPR cases? (possibly
updating the comment)  The code looks identical to me, but I might be
misreading it.

[...snip...]

> diff --git a/gcc/testsuite/c-c++-common/analyzer/compound-assignment-1.c 
> b/gcc/testsuite/c-c++-common/analyzer/compound-assignment-1.c
> new file mode 100644
> index 000..b208f58f09f
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/analyzer/compound-assignment-1.c
> @@ -0,0 +1,72 @@
> +#include 
> +
> +struct ptr_wrapper
> +{
> +  int *ptr;
> +};
> +
> +struct ptr_wrapper
> +test_1 (void)
> +{
> +  struct ptr_wrapper r;
> +  r.ptr = (int *) malloc (sizeof (int));
> +  return r;
> +}

This looks the same as gcc.dg/analyzer/compound-assignment-1.c

Should this be a move, rather than a new file?  i.e. is the patch
missing a deletion of the file in the old location?

[...snip...]

> diff --git a/gcc/testsuite/c-c++-common/analyzer/infinite-recursion.c 
> b/gcc/testsuite/c-c++-common/analyzer/infinite-recursion.c
> new file mode 100644
> index 000..6b7d25cfabe
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/analyzer/infinite-recursion.c

Likewise here for infinite-recursion.c.

[...snip...]

> diff --git 
> a/gcc/testsuite/gcc.dg/analyzer/loop-0-up-to-n-by-1-with-iter-obj.c 
> b/gcc/testsuite/c-c++-common/analyzer/loop-0-up-to-n-by-1-with-iter-obj.c
> similarity index 97%
> rename from gcc/testsuite/gcc.dg/analyzer/loop-0-up-to-n-by-1-with-iter-obj.c
> rename to 
> gcc/testsuite/c-c++-common/analyzer/loop-0-up-to-n-by-1-with-iter-obj.c
> index 0172c9b324c..1b657697ef4 100644
> --- a/gcc/testsuite/gcc.dg/analyzer/loop-0-up-to-n-by-1-with-iter-obj.c
> +++ b/gcc/testsuite/c-c++-common/analyzer/loop-0-up-to-n-by-1-with-iter-obj.c
> @@ -1,6 

Re: [PATCH v3 1/4] LoongArch: improved target configuration interface

[Xi Ruoyao via Gcc-patches]

On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote:
>  /* Note: optimize_size may vary across functions,
>     while -m[no]-memcpy imposes a global constraint.  */
>  #define TARGET_DO_OPTIMIZE_BLOCK_MOVE_P 
> loongarch_do_optimize_block_move_p()
>  
> -#ifndef HAVE_AS_EXPLICIT_RELOCS
> -#define HAVE_AS_EXPLICIT_RELOCS 0
> -#endif
> -

This causes a build failure with older assembler:

options.cc:3040:3: error: 'HAVE_AS_EXPLICIT_RELOCS' was not declared in this 
scope; did you mean 'TARGET_EXPLICIT_RELOCS'?
 3040 |   HAVE_AS_EXPLICIT_RELOCS, /* TARGET_EXPLICIT_RELOCS */
  |   ^~~
  |   TARGET_EXPLICIT_RELOCS

Why this is removed?  If this is an unintentionally change I'll add it
back.

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

Re: [PATCH v2] RISC-V: Optimize the MASK opt generation

[Kito Cheng via Gcc-patches]

Hi Feng:

Thanks for the simplification, that reduces the effort of adding a new
extension!
Functional part looks good, but I think we may document that new
syntax at gcc/gcc/doc/options.texi

On Thu, Aug 31, 2023 at 11:32 AM Feng Wang  wrote:
>
> This patch rebases the change of "[PATCH] RISC-V: Optimize the MASK opt
> generation". Please check the detail info on the
> "https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg302295.html;
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-opts.h (MASK_ZICSR):
> (MASK_ZIFENCEI): Delete;
> (MASK_ZIHINTNTL):Ditto;
> (MASK_ZIHINTPAUSE):  Ditto;
> (TARGET_ZICSR):  Ditto;
> (TARGET_ZIFENCEI):   Ditto;
> (TARGET_ZIHINTNTL):  Ditto;
> (TARGET_ZIHINTPAUSE):Ditto;
> (MASK_ZAWRS):Ditto;
> (TARGET_ZAWRS):  Ditto;
> (MASK_ZBA):  Ditto;
> (MASK_ZBB):  Ditto;
> (MASK_ZBC):  Ditto;
> (MASK_ZBS):  Ditto;
> (TARGET_ZBA):Ditto;
> (TARGET_ZBB):Ditto;
> (TARGET_ZBC):Ditto;
> (TARGET_ZBS):Ditto;
> (MASK_ZFINX):Ditto;
> (MASK_ZDINX):Ditto;
> (MASK_ZHINX):Ditto;
> (MASK_ZHINXMIN): Ditto;
> (TARGET_ZFINX):  Ditto;
> (TARGET_ZDINX):  Ditto;
> (TARGET_ZHINX):  Ditto;
> (TARGET_ZHINXMIN):   Ditto;
> (MASK_ZBKB): Ditto;
> (MASK_ZBKC): Ditto;
> (MASK_ZBKX): Ditto;
> (MASK_ZKNE): Ditto;
> (MASK_ZKND): Ditto;
> (MASK_ZKNH): Ditto;
> (MASK_ZKR):  Ditto;
> (MASK_ZKSED):Ditto;
> (MASK_ZKSH): Ditto;
> (MASK_ZKT):  Ditto;
> (TARGET_ZBKB):   Ditto;
> (TARGET_ZBKC):   Ditto;
> (TARGET_ZBKX):   Ditto;
> (TARGET_ZKNE):   Ditto;
> (TARGET_ZKND):   Ditto;
> (TARGET_ZKNH):   Ditto;
> (TARGET_ZKR):Ditto;
> (TARGET_ZKSED):  Ditto;
> (TARGET_ZKSH):   Ditto;
> (TARGET_ZKT):Ditto;
> (MASK_ZTSO): Ditto;
> (TARGET_ZTSO):   Ditto;
> (MASK_VECTOR_ELEN_32):   Ditto;
> (MASK_VECTOR_ELEN_64):   Ditto;
> (MASK_VECTOR_ELEN_FP_32):Ditto;
> (MASK_VECTOR_ELEN_FP_64):Ditto;
> (MASK_VECTOR_ELEN_FP_16):Ditto;
> (TARGET_VECTOR_ELEN_32): Ditto;
> (TARGET_VECTOR_ELEN_64): Ditto;
> (TARGET_VECTOR_ELEN_FP_32):Ditto;
> (TARGET_VECTOR_ELEN_FP_64):Ditto;
> (TARGET_VECTOR_ELEN_FP_16):Ditto;
>  (MASK_ZVBB):   Ditto;
> (MASK_ZVBC):   Ditto;
> (TARGET_ZVBB): Ditto;
> (TARGET_ZVBC): Ditto;
> (MASK_ZVKG):   Ditto;
> (MASK_ZVKNED): Ditto;
> (MASK_ZVKNHA): Ditto;
> (MASK_ZVKNHB): Ditto;
> (MASK_ZVKSED): Ditto;
> (MASK_ZVKSH):  Ditto;
> (MASK_ZVKN):   Ditto;
> (MASK_ZVKNC):  Ditto;
> (MASK_ZVKNG):  Ditto;
> (MASK_ZVKS):   Ditto;
> (MASK_ZVKSC):  Ditto;
> (MASK_ZVKSG):  Ditto;
> (MASK_ZVKT):   Ditto;
> (TARGET_ZVKG): Ditto;
> (TARGET_ZVKNED):   Ditto;
> (TARGET_ZVKNHA):   Ditto;
> (TARGET_ZVKNHB):   Ditto;
> (TARGET_ZVKSED):   Ditto;
> (TARGET_ZVKSH):Ditto;
> (TARGET_ZVKN): Ditto;
> (TARGET_ZVKNC):Ditto;
> (TARGET_ZVKNG):Ditto;
> (TARGET_ZVKS): Ditto;
> (TARGET_ZVKSC):Ditto;
> (TARGET_ZVKSG):Ditto;
> (TARGET_ZVKT): Ditto;
> (MASK_ZVL32B): Ditto;
> (MASK_ZVL64B): Ditto;
> (MASK_ZVL128B):Ditto;
> (MASK_ZVL256B):Ditto;
> (MASK_ZVL512B):Ditto;
> (MASK_ZVL1024B):   Ditto;
> (MASK_ZVL2048B):   Ditto;
> (MASK_ZVL4096B):   Ditto;
> (MASK_ZVL8192B):   Ditto;
> (MASK_ZVL16384B):  Ditto;
> (MASK_ZVL32768B):  Ditto;
> (MASK_ZVL65536B):  Ditto;
> (TARGET_ZVL32B):   Ditto;
> (TARGET_ZVL64B):   Ditto;
> (TARGET_ZVL128B):  Ditto;
> (TARGET_ZVL256B):  Ditto;
> (TARGET_ZVL512B):  Ditto;
> (TARGET_ZVL1024B): Ditto;
> (TARGET_ZVL2048B): Ditto;
> (TARGET_ZVL4096B): Ditto;
> (TARGET_ZVL8192B): Ditto;
> (TARGET_ZVL16384B):Ditto;
> (TARGET_ZVL32768B):Ditto;
> (TARGET_ZVL65536B):Ditto;
> (MASK_ZICBOZ): Ditto;
> (MASK_ZICBOM): Ditto;
> (MASK_ZICBOP): 

Re:[pushed] [PATCH v6 0/4] Add Loongson SX/ASX instruction support to LoongArch target.

[chenglulu]

Pushed to r14-3700.

在 2023/8/31 下午5:08, Chenghui Pan 写道:

This is an update of:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628303.html

Changes since last version of patch set:
- "dg-skip-if"-related Changes of the g++.dg/torture/vshuf* testcases are 
reverted.
   (Replaced by __builtin_shuffle fix)
- Add fix of __builtin_shuffle() for Loongson SX/ASX (Implemeted by adding
   vand/xvand insn in front of shuffle operation). There's no significant 
performance
   impact in current state.
- Rebased on the top of Yang Yujie's latest target configuration interface 
patch set
   (https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628772.html).

Brief history of patch set:
v1 -> v2:
- Reduce usage of "unspec" in RTL template.
- Append Support of ADDR_REG_REG in LSX and LASX.
- Constraint docs are appended in gcc/doc/md.texi and ccomment block.
- Codes related to vecarg are removed.
- Testsuite of LSX and LASX is added in v2. (Because of the size limitation of
   mail list, these patches are not shown)
- Adjust the loongarch_expand_vector_init() function to reduce instruction
output amount.
- Some minor implementation changes of RTL templates.

v2 -> v3:
- Revert vabsd/xvabsd RTL templates to unspec impl.
- Resolve warning in gcc/config/loongarch/loongarch.cc when bootstrapping
   with BOOT_CFLAGS="-O2 -ftree-vectorize -fno-vect-cost-model -mlasx".
- Remove redundant definitions in lasxintrin.h.
- Refine commit info.

v3 -> v4:
- Code simplification.
- Testsuite patches are splited from this patch set again and will be
   submitted independently in the future.

v4 -> v5:
- Regression test fix (pr54346.c)
- Combine vilvh/xvilvh insn's RTL template impl.
- Add dg-skip-if for loongarch*-*-* in vshuf test inside g++.dg/torture
   (reverted in this version)

Lulu Cheng (4):
   LoongArch: Add Loongson SX base instruction support.
   LoongArch: Add Loongson SX directive builtin function support.
   LoongArch: Add Loongson ASX base instruction support.
   LoongArch: Add Loongson ASX directive builtin function support.

  gcc/config.gcc|2 +-
  gcc/config/loongarch/constraints.md   |  131 +-
  gcc/config/loongarch/genopts/loongarch.opt.in |4 +
  gcc/config/loongarch/lasx.md  | 5104 
  gcc/config/loongarch/lasxintrin.h | 5338 +
  gcc/config/loongarch/loongarch-builtins.cc| 2686 -
  gcc/config/loongarch/loongarch-ftypes.def |  666 +-
  gcc/config/loongarch/loongarch-modes.def  |   39 +
  gcc/config/loongarch/loongarch-protos.h   |   35 +
  gcc/config/loongarch/loongarch.cc | 4751 ++-
  gcc/config/loongarch/loongarch.h  |  117 +-
  gcc/config/loongarch/loongarch.md |   56 +-
  gcc/config/loongarch/loongarch.opt|4 +
  gcc/config/loongarch/lsx.md   | 4467 ++
  gcc/config/loongarch/lsxintrin.h  | 5181 
  gcc/config/loongarch/predicates.md|  333 +-
  gcc/doc/md.texi   |   11 +
  17 files changed, 28645 insertions(+), 280 deletions(-)
  create mode 100644 gcc/config/loongarch/lasx.md
  create mode 100644 gcc/config/loongarch/lasxintrin.h
  create mode 100644 gcc/config/loongarch/lsx.md
  create mode 100644 gcc/config/loongarch/lsxintrin.h

Re: [PING][PATCH] LoongArch: initial ada support on linux

[Marc Poulhiès via Gcc-patches]

Yujie Yang  writes:
> Hi Marc,
>
> Thank you for the review!
>
> We added -gnatea and -gnatez to CC1_SPECS for correct multilib handling,
> and I believe this is currently specific to LoongArch.
>
> LoongArch relies on the GCC driver (via self_specs rules) to generate a
> canonicalized tuple of parameters that identifies the current target (ISA/ABI)
> configuration, including the "-mabi=" option that corresponds to the selected
> multilib variant.  Even if "-mabi=" itself is not given explicitly to gcc, it
> may be fed to the compiler propers with values other than the default ABI.
>
> For GNAT on LoongArch, it is necessary that -mabi= generated by driver
> self-specs gets stored in the .ali file, otherwise the linker might
> hit the wrong multilib variant by assuming the default ABI.  Using
> -gnatea/-gnatez can mark the driver-generated "-mabi=" as "explicit",
> so it is sure to be found in "A"-records of the generated *.ali file.

Hello Yujie,

Thanks for the explanation!

Marc

[COMMITTED] ada: Elide the copy in extended returns for nonlimited by-reference types

[Marc Poulhiès via Gcc-patches]

From: Eric Botcazou 

gcc/ada/

* gcc-interface/trans.cc (gnat_to_gnu): Really test Storage_Pool on
the simple return statement.

Tested on x86_64-pc-linux-gnu, committed on master.

---
 gcc/ada/gcc-interface/trans.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/ada/gcc-interface/trans.cc b/gcc/ada/gcc-interface/trans.cc
index 5d93060c6d8..e99fbb4eb5e 100644
--- a/gcc/ada/gcc-interface/trans.cc
+++ b/gcc/ada/gcc-interface/trans.cc
@@ -8519,7 +8519,7 @@ gnat_to_gnu (Node_Id gnat_node)
   && ((Nkind (Parent (gnat_node)) == N_Attribute_Reference
&& lvalue_required_for_attribute_p (Parent (gnat_node)))
   || (Nkind (Parent (gnat_node)) == N_Simple_Return_Statement
-  && No (Storage_Pool (gnat_node)
+  && No (Storage_Pool (Parent (gnat_node))
 ;
 
   else if (TREE_TYPE (gnu_result) != gnu_result_type)
-- 
2.40.0

[COMMITTED] ada: Fix spurious warning emissions

[Marc Poulhiès via Gcc-patches]

From: Ronan Desplanques 

Before this patch, warnings handled by `Sem_Warn.Check_References` were
erroneously emitted in some cases. Here is an example of a program that,
when compiled with the `-gnatwu` switch, triggered the bug:

procedure Main is
   package T is
  A : Integer;
   end T;
begin
   T.A := 7;
end Main;

The following message was emitted:

   main.adb:3:07: warning: variable "A" is never read and never assigned 
[-gnatwu]

This patch mitigates the issue by restricting the cases in which
`Sem_Warn.Check_References` is called for package specifications.

Note that the recursive calls in `Sem_Warn.Check_References` can be used
to convince oneself that this patch does not remove legitimate warnings
for non-library-level package specifications.

gcc/ada/

* sem_ch7.adb (Analyze_Package_Declaration): Restrict calls to
`Sem_Warn.Check_References` and adjust comment accordingly.

Tested on x86_64-pc-linux-gnu, committed on master.

---
 gcc/ada/sem_ch7.adb | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/gcc/ada/sem_ch7.adb b/gcc/ada/sem_ch7.adb
index ecb4bbe3e56..1a49a53ad63 100644
--- a/gcc/ada/sem_ch7.adb
+++ b/gcc/ada/sem_ch7.adb
@@ -1267,12 +1267,17 @@ package body Sem_Ch7 is
Is_Main_Unit => Parent (N) = Cunit (Main_Unit));
  end if;
 
- --  Warn about references to unset objects, which is straightforward
- --  for packages with no bodies. For packages with bodies this is more
- --  complicated, because some of the objects might be set between spec
- --  and body elaboration, in nested or child packages, etc.
-
- Check_References (Id);
+ --  For package declarations at the library level, warn about
+ --  references to unset objects, which is straightforward for packages
+ --  with no bodies. For packages with bodies this is more complicated,
+ --  because some of the objects might be set between spec and body
+ --  elaboration, in nested or child packages, etc. Note that the
+ --  recursive calls in Check_References will handle nested package
+ --  specifications.
+
+ if Is_Library_Level_Entity (Id) then
+Check_References (Id);
+ end if;
   end if;
 
   --  Set Body_Required indication on the compilation unit node
-- 
2.40.0

Re: [PATCH v1] RISC-V: Support FP SGNJ autovec for VLS mode

[juzhe.zh...@rivai.ai]

LGTM



juzhe.zh...@rivai.ai
 
From: pan2.li
Date: 2023-09-05 18:32
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support FP SGNJ autovec for VLS mode
From: Pan Li 
 
This patch would like to allow the VLS mode autovec for the
floating-point binary operation MAX/MIN.
 
Given below code example:
 
void test(float * restrict out, float * restrict in1, float * restrict in2)
{
  for (int i = 0; i < 128; i++)
out[i] = __builtin_copysignf (in1[i], in2[i]);
}
 
Before this patch:
test:
  csrra4,vlenb
  sllia4,a4,1
  li  a5,128
  bleua5,a4,.L2
  mv  a5,a4
.L2:
  vsetvli zero,a5,e32,m8,ta,ma
  vle32.v v8,0(a1)
  vle32.v v16,0(a2)
  vsetvli a4,zero,e32,m8,ta,ma
  vfsgnj.vv   v8,v8,v16
  vsetvli zero,a5,e32,m8,ta,ma
  vse32.v v8,0(a0)
  ret
 
After this patch:
test:
  li  a5,128
  vsetvli zero,a5,e32,m1,ta,ma
  vle32.v v1,0(a1)
  vle32.v v2,0(a2)
  vfsgnj.vv   v1,v1,v2
  vse32.v v1,0(a0)
  ret
 
Signed-off-by: Pan Li 
 
gcc/ChangeLog:
 
* config/riscv/autovec-vls.md (copysign3): New pattern.
* config/riscv/vector.md: Extend iterator for VLS.
 
gcc/testsuite/ChangeLog:
 
* gcc.target/riscv/rvv/autovec/vls/def.h: New macro.
* gcc.target/riscv/rvv/autovec/vls/floating-point-sgnj-1.c: New test.
* gcc.target/riscv/rvv/autovec/vls/floating-point-sgnj-2.c: New test.
---
gcc/config/riscv/autovec-vls.md   | 22 ++
gcc/config/riscv/vector.md| 24 +--
.../gcc.target/riscv/rvv/autovec/vls/def.h|  8 
.../rvv/autovec/vls/floating-point-sgnj-1.c   | 43 +++
.../rvv/autovec/vls/floating-point-sgnj-2.c   | 43 +++
5 files changed, 128 insertions(+), 12 deletions(-)
create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/floating-point-sgnj-1.c
create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/floating-point-sgnj-2.c
 
diff --git a/gcc/config/riscv/autovec-vls.md b/gcc/config/riscv/autovec-vls.md
index 7ef29637e33..31b6c4ae714 100644
--- a/gcc/config/riscv/autovec-vls.md
+++ b/gcc/config/riscv/autovec-vls.md
@@ -255,6 +255,28 @@ (define_insn_and_split "3"
[(set_attr "type" "vector")]
)
+;; -
+;; Includes:
+;; - vfsgnj.vv
+;; - vfsgnj.vf
+;; -
+(define_insn_and_split "copysign3"
+  [(set (match_operand:VLSF 0 "register_operand")
+(unspec:VLSF
+  [(match_operand:VLSF  1 "register_operand")
+   (match_operand:VLSF  2 "register_operand")] UNSPEC_VCOPYSIGN))]
+  "TARGET_VECTOR && can_create_pseudo_p ()"
+  "#"
+  "&& 1"
+  [(const_int 0)]
+  {
+riscv_vector::emit_vlmax_insn (code_for_pred (UNSPEC_VCOPYSIGN, 
mode),
+riscv_vector::BINARY_OP, operands);
+DONE;
+  }
+  [(set_attr "type" "vector")]
+)
+
;; 
---
;;  [INT] Unary operations
;; 
---
diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md
index 9d7b4bbe1d4..fc985ff6a01 100644
--- a/gcc/config/riscv/vector.md
+++ b/gcc/config/riscv/vector.md
@@ -6166,8 +6166,8 @@ (define_insn "@pred__reverse_scalar"
(symbol_ref "riscv_vector::get_frm_mode (operands[9])"))])
(define_insn "@pred_"
-  [(set (match_operand:VF 0 "register_operand"   "=vd, vd, vr, vr")
- (if_then_else:VF
+  [(set (match_operand:V_VLSF 0 "register_operand"   "=vd, vd, vr, vr")
+ (if_then_else:V_VLSF
  (unspec:
[(match_operand: 1 "vector_mask_operand" " vm, vm,Wc1,Wc1")
 (match_operand 5 "vector_length_operand"" rK, rK, rK, rK")
@@ -6176,10 +6176,10 @@ (define_insn "@pred_"
 (match_operand 8 "const_int_operand""  i,  i,  i,  i")
 (reg:SI VL_REGNUM)
 (reg:SI VTYPE_REGNUM)] UNSPEC_VPREDICATE)
-   (unspec:VF
- [(match_operand:VF 3 "register_operand"   " vr, vr, vr, vr")
-  (match_operand:VF 4 "register_operand"   " vr, vr, vr, vr")] 
VCOPYSIGNS)
-   (match_operand:VF 2 "vector_merge_operand" " vu,  0, vu,  0")))]
+   (unspec:V_VLSF
+ [(match_operand:V_VLSF 3 "register_operand"  " vr, vr, vr, vr")
+  (match_operand:V_VLSF 4 "register_operand"  " vr, vr, vr, vr")] 
VCOPYSIGNS)
+   (match_operand:V_VLSF 2 "vector_merge_operand" " vu,  0, vu,  0")))]
   "TARGET_VECTOR"
   "vfsgnj.vv\t%0,%3,%4%p1"
   [(set_attr "type" "vfsgnj")
@@ -6207,8 +6207,8 @@ (define_insn "@pred_ncopysign"
(set_attr "mode" "")])
(define_insn "@pred__scalar"
-  [(set (match_operand:VF 0 "register_operand"   "=vd, vd, vr, vr")
- (if_then_else:VF
+  [(set (match_operand:V_VLSF 0 "register_operand"   "=vd, vd, vr, vr")
+ (if_then_else:V_VLSF
  (unspec:
[(match_operand: 1 "vector_mask_operand" " vm, vm,Wc1,Wc1")
 (match_operand 5 "vector_length_operand"" rK, rK, rK, rK")
@@ -6217,11 +6217,11 @@ (define_insn "@pred__scalar"
 

[COMMITTED] ada: Support setting task affinity on QNX

[Marc Poulhiès via Gcc-patches]

From: Johannes Kliemann 

QNX does not support setting the thread affinity via a POSIX API.
This implementation uses QNX's native Thread_Ctl API to set the
thread affinity for Ada tasks.

gcc/ada/

* libgnarl/s-taprop__qnx.adb: Implement Set_Task_Affinity.

Tested on x86_64-pc-linux-gnu, committed on master.

---
 gcc/ada/libgnarl/s-taprop__qnx.adb | 45 ++
 1 file changed, 40 insertions(+), 5 deletions(-)

diff --git a/gcc/ada/libgnarl/s-taprop__qnx.adb 
b/gcc/ada/libgnarl/s-taprop__qnx.adb
index 13335ef4acd..423229854a8 100644
--- a/gcc/ada/libgnarl/s-taprop__qnx.adb
+++ b/gcc/ada/libgnarl/s-taprop__qnx.adb
@@ -49,6 +49,7 @@ with System.Interrupt_Management;
 with System.OS_Constants;
 with System.OS_Primitives;
 with System.Task_Info;
+with System.Multiprocessors;
 
 with System.Soft_Links;
 --  We use System.Soft_Links instead of System.Tasking.Initialization
@@ -1317,12 +1318,46 @@ package body System.Task_Primitives.Operations is
---
 
procedure Set_Task_Affinity (T : ST.Task_Id) is
-  pragma Unreferenced (T);
-
+  use type Multiprocessors.CPU_Range;
+
+  function Thread_Ctl_Ext
+(Pid : pid_t;
+ Tid : Thread_Id;
+ Command : Interfaces.C.unsigned;
+ Runmask : Interfaces.C.size_t) return Interfaces.C.int
+  with
+Import, Convention => C, External_Name => "ThreadCtlExt";
+  --  Thread_Ctl_Ext is a generic thread control function in QNX.
+  --  It is defined locally because in the C API its second
+  --  argument is a void pointer that takes different actual
+  --  pointer types or values depending on the command. This
+  --  particular instance of this function only accepts the
+  --  NTO_TCTL_RUNMASK command. The void * pointer in the C
+  --  interface is interpreted as bitmask for this command.
+  --  In the binding size_t is used as an integer type that
+  --  always has the same size as a pointer.
+
+  NTO_TCTL_RUNMASK : constant := 4;
+  --  Command for Thread_Ctl. Using this command in Thread_Ctl
+  --  allows the caller to pass a bitmask that describes on
+  --  which CPU the current thread is allowed to run on.
+
+  Pid : constant pid_t := getpid;
+  Result  : Interfaces.C.int;
+  Runmask : Interfaces.C.size_t;
+  --  Each set bit in runmask represents a processor that the thread
+  --  can run on. If all bits are set to one the thread can run on any CPU.
begin
-  --  Setting task affinity is not supported by the underlying system
-
-  null;
+  if T.Common.Base_CPU = Multiprocessors.Not_A_Specific_CPU then
+ Runmask := Interfaces.C.size_t'Last;
+  else
+ Runmask :=
+   Interfaces.C.size_t
+ (2 ** Natural (T.Common.Base_CPU - Multiprocessors.CPU'First));
+  end if;
+  Result :=
+ Thread_Ctl_Ext (Pid, Get_Thread_Id (T), NTO_TCTL_RUNMASK, Runmask);
+  pragma Assert (Result = 0);
end Set_Task_Affinity;
 
 end System.Task_Primitives.Operations;
-- 
2.40.0

[COMMITTED] ada: building_executable_programs_with_gnat.rst: fix -gnatw.x index

[Marc Poulhiès via Gcc-patches]

From: Ghjuvan Lacambre 

The index for this paragraph was wrong.

gcc/ada/

* doc/gnat_ugn/building_executable_programs_with_gnat.rst: Fix
index.
* gnat_ugn.texi: Regenerate.

Tested on x86_64-pc-linux-gnu, committed on master.

---
 .../doc/gnat_ugn/building_executable_programs_with_gnat.rst   | 2 +-
 gcc/ada/gnat_ugn.texi | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst 
b/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst
index 8e479679ec1..6c0d2b34a92 100644
--- a/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst
+++ b/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst
@@ -4095,7 +4095,7 @@ of the pragma in the :title:`GNAT_Reference_manual`).
   should not complain at you.
 
 
-.. index:: -gnatwm  (gcc)
+.. index:: -gnatw.x  (gcc)
 
 :switch:`-gnatw.x`
   *Activate warnings for No_Exception_Propagation mode.*
diff --git a/gcc/ada/gnat_ugn.texi b/gcc/ada/gnat_ugn.texi
index 78f9b87a82e..7c5926eba64 100644
--- a/gcc/ada/gnat_ugn.texi
+++ b/gcc/ada/gnat_ugn.texi
@@ -19,7 +19,7 @@
 
 @copying
 @quotation
-GNAT User's Guide for Native Platforms , Jul 17, 2023
+GNAT User's Guide for Native Platforms , Aug 31, 2023
 
 AdaCore
 
@@ -12578,7 +12578,7 @@ you know what you are doing in writing the pragma, and 
it
 should not complain at you.
 @end table
 
-@geindex -gnatwm (gcc)
+@geindex -gnatw.x (gcc)
 
 
 @table @asis
-- 
2.40.0

[COMMITTED] ada: Remove redundant protection against empty list

[Marc Poulhiès via Gcc-patches]

From: Piotr Trojanek 

Calls to First on No_List intentionally return Empty, so explicit guards
against No_List are unnecessary. Code cleanup; semantics is unaffected.

gcc/ada/

* sem_type.adb (Interface_Present_In_Ancestor): Remove guard against no
list of interfaces; fix style in comments (trailing dots).

Tested on x86_64-pc-linux-gnu, committed on master.

---
 gcc/ada/sem_type.adb | 40 +++-
 1 file changed, 19 insertions(+), 21 deletions(-)

diff --git a/gcc/ada/sem_type.adb b/gcc/ada/sem_type.adb
index 8579130cdac..40de2951e20 100644
--- a/gcc/ada/sem_type.adb
+++ b/gcc/ada/sem_type.adb
@@ -2649,34 +2649,32 @@ package body Sem_Type is
   --  In case of concurrent types we can't use the Corresponding Record_Typ
   --  to look for the interface because it is built by the expander (and
   --  hence it is not always available). For this reason we traverse the
-  --  list of interfaces (available in the parent of the concurrent type)
+  --  list of interfaces (available in the parent of the concurrent type).
 
   if Is_Concurrent_Type (Target_Typ) then
- if Present (Interface_List (Parent (Target_Typ))) then
-declare
-   AI : Node_Id;
+ declare
+AI : Node_Id;
 
-begin
-   AI := First (Interface_List (Parent (Target_Typ)));
+ begin
+AI := First (Interface_List (Parent (Target_Typ)));
 
-   --  The progenitor itself may be a subtype of an interface type.
+--  The progenitor itself may be a subtype of an interface type
 
-   while Present (AI) loop
-  if Etype (AI) = Iface_Typ
-or else Base_Type (Etype (AI)) = Iface_Typ
-  then
- return True;
+while Present (AI) loop
+   if Etype (AI) = Iface_Typ
+ or else Base_Type (Etype (AI)) = Iface_Typ
+   then
+  return True;
 
-  elsif Present (Interfaces (Etype (AI)))
-and then Iface_Present_In_Ancestor (Etype (AI))
-  then
- return True;
-  end if;
+   elsif Present (Interfaces (Etype (AI)))
+ and then Iface_Present_In_Ancestor (Etype (AI))
+   then
+  return True;
+   end if;
 
-  Next (AI);
-   end loop;
-end;
- end if;
+   Next (AI);
+end loop;
+ end;
 
  return False;
   end if;
-- 
2.40.0

[COMMITTED] ada: Fix problematic secondary stack management in protected entry

[Marc Poulhiès via Gcc-patches]

From: Eric Botcazou 

The secondary stack mark goes formally out of scope before the finalizer
reads it to reclaim the storage.

gcc/ada/

* exp_ch9.adb (Build_Protected_Entry): Move the At_End procedure
from the entry body to the inner block statement.

Tested on x86_64-pc-linux-gnu, committed on master.

---
 gcc/ada/exp_ch9.adb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/ada/exp_ch9.adb b/gcc/ada/exp_ch9.adb
index b0e3632b8c8..5dcd890c33c 100644
--- a/gcc/ada/exp_ch9.adb
+++ b/gcc/ada/exp_ch9.adb
@@ -3457,6 +3457,7 @@ package body Exp_Ch9 is
   Set_Uses_Sec_Stack (Block_Id, Uses_Sec_Stack (Corresponding_Spec (N)));
 
   Reset_Scopes_To (First (Bod_Stmts), Block_Id);
+  Set_At_End_Proc (First (Bod_Stmts), At_End_Proc (N));
 
   case Corresponding_Runtime_Package (Pid) is
  when System_Tasking_Protected_Objects_Entries =>
@@ -3553,7 +3554,6 @@ package body Exp_Ch9 is
  --  Establish link between subprogram body and source entry body
 
  Set_Corresponding_Entry_Body (Proc_Body, N);
- Set_At_End_Proc (Proc_Body, At_End_Proc (N));
 
  Reset_Scopes_To (Proc_Body, Protected_Body_Subprogram (Ent));
  return Proc_Body;
-- 
2.40.0

[COMMITTED] ada: Preserve capability validity in address arithmetic

[Marc Poulhiès via Gcc-patches]

From: Daniel King 

On CHERI targets where System.Address is a capability, arithmetic on
addresses should avoid converting to integers and instead use the
operations defined in System.Storage_Elements to perform the arithmetic
directly on the System.Address object. This preserves the capability's
validity throughout the calculation, ensuring that the resulting capability
can be dereferenced.

gcc/ada/

* libgnat/s-carsi8.adb: Use operations from
System.Storage_Elements for address arithmetic.
* libgnat/s-carun8.adb: Likewise
* libgnat/s-casi128.adb: Likewise
* libgnat/s-casi16.adb: Likewise
* libgnat/s-casi32.adb: Likewise
* libgnat/s-casi64.adb: Likewise
* libgnat/s-caun128.adb: Likewise
* libgnat/s-caun16.adb: Likewise
* libgnat/s-caun32.adb: Likewise
* libgnat/s-caun64.adb: Likewise
* libgnat/s-geveop.adb: Likewise

Tested on x86_64-pc-linux-gnu, committed on master.

---
 gcc/ada/libgnat/s-carsi8.adb  |  9 
 gcc/ada/libgnat/s-carun8.adb  |  9 
 gcc/ada/libgnat/s-casi128.adb |  9 
 gcc/ada/libgnat/s-casi16.adb  | 13 ++-
 gcc/ada/libgnat/s-casi32.adb  |  9 
 gcc/ada/libgnat/s-casi64.adb  |  9 
 gcc/ada/libgnat/s-caun128.adb |  9 
 gcc/ada/libgnat/s-caun16.adb  | 13 ++-
 gcc/ada/libgnat/s-caun32.adb  |  9 
 gcc/ada/libgnat/s-caun64.adb  |  9 
 gcc/ada/libgnat/s-geveop.adb  | 43 ++-
 11 files changed, 76 insertions(+), 65 deletions(-)

diff --git a/gcc/ada/libgnat/s-carsi8.adb b/gcc/ada/libgnat/s-carsi8.adb
index 839f157a2ee..3946d474dd9 100644
--- a/gcc/ada/libgnat/s-carsi8.adb
+++ b/gcc/ada/libgnat/s-carsi8.adb
@@ -30,6 +30,7 @@
 --
 
 with System.Address_Operations; use System.Address_Operations;
+with System.Storage_Elements;   use System.Storage_Elements;
 
 with Ada.Unchecked_Conversion;
 
@@ -94,8 +95,8 @@ package body System.Compare_Array_Signed_8 is
  for J in 0 .. Words_To_Compare - 1 loop
 if LeftP (J) /= RightP (J) then
return Compare_Array_S8_Unaligned
-(AddA (Left,  Address (4 * J)),
- AddA (Right, Address (4 * J)),
+(Left  + Storage_Offset (4 * J),
+ Right + Storage_Offset (4 * J),
  4, 4);
 end if;
  end loop;
@@ -108,8 +109,8 @@ package body System.Compare_Array_Signed_8 is
  --* Words_To_Compare = Compare_Len / 4
  --* Bytes_Compared_As_Words = Words_To_Compare * 4
  return Compare_Array_S8_Unaligned
-  (AddA (Left,  Address (Bytes_Compared_As_Words)),
-   AddA (Right, Address (Bytes_Compared_As_Words)),
+(Left  + Storage_Offset (Bytes_Compared_As_Words),
+ Right + Storage_Offset (Bytes_Compared_As_Words),
Left_Len  - Bytes_Compared_As_Words,
Right_Len - Bytes_Compared_As_Words);
   end;
diff --git a/gcc/ada/libgnat/s-carun8.adb b/gcc/ada/libgnat/s-carun8.adb
index b20e4e1b922..e6938def56a 100644
--- a/gcc/ada/libgnat/s-carun8.adb
+++ b/gcc/ada/libgnat/s-carun8.adb
@@ -30,6 +30,7 @@
 --
 
 with System.Address_Operations; use System.Address_Operations;
+with System.Storage_Elements;   use System.Storage_Elements;
 
 with Ada.Unchecked_Conversion;
 
@@ -93,8 +94,8 @@ package body System.Compare_Array_Unsigned_8 is
  for J in 0 .. Words_To_Compare - 1 loop
 if LeftP (J) /= RightP (J) then
return Compare_Array_U8_Unaligned
-(AddA (Left,  Address (4 * J)),
- AddA (Right, Address (4 * J)),
+(Left  + Storage_Offset (4 * J),
+ Right + Storage_Offset (4 * J),
  4, 4);
 end if;
  end loop;
@@ -107,8 +108,8 @@ package body System.Compare_Array_Unsigned_8 is
  --* Words_To_Compare = Compare_Len / 4
  --* Bytes_Compared_As_Words = Words_To_Compare * 4
  return Compare_Array_U8_Unaligned
-  (AddA (Left,  Address (Bytes_Compared_As_Words)),
-   AddA (Right, Address (Bytes_Compared_As_Words)),
+  (Left  + Storage_Offset (Bytes_Compared_As_Words),
+   Right + Storage_Offset (Bytes_Compared_As_Words),
Left_Len  - Bytes_Compared_As_Words,
Right_Len - Bytes_Compared_As_Words);
   end;
diff --git a/gcc/ada/libgnat/s-casi128.adb b/gcc/ada/libgnat/s-casi128.adb
index 2b0caac75b2..91569e1091d 100644
--- a/gcc/ada/libgnat/s-casi128.adb
+++ b/gcc/ada/libgnat/s-casi128.adb
@@ -30,6 +30,7 @@
 

[COMMITTED] ada: Add guard before querying the type for its interfaces

[Marc Poulhiès via Gcc-patches]

From: Piotr Trojanek 

Fix crash on illegal code, when routine Iface_Present_In_Ancestor is
called on the predefined String type and attempts to examine the list of
interfaces.

gcc/ada/

* sem_type.adb (Iface_Present_In_Ancestor): Only look at the list of
interfaces for types that allow it. The guard is a high-level equivalent
of the entity kinds listed in the preconditon of the Interfaces query.

Tested on x86_64-pc-linux-gnu, committed on master.

---
 gcc/ada/sem_type.adb | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/ada/sem_type.adb b/gcc/ada/sem_type.adb
index bbdcd5f24b8..8579130cdac 100644
--- a/gcc/ada/sem_type.adb
+++ b/gcc/ada/sem_type.adb
@@ -2578,7 +2578,9 @@ package body Sem_Type is
  end if;
 
  loop
-if Present (Interfaces (E)) then
+if Is_Record_Type (E)
+  and then Present (Interfaces (E))
+then
Elmt := First_Elmt (Interfaces (E));
while Present (Elmt) loop
   AI := Node (Elmt);
-- 
2.40.0

[COMMITTED] ada: Fix DWARF for certain arrays

[Marc Poulhiès via Gcc-patches]

From: Tom Tromey 

An array whose index type is a nonstandard enum will be marked as
"packed", but should not emit DW_AT_bit_stride unless it is also
bit-packed.

gcc/ada/

* gcc-interface/decl.cc (gnat_to_gnu_entity): Set bit-packed for
constrained and unconstrained array types.
* gcc-interface/misc.cc (gnat_get_array_descr_info): Examine
BIT_PACKED_ARRAY_TYPE_P.

Tested on x86_64-pc-linux-gnu, committed on master.

---
 gcc/ada/gcc-interface/decl.cc |  8 +++-
 gcc/ada/gcc-interface/misc.cc | 14 +++---
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/gcc/ada/gcc-interface/decl.cc b/gcc/ada/gcc-interface/decl.cc
index ae756b35fdb..0cf7d3cee60 100644
--- a/gcc/ada/gcc-interface/decl.cc
+++ b/gcc/ada/gcc-interface/decl.cc
@@ -2388,6 +2388,11 @@ gnat_to_gnu_entity (Entity_Id gnat_entity, tree 
gnu_expr, bool definition)
  = (Is_Packed (gnat_entity)
 || Is_Packed_Array_Impl_Type (gnat_entity));
 
+   TYPE_BIT_PACKED_ARRAY_TYPE_P (tem)
+ = (Is_Packed_Array_Impl_Type (gnat_entity)
+? Is_Bit_Packed_Array (Original_Array_Type (gnat_entity))
+: Is_Bit_Packed_Array (gnat_entity));
+
if (Treat_As_Volatile (gnat_entity))
  tem = change_qualified_type (tem, TYPE_QUAL_VOLATILE);
 
@@ -2815,7 +2820,8 @@ gnat_to_gnu_entity (Entity_Id gnat_entity, tree gnu_expr, 
bool definition)
 
  TYPE_BIT_PACKED_ARRAY_TYPE_P (gnu_type)
= (Is_Packed_Array_Impl_Type (gnat_entity)
-  && Is_Bit_Packed_Array (Original_Array_Type (gnat_entity)));
+  ? Is_Bit_Packed_Array (Original_Array_Type (gnat_entity))
+  : Is_Bit_Packed_Array (gnat_entity));
 
  /* If the maximum size doesn't overflow, use it.  */
  if (gnu_max_size
diff --git a/gcc/ada/gcc-interface/misc.cc b/gcc/ada/gcc-interface/misc.cc
index 30319ae58b1..3b21bf5b43a 100644
--- a/gcc/ada/gcc-interface/misc.cc
+++ b/gcc/ada/gcc-interface/misc.cc
@@ -774,7 +774,7 @@ gnat_get_array_descr_info (const_tree const_type,
 {
   tree type = const_cast (const_type);
   tree first_dimen, dimen;
-  bool is_packed_array, is_array;
+  bool is_bit_packed_array, is_array;
   int i;
 
   /* Temporaries created in the first pass and used in the second one for thin
@@ -784,15 +784,15 @@ gnat_get_array_descr_info (const_tree const_type,
   tree thinptr_template_expr = NULL_TREE;
   tree thinptr_bound_field = NULL_TREE;
 
-  /* If we have an implementation type for a packed array, get the orignial
+  /* If we have an implementation type for a packed array, get the original
  array type.  */
   if (TYPE_IMPL_PACKED_ARRAY_P (type) && TYPE_ORIGINAL_PACKED_ARRAY (type))
 {
+  is_bit_packed_array = BIT_PACKED_ARRAY_TYPE_P (type);
   type = TYPE_ORIGINAL_PACKED_ARRAY (type);
-  is_packed_array = true;
 }
   else
-is_packed_array = false;
+is_bit_packed_array = false;
 
   /* First pass: gather all information about this array except everything
  related to dimensions.  */
@@ -850,8 +850,8 @@ gnat_get_array_descr_info (const_tree const_type,
  order, so our view here has reversed dimensions.  */
   const bool convention_fortran_p = TYPE_CONVENTION_FORTRAN_P (first_dimen);
 
-  if (TYPE_PACKED (first_dimen))
-is_packed_array = true;
+  if (BIT_PACKED_ARRAY_TYPE_P (first_dimen))
+is_bit_packed_array = true;
 
   /* ??? For row major ordering, we probably want to emit nothing and
  instead specify it as the default in Dw_TAG_compile_unit.  */
@@ -975,7 +975,7 @@ gnat_get_array_descr_info (const_tree const_type,
   /* We need to specify a bit stride when it does not correspond to the
 natural size of the contained elements.  ??? Note that we do not
 support packed records and nested packed arrays.  */
-  else if (is_packed_array)
+  else if (is_bit_packed_array)
{
  info->stride = get_array_bit_stride (info->element_type);
  info->stride_in_bits = true;
-- 
2.40.0

[COMMITTED] ada: Remove TBC comment, no more needed

[Marc Poulhiès via Gcc-patches]

From: Liaiss Merzougue 

gcc/ada/

* libgnat/s-imguti.adb: Remove comment.

Tested on x86_64-pc-linux-gnu, committed on master.

---
 gcc/ada/libgnat/s-imguti.adb | 1 -
 1 file changed, 1 deletion(-)

diff --git a/gcc/ada/libgnat/s-imguti.adb b/gcc/ada/libgnat/s-imguti.adb
index 2e69e630c8a..4b9e27a7d8f 100644
--- a/gcc/ada/libgnat/s-imguti.adb
+++ b/gcc/ada/libgnat/s-imguti.adb
@@ -231,7 +231,6 @@ package body System.Img_Util is
   begin
  pragma Assert (S >= Digs'First and E <= Digs'Last);
  --  S and E should be in the Digs array range
- --  TBC: Analysis should be completed
  for J in S .. E loop
 Set (Digs (J));
  end loop;
-- 
2.40.0

[COMMITTED] ada: Fix internal error on instantiation with private component type

[Marc Poulhiès via Gcc-patches]

From: Eric Botcazou 

First, this fixes an internal error on the instantiation of a nested generic
package taking an array type whose component type is a private type declared
in the parent package as formal type parameter. In the body of the instance,
the full view of the private type is visible and must be restored by means
of the Check_Generic_Actuals mechanism.

Second, this fixes the same internal error in the case where the component
type itself is an array type whose component type is a private type declared
in the parent package, i.e. when the formal type parameter is an array of
array type, by naturally extending the Has_Secondary_Private_View mechanism
to the array of array case.

gcc/ada/

* sem_ch12.adb (Component_Type_For_Private_View): New function.
(Check_Generic_Actuals): For an actual type parameter, also check
its component type if it is an array type.
(Check_Private_View): Use Component_Type_For_Private_View in the
case of an array type.
(Instantiate_Type): Likewise.
(Save_Global_References.Set_Global_Type): Likewise.

Tested on x86_64-pc-linux-gnu, committed on master.

---
 gcc/ada/sem_ch12.adb | 54 +++-
 1 file changed, 48 insertions(+), 6 deletions(-)

diff --git a/gcc/ada/sem_ch12.adb b/gcc/ada/sem_ch12.adb
index 61e0ec47392..c264f2a8283 100644
--- a/gcc/ada/sem_ch12.adb
+++ b/gcc/ada/sem_ch12.adb
@@ -582,6 +582,13 @@ package body Sem_Ch12 is
--  Recurse on an actual that is a formal package whose declaration has
--  a box.
 
+   function Component_Type_For_Private_View (T : Entity_Id) return Entity_Id;
+   --  Return the component type of array type T, with the following addition:
+   --  if this component type itself is an array type which has not been first
+   --  declared as private, then recurse on it. This makes it possible to deal
+   --  with arrays of arrays the same way as multi-dimensional arrays in the
+   --  mechanism handling private views.
+
function Contains_Instance_Of
  (Inner : Entity_Id;
   Outer : Entity_Id;
@@ -7084,10 +7091,27 @@ package body Sem_Ch12 is
and then Scope (Etype (E)) /= Instance
and then Is_Entity_Name (Subtype_Indication (Parent (E)))
  then
---  Restore the proper view of the actual from the information
---  saved earlier by Instantiate_Type.
+declare
+   Indic : constant Node_Id := Subtype_Indication (Parent (E));
+
+begin
+   --  Restore the proper view of the actual from the information
+   --  saved earlier by Instantiate_Type.
+
+   Check_Private_View (Indic);
 
-Check_Private_View (Subtype_Indication (Parent (E)));
+   --  If this view is an array type, check its component type.
+   --  This handles the case of an array type whose component
+   --  type is private, used as the actual in an instantiation
+   --  of a generic construct declared in the same package as
+   --  the component type and taking an array type with this
+   --  component type as formal type parameter.
+
+   if Is_Array_Type (Etype (Indic)) then
+  Check_Actual_Type
+(Component_Type_For_Private_View (Etype (Indic)));
+   end if;
+end;
 
 --  If the actual is itself the formal of a parent instance,
 --  then also restore the proper view of its actual and so on.
@@ -7759,7 +7783,8 @@ package body Sem_Ch12 is
 
 elsif Is_Array_Type (Typ) then
Check_Private_Type
- (Component_Type (Typ), Has_Secondary_Private_View (N));
+ (Component_Type_For_Private_View (Typ),
+  Has_Secondary_Private_View (N));
 
 elsif (Is_Record_Type (Typ) or else Is_Concurrent_Type (Typ))
   and then Has_Discriminants (Typ)
@@ -7821,6 +7846,21 @@ package body Sem_Ch12 is
   return Result;
end Check_Hidden_Primitives;
 
+   -
+   -- Component_Type_For_Private_View --
+   -
+
+   function Component_Type_For_Private_View (T : Entity_Id) return Entity_Id is
+  Typ : constant Entity_Id := Component_Type (T);
+
+   begin
+  if Is_Array_Type (Typ) and then not Has_Private_Declaration (Typ) then
+ return Component_Type_For_Private_View (Typ);
+  else
+ return Typ;
+  end if;
+   end Component_Type_For_Private_View;
+
--
-- Contains_Instance_Of --
--
@@ -14373,7 +14413,8 @@ package body Sem_Ch12 is
   elsif (Is_Access_Type (Act_T)
   and then Is_Private_Type (Designated_Type (Act_T)))
 or else (Is_Array_Type (Act_T)
-  and then Is_Private_Type (Component_Type (Act_T)))
+   

[COMMITTED] ada: Remove redundant guard against an empty list of interfaces

[Marc Poulhiès via Gcc-patches]

From: Piotr Trojanek 

Code cleanup; semantics is unaffected.

gcc/ada/

* sem_type.adb (Iface_Present_In_Ancestor): Remove guard for empty list
of interfaces; the following loop will work just fine without it.

Tested on x86_64-pc-linux-gnu, committed on master.

---
 gcc/ada/sem_type.adb | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/gcc/ada/sem_type.adb b/gcc/ada/sem_type.adb
index 00a64152df1..bbdcd5f24b8 100644
--- a/gcc/ada/sem_type.adb
+++ b/gcc/ada/sem_type.adb
@@ -2578,9 +2578,7 @@ package body Sem_Type is
  end if;
 
  loop
-if Present (Interfaces (E))
-  and then not Is_Empty_Elmt_List (Interfaces (E))
-then
+if Present (Interfaces (E)) then
Elmt := First_Elmt (Interfaces (E));
while Present (Elmt) loop
   AI := Node (Elmt);
-- 
2.40.0

[COMMITTED] ada: Crash on creation of extra formals on type extension

[Marc Poulhiès via Gcc-patches]

From: Javier Miranda 

The compiler blows up processing an overriding dispatching function
of a derived tagged type that returns a private tagged type that
has an access type discriminant.

gcc/ada/

* accessibility.ads (Needs_Result_Accessibility_Extra_Formal): New
subprogram.
* accessibility.adb (Needs_Result_Accessibility_Level_Param): New
subprogram.
(Needs_Result_Accessibility_Extra_Formal): New subprogram,
temporarily keep the previous behavior of the frontend.
* sem_ch6.adb (Create_Extra_Formals): Replace occurrences of
function Needs_Result_Accessibility_Level_Param by calls to
function Needs_Result_Accessibility_Extra_Formal.
(Extra_Formals_OK): Ditto.

Tested on x86_64-pc-linux-gnu, committed on master.

---
 gcc/ada/accessibility.adb | 54 +--
 gcc/ada/accessibility.ads | 12 -
 gcc/ada/sem_ch6.adb   |  8 +++---
 3 files changed, 67 insertions(+), 7 deletions(-)

diff --git a/gcc/ada/accessibility.adb b/gcc/ada/accessibility.adb
index bc897d1ef18..6b4ec5b9d24 100644
--- a/gcc/ada/accessibility.adb
+++ b/gcc/ada/accessibility.adb
@@ -56,6 +56,16 @@ with Tbuild; use Tbuild;
 
 package body Accessibility is
 
+   function Needs_Result_Accessibility_Level_Param
+ (Func_Id  : Entity_Id;
+  Func_Typ : Entity_Id) return Boolean;
+   --  Subsidiary of functions Needs_Result_Accessibility_Extra_Formal and
+   --  Needs_Result_Accessibility_Level_Param. Return True if the function
+   --  needs an implicit parameter to identify the accessibility level of
+   --  the function result "determined by the point of call". Func_Typ is
+   --  the function return type; this function returns False if Func_Typ is
+   --  Empty.
+
---
-- Accessibility_Message --
---
@@ -1892,6 +1902,34 @@ package body Accessibility is
and then Is_Explicitly_Aliased (Entity (Prefix (Exp)));
end Is_Special_Aliased_Formal_Access;
 
+   -
+   -- Needs_Result_Accessibility_Extra_Formal --
+   -
+
+   function Needs_Result_Accessibility_Extra_Formal
+ (Func_Id : Entity_Id) return Boolean
+   is
+  Func_Typ : Entity_Id;
+
+   begin
+  if Present (Underlying_Type (Etype (Func_Id))) then
+ Func_Typ := Underlying_Type (Etype (Func_Id));
+
+  --  Case of a function returning a private type which is not completed
+  --  yet. The support for this case is required because this function is
+  --  called to create the extra formals of dispatching primitives, and
+  --  they may be frozen before we see the full-view of their returned
+  --  private type.
+
+  else
+ --  Temporarily restore previous behavior
+ --  Func_Typ := Etype (Func_Id);
+ Func_Typ := Empty;
+  end if;
+
+  return Needs_Result_Accessibility_Level_Param (Func_Id, Func_Typ);
+   end Needs_Result_Accessibility_Extra_Formal;
+
--
-- Needs_Result_Accessibility_Level --
--
@@ -1901,6 +1939,18 @@ package body Accessibility is
is
   Func_Typ : constant Entity_Id := Underlying_Type (Etype (Func_Id));
 
+   begin
+  return Needs_Result_Accessibility_Level_Param (Func_Id, Func_Typ);
+   end Needs_Result_Accessibility_Level;
+
+   
+   -- Needs_Result_Accessibility_Level_Param --
+   
+
+   function Needs_Result_Accessibility_Level_Param
+ (Func_Id  : Entity_Id;
+  Func_Typ : Entity_Id) return Boolean
+   is
   function Has_Unconstrained_Access_Discriminant_Component
 (Comp_Typ : Entity_Id) return Boolean;
   --  Returns True if any component of the type has an unconstrained access
@@ -1952,7 +2002,7 @@ package body Accessibility is
   --  Flag used to temporarily disable a "True" result for tagged types.
   --  See comments further below for details.
 
-   --  Start of processing for Needs_Result_Accessibility_Level
+   --  Start of processing for Needs_Result_Accessibility_Level_Param
 
begin
   --  False if completion unavailable, which can happen when we are
@@ -2028,7 +2078,7 @@ package body Accessibility is
   else
  return False;
   end if;
-   end Needs_Result_Accessibility_Level;
+   end Needs_Result_Accessibility_Level_Param;
 
--
-- Prefix_With_Safe_Accessibility_Level --
diff --git a/gcc/ada/accessibility.ads b/gcc/ada/accessibility.ads
index e30c90ab6a7..731fea125f4 100644
--- a/gcc/ada/accessibility.ads
+++ b/gcc/ada/accessibility.ads
@@ -197,11 +197,21 @@ package Accessibility is
--  prefix is an aliased formal of Scop and that Scop returns an anonymous
--  access type. See RM 3.10.2 for more details.
 
+  

[COMMITTED] ada: Handle GNATcheck violations

[Marc Poulhiès via Gcc-patches]

From: Sheri Bernstein 

For the GNATcheck rule "Improper_Returns", either use pragma Annotate
to exempt the violation with the rationale "early returns for performance",
or refactor the code by replacing multiple returns by a single return
statement with a conditional expression; this is more readable and
maintainable, and also conformant with a Highly Recommended design principle
of ISO 26262-6.  For the GNATcheck rule "Discriminated_Records", use pragma
Annotate to exempt the violation with the rationale "only variant records
are disallowed".

gcc/ada/

* libgnarl/a-reatim.adb (Time_Of): Add pragma to exempt
Discriminated_Records.
* libgnat/s-imguti.adb (Round, Set_Decimal_Digits): Likewise.
* libgnat/s-multip.adb (Number_Of_CPUs): Likewise.
* libgnarl/s-tpopsp__posix-foreign.adb (Self): Refactor multiple
returns.

Tested on x86_64-pc-linux-gnu, committed on master.

---
 gcc/ada/libgnarl/a-reatim.adb|  5 +
 gcc/ada/libgnarl/s-tpopsp__posix-foreign.adb | 10 --
 gcc/ada/libgnat/s-imguti.adb | 10 ++
 gcc/ada/libgnat/s-multip.adb |  5 +
 4 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/gcc/ada/libgnarl/a-reatim.adb b/gcc/ada/libgnarl/a-reatim.adb
index 56a84789729..24a77311f9d 100644
--- a/gcc/ada/libgnarl/a-reatim.adb
+++ b/gcc/ada/libgnarl/a-reatim.adb
@@ -307,6 +307,9 @@ is
--  Start of processing for Time_Of
 
begin
+  pragma Annotate (Gnatcheck, Exempt_On, "Improper_Returns",
+   "early returns for performance");
+
   --  If SC is so far out of range that there is no possibility of the
   --  addition of TS getting it back in range, raise an exception right
   --  away. That way we don't have to worry about SC values overflowing.
@@ -356,6 +359,8 @@ is
 Out_Of_Range;
  end if;
   end if;
+
+  pragma Annotate (Gnatcheck, Exempt_Off, "Improper_Returns");
end Time_Of;
 
-
diff --git a/gcc/ada/libgnarl/s-tpopsp__posix-foreign.adb 
b/gcc/ada/libgnarl/s-tpopsp__posix-foreign.adb
index 4b3e200150d..ebf0f622db0 100644
--- a/gcc/ada/libgnarl/s-tpopsp__posix-foreign.adb
+++ b/gcc/ada/libgnarl/s-tpopsp__posix-foreign.adb
@@ -95,12 +95,10 @@ package body Specific is
   Result := pthread_getspecific (ATCB_Key);
 
   --  If the key value is Null then it is a non-Ada task
-
-  if Result /= System.Null_Address then
- return To_Task_Id (Result);
-  else
- return Register_Foreign_Thread;
-  end if;
+  return
+ (if Result /= System.Null_Address then To_Task_Id (Result)
+  else Register_Foreign_Thread
+ );
end Self;
 
 end Specific;
diff --git a/gcc/ada/libgnat/s-imguti.adb b/gcc/ada/libgnat/s-imguti.adb
index 4c8cf5f3295..2e69e630c8a 100644
--- a/gcc/ada/libgnat/s-imguti.adb
+++ b/gcc/ada/libgnat/s-imguti.adb
@@ -119,6 +119,9 @@ package body System.Img_Util is
  pragma Assert (Digs'First < Digs'Last);
 
   begin
+ pragma Annotate (Gnatcheck, Exempt_On, "Improper_Returns",
+   "early returns for performance");
+
  --  Nothing to do if rounding past the last digit we have
 
  if N >= LD then
@@ -178,6 +181,8 @@ package body System.Img_Util is
Digits_Before_Point := Digits_Before_Point + 1;
 end if;
  end if;
+
+ pragma Annotate (Gnatcheck, Exempt_Off, "Improper_Returns");
   end Round;
 
   -
@@ -246,6 +251,9 @@ package body System.Img_Util is
--  Start of processing for Set_Decimal_Digits
 
begin
+  pragma Annotate (Gnatcheck, Exempt_On, "Improper_Returns",
+"early returns for performance");
+
   --  Case of exponent given
 
   if Exp > 0 then
@@ -398,6 +406,8 @@ package body System.Img_Util is
 end if;
  end if;
   end if;
+
+  pragma Annotate (Gnatcheck, Exempt_Off, "Improper_Returns");
end Set_Decimal_Digits;
 

diff --git a/gcc/ada/libgnat/s-multip.adb b/gcc/ada/libgnat/s-multip.adb
index 372f1407dbf..96177f9fc41 100644
--- a/gcc/ada/libgnat/s-multip.adb
+++ b/gcc/ada/libgnat/s-multip.adb
@@ -36,6 +36,9 @@ package body System.Multiprocessors is
 
function Number_Of_CPUs return CPU is
begin
+  pragma Annotate (Gnatcheck, Exempt_On, "Improper_Returns",
+   "early returns for performance");
+
   if CPU'Last = 1 then
  return 1;
   else
@@ -46,6 +49,8 @@ package body System.Multiprocessors is
 return CPU (Gnat_Number_Of_CPUs);
  end;
   end if;
+
+  pragma Annotate (Gnatcheck, Exempt_Off, "Improper_Returns");
end Number_Of_CPUs;
 
 end System.Multiprocessors;
-- 
2.40.0