Re: [PATCH v2] rs6000: Rework option -mpowerpc64 handling [PR106680]

[Kewen.Lin via Gcc-patches]

Hi Segher,

on 2022/12/24 04:26, Segher Boessenkool wrote:
> Hi!
> 
> On Wed, Oct 12, 2022 at 04:12:21PM +0800, Kewen.Lin wrote:
>> PR106680 shows that -m32 -mpowerpc64 is different from
>> -mpowerpc64 -m32, this is determined by the way how we
>> handle option powerpc64 in rs6000_handle_option.
>>
>> Segher pointed out this difference should be taken as
>> a bug and we should ensure that option powerpc64 is
>> independent of -m32/-m64.  So this patch removes the
>> handlings in rs6000_handle_option and add some necessary
>> supports in rs6000_option_override_internal instead.
> 
> Sorry for the late review.
> 
>> +  /* Don't expect powerpc64 enabled on those OSes with OS_MISSING_POWERPC64,
>> + since they don't support saving the high part of 64-bit registers on
>> + context switch.  If the user explicitly specifies it, we won't 
>> interfere
>> + with the user's specification.  */
> 
> It depends on the OS, and what you call "context switch".  For example
> on Linux the context switches done by the kernel are fine, only things
> done by setjmp/longjmp and getcontext/setcontext are not.  So just be a
> bit more vague here?  "Since they do not save and restore the high half
> of the GPRs correctly in all cases", something like that?
> 
> Okay for trunk like that.  Thanks!
> 

Thanks!  Adjusted as you suggested and committed in r13-4894-gacc727cf02a144.

BR,
Kewen

Re: [patch, fortran] ICE in attr_decl1, at fortran/decl.c:8691

[Harald Anlauf via Gcc-patches]

Hi Jerry,

Am 26.12.22 um 23:26 schrieb Jerry DeLisle via Gcc-patches:

The attached patch was provided by Steve Kargl.  After exploring for
possible other checks I settled on leaving the patch intact.

Two existing test cases updated as different but sensible error messages
resulted.


I think this is fine.  The error message for CLASS is
now arguably more consistent with TYPE.


Regression tested on main line.

OK to commit?


Regarding the format of the commit message: if you want
bugzilla to get updated properly, please consider adding
PR/fortran ## to the respective parts below.
It is also custom to have a one-line summary including
e.g. [PR##] to make it easier for others to relate
a commit to bugzilla.

OK with these things fixed.

Thanks for taking this!

Harald


Regards,

Jerry

Author: Steve Kargl 
Date:   Mon Dec 26 14:07:04 2022 -0800

  Modify checks to avoid referencing NULL pointer.
  Update test cases with error messages that changed as a result.

  gcc/fortran/ChangeLog:

  * decl.cc (attr_decl1): Guard against NULL pointer.
  * parse.cc (match_deferred_characteristics): Include
BT_CLASS in check for
derived being undefined.

  gcc/testsuite/ChangeLog:

  * gfortran.dg/class_result_4.f90: Update error message check.
  * gfortran.dg/pr85779_3.f90: Update error message check.

Re: [PATCH] loading float member of parameter stored via int registers

[Jiufu Guo via Gcc-patches]

Hi,

Jiufu Guo via Gcc-patches  writes:

> Hi,
>
> Segher Boessenkool  writes:
>
>> On Fri, Dec 23, 2022 at 08:13:48PM +0100, Richard Biener wrote:
>>> > Am 23.12.2022 um 17:55 schrieb Segher Boessenkool 
>>> > :
>>> > There are at least six very different kinds of subreg:
>>> > 
>>> > 0) Lvalue subregs.  Most archs have no use for it, and it can be
>>> >   expressed much more clearly and cleanly always.
>>> > 1) Subregs of mem.  Do not use, deprecated.  When old reload goes away
>>> >   this will go away.
>>> > 2) Subregs of hard registers.  Do not use, there are much better ways to
>>> >   write subregs of a non-zero byte offset, and for zero offset this is
>>> >   non-canonical RTL.
>>> > 3) Bitcast subregs.  In principle they go from one mode to another mode
>>> >   of the same size (but read on).
>>> > 4) Paradoxical subregs.  A concept completely separate from the rest,
>>> >   different rules for everything, it has to be special cased almost
>>> >   everywhere, it would be better if it was a separate rtx_code imo.
>>> > 5) Finally, normal subregs, taking a contiguous span of bits from some
>>> >   value.
>>> > 
>>> > Now, it is invalid to have a subreg of a subreg, so a 3) of a 5) is
>>> > written as just one subreg, as you say.  And a 4) of a 5) is just
>>> > invalid afaics (and let's not talk about 0)..2) anymore :-) )
>>> > 
>>> >> Note whether targets actually support subreg operations needs to be 
>>> >> queried and I’m not sure how subreg with offset validation should work 
>>> >> there.
>>> > 
>>> > But 3) is always valid, no?  On pseudos
> I also has similar question: do we need to query/recog if "SF(SI#0)" is
> valid on the target, or it would always work (even through reload)?
> I also hit this during debugging on ppc64le: "SF(SI#0)" is valid,
> and "SF(DI#4)" is not valid. 
>>> 
>>> Yes, but it will eventually result in a spill/reload which is
>>> undesirable when we created this from CSE from a load.  So I think
>>> for CSE we do want to know whether a spill will definitely not
>>> occur.
>>
>> Does it cause reloads though?  On any sane backend?  If no movsf pattern
>> allows integer registers, can things work at all?
>>
>> Anyway, the normal way to test if some RTL is valid is to just generate
>> it (using validate_change) and then do apply_change_group, which then
>> cancels the changes if they do not work.  CSE already does some of
>> this.
> validate_change seems ok. Thanks!
>>
>> (I am doubtful doing any of this in CSE is a good idea fwiw).
> Understand your concern! Especially when we need to emit additional
> inns in CSE.
> While CSE does some similar work. It transforms
> "[sf:DI]=%x:DI; %y:DI=[sf:DI]" to "%y:DI=%x:DI".
> and "see if a MEM has already been loaded with a widening operation;
> if it has, we can use a subreg of that." (only for int modes).
> So, it may be acceptable to do this in CSE (maybe still seems
> hacking).

This maybe works for "DI to DF", because "mode converting
subreg:DF(x:DI,0)" is cheaper than "mem load DF([sf:DI])". Then
"y:DF=[sf:DI]" can be replaced by "y:DF=x:DI#0".

While for "subreg:SF(x:SI,0)", in CSE, it may not cheaper.
So, it may be doubtful for "convert DI to SF" in CSE.

Any comments or suggestions?


BR,
Jeff (Jiufu)

>
> Thanks for so great comments!
>
> BR,
> Jeff (Jiufu)
>
>>
>>
>> Segher

Re: [PATCH] RISC-V: Add testcases for VSETVL PASS

[Jeff Law via Gcc-patches]

On 12/26/22 02:20, Andreas Schwab wrote:

FAIL: gcc.target/riscv/rvv/vsetvl/dump-1.c   -O0  (test for excess errors)
Excess errors:
/usr/include/gnu/stubs.h:8:11: fatal error: gnu/stubs-ilp32.h: No such file or 
directory
compilation terminated.
Isn't this really an indicator that the ILP32 bits from glibc aren't 
installed and/or the test needs to be conditionalized?


jeff

Re: [01/13] scoped tables: insert before further lookups

[Jeff Law via Gcc-patches]

On 12/26/22 21:17, Alexandre Oliva via Gcc-patches wrote:


Avoid hash table lookups between requesting an insert and storing the
inserted value in avail_exprs_stack.  Lookups before the insert is
completed could fail to find double-hashed elements.

Regstrapped on x86_64-linux-gnu.  Ok to install?


for  gcc/ChangeLog

* tree-ssa-scopedtables.cc
(avail_exprs_stack::lookup_avail_expr): Finish hash table
insertion before further lookups.

Thanks.  OK.
Jeff

Re: [07/13] postreload-gcse: no insert on mere lookup

[Jeff Law via Gcc-patches]

On 12/26/22 21:24, Alexandre Oliva via Gcc-patches wrote:


lookup_expr_in_table is not used for insertions, but it mistakenly
used INSERT rather than NO_INSERT.

Regstrapped on x86_64-linux-gnu.  Ok to install?


for  gcc/ChangeLog

* postreload-gcse.cc (lookup_expr_in_table): Use NO_INSERT.

OK
jeff

Re: [PATCH] RISC-V: Add testcases for VSETVL PASS

[Kito Cheng via Gcc-patches]

It should be same issue as
https://github.com/gcc-mirror/gcc/commit/d0bbecb1c418b680505faa998fe420f0fd4bbfc1,
I gonna commit a fix for that.

On Tue, Dec 27, 2022 at 11:04 PM Jeff Law via Gcc-patches
 wrote:
>
>
>
> On 12/26/22 02:20, Andreas Schwab wrote:
> > FAIL: gcc.target/riscv/rvv/vsetvl/dump-1.c   -O0  (test for excess errors)
> > Excess errors:
> > /usr/include/gnu/stubs.h:8:11: fatal error: gnu/stubs-ilp32.h: No such file 
> > or directory
> > compilation terminated.
> Isn't this really an indicator that the ILP32 bits from glibc aren't
> installed and/or the test needs to be conditionalized?
>
> jeff
> >

Re: [02/13] varpool: do not add NULL vnodes to referenced

[Jeff Law via Gcc-patches]

On 12/26/22 21:18, Alexandre Oliva via Gcc-patches wrote:


Avoid adding NULL vnodes to referenced tables.

Regstrapped on x86_64-linux-gnu.  Ok to install?


for  gcc/ChangeLog

* varpool.c (symbol_table::remove_unreferenced_decls): Do not
add NULL vnodes to referenced table.

OK
jeff

Re: [03/13] tree-inline decl_map: skip mapping NULL to itself

[Jeff Law via Gcc-patches]

On 12/26/22 21:19, Alexandre Oliva via Gcc-patches wrote:


Mapping a NULL key is no use, skip it.

Regstrapped on x86_64-linux-gnu.  Ok to install?


for  gcc/ChangeLog

* tree-inline.cc (insert_decl_map): Skip mapping a NULL decl
as value to itself.

OK
jeff

Re: [05/13] ssa-loop-niter: skip caching of null operands

[Jeff Law via Gcc-patches]

On 12/26/22 21:22, Alexandre Oliva via Gcc-patches wrote:


When a TREE_OPERAND is NULL, do not cache it.

Regstrapped on x86_64-linux-gnu.  Ok to install?


for  gcc/ChangeLog

* tree-ssa-loop-niter.cc (expand_simple_operands): Refrain
from caching NULL TREE_OPERANDs.
I must admit some curiosity about the NULL operand though.  Do you 
recall what kind of node had a NULL operand and whether or not that was 
a valid state or not?


I just want to make sure this isn't just papering over a deeper issue.

jeff

[PATCH] RISC-V: Return const ref. for vl_vtype_info::get_avl_info

[Kito Cheng]

Return const reference could prevent unnecessary copying.

gcc/

* config/riscv/riscv-vsetvl.h (vl_vtype_info::get_avl_info):
Return const reference rather than value.
---
 gcc/config/riscv/riscv-vsetvl.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/riscv/riscv-vsetvl.h b/gcc/config/riscv/riscv-vsetvl.h
index 6f27004fab1..a5d3f256412 100644
--- a/gcc/config/riscv/riscv-vsetvl.h
+++ b/gcc/config/riscv/riscv-vsetvl.h
@@ -173,7 +173,7 @@ public:
   bool has_non_zero_avl () const;
 
   rtx get_avl () const { return m_avl.get_value (); }
-  avl_info get_avl_info () const { return m_avl; }
+  const avl_info &get_avl_info () const { return m_avl; }
   void set_avl_info (const avl_info &avl) { m_avl = avl; }
   uint8_t get_sew () const { return m_sew; }
   riscv_vector::vlmul_type get_vlmul () const { return m_vlmul; }
-- 
2.37.2

Re: [06/13] tree-inline decl_map: skip mapping result's NULL default def

[Jeff Law via Gcc-patches]

On 12/26/22 21:23, Alexandre Oliva via Gcc-patches wrote:


If a result doesn't have a default def, don't attempt to remap it.

Regstrapped on x86_64-linux-gnu.  Ok to install?


for  gcc/ChangeLog

* tree-inline.cc (declare_return_variable): Don't remap NULL
default def of result.

OK
jeff

Re: [08/13] tm: complete tm_restart insertion

[Jeff Law via Gcc-patches]

On 12/26/22 21:28, Alexandre Oliva via Gcc-patches wrote:


Insertion of a tm_restart_node in tm_restart failed to record the
newly-allocated node in the hash table.

Regstrapped on x86_64-linux-gnu.  Ok to install?


for  gcc/ChangeLog

* trans-mem.cc (split_bb_make_tm_edge): Record new node in
tm_restart.

OK
jeff

Re: [12/13] hash set: reject attempts to add empty values

[Jeff Law via Gcc-patches]

On 12/26/22 21:38, Alexandre Oliva via Gcc-patches wrote:


Check, after adding a key to a hash set, that the entry does not look
empty.

Regstrapped on x86_64-linux-gnu.  Ok to install?


for  gcc/ChangeLog

* hash-set.h (add): Check that the inserted entry does not
look empty.

OK once prereqs are installed.
jeff

[committed] RISC-V: Add riscv_vector.h wrapper

[Kito Cheng]

Like d0bbecb1c418b680505faa998fe420f0fd4bbfc1, we add a wrapper to
prevent it pull stdint.h from standard C library.

