Re: [PATCH] Fortran: fix issues with class(*) assignment [PR114827]

[Paul Richard Thomas]

Hi Harald,

This patch is verging on 'obvious', . once one sees it :-)

Yes, it's good for mainline and all active branches, when available.

Thanks

Paul

PS The fall-out pr114874 is so peculiar that I am dropping everything to
find the source.


On Mon, 29 Apr 2024 at 19:39, Harald Anlauf  wrote:

> Dear all,
>
> the attached patch fixes issues with assignments of unlimited polymorphic
> entities that were found with the help of valgrind or asan, see PR.
> Looking
> further into it, it turns out that allocation sizes as well as array spans
> could be set incorrectly, leading to wrong results or heap corruption.
>
> The fix is rather straightforward: take into the _len of unlimited
> polymorphic entities when it is non-zero to get the correct allocation
> sizes and array spans.
>
> The patch has been tested by the reporter, see PR.
>
> Regtested on x86_64-pc-linux-gnu.  OK for 15-mainline?
>
> I would like to backport this to active branches where appropriate,
> starting with 14 after it reopens after release.  Is this OK?
>
> Thanks,
> Harald
>
>

[PATCH] fixincludes: add AC_CONFIG_MACRO_DIRS to configure.ac

[Simon Marchi]

Add an "AC_CONFIG_MACRO_DIRS" call in configure.ac, with the same
directories as specified in "ACLOCAL_AMFLAGS", in Makefile.in.

This makes it possible to re-generate aclocal.m4 using "autoreconf".
---
 fixincludes/configure| 1 +
 fixincludes/configure.ac | 1 +
 2 files changed, 2 insertions(+)

diff --git a/fixincludes/configure b/fixincludes/configure
index 662c94dc1120..7147c9a618aa 100755
--- a/fixincludes/configure
+++ b/fixincludes/configure
@@ -4627,6 +4627,7 @@ $as_echo "$ac_cv_path_SED" >&6; }
   rm -f conftest.sed
 
 
+
 # Figure out what compiler warnings we can enable.
 # See config/warnings.m4 for details.
 
diff --git a/fixincludes/configure.ac b/fixincludes/configure.ac
index 4e78511d20fc..3d177699ebfa 100644
--- a/fixincludes/configure.ac
+++ b/fixincludes/configure.ac
@@ -7,6 +7,7 @@ AC_CANONICAL_SYSTEM
 AC_PROG_CC
 AC_USE_SYSTEM_EXTENSIONS
 AC_PROG_SED
+AC_CONFIG_MACRO_DIRS([.. ../config])
 
 # Figure out what compiler warnings we can enable.
 # See config/warnings.m4 for details.

base-commit: 22b20ac6c6aead2d3f36c413a77dd0b80adfec39
-- 
2.44.0

[PATCH] libgm2: re-generate with autoreconf

[Simon Marchi]

I get a diff when running "autoreconf" in this directory.  I think that
the current state is erroneous: it appears to have been generated using

aclocal -I ../config -I ..

even though configure.ac and Makefile.am list the include flag in the
reverse order:

   aclocal -I .. -I ../config

Running "autoreconf" uses the latter order, so I think that's the
"right" output.

No functional difference expected.
---
 libgm2/Makefile.in  | 10 +-
 libgm2/aclocal.m4   | 10 +-
 libgm2/libm2cor/Makefile.in | 10 +-
 libgm2/libm2iso/Makefile.in | 10 +-
 libgm2/libm2log/Makefile.in | 10 +-
 libgm2/libm2min/Makefile.in | 10 +-
 libgm2/libm2pim/Makefile.in | 10 +-
 7 files changed, 35 insertions(+), 35 deletions(-)

diff --git a/libgm2/Makefile.in b/libgm2/Makefile.in
index f259df7842cf..9cd79824a53d 100644
--- a/libgm2/Makefile.in
+++ b/libgm2/Makefile.in
@@ -90,15 +90,15 @@ host_triplet = @host@
 target_triplet = @target@
 subdir = .
 ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
-am__aclocal_m4_deps = $(top_srcdir)/../libtool.m4 \
-   $(top_srcdir)/../ltoptions.m4 $(top_srcdir)/../ltsugar.m4 \
-   $(top_srcdir)/../ltversion.m4 $(top_srcdir)/../lt~obsolete.m4 \
-   $(top_srcdir)/../config/acx.m4 \
+am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \
$(top_srcdir)/../config/depstand.m4 \
$(top_srcdir)/../config/lead-dot.m4 \
$(top_srcdir)/../config/multi.m4 \
$(top_srcdir)/../config/no-executables.m4 \
-   $(top_srcdir)/../config/override.m4 $(top_srcdir)/acinclude.m4 \
+   $(top_srcdir)/../config/override.m4 \
+   $(top_srcdir)/../libtool.m4 $(top_srcdir)/../ltoptions.m4 \
+   $(top_srcdir)/../ltsugar.m4 $(top_srcdir)/../ltversion.m4 \
+   $(top_srcdir)/../lt~obsolete.m4 $(top_srcdir)/acinclude.m4 \
$(top_srcdir)/../config/gc++filt.m4 \
$(top_srcdir)/../config/tls.m4 $(top_srcdir)/../config/gthr.m4 \
$(top_srcdir)/../config/cet.m4 $(top_srcdir)/configure.ac
diff --git a/libgm2/aclocal.m4 b/libgm2/aclocal.m4
index bee67b05dee2..19cfb0d1eb26 100644
--- a/libgm2/aclocal.m4
+++ b/libgm2/aclocal.m4
@@ -1187,15 +1187,15 @@ AC_SUBST([am__tar])
 AC_SUBST([am__untar])
 ]) # _AM_PROG_TAR
 
-m4_include([../libtool.m4])
-m4_include([../ltoptions.m4])
-m4_include([../ltsugar.m4])
-m4_include([../ltversion.m4])
-m4_include([../lt~obsolete.m4])
 m4_include([../config/acx.m4])
 m4_include([../config/depstand.m4])
 m4_include([../config/lead-dot.m4])
 m4_include([../config/multi.m4])
 m4_include([../config/no-executables.m4])
 m4_include([../config/override.m4])
+m4_include([../libtool.m4])
+m4_include([../ltoptions.m4])
+m4_include([../ltsugar.m4])
+m4_include([../ltversion.m4])
+m4_include([../lt~obsolete.m4])
 m4_include([acinclude.m4])
diff --git a/libgm2/libm2cor/Makefile.in b/libgm2/libm2cor/Makefile.in
index 63299388dd8f..f9952cff71a7 100644
--- a/libgm2/libm2cor/Makefile.in
+++ b/libgm2/libm2cor/Makefile.in
@@ -108,15 +108,15 @@ target_triplet = @target@
 @BUILD_CORLIB_TRUE@@ENABLE_DARWIN_AT_RPATH_TRUE@am__append_1 = 
-nodefaultrpaths -Wl,-rpath,@loader_path/
 subdir = libm2cor
 ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
-am__aclocal_m4_deps = $(top_srcdir)/../libtool.m4 \
-   $(top_srcdir)/../ltoptions.m4 $(top_srcdir)/../ltsugar.m4 \
-   $(top_srcdir)/../ltversion.m4 $(top_srcdir)/../lt~obsolete.m4 \
-   $(top_srcdir)/../config/acx.m4 \
+am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \
$(top_srcdir)/../config/depstand.m4 \
$(top_srcdir)/../config/lead-dot.m4 \
$(top_srcdir)/../config/multi.m4 \
$(top_srcdir)/../config/no-executables.m4 \
-   $(top_srcdir)/../config/override.m4 $(top_srcdir)/acinclude.m4 \
+   $(top_srcdir)/../config/override.m4 \
+   $(top_srcdir)/../libtool.m4 $(top_srcdir)/../ltoptions.m4 \
+   $(top_srcdir)/../ltsugar.m4 $(top_srcdir)/../ltversion.m4 \
+   $(top_srcdir)/../lt~obsolete.m4 $(top_srcdir)/acinclude.m4 \
$(top_srcdir)/../config/gc++filt.m4 \
$(top_srcdir)/../config/tls.m4 $(top_srcdir)/../config/gthr.m4 \
$(top_srcdir)/../config/cet.m4 $(top_srcdir)/configure.ac
diff --git a/libgm2/libm2iso/Makefile.in b/libgm2/libm2iso/Makefile.in
index 964c6da85270..370837f15b82 100644
--- a/libgm2/libm2iso/Makefile.in
+++ b/libgm2/libm2iso/Makefile.in
@@ -108,15 +108,15 @@ target_triplet = @target@
 @BUILD_ISOLIB_TRUE@@ENABLE_DARWIN_AT_RPATH_TRUE@am__append_1 = 
-nodefaultrpaths -Wl,-rpath,@loader_path/
 subdir = libm2iso
 ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
-am__aclocal_m4_deps = $(top_srcdir)/../libtool.m4 \
-   $(top_srcdir)/../ltoptions.m4 $(top_srcdir)/../ltsugar.m4 \
-   $(top_srcdir)/../ltversion.m4 $(top_srcdir)/../lt~obsolete.m4 \
-   $(top_srcdir)/../config/acx.m4 \
+am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \
$(top_srcdir)/../config/depstand.m4 \
$(top_srcdir)/../config/lead-dot.m4 \

Re: [pushed][PATCH][gcc-13] LoongArch: Fix eh_return epilogue for normal returns.

[Lulu Cheng]

Pushed to r13-8661.

在 2024/4/29 下午4:09, Lulu Cheng 写道:

From: Yang Yujie 

On LoongArch, the regitsters $r4 - $r7 (EH_RETURN_DATA_REGNO) will be saved
and restored in the function prologue and epilogue if the given function calls
__builtin_eh_return.  This causes the return value to be overwritten on normal
return paths and breaks a rare case of libgcc's _Unwind_RaiseException.

gcc/ChangeLog:

PR target/114848
* config/loongarch/loongarch.cc: Do not restore the saved eh_return
data registers ($r4-$r7) for a normal return of a function that calls
__builtin_eh_return elsewhere.
* config/loongarch/loongarch-protos.h: Same.
* config/loongarch/loongarch.md: Same.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/eh_return-normal-return.c: New test.

(cherry picked from commit 4b421728289e6f1caa0dfaa953a11698ab95d37d)
---
  gcc/config/loongarch/loongarch-protos.h   |  2 +-
  gcc/config/loongarch/loongarch.cc | 35 -
  gcc/config/loongarch/loongarch.md | 23 ++-
  .../loongarch/eh_return-normal-return.c   | 38 +++
  4 files changed, 85 insertions(+), 13 deletions(-)
  create mode 100644 
gcc/testsuite/gcc.target/loongarch/eh_return-normal-return.c

diff --git a/gcc/config/loongarch/loongarch-protos.h 
b/gcc/config/loongarch/loongarch-protos.h
index 35cc77c7367..0f608ee5179 100644
--- a/gcc/config/loongarch/loongarch-protos.h
+++ b/gcc/config/loongarch/loongarch-protos.h
@@ -60,7 +60,7 @@ enum loongarch_symbol_type {
  extern rtx loongarch_emit_move (rtx, rtx);
  extern HOST_WIDE_INT loongarch_initial_elimination_offset (int, int);
  extern void loongarch_expand_prologue (void);
-extern void loongarch_expand_epilogue (bool);
+extern void loongarch_expand_epilogue (int);
  extern bool loongarch_can_use_return_insn (void);
  
  extern bool loongarch_symbolic_constant_p (rtx, enum loongarch_symbol_type *);
diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc
index f47a5fc2ad7..2238858cd6a 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -1012,7 +1012,8 @@ loongarch_save_restore_reg (machine_mode mode, int regno, 
HOST_WIDE_INT offset,
  
  static void

  loongarch_for_each_saved_reg (HOST_WIDE_INT sp_offset,
- loongarch_save_restore_fn fn)
+ loongarch_save_restore_fn fn,
+ bool skip_eh_data_regs_p)
  {
HOST_WIDE_INT offset;
  
@@ -1021,7 +1022,15 @@ loongarch_for_each_saved_reg (HOST_WIDE_INT sp_offset,

for (int regno = GP_REG_FIRST; regno <= GP_REG_LAST; regno++)
  if (BITSET_P (cfun->machine->frame.mask, regno - GP_REG_FIRST))
{
-   loongarch_save_restore_reg (word_mode, regno, offset, fn);
+   /* Special care needs to be taken for $r4-$r7 (EH_RETURN_DATA_REGNO)
+  when returning normally from a function that calls
+  __builtin_eh_return.  In this case, these registers are saved but
+  should not be restored, or the return value may be clobbered.  */
+
+   if (!(skip_eh_data_regs_p
+ && GP_ARG_FIRST <= regno && regno < GP_ARG_FIRST + 4))
+ loongarch_save_restore_reg (word_mode, regno, offset, fn);
+
offset -= UNITS_PER_WORD;
}
  
@@ -1290,7 +1299,7 @@ loongarch_expand_prologue (void)

GEN_INT (-step1));
RTX_FRAME_RELATED_P (emit_insn (insn)) = 1;
size -= step1;
-  loongarch_for_each_saved_reg (size, loongarch_save_reg);
+  loongarch_for_each_saved_reg (size, loongarch_save_reg, false);
  }
  
/* Set up the frame pointer, if we're using one.  */

@@ -1375,11 +1384,13 @@ loongarch_can_use_return_insn (void)
return reload_completed && cfun->machine->frame.total_size == 0;
  }
  
-/* Expand an "epilogue" or "sibcall_epilogue" pattern; SIBCALL_P

-   says which.  */
+/* Expand function epilogue using the following insn patterns:
+   "epilogue"  (style == NORMAL_RETURN)
+   "sibcall_epilogue" (style == SIBCALL_RETURN)
+   "eh_return" (style == EXCEPTION_RETURN) */
  
  void