gcc/testsuite:

* gcc.target/riscv/rvv/vsetvl/riscv_vector.h: New.
---
 .../gcc.target/riscv/rvv/vsetvl/riscv_vector.h| 11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/riscv_vector.h

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/riscv_vector.h 
b/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/riscv_vector.h
new file mode 100644
index 000..fbb4858fc86
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/riscv_vector.h
@@ -0,0 +1,11 @@
+/* Wrapper of riscv_vector.h, prevent riscv_vector.h including stdint.h from
+   C library, that might cause problem on testing RV32 related testcase when
+   we disable multilib.  */
+#ifndef _RISCV_VECTOR_WRAP_H
+
+#define _GCC_WRAP_STDINT_H
+#include "stdint-gcc.h"
+#include_next 
+#define _RISCV_VECTOR_WRAP_H
+
+#endif
-- 
2.37.2

Re: [13/13] hash-map: reject empty-looking insertions

[Jeff Law via Gcc-patches]

On 12/26/22 21:39, Alexandre Oliva via Gcc-patches wrote:


Check, after inserting entries, that they don't look empty.

Regstrapped on x86_64-linux-gnu.  Ok to install?


for  gcc/ChangeLog

* hash-map.h (put, get_or_insert): Check that entry does not
look empty after insertion.

OK once prereqs are installed.
jeff

Re: [11/13] ada: don't map NULL decl to locus

[Jeff Law via Gcc-patches]

On 12/26/22 21:38, Alexandre Oliva via Gcc-patches wrote:


When decl is NULL, don't record its mapping in the
decl_to_instance_map.

Regstrapped on x86_64-linux-gnu.  Ok to install?


for  gcc/ada/ChangeLog

* gcc-interface/trans.cc (Sloc_to_locus): Don't map NULL decl.
OK assuming that a NULL "decl" is valid -- you're in a much better 
position than me to assess validity of a NULL "decl" here.


jeff

Re: [10/13] lto: drop dummy partition mapping

[Jeff Law via Gcc-patches]

On 12/26/22 21:35, Alexandre Oliva via Gcc-patches wrote:


When adding a catch-all partition, we map NULL to it.  That mapping is
ineffective and unnecessary.  Drop it.

Regstrapped on x86_64-linux-gnu.  Ok to install?


for  gcc/lto/ChangeLog

* lto-partition.cc (lto_1_to_1_map): Drop NULL partition
mapping.

OK
jeff

Re: [04/13] [C++] constraint: insert norm entry once

[Jeff Law via Gcc-patches]

On 12/26/22 21:21, Alexandre Oliva via Gcc-patches wrote:


Use NO_INSERT to test whether inserting should be attempted.

Regstrapped on x86_64-linux-gnu.  Ok to install?


for  gcc/cp/ChangeLog

* constraint.cc (normalize_concept_check): Use NO_INSERT for
pre-insertion check.

OK
jeff

Re: [09/13] [C++] constexpr: request insert iff depth is ok

[Jeff Law via Gcc-patches]

On 12/26/22 21:30, Alexandre Oliva via Gcc-patches wrote:


cxx_eval_call_expression requests an INSERT even in cases when it
would later decide not to insert.  This could break double-hashing
chains.  Arrange for it to use NO_INSERT when the insertion would not
be completed.

Regstrapped on x86_64-linux-gnu.  Ok to install?


for  gcc/cp/ChangeLog

* constexpr.cc (cxx_eval_call_expression): Do not request an
INSERT that would not be completed.

OK.
Jeff

Re: [PATCH] xtensa: Apply a few minor fixes

[Max Filippov via Gcc-patches]

On Mon, Dec 26, 2022 at 10:30 PM Takayuki 'January June' Suwa
 wrote:
>
> Almost cosmetic and no functional changes.
>
> gcc/ChangeLog:
>
> * config/xtensa/*: Tabify, and trim trailing spaces.
> * config/xtensa/xtensa.h (GP_RETURN, GP_RETURN_REG_COUNT):
> Change to GP_RETURN_FIRST and GP_RETURN_LAST, respectively.
> * config/xtensa/xtensa.cc (xtensa_function_value,
> xtensa_libcall_value, xtensa_function_value_regno_p): Ditto.
> (xtensa_expand_prologue): Modify to exit the inspection loops
> as soon as the necessity of stack pointer is found.
> (xtensa_set_return_address): Change the style of brackets.
> * config/xtensa/xtensa.md (set_frame_ptr):
> Fix to reflect TARGET_DENSITY.
> ---
>  gcc/config/xtensa/elf.h  |  32 
>  gcc/config/xtensa/linux.h|   1 -
>  gcc/config/xtensa/uclinux.h  |   1 -
>  gcc/config/xtensa/xtensa-dynconfig.c |   6 +-
>  gcc/config/xtensa/xtensa.cc  | 105 ++-
>  gcc/config/xtensa/xtensa.h   |  10 +--
>  gcc/config/xtensa/xtensa.md  | 105 ++-
>  7 files changed, 133 insertions(+), 127 deletions(-)

I've split it into independent parts and applied to master.

-- 
Thanks.
-- Max

[COMMITTED 4/4] xtensa: Generate density instructions in set_frame_ptr

[Max Filippov via Gcc-patches]

From: Takayuki 'January June' Suwa 

gcc/ChangeLog:

* config/xtensa/xtensa.md (set_frame_ptr): Fix to reflect
TARGET_DENSITY.
---
 gcc/config/xtensa/xtensa.md | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
index a77d3285bad1..e72fd9ac3f61 100644
--- a/gcc/config/xtensa/xtensa.md
+++ b/gcc/config/xtensa/xtensa.md
@@ -2562,12 +2562,15 @@
   ""
 {
   if (frame_pointer_needed)
-return "mov\ta7, sp";
+return (TARGET_DENSITY ? "mov.n\ta7, sp" : "mov\ta7, sp");
   return "";
 }
   [(set_attr "type""move")
(set_attr "mode""SI")
-   (set_attr "length"  "3")])
+   (set (attr "length")
+   (if_then_else (match_test "TARGET_DENSITY")
+ (const_int 2)
+ (const_int 3)))])
 
 ;; Post-reload splitter to remove fp assignment when it's not needed.
 (define_split
-- 
2.30.2

[COMMITTED 3/4] xtensa: Change GP_RETURN{, _REG_COUNT} to GP_RETURN_{FIRST, LAST}

[Max Filippov via Gcc-patches]

From: Takayuki 'January June' Suwa 

gcc/ChangeLog:

* config/xtensa/xtensa.h (GP_RETURN, GP_RETURN_REG_COUNT):
Change to GP_RETURN_FIRST and GP_RETURN_LAST, respectively.
* config/xtensa/xtensa.cc (xtensa_function_value,
xtensa_libcall_value, xtensa_function_value_regno_p): Ditto.
---
 gcc/config/xtensa/xtensa.cc | 10 +-
 gcc/config/xtensa/xtensa.h  |  4 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index 709b0d52d069..66e253495211 100644
--- a/gcc/config/xtensa/xtensa.cc
+++ b/gcc/config/xtensa/xtensa.cc
@@ -4526,9 +4526,9 @@ xtensa_function_value (const_tree valtype, const_tree 
func ATTRIBUTE_UNUSED,
   bool outgoing)
 {
   return gen_rtx_REG ((INTEGRAL_TYPE_P (valtype)
-  && TYPE_PRECISION (valtype) < BITS_PER_WORD)
- ? SImode : TYPE_MODE (valtype),
- outgoing ? GP_OUTGOING_RETURN : GP_RETURN);
+  && TYPE_PRECISION (valtype) < BITS_PER_WORD)
+ ? SImode : TYPE_MODE (valtype),
+ outgoing ? GP_OUTGOING_RETURN : GP_RETURN_FIRST);
 }
 
 /* Worker function for TARGET_LIBCALL_VALUE.  */
@@ -4538,7 +4538,7 @@ xtensa_libcall_value (machine_mode mode, const_rtx fun 
ATTRIBUTE_UNUSED)
 {
   return gen_rtx_REG ((GET_MODE_CLASS (mode) == MODE_INT
   && GET_MODE_SIZE (mode) < UNITS_PER_WORD)
- ? SImode : mode, GP_RETURN);
+ ? SImode : mode, GP_RETURN_FIRST);
 }
 
 /* Worker function TARGET_FUNCTION_VALUE_REGNO_P.  */
@@ -4546,7 +4546,7 @@ xtensa_libcall_value (machine_mode mode, const_rtx fun 
ATTRIBUTE_UNUSED)
 static bool
 xtensa_function_value_regno_p (const unsigned int regno)
 {
-  return (regno >= GP_RETURN && regno < GP_RETURN + GP_RETURN_REG_COUNT);
+  return IN_RANGE (regno, GP_RETURN_FIRST, GP_RETURN_LAST);
 }
 
 /* The static chain is passed in memory.  Provide rtx giving 'mem'
diff --git a/gcc/config/xtensa/xtensa.h b/gcc/config/xtensa/xtensa.h
index 60d3fdfbc706..a7c112b87538 100644
--- a/gcc/config/xtensa/xtensa.h
+++ b/gcc/config/xtensa/xtensa.h
@@ -474,9 +474,9 @@ enum reg_class
 
 /* Symbolic macros for the registers used to return integer, floating
point, and values of coprocessor and user-defined modes.  */
-#define GP_RETURN (GP_REG_FIRST + 2 + WINDOW_SIZE)
+#define GP_RETURN_FIRST (GP_REG_FIRST + 2 + WINDOW_SIZE)
+#define GP_RETURN_LAST  (GP_RETURN_FIRST + 3)
 #define GP_OUTGOING_RETURN (GP_REG_FIRST + 2)
-#define GP_RETURN_REG_COUNT 4
 
 /* Symbolic macros for the first/last argument registers.  */
 #define GP_ARG_FIRST (GP_REG_FIRST + 2)
-- 
2.30.2

[COMMITTED 2/4] xtensa: Clean up xtensa_expand_prologue

[Max Filippov via Gcc-patches]

From: Takayuki 'January June' Suwa 

gcc/ChangeLog:

* config/xtensa/xtensa.cc (xtensa_expand_prologue): Modify to
exit the inspection loops as soon as the necessity of stack
pointer is found.
---
 gcc/config/xtensa/xtensa.cc | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index 178d16a78462..709b0d52d069 100644
--- a/gcc/config/xtensa/xtensa.cc
+++ b/gcc/config/xtensa/xtensa.cc
@@ -3327,12 +3327,18 @@ xtensa_expand_prologue (void)
 ref; ref = DF_REF_NEXT_REG (ref))
  if (DF_REF_CLASS (ref) == DF_REF_REGULAR
  && NONJUMP_INSN_P (DF_REF_INSN (ref)))
-   stack_pointer_needed = true;
+   {
+ stack_pointer_needed = true;
+ break;
+   }
   /* Check if callee-saved registers really need saving to the stack.  */
   if (!stack_pointer_needed)
for (regno = 0; regno < FIRST_PSEUDO_REGISTER; ++regno)
  if (xtensa_call_save_reg (regno))
-   stack_pointer_needed = true;
+   {
+ stack_pointer_needed = true;
+ break;
+   }
 
   cfun->machine->inhibit_logues_a1_adjusts = !stack_pointer_needed;
 
-- 
2.30.2

[COMMITTED] gcc: xtensa: use define_c_enums instead of define_constants

[Max Filippov via Gcc-patches]

This improves RTL dumps readability. No functional changes.

gcc/
* config/xtensa/xtensa.md (unspec): Extract UNSPEC_* constants
into this enum.
(unspecv): Extract UNSPECV_* constants into this enum.
---
 gcc/config/xtensa/xtensa.md | 46 -
 1 file changed, 25 insertions(+), 21 deletions(-)

diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
index e72fd9ac3f61..0a26d3dccf44 100644
--- a/gcc/config/xtensa/xtensa.md
+++ b/gcc/config/xtensa/xtensa.md
@@ -25,28 +25,32 @@
   (A7_REG  7)
   (A8_REG  8)
   (A9_REG  9)
+])
+
+(define_c_enum "unspec" [
+  UNSPEC_NOP
+  UNSPEC_PLT
+  UNSPEC_RET_ADDR
+  UNSPEC_TPOFF
+  UNSPEC_DTPOFF
+  UNSPEC_TLS_FUNC
+  UNSPEC_TLS_ARG
+  UNSPEC_TLS_CALL
+  UNSPEC_TP
+  UNSPEC_MEMW
+  UNSPEC_LSETUP_START
+  UNSPEC_LSETUP_END
+  UNSPEC_FRAME_BLOCKAGE
+])
 
-  (UNSPEC_NOP  2)
-  (UNSPEC_PLT  3)
-  (UNSPEC_RET_ADDR 4)
-  (UNSPEC_TPOFF5)
-  (UNSPEC_DTPOFF   6)
-  (UNSPEC_TLS_FUNC 7)
-  (UNSPEC_TLS_ARG  8)
-  (UNSPEC_TLS_CALL 9)
-  (UNSPEC_TP   10)
-  (UNSPEC_MEMW 11)
-  (UNSPEC_LSETUP_START  12)
-  (UNSPEC_LSETUP_END13)
-  (UNSPEC_FRAME_BLOCKAGE 14)
-
-  (UNSPECV_SET_FP  1)
-  (UNSPECV_ENTRY   2)
-  (UNSPECV_S32RI   4)
-  (UNSPECV_S32C1I  5)
-  (UNSPECV_EH_RETURN   6)
-  (UNSPECV_SET_TP  7)
-  (UNSPECV_BLOCKAGE8)
+(define_c_enum "unspecv" [
+  UNSPECV_SET_FP
+  UNSPECV_ENTRY
+  UNSPECV_S32RI
+  UNSPECV_S32C1I
+  UNSPECV_EH_RETURN
+  UNSPECV_SET_TP
+  UNSPECV_BLOCKAGE
 ])
 
 ;; This code iterator allows signed and unsigned widening multiplications
-- 
2.30.2

[COMMITTED 1/4] xtensa: Tabify, and trim trailing spaces

[Max Filippov via Gcc-patches]

From: Takayuki 'January June' Suwa 

Cosmetic and no functional changes.

gcc/ChangeLog:

* config/xtensa/elf.h: Tabify, and trim trailing spaces.
* config/xtensa/linux.h: Likewise.
* config/xtensa/uclinux.h: Likewise.
* config/xtensa/xtensa-dynconfig.c: Likewise.
* config/xtensa/xtensa.cc: Likewise.
* config/xtensa/xtensa.h: Likewise.
* config/xtensa/xtensa.md: Likewise.
---
 gcc/config/xtensa/elf.h  | 32 +
 gcc/config/xtensa/linux.h|  1 -
 gcc/config/xtensa/uclinux.h  |  1 -
 gcc/config/xtensa/xtensa-dynconfig.c |  6 +-
 gcc/config/xtensa/xtensa.cc  | 85 
 gcc/config/xtensa/xtensa.h   |  6 +-
 gcc/config/xtensa/xtensa.md  | 98 ++--
 7 files changed, 113 insertions(+), 116 deletions(-)

diff --git a/gcc/config/xtensa/elf.h b/gcc/config/xtensa/elf.h
index fbdccc49c9b5..1edc1761d74d 100644
--- a/gcc/config/xtensa/elf.h
+++ b/gcc/config/xtensa/elf.h
@@ -59,7 +59,7 @@ along with GCC; see the file COPYING3.  If not see
   "crt1-sim%O%s crt0%O%s crti%O%s crtbegin%O%s _vectors%O%s"
 
 #undef ENDFILE_SPEC
-#define ENDFILE_SPEC "crtend%O%s crtn%O%s"  
+#define ENDFILE_SPEC "crtend%O%s crtn%O%s"
 
 #undef LINK_SPEC
 #define LINK_SPEC \
@@ -86,19 +86,17 @@ along with GCC; see the file COPYING3.  If not see
 /* Search for headers in $tooldir/arch/include and for libraries and
startfiles in $tooldir/arch/lib.  */
 #define GCC_DRIVER_HOST_INITIALIZATION \
-do \
-{ \
-  char *tooldir, *archdir; \
-  tooldir = concat (tooldir_base_prefix, spec_machine, \
-   dir_separator_str, NULL); \
-  if (!IS_ABSOLUTE_PATH (tooldir)) \
-tooldir = concat (standard_exec_prefix, spec_machine, dir_separator_str, \
- spec_version, dir_separator_str, tooldir, NULL); \
-  archdir = concat (tooldir, "arch", dir_separator_str, NULL); \
-  add_prefix (&startfile_prefixes, \
- concat (archdir, "lib", dir_separator_str, NULL), \
- "GCC", PREFIX_PRIORITY_LAST, 0, 1); \
-  add_prefix (&include_prefixes, archdir, \
- "GCC", PREFIX_PRIORITY_LAST, 0, 0); \
-  } \
-while (0)
+  do { \
+char *tooldir, *archdir; \
+tooldir = concat (tooldir_base_prefix, spec_machine, \
+ dir_separator_str, NULL); \
+if (!IS_ABSOLUTE_PATH (tooldir)) \
+  tooldir = concat (standard_exec_prefix, spec_machine, dir_separator_str, 
\
+   spec_version, dir_separator_str, tooldir, NULL); \
+archdir = concat (tooldir, "arch", dir_separator_str, NULL); \
+add_prefix (&startfile_prefixes, \
+   concat (archdir, "lib", dir_separator_str, NULL), \
+   "GCC", PREFIX_PRIORITY_LAST, 0, 1); \
+add_prefix (&include_prefixes, archdir, \
+   "GCC", PREFIX_PRIORITY_LAST, 0, 0); \
+  } while (0)
diff --git a/gcc/config/xtensa/linux.h b/gcc/config/xtensa/linux.h
index bc7bee71517d..198edfe05531 100644
--- a/gcc/config/xtensa/linux.h
+++ b/gcc/config/xtensa/linux.h
@@ -69,4 +69,3 @@ along with GCC; see the file COPYING3.  If not see
 #define XTENSA_ALWAYS_PIC 1
 
 #undef DEBUGGER_REGNO
-
diff --git a/gcc/config/xtensa/uclinux.h b/gcc/config/xtensa/uclinux.h
index 5fcf639ccff4..5787b2f1ab95 100644
--- a/gcc/config/xtensa/uclinux.h
+++ b/gcc/config/xtensa/uclinux.h
@@ -71,4 +71,3 @@ along with GCC; see the file COPYING3.  If not see
 #define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
 
 #undef DEBUGGER_REGNO
-
diff --git a/gcc/config/xtensa/xtensa-dynconfig.c 
b/gcc/config/xtensa/xtensa-dynconfig.c
index 056204ae9463..0a611fd14b03 100644
--- a/gcc/config/xtensa/xtensa-dynconfig.c
+++ b/gcc/config/xtensa/xtensa-dynconfig.c
@@ -35,7 +35,7 @@
 
 #if !defined (HAVE_DLFCN_H) && defined (_WIN32)
 
-#define RTLD_LAZY 0  /* Dummy value.  */
+#define RTLD_LAZY 0/* Dummy value.  */
 
 static void *
 dlopen (const char *file, int mode ATTRIBUTE_UNUSED)
@@ -142,8 +142,8 @@ XTENSA_CONFIG_INSTANCE_LIST;
 #define XTENSA_CONFIG_ENTRY(a) "__" #a "=" STRINGIFY(a)
 
 static const char * const xtensa_config_strings[] = {
-XTENSA_CONFIG_ENTRY_LIST,
-NULL,
+  XTENSA_CONFIG_ENTRY_LIST,
+  NULL,
 };
 
 const struct xtensa_config_v1 *xtensa_get_config_v1 (void)
diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index 94a98c25f8c9..178d16a78462 100644
--- a/gcc/config/xtensa/xtensa.cc
+++ b/gcc/config/xtensa/xtensa.cc
@@ -176,7 +176,7 @@ static bool constantpool_address_p (const_rtx addr);
 static bool xtensa_legitimate_constant_p (machine_mode, rtx);
 static void xtensa_reorg (void);
 static bool xtensa_can_use_doloop_p (const widest_int &, const widest_int &,
- unsigned int, bool);
+unsigned int, bool);
 static const char *xtensa_invalid_within_doloop (const rtx_insn *);
 
 static bool xtensa_member_type_forces_blk (const_tree,
@@ -2115,7 +2115,7 @@ xtensa_emit

Re: [PATCH] libgfortran: Replace mutex with rwlock

[H.J. Lu via Gcc-patches]

On Sun, Dec 25, 2022 at 4:58 PM Steve Kargl via Gcc-patches
 wrote:
>
> On Wed, Dec 21, 2022 at 07:27:11PM -0500, Lipeng Zhu via Fortran wrote:
> > This patch try to introduce the rwlock and split the read/write to
> > unit_root tree and unit_cache with rwlock instead of the mutex to
> > increase CPU efficiency. In the get_gfc_unit function, the percentage
> > to step into the insert_unit function is around 30%, in most instances,
> > we can get the unit in the phase of reading the unit_cache or unit_root
> > tree. So split the read/write phase by rwlock would be an approach to
> > make it more parallel.
> >
> > BTW, the IPC metrics can increase from 0.25 to 2.2 in the Intel
> > SRP server with 220 cores. The benchmark we used is
> > https://github.com/rwesson/NEAT
> >
>
> The patch fails bootstrap on x86_64-*-freebsd.
>
> gmake[6]: Entering directory 
> '/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/src/c++17'
> /bin/sh ../../libtool --tag CXX --tag disable-shared   --mode=compile 
> /home/kargl/gcc/obj/./gcc/xgcc -shared-libgcc -B/home/kargl/gcc/obj/./gcc 
> -nostdinc++ -L/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/src 
> -L/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/src/.libs 
> -L/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/libsupc++/.libs 
> -B/home/kargl/work/x86_64-unknown-freebsd14.0/bin/ 
> -B/home/kargl/work/x86_64-unknown-freebsd14.0/lib/ -isystem 
> /home/kargl/work/x86_64-unknown-freebsd14.0/include -isystem 
> /home/kargl/work/x86_64-unknown-freebsd14.0/sys-include   -fno-checking 
> -I/home/kargl/gcc/gcc/libstdc++-v3/../libgcc 
> -I/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/x86_64-unknown-freebsd14.0
>  -I/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include 
> -I/home/kargl/gcc/gcc/libstdc++-v3/libsupc++   -std=gnu++17 -nostdinc++ 
> -prefer-pic -D_GLIBCXX_SHARED -fno-implicit-templates  -Wall -Wextra 
> -Wwrite-strings -Wcast-qual -Wabi=2  -fdiagnostics-show-location=once   
> -ffunction-sections -fdata-sections  -frandom-seed=floating_from_chars.lo  
> -fimplicit-templates -g -O2  -c -o floating_from_chars.lo 
> ../../../../../gcc/libstdc++-v3/src/c++17/floating_from_chars.cc
> libtool: compile:  /home/kargl/gcc/obj/./gcc/xgcc -shared-libgcc 
> -B/home/kargl/gcc/obj/./gcc -nostdinc++ 
> -L/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/src 
> -L/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/src/.libs 
> -L/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/libsupc++/.libs 
> -B/home/kargl/work/x86_64-unknown-freebsd14.0/bin/ 
> -B/home/kargl/work/x86_64-unknown-freebsd14.0/lib/ -isystem 
> /home/kargl/work/x86_64-unknown-freebsd14.0/include -isystem 
> /home/kargl/work/x86_64-unknown-freebsd14.0/sys-include -fno-checking 
> -I/home/kargl/gcc/gcc/libstdc++-v3/../libgcc 
> -I/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/x86_64-unknown-freebsd14.0
>  -I/home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include 
> -I/home/kargl/gcc/gcc/libstdc++-v3/libsupc++ -std=gnu++17 -nostdinc++ 
> -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings 
> -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections 
> -fdata-sections -frandom-seed=floating_from_chars.lo -fimplicit-templates -g 
> -O2 -c ../../../../../gcc/libstdc++-v3/src/c++17/floating_from_chars.cc  
> -fPIC -DPIC -D_GLIBCXX_SHARED -o floating_from_chars.o
> In file included from 
> /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/memory_resource:40,
>  from 
> ../../../../../gcc/libstdc++-v3/src/c++17/floating_from_chars.cc:37:
> /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/shared_mutex:
>  In function 'int std::__glibcxx_rwlock_rdlock(pthread_rwlock**)':
> /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/shared_mutex:80:3:
>  error: call of overloaded '__gthrw_pthread_rwlock_rdlock(pthread_rwlock**&)' 
> is ambiguous
>80 |   _GLIBCXX_GTHRW(rwlock_rdlock)
>   |   ^
> In file included from 
> /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/x86_64-unknown-freebsd14.0/bits/gthr.h:148,
>  from 
> /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/bits/std_mutex.h:41,
>  from 
> /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/shared_mutex:41:
> /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/shared_mutex:80:3:
>  note: candidate: 'int std::__gthrw_pthread_rwlock_rdlock(pthread_rwlock**)'
>80 |   _GLIBCXX_GTHRW(rwlock_rdlock)
>   |   ^~
> /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libstdc++-v3/include/x86_64-unknown-freebsd14.0/bits/gthr-default.h:140:1:
>  note: candidate: 'int __gthrw_pthread_rwlock_rdlock(pthread_rwlock**)'
>   140 | __gthrw(pthread_rwlock_rdlock)
>   | ^~~
> /home/kargl/gcc/obj/x86_64-unknown-freebsd14.0/libst

Re: [PATCH] regression tests for 103770 fixed on trunk

[Jeff Law via Gcc-patches]

On 12/22/22 13:13, Martin Uecker via Gcc-patches wrote:


This adds regression tests for an ICE on valid code that
seems gone on trunk, but the cause is still unclear.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103770



regressions tests for PR103770

This adds tests from bugzilla for PR103770 and duplicates.

testsuite/gcc.dg/
* pr103770.c: New test.
* pr103859.c: New test.
* pr105065.c: New test.
OK.  Though I suspect your ChangeLog will need adjustments to get past 
the commit hooks.


gcc/testsuite
* gcc.dg/pr103770.c: New test.

Would be the proper format I think.

jeff

Re: [11/13] ada: don't map NULL decl to locus

[Arnaud Charlet via Gcc-patches]

>> When decl is NULL, don't record its mapping in the
>> decl_to_instance_map.
>> Regstrapped on x86_64-linux-gnu.  Ok to install?
>> for  gcc/ada/ChangeLog
>>* gcc-interface/trans.cc (Sloc_to_locus): Don't map NULL decl.
> OK assuming that a NULL "decl" is valid -- you're in a much better position 
> than me to assess validity of a NULL "decl" here.

I confirm that this is OK and expected.

Arno

Re: [PATCH 1/1] Fixed typo in RISCV

[Jeff Law via Gcc-patches]

On 12/22/22 23:06, jinma via Gcc-patches wrote:

 From 21904908689318ab81c630adc8cc7067e1a12488 Mon Sep 17 00:00:00 2001
From: Jin Ma 
Date: Fri, 23 Dec 2022 10:42:19 +0800
Subject: [PATCH 1/1] Fixed typo

gcc/ChangeLog:

 * common/config/riscv/riscv-common.cc:

Thanks.  I've pushed this to the trunk.
jeff

Re: [RFC PATCH] RISC-V: Add support for vector crypto extensions

[Jeff Law via Gcc-patches]

On 12/21/22 11:31, Christoph Muellner wrote:

From: Christoph Müllner 

This series adds basic support for the vector crypto extensions:
* Zvkb
* Zvkg
* Zvkh[a,b]
* Zvkn
* Zvksed
* Zvksh

The implementation follows the version 20221220 of the specification,
which can be found here:
   https://github.com/riscv/riscv-crypto/releases/tag/v20221220

Note, that this specification is not frozen yet, meaning that
incompatible changes are possible.
Therefore, this patchset is marked as RFC and should not be considered
for upstream inclusion.

All extensions come with (passing) tests for the feature test macros.

A Binutils patch series for vector crypto support can be found here:
   https://sourceware.org/pipermail/binutils/2022-December/125272.html

Signed-off-by: Christoph Müllner 
---
  gcc/common/config/riscv/riscv-common.cc | 16 
  gcc/config/riscv/riscv-opts.h   | 16 
  gcc/config/riscv/riscv.opt  |  3 +++
  gcc/testsuite/gcc.target/riscv/zvkb.c   | 13 +
  gcc/testsuite/gcc.target/riscv/zvkg.c   | 13 +
  gcc/testsuite/gcc.target/riscv/zvkha.c  | 13 +
  gcc/testsuite/gcc.target/riscv/zvkhb.c  | 13 +
  gcc/testsuite/gcc.target/riscv/zvkn.c   | 13 +
  gcc/testsuite/gcc.target/riscv/zvksed.c | 13 +
  gcc/testsuite/gcc.target/riscv/zvksh.c  | 13 +
  10 files changed, 126 insertions(+)
  create mode 100644 gcc/testsuite/gcc.target/riscv/zvkb.c
  create mode 100644 gcc/testsuite/gcc.target/riscv/zvkg.c
  create mode 100644 gcc/testsuite/gcc.target/riscv/zvkha.c
  create mode 100644 gcc/testsuite/gcc.target/riscv/zvkhb.c
  create mode 100644 gcc/testsuite/gcc.target/riscv/zvkn.c
  create mode 100644 gcc/testsuite/gcc.target/riscv/zvksed.c
  create mode 100644 gcc/testsuite/gcc.target/riscv/zvksh.c
I don't see anything objectionable in here.  I'd guess that most (but 
perhaps not all) of these will wire up as builtins at some point in the 
not too distant future.



Jeff

Re: [PATCH] strlen: do not use cond_expr for boundaries

[Jeff Law via Gcc-patches]

On 12/23/22 08:44, Martin Liška wrote:

Hi.

We reach cond_expr and then we get an ICE in tree_int_cst_lt.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

PR tree-optimization/108137

gcc/ChangeLog:

* tree-ssa-strlen.cc (get_range_strlen_phi): Reject anything
different from INTEGER_CST.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/pr108137.c: New test.
OK.  You could perhaps do better by looking at the arms of the 
COND_EXPR, but this seems like the safest thing to do for gcc-13.


jeff

Re: GCC Patch Tracking [https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599882.html]

[Jeff Law via Gcc-patches]

On 12/21/22 10:36, Shinde, Yash wrote:

https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599882.html
Submission Date- Wed, 17 Aug 2022
Upstream-Status: Submitted

The given GCC patch is with it’s current status as ‘Submitted’ but still is not 
taken to the upstream. Please let us know about why the patch is not taken to 
the upstream or let us know if there is any problem in including it in upstream.
The powerpc maintainers will need to review the patch and decide if they 
want to take it now, take it later or reject.




jeff

Re: [13/13] hash-map: reject empty-looking insertions

[David Malcolm via Gcc-patches]

On Tue, 2022-12-27 at 01:39 -0300, Alexandre Oliva via Gcc-patches
wrote:
> 
> Check, after inserting entries, that they don't look empty.

Thanks for working on this - I often get this stuff wrong.

Would it make sense to also add assertions that such entries aren't
Traits::is_deleted?  (both for hash_map and hash_set)

Dave

> 
> Regstrapped on x86_64-linux-gnu.  Ok to install?
> 
> 
> for  gcc/ChangeLog
> 
> * hash-map.h (put, get_or_insert): Check that entry does not
> look empty after insertion.
> ---
>  gcc/hash-map.h |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/hash-map.h b/gcc/hash-map.h
> index 457967f4bf1ae..63fa21cf37c5b 100644
> --- a/gcc/hash-map.h
> +++ b/gcc/hash-map.h
> @@ -169,11 +169,12 @@ public:
>  {
>    hash_entry *e = m_table.find_slot_with_hash (k, Traits::hash
> (k),
>    INSERT);
> -  bool ins = hash_entry::is_empty (*e);
> +  bool ins = Traits::is_empty (*e);
>    if (ins)
> {
>   e->m_key = k;
>   new ((void *) &e->m_value) Value (v);
> + gcc_checking_assert (!Traits::is_empty (*e));
> }
>    else
> e->m_value = v;
> @@ -203,6 +204,7 @@ public:
> {
>   e->m_key = k;
>   new ((void *)&e->m_value) Value ();
> + gcc_checking_assert (!Traits::is_empty (*e));
> }
>  
>    if (existed != NULL)
> 

Re: PING: New reg note REG_CFA_NORESTORE

[Jeff Law via Gcc-patches]

On 12/13/22 01:55, Andreas Krebbel via Gcc-patches wrote:

Hi,

I need a way to save registers on the stack and generate proper CFI for it. 
Since I do not intend to
restore them I needed a way to tell the CFI generation step about it:

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606128.html

Is this ok for mainline?
Presumably there's validation bits that want to validate that everything 
saved eventually gets restored?


There's only one call to dwarf2out_frame_debug_cfa_restore, so ISTM that 
providing an initializer for the argument isn't needed and just creates 
an overload (and associated code) that isn't needed.  Why not just 
remove the default initializer?


Ok with that change or a good reason why you need to keep the initializer.

jeff

Re: [RFC]RISC-V: Support RV64-ILP32

[Jeff Law via Gcc-patches]

On 12/12/22 23:49, shi...@iscas.ac.cn wrote:

From: Liao Shihua 

   This patch support rv64 insn in ilp32 ABI. It was inspired by aarch64 
both
support 64-bit and 32-bit ABI with the same set of instructions.


gcc/ChangeLog:

 * config.gcc:  Implememt ilp32* with rv64*.
 * config/riscv/riscv.cc (riscv_option_override): Remove the constraint 
between RV64 and ILP32.
 * config/riscv/riscv.h (TARGET_ILP32): Define TARGET_ILP32 with 
riscv_abi.
 (POINTER_SIZE):POINTER_SIZE will change with TARGET_ILP32.
 (Pmode):Likewise.
 * config/riscv/riscv.md: Convert split mode with Pmode and change mode 
form Xmode to Pmode in stack_tie.
This is a new feature and thus I think we should defer to gcc-14 unless 
there is a compelling need.


jeff

Re: [RFC]RISC-V: Support RV64-ILP32

[Palmer Dabbelt]

On Tue, 27 Dec 2022 10:24:10 PST (-0800), gcc-patches@gcc.gnu.org wrote:



On 12/12/22 23:49, shi...@iscas.ac.cn wrote:

From: Liao Shihua 

   This patch support rv64 insn in ilp32 ABI. It was inspired by aarch64 
both
support 64-bit and 32-bit ABI with the same set of instructions.


gcc/ChangeLog:

 * config.gcc:  Implememt ilp32* with rv64*.
 * config/riscv/riscv.cc (riscv_option_override): Remove the constraint 
between RV64 and ILP32.
 * config/riscv/riscv.h (TARGET_ILP32): Define TARGET_ILP32 with 
riscv_abi.
 (POINTER_SIZE):POINTER_SIZE will change with TARGET_ILP32.
 (Pmode):Likewise.
 * config/riscv/riscv.md: Convert split mode with Pmode and change mode 
form Xmode to Pmode in stack_tie.

This is a new feature and thus I think we should defer to gcc-14 unless
there is a compelling need.


I agree.  This is a pretty big one with a lot of ABI-related 
complications, so let's just play it safe.

Re: [PATCH] tree-optimization/105043: Object Size Checking docs cleanup

[Jeff Law via Gcc-patches]

On 12/15/22 12:25, Siddhesh Poyarekar wrote:

Break the _FORTIFY_SOURCE-specific builtins out into a separate
subsection from Object Size Checking built-ins and mention
_FORTIFY_SOURCE in there so that the link between the object size
checking builtins, the helper builtins (e.g. __builtin___memcpy_chk) and
_FORTIFY_SOURCE is clearer.

gcc/ChangeLog:

PR tree-optimization/105043
* doc/extend.texi (Object Size Checking): Split out into two
subsections and mention _FORTIFY_SOURCE.

OK
jeff

Re: [PATCH] RISC-V: Support VSETVL PASS for RVV support

[Jeff Law via Gcc-patches]

On 12/19/22 15:59, 钟居哲 wrote:

 >> ISTM that if you want to run before sched2, then

you'd need to introduce dependencies between the vsetvl instrutions and
the vector instructions that utilize those settings?


Yes, I want to run before sched2 so that we could have the chance to do the
instruction scheduling before sched2. I already introduce dependencies in
vector instructions so that it won't produce any issues.
Ah good that you're adding the necessary dependencies.  We'd been 
talking a bit about this internally.  The hope is that on an OOO machine 
the vsetvl will be able to issue/execute relatively early, but on an 
in-order machine the ability to schedule the vsetvl could become 
significantly more important.





 >> It'd probably be better to move this into rtl.cc with a prototype in

rtl.h rather than have duplicate definitions in gcse.c and the RISC-V
backend.  I'm not even entirely sure why we really need it here.

Maybe we do that when GCC14 is open?
If we're just making a routine external that previously had static scope 
then we can still do that IMHO.  Such a change won't affect code 
generation so it should be extremely safe.  I'm happy to engage with 
Richi and Jakub to get their sign-off on such a change.




Jeff

Re: [RFC PATCH] RISC-V: Add support for vector crypto extensions

[Palmer Dabbelt]

On Tue, 27 Dec 2022 09:35:55 PST (-0800), gcc-patches@gcc.gnu.org wrote:



On 12/21/22 11:31, Christoph Muellner wrote:

From: Christoph Müllner 

This series adds basic support for the vector crypto extensions:
* Zvkb
* Zvkg
* Zvkh[a,b]
* Zvkn
* Zvksed
* Zvksh

The implementation follows the version 20221220 of the specification,
which can be found here:
   https://github.com/riscv/riscv-crypto/releases/tag/v20221220

Note, that this specification is not frozen yet, meaning that
incompatible changes are possible.
Therefore, this patchset is marked as RFC and should not be considered
for upstream inclusion.

All extensions come with (passing) tests for the feature test macros.

A Binutils patch series for vector crypto support can be found here:
   https://sourceware.org/pipermail/binutils/2022-December/125272.html

Signed-off-by: Christoph Müllner 
---
  gcc/common/config/riscv/riscv-common.cc | 16 
  gcc/config/riscv/riscv-opts.h   | 16 
  gcc/config/riscv/riscv.opt  |  3 +++
  gcc/testsuite/gcc.target/riscv/zvkb.c   | 13 +
  gcc/testsuite/gcc.target/riscv/zvkg.c   | 13 +
  gcc/testsuite/gcc.target/riscv/zvkha.c  | 13 +
  gcc/testsuite/gcc.target/riscv/zvkhb.c  | 13 +
  gcc/testsuite/gcc.target/riscv/zvkn.c   | 13 +
  gcc/testsuite/gcc.target/riscv/zvksed.c | 13 +
  gcc/testsuite/gcc.target/riscv/zvksh.c  | 13 +
  10 files changed, 126 insertions(+)
  create mode 100644 gcc/testsuite/gcc.target/riscv/zvkb.c
  create mode 100644 gcc/testsuite/gcc.target/riscv/zvkg.c
  create mode 100644 gcc/testsuite/gcc.target/riscv/zvkha.c
  create mode 100644 gcc/testsuite/gcc.target/riscv/zvkhb.c
  create mode 100644 gcc/testsuite/gcc.target/riscv/zvkn.c
  create mode 100644 gcc/testsuite/gcc.target/riscv/zvksed.c
  create mode 100644 gcc/testsuite/gcc.target/riscv/zvksh.c

I don't see anything objectionable in here.  I'd guess that most (but
perhaps not all) of these will wire up as builtins at some point in the
not too distant future.


These allow things like `-march=rv64gc_zvksh`, it's not really clear 
what the indented behavior is there -- specifically, does that 
implicitly enable some base vector extension?


I've just skimmed the ISA manual here, but all I can find is a bit 
ambiguous


   With the exception of Zvknhb, each of these Vector Crypto Extensions 
   can be build on any base Vector Extension, embedded (Zve*) or 
   application ("V"). Zvknhb requires ELEN=64 and therefore cannot be 
   implemented on a Zve32* base.


I doubt it really matters which way we pick, but it is something we're 
going to need to keep consistent moving forwards as otherwise users 
might get some surprising behavior.  This has come up a bunch of times, 
but there's slightly different wording each time in the specs and I'm 
never really sure what to read of it.


I don't think that alone would be enough to delay this for gcc-14, but 
as far as I can tell binutils is branching very soon for a target 
release in the middle of January.  I'm guessing these extensions will 
not be frozen by then, which would be a blocker.


I'm not sure if anyone has a pressing need for these?  If not, I think 
it's best to delay them until binutils-2.41 (and presumably then 
gcc-14).

Re: [RFC PATCH] RISC-V: Add support for vector crypto extensions

[Philipp Tomsich]

On Tue, 27 Dec 2022 at 19:58, Palmer Dabbelt  wrote:
>
> On Tue, 27 Dec 2022 09:35:55 PST (-0800), gcc-patches@gcc.gnu.org wrote:
> >
> >
> > On 12/21/22 11:31, Christoph Muellner wrote:
> >> From: Christoph Müllner 
> >>
> >> This series adds basic support for the vector crypto extensions:
> >> * Zvkb
> >> * Zvkg
> >> * Zvkh[a,b]
> >> * Zvkn
> >> * Zvksed
> >> * Zvksh
> >>
> >> The implementation follows the version 20221220 of the specification,
> >> which can be found here:
> >>https://github.com/riscv/riscv-crypto/releases/tag/v20221220
> >>
> >> Note, that this specification is not frozen yet, meaning that
> >> incompatible changes are possible.
> >> Therefore, this patchset is marked as RFC and should not be considered
> >> for upstream inclusion.
> >>
> >> All extensions come with (passing) tests for the feature test macros.
> >>
> >> A Binutils patch series for vector crypto support can be found here:
> >>https://sourceware.org/pipermail/binutils/2022-December/125272.html
> >>
> >> Signed-off-by: Christoph Müllner 
> >> ---
> >>   gcc/common/config/riscv/riscv-common.cc | 16 
> >>   gcc/config/riscv/riscv-opts.h   | 16 
> >>   gcc/config/riscv/riscv.opt  |  3 +++
> >>   gcc/testsuite/gcc.target/riscv/zvkb.c   | 13 +
> >>   gcc/testsuite/gcc.target/riscv/zvkg.c   | 13 +
> >>   gcc/testsuite/gcc.target/riscv/zvkha.c  | 13 +
> >>   gcc/testsuite/gcc.target/riscv/zvkhb.c  | 13 +
> >>   gcc/testsuite/gcc.target/riscv/zvkn.c   | 13 +
> >>   gcc/testsuite/gcc.target/riscv/zvksed.c | 13 +
> >>   gcc/testsuite/gcc.target/riscv/zvksh.c  | 13 +
> >>   10 files changed, 126 insertions(+)
> >>   create mode 100644 gcc/testsuite/gcc.target/riscv/zvkb.c
> >>   create mode 100644 gcc/testsuite/gcc.target/riscv/zvkg.c
> >>   create mode 100644 gcc/testsuite/gcc.target/riscv/zvkha.c
> >>   create mode 100644 gcc/testsuite/gcc.target/riscv/zvkhb.c
> >>   create mode 100644 gcc/testsuite/gcc.target/riscv/zvkn.c
> >>   create mode 100644 gcc/testsuite/gcc.target/riscv/zvksed.c
> >>   create mode 100644 gcc/testsuite/gcc.target/riscv/zvksh.c
> > I don't see anything objectionable in here.  I'd guess that most (but
> > perhaps not all) of these will wire up as builtins at some point in the
> > not too distant future.
>
> These allow things like `-march=rv64gc_zvksh`, it's not really clear
> what the indented behavior is there -- specifically, does that
> implicitly enable some base vector extension?
>
> I've just skimmed the ISA manual here, but all I can find is a bit
> ambiguous
>
> With the exception of Zvknhb, each of these Vector Crypto Extensions
> can be build on any base Vector Extension, embedded (Zve*) or
> application ("V"). Zvknhb requires ELEN=64 and therefore cannot be
> implemented on a Zve32* base.
>
> I doubt it really matters which way we pick, but it is something we're
> going to need to keep consistent moving forwards as otherwise users
> might get some surprising behavior.  This has come up a bunch of times,
> but there's slightly different wording each time in the specs and I'm
> never really sure what to read of it.
>
> I don't think that alone would be enough to delay this for gcc-14, but
> as far as I can tell binutils is branching very soon for a target
> release in the middle of January.  I'm guessing these extensions will
> not be frozen by then, which would be a blocker.
>
> I'm not sure if anyone has a pressing need for these?  If not, I think
> it's best to delay them until binutils-2.41 (and presumably then
> gcc-14).

Given that the encodings last changed on Dec 21st, I would also prefer
if we could off until after the binutils-2.40 has been released.

Philipp.

Re: [PATCH v2 01/11] riscv: attr: Synchronize comments with code

[Philipp Tomsich]

Applied to master, thanks!

Philipp.

On Mon, 19 Dec 2022 at 03:49, Kito Cheng  wrote:

> LGTM, you can commit this separately if you want :)
>
> On Mon, Dec 19, 2022 at 9:09 AM Christoph Muellner
>  wrote:
> >
> > From: Christoph Müllner 
> >
> > The comment above the enumeration of existing attributes got out of
> > order and a few entries were forgotten.
> > This patch synchronizes the comments according to the list.
> > This commit does not include any functional change.
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/riscv.md: Sync comments with code.
> >
> > Signed-off-by: Christoph Müllner 
> > ---
> >  gcc/config/riscv/riscv.md | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
> > index df57e2b0b4a..a8bb331f25c 100644
> > --- a/gcc/config/riscv/riscv.md
> > +++ b/gcc/config/riscv/riscv.md
> > @@ -220,7 +220,6 @@ (define_attr "enabled" "no,yes"
> >  ;; mfc transfer from coprocessor
> >  ;; const   load constant
> >  ;; arith   integer arithmetic instructions
> > -;; auipc   integer addition to PC
> >  ;; logical  integer logical instructions
> >  ;; shift   integer shift instructions
> >  ;; slt set less than instructions
> > @@ -236,9 +235,13 @@ (define_attr "enabled" "no,yes"
> >  ;; fcvtfloating point convert
> >  ;; fsqrt   floating point square root
> >  ;; multi   multiword sequence (or user asm statements)
> > +;; auipc   integer addition to PC
> > +;; sfb_alu  SFB ALU instruction
> >  ;; nop no operation
> >  ;; ghost   an instruction that produces no real code
> >  ;; bitmanipbit manipulation instructions
> > +;; rotate   rotation instructions
> > +;; atomic   atomic instructions
> >  ;; Classification of RVV instructions which will be added to each RVV
> .md pattern and used by scheduler.
> >  ;; rdvlenb vector byte length vlenb csrr read
> >  ;; rdvlvector length vl csrr read
> > --
> > 2.38.1
> >
>

Re: [PATCH v2 02/11] riscv: Restructure callee-saved register save/restore code

[Philipp Tomsich]

Applied to master (with the change from the reviews), thanks!

Philipp.

On Mon, 19 Dec 2022 at 07:30, Kito Cheng  wrote:

> just one more nit: Use INVALID_REGNUM as sentinel value for
> riscv_next_saved_reg, otherwise LGTM, and feel free to commit that
> separately :)
>
> On Mon, Dec 19, 2022 at 9:08 AM Christoph Muellner
>  wrote:
> >
> > From: Christoph Müllner 
> >
> > This patch restructures the loop over the GP registers
> > which saves/restores then as part of the prologue/epilogue.
> > No functional change is intended by this patch, but it
> > offers the possibility to use load-pair/store-pair instructions.
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/riscv.cc (riscv_next_saved_reg): New function.
> > (riscv_is_eh_return_data_register): New function.
> > (riscv_for_each_saved_reg): Restructure loop.
> >
> > Signed-off-by: Christoph Müllner 
> > ---
> >  gcc/config/riscv/riscv.cc | 94 +++
> >  1 file changed, 66 insertions(+), 28 deletions(-)
> >
> > diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> > index 6dd2ab2d11e..a8d5e1dac7f 100644
> > --- a/gcc/config/riscv/riscv.cc
> > +++ b/gcc/config/riscv/riscv.cc
> > @@ -4835,6 +4835,49 @@ riscv_save_restore_reg (machine_mode mode, int
> regno,
> >fn (gen_rtx_REG (mode, regno), mem);
> >  }
> >
> > +/* Return the next register up from REGNO up to LIMIT for the callee
> > +   to save or restore.  OFFSET will be adjusted accordingly.
> > +   If INC is set, then REGNO will be incremented first.  */
> > +
> > +static unsigned int
> > +riscv_next_saved_reg (unsigned int regno, unsigned int limit,
> > + HOST_WIDE_INT *offset, bool inc = true)
> > +{
> > +  if (inc)
> > +regno++;
> > +
> > +  while (regno <= limit)
> > +{
> > +  if (BITSET_P (cfun->machine->frame.mask, regno - GP_REG_FIRST))
> > +   {
> > + *offset = *offset - UNITS_PER_WORD;
> > + break;
> > +   }
> > +
> > +  regno++;
> > +}
> > +  return regno;
> > +}
> > +
> > +/* Return TRUE if provided REGNO is eh return data register.  */
> > +
> > +static bool
> > +riscv_is_eh_return_data_register (unsigned int regno)
> > +{
> > +  unsigned int i, regnum;
> > +
> > +  if (!crtl->calls_eh_return)
> > +return false;
> > +
> > +  for (i = 0; (regnum = EH_RETURN_DATA_REGNO (i)) != INVALID_REGNUM;
> i++)
> > +if (regno == regnum)
> > +  {
> > +   return true;
> > +  }
> > +
> > +  return false;
> > +}
> > +
> >  /* Call FN for each register that is saved by the current function.
> > SP_OFFSET is the offset of the current stack pointer from the start
> > of the frame.  */
> > @@ -4844,36 +4887,31 @@ riscv_for_each_saved_reg (poly_int64 sp_offset,
> riscv_save_restore_fn fn,
> >   bool epilogue, bool maybe_eh_return)
> >  {
> >HOST_WIDE_INT offset;
> > +  unsigned int regno;
> > +  unsigned int start = GP_REG_FIRST;
> > +  unsigned int limit = GP_REG_LAST;
> >
> >/* Save the link register and s-registers. */
> > -  offset = (cfun->machine->frame.gp_sp_offset - sp_offset).to_constant
> ();
> > -  for (unsigned int regno = GP_REG_FIRST; regno <= GP_REG_LAST; regno++)
> > -if (BITSET_P (cfun->machine->frame.mask, regno - GP_REG_FIRST))
> > -  {
> > -   bool handle_reg =
> !cfun->machine->reg_is_wrapped_separately[regno];
> > -
> > -   /* If this is a normal return in a function that calls the
> eh_return
> > -  builtin, then do not restore the eh return data registers as
> that
> > -  would clobber the return value.  But we do still need to save
> them
> > -  in the prologue, and restore them for an exception return, so
> we
> > -  need special handling here.  */
> > -   if (epilogue && !maybe_eh_return && crtl->calls_eh_return)
> > - {
> > -   unsigned int i, regnum;
> > -
> > -   for (i = 0; (regnum = EH_RETURN_DATA_REGNO (i)) !=
> INVALID_REGNUM;
> > -i++)
> > - if (regno == regnum)
> > -   {
> > - handle_reg = FALSE;
> > - break;
> > -   }
> > - }
> > -
> > -   if (handle_reg)
> > - riscv_save_restore_reg (word_mode, regno, offset, fn);
> > -   offset -= UNITS_PER_WORD;
> > -  }
> > +  offset = (cfun->machine->frame.gp_sp_offset - sp_offset).to_constant
> ()
> > +  + UNITS_PER_WORD;
> > +  for (regno = riscv_next_saved_reg (start, limit, &offset, false);
> > +   regno <= limit;
> > +   regno = riscv_next_saved_reg (regno, limit, &offset))
> > +{
> > +  if (cfun->machine->reg_is_wrapped_separately[regno])
> > +   continue;
> > +
> > +  /* If this is a normal return in a function that calls the
> eh_return
> > +builtin, then do not restore the eh return data registers as
> that
> > +would clobber the return value.  But we do still need to save
> them
> > +in the prol

Re: [PATCH] RISC-V: Fix RVV mask mode size

[Jeff Law via Gcc-patches]

On 12/19/22 00:44, Richard Biener wrote:

On Sat, Dec 17, 2022 at 2:54 AM Jeff Law via Gcc-patches
 wrote:




On 12/16/22 18:44, 钟居哲 wrote:

Yes, VNx4DF only has 4 bit in mask mode in case of load and store.
For example vlm or vsm we will load store 8-bit ??? (I am not sure
hardward can load store 4bit,but I am sure it definetly not load store
the whole register size)

Most likely than not you end up loading a larger quantity with the high
bits zero'd.  Interesting that we're using a packed model.  I'd been
told it was fairly expensive to implement in hardware relative to teh
cost of implementing the sparse model.


Since the masks are extra inputs if you use a packed model you need
to wire less bits into the execution units for the masks which I guess
is actually cheaper.  Yes, producing the masks might be more complicated.
We went through this at a prior employer and the hardware guys argued 
strongly that a packed model for mask registers was just too expensive 
to implement.  I don't think it was the # of wires, but the muxes.  The 
number of wires into the unit was an issue when we started talking about 
sub-byte masking :-)


Conceptually on the hardware side each bit in the mask corresponds to a 
byte in a vector register.  When the element size is 8 bits, then 
obviously there is a 1:1 correspondence between potentially masked 
elements and bits the mask register.


When the element size is 32 bits, then there are 3 don't care bits in 
the mask register, then a single bit that is queried for masked 
operations.  So if you had a 128bit vector with 32 bits per element, a 
mask register might have a value like:


0xxx 1xxx 1xxx 0xxx

A 128 bit vector with 64 bits per element might be:

0xxx  1xxx 

Where the xxxs are don't cares and the 0/1 are the masks.





The only "issue" might be with 4, 2 and 1 bit masks which would
have a size of 8 bits but a precision of less that endianess might
play a role.

Btw, this is all similar to AVX512 where we even don't use
vector BI modes but integer modes for the mask which
then becomes QImode for 1, 2, 4 and 8 bit masks and
HImode for 16, SImode for 32 and DImode for 64 bit masks.

Right.  I think in hindsight that might have been a mistake.

jeff

Re: [PATCH] RISC-V: Fix ICE of visiting non-existing block in CFG.

[Jeff Law via Gcc-patches]

On 12/23/22 20:08, juzhe.zh...@rivai.ai wrote:

From: Ju-Zhe Zhong 

This patch is to fix issue of visiting non-existing block of CFG.
Since blocks index of CFG in GCC are not always contiguous, we will potentially
visit a gap block which is no existing in the current CFG.

This patch can avoid visiting non existing block in CFG.

I noticed such issue in my internal regression of current testsuite
when I change the X86 server machine. This patch fix it:
17:27:15  job(build_and_test_rv32): Increased FAIL List:
17:27:15  job(build_and_test_rv32): FAIL: 
gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-46.c
-O2 -flto -fno-use-linker-plugin -flto-partition=none  (internal compiler 
error: Segmentation fault)

gcc/ChangeLog:

 * config/riscv/riscv-vsetvl.cc 
(pass_vsetvl::compute_global_backward_infos): Change to visit CFG.
 (pass_vsetvl::prune_expressions): Ditto.

The usual way to iterate over the blocks is something like this

basic_block bb
FOR_EACH_BB (bb, cfun)
  {
do whatever you need on BB
  }

Please use that form as that's what most folks working with GCC are 
already using.


Jeff

Re: [Bug c/108224] [PATCH] add srandom random initstate setstate

[Jonny Grant]

On 26/12/2022 09:19, Prathamesh Kulkarni wrote:
> On Mon, 26 Dec 2022 at 14:25, Jonny Grant  wrote:
>>
>>
>>
>> From 6ff344979af46dbcd739dd9068d6d595547e4c27 Mon Sep 17 00:00:00 2001
>> From: Jonathan Grant 
>> Date: Sun, 25 Dec 2022 22:38:44 +
>> Subject: [PATCH] add srandom random initstate setstate
>>
>> ---
>>  gcc/c-family/known-headers.cc | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/gcc/c-family/known-headers.cc b/gcc/c-family/known-headers.cc
>> index 9c256173b82..ade9fa2dcc0 100644
>> --- a/gcc/c-family/known-headers.cc
>> +++ b/gcc/c-family/known-headers.cc
>> @@ -171,6 +171,10 @@ get_stdlib_header_for_name (const char *name, enum 
>> stdlib lib)
>>  {"getenv", {"", ""} },
>>  {"malloc", {"", ""} },
>>  {"realloc", {"", ""} },
>> +{"random", {"", ""} },
>> +{"srandom", {"", ""} },
>> +{"initstate", {"", ""} },
>> +{"setstate", {"", ""} },
>>
>>  /*  and .  */
>>  {"memchr", {"", ""} },
> Hi Jonny,
> Thanks for the patch. A couple of things:
> (a) Could you please add a test-case for the above symbols ? See
> testsuite/gcc.dg/missing-header-fixit-4.c
> for a similar example for printf.
> (b) The patch is missing changelog.
> I assume you've tested the patch with bootstrap+regtest ?

Hi Prathmesh
Many thanks for your reply.

I built gcc by typing "make", I understand that is the bootstrap. I don't know 
about regtest, could you direct me to a guide please.

I didn't add a test; I can do that now. Is there an FAQ you can direct me to to 
run those tests please.

Running ‘make check-c’ now, its taking along time on gcc.c-torture.
Is there a way I can quickly run only the gcc.dg missing header tests?

BTW, do you know if a change could be made to detect dejagnu being installed?

Would be good if "make check" quickly failed if the "runtest" command from 
dejagnu was not found.

I needed to install these two packages. Would be good to get a hint when 
running ‘make check-c’
autogen dejagnu


For the files like missing-header-fixit-4.c is it sufficient to just add a file 
to that folder?
Cheers
Jonny

Re: [PATCH v2] RISC-V: Produce better code with complex constants [PR95632] [PR106602]

[Jeff Law via Gcc-patches]

On 12/9/22 11:25, Raphael Moreira Zinsly wrote:

Changes since v1:
- Fixed formatting issues.
- Added a name to the define_insn_and_split pattern.
- Set the target on the 'dg-do compile' in pr106602.c.
- Removed the rv32 restriction in pr95632.c.

-- >8 --

Due to RISC-V limitations on operations with big constants combine
is failing to match such operations and is not being able to
produce optimal code as it keeps splitting them.  By pretending we
can do those operations we can get more opportunities for
simplification of surrounding instructions.

2022-12-06  Raphael Moreira Zinsly  
Jeff Law  

gcc/Changelog:
PR target/95632
PR target/106602
* config/riscv/riscv.md: New pattern to simulate complex
const_int loads.

gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr95632.c: New test.
* gcc.target/riscv/pr106602.c: New test.

Here's the final version of the patch that addresses these two BZs.

This version tightens slightly the condition for the new pattern so that 
it doesn't match two special cases.


In particular, we avoid certain constants which are used in 
define_splits where the constant load feeds a logical AND which can 
ultimately be implemented via a pair of shifts.


Those cases are 3->2 splits on the trunk.  If we allowed those constants 
in the new pattern, then we'd need to support 2->2 splits in combine.c 
which is a non-starter.


Bootstrapped and regression tested on riscv64-linux-gnu.  I also 
compared resultant assembly code with/without this change for all the 
source files in the compiler natively to look for further regressions.


Committed to the trunk,
Jeffcommit 2e886eef7f2b5aadb00171af868f0895b647c3a4
Author: Raphael Moreira Zinsly 
Date:   Tue Dec 27 18:29:25 2022 -0500

RISC-V: Produce better code with complex constants [PR95632] [PR106602]

gcc/Changelog:
PR target/95632
PR target/106602
* config/riscv/riscv.md: New pattern to simulate complex
const_int loads.

gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr95632.c: New test.
* gcc.target/riscv/pr106602.c: New test.

diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index a8bb331f25c..020833b9206 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -1670,6 +1670,23 @@ (define_split
  MAX_MACHINE_MODE, &operands[3], TRUE);
 })
 
+;; Pretend to have the ability to load complex const_int in order to get
+;; better code generation around them.
+;;
+;; But avoid constants that are special cased elsewhere.
+(define_insn_and_split "*mvconst_internal"
+  [(set (match_operand:GPR 0 "register_operand" "=r")
+(match_operand:GPR 1 "splittable_const_int_operand" "i"))]
+  "!(p2m1_shift_operand (operands[1]) || high_mask_shift_operand 
(operands[1]))"
+  "#"
+  "&& 1"
+  [(const_int 0)]
+{
+  riscv_move_integer (operands[0], operands[0], INTVAL (operands[1]),
+  mode, TRUE);
+  DONE;
+})
+
 ;; 64-bit integer moves
 
 (define_expand "movdi"
diff --git a/gcc/testsuite/gcc.target/riscv/pr106602.c 
b/gcc/testsuite/gcc.target/riscv/pr106602.c
new file mode 100644
index 000..825b1a143b5
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/pr106602.c
@@ -0,0 +1,14 @@
+/* { dg-do compile { target { riscv64*-*-* } } } */
+/* { dg-options "-O2" } */
+
+unsigned long
+foo2 (unsigned long a)
+{
+  return (unsigned long)(unsigned int) a << 6;
+}
+
+/* { dg-final { scan-assembler-times "slli\t" 1 } } */
+/* { dg-final { scan-assembler-times "srli\t" 1 } } */
+/* { dg-final { scan-assembler-not "\tli\t" } } */
+/* { dg-final { scan-assembler-not "addi\t" } } */
+/* { dg-final { scan-assembler-not "and\t" } } */
diff --git a/gcc/testsuite/gcc.target/riscv/pr95632.c 
b/gcc/testsuite/gcc.target/riscv/pr95632.c
new file mode 100644
index 000..b865c2f2e97
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/pr95632.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+unsigned short
+foo (unsigned short crc)
+{
+  crc ^= 0x4002;
+  crc >>= 1;
+  crc |= 0x8000;
+
+  return crc;
+}
+
+/* { dg-final { scan-assembler-times "srli\t" 1 } } */
+/* { dg-final { scan-assembler-not "slli\t" } } */

Re: [PATCH] RISC-V: Fix ICE of visiting non-existing block in CFG.

[Jeff Law via Gcc-patches]

On 12/27/22 16:11, juzhe.zhong wrote:
You mean only change to this form you suggested in this patch？ Since in 
all other places of this PASS，I use RTL_SSA framework to iterate 
instructions and blocks. I use RTL_SSA framework to iterate blocks here 
to make codes look more consistent even though they are same here.
The FOR_EACH_BB is used far more widely than the C++ style found in 
RTL-SSA so I'd slightly prefer that style.


jeff

[x86 PATCH] Use ix86_expand_clear in ix86_split_ashl.

[Roger Sayle]

This patch is a one line change, to call ix86_expand_clear instead of
emit_move_insn with const0_rtx in ix86_split_ashl, allowing the backend
to use an xor instruction to clear a register if appropriate.

The effect is demonstrated with the following function.
__int128 foo(__int128 x, unsigned long long b) {
return ((__int128)b << 72) + x;
}

previously with -O2, GCC would generate

foo:movl$0, %eax
salq$8, %rdx
addq%rdi, %rax
adcq%rsi, %rdx
ret

with this patch, it now generates

foo:xorl%eax, %eax
salq$8, %rdx
addq%rdi, %rax
adcq%rsi, %rdx
ret

This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32},
with no new failures.  It's an independent piece of a larger bug fix.
Ok for mainline?


2022-12-28  Roger Sayle  

gcc/ChangeLog
* config/i386/i386-expand.cc (ix86_split_ashl): Call
ix86_expand_clear to generate an xor instruction.

gcc/testsuite/ChangeLog
* gcc.target/i386/ashlti3-1.c: New test case.


Thanks in advance,
Roger
--

diff --git a/gcc/config/i386/i386-expand.cc b/gcc/config/i386/i386-expand.cc
index b6cc76d..3eddbc9 100644
--- a/gcc/config/i386/i386-expand.cc
+++ b/gcc/config/i386/i386-expand.cc
@@ -6211,7 +6211,7 @@ ix86_split_ashl (rtx *operands, rtx scratch, machine_mode 
mode)
   if (count >= half_width)
{
  emit_move_insn (high[0], low[1]);
- emit_move_insn (low[0], const0_rtx);
+ ix86_expand_clear (low[0]);
 
  if (count > half_width)
ix86_expand_ashl_const (high[0], count - half_width, mode);
diff --git a/gcc/testsuite/gcc.target/i386/ashlti3-1.c 
b/gcc/testsuite/gcc.target/i386/ashlti3-1.c
new file mode 100644
index 000..1cf1306
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/ashlti3-1.c
@@ -0,0 +1,6 @@
+/* { dg-do compile { target int128 } } */
+/* { dg-options "-O2" } */
+__int128 foo(__int128 x, unsigned long long b) {
+return ((__int128)b << 72) + x;
+}
+/* { dg-final { scan-assembler-not "\tmovl\[ \\t\]+\\\$0," } } */

Re: Re: [PATCH] RISC-V: Fix ICE of visiting non-existing block in CFG.

[钟居哲]

OK, I will change that after I finished my current work.



juzhe.zh...@rivai.ai
 
From: Jeff Law
Date: 2022-12-28 08:06
To: juzhe.zhong
CC: gcc-patches@gcc.gnu.org; kito.ch...@gmail.com; pal...@dabbelt.com
Subject: Re: [PATCH] RISC-V: Fix ICE of visiting non-existing block in CFG.
 
 
On 12/27/22 16:11, juzhe.zhong wrote:
> You mean only change to this form you suggested in this patch？ Since in 
> all other places of this PASS，I use RTL_SSA framework to iterate 
> instructions and blocks. I use RTL_SSA framework to iterate blocks here 
> to make codes look more consistent even though they are same here.
The FOR_EACH_BB is used far more widely than the C++ style found in 
RTL-SSA so I'd slightly prefer that style.
 
jeff
 

[x86_64 PATCH] Add post-reload splitter for extendditi2.

[Roger Sayle]

This is another step towards a possible solution for PR 105137.
This patch introduces a define_insn_and_split for extendditi2,
that allows DImode to TImode sign-extension to be represented in
the early RTL optimizers, before being split post-reload into
the exact same idiom as currently produced by RTL expansion.

Typically this produces the identical code, so the first new
test case:
__int128 foo(long long x) { return (__int128)x; }

continues to generate:
foo:movq%rdi, %rax
cqto
ret

The "magic" is that this representation allows combine and the
other RTL optimizers to do a better job.  Hence, the second
test case:

__int128 foo(__int128 a, long long b) {
a += ((__int128)b) << 70;
return a;
}

which mainline with -O2 currently generates as:

foo:movq%rsi, %rax
movq%rdx, %rcx
movq%rdi, %rsi
salq$6, %rcx
movq%rax, %rdi
xorl%eax, %eax
movq%rcx, %rdx
addq%rsi, %rax
adcq%rdi, %rdx
ret

with this patch now becomes:
foo:movl$0, %eax
salq$6, %rdx
addq%rdi, %rax
adcq%rsi, %rdx
ret

i.e. the same code for the signed and unsigned extension variants.

This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32},
with no new failures.  Ok for mainline?

2022-12-28  Roger Sayle  

gcc/ChangeLog
* config/i386/i386.md (extendditi2): New define_insn_and_split
to split DImode to TImode sign-extension after reload.

gcc/testsuite/ChangeLog
* gcc.target/i386/extendditi2-1.c: New test case.
* gcc.target/i386/extendditi2-2.c: Likewise.


Thanks in advance,
Roger
--

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 0626752..fabddc2 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -4756,6 +4756,38 @@
  (if_then_else (eq_attr "prefix_0f" "0")
(const_string "0")
(const_string "1")))])
+
+(define_insn_and_split "extendditi2"
+  [(set (match_operand:TI 0 "register_operand" "=r")
+   (sign_extend:TI (match_operand:DI 1 "register_operand" "r")))
+   (clobber (reg:CC FLAGS_REG))]
+  "TARGET_64BIT"
+  "#"
+  "&& reload_completed"
+  [(const_int 0)]
+{
+  split_double_mode (TImode, &operands[0], 1, &operands[2], &operands[3]);
+  if (REGNO (operands[1]) != REGNO (operands[2]))
+emit_move_insn (operands[2], operands[1]);
+
+  rtx src = operands[1];
+  if (REGNO (operands[2]) == AX_REG)
+src = operands[2];
+
+  /* Generate a cltd if possible and doing so it profitable.  */
+  if ((optimize_function_for_size_p (cfun) || TARGET_USE_CLTD)
+  && REGNO (operands[3]) == DX_REG
+  && REGNO (src) == AX_REG)
+{
+  emit_insn (gen_ashrdi3_cvt (operands[3], src, GEN_INT (63)));
+}
+  else
+{
+  if (REGNO (operands[1]) != REGNO (operands[3]))
+   emit_move_insn (operands[3], operands[1]);
+  emit_insn (gen_ashrdi3_cvt (operands[3], operands[3], GEN_INT (63)));
+}
+})
 
 ;; Conversions between float and double.
 
diff --git a/gcc/testsuite/gcc.target/i386/extendditi2-1.c 
b/gcc/testsuite/gcc.target/i386/extendditi2-1.c
new file mode 100644
index 000..846afef
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/extendditi2-1.c
@@ -0,0 +1,8 @@
+/* { dg-do compile { target int128 } } */
+/* { dg-options "-O2" } */
+
+__int128 foo(long long x)
+{
+  return (__int128)x;
+}
+/* { dg-final { scan-assembler "cqto" } } */
diff --git a/gcc/testsuite/gcc.target/i386/extendditi2-2.c 
b/gcc/testsuite/gcc.target/i386/extendditi2-2.c
new file mode 100644
index 000..dbfa6fb
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/extendditi2-2.c
@@ -0,0 +1,13 @@
+/* { dg-do compile { target int128 } } */
+/* { dg-options "-O2" } */
+
+__int128 foo(__int128 a, long long b) {
+a += ((__int128)b) << 70;
+return a;
+}
+
+__int128 bar(__int128 a, unsigned long long b) {
+a += ((__int128)b) << 70;
+return a;
+}
+/* { dg-final { scan-assembler-not "movq" } } */

Re: Re: [PATCH] RISC-V: Fix ICE for avl_info deprecated copy and pp_print error.

[Kito Cheng via Gcc-patches]

Committed.

On Sun, Dec 25, 2022 at 6:42 AM 钟居哲  wrote:
>
> I just want to make sure. You mean the bootstrap can pass now with this patch?
> If yes, plz merge this patch. Thank you so much.
>
>
>
> juzhe.zh...@rivai.ai
>
> From: Andreas Schwab
> Date: 2022-12-25 00:58
> To: juzhe.zhong
> CC: gcc-patches
> Subject: Re: [PATCH] RISC-V: Fix ICE for avl_info deprecated copy and 
> pp_print error.
> On Dez 23 2022, juzhe.zh...@rivai.ai wrote:
>
> > * config/riscv/riscv-vsetvl.cc (change_insn): Remove pp_print.
> > (avl_info::avl_info): Add copy function.
> > (vector_insn_info::dump): Remove pp_print.
> > * config/riscv/riscv-vsetvl.h: Add copy function.
>
> Survived bootstrap so far.
>
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
> "And now for something completely different."
>

Re: [PATCH] RISC-V: Fix ICE of visiting non-existing block in CFG.

[Jeff Law via Gcc-patches]

On 12/27/22 17:24, 钟居哲 wrote:

OK, I will change that after I finished my current work.

Sounds good.  Thanks.

Jeff

[x86 PATCH] Provide zero_extend versions/variants of several patterns.

[Roger Sayle]

Back in September, the review of my patch for PR rtl-optimization/106594,
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601501.html
suggested that I submit the x86 backend bits, independently and first.

The executive summary is that the middle-end doesn't have a preferred
canonical form for expressing zero-extension, sometimes using an AND
and sometimes using zero_extend.  Pending changes to RTL simplification
will/may alter some of these representations, so a few additional
patterns are required to recognize these alternate representations
and avoid any testsuite regressions.

As an example, *popcountsi2_zext is currently represented as:
  [(set (match_operand:DI 0 "register_operand" "=r")
(and:DI
  (subreg:DI
(popcount:SI
  (match_operand:SI 1 "nonimmediate_operand" "rm")) 0)
  (const_int 63)))
   (clobber (reg:CC FLAGS_REG))]

this patch adds an alternate/equivalent pattern that matches:
  [(set (match_operand:DI 0 "register_operand" "=r")
   (zero_extend:DI
 (popcount:SI (match_operand:SI 1 "nonimmediate_operand" "rm"
   (clobber (reg:CC FLAGS_REG))]

Another example is *popcounthi2 which is currently represented as:
  [(set (match_operand:SI 0 "register_operand")
(popcount:SI
  (zero_extend:SI (match_operand:HI 1 "nonimmediate_operand"
   (clobber (reg:CC FLAGS_REG))]

this patch adds an alternate/equivalent pattern that matches:
  [(set (match_operand:SI 0 "register_operand")
(zero_extend:SI
  (popcount:HI (match_operand:HI 1 "nonimmediate_operand"
   (clobber (reg:CC FLAGS_REG))]

The contents of the machine description definitions remain the same,
it's just the expected RTL is slightly different but equivalent.
Providing both forms makes the backend more robust to middle-end
changes [and possibly catches some missed optimizations].

This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32},
with no new failures.  Ok for mainline?


2022-12-28  Roger Sayle  

gcc/ChangeLog
* config/i386/i386.md (*clzsi2_lzcnt_zext_2): define_insn_and_split
to match ZERO_EXTEND form of *clzsi2_lzcnt_zext.
(*clzsi2_lzcnt_zext_2_falsedep): Likewise, new define_insn to match
ZERO_EXTEND form of *clzsi2_lzcnt_zext_falsedep.
(*bmi2_bzhi_zero_extendsidi_5): Likewise, new define_insn to match
ZERO_EXTEND form of *bmi2_bzhi_zero_extendsidi.
(*popcountsi2_zext_2): Likewise, new define_insn_and_split to match
ZERO_EXTEND form of *popcountsi2_zext.
(*popcountsi2_zext_2_falsedep): Likewise, new define_insn to match
ZERO_EXTEND form of *popcountsi2_zext_falsedep.
(*popcounthi2_2): Likewise, new define_insn_and_split to match
ZERO_EXTEND form of *popcounthi2.
(define_peephole2): ZERO_EXTEND variant of HImode popcount&1 using
parity flag peephole2.

Thanks in advance,
Roger
--

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 0626752..ca40c4f 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -17419,6 +17419,42 @@
(set_attr "type" "bitmanip")
(set_attr "mode" "SI")])
 
+(define_insn_and_split "*clzsi2_lzcnt_zext_2"
+  [(set (match_operand:DI 0 "register_operand" "=r")
+   (zero_extend:DI
+ (clz:SI (match_operand:SI 1 "nonimmediate_operand" "rm"
+   (clobber (reg:CC FLAGS_REG))]
+  "TARGET_LZCNT && TARGET_64BIT"
+  "lzcnt{l}\t{%1, %k0|%k0, %1}"
+  "&& TARGET_AVOID_FALSE_DEP_FOR_BMI && epilogue_completed
+   && optimize_function_for_speed_p (cfun)
+   && !reg_mentioned_p (operands[0], operands[1])"
+  [(parallel
+[(set (match_dup 0)
+ (zero_extend:DI (clz:SI (match_dup 1
+ (unspec [(match_dup 0)] UNSPEC_INSN_FALSE_DEP)
+ (clobber (reg:CC FLAGS_REG))])]
+  "ix86_expand_clear (operands[0]);"
+  [(set_attr "prefix_rep" "1")
+   (set_attr "type" "bitmanip")
+   (set_attr "mode" "SI")])
+
+; False dependency happens when destination is only updated by tzcnt,
+; lzcnt or popcnt.  There is no false dependency when destination is
+; also used in source.
+(define_insn "*clzsi2_lzcnt_zext_2_falsedep"
+  [(set (match_operand:DI 0 "register_operand" "=r")
+   (zero_extend:DI
+ (clz:SI (match_operand:SWI48 1 "nonimmediate_operand" "rm"
+   (unspec [(match_operand:DI 2 "register_operand" "0")]
+  UNSPEC_INSN_FALSE_DEP)
+   (clobber (reg:CC FLAGS_REG))]
+  "TARGET_LZCNT"
+  "lzcnt{l}\t{%1, %k0|%k0, %1}"
+  [(set_attr "prefix_rep" "1")
+   (set_attr "type" "bitmanip")
+   (set_attr "mode" "SI")])
+
 (define_int_iterator LT_ZCNT
[(UNSPEC_TZCNT "TARGET_BMI")
 (UNSPEC_LZCNT "TARGET_LZCNT")])
@@ -17737,6 +17773,22 @@
(set_attr "prefix" "vex")
(set_attr "mode" "DI")])
 
+(define_insn "*bmi2_bzhi_zero_extendsidi_5"
+  [(set (match_operand:DI 0 "register_operand" "=r")
+   (and:DI
+ (zero_extend:DI
+  

Re: [x86 PATCH] Provide zero_extend versions/variants of several patterns.

[Jeff Law via Gcc-patches]

On 12/27/22 18:15, Roger Sayle wrote:


Back in September, the review of my patch for PR rtl-optimization/106594,
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601501.html
suggested that I submit the x86 backend bits, independently and first.

The executive summary is that the middle-end doesn't have a preferred
canonical form for expressing zero-extension, sometimes using an AND
and sometimes using zero_extend.  Pending changes to RTL simplification
will/may alter some of these representations, so a few additional
patterns are required to recognize these alternate representations
and avoid any testsuite regressions.
Oh and internally other forms can show up.  Like paired shifts.  In 
fact, I think paired shifts are canonical inside at least some parts of 
combine.


jeff

Re: [PATCH] RISC-V: Fix ICE of visiting non-existing block in CFG.

[Kito Cheng via Gcc-patches]

oops, I just committed this yesterday, anyway, I think we can always
have further patches to improve that.

On Wed, Dec 28, 2022 at 9:12 AM Jeff Law via Gcc-patches
 wrote:
>
>
>
> On 12/27/22 17:24, 钟居哲 wrote:
> > OK, I will change that after I finished my current work.
> Sounds good.  Thanks.
>
> Jeff

Re: [PATCH] RISC-V: Return const ref. for vl_vtype_info: get_avl_info

[Kito Cheng]

committed, thanks :)

On Wed, Dec 28, 2022 at 7:05 AM juzhe.zhong  wrote:

> LGTM.
>  Replied Message 
> From Kito Cheng 
> Date 12/27/2022 23:21
> To gcc-patches@gcc.gnu.org
> ,
> kito.ch...@gmail.com ,
> jim.wilson@gmail.com
> ,
> pal...@dabbelt.com ,
> and...@sifive.com ,
> juzhe.zh...@rivai.ai ,
> jeffreya...@gmail.com 
> Cc Kito Cheng 
> Subject [PATCH] RISC-V: Return const ref. for vl_vtype_info::get_avl_info
>

Re: [RFC]RISC-V: Support RV64-ILP32

[Kito Cheng via Gcc-patches]

I would suggest you could send all necessary parts like binutils,
glibc and/or qemu together future, so that we could easier test that?


On Wed, Dec 28, 2022 at 2:25 AM Palmer Dabbelt  wrote:
>
> On Tue, 27 Dec 2022 10:24:10 PST (-0800), gcc-patches@gcc.gnu.org wrote:
> >
> >
> > On 12/12/22 23:49, shi...@iscas.ac.cn wrote:
> >> From: Liao Shihua 
> >>
> >>This patch support rv64 insn in ilp32 ABI. It was inspired by 
> >> aarch64 both
> >> support 64-bit and 32-bit ABI with the same set of instructions.
> >>
> >>
> >> gcc/ChangeLog:
> >>
> >>  * config.gcc:  Implememt ilp32* with rv64*.
> >>  * config/riscv/riscv.cc (riscv_option_override): Remove the 
> >> constraint between RV64 and ILP32.
> >>  * config/riscv/riscv.h (TARGET_ILP32): Define TARGET_ILP32 with 
> >> riscv_abi.
> >>  (POINTER_SIZE):POINTER_SIZE will change with TARGET_ILP32.
> >>  (Pmode):Likewise.
> >>  * config/riscv/riscv.md: Convert split mode with Pmode and change 
> >> mode form Xmode to Pmode in stack_tie.
> > This is a new feature and thus I think we should defer to gcc-14 unless
> > there is a compelling need.
>
> I agree.  This is a pretty big one with a lot of ABI-related
> complications, so let's just play it safe.

[RFC v2] Support RV64-ILP32

[shihua]

From: Liao Shihua 

patch v1

1. use ABI_LEN_SPEC instead of ABI_LEN_SPEC


  This patch support rv64 insn in ilp32 ABI. It was inspired by aarch64 
both 
   support 64-bit and 32-bit ABI with the same set of instructions.

gcc/ChangeLog:

* config.gcc: Implememt ilp32* with rv64*.
* config/riscv/elf.h (LINK_SPEC): use ABI_LEN_SPEC instead of XLEN_SPEC
* config/riscv/freebsd.h (LINK_SPEC): Likewise
(STARTFILE_PREFIX_SPEC): Likewise
* config/riscv/linux.h (GLIBC_DYNAMIC_LINKER): Likewise
(MUSL_DYNAMIC_LINKER): Likewise
(LINK_SPEC): Likewise
(STARTFILE_PREFIX_SPEC): Likewise
* config/riscv/riscv.cc (riscv_option_override): Remove the constraint 
between RV64 and ILP32.
* config/riscv/riscv.h (TARGET_ILP32): Define TARGET_ILP32 with 
riscv_abi.
(POINTER_SIZE): POINTER_SIZE will change with TARGET_ILP32.
(Pmode): Likewise.
(XLEN_SPEC): Remove
(ABI_LEN_SPEC): Define ABI_LEN_SPEC with -mabi option .
* config/riscv/riscv.md: Convert split mode with Pmode and change mode 
form Xmode to Pmode in stack_tie.
---
 gcc/config.gcc |  3 +++
 gcc/config/riscv/elf.h |  2 +-
 gcc/config/riscv/freebsd.h |  6 +++---
 gcc/config/riscv/linux.h   | 10 +-
 gcc/config/riscv/riscv.cc  |  4 
 gcc/config/riscv/riscv.h   | 14 +-
 gcc/config/riscv/riscv.md  |  8 ++--
 7 files changed, 27 insertions(+), 20 deletions(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index c5064dd3766..069293a6e19 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4748,6 +4748,9 @@ case "${target}" in
ilp32,rv32* | ilp32e,rv32e* \
| ilp32f,rv32*f* | ilp32f,rv32g* \
| ilp32d,rv32*d* | ilp32d,rv32g* \
+   | ilp32f,rv64*f* | ilp32f,rv64g* \
+   | ilp32d,rv64*d* | ilp32d,rv64g* \
+   | ilp32,rv64* \
| lp64,rv64* \
| lp64f,rv64*f* | lp64f,rv64g* \
| lp64d,rv64*d* | lp64d,rv64g*)
diff --git a/gcc/config/riscv/elf.h b/gcc/config/riscv/elf.h
index f0e865d6ef4..efc79f3147b 100644
--- a/gcc/config/riscv/elf.h
+++ b/gcc/config/riscv/elf.h
@@ -18,7 +18,7 @@ along with GCC; see the file COPYING3.  If not see
 .  */
 
 #define LINK_SPEC "\
--melf" XLEN_SPEC DEFAULT_ENDIAN_SPEC "riscv \
+-melf" ABI_LEN_SPEC DEFAULT_ENDIAN_SPEC "riscv \
 %{mno-relax:--no-relax} \
 %{mbig-endian:-EB} \
 %{mlittle-endian:-EL} \
diff --git a/gcc/config/riscv/freebsd.h b/gcc/config/riscv/freebsd.h
index 5e5cbe03166..8d72611db7b 100644
--- a/gcc/config/riscv/freebsd.h
+++ b/gcc/config/riscv/freebsd.h
@@ -40,7 +40,7 @@ along with GCC; see the file COPYING3.  If not see
 
 #undef LINK_SPEC
 #define LINK_SPEC "\
-  -melf" XLEN_SPEC DEFAULT_ENDIAN_SPEC "riscv  \
+  -melf" ABI_LEN_SPEC DEFAULT_ENDIAN_SPEC "riscv   \
   %{p:%nconsider using `-pg' instead of `-p' with gprof (1)}   \
   %{v:-V}  \
   %{assert*} %{R*} %{rpath*} %{defsym*}\
@@ -56,7 +56,7 @@ along with GCC; see the file COPYING3.  If not see
 %{static:-static}}"
 
 #define STARTFILE_PREFIX_SPEC  \
-   "/lib" XLEN_SPEC "/" ABI_SPEC "/ "  \
-   "/usr/lib" XLEN_SPEC "/" ABI_SPEC "/ "  \
+   "/lib" ABI_LEN_SPEC "/" ABI_SPEC "/ "   \
+   "/usr/lib" ABI_LEN_SPEC "/" ABI_SPEC "/ "   \
"/lib/ "\
"/usr/lib/ "
diff --git a/gcc/config/riscv/linux.h b/gcc/config/riscv/linux.h
index 38803723ba9..0953809976a 100644
--- a/gcc/config/riscv/linux.h
+++ b/gcc/config/riscv/linux.h
@@ -22,7 +22,7 @@ along with GCC; see the file COPYING3.  If not see
 GNU_USER_TARGET_OS_CPP_BUILTINS(); \
   } while (0)
 
-#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-riscv" XLEN_SPEC "-" ABI_SPEC 
".so.1"
+#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-riscv" ABI_LEN_SPEC "-" ABI_SPEC 
".so.1"
 
 #define MUSL_ABI_SUFFIX \
   "%{mabi=ilp32:-sf}" \
@@ -33,7 +33,7 @@ along with GCC; see the file COPYING3.  If not see
   "%{mabi=lp64d:}"
 
 #undef MUSL_DYNAMIC_LINKER
-#define MUSL_DYNAMIC_LINKER "/lib/ld-musl-riscv" XLEN_SPEC MUSL_ABI_SUFFIX 
".so.1"
+#define MUSL_DYNAMIC_LINKER "/lib/ld-musl-riscv" ABI_LEN_SPEC MUSL_ABI_SUFFIX 
".so.1"
 
 /* Because RISC-V only has word-sized atomics, it requries libatomic where
others do not.  So link libatomic by default, as needed.  */
@@ -58,7 +58,7 @@ along with GCC; see the file COPYING3.  If not see
   "%{mabi=ilp32:_ilp32}"
 
 #define LINK_SPEC "\
--melf" XLEN_SPEC DEFAULT_ENDIAN_SPEC "riscv" LD_EMUL_SUFFIX " \
+-melf" ABI_LEN_SPEC DEFAULT_ENDIAN_SPEC "riscv" LD_EMUL_SUFFIX " \
 %{mno-relax:--no-relax} \
 %{mbig-endian:-EB} \
 %{mlittle-endian:-EL} \
@@ -72,7 +72,7

Re: [05/13] ssa-loop-niter: skip caching of null operands

[Alexandre Oliva via Gcc-patches]

Hello, Jeff,

On Dec 27, 2022, Jeff Law  wrote:

>> * tree-ssa-loop-niter.cc (expand_simple_operands): Refrain
>> from caching NULL TREE_OPERANDs.

> I must admit some curiosity about the NULL operand though.  Do you
> recall what kind of node had a NULL operand and whether or not that
> was a valid state or not?

I'm pretty sure the case I hit was a CALL_EXPR.


Thanks for the reviews!

Happy GNU Year!

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [RFC]RISC-V: Support RV64-ILP32

[Liao Shihua]

I had send gcc and binutils patch to mainlist . But I only support them 
in newlib , not in glibc and qemu. As I know, qemu not support this now.


在 2022/12/28 9:40, Kito Cheng 写道:

I would suggest you could send all necessary parts like binutils,
glibc and/or qemu together future, so that we could easier test that?


On Wed, Dec 28, 2022 at 2:25 AM Palmer Dabbelt  wrote:

On Tue, 27 Dec 2022 10:24:10 PST (-0800), gcc-patches@gcc.gnu.org wrote:


On 12/12/22 23:49, shi...@iscas.ac.cn wrote:

From: Liao Shihua 

This patch support rv64 insn in ilp32 ABI. It was inspired by aarch64 
both
 support 64-bit and 32-bit ABI with the same set of instructions.


gcc/ChangeLog:

  * config.gcc:  Implememt ilp32* with rv64*.
  * config/riscv/riscv.cc (riscv_option_override): Remove the 
constraint between RV64 and ILP32.
  * config/riscv/riscv.h (TARGET_ILP32): Define TARGET_ILP32 with 
riscv_abi.
  (POINTER_SIZE):POINTER_SIZE will change with TARGET_ILP32.
  (Pmode):Likewise.
  * config/riscv/riscv.md: Convert split mode with Pmode and change 
mode form Xmode to Pmode in stack_tie.

This is a new feature and thus I think we should defer to gcc-14 unless
there is a compelling need.

I agree.  This is a pretty big one with a lot of ABI-related
complications, so let's just play it safe.

[PATCH] RISC-V: Fix pointer tree type for store pointer.

[juzhe . zhong]

From: Ju-Zhe Zhong 

For store intrinsic, 
the function type should be void store (T *...) instead of void store (const T 
*...)

gcc/ChangeLog:

* config/riscv/riscv-vector-builtins.cc: Change to scalar pointer.

---
 gcc/config/riscv/riscv-vector-builtins.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/riscv/riscv-vector-builtins.cc 
b/gcc/config/riscv/riscv-vector-builtins.cc
index 9170776f979..e39bfea9636 100644
--- a/gcc/config/riscv/riscv-vector-builtins.cc
+++ b/gcc/config/riscv/riscv-vector-builtins.cc
@@ -158,7 +158,7 @@ static CONSTEXPR const rvv_arg_type_info 
scalar_const_ptr_args[]
 
 /* A list of args for void func (scalar_type *, vector_type) function.  */
 static CONSTEXPR const rvv_arg_type_info scalar_ptr_args[]
-  = {rvv_arg_type_info (RVV_BASE_scalar_const_ptr),
+  = {rvv_arg_type_info (RVV_BASE_scalar_ptr),
  rvv_arg_type_info (RVV_BASE_vector), rvv_arg_type_info_end};
 
 /* A list of none preds that will be registered for intrinsic functions.  */
-- 
2.36.3

[PATCH] RISC-V: Change form of iterating blocks

[juzhe . zhong]

From: Ju-Zhe Zhong 

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc 
(pass_vsetvl::compute_global_backward_infos): Change iterator form.
(pass_vsetvl::prune_expressions): Change iterator form.

---
 gcc/config/riscv/riscv-vsetvl.cc | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/gcc/config/riscv/riscv-vsetvl.cc b/gcc/config/riscv/riscv-vsetvl.cc
index 0d66765e09c..ce1e9e3609f 100644
--- a/gcc/config/riscv/riscv-vsetvl.cc
+++ b/gcc/config/riscv/riscv-vsetvl.cc
@@ -1962,10 +1962,11 @@ pass_vsetvl::compute_global_backward_infos (void)
   if (dump_file)
 {
   fprintf (dump_file, "\n\nDirty blocks list: ");
-  for (const bb_info *bb : crtl->ssa->bbs ())
-   if (m_vector_manager->vector_block_infos[bb->index ()]
+  basic_block cfg_bb;
+  FOR_EACH_BB_FN (cfg_bb, cfun)
+   if (m_vector_manager->vector_block_infos[cfg_bb->index]
  .reaching_out.dirty_p ())
- fprintf (dump_file, "%d ", bb->index ());
+ fprintf (dump_file, "%d ", cfg_bb->index);
   fprintf (dump_file, "\n\n");
 }
 }
@@ -1974,16 +1975,17 @@ pass_vsetvl::compute_global_backward_infos (void)
 void
 pass_vsetvl::prune_expressions (void)
 {
-  for (const bb_info *bb : crtl->ssa->bbs ())
+  basic_block cfg_bb;
+  FOR_EACH_BB_FN (cfg_bb, cfun)
 {
-  if (m_vector_manager->vector_block_infos[bb->index ()]
+  if (m_vector_manager->vector_block_infos[cfg_bb->index]
.local_dem.valid_or_dirty_p ())
m_vector_manager->create_expr (
- m_vector_manager->vector_block_infos[bb->index ()].local_dem);
-  if (m_vector_manager->vector_block_infos[bb->index ()]
+ m_vector_manager->vector_block_infos[cfg_bb->index].local_dem);
+  if (m_vector_manager->vector_block_infos[cfg_bb->index]
.reaching_out.valid_or_dirty_p ())
m_vector_manager->create_expr (
- m_vector_manager->vector_block_infos[bb->index ()].reaching_out);
+ m_vector_manager->vector_block_infos[cfg_bb->index].reaching_out);
 }
 
   if (dump_file)
-- 
2.36.3

Re: Re: [PATCH] RISC-V: Fix ICE of visiting non-existing block in CFG.

[钟居哲]

Hi, I fixed that form like you said:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609217.html 




juzhe.zh...@rivai.ai
 
From: Jeff Law
Date: 2022-12-28 09:11
To: 钟居哲
CC: gcc-patches; kito.cheng; palmer
Subject: Re: [PATCH] RISC-V: Fix ICE of visiting non-existing block in CFG.
 
 
On 12/27/22 17:24, 钟居哲 wrote:
> OK, I will change that after I finished my current work.
Sounds good.  Thanks.
 
Jeff