-loongarch_expand_epilogue (bool sibcall_p)
+loongarch_expand_epilogue (int style)
  {
/* Split the frame into two.  STEP1 is the amount of stack we should
   deallocate before restoring the registers.  STEP2 is the amount we
@@ -1396,7 +1407,8 @@ loongarch_expand_epilogue (bool sibcall_p)
bool need_barrier_p
  = (get_frame_size () + cfun->machine->frame.arg_pointer_offset) != 0;
  
-  if (!sibcall_p && loongarch_can_use_return_insn ())

+  /* Handle simple returns.  */
+  if (style == NORMAL_RETURN && loongarch_can_use_return_insn ())
  {
emit_jump_insn (gen_return ());
return;
@@ -1472,7 +1484,9 @@ loongarch_expand_epilogue (bool sibcall_p)
  
/* Restore the registers.  */

loongarch_for_each_saved_reg (frame->total_size - step2,
-

Re: [pushed][PATCH][gcc-12] LoongArch: Fix eh_return epilogue for normal returns.

[Lulu Cheng]

Pushed to r12-10403.

在 2024/4/29 下午4:09, Lulu Cheng 写道:

From: Yang Yujie 

On LoongArch, the regitsters $r4 - $r7 (EH_RETURN_DATA_REGNO) will be saved
and restored in the function prologue and epilogue if the given function calls
__builtin_eh_return.  This causes the return value to be overwritten on normal
return paths and breaks a rare case of libgcc's _Unwind_RaiseException.

gcc/ChangeLog:

PR target/114848
* config/loongarch/loongarch.cc: Do not restore the saved eh_return
data registers ($r4-$r7) for a normal return of a function that calls
__builtin_eh_return elsewhere.
* config/loongarch/loongarch-protos.h: Same.
* config/loongarch/loongarch.md: Same.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/eh_return-normal-return.c: New test.

(cherry picked from commit 4b421728289e6f1caa0dfaa953a11698ab95d37d)
---
  gcc/config/loongarch/loongarch-protos.h   |  2 +-
  gcc/config/loongarch/loongarch.cc | 35 -
  gcc/config/loongarch/loongarch.md | 23 ++-
  .../loongarch/eh_return-normal-return.c   | 38 +++
  4 files changed, 85 insertions(+), 13 deletions(-)
  create mode 100644 
gcc/testsuite/gcc.target/loongarch/eh_return-normal-return.c

diff --git a/gcc/config/loongarch/loongarch-protos.h 
b/gcc/config/loongarch/loongarch-protos.h
index 2144c2421ed..8af82ffaa20 100644
--- a/gcc/config/loongarch/loongarch-protos.h
+++ b/gcc/config/loongarch/loongarch-protos.h
@@ -47,7 +47,7 @@ enum loongarch_symbol_type {
  extern rtx loongarch_emit_move (rtx, rtx);
  extern HOST_WIDE_INT loongarch_initial_elimination_offset (int, int);
  extern void loongarch_expand_prologue (void);
-extern void loongarch_expand_epilogue (bool);
+extern void loongarch_expand_epilogue (int);
  extern bool loongarch_can_use_return_insn (void);
  
  extern bool loongarch_symbolic_constant_p (rtx, enum loongarch_symbol_type *);
diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc
index 33b1919e7a3..a0e11f2fc66 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -1008,7 +1008,8 @@ loongarch_save_restore_reg (machine_mode mode, int regno, 
HOST_WIDE_INT offset,
  
  static void

  loongarch_for_each_saved_reg (HOST_WIDE_INT sp_offset,
- loongarch_save_restore_fn fn)
+ loongarch_save_restore_fn fn,
+ bool skip_eh_data_regs_p)
  {
HOST_WIDE_INT offset;
  
@@ -1017,7 +1018,15 @@ loongarch_for_each_saved_reg (HOST_WIDE_INT sp_offset,

for (int regno = GP_REG_FIRST; regno <= GP_REG_LAST; regno++)
  if (BITSET_P (cfun->machine->frame.mask, regno - GP_REG_FIRST))
{
-   loongarch_save_restore_reg (word_mode, regno, offset, fn);
+   /* Special care needs to be taken for $r4-$r7 (EH_RETURN_DATA_REGNO)
+  when returning normally from a function that calls
+  __builtin_eh_return.  In this case, these registers are saved but
+  should not be restored, or the return value may be clobbered.  */
+
+   if (!(skip_eh_data_regs_p
+ && GP_ARG_FIRST <= regno && regno < GP_ARG_FIRST + 4))
+ loongarch_save_restore_reg (word_mode, regno, offset, fn);
+
offset -= UNITS_PER_WORD;
}
  
@@ -1289,7 +1298,7 @@ loongarch_expand_prologue (void)

GEN_INT (-step1));
RTX_FRAME_RELATED_P (emit_insn (insn)) = 1;
size -= step1;
-  loongarch_for_each_saved_reg (size, loongarch_save_reg);
+  loongarch_for_each_saved_reg (size, loongarch_save_reg, false);
  }
  
  
@@ -1336,11 +1345,13 @@ loongarch_can_use_return_insn (void)

return reload_completed && cfun->machine->frame.total_size == 0;
  }
  
-/* Expand an "epilogue" or "sibcall_epilogue" pattern; SIBCALL_P

-   says which.  */
+/* Expand function epilogue using the following insn patterns:
+   "epilogue"  (style == NORMAL_RETURN)
+   "sibcall_epilogue" (style == SIBCALL_RETURN)
+   "eh_return" (style == EXCEPTION_RETURN) */
  
  void

-loongarch_expand_epilogue (bool sibcall_p)
+loongarch_expand_epilogue (int style)
  {
/* Split the frame into two.  STEP1 is the amount of stack we should
   deallocate before restoring the registers.  STEP2 is the amount we
@@ -1357,7 +1368,8 @@ loongarch_expand_epilogue (bool sibcall_p)
bool need_barrier_p
  = (get_frame_size () + cfun->machine->frame.arg_pointer_offset) != 0;
  
-  if (!sibcall_p && loongarch_can_use_return_insn ())

+  /* Handle simple returns.  */
+  if (style == NORMAL_RETURN && loongarch_can_use_return_insn ())
  {
emit_jump_insn (gen_return ());
return;
@@ -1433,7 +1445,9 @@ loongarch_expand_epilogue (bool sibcall_p)
  
/* Restore the registers.  */

loongarch_for_each_saved_reg (frame->total_size - step2,
-   loongarch_restore_reg);
+ 

RE: [PATCH v2] DSE: Bugfix ICE after allow vector type in get_stored_val

[Li, Pan2]

> So how about this.  I'll ack this for the trunk, but not for gcc-14 (at 
> this time).  We can revisit for gcc-14 after it's been on the trunk a 
> bit.  Realistically that likely means gcc-14.2 at the end of the summer 
> rather than gcc-14.1 which is due in roughly a week.

Thanks Jeff, I will prepare a v3 for this with full and well tested results.

Pan

-Original Message-
From: Jeff Law  
Sent: Monday, April 29, 2024 11:20 PM
To: Li, Pan2 ; Robin Dapp ; 
gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; richard.guent...@gmail.com; 
Wang, Yanzhang ; Liu, Hongtao 
Subject: Re: [PATCH v2] DSE: Bugfix ICE after allow vector type in 
get_stored_val



On 3/22/24 11:45 PM, Li, Pan2 wrote:
> Thanks Jeff for comments.
> 
>> As Richi noted using validate_subreg here isn't great.  Does it work to
>> factor out this code from extract_low_bits
>>
>>>if (!int_mode_for_mode (src_mode).exists (_int_mode)
>>>|| !int_mode_for_mode (mode).exists (_mode))
>>>  return NULL_RTX;
>>>
>>>if (!targetm.modes_tieable_p (src_int_mode, src_mode))
>>>  return NULL_RTX;
>>>if (!targetm.modes_tieable_p (int_mode, mode))
>>>  return NULL_RTX;
> 
>> And use that in the condition (and in extract_low_bits rather than
>> duplicating the code)?
> 
> It can solve the ICE but will forbid all vector modes goes gen_lowpart.
> Actually only the vector mode size is less than reg nature size will trigger 
> the ICE.
> Thus, how about just add one more condition before goes to gen_lowpart as 
> below?
> 
> Feel free to correct me if any misunderstandings. !
> 
> diff --git a/gcc/dse.cc b/gcc/dse.cc
> index edc7a1dfecf..258d2ccc299 100644
> --- a/gcc/dse.cc
> +++ b/gcc/dse.cc
> @@ -1946,7 +1946,9 @@ get_stored_val (store_info *store_info, machine_mode 
> read_mode,
>   copy_rtx (store_info->const_rhs));
> else if (VECTOR_MODE_P (read_mode) && VECTOR_MODE_P (store_mode)
>   && known_le (GET_MODE_BITSIZE (read_mode), GET_MODE_BITSIZE 
> (store_mode))
> -&& targetm.modes_tieable_p (read_mode, store_mode))
> +&& targetm.modes_tieable_p (read_mode, store_mode)
> +/* It's invalid in validate_subreg if read_mode size is < reg natural.  
> */
> +&& known_ge (GET_MODE_SIZE (read_mode), REGMODE_NATURAL_SIZE 
> (read_mode)))
>   read_reg = gen_lowpart (read_mode, copy_rtx (store_info->rhs));
> else
>   read_reg = extract_low_bits (read_mode, store_mode,
So how about this.  I'll ack this for the trunk, but not for gcc-14 (at 
this time).  We can revisit for gcc-14 after it's been on the trunk a 
bit.  Realistically that likely means gcc-14.2 at the end of the summer 
rather than gcc-14.1 which is due in roughly a week.

Jeff

Re: [PATCH] c++: Implement C++26 P0609R3 - Attributes for Structured Bindings [PR114456]

[Jason Merrill]

On 4/29/24 00:11, Jakub Jelinek wrote:

Hi!

The following patch implements the P0609R3 paper; we build the
VAR_DECLs for the structured binding identifiers early, so all we need
IMHO is just to parse the attributed identifier list and pass the attributes
to the VAR_DECL creation.

The paper mentions maybe_unused and gnu::nonstring attributes as examples
where they can be useful.  Not sure about either of them.
For maybe_unused, the thing is that both GCC and clang already don't
diagnose maybe unused for the structured binding identifiers, because it
would be a false positive too often; and there is no easy way to find out
if a structured binding has been written with the P0609R3 paper in mind or
not (maybe we could turn it on if in the structured binding is any
attribute, even if just [[]] and record that as a flag on the whole
underlying decl, so that we'd diagnose
   auto [a, b, c[[]]] = d;
   // use a, c but not b
but not
   auto [e, f, g] = d;
   // use a, c but not b
).  For gnu::nonstring, the issue is that we currently don't allow the
attribute on references to char * or references to char[], just on
char */char[].  I've filed a PR for that.

The first testcase in the patch tests it on [[]] and [[maybe_unused]],
just whether it is parsed properly, second on gnu::deprecated, which
works.  Haven't used deprecated attribute because the paper said that
attribute is for further investigation.

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


OK.


2024-04-29  Jakub Jelinek  

PR c++/114456
gcc/c-family/
* c-cppbuiltin.cc (c_cpp_builtins): Predefine
__cpp_structured_bindings for C++26 to 202403L rather than
201606L.
gcc/cp/
* parser.cc (cp_parser_decomposition_declaration): Implement C++26
P0609R3 - Attributes for Structured Bindings.  Parse attributed
identifier lists for structured binding declarations, pass the
attributes to start_decl.
gcc/testsuite/
* g++.dg/cpp26/decomp1.C: New test.
* g++.dg/cpp26/decomp2.C: New test.
* g++.dg/cpp26/feat-cxx26.C (__cpp_structured_bindings): Expect
202403 rather than 201606.

--- gcc/cp/parser.cc.jj 2024-04-26 11:42:24.653016208 +0200
+++ gcc/cp/parser.cc2024-04-26 13:59:17.791482874 +0200
@@ -16075,13 +16075,37 @@ cp_parser_decomposition_declaration (cp_
  
/* Parse the identifier-list.  */

auto_vec v;
+  bool attr_diagnosed = false;
+  int first_attr = -1;
+  unsigned int cnt = 0;
if (!cp_lexer_next_token_is (parser->lexer, CPP_CLOSE_SQUARE))
  while (true)
{
cp_expr e = cp_parser_identifier (parser);
if (e.get_value () == error_mark_node)
  break;
+   tree attr = NULL_TREE;
+   if (cp_next_tokens_can_be_std_attribute_p (parser))
+ {
+   if (cxx_dialect >= cxx17 && cxx_dialect < cxx26 && !attr_diagnosed)
+ {
+   pedwarn (cp_lexer_peek_token (parser->lexer)->location,
+OPT_Wc__26_extensions,
+"structured bindings with attributed identifiers "
+"only available with %<-std=c++2c%> or "
+"%<-std=gnu++2c%>");
+   attr_diagnosed = true;
+ }
+   attr = cp_parser_std_attribute_spec_seq (parser);
+   if (attr == error_mark_node)
+ attr = NULL_TREE;
+   if (attr && first_attr == -1)
+ first_attr = v.length ();
+ }
v.safe_push (e);
+   ++cnt;
+   if (first_attr != -1)
+ v.safe_push (attr);
if (!cp_lexer_next_token_is (parser->lexer, CPP_COMMA))
  break;
cp_lexer_consume_token (parser->lexer);
@@ -16139,8 +16163,11 @@ cp_parser_decomposition_declaration (cp_
  declarator->id_loc = e.get_location ();
}
tree elt_pushed_scope;
+  tree attr = NULL_TREE;
+  if (first_attr != -1 && i >= (unsigned) first_attr)
+   attr = v[++i].get_value ();
tree decl2 = start_decl (declarator, _specs, SD_DECOMPOSITION,
-  NULL_TREE, NULL_TREE, _pushed_scope);
+  NULL_TREE, attr, _pushed_scope);
if (decl2 == error_mark_node)
decl = error_mark_node;
else if (decl != error_mark_node && DECL_CHAIN (decl2) != prev)
@@ -16183,7 +16210,7 @@ cp_parser_decomposition_declaration (cp_
  
if (decl != error_mark_node)

{
- cp_decomp decomp = { prev, v.length () };
+ cp_decomp decomp = { prev, cnt };
  cp_finish_decl (decl, initializer, non_constant_p, NULL_TREE,
  (is_direct_init ? LOOKUP_NORMAL : LOOKUP_IMPLICIT),
  );
@@ -16193,7 +16220,7 @@ cp_parser_decomposition_declaration (cp_
else if (decl != error_mark_node)
  {
*maybe_range_for_decl = prev;
-  cp_decomp decomp = { prev, v.length () };
+  cp_decomp decomp = { prev, cnt };
/* 

Re: [PATCH] decay vect tests from run to link for pr95401

[Alexandre Oliva]

On Apr 22, 2024, Richard Biener  wrote:

>> Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu.  Also tested with
>> gcc-13 on ppc64-vx7r2 and ppc-vx7r2.  Ok to install?

> That makes sense.  OK

>> for  gcc/testsuite/ChangeLog
>> 
>> * lib/target-supports.exp (check_vect_support_and_set_flags):
>> Decay to link rather than compile.

Alas, linking may fail because of an incompatible libc, as reported by
Linaro with a link to their issue GNU-1206 (I'm not posting the link to
the fully-Javascrippled Jira web page; it shows nothing useful, and I
can't post feedback there) and to
https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m7_hard_eabi-build/10/artifact/artifacts/00-sumfiles/
(where I could get useful information)

I'm reverting the patch, and I'll see about some alternate approach that
can accommodate this scenario after I return from LibrePlanet.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

Re: [PATCH] ppc: testsuite: pr79004 needs -mlong-double-128

[Alexandre Oliva]

On Apr 29, 2024, "Kewen.Lin"  wrote:

> Thanks for catching this and sorry
> that I didn't check it before suggesting it, I think we can aggressively
> drop this effective target instead to avoid any possible confusion.

The 128-bit ones, unfortunately, follow the same pattern but are
probably used.  IMHO we should transition all 3 to an '_ok' suffix, but...

> How about the generic one "longdouble64"?  I did a grep and found it has one
> use, I'd expect it can work here. :)

... since this and longdouble128 exist, maybe we can fix it and leave
them all alone, despite the interface oddity.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[C PATCH] PR c/109618: ICE-after-error from error_mark_node.

[Roger Sayle]

This patch solves another ICE-after-error problem in the C family
front-ends.  Upon a conflicting type redeclaration, the ambiguous
type is poisoned with an error_mark_node to indicate to the middle-end
that the type is suspect, but care has to be taken by the front-end to
avoid passing these malformed trees into the middle-end during error
recovery. In this case, a var_decl with a poisoned type appears within
a sizeof() expression (wrapped in NOP_EXPR) which causes problems.

This revision of the patch tests seen_error() to avoid tree traversal
(STRIP_NOPs) in the most common case that an error hasn't occurred.
Both this version (and an earlier revision that didn't test seen_error)
have survived bootstrap and regression testing on x86_64-pc-linux-gnu.
As a consolation, this code also contains a minor performance improvement,
by avoiding trying to create (and folding away) a CEIL_DIV_EXPR in the
common case that "char" is a single-byte.  The current code relies on
the middle-end's tree folding to recognize that CEIL_DIV_EXPR of
integer_one_node is a no-op, that can be optimized away.

Ok for mainline?


2024-04-30  Roger Sayle  

gcc/c-family/ChangeLog
PR c/109618
* c-common.cc (c_sizeof_or_alignof_type): If seen_error() check
whether value is (a VAR_DECL) of type error_mark_node, or a
NOP_EXPR thereof.  Avoid folding CEIL_DIV_EXPR for the common
case where char_type is a single byte.

gcc/testsuite/ChangeLog
PR c/109618
* gcc.dg/pr109618.c: New test case.


Thanks in advance,
Roger
--

diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
index 6fa8243..be8ff09 100644
--- a/gcc/c-family/c-common.cc
+++ b/gcc/c-family/c-common.cc
@@ -3993,10 +3993,31 @@ c_sizeof_or_alignof_type (location_t loc,
   else
 {
   if (is_sizeof)
-   /* Convert in case a char is more than one unit.  */
-   value = size_binop_loc (loc, CEIL_DIV_EXPR, TYPE_SIZE_UNIT (type),
-   size_int (TYPE_PRECISION (char_type_node)
- / BITS_PER_UNIT));
+   {
+ value = TYPE_SIZE_UNIT (type);
+
+ /* PR 109618: Check for erroneous types, stripping NOPs.  */
+ if (seen_error ())
+   {
+ tree tmp = value;
+ while (CONVERT_EXPR_P (tmp)
+|| TREE_CODE (tmp) == NON_LVALUE_EXPR)
+   {
+ if (TREE_TYPE (tmp) == error_mark_node)
+   return error_mark_node;
+ tmp = TREE_OPERAND (tmp, 0);
+   }
+ if (tmp == error_mark_node
+ || TREE_TYPE (tmp) == error_mark_node)
+   return error_mark_node;
+   }
+
+ /* Convert in case a char is more than one unit.  */
+ if (TYPE_PRECISION (char_type_node) != BITS_PER_UNIT)
+   value = size_binop_loc (loc, CEIL_DIV_EXPR, value,
+   size_int (TYPE_PRECISION (char_type_node)
+ / BITS_PER_UNIT));
+   }
   else if (min_alignof)
value = size_int (min_align_of_type (type));
   else
diff --git a/gcc/testsuite/gcc.dg/pr109618.c b/gcc/testsuite/gcc.dg/pr109618.c
new file mode 100644
index 000..f240907
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr109618.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O0" } */
+int foo()
+{
+  const unsigned int var_1 = 2;
+  
+  char var_5[var_1];
+  
+  int var_1[10];  /* { dg-error "conflicting type" } */
+  
+  return sizeof(var_5);
+}
+

Re: [PATCH v4 2/2] c++: Fix instantiation of imported temploid friends [PR114275]

[Jason Merrill]

On 4/29/24 02:34, Nathaniel Shead wrote:

On Fri, Apr 26, 2024 at 09:16:40PM -0400, Jason Merrill wrote:

On 4/19/24 09:29, Nathaniel Shead wrote:

On Fri, Apr 19, 2024 at 12:14:06PM +1000, Nathaniel Shead wrote:

On Wed, Apr 17, 2024 at 02:02:21PM -0400, Patrick Palka wrote:

On Mon, 15 Apr 2024, Nathaniel Shead wrote:


I'm not a huge fan of always streaming 'imported_temploid_friends' for
all decls, but I don't think it adds much performance cost over adding a
new flag to categorise decls that might be marked as such.


IIUC this value is going to be almost always null which is encoded as a
single 0 byte, which should be fast to stream.  But I wonder how much
larger  gets?  Can we get away with streaming this value
only for TEMPLATE_DECLs?


Yes, it should either just be a 0 byte or an additional backref
somewhere, which will likely also be small. On my system it increases
the size by 0.26%, from 31186800 bytes to 31268672.

But I've just found that this patch has a bug anyway, in that it doesn't
correctly dedup if the friend types are instantiated in two separate
modules that are then both imported.  I'll see what I need to do to fix
this which may influence what we need to stream here.



Here's an updated version of the patch that fixes this. Also changed to
only stream when 'inner' is either TYPE_DECL or FUNCTION_DECL, which
cuts the size of  down a bit to 31246992 (0.19% growth).

Another alternative would be to add another boolean flag at the top of
'decl_value' and branch on that; that would make use of the bitpacking
logic and probably cut down on the size further.  (I haven't measured
this yet though.)

Bootstrapped and regtested (so far just dg.exp and modules.exp) on
x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds?

-- >8 --

This patch fixes a number of issues with the handling of temploid friend
declarations.

The primary issue is that instantiations of friend declarations should
attach the declaration to the same module as the befriending class, by
[module.unit] p7.1 and [temp.friend] p2; this could be a different
module from the current TU, and so needs special handling.


This is only an issue for DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P, right?


It's true for any friend instantiations, including e.g. friend
functions, not just template class friends.



Hmm, CWG2588 should probably touch [module.unit]/7.1 as well as
[basic.link].


The other main issue here is that we can't assume that just because name
lookup didn't find a definition for a hidden template class, it doesn't
mean that it doesn't exist: it could be a non-exported entity that we've
nevertheless streamed in from an imported module.  We need to ensure
that when instantiating friend classes that we return the same TYPE_DECL
that we got from our imports, otherwise we will get later issues with
'duplicate_decls' (rightfully) complaining that they're different.


Tricksy.


This doesn't appear necessary for functions due to the existing name
lookup handling already finding these hidden declarations.

PR c++/105320
PR c++/114275

gcc/cp/ChangeLog:

* cp-tree.h (propagate_defining_module): Declare.
(lookup_imported_hidden_friend): Declare.
* decl.cc (duplicate_decls): Also check if hidden declarations
can be redeclared in this module.
* module.cc (imported_temploid_friends): New map.
(init_modules): Initialize it.
(trees_out::decl_value): Write it; don't consider imported
temploid friends as attached to this module.
(trees_in::decl_value): Read it.
(depset::hash::add_specializations): Don't treat instantiations
of a friend type as a specialisation.
(get_originating_module_decl): Follow the owning decl for an
imported temploid friend.
(propagate_defining_module): New function.
* name-lookup.cc (lookup_imported_hidden_friend): New function.
* pt.cc (tsubst_friend_function): Propagate defining module for
new friend functions.
(tsubst_friend_class): Lookup imported hidden friends. Check
for valid redeclaration. Propagate defining module for new
friend classes.

diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index aa66da4829d..56752cf6872 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -2276,30 +2276,34 @@ duplicate_decls (tree newdecl, tree olddecl, bool 
hiding, bool was_hidden)
 if (modules_p ()
 && TREE_CODE (CP_DECL_CONTEXT (olddecl)) == NAMESPACE_DECL
-  && TREE_CODE (olddecl) != NAMESPACE_DECL
-  && !hiding)
+  && TREE_CODE (olddecl) != NAMESPACE_DECL)
   {
 if (!module_may_redeclare (olddecl, newdecl))
return error_mark_node;
-  tree not_tmpl = STRIP_TEMPLATE (olddecl);
-  if (DECL_LANG_SPECIFIC (not_tmpl)
- && DECL_MODULE_ATTACH_P (not_tmpl)
- /* Typedefs are not entities and so are OK to be redeclared
-as exported: see [module.interface]/p6.  */
- && 

Re: [PATCH] c++/modules: imported spec befriending class tmpl [PR114889]

[Jason Merrill]

On 4/29/24 06:50, Patrick Palka wrote:

Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
14 (I guess after 14.1 is released)?


OK for both.


-- >8 --

We need to look through TEMPLATE_DECL like make_friend_class does when
adding to CLASSTYPE_BEFRIENDING_CLASSES.

Otherwise in the below testcase we won't add _Hashtable to
CLASSTYPE_BEFRIENDING_CLASSES of _Map_base when installing the definition
of the former which leads to access control issues.

PR c++/114889

gcc/cp/ChangeLog:

* module.cc (trees_in::read_class_def): Look through
TEMPLATE_DECL when adding to CLASSTYPE_BEFRIENDING_CLASSES.

gcc/testsuite/ChangeLog:

* g++.dg/modules/friend-8_a.H: New test.
* g++.dg/modules/friend-8_b.C: New test.
---
  gcc/cp/module.cc  |  2 ++
  gcc/testsuite/g++.dg/modules/friend-8_a.H | 23 +++
  gcc/testsuite/g++.dg/modules/friend-8_b.C |  9 +
  3 files changed, 34 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/modules/friend-8_a.H
  create mode 100644 gcc/testsuite/g++.dg/modules/friend-8_b.C

diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 7e654305f0a..3b2ba40c92b 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -12518,6 +12518,8 @@ trees_in::read_class_def (tree defn, tree 
maybe_template)
  for (; friend_classes; friend_classes = TREE_CHAIN (friend_classes))
{
  tree f = TREE_VALUE (friend_classes);
+ if (TREE_CODE (f) == TEMPLATE_DECL)
+   f = TREE_TYPE (f);
  
  	  if (CLASS_TYPE_P (f))

{
diff --git a/gcc/testsuite/g++.dg/modules/friend-8_a.H 
b/gcc/testsuite/g++.dg/modules/friend-8_a.H
new file mode 100644
index 000..b07ea25adfb
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/friend-8_a.H
@@ -0,0 +1,23 @@
+// PR c++/114889
+// { dg-additional-options "-fmodule-header" }
+// { dg-module-cmi {} }
+
+template
+struct _Hashtable;
+
+template
+struct _Map_base {
+  void f() {
+_Hashtable<_Key, _Val> __h;
+__h._M_hash_code(0);
+  }
+};
+
+template
+struct _Hashtable {
+  template friend struct _Map_base;
+protected:
+  void _M_hash_code(int);
+};
+
+inline _Hashtable m;
diff --git a/gcc/testsuite/g++.dg/modules/friend-8_b.C 
b/gcc/testsuite/g++.dg/modules/friend-8_b.C
new file mode 100644
index 000..b04280bc91a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/friend-8_b.C
@@ -0,0 +1,9 @@
+// PR c++/114889
+// { dg-additional-options "-fmodules-ts" }
+
+import "friend-8_a.H";
+
+int main() {
+  _Map_base m;
+  m.f();
+}

Re: [PATCH] c++: ICE with templated sizeof(E1) / sizeof(E2) [PR114888]

[Jason Merrill]

On 4/29/24 07:52, Marek Polacek wrote:

On Mon, Apr 29, 2024 at 10:28:19AM -0400, Patrick Palka wrote:

Lightly tested on x86_64-pc-linux-gnu so far, does this look OK for
trunk/14.1 after bootstrap+regtest finishes?


LGTM.


Yes, OK.


-- >8 --

We're missing a dependence check for the second operand in the
sizeof / sizeof handling.

PR c++/114888

gcc/cp/ChangeLog:

* typeck.cc (cp_build_binary_op) : Add missing
dependence check for the second sizeof operand.

gcc/testsuite/ChangeLog:

* g++.dg/template/sizeof19.C: New test.
---
  gcc/cp/typeck.cc | 1 +
  gcc/testsuite/g++.dg/template/sizeof19.C | 8 
  2 files changed, 9 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/template/sizeof19.C

diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
index e5a52dc2b39..a25f8622651 100644
--- a/gcc/cp/typeck.cc
+++ b/gcc/cp/typeck.cc
@@ -5501,6 +5501,7 @@ cp_build_binary_op (const op_location_t ,
  if (!TYPE_P (type1))
type1 = TREE_TYPE (type1);
  if (type0
+ && type1
  && INDIRECT_TYPE_P (type0)
  && same_type_p (TREE_TYPE (type0), type1))
{
diff --git a/gcc/testsuite/g++.dg/template/sizeof19.C 
b/gcc/testsuite/g++.dg/template/sizeof19.C
new file mode 100644
index 000..a1467995a9b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/sizeof19.C
@@ -0,0 +1,8 @@
+// PR c++/114888
+
+template
+struct A {
+  struct B {} *b;
+  static const int c = sizeof (b) / sizeof (b[0]);
+};
+const int d = A::c;
--
2.45.0.rc1



Marek

Re: [PATCH] libcpp: Adjust __STDC_VERSION__ for C23

[Joseph Myers]

On Thu, 25 Apr 2024, Jakub Jelinek wrote:

> Hi!
> 
> While the C23 standard isn't officially release yet,
> in 2011 we've changed __STDC_VERSION__ value for C11 already
> in the month in which the new __STDC_VERSION__ value has been
> finalized, so we want to change this now or wait
> until we implement all the C23 features?
> 
> Note, seems Clang up to 17 also used 202000L for -std=c2x but
> Clang 18+ uses 202311L as specified in the latest C23 drafts.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?

In the spirit of the principle that these macros indicate intent rather 
than completeness, it's probably reasonable to change now.  The main 
missing feature still to be implemented is #embed, hopefully we can get 
that done for GCC 15.

-- 
Joseph S. Myers
josmy...@redhat.com

libgo patch commited: Dump register on Solaris

[Ian Lance Taylor]

This libgo patch, by Rainer Orth, dumps register values on Solaris on
a crash.  This fixes GC PR 106813.  Bootstrapped and ran Go testsuite
on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
a05efc8bf5ed329ea7d9b1740c326bdc6b04e37a
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 8a2810d5b2d..9a4b402573a 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-1f0c8364cd35026a647aa4e66ee4d8563c8a5d27
+60f985a7852632834936b4b859aa75d9df88f038
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/runtime/go-signal.c b/libgo/runtime/go-signal.c
index aa1b6305ad0..c48c8ee58e3 100644
--- a/libgo/runtime/go-signal.c
+++ b/libgo/runtime/go-signal.c
@@ -216,6 +216,10 @@ getSiginfoCode(siginfo_t *info)
return (uintptr)(info->si_code);
 }
 
+#if defined(__sparc__) && defined(__arch64__) && defined(__linux__)
+  #define gregs mc_gregs
+#endif
+
 struct getSiginfoRet {
uintptr sigaddr;
uintptr sigpc;
@@ -242,9 +246,9 @@ getSiginfo(siginfo_t *info, void *context 
__attribute__((unused)))
// Use unportable code to pull it from context, and if that fails
// try a stack backtrace across the signal handler.
 
-#if defined(__x86_64__) && defined(__linux__)
+#if defined(__x86_64__) && (defined(__linux__) || (defined(__sun__) && 
defined(__svr4__)))
ret.sigpc = ((ucontext_t*)(context))->uc_mcontext.gregs[REG_RIP];
-#elif defined(__i386__) && defined(__linux__)
+#elif defined(__i386__) && (defined(__linux__) || (defined(__sun__) && 
defined(__svr4__)))
ret.sigpc = ((ucontext_t*)(context))->uc_mcontext.gregs[REG_EIP];
 #elif defined(__alpha__) && defined(__linux__)
ret.sigpc = ((ucontext_t*)(context))->uc_mcontext.sc_pc;
@@ -263,6 +267,9 @@ getSiginfo(siginfo_t *info, void *context 
__attribute__((unused)))
 #elif defined(__NetBSD__)
ret.sigpc = _UC_MACHINE_PC(((ucontext_t*)(context)));
 #endif
+#if defined(__sparc__) && (defined(__linux__) || (defined(__sun__) && 
defined(__svr4__)))
+   ret.sigpc = ((ucontext_t*)(context))->uc_mcontext.gregs[REG_PC];
+#endif
 
if (ret.sigpc == 0) {
// Skip getSiginfo/sighandler/sigtrampgo/sigtramp/handler.
@@ -285,7 +292,7 @@ void dumpregs(siginfo_t *, void *)
 void
 dumpregs(siginfo_t *info __attribute__((unused)), void *context 
__attribute__((unused)))
 {
-#if defined(__x86_64__) && defined(__linux__)
+#if defined(__x86_64__) && (defined(__linux__) || (defined(__sun__) && 
defined(__svr4__)))
{
mcontext_t *m = &((ucontext_t*)(context))->uc_mcontext;
 
@@ -306,12 +313,22 @@ dumpregs(siginfo_t *info __attribute__((unused)), void 
*context __attribute__((u
runtime_printf("r14%X\n", m->gregs[REG_R14]);
runtime_printf("r15%X\n", m->gregs[REG_R15]);
runtime_printf("rip%X\n", m->gregs[REG_RIP]);
+#if defined(REG_EFL)
runtime_printf("rflags %X\n", m->gregs[REG_EFL]);
+#elif defined(REG_RFL)
+   runtime_printf("rflags %X\n", m->gregs[REG_RFL]);
+#endif
+#if defined(REG_CSGSFS)
runtime_printf("cs %X\n", m->gregs[REG_CSGSFS] & 0x);
runtime_printf("fs %X\n", (m->gregs[REG_CSGSFS] >> 16) & 
0x);
runtime_printf("gs %X\n", (m->gregs[REG_CSGSFS] >> 32) & 
0x);
+#elif defined(REG_CS) && defined(REG_FS) && defined(REG_GS)
+   runtime_printf("cs %X\n", m->gregs[REG_CS]);
+   runtime_printf("fs %X\n", m->gregs[REG_FS]);
+   runtime_printf("gs %X\n", m->gregs[REG_GS]);
+#endif
  }
-#elif defined(__i386__) && defined(__linux__)
+#elif defined(__i386__) && (defined(__linux__) || (defined(__sun__) && 
defined(__svr4__)))
{
mcontext_t *m = &((ucontext_t*)(context))->uc_mcontext;
 
@@ -423,5 +440,43 @@ dumpregs(siginfo_t *info __attribute__((unused)), void 
*context __attribute__((u
runtime_printf("pc %X\n", m->pc);
runtime_printf("pstate %X\n", m->pstate);
  }
+#elif defined(__sparc__) && (defined(__linux__) || (defined(__sun__) && 
defined(__svr4__)))
+   {
+   mcontext_t *m = &((ucontext_t*)(context))->uc_mcontext;
+
+#ifdef __sparcv9
+  #define REG_FMT "%X"
+#else
+  #define REG_FMT "%x"
+#endif
+
+#ifdef REG_CCR
+   runtime_printf("ccr  " REG_FMT "\n", m->gregs[REG_CCR]);
+#else
+   runtime_printf("psr  " REG_FMT "\n", m->gregs[REG_PSR]);
+#endif
+   runtime_printf("pc   " REG_FMT "\n", m->gregs[REG_PC]);
+   runtime_printf("npc  " REG_FMT "\n", m->gregs[REG_nPC]);
+   runtime_printf("y" REG_FMT "\n", m->gregs[REG_Y]);
+   runtime_printf("g1   " REG_FMT "\n", m->gregs[REG_G1]);
+   runtime_printf("g2   " REG_FMT "\n", m->gregs[REG_G2]);
+   runtime_printf("g3   " 

[PATCH] Fortran: fix issues with class(*) assignment [PR114827]

[Harald Anlauf]

Dear all,

the attached patch fixes issues with assignments of unlimited polymorphic
entities that were found with the help of valgrind or asan, see PR.  Looking
further into it, it turns out that allocation sizes as well as array spans
could be set incorrectly, leading to wrong results or heap corruption.

The fix is rather straightforward: take into the _len of unlimited
polymorphic entities when it is non-zero to get the correct allocation
sizes and array spans.

The patch has been tested by the reporter, see PR.

Regtested on x86_64-pc-linux-gnu.  OK for 15-mainline?

I would like to backport this to active branches where appropriate,
starting with 14 after it reopens after release.  Is this OK?

Thanks,
Harald

From 3b73471b570898e5a5085422da48d5bf118edff1 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Mon, 29 Apr 2024 19:52:52 +0200
Subject: [PATCH] Fortran: fix issues with class(*) assignment [PR114827]

gcc/fortran/ChangeLog:

	PR fortran/114827
	* trans-array.cc (gfc_alloc_allocatable_for_assignment): Take into
	account _len of unlimited polymorphic entities when calculating
	the effective element size for allocation size and array span.
	Set _len of lhs to _len of rhs.
	* trans-expr.cc (trans_class_assignment): Take into account _len
	of unlimited polymorphic entities for allocation size.

gcc/testsuite/ChangeLog:

	PR fortran/114827
	* gfortran.dg/asan/unlimited_polymorphic_34.f90: New test.
---
 gcc/fortran/trans-array.cc|  16 +++
 gcc/fortran/trans-expr.cc |  12 ++
 .../asan/unlimited_polymorphic_34.f90 | 135 ++
 3 files changed, 163 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/asan/unlimited_polymorphic_34.f90

diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 30b84762346..7ec33fb1598 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -11278,6 +11278,19 @@ gfc_alloc_allocatable_for_assignment (gfc_loopinfo *loop,
 	gfc_add_modify (, linfo->delta[dim], tmp);
 }

+  /* Take into account _len of unlimited polymorphic entities, so that span
+ for array descriptors and allocation sizes are computed correctly.  */
+  if (UNLIMITED_POLY (expr2))
+{
+  tree len = gfc_class_len_get (TREE_OPERAND (desc2, 0));
+  len = fold_build2_loc (input_location, MAX_EXPR, size_type_node,
+			 fold_convert (size_type_node, len),
+			 size_one_node);
+  elemsize2 = fold_build2_loc (input_location, MULT_EXPR,
+   gfc_array_index_type, elemsize2,
+   fold_convert (gfc_array_index_type, len));
+}
+
   if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (desc)))
 gfc_conv_descriptor_span_set (, desc, elemsize2);

@@ -11324,6 +11337,9 @@ gfc_alloc_allocatable_for_assignment (gfc_loopinfo *loop,
 	gfc_add_modify (, tmp,
 			fold_convert (TREE_TYPE (tmp),
 	  TYPE_SIZE_UNIT (type)));
+	  else if (UNLIMITED_POLY (expr2))
+	gfc_add_modify (, tmp,
+			gfc_class_len_get (TREE_OPERAND (desc2, 0)));
 	  else
 	gfc_add_modify (, tmp,
 			build_int_cst (TREE_TYPE (tmp), 0));
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 0280c441ced..4ba40bfdbd3 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -11991,6 +11991,18 @@ trans_class_assignment (stmtblock_t *block, gfc_expr *lhs, gfc_expr *rhs,
 	old_vptr = build_int_cst (TREE_TYPE (vptr), 0);

   size = gfc_vptr_size_get (rhs_vptr);
+
+  /* Take into account _len of unlimited polymorphic entities.  */
+  if (UNLIMITED_POLY (rhs))
+	{
+	  tree len = trans_get_upoly_len (block, rhs);
+	  len = fold_build2_loc (input_location, MAX_EXPR, size_type_node,
+ fold_convert (size_type_node, len),
+ size_one_node);
+	  size = fold_build2_loc (input_location, MULT_EXPR, TREE_TYPE (size),
+  size, fold_convert (TREE_TYPE (size), len));
+	}
+
   tmp = lse->expr;
   class_han = GFC_CLASS_TYPE_P (TREE_TYPE (tmp))
 	  ? gfc_class_data_get (tmp) : tmp;
diff --git a/gcc/testsuite/gfortran.dg/asan/unlimited_polymorphic_34.f90 b/gcc/testsuite/gfortran.dg/asan/unlimited_polymorphic_34.f90
new file mode 100644
index 000..c69158a1b55
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/asan/unlimited_polymorphic_34.f90
@@ -0,0 +1,135 @@
+! { dg-do run }
+! PR fortran/114827 - issues with class(*) assignment found by valgrind
+!
+! Contributed by Neil Carlson 
+
+program main
+  implicit none
+  call run
+  call run1
+  call run2
+contains
+  ! Scalar tests
+  subroutine run ()
+character(*),parameter :: c = 'fubarfubarfubarfubarfubarfu'
+character(*,kind=4), parameter :: d = 4_"abcdef"
+complex, parameter :: z = (1.,2.)
+class(*),  allocatable :: y
+
+call foo (c, y)
+select type (y)
+type is (character(*))
+!  print *, y(5:6)  ! ICE (-> pr114874)
+   if (y /= c) stop 1
+class default
+   stop 2
+end select
+
+call foo (z, y)
+select 

Re: [PATCH] libgcc: Do use weakrefs for glibc 2.34 on GNU Hurd

[Joseph Myers]

On Mon, 29 Apr 2024, Jakub Jelinek wrote:

> On Mon, Apr 29, 2024 at 01:44:24PM +, Joseph Myers wrote:
> > > glibc 2.34 and later doesn't have separate libpthread (libpthread.so.0 is 
> > > a
> > > dummy shared library with just some symbol versions for compatibility, but
> > > all the pthread_* APIs are in libc.so.6).
> > 
> > I suspect this has caused link failures in the glibc testsuite for Hurd, 
> > which still has separate libpthread.
> > 
> > https://sourceware.org/pipermail/libc-testresults/2024q2/012556.html
> 
> So like this then?  I can't really test it on Hurd, but will certainly
> test on x86_64-linux/i686-linux.
> 
> 2024-04-29  Jakub Jelinek  
> 
>   * gthr.h (GTHREAD_USE_WEAK): Don't redefine to 0 for glibc 2.34+
>   on GNU Hurd.

Yes, this fixes the problem seem for Hurd with build-many-glibcs.py.

-- 
Joseph S. Myers
josmy...@redhat.com

libgo patch committed: Use in runtime/runtime.h

[Ian Lance Taylor]

This libgo patch changes runtime/runtime.h to use the C99 
header file rather than defining a bool type and true/false constants
itself.  C99 was a long time ago and in case this file is always
compiled by the newly built GCC.  This should fix GCC PR 114875.
Bootstrapped on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
ef246d48fd487805f1c4181c7482545c54a4d4a9
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 50d430d5034..8a2810d5b2d 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-98e92493db2ab7857a5934a950a830fc1f95a4e5
+1f0c8364cd35026a647aa4e66ee4d8563c8a5d27
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/runtime/runtime.h b/libgo/runtime/runtime.h
index 699770d53ad..da31e11bb77 100644
--- a/libgo/runtime/runtime.h
+++ b/libgo/runtime/runtime.h
@@ -7,6 +7,7 @@
 #include "go-assert.h"
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -51,7 +52,6 @@ typedef uintptr   uintreg;
 
 /* Defined types.  */
 
-typedef_Bool   bool;
 typedefuint8   byte;
 typedefstruct  g   G;
 typedefstruct  mutex   Lock;
@@ -114,11 +114,6 @@ extern M*  runtime_m(void);
 extern G*  runtime_g(void)
   __asm__(GOSYM_PREFIX "runtime.getg");
 
-enum
-{
-   true= 1,
-   false   = 0,
-};
 enum
 {
PtrSize = sizeof(void*),

[PATCH] Add widening expansion of MULT_HIGHPART_EXPR for integral modes

[Eric Botcazou]

Hi,

for integral modes, the expansion of MULT_HIGHPART_EXPR requires the presence 
of an {s,u}mul_highpart optab whereas, for vector modes, widening expansion is
supported.  This adds a widening expansion for integral modes too, which is in 
fact already implemented in expmed_mult_highpart_optab.  We'll use that in a 
subsequent change to the Ada front-end to generate fast modulo reduction for 
modular types with nonbinary modulus (a little controversial Ada 95 feature).

Tested on x86-64/Linux, OK for the mainline?

2024-04-29  Eric Botcazou  

* expmed.h (expmed_mult_highpart_optab): Declare.
* expmed.cc (expmed_mult_highpart_optab): Remove static keyword.
Do not assume that OP1 is a constant integer.  Fix pasto.
(expmed_mult_highpart): Pass OP1 narrowed to MODE in all the calls
to expmed_mult_highpart_optab.
* optabs-query.cc (can_mult_highpart_p): Use 2 for integer widening
and shift subsequent values accordingly.
* optabs.cc (expand_mult_highpart): Call expmed_mult_highpart_optab
when can_mult_highpart_p returns 2 and adjust to above change.

-- 
Eric Botcazoudiff --git a/gcc/expmed.cc b/gcc/expmed.cc
index 60f65c7acc5..ccc671e922d 100644
--- a/gcc/expmed.cc
+++ b/gcc/expmed.cc
@@ -2742,8 +2742,7 @@ static rtx expand_mult_const (machine_mode, rtx, HOST_WIDE_INT, rtx,
 static unsigned HOST_WIDE_INT invert_mod2n (unsigned HOST_WIDE_INT, int);
 static rtx extract_high_half (scalar_int_mode, rtx);
 static rtx expmed_mult_highpart (scalar_int_mode, rtx, rtx, rtx, int, int);
-static rtx expmed_mult_highpart_optab (scalar_int_mode, rtx, rtx, rtx,
-   int, int);
+
 /* Compute and return the best algorithm for multiplying by T.
The algorithm must cost less than cost_limit
If retval.cost >= COST_LIMIT, no algorithm was found and all
@@ -3850,30 +3849,25 @@ extract_high_half (scalar_int_mode mode, rtx op)
   return convert_modes (mode, wider_mode, op, 0);
 }
 
-/* Like expmed_mult_highpart, but only consider using a multiplication
-   optab.  OP1 is an rtx for the constant operand.  */
+/* Like expmed_mult_highpart, but only consider using multiplication optab.  */
 
-static rtx
+rtx
 expmed_mult_highpart_optab (scalar_int_mode mode, rtx op0, rtx op1,
 			rtx target, int unsignedp, int max_cost)
 {
-  rtx narrow_op1 = gen_int_mode (INTVAL (op1), mode);
+  const scalar_int_mode wider_mode = GET_MODE_WIDER_MODE (mode).require ();
+  const bool speed = optimize_insn_for_speed_p ();
+  const int size = GET_MODE_BITSIZE (mode);
   optab moptab;
   rtx tem;
-  int size;
-  bool speed = optimize_insn_for_speed_p ();
-
-  scalar_int_mode wider_mode = GET_MODE_WIDER_MODE (mode).require ();
-
-  size = GET_MODE_BITSIZE (mode);
 
   /* Firstly, try using a multiplication insn that only generates the needed
  high part of the product, and in the sign flavor of unsignedp.  */
   if (mul_highpart_cost (speed, mode) < max_cost)
 {
   moptab = unsignedp ? umul_highpart_optab : smul_highpart_optab;
-  tem = expand_binop (mode, moptab, op0, narrow_op1, target,
-			  unsignedp, OPTAB_DIRECT);
+  tem = expand_binop (mode, moptab, op0, op1, target, unsignedp,
+			  OPTAB_DIRECT);
   if (tem)
 	return tem;
 }
@@ -3886,12 +3880,12 @@ expmed_mult_highpart_optab (scalar_int_mode mode, rtx op0, rtx op1,
 	  + 4 * add_cost (speed, mode) < max_cost))
 {
   moptab = unsignedp ? smul_highpart_optab : umul_highpart_optab;
-  tem = expand_binop (mode, moptab, op0, narrow_op1, target,
-			  unsignedp, OPTAB_DIRECT);
+  tem = expand_binop (mode, moptab, op0, op1, target, !unsignedp,
+			  OPTAB_DIRECT);
   if (tem)
 	/* We used the wrong signedness.  Adjust the result.  */
-	return expand_mult_highpart_adjust (mode, tem, op0, narrow_op1,
-	tem, unsignedp);
+	return expand_mult_highpart_adjust (mode, tem, op0, op1, tem,
+	unsignedp);
 }
 
   /* Try widening multiplication.  */
@@ -3899,8 +3893,8 @@ expmed_mult_highpart_optab (scalar_int_mode mode, rtx op0, rtx op1,
   if (convert_optab_handler (moptab, wider_mode, mode) != CODE_FOR_nothing
   && mul_widen_cost (speed, wider_mode) < max_cost)
 {
-  tem = expand_binop (wider_mode, moptab, op0, narrow_op1, 0,
-			  unsignedp, OPTAB_WIDEN);
+  tem = expand_binop (wider_mode, moptab, op0, op1, NULL_RTX, unsignedp,
+			  OPTAB_WIDEN);
   if (tem)
 	return extract_high_half (mode, tem);
 }
@@ -3941,14 +3935,14 @@ expmed_mult_highpart_optab (scalar_int_mode mode, rtx op0, rtx op1,
 	  + 2 * shift_cost (speed, mode, size-1)
 	  + 4 * add_cost (speed, mode) < max_cost))
 {
-  tem = expand_binop (wider_mode, moptab, op0, narrow_op1,
-			  NULL_RTX, ! unsignedp, OPTAB_WIDEN);
+  tem = expand_binop (wider_mode, moptab, op0, op1, NULL_RTX, !unsignedp,
+			  OPTAB_WIDEN);
   if (tem != 0)
 	{
 	  tem = extract_high_half (mode, tem);
 	  /* We used the wrong signedness.  Adjust the result.  */
-	  return 

Re: [PATCH] Minor tweaks to code computing modular multiplicative inverse

[Eric Botcazou]

> OK.  Consider waiting to commit though as we want to make it easy to
> cherry pick patches over to the release branch if needed.

Sure.  There are a couple more changes on top of it, but all can wait a bit.

-- 
Eric Botcazou

Re: [PATCH] Don't assert for IFN_COND_{MIN, MAX} in vect_transform_reduction

[H.J. Lu]

On Mon, Apr 29, 2024 at 6:47 AM liuhongt  wrote:
>
> The Fortran standard does not specify what the result of the MAX
> and MIN intrinsics are if one of the arguments is a NaN. So it
> should be ok to tranform reduction for IFN_COND_MIN with vectorized
> COND_MIN and REDUC_MIN.

The commit subject isn't very clear.   This patch isn't about "Don't assert
for IFN_COND_{MIN,MAX}".  It allows IFN_COND_{MIN,MAX} in
vect_transform_reduction.

> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk and backport to GCC14?
>
> gcc/ChangeLog:
>
> PR 114883
> * tree-vect-loop.cc (vect_transform_reduction): Don't assert
> for IFN_COND_{MIN, MAX}.
>
> gcc/testsuite/ChangeLog:
>
> * gfortran.dg/pr114883.f90: New test.
> ---
>  gcc/testsuite/gfortran.dg/pr114883.f90 | 191 +
>  gcc/tree-vect-loop.cc  |   3 +-
>  2 files changed, 193 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gfortran.dg/pr114883.f90
>
> diff --git a/gcc/testsuite/gfortran.dg/pr114883.f90 
> b/gcc/testsuite/gfortran.dg/pr114883.f90
> new file mode 100644
> index 000..86b664a521e
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/pr114883.f90
> @@ -0,0 +1,191 @@
> +! { dg-do compile }
> +! { dg-options "-O3" }
> +! { dg-additional-options "-march=x86-64-v4" { target { x86_64-*-* i?86-*-* 
> } } }
> +
> +module ndrop
> +
> +
> +  implicit none
> +
> +  private
> +  save
> +
> +  public dropmixnuc
> +
> +  real(8) :: npv(1011) ! number per volume concentration
> +  real(8) :: alogsig(1011) ! natl log of geometric standard dev of aerosol
> +
> +  type qqcw_type
> + real(8), pointer :: fldcw(:,:)
> +  end type qqcw_type
> +
> +contains
> +
> +  subroutine dropmixnuc(lchnk, ncol, temp,  &
> +   cldn,cldo, &
> +   raer, dtmicro   &
> +   )
> +implicit none
> +
> +! input
> +
> +integer, intent(in) :: lchnk! chunk identifier
> +integer, intent(in) :: ncol ! number of columns
> +!  type(physics_state), intent(in) :: state  ! Physics state 
> variables
> +real(8), intent(in) :: dtmicro ! time step for microphysics 
> (s)
> +real(8), intent(in) :: temp(1,1011)! temperature (K)
> +real(8), intent(in) :: cldo(1,1011)! cloud fraction on previous time 
> step
> +real(8), intent(in) :: cldn(1,1011)! cloud fraction
> +real(8), intent(in) :: raer(1,1011,1011) ! aerosol mass, number mixing 
> ratios
> +
> +
> +type(qqcw_type) :: QQCW(1011)
> +
> +real(8) depvel(1,1011)! deposition velocity for droplets (m/s)
> +real(8) wtke(1,1011) ! turbulent vertical velocity at base of layer 
> k (m/s)
> +real(8) wtke_cen(1,1011) ! turbulent vertical velocity at center of 
> layer k (m/s)
> +real(8) zn(1011) ! g/pdel (m2/g) for layer
> +real(8) zs(1011) ! inverse of distance between levels (m)
> +real(8), parameter :: zkmin=0.01_8,zkmax=100._8
> +real(8) cs(1,1011)  ! air density (kg/m3)
> +real(8) dz(1,1011)  ! geometric thickness of layers (m)
> +real(8) zero
> +
> +real(8) wdiab   ! diabatic vertical velocity
> +real(8), parameter :: wmixmin = 0.1 ! minimum turbulence vertical 
> velocity (m/s)
> +!   real(8), parameter :: wmixmin = 0.2 ! minimum turbulence 
> vertical velocity (m/s)
> +!  real(8), parameter :: wmixmin = 1.0 ! minimum turbulence vertical 
> velocity (m/s)
> +real(8) ekk(0:1011)   ! density*diffusivity for droplets (kg/m3 m2/s)
> +real(8), parameter :: sq2pi=2.5066283_8
> +real(8) dtinv
> +
> +integer km1,kp1
> +real(8) wbar,wmix,wmin,wmax
> +real(8) dumc
> +real(8) fac_srflx
> +real(8) surfrate(1011) ! surface exchange rate (/s)
> +real(8) surfratemax  ! max surfrate for all species treated here
> +real(8) dtmin,tinv,dtt
> +integer nsubmix,nsubmix_bnd
> +integer i,k,m
> +real(8) dtmix
> +real(8) pi
> +integer nnew,nsav,ntemp
> +real(8) ekkp(1011),ekkm(1011) ! zn*zs*density*diffusivity
> +integer count_submix(100)
> +save count_submix
> +real(8) nsource(1,1011)! droplet number source (#/kg/s)
> +real(8) ndropmix(1,1011)   ! droplet number mixing (#/kg/s)
> +real(8) ndropcol(1)   ! column droplet number (#/m2)
> +
> +real(8) na(1),va(1),hy(1)
> +real(8) naermod(1011) ! (/m3)
> +real(8) hygro(1011)  ! hygroscopicity of aerosol mode
> +real(8) vaerosol(1011) ! interstit+activated aerosol volume conc 
> (cm3/cm3)
> +real(8) :: taumix_internal_1011_inv ! 1/(internal mixing time scale for 
> k=1011) (1/s)
> +real(8) :: cldo_tmp, cldn_tmp
> +real(8) :: tau_cld_regenerate
> +
> +integer ixndrop, l
> +integer, parameter :: psat=6 ! number of supersaturations to calc ccn 
> concentration
> +real(8)  :: supersat(psat)= & ! supersaturation (%) to determine ccn 
> concentration
> 

Re: [PATCH] Remove m_nloops field from loop_versioning

[Jeff Law]

On 4/26/24 11:25 PM, Andrew Pinski wrote:

This is a small cleanup of loop_versioning where m_nloops
is only used in the constructor so we can remove the whole
field.

Bootstrapped and tested on x86_64-linux-gnu.

gcc/ChangeLog:

* gimple-loop-versioning.cc (loop_versioning): Remove m_nloops field.
(loop_versioning::loop_versioning): Remove initialization of
m_nloops field and move it to be a local variable.
(loop_versioning::analyze_blocks): Fix formating.
OK.  But consider holding off on the commit for a bit to make 
cherry-picking to the release branch easier.


jeff

Re: [PATCH v2] DSE: Bugfix ICE after allow vector type in get_stored_val

[Jeff Law]

On 3/22/24 11:45 PM, Li, Pan2 wrote:

Thanks Jeff for comments.


As Richi noted using validate_subreg here isn't great.  Does it work to
factor out this code from extract_low_bits


   if (!int_mode_for_mode (src_mode).exists (_int_mode)
   || !int_mode_for_mode (mode).exists (_mode))
 return NULL_RTX;

   if (!targetm.modes_tieable_p (src_int_mode, src_mode))
 return NULL_RTX;
   if (!targetm.modes_tieable_p (int_mode, mode))
 return NULL_RTX;



And use that in the condition (and in extract_low_bits rather than
duplicating the code)?


It can solve the ICE but will forbid all vector modes goes gen_lowpart.
Actually only the vector mode size is less than reg nature size will trigger 
the ICE.
Thus, how about just add one more condition before goes to gen_lowpart as below?

Feel free to correct me if any misunderstandings. !

diff --git a/gcc/dse.cc b/gcc/dse.cc
index edc7a1dfecf..258d2ccc299 100644
--- a/gcc/dse.cc
+++ b/gcc/dse.cc
@@ -1946,7 +1946,9 @@ get_stored_val (store_info *store_info, machine_mode 
read_mode,
  copy_rtx (store_info->const_rhs));
else if (VECTOR_MODE_P (read_mode) && VECTOR_MODE_P (store_mode)
  && known_le (GET_MODE_BITSIZE (read_mode), GET_MODE_BITSIZE (store_mode))
-&& targetm.modes_tieable_p (read_mode, store_mode))
+&& targetm.modes_tieable_p (read_mode, store_mode)
+/* It's invalid in validate_subreg if read_mode size is < reg natural.  */
+&& known_ge (GET_MODE_SIZE (read_mode), REGMODE_NATURAL_SIZE (read_mode)))
  read_reg = gen_lowpart (read_mode, copy_rtx (store_info->rhs));
else
  read_reg = extract_low_bits (read_mode, store_mode,
So how about this.  I'll ack this for the trunk, but not for gcc-14 (at 
this time).  We can revisit for gcc-14 after it's been on the trunk a 
bit.  Realistically that likely means gcc-14.2 at the end of the summer 
rather than gcc-14.1 which is due in roughly a week.


Jeff

Re: [PATCH] Minor tweaks to code computing modular multiplicative inverse

[Jeff Law]

On 4/29/24 1:14 AM, Eric Botcazou wrote:

Hi,

this removes the last parameter of choose_multiplier, which is unused, adds
another assertion and more details to the description and various comments.
Likewise to the closely related invert_mod2n, except for the last parameter.

Tested on x86-64/Linux, OK for the mainline?


2024-04-29  Eric Botcazou  

* expmed.h (choose_multiplier): Tweak description and remove last
parameter.
* expmed.cc (choose_multiplier): Likewise.  Add assertion for the
third parameter and adds details to various comments.
(invert_mod2n): Tweak description and add assertion for the first
parameter.
(expand_divmod): Adjust calls to choose_multiplier.
* tree-vect-generic.cc (expand_vector_divmod): Likewise.
* tree-vect-patterns.cc (vect_recog_divmod_pattern): Likewise.
OK.  Consider waiting to commit though as we want to make it easy to 
cherry pick patches over to the release branch if needed.


Jeff

[PATCH][Backport][GCC13] match.pd: Only merge truncation with conversion for -fno-signed-zeros

[Joe Ramsay]

This optimisation does not honour signed zeros, so should not be
enabled except with -fno-signed-zeros.

Cherry-pick of 7dd3b2b09cbeb6712ec680a0445cb0ad41070423.

Applies cleanly on releases/gcc-13, regression-tested with no new
failures.

OK for backport to GCC 13? If so, please commit for me as I do not
have commit rights in GCC.

Thanks,
Joe

gcc/ChangeLog:

* match.pd: Fix truncation pattern for -fno-signed-zeroes

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/no_merge_trunc_signed_zero.c: New test.
---
 gcc/match.pd  |  1 +
 .../aarch64/no_merge_trunc_signed_zero.c  | 24 +++
 2 files changed, 25 insertions(+)
 create mode 100644 
gcc/testsuite/gcc.target/aarch64/no_merge_trunc_signed_zero.c

diff --git a/gcc/match.pd b/gcc/match.pd
index 47e48fa2ca5..dc34e7ead9f 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -4188,6 +4188,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 (simplify
(float (fix_trunc @0))
(if (!flag_trapping_math
+   && !HONOR_SIGNED_ZEROS (type)
&& types_match (type, TREE_TYPE (@0))
&& direct_internal_fn_supported_p (IFN_TRUNC, type,
  OPTIMIZE_FOR_BOTH))
diff --git a/gcc/testsuite/gcc.target/aarch64/no_merge_trunc_signed_zero.c 
b/gcc/testsuite/gcc.target/aarch64/no_merge_trunc_signed_zero.c
new file mode 100644
index 000..b2c93e55567
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/no_merge_trunc_signed_zero.c
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-trapping-math -fsigned-zeros" } */
+
+#include 
+
+float
+f1 (float x)
+{
+  return (int) rintf(x);
+}
+
+double
+f2 (double x)
+{
+  return (long) rint(x);
+}
+
+/* { dg-final { scan-assembler "frintx\\ts\[0-9\]+, s\[0-9\]+" } } */
+/* { dg-final { scan-assembler "cvtzs\\ts\[0-9\]+, s\[0-9\]+" } } */
+/* { dg-final { scan-assembler "scvtf\\ts\[0-9\]+, s\[0-9\]+" } } */
+/* { dg-final { scan-assembler "frintx\\td\[0-9\]+, d\[0-9\]+" } } */
+/* { dg-final { scan-assembler "cvtzs\\td\[0-9\]+, d\[0-9\]+" } } */
+/* { dg-final { scan-assembler "scvtf\\td\[0-9\]+, d\[0-9\]+" } } */
+
-- 
2.27.0

[PATCH][Backport][GCC12] match.pd: Only merge truncation with conversion for -fno-signed-zeros

[Joe Ramsay]

This optimisation does not honour signed zeros, so should not be
enabled except with -fno-signed-zeros.

Cherry-pick of 7dd3b2b09cbeb6712ec680a0445cb0ad41070423.

Applies cleanly on releases/gcc-12. Regression-tested, only new
failure is in gcc/testsuite/c-c++-common/hwasan/large-aligned-1.c
which I believe is unrelated and known to be flaky.

OK for backport to GCC 12? If so, please commit for me as I do not
have commit rights in GCC.

Thanks,
Joe

gcc/ChangeLog:

* match.pd: Fix truncation pattern for -fno-signed-zeroes

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/no_merge_trunc_signed_zero.c: New test.
---
 gcc/match.pd  |  1 +
 .../aarch64/no_merge_trunc_signed_zero.c  | 24 +++
 2 files changed, 25 insertions(+)
 create mode 100644 
gcc/testsuite/gcc.target/aarch64/no_merge_trunc_signed_zero.c

diff --git a/gcc/match.pd b/gcc/match.pd
index c5a4426e76b..0938d56fa45 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -3825,6 +3825,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 (simplify
(float (fix_trunc @0))
(if (!flag_trapping_math
+   && !HONOR_SIGNED_ZEROS (type)
&& types_match (type, TREE_TYPE (@0))
&& direct_internal_fn_supported_p (IFN_TRUNC, type,
  OPTIMIZE_FOR_BOTH))
diff --git a/gcc/testsuite/gcc.target/aarch64/no_merge_trunc_signed_zero.c 
b/gcc/testsuite/gcc.target/aarch64/no_merge_trunc_signed_zero.c
new file mode 100644
index 000..b2c93e55567
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/no_merge_trunc_signed_zero.c
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-trapping-math -fsigned-zeros" } */
+
+#include 
+
+float
+f1 (float x)
+{
+  return (int) rintf(x);
+}
+
+double
+f2 (double x)
+{
+  return (long) rint(x);
+}
+
+/* { dg-final { scan-assembler "frintx\\ts\[0-9\]+, s\[0-9\]+" } } */
+/* { dg-final { scan-assembler "cvtzs\\ts\[0-9\]+, s\[0-9\]+" } } */
+/* { dg-final { scan-assembler "scvtf\\ts\[0-9\]+, s\[0-9\]+" } } */
+/* { dg-final { scan-assembler "frintx\\td\[0-9\]+, d\[0-9\]+" } } */
+/* { dg-final { scan-assembler "cvtzs\\td\[0-9\]+, d\[0-9\]+" } } */
+/* { dg-final { scan-assembler "scvtf\\td\[0-9\]+, d\[0-9\]+" } } */
+
-- 
2.27.0

[PATCH] libgcc: Do use weakrefs for glibc 2.34 on GNU Hurd

[Jakub Jelinek]

On Mon, Apr 29, 2024 at 01:44:24PM +, Joseph Myers wrote:
> > glibc 2.34 and later doesn't have separate libpthread (libpthread.so.0 is a
> > dummy shared library with just some symbol versions for compatibility, but
> > all the pthread_* APIs are in libc.so.6).
> 
> I suspect this has caused link failures in the glibc testsuite for Hurd, 
> which still has separate libpthread.
> 
> https://sourceware.org/pipermail/libc-testresults/2024q2/012556.html

So like this then?  I can't really test it on Hurd, but will certainly
test on x86_64-linux/i686-linux.

2024-04-29  Jakub Jelinek  

* gthr.h (GTHREAD_USE_WEAK): Don't redefine to 0 for glibc 2.34+
on GNU Hurd.

--- libgcc/gthr.h.jj2024-04-25 20:43:10.555694952 +0200
+++ libgcc/gthr.h   2024-04-29 16:57:40.734062691 +0200
@@ -142,7 +142,7 @@ see the files COPYING3 and COPYING.RUNTI
 #endif
 
 #ifdef __GLIBC_PREREQ
-#if __GLIBC_PREREQ(2, 34)
+#if __GLIBC_PREREQ(2, 34) && !defined(__gnu_hurd__)
 /* glibc 2.34 and later has all pthread_* APIs inside of libc,
no need to link separately with -lpthread.  */
 #undef GTHREAD_USE_WEAK


Jakub

Re: [PATCH] c++: ICE with templated sizeof(E1) / sizeof(E2) [PR114888]

[Marek Polacek]

On Mon, Apr 29, 2024 at 10:28:19AM -0400, Patrick Palka wrote:
> Lightly tested on x86_64-pc-linux-gnu so far, does this look OK for
> trunk/14.1 after bootstrap+regtest finishes?

LGTM.
 
> -- >8 --
> 
> We're missing a dependence check for the second operand in the
> sizeof / sizeof handling.
> 
>   PR c++/114888
> 
> gcc/cp/ChangeLog:
> 
>   * typeck.cc (cp_build_binary_op) : Add missing
>   dependence check for the second sizeof operand.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/template/sizeof19.C: New test.
> ---
>  gcc/cp/typeck.cc | 1 +
>  gcc/testsuite/g++.dg/template/sizeof19.C | 8 
>  2 files changed, 9 insertions(+)
>  create mode 100644 gcc/testsuite/g++.dg/template/sizeof19.C
> 
> diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
> index e5a52dc2b39..a25f8622651 100644
> --- a/gcc/cp/typeck.cc
> +++ b/gcc/cp/typeck.cc
> @@ -5501,6 +5501,7 @@ cp_build_binary_op (const op_location_t ,
> if (!TYPE_P (type1))
>   type1 = TREE_TYPE (type1);
> if (type0
> +   && type1
> && INDIRECT_TYPE_P (type0)
> && same_type_p (TREE_TYPE (type0), type1))
>   {
> diff --git a/gcc/testsuite/g++.dg/template/sizeof19.C 
> b/gcc/testsuite/g++.dg/template/sizeof19.C
> new file mode 100644
> index 000..a1467995a9b
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/template/sizeof19.C
> @@ -0,0 +1,8 @@
> +// PR c++/114888
> +
> +template
> +struct A {
> +  struct B {} *b;
> +  static const int c = sizeof (b) / sizeof (b[0]);
> +};
> +const int d = A::c;
> -- 
> 2.45.0.rc1
> 

Marek

[PATCH] c++: ICE with templated sizeof(E1) / sizeof(E2) [PR114888]

[Patrick Palka]

Lightly tested on x86_64-pc-linux-gnu so far, does this look OK for
trunk/14.1 after bootstrap+regtest finishes?

-- >8 --

We're missing a dependence check for the second operand in the
sizeof / sizeof handling.

PR c++/114888

gcc/cp/ChangeLog:

* typeck.cc (cp_build_binary_op) : Add missing
dependence check for the second sizeof operand.

gcc/testsuite/ChangeLog:

* g++.dg/template/sizeof19.C: New test.
---
 gcc/cp/typeck.cc | 1 +
 gcc/testsuite/g++.dg/template/sizeof19.C | 8 
 2 files changed, 9 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/template/sizeof19.C

diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
index e5a52dc2b39..a25f8622651 100644
--- a/gcc/cp/typeck.cc
+++ b/gcc/cp/typeck.cc
@@ -5501,6 +5501,7 @@ cp_build_binary_op (const op_location_t ,
  if (!TYPE_P (type1))
type1 = TREE_TYPE (type1);
  if (type0
+ && type1
  && INDIRECT_TYPE_P (type0)
  && same_type_p (TREE_TYPE (type0), type1))
{
diff --git a/gcc/testsuite/g++.dg/template/sizeof19.C 
b/gcc/testsuite/g++.dg/template/sizeof19.C
new file mode 100644
index 000..a1467995a9b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/sizeof19.C
@@ -0,0 +1,8 @@
+// PR c++/114888
+
+template
+struct A {
+  struct B {} *b;
+  static const int c = sizeof (b) / sizeof (b[0]);
+};
+const int d = A::c;
-- 
2.45.0.rc1

[PATCH] c++/modules: imported spec befriending class tmpl [PR114889]

[Patrick Palka]

Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
14 (I guess after 14.1 is released)?

-- >8 --

We need to look through TEMPLATE_DECL like make_friend_class does when
adding to CLASSTYPE_BEFRIENDING_CLASSES.

Otherwise in the below testcase we won't add _Hashtable to
CLASSTYPE_BEFRIENDING_CLASSES of _Map_base when installing the definition
of the former which leads to access control issues.

PR c++/114889

gcc/cp/ChangeLog:

* module.cc (trees_in::read_class_def): Look through
TEMPLATE_DECL when adding to CLASSTYPE_BEFRIENDING_CLASSES.

gcc/testsuite/ChangeLog:

* g++.dg/modules/friend-8_a.H: New test.
* g++.dg/modules/friend-8_b.C: New test.
---
 gcc/cp/module.cc  |  2 ++
 gcc/testsuite/g++.dg/modules/friend-8_a.H | 23 +++
 gcc/testsuite/g++.dg/modules/friend-8_b.C |  9 +
 3 files changed, 34 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/modules/friend-8_a.H
 create mode 100644 gcc/testsuite/g++.dg/modules/friend-8_b.C

diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 7e654305f0a..3b2ba40c92b 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -12518,6 +12518,8 @@ trees_in::read_class_def (tree defn, tree 
maybe_template)
  for (; friend_classes; friend_classes = TREE_CHAIN (friend_classes))
{
  tree f = TREE_VALUE (friend_classes);
+ if (TREE_CODE (f) == TEMPLATE_DECL)
+   f = TREE_TYPE (f);
 
  if (CLASS_TYPE_P (f))
{
diff --git a/gcc/testsuite/g++.dg/modules/friend-8_a.H 
b/gcc/testsuite/g++.dg/modules/friend-8_a.H
new file mode 100644
index 000..b07ea25adfb
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/friend-8_a.H
@@ -0,0 +1,23 @@
+// PR c++/114889
+// { dg-additional-options "-fmodule-header" }
+// { dg-module-cmi {} }
+
+template
+struct _Hashtable;
+
+template
+struct _Map_base {
+  void f() {
+_Hashtable<_Key, _Val> __h;
+__h._M_hash_code(0);
+  }
+};
+
+template
+struct _Hashtable {
+  template friend struct _Map_base;
+protected:
+  void _M_hash_code(int);
+};
+
+inline _Hashtable m;
diff --git a/gcc/testsuite/g++.dg/modules/friend-8_b.C 
b/gcc/testsuite/g++.dg/modules/friend-8_b.C
new file mode 100644
index 000..b04280bc91a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/friend-8_b.C
@@ -0,0 +1,9 @@
+// PR c++/114889
+// { dg-additional-options "-fmodules-ts" }
+
+import "friend-8_a.H";
+
+int main() {
+  _Map_base m;
+  m.f();
+}
-- 
2.45.0.rc1

[PATCH] Don't assert for IFN_COND_{MIN, MAX} in vect_transform_reduction

[liuhongt]

The Fortran standard does not specify what the result of the MAX
and MIN intrinsics are if one of the arguments is a NaN. So it
should be ok to tranform reduction for IFN_COND_MIN with vectorized
COND_MIN and REDUC_MIN.

Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk and backport to GCC14?

gcc/ChangeLog:

PR 114883
* tree-vect-loop.cc (vect_transform_reduction): Don't assert
for IFN_COND_{MIN, MAX}.

gcc/testsuite/ChangeLog:

* gfortran.dg/pr114883.f90: New test.
---
 gcc/testsuite/gfortran.dg/pr114883.f90 | 191 +
 gcc/tree-vect-loop.cc  |   3 +-
 2 files changed, 193 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr114883.f90

diff --git a/gcc/testsuite/gfortran.dg/pr114883.f90 
b/gcc/testsuite/gfortran.dg/pr114883.f90
new file mode 100644
index 000..86b664a521e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr114883.f90
@@ -0,0 +1,191 @@
+! { dg-do compile }
+! { dg-options "-O3" }
+! { dg-additional-options "-march=x86-64-v4" { target { x86_64-*-* i?86-*-* } 
} }
+
+module ndrop
+
+
+  implicit none
+
+  private
+  save
+
+  public dropmixnuc
+
+  real(8) :: npv(1011) ! number per volume concentration
+  real(8) :: alogsig(1011) ! natl log of geometric standard dev of aerosol
+
+  type qqcw_type
+ real(8), pointer :: fldcw(:,:)
+  end type qqcw_type
+
+contains
+
+  subroutine dropmixnuc(lchnk, ncol, temp,  &
+   cldn,cldo, &
+   raer, dtmicro   &
+   ) 
+implicit none
+
+! input
+
+integer, intent(in) :: lchnk! chunk identifier
+integer, intent(in) :: ncol ! number of columns
+!  type(physics_state), intent(in) :: state  ! Physics state 
variables
+real(8), intent(in) :: dtmicro ! time step for microphysics (s)
+real(8), intent(in) :: temp(1,1011)! temperature (K)
+real(8), intent(in) :: cldo(1,1011)! cloud fraction on previous time 
step
+real(8), intent(in) :: cldn(1,1011)! cloud fraction
+real(8), intent(in) :: raer(1,1011,1011) ! aerosol mass, number mixing 
ratios
+
+
+type(qqcw_type) :: QQCW(1011)
+
+real(8) depvel(1,1011)! deposition velocity for droplets (m/s)
+real(8) wtke(1,1011) ! turbulent vertical velocity at base of layer k 
(m/s)
+real(8) wtke_cen(1,1011) ! turbulent vertical velocity at center of layer 
k (m/s)
+real(8) zn(1011) ! g/pdel (m2/g) for layer
+real(8) zs(1011) ! inverse of distance between levels (m)
+real(8), parameter :: zkmin=0.01_8,zkmax=100._8
+real(8) cs(1,1011)  ! air density (kg/m3)
+real(8) dz(1,1011)  ! geometric thickness of layers (m)
+real(8) zero
+
+real(8) wdiab   ! diabatic vertical velocity
+real(8), parameter :: wmixmin = 0.1 ! minimum turbulence vertical velocity 
(m/s)
+!   real(8), parameter :: wmixmin = 0.2 ! minimum turbulence vertical 
velocity (m/s)
+!  real(8), parameter :: wmixmin = 1.0 ! minimum turbulence vertical 
velocity (m/s)
+real(8) ekk(0:1011)   ! density*diffusivity for droplets (kg/m3 m2/s)
+real(8), parameter :: sq2pi=2.5066283_8
+real(8) dtinv
+
+integer km1,kp1
+real(8) wbar,wmix,wmin,wmax
+real(8) dumc
+real(8) fac_srflx
+real(8) surfrate(1011) ! surface exchange rate (/s)
+real(8) surfratemax  ! max surfrate for all species treated here
+real(8) dtmin,tinv,dtt
+integer nsubmix,nsubmix_bnd
+integer i,k,m
+real(8) dtmix
+real(8) pi
+integer nnew,nsav,ntemp
+real(8) ekkp(1011),ekkm(1011) ! zn*zs*density*diffusivity
+integer count_submix(100)
+save count_submix
+real(8) nsource(1,1011)! droplet number source (#/kg/s)
+real(8) ndropmix(1,1011)   ! droplet number mixing (#/kg/s)
+real(8) ndropcol(1)   ! column droplet number (#/m2)
+
+real(8) na(1),va(1),hy(1)
+real(8) naermod(1011) ! (/m3)
+real(8) hygro(1011)  ! hygroscopicity of aerosol mode
+real(8) vaerosol(1011) ! interstit+activated aerosol volume conc (cm3/cm3)
+real(8) :: taumix_internal_1011_inv ! 1/(internal mixing time scale for 
k=1011) (1/s)
+real(8) :: cldo_tmp, cldn_tmp
+real(8) :: tau_cld_regenerate
+
+integer ixndrop, l
+integer, parameter :: psat=6 ! number of supersaturations to calc ccn 
concentration
+real(8)  :: supersat(psat)= & ! supersaturation (%) to determine ccn 
concentration
+ (/0.02,0.05,0.1,0.2,0.5,1.0/)
+real(8) ccn(1,1011,psat)! number conc of aerosols activated at 
supersat
+character(len=8), dimension(psat) :: ccn_name(psat)= &
+ (/'CCN1','CCN2','CCN3','CCN4','CCN5','CCN6'/)
+real(8) arg
+integer phase ! phase of aerosol
+
+
+
+arg = 1.0_8
+zero=0._8
+
+
+pi = 4._8*atan(1.0_8)
+dtinv=1./dtmicro
+
+depvel(:,:) = 0.0_8! droplet number is done in pkg_cld_sediment, 
aerosols 

Re: [PATCH] libgcc: Don't use weakrefs for glibc 2.34

[Joseph Myers]

On Thu, 25 Apr 2024, Jakub Jelinek wrote:

> Hi!
> 
> glibc 2.34 and later doesn't have separate libpthread (libpthread.so.0 is a
> dummy shared library with just some symbol versions for compatibility, but
> all the pthread_* APIs are in libc.so.6).

I suspect this has caused link failures in the glibc testsuite for Hurd, 
which still has separate libpthread.

https://sourceware.org/pipermail/libc-testresults/2024q2/012556.html

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] arm: [MVE intrinsics] Fix support for predicate constants [PR target/114801]

[Christophe Lyon]

On Mon, 29 Apr 2024 at 15:29, Jakub Jelinek  wrote:
>
> On Fri, Apr 26, 2024 at 11:10:12PM +, Christophe Lyon wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/arm/mve/pr114801.c
> > @@ -0,0 +1,36 @@
> > +/* { dg-do compile } */
> > +/* { dg-require-effective-target arm_v8_1m_mve_ok } */
> > +/* { dg-add-options arm_v8_1m_mve } */
> > +/* { dg-final { check-function-bodies "**" "" "" } } */
> > +
> > +#include 
> > +
> > +/*
> > +** test_32:
> > +**...
> > +**   mov r[0-9]+, #65535 @ movhi
> > +**...
> > +*/
> > +uint32x4_t test_32() {
> > +  return vdupq_m_n_u32(vdupq_n_u32(0), 0, 0x);
>
> Just a testcase nit.  I think testing 0x isn't that useful,
> it tests the same 4 bits 4 times.
> Might be more interesting to test 4 different 4 bit elements,
> one of them 0 (to verify it doesn't turn that into all ones),
> one all 1s (that is the other valid case) and then 2 random
> other values in between.
>
> > +}
> > +
> > +/*
> > +** test_16:
> > +**...
> > +**   mov r[0-9]+, #52428 @ movhi
> > +**...
> > +*/
> > +uint16x8_t test_16() {
> > +  return vdupq_m_n_u16(vdupq_n_u16(0), 0, 0x);
>
> And for these it can actually test all 4 possible 2 bit elements,
> so say 0x3021
>
> > +}
> > +
> > +/*
> > +** test_8:
> > +**...
> > +**   mov r[0-9]+, #52428 @ movhi
> > +**...
> > +*/
> > +uint8x16_t test_8() {
> > +  return vdupq_m_n_u8(vdupq_n_u8(0), 0, 0x);
>
> and here use some random pattern.
>
> BTW, the patch is ok for 14.1 if it is approved and committed today
> (so that it can be cherry-picked tomorrow morning at latest to the branch).

Thanks for your comments, I'll update the testcase, but Andre provided
additional info in the PR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801#c17

I tried just removing the call to gcc_unreachable in
rtx_vector_builder::find_cached_value and that does the trick, but I'm
worried by such a change.

Christophe






>
> Jakub
>

Re: [PATCH] rust: Add rust.install-dvi and rust.install-html rules

[Christophe Lyon]

On Mon, 29 Apr 2024 at 15:24, Arthur Cohen  wrote:
>
> Thanks Christophe!
>
> I've added your patch as part of a documentation pull-request I'm adding
> to our dev repo: https://github.com/Rust-GCC/gccrs/pull/2966
>
> It'll be upstreamed with the next batch of commits we send, as soon as
> trunk reopens fully for 15.1.
>

Thanks!

Note that I already pushed the patch as r14-9865-g73fb0a6153f478
so you may have conflicts (easy to fix ;-) )

Christophe

> Best,
>
> Arthur
>
> On 4/4/24 18:27, Christophe Lyon wrote:
> > rust has the (empty) rust.dvi and rust.html rules, but lacks the
> > (empty) rust.install-dvi and rust.install-html ones.
> >
> > 2024-04-04  Christophe Lyon  
> >
> >   gcc/rust/
> >   * Make-lang.in (rust.install-dvi, rust.install-html): New rules.
> > ---
> >   gcc/rust/Make-lang.in | 2 ++
> >   1 file changed, 2 insertions(+)
> >
> > diff --git a/gcc/rust/Make-lang.in b/gcc/rust/Make-lang.in
> > index 4d646018792..4d73412739d 100644
> > --- a/gcc/rust/Make-lang.in
> > +++ b/gcc/rust/Make-lang.in
> > @@ -342,6 +342,8 @@ selftest-rust-valgrind: $(RUST_SELFTEST_DEPS)
> >   # should have dependencies on info files that should be installed.
> >   rust.install-info:
> >
> > +rust.install-dvi:
> > +rust.install-html:
> >   rust.install-pdf:
> >
> >   # Install man pages for the front end. This target should ignore errors.

Re: [PATCH] arm: [MVE intrinsics] Fix support for predicate constants [PR target/114801]

[Jakub Jelinek]

On Fri, Apr 26, 2024 at 11:10:12PM +, Christophe Lyon wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/mve/pr114801.c
> @@ -0,0 +1,36 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target arm_v8_1m_mve_ok } */
> +/* { dg-add-options arm_v8_1m_mve } */
> +/* { dg-final { check-function-bodies "**" "" "" } } */
> +
> +#include 
> +
> +/*
> +** test_32:
> +**...
> +**   mov r[0-9]+, #65535 @ movhi
> +**...
> +*/
> +uint32x4_t test_32() {
> +  return vdupq_m_n_u32(vdupq_n_u32(0), 0, 0x);

Just a testcase nit.  I think testing 0x isn't that useful,
it tests the same 4 bits 4 times.
Might be more interesting to test 4 different 4 bit elements,
one of them 0 (to verify it doesn't turn that into all ones),
one all 1s (that is the other valid case) and then 2 random
other values in between.

> +}
> +
> +/*
> +** test_16:
> +**...
> +**   mov r[0-9]+, #52428 @ movhi
> +**...
> +*/
> +uint16x8_t test_16() {
> +  return vdupq_m_n_u16(vdupq_n_u16(0), 0, 0x);

And for these it can actually test all 4 possible 2 bit elements,
so say 0x3021

> +}
> +
> +/*
> +** test_8:
> +**...
> +**   mov r[0-9]+, #52428 @ movhi
> +**...
> +*/
> +uint8x16_t test_8() {
> +  return vdupq_m_n_u8(vdupq_n_u8(0), 0, 0x);

and here use some random pattern.

BTW, the patch is ok for 14.1 if it is approved and committed today
(so that it can be cherry-picked tomorrow morning at latest to the branch).

Jakub

Re: [PATCH] rust: Add rust.install-dvi and rust.install-html rules

[Arthur Cohen]

Thanks Christophe!

I've added your patch as part of a documentation pull-request I'm adding 
to our dev repo: https://github.com/Rust-GCC/gccrs/pull/2966


It'll be upstreamed with the next batch of commits we send, as soon as 
trunk reopens fully for 15.1.


Best,

Arthur

On 4/4/24 18:27, Christophe Lyon wrote:

rust has the (empty) rust.dvi and rust.html rules, but lacks the
(empty) rust.install-dvi and rust.install-html ones.

2024-04-04  Christophe Lyon  

gcc/rust/
* Make-lang.in (rust.install-dvi, rust.install-html): New rules.
---
  gcc/rust/Make-lang.in | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/gcc/rust/Make-lang.in b/gcc/rust/Make-lang.in
index 4d646018792..4d73412739d 100644
--- a/gcc/rust/Make-lang.in
+++ b/gcc/rust/Make-lang.in
@@ -342,6 +342,8 @@ selftest-rust-valgrind: $(RUST_SELFTEST_DEPS)
  # should have dependencies on info files that should be installed.
  rust.install-info:
  
+rust.install-dvi:

+rust.install-html:
  rust.install-pdf:
  
  # Install man pages for the front end. This target should ignore errors.

[PATCH] regalloc: Ignore '^' in early costing [PR114766]

[Wilco Dijkstra]

According to documentation, '^' should only have an effect during reload.
However ira-costs.cc treats it in the same way as '?' during early costing.
As a result using '^' can accidentally disable valid alternatives and cause
significant regressions (see PR114741).  Avoid this by ignoring '^' during
costing.

Passes bootstrap and regress, OK for commit?

gcc:
PR rtl-optimization/114766
* ira-costs.cc (record_reg_classes): Ignore '^' during costing.

---

diff --git a/gcc/ira-costs.cc b/gcc/ira-costs.cc
index 
c86c5a16563aeefac9d4fa72839bee8d95409f4b..04d2f21b023f3456ba6f8c16c2418d7313965b2f
 100644
--- a/gcc/ira-costs.cc
+++ b/gcc/ira-costs.cc
@@ -771,10 +771,6 @@ record_reg_classes (int n_alts, int n_ops, rtx *ops,
  c = *++p;
  break;
 
-   case '^':
- alt_cost += 2;
- break;
-
case '?':
  alt_cost += 2;
  break;

RE: [PATCH v2] RISC-V: Refine the condition for add additional vars in RVV cost model

[Demin Han]

Hi, Juzhe.

Thanks for reminding.
I did regression again and committed.

Regard,
Demin
From: juzhe.zh...@rivai.ai 
Sent: 2024年4月29日 13:10
To: Demin Han ; gcc-patches 

Cc: kito.cheng ; pan2.li ; jeffreyalaw 
; Robin Dapp 
Subject: Re: [PATCH v2] RISC-V: Refine the condition for add additional vars in 
RVV cost model

Hi, Han.

GCC 14 is branch out. You can commit it to trunk (GCC 15).


juzhe.zh...@rivai.ai

From: demin.han
Date: 2024-04-02 16:30
To: gcc-patches
CC: juzhe.zhong; 
kito.cheng; pan2.li; 
jeffreyalaw; rdapp.gcc
Subject: [PATCH v2] RISC-V: Refine the condition for add additional vars in RVV 
cost model
The adjacent_dr_p is sufficient and unnecessary condition for contiguous access.
So unnecessary live-ranges are added and result in smaller LMUL.

This patch uses MEMORY_ACCESS_TYPE as condition and constrains segment
load/store.

Tested on RV64 and no regression.

PR target/114506

gcc/ChangeLog:

* config/riscv/riscv-vector-costs.cc (non_contiguous_memory_access_p): Rename
(need_additional_vector_vars_p): Rename and refine condition

gcc/testsuite/ChangeLog:

* gcc.dg/vect/costmodel/riscv/rvv/pr114506.c: New test.

Signed-off-by: demin.han 
mailto:demin@starfivetech.com>>
---
V2 changes:
  1. remove max_point issue
  2. minor change in commit message

gcc/config/riscv/riscv-vector-costs.cc| 23 ---
.../vect/costmodel/riscv/rvv/pr114506.c   | 23 +++
2 files changed, 38 insertions(+), 8 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/pr114506.c

diff --git a/gcc/config/riscv/riscv-vector-costs.cc 
b/gcc/config/riscv/riscv-vector-costs.cc
index f462c272a6e..484196b15b4 100644
--- a/gcc/config/riscv/riscv-vector-costs.cc
+++ b/gcc/config/riscv/riscv-vector-costs.cc
@@ -563,14 +563,24 @@ get_store_value (gimple *stmt)
 return gimple_assign_rhs1 (stmt);
}
-/* Return true if it is non-contiguous load/store.  */
+/* Return true if addtional vector vars needed.  */
static bool
-non_contiguous_memory_access_p (stmt_vec_info stmt_info)
+need_additional_vector_vars_p (stmt_vec_info stmt_info)
{
   enum stmt_vec_info_type type
 = STMT_VINFO_TYPE (vect_stmt_to_vectorize (stmt_info));
-  return ((type == load_vec_info_type || type == store_vec_info_type)
-   && !adjacent_dr_p (STMT_VINFO_DATA_REF (stmt_info)));
+  if (type == load_vec_info_type || type == store_vec_info_type)
+{
+  if (STMT_VINFO_GATHER_SCATTER_P (stmt_info)
+   && STMT_VINFO_MEMORY_ACCESS_TYPE (stmt_info) == VMAT_GATHER_SCATTER)
+ return true;
+
+  machine_mode mode = TYPE_MODE (STMT_VINFO_VECTYPE (stmt_info));
+  int lmul = riscv_get_v_regno_alignment (mode);
+  if (DR_GROUP_SIZE (stmt_info) * lmul > RVV_M8)
+ return true;
+}
+  return false;
}
/* Return the LMUL of the current analysis.  */
@@ -739,10 +749,7 @@ update_local_live_ranges (
  stmt_vec_info stmt_info = vinfo->lookup_stmt (gsi_stmt (si));
  enum stmt_vec_info_type type
= STMT_VINFO_TYPE (vect_stmt_to_vectorize (stmt_info));
-   if (non_contiguous_memory_access_p (stmt_info)
-   /* LOAD_LANES/STORE_LANES doesn't need a perm indice.  */
-   && STMT_VINFO_MEMORY_ACCESS_TYPE (stmt_info)
-!= VMAT_LOAD_STORE_LANES)
+   if (need_additional_vector_vars_p (stmt_info))
{
  /* For non-adjacent load/store STMT, we will potentially
convert it into:
diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/pr114506.c 
b/gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/pr114506.c
new file mode 100644
index 000..a88d24b2d2d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/pr114506.c
@@ -0,0 +1,23 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d -O3 -ftree-vectorize 
-mrvv-max-lmul=dynamic -fdump-tree-vect-details" } */
+
+float a[32000], b[32000], c[32000], d[32000];
+float aa[256][256], bb[256][256], cc[256][256];
+
+void
+s2275 ()
+{
+  for (int i = 0; i < 256; i++)
+{
+  for (int j = 0; j < 256; j++)
+ {
+   aa[j][i] = aa[j][i] + bb[j][i] * cc[j][i];
+ }
+  a[i] = b[i] + c[i] * d[i];
+}
+}
+
+/* { dg-final { scan-assembler-times {e32,m8} 1 } } */
+/* { dg-final { scan-assembler-not {e32,m4} } } */
+/* { dg-final { scan-assembler-not {csrr} } } */
+/* { dg-final { scan-tree-dump-not "Preferring smaller LMUL loop because it 
has unexpected spills" "vect" } } */
--
2.44.0

Re: [Patch, fortran] PR114859 - [14/15 Regression] Seeing new segmentation fault in same_type_as since r14-9752

[Paul Richard Thomas]

Hi Mikael,

Thank you for the review and, in particular, the corrections in the fortran
ChangeLog. Unfortunately, both of us missed the systematically wrong PR
number. The commit was made to 15-branch with the wrong number throughout,
which I will correct tomorrow. This, however, has made a bit more work for
Jakub, which I have communicated to him through the PR. It is what comes of
working in a hurry, late at night.

The good news is that it fixes the original problem, which showed up
in Parallel Sparse BLAS is fixed.

Best regards

Paul


On Mon, 29 Apr 2024 at 09:34, Mikael Morin  wrote:

> Hello,
>
> Le 28/04/2024 à 23:37, Paul Richard Thomas a écrit :
> > Hi All,
> >
> > Could this be looked at quickly? The timing of this regression is more
> > than a little embarrassing on the eve of the 14.1 release. The testcase
> > and the comment in gfc_trans_class_init_assign explain what this problem
> > is all about and how the patch fixes it.
> >
> > OK for 15-branch and backporting to 14-branch (hopefully to the RC as
> well)?
> >
> > Paul
> >
> > Fortran: Fix regression caused by r14-9752 [PR114959]
> >
> > 2024-04-28  Paul Thomas  mailto:pa...@gcc.gnu.org>>
>
> You can drop the mailto:… thing. ;-)
>
> > gcc/fortran
> > PR fortran/114959
> > * trans-expr.cc (gfc_trans_class_init_assign): Return NULL_TREE
> > if the default initializer has all NULL fields. Guard this
> > by a requirement that the code be EXEC_INIT_ASSIGN and that the
> > object be an INTENT_IN dummy.
>
> In the patch, the code requirement is different from EXEC_ALLOCATE and
> the intent is INTENT_OUT, not INTENT_IN.
>
> > * trans-stmt.cc (gfc_trans_allocate): Change the initializer
> > code for allocate with mold to EXEC_ASSIGN to allow initializer
> > with all NULL fields..
>
> In the patch it's EXEC_ALLOCATE, not EXEC_ASSIGN.
>
> OK for master with the ChangeLog fixed.
> For 14, you need release manager approval, I think.
> Thanks for the quick fix.
>
> Mikael
>

Re: [Patch, fortran] PR114859 - [14/15 Regression] Seeing new segmentation fault in same_type_as since r14-9752

[Jakub Jelinek]

On Sun, Apr 28, 2024 at 10:37:06PM +0100, Paul Richard Thomas wrote:
> Could this be looked at quickly? The timing of this regression is more than
> a little embarrassing on the eve of the 14.1 release. The testcase and the
> comment in gfc_trans_class_init_assign explain what this problem is all
> about and how the patch fixes it.
> 
> OK for 15-branch and backporting to 14-branch (hopefully to the RC as well)?

The patch is ok for 14.1 if cherry-picked today.

Jakub

[PATCH v4 2/2] c++: Fix instantiation of imported temploid friends [PR114275]

[Nathaniel Shead]

On Fri, Apr 26, 2024 at 09:16:40PM -0400, Jason Merrill wrote:
> On 4/19/24 09:29, Nathaniel Shead wrote:
> > On Fri, Apr 19, 2024 at 12:14:06PM +1000, Nathaniel Shead wrote:
> > > On Wed, Apr 17, 2024 at 02:02:21PM -0400, Patrick Palka wrote:
> > > > On Mon, 15 Apr 2024, Nathaniel Shead wrote:
> > > > 
> > > > > I'm not a huge fan of always streaming 'imported_temploid_friends' for
> > > > > all decls, but I don't think it adds much performance cost over 
> > > > > adding a
> > > > > new flag to categorise decls that might be marked as such.
> > > > 
> > > > IIUC this value is going to be almost always null which is encoded as a
> > > > single 0 byte, which should be fast to stream.  But I wonder how much
> > > > larger  gets?  Can we get away with streaming this value
> > > > only for TEMPLATE_DECLs?
> > > 
> > > Yes, it should either just be a 0 byte or an additional backref
> > > somewhere, which will likely also be small. On my system it increases
> > > the size by 0.26%, from 31186800 bytes to 31268672.
> > > 
> > > But I've just found that this patch has a bug anyway, in that it doesn't
> > > correctly dedup if the friend types are instantiated in two separate
> > > modules that are then both imported.  I'll see what I need to do to fix
> > > this which may influence what we need to stream here.
> > > 
> > 
> > Here's an updated version of the patch that fixes this. Also changed to
> > only stream when 'inner' is either TYPE_DECL or FUNCTION_DECL, which
> > cuts the size of  down a bit to 31246992 (0.19% growth).
> > 
> > Another alternative would be to add another boolean flag at the top of
> > 'decl_value' and branch on that; that would make use of the bitpacking
> > logic and probably cut down on the size further.  (I haven't measured
> > this yet though.)
> > 
> > Bootstrapped and regtested (so far just dg.exp and modules.exp) on
> > x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds?
> > 
> > -- >8 --
> > 
> > This patch fixes a number of issues with the handling of temploid friend
> > declarations.
> > 
> > The primary issue is that instantiations of friend declarations should
> > attach the declaration to the same module as the befriending class, by
> > [module.unit] p7.1 and [temp.friend] p2; this could be a different
> > module from the current TU, and so needs special handling.
> 
> This is only an issue for DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P, right?

It's true for any friend instantiations, including e.g. friend
functions, not just template class friends.

> 
> Hmm, CWG2588 should probably touch [module.unit]/7.1 as well as
> [basic.link].
> 
> > The other main issue here is that we can't assume that just because name
> > lookup didn't find a definition for a hidden template class, it doesn't
> > mean that it doesn't exist: it could be a non-exported entity that we've
> > nevertheless streamed in from an imported module.  We need to ensure
> > that when instantiating friend classes that we return the same TYPE_DECL
> > that we got from our imports, otherwise we will get later issues with
> > 'duplicate_decls' (rightfully) complaining that they're different.
> 
> Tricksy.
> 
> > This doesn't appear necessary for functions due to the existing name
> > lookup handling already finding these hidden declarations.
> > 
> > PR c++/105320
> > PR c++/114275
> > 
> > gcc/cp/ChangeLog:
> > 
> > * cp-tree.h (propagate_defining_module): Declare.
> > (lookup_imported_hidden_friend): Declare.
> > * decl.cc (duplicate_decls): Also check if hidden declarations
> > can be redeclared in this module.
> > * module.cc (imported_temploid_friends): New map.
> > (init_modules): Initialize it.
> > (trees_out::decl_value): Write it; don't consider imported
> > temploid friends as attached to this module.
> > (trees_in::decl_value): Read it.
> > (depset::hash::add_specializations): Don't treat instantiations
> > of a friend type as a specialisation.
> > (get_originating_module_decl): Follow the owning decl for an
> > imported temploid friend.
> > (propagate_defining_module): New function.
> > * name-lookup.cc (lookup_imported_hidden_friend): New function.
> > * pt.cc (tsubst_friend_function): Propagate defining module for
> > new friend functions.
> > (tsubst_friend_class): Lookup imported hidden friends. Check
> > for valid redeclaration. Propagate defining module for new
> > friend classes.
> > 
> > diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
> > index aa66da4829d..56752cf6872 100644
> > --- a/gcc/cp/decl.cc
> > +++ b/gcc/cp/decl.cc
> > @@ -2276,30 +2276,34 @@ duplicate_decls (tree newdecl, tree olddecl, bool 
> > hiding, bool was_hidden)
> > if (modules_p ()
> > && TREE_CODE (CP_DECL_CONTEXT (olddecl)) == NAMESPACE_DECL
> > -  && TREE_CODE (olddecl) != NAMESPACE_DECL
> > -  && !hiding)
> > +  && TREE_CODE (olddecl) != NAMESPACE_DECL)
> >   {
> > if (!module_may_redeclare 

Re: [PATCH] libstdc++: Implement ranges::concat_view from P2542R7

[Jonathan Wakely]

On Mon, 22 Apr 2024 at 22:43, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?  More tests
> are needed but I figured I'd submit this now for possible consideration into
> GCC 14 since we're getting close to release..  All changes are confined to
> C++26.

OK for trunk. Maybe we can backport it for 14.2 later, but not now.
Sorry for the review being slow.


>
> -- >8 --
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/version.def (ranges_concat): Define.
> * include/bits/version.h: Regenerate.
> * include/std/ranges (__detail::__concat_reference_t): Define
> for C++26.
> (__detail::__concat_value_t): Likewise.
> (__detail::__concat_rvalue_reference_t): Likewise.
> (__detail::__concat_indirectly_readable_impl): Likewise.
> (__detail::__concat_indirectly_readable): Likewise.
> (__detail::__concatable): Likewise.
> (__detail::__all_but_last_common): Likewise.
> (__detail::__concat_is_random_access): Likewise.
> (__detail::__concat_is_bidirectional): Likewise.
> (__detail::__last_is_common): Likewise.
> (concat_view): Likewise.
> (__detail::__concat_view_iter_cat): Likewise.
> (concat_view::iterator): Likewise.
> (views::__detail::__can_concat_view): Likewise.
> (views::_Concat, views::concat): Likewise.
> * testsuite/std/ranges/concat/1.cc: New test.
> ---
>  libstdc++-v3/include/bits/version.def |   8 +
>  libstdc++-v3/include/bits/version.h   |  10 +
>  libstdc++-v3/include/std/ranges   | 584 ++
>  libstdc++-v3/testsuite/std/ranges/concat/1.cc |  61 ++
>  4 files changed, 663 insertions(+)
>  create mode 100644 libstdc++-v3/testsuite/std/ranges/concat/1.cc
>
> diff --git a/libstdc++-v3/include/bits/version.def 
> b/libstdc++-v3/include/bits/version.def
> index 5c0477fb61e..af13090c094 100644
> --- a/libstdc++-v3/include/bits/version.def
> +++ b/libstdc++-v3/include/bits/version.def
> @@ -1796,6 +1796,14 @@ ftms = {
>};
>  };
>
> +ftms = {
> +  name = ranges_concat;
> +  values = {
> +v = 202403;
> +cxxmin = 26;
> +  };
> +};
> +
>  // Standard test specifications.
>  stds[97] = ">= 199711L";
>  stds[03] = ">= 199711L";
> diff --git a/libstdc++-v3/include/bits/version.h 
> b/libstdc++-v3/include/bits/version.h
> index 65e708c73fb..1f27bfe050d 100644
> --- a/libstdc++-v3/include/bits/version.h
> +++ b/libstdc++-v3/include/bits/version.h
> @@ -2003,4 +2003,14 @@
>  #endif /* !defined(__cpp_lib_to_string) && defined(__glibcxx_want_to_string) 
> */
>  #undef __glibcxx_want_to_string
>
> +#if !defined(__cpp_lib_ranges_concat)
> +# if (__cplusplus >  202302L)
> +#  define __glibcxx_ranges_concat 202403L
> +#  if defined(__glibcxx_want_all) || defined(__glibcxx_want_ranges_concat)
> +#   define __cpp_lib_ranges_concat 202403L
> +#  endif
> +# endif
> +#endif /* !defined(__cpp_lib_ranges_concat) && 
> defined(__glibcxx_want_ranges_concat) */
> +#undef __glibcxx_want_ranges_concat
> +
>  #undef __glibcxx_want_all
> diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
> index afce818376b..28a39bf6f34 100644
> --- a/libstdc++-v3/include/std/ranges
> +++ b/libstdc++-v3/include/std/ranges
> @@ -55,6 +55,7 @@
>  #define __glibcxx_want_ranges_as_const
>  #define __glibcxx_want_ranges_as_rvalue
>  #define __glibcxx_want_ranges_cartesian_product
> +#define __glibcxx_want_ranges_concat
>  #define __glibcxx_want_ranges_chunk
>  #define __glibcxx_want_ranges_chunk_by
>  #define __glibcxx_want_ranges_enumerate
> @@ -9514,6 +9515,589 @@ namespace __detail
>  } // namespace ranges
>  #endif // __cpp_lib_ranges_to_container
>
> +#if __cpp_lib_ranges_concat // C++ >= C++26
> +namespace ranges
> +{
> +  namespace __detail
> +  {
> +template
> +  using __concat_reference_t = 
> common_reference_t...>;
> +
> +template
> +  using __concat_value_t = common_type_t...>;
> +
> +template
> +  using __concat_rvalue_reference_t
> +   = common_reference_t...>;
> +
> +template
> +  concept __concat_indirectly_readable_impl = requires (const _It __it) {
> +   { *__it } -> convertible_to<_Ref>;
> +   { ranges::iter_move(__it) } -> convertible_to<_RRef>;
> +  };
> +
> +template
> +  concept __concat_indirectly_readable
> +   = common_reference_with<__concat_reference_t<_Rs...>&&, 
> __concat_value_t<_Rs...>&>
> + && common_reference_with<__concat_reference_t<_Rs...>&&,
> +  __concat_rvalue_reference_t<_Rs...>&&>
> + && common_reference_with<__concat_rvalue_reference_t<_Rs...>&&,
> +  __concat_value_t<_Rs...> const&>
> + && (__concat_indirectly_readable_impl<__concat_reference_t<_Rs...>,
> +   
> __concat_rvalue_reference_t<_Rs...>,
> +   

Re: [PATCH] ppc: testsuite: pr79004 needs -mlong-double-128

[Kewen.Lin]

on 2024/4/29 15:20, Alexandre Oliva wrote:
> On Apr 28, 2024, "Kewen.Lin"  wrote:
> 
>> OK, from this perspective IMHO it seems more clear to adopt xfail
>> with effective target long_double_64bit?
> 
> That's effective target is quite broken, alas.  I doubt it's used
> anywhere: it calls an undefined proc, and its memcmp call seems to have
> the size cut from the 128-bit functions.  (a patchlet that
> fixes these most glaring issues is below)
> 
> Furthermore, it doesn't really work.  Since it adds -mlong-double-64 for
> the effective target test, it overrides the default, so it sort of
> always passes, even on a 128-bit long double target.  But since the test
> itself doesn't add that option, any xfails on long_double_64bit would be
> flagged as XPASS.
> 
> There's no effective target test for 64-bit long double that doesn't
> override the default, so we'd have to add one.  Alas, the natural name
> for it is the one that's taken with overriding behavior, and the current
> option-overriding tests, that need to be used along with the
> corresponding add-options in testcases, might benefit from a renaming to
> make them fit the already-established (?) naming standards.  Yuck.
> 

Oops, it's really out of my expectation, I just noticed that no test cases
are using this effective target and the commit r12-3151-g4c5d76a655b9ab
contributing this even doesn't adopt it.  Thanks for catching this and sorry
that I didn't check it before suggesting it, I think we can aggressively
drop this effective target instead to avoid any possible confusion.

CC Mike for this.

How about the generic one "longdouble64"?  I did a grep and found it has one
use, I'd expect it can work here. :)

gcc/testsuite//gcc.target/powerpc/pr99708.c:/* { dg-xfail-run-if "unsupported 
type __ibm128 with long-double-64" { longdouble64 } } */

BR,
Kewen

> 
> diff --git a/gcc/testsuite/lib/target-supports.exp 
> b/gcc/testsuite/lib/target-supports.exp
> index 182d80129de9b..603da25c97d67 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -2961,12 +2961,12 @@ proc check_effective_target_long_double_64bit { } {
> /* eliminate removing volatile cast warning.  */
> a2 = a;
> b2 = b;
> -   if (memcmp (, , 16) != 0)
> +   if (memcmp (, , 8) != 0)
>   return 1;
> sprintf (buffer, "%lg", b);
> return strcmp (buffer, "3") != 0;
>   }
> -}  [add_options_for_ppc_long_double_override_64bit ""]]
> +}  [add_options_for_long_double_64bit ""]]
>  }
>  
>  # Return the appropriate options to specify that long double uses the IEEE
> 
> 

Re: [PATCH] adjust vectorization expectations for ppc costmodel 76b

[Kewen.Lin]

on 2024/4/29 14:28, Alexandre Oliva wrote:
> On Apr 28, 2024, "Kewen.Lin"  wrote:
> 
>> Nit: Maybe add a prefix "testsuite: ".
> 
> ACK
> 
>>>
>>> From: Kewen Lin 
> 
>> Thanks, you can just drop this.  :)
> 
> I've turned it into Co-Authored-By, since you insist.
> 
> But unfortunately with the patch it still fails when testing for
> -mcpu=power7 on ppc64le-linux-gnu: it does vectorize the loop with 13
> iterations.  We need 16 iterations, as in an earlier version of this
> test, for it to pass for -mcpu=power7, but then it doesn't pass for
> -mcpu=power6.
> 
> It looks like we're going to have to adjust the expectations.
> 

I had a look at the failure, it's due to that "vect_no_align" is
evaluated as true unexpectedly.

  "selector_expression: ` vect_no_align || {! vector_alignment_reachable} ' 1"

Currently powerpc* checks check_p8vector_hw_available, ppc64le-linux-gnu
has at least Power8 support (that is testing machine supports p8vector run),
so it concludes vect_no_align is true.

proc check_effective_target_vect_no_align { } {
return [check_cached_effective_target_indexed vect_no_align {
  expr { [istarget mipsisa64*-*-*]
 || [istarget mips-sde-elf]
 || [istarget sparc*-*-*]
 || [istarget ia64-*-*]
 || [check_effective_target_arm_vect_no_misalign]
 || ([istarget powerpc*-*-*] && [check_p8vector_hw_available])

I'll fix this in PR113535 which was filed previously for visiting powerpc
specific check in these vect* effective targets.  If the testing just goes
with native cpu type, this issue will become invisible.  I think you can
still push the patch as the testing just exposes another issue.

BR,
Kewen

Re: [Patch, fortran] PR114859 - [14/15 Regression] Seeing new segmentation fault in same_type_as since r14-9752

[Mikael Morin]

Hello,

Le 28/04/2024 à 23:37, Paul Richard Thomas a écrit :

Hi All,

Could this be looked at quickly? The timing of this regression is more 
than a little embarrassing on the eve of the 14.1 release. The testcase 
and the comment in gfc_trans_class_init_assign explain what this problem 
is all about and how the patch fixes it.


OK for 15-branch and backporting to 14-branch (hopefully to the RC as well)?

Paul

Fortran: Fix regression caused by r14-9752 [PR114959]

2024-04-28  Paul Thomas  mailto:pa...@gcc.gnu.org>>


You can drop the mailto:… thing. ;-)


gcc/fortran
PR fortran/114959
* trans-expr.cc (gfc_trans_class_init_assign): Return NULL_TREE
if the default initializer has all NULL fields. Guard this
by a requirement that the code be EXEC_INIT_ASSIGN and that the
object be an INTENT_IN dummy.


In the patch, the code requirement is different from EXEC_ALLOCATE and 
the intent is INTENT_OUT, not INTENT_IN.



* trans-stmt.cc (gfc_trans_allocate): Change the initializer
code for allocate with mold to EXEC_ASSIGN to allow initializer
with all NULL fields..


In the patch it's EXEC_ALLOCATE, not EXEC_ASSIGN.

OK for master with the ChangeLog fixed.
For 14, you need release manager approval, I think.
Thanks for the quick fix.

Mikael

RE: [PATCH v2] RISC-V: Fix ICE for legitimize move on subreg const_poly_int [PR114885]

[Li, Pan2]

Committed to trunk, thanks Kito.

Backported to releases/gcc-14, thanks Jakub.

Pan

-Original Message-
From: Jakub Jelinek  
Sent: Monday, April 29, 2024 3:53 PM
To: Kito Cheng 
Cc: Li, Pan2 ; Jeff Law ; 
gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai
Subject: Re: [PATCH v2] RISC-V: Fix ICE for legitimize move on subreg 
const_poly_int [PR114885]

On Mon, Apr 29, 2024 at 03:47:05PM +0800, Kito Cheng wrote:
> Hi Jakub:
> 
> Is this OK for GCC 14 branch? it's fix ICE on valid code, thanks :)

Ok.

Jakub

Re: [PATCH] libstdc++: Update Solaris baselines for GCC 14.0

[Jakub Jelinek]

On Mon, Apr 29, 2024 at 10:07:42AM +0200, Rainer Orth wrote:
> This patch updates the Solaris baselines for the GLIBCXX_3.4.33 version
> added in GCC 14.0.
> 
> Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (32 and 64-bit
> each), together with the GLIBCXX_3.4.32 update, on both gcc-14 branch
> and trunk.
> 
> Ok for and gcc-14 branch and trunk?

Ok for both.

> 2024-04-28  Rainer Orth  
> 
>   libstdc++-v3:
>   * config/abi/post/i386-solaris/baseline_symbols.txt: Regenerate.
>   * config/abi/post/i386-solaris/amd64/baseline_symbols.txt:
>   Likewise.
>   * config/abi/post/sparc-solaris/baseline_symbols.txt: Likewise.
>   * config/abi/post/sparc-solaris/sparcv9/baseline_symbols.txt:
>   Likewise.

Jakub

Re: [PATCH] libstdc++: Update Solaris baselines for GCC 13.2

[Jakub Jelinek]

On Mon, Apr 29, 2024 at 10:02:56AM +0200, Rainer Orth wrote:
> This patch updates the Solaris baselines for the GLIBCXX_3.4.32 version
> added in GCC 13.2.
> 
> Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (32 and 64-bit
> each) on the gcc-13 branch and (together with the GLIBCXX_3.4.33 update)
> on both gcc-14 branch and trunk.
> 
> Ok for all of gcc-13 and gcc-14 branches and trunk?

I think Solaris shouldn't have the _ZNSt8ios_base4InitC1Ev @@GLIBCXX_3.4.32
export, so this LGTM, for all 3 branches.

> 2024-04-28  Rainer Orth  
> 
>   libstdc++-v3:
>   * config/abi/post/i386-solaris/baseline_symbols.txt: Regenerate.
>   * config/abi/post/i386-solaris/amd64/baseline_symbols.txt:
>   Likewise.
>   * config/abi/post/sparc-solaris/baseline_symbols.txt: Likewise.
>   * config/abi/post/sparc-solaris/sparcv9/baseline_symbols.txt:
>   Likewise.

Jakub

[PATCH][gcc-12] LoongArch: Fix eh_return epilogue for normal returns.

[Lulu Cheng]

From: Yang Yujie 

On LoongArch, the regitsters $r4 - $r7 (EH_RETURN_DATA_REGNO) will be saved
and restored in the function prologue and epilogue if the given function calls
__builtin_eh_return.  This causes the return value to be overwritten on normal
return paths and breaks a rare case of libgcc's _Unwind_RaiseException.

gcc/ChangeLog:

PR target/114848
* config/loongarch/loongarch.cc: Do not restore the saved eh_return
data registers ($r4-$r7) for a normal return of a function that calls
__builtin_eh_return elsewhere.
* config/loongarch/loongarch-protos.h: Same.
* config/loongarch/loongarch.md: Same.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/eh_return-normal-return.c: New test.

(cherry picked from commit 4b421728289e6f1caa0dfaa953a11698ab95d37d)
---
 gcc/config/loongarch/loongarch-protos.h   |  2 +-
 gcc/config/loongarch/loongarch.cc | 35 -
 gcc/config/loongarch/loongarch.md | 23 ++-
 .../loongarch/eh_return-normal-return.c   | 38 +++
 4 files changed, 85 insertions(+), 13 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/eh_return-normal-return.c

diff --git a/gcc/config/loongarch/loongarch-protos.h 
b/gcc/config/loongarch/loongarch-protos.h
index 2144c2421ed..8af82ffaa20 100644
--- a/gcc/config/loongarch/loongarch-protos.h
+++ b/gcc/config/loongarch/loongarch-protos.h
@@ -47,7 +47,7 @@ enum loongarch_symbol_type {
 extern rtx loongarch_emit_move (rtx, rtx);
 extern HOST_WIDE_INT loongarch_initial_elimination_offset (int, int);
 extern void loongarch_expand_prologue (void);
-extern void loongarch_expand_epilogue (bool);
+extern void loongarch_expand_epilogue (int);
 extern bool loongarch_can_use_return_insn (void);
 
 extern bool loongarch_symbolic_constant_p (rtx, enum loongarch_symbol_type *);
diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc
index 33b1919e7a3..a0e11f2fc66 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -1008,7 +1008,8 @@ loongarch_save_restore_reg (machine_mode mode, int regno, 
HOST_WIDE_INT offset,
 
 static void
 loongarch_for_each_saved_reg (HOST_WIDE_INT sp_offset,
- loongarch_save_restore_fn fn)
+ loongarch_save_restore_fn fn,
+ bool skip_eh_data_regs_p)
 {
   HOST_WIDE_INT offset;
 
@@ -1017,7 +1018,15 @@ loongarch_for_each_saved_reg (HOST_WIDE_INT sp_offset,
   for (int regno = GP_REG_FIRST; regno <= GP_REG_LAST; regno++)
 if (BITSET_P (cfun->machine->frame.mask, regno - GP_REG_FIRST))
   {
-   loongarch_save_restore_reg (word_mode, regno, offset, fn);
+   /* Special care needs to be taken for $r4-$r7 (EH_RETURN_DATA_REGNO)
+  when returning normally from a function that calls
+  __builtin_eh_return.  In this case, these registers are saved but
+  should not be restored, or the return value may be clobbered.  */
+
+   if (!(skip_eh_data_regs_p
+ && GP_ARG_FIRST <= regno && regno < GP_ARG_FIRST + 4))
+ loongarch_save_restore_reg (word_mode, regno, offset, fn);
+
offset -= UNITS_PER_WORD;
   }
 
@@ -1289,7 +1298,7 @@ loongarch_expand_prologue (void)
GEN_INT (-step1));
   RTX_FRAME_RELATED_P (emit_insn (insn)) = 1;
   size -= step1;
-  loongarch_for_each_saved_reg (size, loongarch_save_reg);
+  loongarch_for_each_saved_reg (size, loongarch_save_reg, false);
 }
 
 
@@ -1336,11 +1345,13 @@ loongarch_can_use_return_insn (void)
   return reload_completed && cfun->machine->frame.total_size == 0;
 }
 
-/* Expand an "epilogue" or "sibcall_epilogue" pattern; SIBCALL_P
-   says which.  */
+/* Expand function epilogue using the following insn patterns:
+   "epilogue"(style == NORMAL_RETURN)
+   "sibcall_epilogue" (style == SIBCALL_RETURN)
+   "eh_return"   (style == EXCEPTION_RETURN) */
 
 void
-loongarch_expand_epilogue (bool sibcall_p)
+loongarch_expand_epilogue (int style)
 {
   /* Split the frame into two.  STEP1 is the amount of stack we should
  deallocate before restoring the registers.  STEP2 is the amount we
@@ -1357,7 +1368,8 @@ loongarch_expand_epilogue (bool sibcall_p)
   bool need_barrier_p
 = (get_frame_size () + cfun->machine->frame.arg_pointer_offset) != 0;
 
-  if (!sibcall_p && loongarch_can_use_return_insn ())
+  /* Handle simple returns.  */
+  if (style == NORMAL_RETURN && loongarch_can_use_return_insn ())
 {
   emit_jump_insn (gen_return ());
   return;
@@ -1433,7 +1445,9 @@ loongarch_expand_epilogue (bool sibcall_p)
 
   /* Restore the registers.  */
   loongarch_for_each_saved_reg (frame->total_size - step2,
-   loongarch_restore_reg);
+   loongarch_restore_reg,
+   crtl->calls_eh_return
+ 

[PATCH][gcc-13] LoongArch: Fix eh_return epilogue for normal returns.

[Lulu Cheng]

From: Yang Yujie 

On LoongArch, the regitsters $r4 - $r7 (EH_RETURN_DATA_REGNO) will be saved
and restored in the function prologue and epilogue if the given function calls
__builtin_eh_return.  This causes the return value to be overwritten on normal
return paths and breaks a rare case of libgcc's _Unwind_RaiseException.

gcc/ChangeLog:

PR target/114848
* config/loongarch/loongarch.cc: Do not restore the saved eh_return
data registers ($r4-$r7) for a normal return of a function that calls
__builtin_eh_return elsewhere.
* config/loongarch/loongarch-protos.h: Same.
* config/loongarch/loongarch.md: Same.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/eh_return-normal-return.c: New test.

(cherry picked from commit 4b421728289e6f1caa0dfaa953a11698ab95d37d)
---
 gcc/config/loongarch/loongarch-protos.h   |  2 +-
 gcc/config/loongarch/loongarch.cc | 35 -
 gcc/config/loongarch/loongarch.md | 23 ++-
 .../loongarch/eh_return-normal-return.c   | 38 +++
 4 files changed, 85 insertions(+), 13 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/eh_return-normal-return.c

diff --git a/gcc/config/loongarch/loongarch-protos.h 
b/gcc/config/loongarch/loongarch-protos.h
index 35cc77c7367..0f608ee5179 100644
--- a/gcc/config/loongarch/loongarch-protos.h
+++ b/gcc/config/loongarch/loongarch-protos.h
@@ -60,7 +60,7 @@ enum loongarch_symbol_type {
 extern rtx loongarch_emit_move (rtx, rtx);
 extern HOST_WIDE_INT loongarch_initial_elimination_offset (int, int);
 extern void loongarch_expand_prologue (void);
-extern void loongarch_expand_epilogue (bool);
+extern void loongarch_expand_epilogue (int);
 extern bool loongarch_can_use_return_insn (void);
 
 extern bool loongarch_symbolic_constant_p (rtx, enum loongarch_symbol_type *);
diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc
index f47a5fc2ad7..2238858cd6a 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -1012,7 +1012,8 @@ loongarch_save_restore_reg (machine_mode mode, int regno, 
HOST_WIDE_INT offset,
 
 static void
 loongarch_for_each_saved_reg (HOST_WIDE_INT sp_offset,
- loongarch_save_restore_fn fn)
+ loongarch_save_restore_fn fn,
+ bool skip_eh_data_regs_p)
 {
   HOST_WIDE_INT offset;
 
@@ -1021,7 +1022,15 @@ loongarch_for_each_saved_reg (HOST_WIDE_INT sp_offset,
   for (int regno = GP_REG_FIRST; regno <= GP_REG_LAST; regno++)
 if (BITSET_P (cfun->machine->frame.mask, regno - GP_REG_FIRST))
   {
-   loongarch_save_restore_reg (word_mode, regno, offset, fn);
+   /* Special care needs to be taken for $r4-$r7 (EH_RETURN_DATA_REGNO)
+  when returning normally from a function that calls
+  __builtin_eh_return.  In this case, these registers are saved but
+  should not be restored, or the return value may be clobbered.  */
+
+   if (!(skip_eh_data_regs_p
+ && GP_ARG_FIRST <= regno && regno < GP_ARG_FIRST + 4))
+ loongarch_save_restore_reg (word_mode, regno, offset, fn);
+
offset -= UNITS_PER_WORD;
   }
 
@@ -1290,7 +1299,7 @@ loongarch_expand_prologue (void)
GEN_INT (-step1));
   RTX_FRAME_RELATED_P (emit_insn (insn)) = 1;
   size -= step1;
-  loongarch_for_each_saved_reg (size, loongarch_save_reg);
+  loongarch_for_each_saved_reg (size, loongarch_save_reg, false);
 }
 
   /* Set up the frame pointer, if we're using one.  */
@@ -1375,11 +1384,13 @@ loongarch_can_use_return_insn (void)
   return reload_completed && cfun->machine->frame.total_size == 0;
 }
 
-/* Expand an "epilogue" or "sibcall_epilogue" pattern; SIBCALL_P
-   says which.  */
+/* Expand function epilogue using the following insn patterns:
+   "epilogue"(style == NORMAL_RETURN)
+   "sibcall_epilogue" (style == SIBCALL_RETURN)
+   "eh_return"   (style == EXCEPTION_RETURN) */
 
 void
-loongarch_expand_epilogue (bool sibcall_p)
+loongarch_expand_epilogue (int style)
 {
   /* Split the frame into two.  STEP1 is the amount of stack we should
  deallocate before restoring the registers.  STEP2 is the amount we
@@ -1396,7 +1407,8 @@ loongarch_expand_epilogue (bool sibcall_p)
   bool need_barrier_p
 = (get_frame_size () + cfun->machine->frame.arg_pointer_offset) != 0;
 
-  if (!sibcall_p && loongarch_can_use_return_insn ())
+  /* Handle simple returns.  */
+  if (style == NORMAL_RETURN && loongarch_can_use_return_insn ())
 {
   emit_jump_insn (gen_return ());
   return;
@@ -1472,7 +1484,9 @@ loongarch_expand_epilogue (bool sibcall_p)
 
   /* Restore the registers.  */
   loongarch_for_each_saved_reg (frame->total_size - step2,
-   loongarch_restore_reg);
+   loongarch_restore_reg,
+ 

[PATCH] libstdc++: Update Solaris baselines for GCC 14.0

[Rainer Orth]

This patch updates the Solaris baselines for the GLIBCXX_3.4.33 version
added in GCC 14.0.

Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (32 and 64-bit
each), together with the GLIBCXX_3.4.32 update, on both gcc-14 branch
and trunk.

Ok for and gcc-14 branch and trunk?

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


2024-04-28  Rainer Orth  

libstdc++-v3:
* config/abi/post/i386-solaris/baseline_symbols.txt: Regenerate.
* config/abi/post/i386-solaris/amd64/baseline_symbols.txt:
Likewise.
* config/abi/post/sparc-solaris/baseline_symbols.txt: Likewise.
* config/abi/post/sparc-solaris/sparcv9/baseline_symbols.txt:
Likewise.

# HG changeset patch
# Parent  4232f168006d992630395835612adee6a8a72636
libstdc++: Update Solaris baselines for GCC 14.0

diff --git a/libstdc++-v3/config/abi/post/i386-solaris/amd64/baseline_symbols.txt b/libstdc++-v3/config/abi/post/i386-solaris/amd64/baseline_symbols.txt
--- a/libstdc++-v3/config/abi/post/i386-solaris/amd64/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/i386-solaris/amd64/baseline_symbols.txt
@@ -488,6 +488,7 @@ FUNC:_ZNKSt11__timepunctIwE7_M_daysEPPKw
 FUNC:_ZNKSt11__timepunctIwE8_M_am_pmEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIwE9_M_monthsEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11logic_error4whatEv@@GLIBCXX_3.4
+FUNC:_ZNKSt12__basic_fileIcE13native_handleEv@@GLIBCXX_3.4.33
 FUNC:_ZNKSt12__basic_fileIcE7is_openEv@@GLIBCXX_3.4
 FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31
 FUNC:_ZNKSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31
@@ -4487,6 +4488,7 @@ FUNC:__cxa_allocate_exception@@CXXABI_1.
 FUNC:__cxa_bad_cast@@CXXABI_1.3
 FUNC:__cxa_bad_typeid@@CXXABI_1.3
 FUNC:__cxa_begin_catch@@CXXABI_1.3
+FUNC:__cxa_call_terminate@@CXXABI_1.3.15
 FUNC:__cxa_call_unexpected@@CXXABI_1.3
 FUNC:__cxa_current_exception_type@@CXXABI_1.3
 FUNC:__cxa_deleted_virtual@@CXXABI_1.3.6
@@ -4530,6 +4532,7 @@ OBJECT:0:CXXABI_1.3.11
 OBJECT:0:CXXABI_1.3.12
 OBJECT:0:CXXABI_1.3.13
 OBJECT:0:CXXABI_1.3.14
+OBJECT:0:CXXABI_1.3.15
 OBJECT:0:CXXABI_1.3.2
 OBJECT:0:CXXABI_1.3.3
 OBJECT:0:CXXABI_1.3.4
@@ -4567,6 +4570,7 @@ OBJECT:0:GLIBCXX_3.4.3
 OBJECT:0:GLIBCXX_3.4.30
 OBJECT:0:GLIBCXX_3.4.31
 OBJECT:0:GLIBCXX_3.4.32
+OBJECT:0:GLIBCXX_3.4.33
 OBJECT:0:GLIBCXX_3.4.4
 OBJECT:0:GLIBCXX_3.4.5
 OBJECT:0:GLIBCXX_3.4.6
diff --git a/libstdc++-v3/config/abi/post/i386-solaris/baseline_symbols.txt b/libstdc++-v3/config/abi/post/i386-solaris/baseline_symbols.txt
--- a/libstdc++-v3/config/abi/post/i386-solaris/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/i386-solaris/baseline_symbols.txt
@@ -488,6 +488,7 @@ FUNC:_ZNKSt11__timepunctIwE7_M_daysEPPKw
 FUNC:_ZNKSt11__timepunctIwE8_M_am_pmEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIwE9_M_monthsEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11logic_error4whatEv@@GLIBCXX_3.4
+FUNC:_ZNKSt12__basic_fileIcE13native_handleEv@@GLIBCXX_3.4.33
 FUNC:_ZNKSt12__basic_fileIcE7is_openEv@@GLIBCXX_3.4
 FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31
 FUNC:_ZNKSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31
@@ -4487,6 +4488,7 @@ FUNC:__cxa_allocate_exception@@CXXABI_1.
 FUNC:__cxa_bad_cast@@CXXABI_1.3
 FUNC:__cxa_bad_typeid@@CXXABI_1.3
 FUNC:__cxa_begin_catch@@CXXABI_1.3
+FUNC:__cxa_call_terminate@@CXXABI_1.3.15
 FUNC:__cxa_call_unexpected@@CXXABI_1.3
 FUNC:__cxa_current_exception_type@@CXXABI_1.3
 FUNC:__cxa_deleted_virtual@@CXXABI_1.3.6
@@ -4530,6 +4532,7 @@ OBJECT:0:CXXABI_1.3.11
 OBJECT:0:CXXABI_1.3.12
 OBJECT:0:CXXABI_1.3.13
 OBJECT:0:CXXABI_1.3.14
+OBJECT:0:CXXABI_1.3.15
 OBJECT:0:CXXABI_1.3.2
 OBJECT:0:CXXABI_1.3.3
 OBJECT:0:CXXABI_1.3.4
@@ -4567,6 +4570,7 @@ OBJECT:0:GLIBCXX_3.4.3
 OBJECT:0:GLIBCXX_3.4.30
 OBJECT:0:GLIBCXX_3.4.31
 OBJECT:0:GLIBCXX_3.4.32
+OBJECT:0:GLIBCXX_3.4.33
 OBJECT:0:GLIBCXX_3.4.4
 OBJECT:0:GLIBCXX_3.4.5
 OBJECT:0:GLIBCXX_3.4.6
diff --git a/libstdc++-v3/config/abi/post/sparc-solaris/baseline_symbols.txt b/libstdc++-v3/config/abi/post/sparc-solaris/baseline_symbols.txt
--- a/libstdc++-v3/config/abi/post/sparc-solaris/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/sparc-solaris/baseline_symbols.txt
@@ -488,6 +488,7 @@ FUNC:_ZNKSt11__timepunctIwE7_M_daysEPPKw
 FUNC:_ZNKSt11__timepunctIwE8_M_am_pmEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIwE9_M_monthsEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11logic_error4whatEv@@GLIBCXX_3.4
+FUNC:_ZNKSt12__basic_fileIcE13native_handleEv@@GLIBCXX_3.4.33
 FUNC:_ZNKSt12__basic_fileIcE7is_openEv@@GLIBCXX_3.4
 FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31
 

[PATCH] libstdc++: Update Solaris baselines for GCC 13.2

[Rainer Orth]

This patch updates the Solaris baselines for the GLIBCXX_3.4.32 version
added in GCC 13.2.

Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (32 and 64-bit
each) on the gcc-13 branch and (together with the GLIBCXX_3.4.33 update)
on both gcc-14 branch and trunk.

Ok for all of gcc-13 and gcc-14 branches and trunk?

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


2024-04-28  Rainer Orth  

libstdc++-v3:
* config/abi/post/i386-solaris/baseline_symbols.txt: Regenerate.
* config/abi/post/i386-solaris/amd64/baseline_symbols.txt:
Likewise.
* config/abi/post/sparc-solaris/baseline_symbols.txt: Likewise.
* config/abi/post/sparc-solaris/sparcv9/baseline_symbols.txt:
Likewise.

# HG changeset patch
# Parent  dd18a74d3c5f8539cec05a9394d14e209474ab64
libstdc++: Update Solaris baselines for GCC 13.2

diff --git a/libstdc++-v3/config/abi/post/i386-solaris/amd64/baseline_symbols.txt b/libstdc++-v3/config/abi/post/i386-solaris/amd64/baseline_symbols.txt
--- a/libstdc++-v3/config/abi/post/i386-solaris/amd64/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/i386-solaris/amd64/baseline_symbols.txt
@@ -3175,6 +3175,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIcSt11ch
 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEmmPKcm@@GLIBCXX_3.4.21
 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_S_compareEmm@@GLIBCXX_3.4.21
 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_M_capacityEm@@GLIBCXX_3.4.21
+FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_S_allocateERS3_m@@GLIBCXX_3.4.32
 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_@@GLIBCXX_3.4.23
 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcRKS3_@@GLIBCXX_3.4.21
 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
@@ -3327,6 +3328,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIwSt11ch
 FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_replaceEmmPKwm@@GLIBCXX_3.4.21
 FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_S_compareEmm@@GLIBCXX_3.4.21
 FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_M_capacityEm@@GLIBCXX_3.4.21
+FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_S_allocateERS3_m@@GLIBCXX_3.4.32
 FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwOS3_@@GLIBCXX_3.4.23
 FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwRKS3_@@GLIBCXX_3.4.21
 FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23
@@ -4564,6 +4566,7 @@ OBJECT:0:GLIBCXX_3.4.29
 OBJECT:0:GLIBCXX_3.4.3
 OBJECT:0:GLIBCXX_3.4.30
 OBJECT:0:GLIBCXX_3.4.31
+OBJECT:0:GLIBCXX_3.4.32
 OBJECT:0:GLIBCXX_3.4.4
 OBJECT:0:GLIBCXX_3.4.5
 OBJECT:0:GLIBCXX_3.4.6
diff --git a/libstdc++-v3/config/abi/post/i386-solaris/baseline_symbols.txt b/libstdc++-v3/config/abi/post/i386-solaris/baseline_symbols.txt
--- a/libstdc++-v3/config/abi/post/i386-solaris/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/i386-solaris/baseline_symbols.txt
@@ -3175,6 +3175,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIcSt11ch
 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEjjPKcj@@GLIBCXX_3.4.21
 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_S_compareEjj@@GLIBCXX_3.4.21
 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_M_capacityEj@@GLIBCXX_3.4.21
+FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_@@GLIBCXX_3.4.23
 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcRKS3_@@GLIBCXX_3.4.21
 FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
@@ -3327,6 +3328,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIwSt11ch
 FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_replaceEjjPKwj@@GLIBCXX_3.4.21
 FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_S_compareEjj@@GLIBCXX_3.4.21
 FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_M_capacityEj@@GLIBCXX_3.4.21
+FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
 FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwOS3_@@GLIBCXX_3.4.23
 FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwRKS3_@@GLIBCXX_3.4.21
 FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23
@@ -4564,6 +4566,7 @@ OBJECT:0:GLIBCXX_3.4.29
 OBJECT:0:GLIBCXX_3.4.3
 OBJECT:0:GLIBCXX_3.4.30
 OBJECT:0:GLIBCXX_3.4.31
+OBJECT:0:GLIBCXX_3.4.32
 OBJECT:0:GLIBCXX_3.4.4
 OBJECT:0:GLIBCXX_3.4.5
 OBJECT:0:GLIBCXX_3.4.6
diff --git a/libstdc++-v3/config/abi/post/sparc-solaris/baseline_symbols.txt 

[PATCH v3] Internal-fn: Introduce new internal function SAT_ADD

[pan2 . li]

From: Pan Li 

Update in v3:
* Rebase upstream for conflict.

Update in v2:
* Fix one failure for x86 bootstrap.

Original log:

This patch would like to add the middle-end presentation for the
saturation add.  Aka set the result of add to the max when overflow.
It will take the pattern similar as below.

SAT_ADD (x, y) => (x + y) | (-(TYPE)((TYPE)(x + y) < x))

Take uint8_t as example, we will have:

* SAT_ADD (1, 254)   => 255.
* SAT_ADD (1, 255)   => 255.
* SAT_ADD (2, 255)   => 255.
* SAT_ADD (255, 255) => 255.

The patch also implement the SAT_ADD in the riscv backend as
the sample for both the scalar and vector.  Given below example:

uint64_t sat_add_u64 (uint64_t x, uint64_t y)
{
  return (x + y) | (- (uint64_t)((uint64_t)(x + y) < x));
}

Before this patch:
uint64_t sat_add_uint64_t (uint64_t x, uint64_t y)
{
  long unsigned int _1;
  _Bool _2;
  long unsigned int _3;
  long unsigned int _4;
  uint64_t _7;
  long unsigned int _10;
  __complex__ long unsigned int _11;

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  _11 = .ADD_OVERFLOW (x_5(D), y_6(D));
  _1 = REALPART_EXPR <_11>;
  _10 = IMAGPART_EXPR <_11>;
  _2 = _10 != 0;
  _3 = (long unsigned int) _2;
  _4 = -_3;
  _7 = _1 | _4;
  return _7;
;;succ:   EXIT

}

After this patch:
uint64_t sat_add_uint64_t (uint64_t x, uint64_t y)
{
  uint64_t _7;

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  _7 = .SAT_ADD (x_5(D), y_6(D)); [tail call]
  return _7;
;;succ:   EXIT
}

For vectorize, we leverage the existing vect pattern recog to find
the pattern similar to scalar and let the vectorizer to perform
the rest part for standard name usadd3 in vector mode.
The riscv vector backend have insn "Vector Single-Width Saturating
Add and Subtract" which can be leveraged when expand the usadd3
in vector mode.  For example:

void vec_sat_add_u64 (uint64_t *out, uint64_t *x, uint64_t *y, unsigned n)
{
  unsigned i;

  for (i = 0; i < n; i++)
out[i] = (x[i] + y[i]) | (- (uint64_t)((uint64_t)(x[i] + y[i]) < x[i]));
}

Before this patch:
void vec_sat_add_u64 (uint64_t *out, uint64_t *x, uint64_t *y, unsigned n)
{
  ...
  _80 = .SELECT_VL (ivtmp_78, POLY_INT_CST [2, 2]);
  ivtmp_58 = _80 * 8;
  vect__4.7_61 = .MASK_LEN_LOAD (vectp_x.5_59, 64B, { -1, ... }, _80, 0);
  vect__6.10_65 = .MASK_LEN_LOAD (vectp_y.8_63, 64B, { -1, ... }, _80, 0);
  vect__7.11_66 = vect__4.7_61 + vect__6.10_65;
  mask__8.12_67 = vect__4.7_61 > vect__7.11_66;
  vect__12.15_72 = .VCOND_MASK (mask__8.12_67, { 18446744073709551615, ... }, 
vect__7.11_66);
  .MASK_LEN_STORE (vectp_out.16_74, 64B, { -1, ... }, _80, 0, vect__12.15_72);
  vectp_x.5_60 = vectp_x.5_59 + ivtmp_58;
  vectp_y.8_64 = vectp_y.8_63 + ivtmp_58;
  vectp_out.16_75 = vectp_out.16_74 + ivtmp_58;
  ivtmp_79 = ivtmp_78 - _80;
  ...
}

vec_sat_add_u64:
  ...
  vsetvli a5,a3,e64,m1,ta,ma
  vle64.v v0,0(a1)
  vle64.v v1,0(a2)
  sllia4,a5,3
  sub a3,a3,a5
  add a1,a1,a4
  add a2,a2,a4
  vadd.vv v1,v0,v1
  vmsgtu.vv   v0,v0,v1
  vmerge.vim  v1,v1,-1,v0
  vse64.v v1,0(a0)
  ...

After this patch:
void vec_sat_add_u64 (uint64_t *out, uint64_t *x, uint64_t *y, unsigned n)
{
  ...
  _62 = .SELECT_VL (ivtmp_60, POLY_INT_CST [2, 2]);
  ivtmp_46 = _62 * 8;
  vect__4.7_49 = .MASK_LEN_LOAD (vectp_x.5_47, 64B, { -1, ... }, _62, 0);
  vect__6.10_53 = .MASK_LEN_LOAD (vectp_y.8_51, 64B, { -1, ... }, _62, 0);
  vect__12.11_54 = .SAT_ADD (vect__4.7_49, vect__6.10_53);
  .MASK_LEN_STORE (vectp_out.12_56, 64B, { -1, ... }, _62, 0, vect__12.11_54);
  ...
}

vec_sat_add_u64:
  ...
  vsetvli a5,a3,e64,m1,ta,ma
  vle64.v v1,0(a1)
  vle64.v v2,0(a2)
  sllia4,a5,3
  sub a3,a3,a5
  add a1,a1,a4
  add a2,a2,a4
  vsaddu.vv   v1,v1,v2
  vse64.v v1,0(a0)
  ...

To limit the patch size for review, only unsigned version of
usadd3 are involved here. The signed version will be covered
in the underlying patch(es).

The below test suites are passed for this patch.
* The riscv fully regression tests.
* The aarch64 fully regression tests.
* The x86 bootstrap tests.
* The x86 fully regression tests.

PR target/51492
PR target/112600

gcc/ChangeLog:

* config/riscv/autovec.md (usadd3): New pattern expand
for unsigned SAT_ADD vector.
* config/riscv/riscv-protos.h (riscv_expand_usadd): New func
decl to expand usadd3 pattern.
(expand_vec_usadd): Ditto but for vector.
* config/riscv/riscv-v.cc (emit_vec_saddu): New func impl to
emit the vsadd insn.
(expand_vec_usadd): New func impl to expand usadd3 for
vector.
* config/riscv/riscv.cc (riscv_expand_usadd): New func impl
to expand usadd3 for scalar.
* config/riscv/riscv.md (usadd3): New pattern expand
for unsigned SAT_ADD scalar.
* config/riscv/vector.md: Allow VLS mode for vsaddu.
* internal-fn.cc (commutative_binary_fn_p): Add type IFN_SAT_ADD.
* internal-fn.def (SAT_ADD): Add new signed optab 

Re: [PATCH v2] RISC-V: Fix ICE for legitimize move on subreg const_poly_int [PR114885]

[Jakub Jelinek]

On Mon, Apr 29, 2024 at 03:47:05PM +0800, Kito Cheng wrote:
> Hi Jakub:
> 
> Is this OK for GCC 14 branch? it's fix ICE on valid code, thanks :)

Ok.

Jakub

Re: [PATCH v2] RISC-V: Fix ICE for legitimize move on subreg const_poly_int [PR114885]

[Kito Cheng]

Hi Pan:

LGTM.

Hi Jakub:

Is this OK for GCC 14 branch? it's fix ICE on valid code, thanks :)

On Mon, Apr 29, 2024 at 3:40 PM  wrote:
>
> From: Pan Li 
>
> When we build with isl, there will be a ICE for graphite in both
> the c/c++ and fortran.  The legitimize move cannot take care of
> below rtl.
>
> (set (subreg:DI (reg:TI 237) 8) (subreg:DI (const_poly_int:TI [4, 2]) 8))
>
> Then we will have ice similar to below:
>
> internal compiler error: in extract_insn, at recog.cc:2812.
>
> This patch would like to take care of the above rtl.  Given the value of
> const_poly_int can hardly excceed the max of int64,  we can simply
> consider the highest 8 bytes of TImode is zero and then set the dest
> to (const_int 0).
>
> The below test cases are fixed by this PATCH.
>
> C:
> FAIL: gcc.dg/graphite/pr111878.c (internal compiler error: in
> extract_insn, at recog.cc:2812)
> FAIL: gcc.dg/graphite/pr111878.c (test for excess errors)
>
> Fortran:
> FAIL: gfortran.dg/graphite/vect-pr40979.f90   -O  (internal compiler
> error: in extract_insn, at recog.cc:2812)
> FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -fomit-frame-pointer
> -funroll-loops -fpeel-loops -ftracer -finline-functions  (internal
> compiler error: in extract_insn, at recog.cc:2812)
> FAIL: gfortran.dg/graphite/pr29581.f90   -O3 -g  (test for excess
> errors)
> FAIL: gfortran.dg/graphite/pr14741.f90   -O  (test for excess errors)
> FAIL: gfortran.dg/graphite/pr29581.f90   -O3 -fomit-frame-pointer
> -funroll-loops -fpeel-loops -ftracer -finline-functions  (test for
> excess errors)
> FAIL: gfortran.dg/graphite/vect-pr40979.f90   -O  (test for excess
> errors)
> FAIL: gfortran.dg/graphite/id-27.f90   -O  (internal compiler error: in
> extract_insn, at recog.cc:2812)
> FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -g  (internal compiler
> error: in extract_insn, at recog.cc:2812)
> FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -g  (test for excess
> errors)
> FAIL: gfortran.dg/graphite/id-27.f90   -O  (test for excess errors)
> FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -fomit-frame-pointer
> -funroll-loops -fpeel-loops -ftracer -finline-functions  (test for
> excess errors)
> FAIL: gfortran.dg/graphite/pr29581.f90   -O3 -fomit-frame-pointer
> -funroll-loops -fpeel-loops -ftracer -finline-functions  (internal
> compiler error: in extract_insn, at recog.cc:2812)
> FAIL: gfortran.dg/graphite/pr14741.f90   -O  (internal compiler error:
> in extract_insn, at recog.cc:2812)
> FAIL: gfortran.dg/graphite/pr29581.f90   -O3 -g  (internal compiler
> error: in extract_insn, at recog.cc:2812)
>
> The below test suites are passed for this patch:
> * The rv64gcv fully regression test.
> * The rv64gc fully regression test.
>
> Try to write some RTL code for test but not works well according to
> existing test cases.  Thus, take above as test cases.  Please note
> graphite require the gcc build with isl.
>
> PR target/114885
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_legitimize_subreg_const_poly_move): New
> func impl to take care of (const_int_poly:TI 8).
> (riscv_legitimize_move): Handle subreg is const_int_poly,
>
> Signed-off-by: Pan Li 
> ---
>  gcc/config/riscv/riscv.cc | 44 +++
>  1 file changed, 44 insertions(+)
>
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 0519e0679ed..0f62b295b96 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -2786,6 +2786,45 @@ riscv_v_adjust_scalable_frame (rtx target, poly_int64 
> offset, bool epilogue)
>REG_NOTES (insn) = dwarf;
>  }
>
> +/* Take care below subreg const_poly_int move:
> +
> +   1. (set (subreg:DI (reg:TI 237) 8)
> +  (subreg:DI (const_poly_int:TI [4, 2]) 8))
> +  =>
> +  (set (subreg:DI (reg:TI 237) 8)
> +  (const_int 0)) */
> +
> +static bool
> +riscv_legitimize_subreg_const_poly_move (machine_mode mode, rtx dest, rtx 
> src)
> +{
> +  gcc_assert (SUBREG_P (src) && CONST_POLY_INT_P (SUBREG_REG (src)));
> +  gcc_assert (SUBREG_BYTE (src).is_constant ());
> +
> +  int byte_offset = SUBREG_BYTE (src).to_constant ();
> +  rtx const_poly = SUBREG_REG (src);
> +  machine_mode subreg_mode = GET_MODE (const_poly);
> +
> +  if (subreg_mode != TImode) /* Only TImode is needed for now.  */
> +return false;
> +
> +  if (byte_offset == 8)
> +{
> +  /* The const_poly_int cannot exceed int64, just set zero here.  */
> +  emit_move_insn (dest, CONST0_RTX (mode));
> +  return true;
> +}
> +
> +  /* The below transform will be covered in somewhere else.
> + Thus, ignore this here.
> + (set (subreg:DI (reg:TI 237) 0)
> + (subreg:DI (const_poly_int:TI [4, 2]) 0))
> + =>
> + (set (subreg:DI (reg:TI 237) 0)
> + (const_poly_int:DI [4, 2])) */
> +
> +  return false;
> +}
> +
>  /* If (set DEST SRC) is not a valid move instruction, emit an equivalent
> sequence that is valid.  */
>
> @@ -2839,6 +2878,11 @@ 

RE: [PATCH v1] RISC-V: Fix ICE for legitimize move on subreg const_poly_move

[Li, Pan2]

Thanks Kito, sent v2 for addressing comments.

Pan

-Original Message-
From: Kito Cheng  
Sent: Monday, April 29, 2024 2:37 PM
To: juzhe.zh...@rivai.ai
Cc: Li, Pan2 ; gcc-patches 
Subject: Re: [PATCH v1] RISC-V: Fix ICE for legitimize move on subreg 
const_poly_move

> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 0519e0679ed..bad23ea487f 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -2786,6 +2786,44 @@ riscv_v_adjust_scalable_frame (rtx target, poly_int64 
> offset, bool epilogue)
>REG_NOTES (insn) = dwarf;
> }
> +/* Take care below subreg const_poly_int move:
> +
> +   1. (set (subreg:DI (reg:TI 237) 8)
> +(subreg:DI (const_poly_int:TI [4, 2]) 8))
> +  =>
> +  (set (subreg:DI (reg:TI 237) 8)
> +(const_int 0)) */
> +
> +static bool
> +riscv_legitimize_subreg_const_poly_move (machine_mode mode, rtx dest, rtx 
> src)
> +{
> +  gcc_assert (SUBREG_P (src) && CONST_POLY_INT_P (SUBREG_REG (src)));
> +  gcc_assert (SUBREG_BYTE (src).is_constant ());
> +
> +  int byte_offset = SUBREG_BYTE (src).to_constant ();
> +  rtx const_poly = SUBREG_REG (src);
> +  machine_mode subreg_mode = GET_MODE (const_poly);
> +
> +  if (subreg_mode != TImode) /* Only TImode is needed for now.  */
> +return false;
> +
> +  if (byte_offset == 8)
> +{ /* The const_poly_int cannot exceed int64, just set zero here.  */

{
 /* The const_poly_int cannot exceed int64, just set zero here.  */

New line for the comment.

> +  emit_move_insn (dest, CONST0_RTX (mode));
> +  return true;
> +}
> +
> +  /* The below transform will be covered in somewhere else.
> + Thus, ignore this here.
> +   1. (set (subreg:DI (reg:TI 237) 0)
> +(subreg:DI (const_poly_int:TI [4, 2]) 0))
> +  =>
> +  (set (subreg:DI (reg:TI 237) 0)
> +(const_poly_int:DI [4, 2])) */
> +
> +  return false;
> +}
> +
> /* If (set DEST SRC) is not a valid move instruction, emit an equivalent
> sequence that is valid.  */
> @@ -2839,6 +2877,11 @@ riscv_legitimize_move (machine_mode mode, rtx dest, 
> rtx src)
> }
>return true;
>  }
> +
> +  if (SUBREG_P (src) && CONST_POLY_INT_P (SUBREG_REG (src))
> +&& riscv_legitimize_subreg_const_poly_move (mode, dest, src))
> +return true;
> +
>/* Expand
> (set (reg:DI target) (subreg:DI (reg:V8QI reg) 0))
>   Expand this data movement instead of simply forbid it since
> --
> 2.34.1
>
>

[PATCH v2] RISC-V: Fix ICE for legitimize move on subreg const_poly_int [PR114885]

[pan2 . li]

From: Pan Li 

When we build with isl, there will be a ICE for graphite in both
the c/c++ and fortran.  The legitimize move cannot take care of
below rtl.

(set (subreg:DI (reg:TI 237) 8) (subreg:DI (const_poly_int:TI [4, 2]) 8))

Then we will have ice similar to below:

internal compiler error: in extract_insn, at recog.cc:2812.

This patch would like to take care of the above rtl.  Given the value of
const_poly_int can hardly excceed the max of int64,  we can simply
consider the highest 8 bytes of TImode is zero and then set the dest
to (const_int 0).

The below test cases are fixed by this PATCH.

C:
FAIL: gcc.dg/graphite/pr111878.c (internal compiler error: in
extract_insn, at recog.cc:2812)
FAIL: gcc.dg/graphite/pr111878.c (test for excess errors)

Fortran:
FAIL: gfortran.dg/graphite/vect-pr40979.f90   -O  (internal compiler
error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal
compiler error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29581.f90   -O3 -g  (test for excess
errors)
FAIL: gfortran.dg/graphite/pr14741.f90   -O  (test for excess errors)
FAIL: gfortran.dg/graphite/pr29581.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for
excess errors)
FAIL: gfortran.dg/graphite/vect-pr40979.f90   -O  (test for excess
errors)
FAIL: gfortran.dg/graphite/id-27.f90   -O  (internal compiler error: in
extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -g  (internal compiler
error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -g  (test for excess
errors)
FAIL: gfortran.dg/graphite/id-27.f90   -O  (test for excess errors)
FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for
excess errors)
FAIL: gfortran.dg/graphite/pr29581.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal
compiler error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr14741.f90   -O  (internal compiler error:
in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29581.f90   -O3 -g  (internal compiler
error: in extract_insn, at recog.cc:2812)

The below test suites are passed for this patch:
* The rv64gcv fully regression test.
* The rv64gc fully regression test.

Try to write some RTL code for test but not works well according to
existing test cases.  Thus, take above as test cases.  Please note
graphite require the gcc build with isl.

PR target/114885

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_legitimize_subreg_const_poly_move): New
func impl to take care of (const_int_poly:TI 8).
(riscv_legitimize_move): Handle subreg is const_int_poly,

Signed-off-by: Pan Li 
---
 gcc/config/riscv/riscv.cc | 44 +++
 1 file changed, 44 insertions(+)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 0519e0679ed..0f62b295b96 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -2786,6 +2786,45 @@ riscv_v_adjust_scalable_frame (rtx target, poly_int64 
offset, bool epilogue)
   REG_NOTES (insn) = dwarf;
 }
 
+/* Take care below subreg const_poly_int move:
+
+   1. (set (subreg:DI (reg:TI 237) 8)
+  (subreg:DI (const_poly_int:TI [4, 2]) 8))
+  =>
+  (set (subreg:DI (reg:TI 237) 8)
+  (const_int 0)) */
+
+static bool
+riscv_legitimize_subreg_const_poly_move (machine_mode mode, rtx dest, rtx src)
+{
+  gcc_assert (SUBREG_P (src) && CONST_POLY_INT_P (SUBREG_REG (src)));
+  gcc_assert (SUBREG_BYTE (src).is_constant ());
+
+  int byte_offset = SUBREG_BYTE (src).to_constant ();
+  rtx const_poly = SUBREG_REG (src);
+  machine_mode subreg_mode = GET_MODE (const_poly);
+
+  if (subreg_mode != TImode) /* Only TImode is needed for now.  */
+return false;
+
+  if (byte_offset == 8)
+{
+  /* The const_poly_int cannot exceed int64, just set zero here.  */
+  emit_move_insn (dest, CONST0_RTX (mode));
+  return true;
+}
+
+  /* The below transform will be covered in somewhere else.
+ Thus, ignore this here.
+ (set (subreg:DI (reg:TI 237) 0)
+ (subreg:DI (const_poly_int:TI [4, 2]) 0))
+ =>
+ (set (subreg:DI (reg:TI 237) 0)
+ (const_poly_int:DI [4, 2])) */
+
+  return false;
+}
+
 /* If (set DEST SRC) is not a valid move instruction, emit an equivalent
sequence that is valid.  */
 
@@ -2839,6 +2878,11 @@ riscv_legitimize_move (machine_mode mode, rtx dest, rtx 
src)
}
   return true;
 }
+
+  if (SUBREG_P (src) && CONST_POLY_INT_P (SUBREG_REG (src))
+&& riscv_legitimize_subreg_const_poly_move (mode, dest, src))
+return true;
+
   /* Expand
(set (reg:DI target) (subreg:DI (reg:V8QI reg) 0))
  Expand this data movement instead of simply forbid it since
-- 

Re: [PATCH] ppc: testsuite: pr79004 needs -mlong-double-128

[Alexandre Oliva]

On Apr 28, 2024, "Kewen.Lin"  wrote:

> OK, from this perspective IMHO it seems more clear to adopt xfail
> with effective target long_double_64bit?

That's effective target is quite broken, alas.  I doubt it's used
anywhere: it calls an undefined proc, and its memcmp call seems to have
the size cut from the 128-bit functions.  (a patchlet that
fixes these most glaring issues is below)

Furthermore, it doesn't really work.  Since it adds -mlong-double-64 for
the effective target test, it overrides the default, so it sort of
always passes, even on a 128-bit long double target.  But since the test
itself doesn't add that option, any xfails on long_double_64bit would be
flagged as XPASS.

There's no effective target test for 64-bit long double that doesn't
override the default, so we'd have to add one.  Alas, the natural name
for it is the one that's taken with overriding behavior, and the current
option-overriding tests, that need to be used along with the
corresponding add-options in testcases, might benefit from a renaming to
make them fit the already-established (?) naming standards.  Yuck.


diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 182d80129de9b..603da25c97d67 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2961,12 +2961,12 @@ proc check_effective_target_long_double_64bit { } {
  /* eliminate removing volatile cast warning.  */
  a2 = a;
  b2 = b;
- if (memcmp (, , 16) != 0)
+ if (memcmp (, , 8) != 0)
return 1;
  sprintf (buffer, "%lg", b);
  return strcmp (buffer, "3") != 0;
}
-}  [add_options_for_ppc_long_double_override_64bit ""]]
+}  [add_options_for_long_double_64bit ""]]
 }
 
 # Return the appropriate options to specify that long double uses the IEEE


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[PATCH] Minor tweaks to code computing modular multiplicative inverse

[Eric Botcazou]

Hi,

this removes the last parameter of choose_multiplier, which is unused, adds
another assertion and more details to the description and various comments.
Likewise to the closely related invert_mod2n, except for the last parameter.

Tested on x86-64/Linux, OK for the mainline?


2024-04-29  Eric Botcazou  

* expmed.h (choose_multiplier): Tweak description and remove last
parameter.
* expmed.cc (choose_multiplier): Likewise.  Add assertion for the
third parameter and adds details to various comments.
(invert_mod2n): Tweak description and add assertion for the first
parameter.
(expand_divmod): Adjust calls to choose_multiplier.
* tree-vect-generic.cc (expand_vector_divmod): Likewise.
* tree-vect-patterns.cc (vect_recog_divmod_pattern): Likewise.

-- 
Eric Botcazoudiff --git a/gcc/expmed.cc b/gcc/expmed.cc
index 4ec035e4843..60f65c7acc5 100644
--- a/gcc/expmed.cc
+++ b/gcc/expmed.cc
@@ -3689,50 +3689,62 @@ expand_widening_mult (machine_mode mode, rtx op0, rtx op1, rtx target,
 		   unsignedp, OPTAB_LIB_WIDEN);
 }
 
-/* Choose a minimal N + 1 bit approximation to 1/D that can be used to
-   replace division by D, and put the least significant N bits of the result
-   in *MULTIPLIER_PTR and return the most significant bit.
+/* Choose a minimal N + 1 bit approximation to 2**K / D that can be used to
+   replace division by D, put the least significant N bits of the result in
+   *MULTIPLIER_PTR, the value K - N in *POST_SHIFT_PTR, and return the most
+   significant bit.
 
The width of operations is N (should be <= HOST_BITS_PER_WIDE_INT), the
-   needed precision is in PRECISION (should be <= N).
+   needed precision is PRECISION (should be <= N).
 
-   PRECISION should be as small as possible so this function can choose
-   multiplier more freely.
+   PRECISION should be as small as possible so this function can choose the
+   multiplier more freely.  If PRECISION is <= N - 1, the most significant
+   bit returned by the function will be zero.
 
-   The rounded-up logarithm of D is placed in *lgup_ptr.  A shift count that
-   is to be used for a final right shift is placed in *POST_SHIFT_PTR.
-
-   Using this function, x/D will be equal to (x * m) >> (*POST_SHIFT_PTR),
-   where m is the full HOST_BITS_PER_WIDE_INT + 1 bit multiplier.  */
+   Using this function, x / D is equal to (x*m) / 2**N >> (*POST_SHIFT_PTR),
+   where m is the full N + 1 bit multiplier.  */
 
 unsigned HOST_WIDE_INT
 choose_multiplier (unsigned HOST_WIDE_INT d, int n, int precision,
 		   unsigned HOST_WIDE_INT *multiplier_ptr,
-		   int *post_shift_ptr, int *lgup_ptr)
+		   int *post_shift_ptr)
 {
   int lgup, post_shift;
-  int pow, pow2;
+  int pow1, pow2;
 
-  /* lgup = ceil(log2(divisor)); */
+  /* lgup = ceil(log2(d)) */
+  /* Assuming d > 1, we have d >= 2^(lgup-1) + 1 */
   lgup = ceil_log2 (d);
 
   gcc_assert (lgup <= n);
+  gcc_assert (lgup <= precision);
 
-  pow = n + lgup;
+  pow1 = n + lgup;
   pow2 = n + lgup - precision;
 
-  /* mlow = 2^(N + lgup)/d */
-  wide_int val = wi::set_bit_in_zero (pow, HOST_BITS_PER_DOUBLE_INT);
+  /* mlow = 2^(n + lgup)/d */
+  /* Trivially from above we have mlow < 2^(n+1) */
+  wide_int val = wi::set_bit_in_zero (pow1, HOST_BITS_PER_DOUBLE_INT);
   wide_int mlow = wi::udiv_trunc (val, d);
 
-  /* mhigh = (2^(N + lgup) + 2^(N + lgup - precision))/d */
+  /* mhigh = (2^(n + lgup) + 2^(n + lgup - precision))/d */
+  /* From above we have mhigh < 2^(n+1) assuming lgup <= precision */
+  /* From precision <= n, the difference between the numerators of mhigh and
+ mlow is >= 2^lgup >= d.  Therefore the difference of the quotients in
+ the Euclidean division by d is at least 1, so we have mlow < mhigh and
+ the exact value of 2^(n + lgup)/d lies in the interval [mlow; mhigh(.  */
   val |= wi::set_bit_in_zero (pow2, HOST_BITS_PER_DOUBLE_INT);
   wide_int mhigh = wi::udiv_trunc (val, d);
 
-  /* If precision == N, then mlow, mhigh exceed 2^N
- (but they do not exceed 2^(N+1)).  */
-
   /* Reduce to lowest terms.  */
+  /* If precision <= n - 1, then the difference between the numerators of
+ mhigh and mlow is >= 2^(lgup + 1) >= 2 * 2^lgup >= 2 * d.  Therefore
+ the difference of the quotients in the Euclidean division by d is at
+ least 2, which means that mhigh and mlow differ by at least one bit
+ not in the last place.  The conclusion is that the first iteration of
+ the loop below completes and shifts mhigh and mlow by 1 bit, which in
+ particular means that mhigh < 2^n, that is to say, the most significant
+ bit in the n + 1 bit value is zero.  */
   for (post_shift = lgup; post_shift > 0; post_shift--)
 {
   unsigned HOST_WIDE_INT ml_lo = wi::extract_uhwi (mlow, 1,
@@ -3747,7 +3759,7 @@ choose_multiplier (unsigned HOST_WIDE_INT d, int n, int precision,
 }
 
   *post_shift_ptr = post_shift;
-  *lgup_ptr = lgup;
+
   if (n < HOST_BITS_PER_WIDE_INT)
 {

[PATCH] c++: Implement C++26 P0609R3 - Attributes for Structured Bindings [PR114456]

[Jakub Jelinek]

Hi!

The following patch implements the P0609R3 paper; we build the
VAR_DECLs for the structured binding identifiers early, so all we need
IMHO is just to parse the attributed identifier list and pass the attributes
to the VAR_DECL creation.

The paper mentions maybe_unused and gnu::nonstring attributes as examples
where they can be useful.  Not sure about either of them.
For maybe_unused, the thing is that both GCC and clang already don't
diagnose maybe unused for the structured binding identifiers, because it
would be a false positive too often; and there is no easy way to find out
if a structured binding has been written with the P0609R3 paper in mind or
not (maybe we could turn it on if in the structured binding is any
attribute, even if just [[]] and record that as a flag on the whole
underlying decl, so that we'd diagnose
  auto [a, b, c[[]]] = d;
  // use a, c but not b
but not
  auto [e, f, g] = d;
  // use a, c but not b
).  For gnu::nonstring, the issue is that we currently don't allow the
attribute on references to char * or references to char[], just on
char */char[].  I've filed a PR for that.

The first testcase in the patch tests it on [[]] and [[maybe_unused]],
just whether it is parsed properly, second on gnu::deprecated, which
works.  Haven't used deprecated attribute because the paper said that
attribute is for further investigation.

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

2024-04-29  Jakub Jelinek  

PR c++/114456
gcc/c-family/
* c-cppbuiltin.cc (c_cpp_builtins): Predefine
__cpp_structured_bindings for C++26 to 202403L rather than
201606L.
gcc/cp/
* parser.cc (cp_parser_decomposition_declaration): Implement C++26
P0609R3 - Attributes for Structured Bindings.  Parse attributed
identifier lists for structured binding declarations, pass the
attributes to start_decl.
gcc/testsuite/
* g++.dg/cpp26/decomp1.C: New test.
* g++.dg/cpp26/decomp2.C: New test.
* g++.dg/cpp26/feat-cxx26.C (__cpp_structured_bindings): Expect
202403 rather than 201606.

--- gcc/cp/parser.cc.jj 2024-04-26 11:42:24.653016208 +0200
+++ gcc/cp/parser.cc2024-04-26 13:59:17.791482874 +0200
@@ -16075,13 +16075,37 @@ cp_parser_decomposition_declaration (cp_
 
   /* Parse the identifier-list.  */
   auto_vec v;
+  bool attr_diagnosed = false;
+  int first_attr = -1;
+  unsigned int cnt = 0;
   if (!cp_lexer_next_token_is (parser->lexer, CPP_CLOSE_SQUARE))
 while (true)
   {
cp_expr e = cp_parser_identifier (parser);
if (e.get_value () == error_mark_node)
  break;
+   tree attr = NULL_TREE;
+   if (cp_next_tokens_can_be_std_attribute_p (parser))
+ {
+   if (cxx_dialect >= cxx17 && cxx_dialect < cxx26 && !attr_diagnosed)
+ {
+   pedwarn (cp_lexer_peek_token (parser->lexer)->location,
+OPT_Wc__26_extensions,
+"structured bindings with attributed identifiers "
+"only available with %<-std=c++2c%> or "
+"%<-std=gnu++2c%>");
+   attr_diagnosed = true;
+ }
+   attr = cp_parser_std_attribute_spec_seq (parser);
+   if (attr == error_mark_node)
+ attr = NULL_TREE;
+   if (attr && first_attr == -1)
+ first_attr = v.length ();
+ }
v.safe_push (e);
+   ++cnt;
+   if (first_attr != -1)
+ v.safe_push (attr);
if (!cp_lexer_next_token_is (parser->lexer, CPP_COMMA))
  break;
cp_lexer_consume_token (parser->lexer);
@@ -16139,8 +16163,11 @@ cp_parser_decomposition_declaration (cp_
  declarator->id_loc = e.get_location ();
}
   tree elt_pushed_scope;
+  tree attr = NULL_TREE;
+  if (first_attr != -1 && i >= (unsigned) first_attr)
+   attr = v[++i].get_value ();
   tree decl2 = start_decl (declarator, _specs, SD_DECOMPOSITION,
-  NULL_TREE, NULL_TREE, _pushed_scope);
+  NULL_TREE, attr, _pushed_scope);
   if (decl2 == error_mark_node)
decl = error_mark_node;
   else if (decl != error_mark_node && DECL_CHAIN (decl2) != prev)
@@ -16183,7 +16210,7 @@ cp_parser_decomposition_declaration (cp_
 
   if (decl != error_mark_node)
{
- cp_decomp decomp = { prev, v.length () };
+ cp_decomp decomp = { prev, cnt };
  cp_finish_decl (decl, initializer, non_constant_p, NULL_TREE,
  (is_direct_init ? LOOKUP_NORMAL : LOOKUP_IMPLICIT),
  );
@@ -16193,7 +16220,7 @@ cp_parser_decomposition_declaration (cp_
   else if (decl != error_mark_node)
 {
   *maybe_range_for_decl = prev;
-  cp_decomp decomp = { prev, v.length () };
+  cp_decomp decomp = { prev, cnt };
   /* Ensure DECL_VALUE_EXPR is created for all the decls but
 the 

Re: [PATCH] RISC-V: Fix parsing of Zic* extensions

[Christoph Müllner]

On Mon, Apr 29, 2024 at 5:58 AM Kito Cheng  wrote:
>
> OK for trunk, and my understanding is that flag isn't really used in
> code gen yet, so it's not necessary to port to GCC 14 branch?

Pushed to master.

Since the riscv_zi_subext masks of the affected extensions are applied
to higher bits of riscv_zicmo_subext (beyond Zicbom, Zicbop, Zicboz),
this triggers indeed no issue in GCC 14 (because the TARGET_ZI* macros
are not used). Therefore, no backport to GCC 14.

Thanks!

>
> On Mon, Apr 29, 2024 at 7:05 AM Christoph Müllner
>  wrote:
> >
> > The extension parsing table entries for a range of Zic* extensions
> > does not match the mask definition in riscv.opt.
> > This results in broken TARGET_ZIC* macros, because the values of
> > riscv_zi_subext and riscv_zicmo_subext are set wrong.
> >
> > This patch fixes this by moving Zic64b into riscv_zicmo_subext
> > and all other affected Zic* extensions to riscv_zi_subext.
> >
> > gcc/ChangeLog:
> >
> > * common/config/riscv/riscv-common.cc: Move ziccamoa, ziccif,
> > zicclsm, and ziccrse into riscv_zi_subext.
> > * config/riscv/riscv.opt: Define MASK_ZIC64B for
> > riscv_ziccmo_subext.
> >
> > Signed-off-by: Christoph Müllner 
> > ---
> >  gcc/common/config/riscv/riscv-common.cc | 8 
> >  gcc/config/riscv/riscv.opt  | 4 ++--
> >  2 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/gcc/common/config/riscv/riscv-common.cc 
> > b/gcc/common/config/riscv/riscv-common.cc
> > index 43b7549e3ec..8cc0e727737 100644
> > --- a/gcc/common/config/riscv/riscv-common.cc
> > +++ b/gcc/common/config/riscv/riscv-common.cc
> > @@ -1638,15 +1638,15 @@ static const riscv_ext_flag_table_t 
> > riscv_ext_flag_table[] =
> >
> >{"zihintntl", _options::x_riscv_zi_subext, MASK_ZIHINTNTL},
> >{"zihintpause", _options::x_riscv_zi_subext, MASK_ZIHINTPAUSE},
> > +  {"ziccamoa", _options::x_riscv_zi_subext, MASK_ZICCAMOA},
> > +  {"ziccif", _options::x_riscv_zi_subext, MASK_ZICCIF},
> > +  {"zicclsm", _options::x_riscv_zi_subext, MASK_ZICCLSM},
> > +  {"ziccrse", _options::x_riscv_zi_subext, MASK_ZICCRSE},
> >
> >{"zicboz", _options::x_riscv_zicmo_subext, MASK_ZICBOZ},
> >{"zicbom", _options::x_riscv_zicmo_subext, MASK_ZICBOM},
> >{"zicbop", _options::x_riscv_zicmo_subext, MASK_ZICBOP},
> >{"zic64b", _options::x_riscv_zicmo_subext, MASK_ZIC64B},
> > -  {"ziccamoa", _options::x_riscv_zicmo_subext, MASK_ZICCAMOA},
> > -  {"ziccif", _options::x_riscv_zicmo_subext, MASK_ZICCIF},
> > -  {"zicclsm", _options::x_riscv_zicmo_subext, MASK_ZICCLSM},
> > -  {"ziccrse", _options::x_riscv_zicmo_subext, MASK_ZICCRSE},
> >
> >{"zve32x",   _options::x_target_flags, MASK_VECTOR},
> >{"zve32f",   _options::x_target_flags, MASK_VECTOR},
> > diff --git a/gcc/config/riscv/riscv.opt b/gcc/config/riscv/riscv.opt
> > index b14888e9816..ee824756381 100644
> > --- a/gcc/config/riscv/riscv.opt
> > +++ b/gcc/config/riscv/riscv.opt
> > @@ -237,8 +237,6 @@ Mask(ZIHINTPAUSE) Var(riscv_zi_subext)
> >
> >  Mask(ZICOND)  Var(riscv_zi_subext)
> >
> > -Mask(ZIC64B)  Var(riscv_zi_subext)
> > -
> >  Mask(ZICCAMOA)Var(riscv_zi_subext)
> >
> >  Mask(ZICCIF)  Var(riscv_zi_subext)
> > @@ -390,6 +388,8 @@ Mask(ZICBOM) Var(riscv_zicmo_subext)
> >
> >  Mask(ZICBOP) Var(riscv_zicmo_subext)
> >
> > +Mask(ZIC64B) Var(riscv_zicmo_subext)
> > +
> >  TargetVariable
> >  int riscv_zf_subext
> >
> > --
> > 2.44.0
> >

[PATCH] PHIOPT: Value-replacement check undef

[Andrew Pinski]

While moving value replacement part of PHIOPT over
to use match-and-simplify, I ran into the case where
we would have an undef use that was conditional become
unconditional. This prevents that. I can't remember at this
point what the testcase was though.

Bootstrapped and tested on x86_64-linux-gnu with no regressions.

gcc/ChangeLog:

* tree-ssa-phiopt.cc (value_replacement): Reject undef variables
so they don't become unconditional used.

Signed-off-by: Andrew Pinski 
---
 gcc/tree-ssa-phiopt.cc | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/gcc/tree-ssa-phiopt.cc b/gcc/tree-ssa-phiopt.cc
index a2bdcb5eae8..f166c3132cb 100644
--- a/gcc/tree-ssa-phiopt.cc
+++ b/gcc/tree-ssa-phiopt.cc
@@ -1146,6 +1146,13 @@ value_replacement (basic_block cond_bb, basic_block 
middle_bb,
   if (code != NE_EXPR && code != EQ_EXPR)
 return 0;
 
+  /* Do not make conditional undefs unconditional.  */
+  if ((TREE_CODE (arg0) == SSA_NAME
+   && ssa_name_maybe_undef_p (arg0))
+  || (TREE_CODE (arg1) == SSA_NAME
+ && ssa_name_maybe_undef_p (arg1)))
+return false;
+
   /* If the type says honor signed zeros we cannot do this
  optimization.  */
   if (HONOR_SIGNED_ZEROS (arg1))
-- 
2.43.0

Re: [PATCH v1] RISC-V: Fix ICE for legitimize move on subreg const_poly_move

[Kito Cheng]

> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 0519e0679ed..bad23ea487f 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -2786,6 +2786,44 @@ riscv_v_adjust_scalable_frame (rtx target, poly_int64 
> offset, bool epilogue)
>REG_NOTES (insn) = dwarf;
> }
> +/* Take care below subreg const_poly_int move:
> +
> +   1. (set (subreg:DI (reg:TI 237) 8)
> +(subreg:DI (const_poly_int:TI [4, 2]) 8))
> +  =>
> +  (set (subreg:DI (reg:TI 237) 8)
> +(const_int 0)) */
> +
> +static bool
> +riscv_legitimize_subreg_const_poly_move (machine_mode mode, rtx dest, rtx 
> src)
> +{
> +  gcc_assert (SUBREG_P (src) && CONST_POLY_INT_P (SUBREG_REG (src)));
> +  gcc_assert (SUBREG_BYTE (src).is_constant ());
> +
> +  int byte_offset = SUBREG_BYTE (src).to_constant ();
> +  rtx const_poly = SUBREG_REG (src);
> +  machine_mode subreg_mode = GET_MODE (const_poly);
> +
> +  if (subreg_mode != TImode) /* Only TImode is needed for now.  */
> +return false;
> +
> +  if (byte_offset == 8)
> +{ /* The const_poly_int cannot exceed int64, just set zero here.  */

{
 /* The const_poly_int cannot exceed int64, just set zero here.  */

New line for the comment.

> +  emit_move_insn (dest, CONST0_RTX (mode));
> +  return true;
> +}
> +
> +  /* The below transform will be covered in somewhere else.
> + Thus, ignore this here.
> +   1. (set (subreg:DI (reg:TI 237) 0)
> +(subreg:DI (const_poly_int:TI [4, 2]) 0))
> +  =>
> +  (set (subreg:DI (reg:TI 237) 0)
> +(const_poly_int:DI [4, 2])) */
> +
> +  return false;
> +}
> +
> /* If (set DEST SRC) is not a valid move instruction, emit an equivalent
> sequence that is valid.  */
> @@ -2839,6 +2877,11 @@ riscv_legitimize_move (machine_mode mode, rtx dest, 
> rtx src)
> }
>return true;
>  }
> +
> +  if (SUBREG_P (src) && CONST_POLY_INT_P (SUBREG_REG (src))
> +&& riscv_legitimize_subreg_const_poly_move (mode, dest, src))
> +return true;
> +
>/* Expand
> (set (reg:DI target) (subreg:DI (reg:V8QI reg) 0))
>   Expand this data movement instead of simply forbid it since
> --
> 2.34.1
>
>

Re: [PATCH] ppc: testsuite: pr79004 needs -mlong-double-128

[Alexandre Oliva]

On Apr 28, 2024, "Kewen.Lin"  wrote:

> OK, from this perspective IMHO it seems more clear to adopt xfail
> with effective target long_double_64bit?

*nod*, yeah, that makes sense.

I'm going to travel this week, to speak at FSF's LibrePlanet conference,
so I'll look into massaging the patch into that when I get back, if you
haven't rendered it obsolete by then ;-)

Thanks,

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

Re: [PATCH] adjust vectorization expectations for ppc costmodel 76b

[Alexandre Oliva]

On Apr 28, 2024, "Kewen.Lin"  wrote:

> Nit: Maybe add a prefix "testsuite: ".

ACK

>> 
>> From: Kewen Lin 

> Thanks, you can just drop this.  :)

I've turned it into Co-Authored-By, since you insist.

But unfortunately with the patch it still fails when testing for
-mcpu=power7 on ppc64le-linux-gnu: it does vectorize the loop with 13
iterations.  We need 16 iterations, as in an earlier version of this
test, for it to pass for -mcpu=power7, but then it doesn't pass for
-mcpu=power6.

It looks like we're going to have to adjust the expectations.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive