[PATCH v2] RISC-V: Recognized Svrsw60t59b extension

[Mingzhu Yan]

This patch support svrsw60t59b extension[1].
To enable GCC to recognize and process svrsw60t59b extension correctly at 
compile time.

[1] https://github.com/riscv/Svrsw60t59b

gcc/ChangeLog:

* common/config/riscv/riscv-common.cc:
(riscv_ext_version_table) New extension.
(riscv_ext_flag_table) Ditto.
* config/riscv/riscv-opts.h: New mask.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/arch-45.c: New test.

gcc/doc:

* doc/invoke.texi(RISC-V Options): New extension

Signed-off-by: Mingzhu Yan 
---
 gcc/common/config/riscv/riscv-common.cc  | 16 +---
 gcc/config/riscv/riscv.opt   |  2 ++
 gcc/doc/invoke.texi  |  4 
 gcc/testsuite/gcc.target/riscv/arch-45.c |  5 +
 4 files changed, 20 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/arch-45.c

diff --git a/gcc/common/config/riscv/riscv-common.cc 
b/gcc/common/config/riscv/riscv-common.cc
index b34409adf..c104cc335 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -409,10 +409,11 @@ static const struct riscv_ext_version 
riscv_ext_version_table[] =
   {"ssstateen", ISA_SPEC_CLASS_NONE, 1, 0},
   {"sstc",  ISA_SPEC_CLASS_NONE, 1, 0},
 
-  {"svinval", ISA_SPEC_CLASS_NONE, 1, 0},
-  {"svnapot", ISA_SPEC_CLASS_NONE, 1, 0},
-  {"svpbmt",  ISA_SPEC_CLASS_NONE, 1, 0},
-  {"svvptc",  ISA_SPEC_CLASS_NONE, 1, 0},
+  {"svinval", ISA_SPEC_CLASS_NONE, 1, 0},
+  {"svnapot", ISA_SPEC_CLASS_NONE, 1, 0},
+  {"svpbmt",  ISA_SPEC_CLASS_NONE, 1, 0},
+  {"svvptc",  ISA_SPEC_CLASS_NONE, 1, 0},
+  {"svrsw60t59b", ISA_SPEC_CLASS_NONE, 1, 0},
 
   {"xcvmac", ISA_SPEC_CLASS_NONE, 1, 0},
   {"xcvalu", ISA_SPEC_CLASS_NONE, 1, 0},
@@ -1732,9 +1733,10 @@ static const riscv_ext_flag_table_t 
riscv_ext_flag_table[] =
   RISCV_EXT_FLAG_ENTRY ("zcmp", x_riscv_zc_subext, MASK_ZCMP),
   RISCV_EXT_FLAG_ENTRY ("zcmt", x_riscv_zc_subext, MASK_ZCMT),
 
-  RISCV_EXT_FLAG_ENTRY ("svinval", x_riscv_sv_subext, MASK_SVINVAL),
-  RISCV_EXT_FLAG_ENTRY ("svnapot", x_riscv_sv_subext, MASK_SVNAPOT),
-  RISCV_EXT_FLAG_ENTRY ("svvptc", x_riscv_sv_subext, MASK_SVVPTC),
+  RISCV_EXT_FLAG_ENTRY ("svinval", x_riscv_sv_subext, MASK_SVINVAL),
+  RISCV_EXT_FLAG_ENTRY ("svnapot", x_riscv_sv_subext, MASK_SVNAPOT),
+  RISCV_EXT_FLAG_ENTRY ("svvptc",  x_riscv_sv_subext, MASK_SVVPTC),
+  RISCV_EXT_FLAG_ENTRY ("svrsw60t59b", x_riscv_sv_subext, MASK_SVRSW60T59B),
 
   RISCV_EXT_FLAG_ENTRY ("ztso", x_riscv_ztso_subext, MASK_ZTSO),
 
diff --git a/gcc/config/riscv/riscv.opt b/gcc/config/riscv/riscv.opt
index 7515c8ea1..4c6387ab7 100644
--- a/gcc/config/riscv/riscv.opt
+++ b/gcc/config/riscv/riscv.opt
@@ -472,6 +472,8 @@ Mask(SVNAPOT) Var(riscv_sv_subext)
 
 Mask(SVVPTC) Var(riscv_sv_subext)
 
+Mask(SVRSW60T59B) Var(riscv_sv_subext)
+
 TargetVariable
 int riscv_ztso_subext
 
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 1819bcdcd..7e61106c5 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -31234,6 +31234,10 @@ to @samp{zvks} and @samp{zvkg}.
 @tab 1.0
 @tab Page-based memory types extension.
 
+@item svrsw60t59b
+@tab 1.0
+@tab PTE Reserved-for-Software Bits 60-59 extension.
+
 @item xcvmac
 @tab 1.0
 @tab Core-V multiply-accumulate extension.
diff --git a/gcc/testsuite/gcc.target/riscv/arch-45.c 
b/gcc/testsuite/gcc.target/riscv/arch-45.c
new file mode 100644
index 0..fe3ee441d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/arch-45.c
@@ -0,0 +1,5 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gc_svrsw60t59b -mabi=lp64" } */
+int foo()
+{
+}
-- 
2.43.0

New Croatian PO file for 'gcc' (version 15.1-b20250316)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Croatian team of translators.  The file is available at:

https://translationproject.org/latest/gcc/hr.po

(This file, 'gcc-15.1-b20250316.hr.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

RE: [PATCH] libgcobol: Add configure checks for iconv.

[Robert Dubner]

> -Original Message-
> From: Iain Sandoe 
> Sent: Thursday, March 20, 2025 08:20
> To: rdub...@symas.com; gcc-patches@gcc.gnu.org
> Subject: [PATCH] libgcobol: Add configure checks for iconv.
> 
> Tested on x86_64 Linux, Darwin, OK for trunk?
> thanks
> Iain

I ran my full test suite, including EBCDIC tests.

Everything passes; I see no adverse affects.

LGTM

> 
> --- 8< ---
> 
> Some targets might need to add libraries to get iconv support.
> 
> libgcobol/ChangeLog:
> 
>   * Makefile.am: Use LIBICONV.
>   * Makefile.in: Regenerate.
>   * aclocal.m4: Regenerate.
>   * config.h.in: Regenerate.
>   * configure: Regenerate.
>   * configure.ac: Check for iconv support.
> 
> Signed-off-by: Iain Sandoe 
> ---
>  libgcobol/Makefile.am  |   2 +-
>  libgcobol/Makefile.in  |   8 +-
>  libgcobol/aclocal.m4   |   4 +
>  libgcobol/config.h.in  |   6 +
>  libgcobol/configure| 914 -
>  libgcobol/configure.ac |   3 +
>  6 files changed, 933 insertions(+), 4 deletions(-)
> 
> diff --git a/libgcobol/Makefile.am b/libgcobol/Makefile.am
> index eddf209807e..888cbf2b0b0 100644
> --- a/libgcobol/Makefile.am
> +++ b/libgcobol/Makefile.am
> @@ -48,7 +48,7 @@ libgcobol_la_LINK = $(LIBTOOL) --mode=link --tag=CXX
> $(CXX)\
>   -Wc,-shared-libgcc  \
>   -version-info $(LIBGCOBOL_VERSION)  \
>   -lstdc++\
> - $(LTLDFLAGS)
> + $(LTLDFLAGS) $(LTLIBICONV)
> 
>  WARN_CFLAGS = -W -Wall -Wwrite-strings
> 
> diff --git a/libgcobol/Makefile.in b/libgcobol/Makefile.in
> index a6096d2a64a..1a1e2ee39eb 100644
> --- a/libgcobol/Makefile.in
> +++ b/libgcobol/Makefile.in
> @@ -113,7 +113,11 @@ target_triplet = @target@
>  subdir = .
>  ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
>  am__aclocal_m4_deps = $(top_srcdir)/../config/depstand.m4 \
> + $(top_srcdir)/../config/iconv.m4 \
>   $(top_srcdir)/../config/lead-dot.m4 \
> + $(top_srcdir)/../config/lib-ld.m4 \
> + $(top_srcdir)/../config/lib-link.m4 \
> + $(top_srcdir)/../config/lib-prefix.m4 \
>   $(top_srcdir)/../config/multi.m4 \
>   $(top_srcdir)/../config/override.m4 \
>   $(top_srcdir)/../config/toolexeclibdir.m4 \
> @@ -300,11 +304,13 @@ INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
>  LD = @LD@
>  LDFLAGS = @LDFLAGS@
>  LIBGCOBOL_VERSION = @LIBGCOBOL_VERSION@
> +LIBICONV = @LIBICONV@
>  LIBOBJS = @LIBOBJS@
>  LIBS = @LIBS@
>  LIBTOOL = @LIBTOOL@
>  LIPO = @LIPO@
>  LN_S = @LN_S@
> +LTLIBICONV = @LTLIBICONV@
>  LTLIBOBJS = @LTLIBOBJS@
>  MAINT = @MAINT@
>  MAKEINFO = @MAKEINFO@
> @@ -422,7 +428,7 @@ libgcobol_la_LINK = $(LIBTOOL) --mode=link --tag=CXX
> $(CXX)\
>   -Wc,-shared-libgcc  \
>   -version-info $(LIBGCOBOL_VERSION)  \
>   -lstdc++\
> - $(LTLDFLAGS)
> + $(LTLDFLAGS) $(LTLIBICONV)
> 
>  WARN_CFLAGS = -W -Wall -Wwrite-strings
> 
> diff --git a/libgcobol/aclocal.m4 b/libgcobol/aclocal.m4
> index 1d5125ec2f0..25c8b71df87 100644
> --- a/libgcobol/aclocal.m4
> +++ b/libgcobol/aclocal.m4
> @@ -1188,7 +1188,11 @@ AC_SUBST([am__untar])
>  ]) # _AM_PROG_TAR
> 
>  m4_include([../config/depstand.m4])
> +m4_include([../config/iconv.m4])
>  m4_include([../config/lead-dot.m4])
> +m4_include([../config/lib-ld.m4])
> +m4_include([../config/lib-link.m4])
> +m4_include([../config/lib-prefix.m4])
>  m4_include([../config/multi.m4])
>  m4_include([../config/override.m4])
>  m4_include([../config/toolexeclibdir.m4])
> diff --git a/libgcobol/config.h.in b/libgcobol/config.h.in
> index 39b20448078..a7e5675c43c 100644
> --- a/libgcobol/config.h.in
> +++ b/libgcobol/config.h.in
> @@ -6,6 +6,9 @@
>  /* Define to 1 if you have the  header file. */
>  #undef HAVE_DLFCN_H
> 
> +/* Define if you have the iconv() function and it works. */
> +#undef HAVE_ICONV
> +
>  /* Define to 1 if you have the  header file. */
>  #undef HAVE_INTTYPES_H
> 
> @@ -36,6 +39,9 @@
>  /* Define to 1 if you have the  header file. */
>  #undef HAVE_UNISTD_H
> 
> +/* Define as const if the declaration of iconv() needs const. */
> +#undef ICONV_CONST
> +
>  /* Define to the sub-directory in which libtool stores uninstalled
> libraries.
> */
>  #undef LT_OBJDIR
> diff --git a/libgcobol/configure b/libgcobol/configure
> index 73433ebb13d..1db4e792e03 100755
> --- a/libgcobol/configure
> +++ b/libgcobol/configure
> @@ -634,6 +634,8 @@ ac_subst_vars='am__EXEEXT_FALSE
>  am__EXEEXT_TRUE
>  LTLIBOBJS
>  LIBOBJS
> +LTLIBICONV
> +LIBICONV
>  extra_darwin_ldflags_libgcobol
>  VERSION_SUFFIX
>  LIBGCOBOL_VERSION
> @@ -804,6 +806,9 @@ enable_fast_install
>  with_gnu_ld
>  enable_libtool_lock
>  enable_darwin_at_rpath
> +enable_rpath
> +with_libiconv_prefix
> +with_libiconv_type
>  '
>ac_precious_vars='build_alias
>  host_alias
> @@ -1456,6 +14

Re: [PATCH][RFC] [cobol] change cbl_field_data_t::etc_t::value from _Float128 to tree

[Iain Sandoe]

> On 20 Mar 2025, at 19:00, Robert Dubner  wrote:
> 
> 
> 
>> -Original Message-
>> From: Richard Biener 
>> Sent: Thursday, March 20, 2025 10:16
>> To: gcc-patches@gcc.gnu.org
>> Cc: Jakub Jelinek ; rdub...@symas.com
>> Subject: Re: [PATCH][RFC] [cobol] change cbl_field_data_t::etc_t::value
>> from _Float128 to tree
>> 
>> On Thu, 20 Mar 2025, Richard Biener wrote:
>> 

>> Can you possibly test this on the full testsuite?
> 
> Forgive me:  I can't figure out how to get my source code to where yours
> must be.

In case it helps…
… here is a short branch based on trunk r15-8468-ga1363f8dd8037d
(you need also one patch that’s already landed)

https://github.com/iains/gcc-git/commits/master-wip-cobol-posted/

It contains the two patches I posted + the three that Richi posted.

(you should be able to cherry-pick Richi’s three in order off that to save 
messing
 with extracting them from mail messages).

My patches are independent of richi’s so you can ignore them in testing the 
second
set.

HTH
Iain

Re: [PATCH][RFC] [cobol] change cbl_field_data_t::etc_t::value from _Float128 to tree

[Iain Sandoe]

> On 20 Mar 2025, at 14:15, Richard Biener  wrote:
> 
> On Thu, 20 Mar 2025, Richard Biener wrote:
> 
>> The following removes the main instance of _Float128 use in the cobol
>> frontend and replaces it with a tree for cbl_field_data_t::etc_t::value
>> and with REAL_VALUE_TYPE in some helpers.
>> 
>> The default value is changed to a float128_type_node zero from 0.0.
>> 
>> get_power_of_ten was picked from Jakubs PR119242 patch, it doesn't build on
>> its own so I've included it here.
>> 
>> Together with the other two pending changes (the one already approved
>> and '[cobol] move global data to symbol_table_init'), this compiles
>> and passes the majority of cobol tests.  As expected there is some
>> fallout which is at the moment
>> 
>> FAIL: cobol.dg/group1/display2.cob   -O0  output pattern test
>> 
>> (fails at all optimization levels), probably related to the
>> _Float128 <-> string conversions.  The failure is
>> 
>> Output was:
>> 1.e+0 
>> 2.e+0
>> 
>> Should match:
>> 1 2
>> 
>> I don't know which of the many _Float128 <-> string conversions is
>> guilty here.
> 
> I've fixed that now, the following patch ontop of
> '[cobol] make sources coretypes.h and tree.h clean' and
> '[cobol] move global data to symbol_table_init' passes build and
> the cobol testsuite as it is in GCC right now.

This improves the testsuite output for current testsuite + darwin**.  I have 
now only
two failing tests (one related to iconv, for which I have a patch, and one 
stilll to be
analysed.
(one comment inline)
thanks,
Iain

** this also requires the libquadmath conversion too.

> 
> Can you possibly test this on the full testsuite?
> 
> Thanks,
> Richard.
> 
> From 0cb5fae11f109a7fcd94da98e203a730c3ecfee4 Mon Sep 17 00:00:00 2001
> From: Richard Biener 
> Date: Thu, 20 Mar 2025 11:08:01 +0100
> Subject: [PATCH] [cobol] change cbl_field_data_t::etc_t::value from _Float128
> to tree
> To: gcc-patches@gcc.gnu.org
> 
> The following removes the main instance of _Float128 use in the cobol
> frontend and replaces it with a tree for cbl_field_data_t::etc_t::value
> and with REAL_VALUE_TYPE in some helpers.
> 
> The default value is changed to a float128_type_node zero from 0.0.
> 
> get_power_of_ten was picked from Jakubs PR119242 patch, it doesn't build on
> its own so I've included it here.
> 
>   PR cobol/119241
>   PR cobol/119242
>   * genutil.h (get_power_of_ten): Return FIXED_WIDE_INT(128).
>   * genutil.cc (get_power_of_ten): Produce FIXED_WIDE_INT(128)
>   instead of __int128.
>   (scale_by_power_of_ten_N): Adjust.
>   (copy_little_endian_into_place): Likewise.
>   * genapi.cc (mh_source_is_literalN): Likewise.
>   * symbols.h (cbl_field_data_t::etc_t::value): Make a tree.
>   (cbl_field_data_t::etc_t::etc_t): Adjust.
>   (cbl_field_data_t::cbl_field_data_t): Likewise.
>   (cbl_field_data_t::value_of): Likewise.
>   (cbl_field_data_t::operator=): Likewise.
>   (cbl_field_data_t::valify): Likewise.
>   * symbols.cc (cbl_occurs_t::subscript_ok): Likewise.
>   * genapi.h (initial_from_float128): Remove.
>   * genapi.cc (initial_from_float128): Make local and adjust.
>   (initialize_variable_internal): Adjust.
>   (get_binary_value_from_float): Likewise.
>   (psa_FldLiteralN): Simplify.
>   (parser_display_internal): Adjust.
>   (mh_source_is_literalN): Likewise.
>   (real_powi10): New helper.
>   (binary_initial_from_float128): Adjust.
>   (digits_from_float128): Likewise.
>   (parser_symbol_add): Likewise.
>   * parse.y (YYVAL): Use REAL_VALUE_TYPE instead of _Float128.
>   (string_of): Adjust and add overload from tree.
>   (field): Adjust.
>   (const_value): Likewise.
>   (value78): Likewise.
>   (data_descr1): Likewise.
>   (value_clause): Likewise.
>   (allocate): Likewise.
>   (move_tgt): Likewise.
>   (cc_expr): Likewise.
>   (cce_factor): Likewise.
>   (literal_refmod_valid): Likewise.
> 
> Co-authored-by: Jakub Jelinek 
> ---
> gcc/cobol/genapi.cc  | 218 +++
> gcc/cobol/genapi.h   |   3 -
> gcc/cobol/genutil.cc |  26 +++---
> gcc/cobol/genutil.h  |   2 +-
> gcc/cobol/parse.y| 118 +--
> gcc/cobol/symbols.cc |  15 ++-
> gcc/cobol/symbols.h  |  21 +++--
> 7 files changed, 220 insertions(+), 183 deletions(-)
> 
> diff --git a/gcc/cobol/genapi.cc b/gcc/cobol/genapi.cc
> index 8f4f9b21370..7f1b78dbf9a 100644
> --- a/gcc/cobol/genapi.cc
> +++ b/gcc/cobol/genapi.cc
> @@ -52,6 +52,7 @@
> #include "../../libgcobol/charmaps.h"
> #include "../../libgcobol/valconv.h"
> #include "show_parse.h"
> +#include "fold-const.h"
> 
> extern int yylineno;
> 
> @@ -1041,7 +1042,9 @@ initialize_variable_internal( cbl_refer_t refer,
>   default:
> {
> char ach[128];
> -strfromf128(ach, sizeof(ach), "%.16E", 
> parse

Re: COBOL: Implementation of STOP RUN / GOBACK [was: [PATCH][v3] Simple cobol.dg testsuite]

[James K. Lowden]

On Mar 13, 2025, at 8:04 AM, Simon Sobisch  wrote:
> 
> exit() allows us to "pass to the operating system" directly; but it doesn't 
> directly say "success" or "fail".
> 
> 
> Obviously the statements
>   STOP RUN WITH NORMAL STATUS 41
> and
>   STOP RUN ERROR 41
> 
> Should have a different result for the operating system.

Or, obviously not.  

For OSes I'm familiar with, there is no *definition* of success/failure.  
There's just convention: 0 is success and nonzero failure.  Even that is 
honored in the breach, see diff(1).  

IMO unless the OS defines success/failure outside the value of the exit status 
value (above, 41), the COBOL compiler cannot supply meaning to STOP RUN NORMAL 
or ERROR.  It has no meaning in COBOL because it has no meaning outside COBOL.  

By that reasoning, the two statements above both return 41 because there is no 
way to say more.  It is for the caller to decide what to do.  

I do not think -41 is an option; the compiler should not make arbitrary changes 
to the user's data.  

It is temping to raise(SIG_TERM) for error, but again the 41 is lost.  

> STOP RUN WITH ERROR "Don't do that, Jon!"

When no numeric value is supplied, IMO: 

• STOP RUN WITH NORMAL STATUS becomes exit(EXIT_SUCCESS)
• STOP RUN WITH ERROR becomes exit(EXIT_FAILURE)

That satisfies the Principle of Least Astonishment.  BTW those values are 
defined by C, not POSIX.  

--jkl

Re: [PATCH][RFC] [cobol] change cbl_field_data_t::etc_t::value from _Float128 to tree

[Jakub Jelinek]

On Thu, Mar 20, 2025 at 03:30:30PM -0500, Robert Dubner wrote:
> Let me find one inky-dink example.  Talk amongst yourselves...here we go.
> 
> identification  division.
> program-id. prog.
> datadivision.
> working-storage section.
> 77 var8 PIC 999V9(8) COMP-5 .
> 77 var555 PIC 999V COMP-5 VALUE 555..
> procedure   division.
> move 555. to var8
> add 0.0001 TO var555 giving var8 rounded
> if var8 not equal to 555.5556 display var8 " should be
> 555.5556".
> end program prog.
> 
> With your patches, the output is
>   
>   555. should be 555.5556

Thanks.
Now, the code certainly could try to do the rounding of the last digits
based on the remaining digits in the string that are being discarded,
if followed by 0-4, don't change anything, if followed by 6-9, increase
last digit, if followed by 5 and any non-zero digit, increase too, if followed
by 5 and all zeros, round to even.
But I'm afraid it can have double rounding, when round_to_decimal rounds
for the precision 33 printing something e.g. with 4999 at
the end to 5000 and this second rounding again.
So I really think we should go to mpfr, I can implement it tomorrow unless
Richi wants to do that.

Jakub

[Fortran, Patch, PR119349, v1] Fix regression of polymorphic dummy sourced from array constructors.

[Andre Vehreschild]

Hi all,

attached patch fixes a 15-regression where an element of an actual
temporary array, i.e., elemental([ e1, e2...]) passed to the formal polymorphic
dummy leads to a double free of the derived types components. This patch
prevents this by preventing the deallocation of the array constructors
temporary, when the formal is polymorphic. ...

Folks its so hard to explain this in prose. I rewrote above paragraph the third
time now. And I still don't understand on re-reading. So here is some pseudo
code:

struct derived {
  char *c; // This is the component suffering from double-free
};

derived[2] atmp = [ derived(""), derived("")]

forall a in atmp
  derived t_a = a; // <- Copy of a, but no deep copy, i.e. t_a.c == a.c
  class_temp = class_derived(a); // set _vtype left out for brevity
  call elemental_function(class_temp);
  if (class_temp._data.c != NULL)
free(class_temp._data.c); // and set it to NULL
  if (t_a.c != NULL)
free(t_a.c); // BOOM, this is freeing the same c
end

Generating the last if-block and the free is what this patch prevents for
polymorphic dummys that stem from an array construction. And only for those.

Sorry, I am having a hard time explaining things today. So I hope the code
above will do.

Regtested ok on x86_64-pc-linux-gnu / F41. Ok for mainline?

Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 8f9c24fe01a1e34bea2e1c95102329562abdb9e1 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild 
Date: Thu, 20 Mar 2025 13:37:21 +0100
Subject: [PATCH] Fortran: Fix double free on polymorphic array dummy argument
 [PR119349]

Calling elemental routines with polymorphic formals leads to generation
of a temporary polymorphic variable and code for its deallocation.
Sourcing this element from an array constructor the latter now is
prevented from generating a second deallocation.

	PR fortran/119349

gcc/fortran/ChangeLog:

	* trans-expr.cc (gfc_conv_procedure_call): Prevent deallocation
	of array temporary for polymorphic temporary argument.

gcc/testsuite/ChangeLog:

	* gfortran.dg/class_79.f90: New test.
---
 gcc/fortran/trans-expr.cc  |  6 +-
 gcc/testsuite/gfortran.dg/class_79.f90 | 25 +
 2 files changed, 30 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/class_79.f90

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index d965539f11e..923d46cb47c 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -7994,7 +7994,11 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 	  gfc_add_expr_to_block (&se->post, local_tmp);
 	}

-	  if (!finalized && !e->must_finalize)
+	  /* Items of array expressions passed to a polymorphic formal arguments
+	 create their own clean up, so prevent double free.  */
+	  if (!finalized && !e->must_finalize
+	  && !(e->expr_type == EXPR_ARRAY && fsym
+		   && fsym->ts.type == BT_CLASS))
 	{
 	  bool scalar_res_outside_loop;
 	  scalar_res_outside_loop = e->expr_type == EXPR_FUNCTION
diff --git a/gcc/testsuite/gfortran.dg/class_79.f90 b/gcc/testsuite/gfortran.dg/class_79.f90
new file mode 100644
index 000..a2226e47aff
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/class_79.f90
@@ -0,0 +1,25 @@
+!{ dg-do run }
+
+! Check double free on array constructor in argument list is fixed.
+! Contributed by Damian Rouson  
+program pr119349
+  implicit none
+
+  type string_t
+character(len=:), allocatable :: string_
+  end type
+
+  print *, true([string()])
+
+contains
+
+  type(string_t) function string()
+string%string_ = ""
+  end function
+
+  logical elemental function true(rhs)
+class(string_t), intent(in) :: rhs
+true = .true.
+  end function
+
+end program
--
2.48.1

Re: [PATCH v2 1/3] libstdc++: Use formatting locale for std::time_put formats

[Jonathan Wakely]

On Thu, 20 Mar 2025 at 16:16, Jonathan Wakely  wrote:
>
> When using std::time_put to format a chrono value, we should imbue the
> formatting locale into the stream. This ensures that when
> std::time_put::do_put uses a ctype or __timepunct facet from the locale,
> it gets the correct facets.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/chrono_io.h (__formatter_chrono::_M_locale_fmt):
> Imbue locale into ostringstream.
> * testsuite/std/time/format/localized.cc: Check that correct
> locale is used for call to time_put::put.
> ---
>
> Now with a test that shows the bug independent of the PR117214 patches
> to use std::time_put for %c formats.
>
> Tested x86_64-linux.
>
>  libstdc++-v3/include/bits/chrono_io.h |  1 +
>  .../testsuite/std/time/format/localized.cc| 30 +++
>  2 files changed, 31 insertions(+)
>
> diff --git a/libstdc++-v3/include/bits/chrono_io.h 
> b/libstdc++-v3/include/bits/chrono_io.h
> index c16b555df29..55ebd4ee061 100644
> --- a/libstdc++-v3/include/bits/chrono_io.h
> +++ b/libstdc++-v3/include/bits/chrono_io.h
> @@ -1697,6 +1697,7 @@ namespace __format
>   char __fmt, char __mod) const
> {
>   basic_ostringstream<_CharT> __os;
> + __os.imbue(__loc);
>   const auto& __tp = use_facet>(__loc);
>   __tp.put(__os, __os, _S_space, &__tm, __fmt, __mod);
>   if (__os)
> diff --git a/libstdc++-v3/testsuite/std/time/format/localized.cc 
> b/libstdc++-v3/testsuite/std/time/format/localized.cc
> index 393d0d200e4..437a4a011b2 100644
> --- a/libstdc++-v3/testsuite/std/time/format/localized.cc
> +++ b/libstdc++-v3/testsuite/std/time/format/localized.cc
> @@ -13,6 +13,7 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -81,6 +82,35 @@ test_en()
>  }
>  }
>
> +void
> +test_locale_imbued()
> +{
> +  // Custom time_put facet which returns %b string for %Om
> +  struct TimePut : std::time_put
> +  {
> +iter_type
> +do_put(iter_type out, std::ios_base& io, char_type fill, const tm* t,
> +  char format, char modifier) const override
> +{
> +  if (format == 'm' && modifier == 'O')
> +   format = 'b';
> +  return std::time_put::do_put(out, io, fill, t, format, 0);
> +}
> +  };
> +
> +  auto m = std::chrono::March;
> +
> +  std::locale fr(ISO_8859(1,fr_FR));
> +  std::locale fr2(fr, new TimePut);
> +  auto s1 = std::format(fr2, "{:L%Om}", m);
> +  VERIFY( s1 == std::format(fr, "{:L}", m) );
> +
> +  std::locale es(ISO_8859(1,es_ES));
> +  std::locale es2(es, new TimePut);
> +  auto s2 = std::format(es2, "{:L%Om}", m);
> +  VERIFY( s2 == std::format(es, "{:L}", m) );
> +}
> +
>  int main()
>  {
>test_ru();

It would help if I added the new test_locale_imbued() function to main
so that it actually runs.

Luckily it passes when I do that.

[PATCH 09/10] testsuite: aarch64: arm: Fix -mfpu=auto support in fp16_neon_ok

[Christophe Lyon]

Like a previous patch, replace "" with -mfpu=auto to match the
intended effect of -march=armv8.2-a+fp16.

No visible change because the effect is masked by other effective
targets used in the tests, done for consistency.

gcc/testsuite/
* lib/target-supports.exp
(check_effective_target_arm_v8_2a_bf16_neon_ok_nocache):
Conditionally use -mfpu=auto.
---
 gcc/testsuite/lib/target-supports.exp | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index c2df22d2255..587db04b95e 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -6661,6 +6661,7 @@ proc 
check_effective_target_arm_v8_2a_fp16_neon_ok_nocache { } {
 global et_arm_v8_2a_fp16_neon_flags
 set et_arm_v8_2a_fp16_neon_flags ""
 set cpu_unset ""
+set fpu_auto ""
 
 if { ![istarget arm*-*-*] && ![istarget aarch64*-*-*] } {
return 0;
@@ -6668,12 +6669,15 @@ proc 
check_effective_target_arm_v8_2a_fp16_neon_ok_nocache { } {
 
 if { [istarget arm*-*-*] } {
set cpu_unset "-mcpu=unset"
+   set fpu_auto "-mfpu=auto"
 }
 
 # Iterate through sets of options to find the compiler flags that
 # need to be added to the -march option.
-foreach flags {"" "-mfpu=neon-fp-armv8" "-mfloat-abi=softfp" \
-  "-mfpu=neon-fp-armv8 -mfloat-abi=softfp"} {
+foreach flags [list "$fpu_auto" \
+  "-mfpu=neon-fp-armv8" \
+  "-mfloat-abi=softfp" \
+  "-mfpu=neon-fp-armv8 -mfloat-abi=softfp"] {
if { [check_no_compiler_messages_nocache \
  arm_v8_2a_fp16_neon_ok object {
#if !defined (__ARM_FEATURE_FP16_VECTOR_ARITHMETIC)
-- 
2.34.1

Re: [PATCH v2 2/2] PR119376: Disable clang musttail

[Jakub Jelinek]

On Thu, Mar 20, 2025 at 10:01:02AM -0700, Andi Kleen wrote:
> So it could be as simple as that patch?  It solves your test case at least
> for x86.

Not sure I like this, but if others (e.g. Richi, Joseph, Jason) are ok with
it I can live with it.  But we'd need a good documentation, ideally some
some new warning about it (perhaps enabled in -Wextra) and testcase
coverage.
Looking around, clang warns for
int foo (int *);
int bar (int *x)
{
  *x = 42;
  int a = 0;
  [[clang::musttail]] return foo (&a);
}
by default (without -Wall/-Wextra) with
warning: address of stack memory associated with local variable 'a' passed to 
musttail function [-Wreturn-stack-address]
Dunno if that warning is about other stuff or just that.
If just that, perhaps we'd need multiple levels for it, diagnose passing
those to musttail arguments by default and have in -Wextra stronger variant
that would diagnose even the
int baz (int *x)
{
  *x = 42;
  int a = 0;
  foo (&a);
  [[clang::musttail]] return foo (nullptr);
}
case, i.e. escaped variables that are still in scope.
That variant of the warning perhaps should suggest to users to end the
lifetime of those variables before the musttail call.

> --- a/gcc/tree-tailcall.cc
> +++ b/gcc/tree-tailcall.cc
> @@ -722,8 +722,9 @@ find_tail_calls (basic_block bb, struct tailcall **ret, 
> bool only_musttail,
> {
>   if (local_live_vars)
> BITMAP_FREE (local_live_vars);
> - maybe_error_musttail (call,
> -   _("call invocation refers to locals"));
> + /* Allow this for musttail to match clang semantics of 
> musttail.  */
> + if (gimple_call_must_tail_p (call))
> +   continue;
>   return;
> }
>   else
> @@ -732,8 +733,9 @@ find_tail_calls (basic_block bb, struct tailcall **ret, 
> bool only_musttail,
>   if (bitmap_bit_p (local_live_vars, *v))
> {
>   BITMAP_FREE (local_live_vars);
> - maybe_error_musttail (call,
> -   _("call invocation refers to 
> locals"));
> + /* Allow this for musttail to match clang semantics of 
> musttail.  */
> + if (gimple_call_must_tail_p (call))
> +   continue;
>   return;
> }
> }

Jakub

[PATCH] tree-optimization/119389 - limit edge processing in dominated_by_p_w_unex

[Richard Biener]

The following removes quadraticness when visiting each predecessor
of a large CFG merge with dominated_by_p_w_unex.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

PR tree-optimization/119389
* tree-ssa-sccvn.cc (dominated_by_p_w_unex): Limit the number
of predecessors of a CFG merge we try to skip.
---
 gcc/tree-ssa-sccvn.cc | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/gcc/tree-ssa-sccvn.cc b/gcc/tree-ssa-sccvn.cc
index 40c38fa020a..481ab8b243d 100644
--- a/gcc/tree-ssa-sccvn.cc
+++ b/gcc/tree-ssa-sccvn.cc
@@ -5172,7 +5172,11 @@ dominated_by_p_w_unex (basic_block bb1, basic_block bb2, 
bool allow_back)
   /* Iterate to the single successor of bb2 with only a single executable
  incoming edge.  */
   else if (EDGE_COUNT (bb2->succs) == 1
-  && EDGE_COUNT (single_succ (bb2)->preds) > 1)
+  && EDGE_COUNT (single_succ (bb2)->preds) > 1
+  /* Limit the number of edges we check, we should bring in
+ context from the iteration and compute the single
+ executable incoming edge when visiting a block.  */
+  && EDGE_COUNT (single_succ (bb2)->preds) < 8)
 {
   edge prede = NULL;
   FOR_EACH_EDGE (e, ei, single_succ (bb2)->preds)
-- 
2.43.0

gcc-patches@gcc.gnu.org

[Jonathan Wakely]

I forgot I'd tweaked my git-send-email settings and so this patch
didn't get sent to gcc-patches, sorry. Resending ...


On 20/03/25 18:52 +, Jonathan Wakely wrote:

Tomasz suggested replacing this constructor with just append_range(rg),
after using a delegating constructor so that the destructor will run if
append_range exits via an exception.

This is slightly less simple than his suggestion, because I want to
avoid the overhead of reserve's slow path and the ASan annotations.
Neither of those is needed for this constructor, because we have no
existing storage to reallocate and no unused capacity to tell ASan
about.

libstdc++-v3/ChangeLog:

* include/bits/stl_vector.h (vector(from_range_t, Alloc)): Use
delegating constructor instead of RAII guards. Use append_range
for unsized input range case.
---

Tested x86_64-linux.


 libstdc++-v3/include/bits/stl_vector.h | 20 ++--
 1 file changed, 2 insertions(+), 18 deletions(-)

diff --git a/libstdc++-v3/include/bits/stl_vector.h 
b/libstdc++-v3/include/bits/stl_vector.h
index 9c75f64b6ef..09fd53696d1 100644
--- a/libstdc++-v3/include/bits/stl_vector.h
+++ b/libstdc++-v3/include/bits/stl_vector.h
@@ -758,7 +758,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   template<__detail::__container_compatible_range<_Tp> _Rg>
constexpr
vector(from_range_t, _Rg&& __rg, const _Alloc& __a = _Alloc())
-   : _Base(__a)
+   : vector(__a)
{
  if constexpr (ranges::forward_range<_Rg> || ranges::sized_range<_Rg>)
{
@@ -766,28 +766,12 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
  pointer __start =
this->_M_allocate(_S_check_init_len(__n,
_M_get_Tp_allocator()));
- _Guard_alloc __guard(__start, __n, *this);
  this->_M_impl._M_finish = this->_M_impl._M_start = __start;
  this->_M_impl._M_end_of_storage = __start + __n;
  _Base::_M_append_range(__rg);
- (void) __guard._M_release();
}
  else
-   {
- // If an exception is thrown ~_Base() will deallocate storage,
- // but will not destroy elements. This RAII type destroys them.
- struct _Clear
- {
-   constexpr ~_Clear() { if (_M_this) _M_this->clear(); }
-   vector* _M_this;
- } __guard{this};
-
- auto __first = ranges::begin(__rg);
- const auto __last = ranges::end(__rg);
- for (; __first != __last; ++__first)
-   emplace_back(*__first);
- __guard._M_this = nullptr;
-   }
+   append_range(std::move(__rg));
}
 #endif

--
2.49.0

Re: [PATCH 1/2] libstdc++: Add views::cache_latest and views::to_input to std module

[Tomasz Kaminski]

On Thu, Mar 20, 2025 at 8:19 PM Jonathan Wakely  wrote:

> Also export the tuple-like helpers from , and the
> std::from_range_t and std::from_range tag.
>
> libstdc++-v3/ChangeLog:
>
> * src/c++23/std.cc.in (tuple_element, tuple_element_t)
> (tuple_size, tuple_size_v, get): Export.
> (ranges::cache_latest_view, views::cache_latest): Export.
> (ranges::to_input_view, views::to_input): Export.
> (from_range_t, from_range): Export.
> ---
>
> Tested by compiling and importing std and briefly testing the imported
> features.
>
LGTM

>
>  libstdc++-v3/src/c++23/std.cc.in | 23 ---
>  1 file changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/libstdc++-v3/src/c++23/std.cc.in b/libstdc++-v3/src/c++23/
> std.cc.in
> index c0b7e1dc727..12253b95c5a 100644
> --- a/libstdc++-v3/src/c++23/std.cc.in
> +++ b/libstdc++-v3/src/c++23/std.cc.in
> @@ -924,6 +924,13 @@ export namespace std
>using std::sqrt;
>using std::tan;
>using std::tanh;
> +#if __cpp_lib_tuple_like >= 202311L
> +  using std::tuple_element;
> +  using std::tuple_element_t;
> +  using std::tuple_size;
> +  using std::tuple_size_v;
> +  using std::get;
> +#endif
>  }
>  export namespace std::inline literals::inline complex_literals
>  {
> @@ -2383,14 +2390,24 @@ export namespace std
>  using ranges::enumerate_view;
>  namespace views { using views::enumerate; }
>  #endif
> -#if __cpp_lib_ranges_to_container // C++ >= 23
> -using ranges::to;
> -#endif // __cpp_lib_ranges_to_container
>  #if __cpp_lib_ranges_concat // C++ >= C++26
>  using ranges::concat_view;
>  namespace views { using views::concat; }
> +#endif
> +#if __cpp_lib_ranges_cache_latest // C++ >= C++26
> +using ranges::cache_latest_view;
> +namespace views { using views::cache_latest; }
> +#endif
> +#if __glibcxx_ranges_to_input // C++ >= 26
> +using ranges::to_input_view;
> +namespace views { using views::to_input; }
>  #endif
>}
> +#if __glibcxx_ranges_to_container // C++ >= 23
> +  namespace ranges { using ranges::to; }
> +  using std::from_range_t;
> +  using std::from_range;
> +#endif
>  }
>
>  // 
> --
> 2.49.0
>
>

Re: [PATCH 1/8] aarch64: Use PAUTH instead of V8_3A in some places

[Alfie Richards]

Hi all,

This commit applies cleanly to GCC 14 and fixes PR119372.

Bootstrapped and regtested on aarch64-linux-gnu.

Okay for gcc 14 backport?

Alfie Richards

On 08/10/2024 16:46, Richard Sandiford wrote:

Andrew Carlotti  writes:

gcc/ChangeLog:

* config/aarch64/aarch64.cc
(aarch64_expand_epilogue): Use TARGET_PAUTH.
* config/aarch64/aarch64.md: Update comment.


diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 
e7bb3278a27eca44c46afd26069d608218198a54..cf1107127fd5d9e12ad42441528666bf6b733f73
 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -10042,12 +10042,12 @@ aarch64_expand_epilogue (rtx_call_insn *sibcall)
1) Sibcalls don't return in a normal way, so if we're about to call one
   we must authenticate.
  
-	2) The RETAA instruction is not available before ARMv8.3-A, so if we are

-  generating code for !TARGET_ARMV8_3 we can't use it and must
+   2) The RETAA instruction is not available without FEAT_PAuth, so if we
+  are generating code for !TARGET_PAUTH we can't use it and must
   explicitly authenticate.
  */
if (aarch64_return_address_signing_enabled ()
-  && (sibcall || !TARGET_ARMV8_3))
+  && (sibcall || !TARGET_PAUTH))
  {
switch (aarch64_ra_sign_key)
{
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 
c54b29cd64b9e0dc6c6d12735049386ccedc5408..0940a84f9295ee2bc07282b150095fdb5af11a4d
 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -7672,10 +7672,10 @@
  )
  
  ;; Pointer authentication patterns are always provided.  In architecture

-;; revisions prior to ARMv8.3-A these HINT instructions operate as NOPs.
+;; revisions prior to FEAT_PAuth these HINT instructions operate as NOPs.


I suppose this should be something like "On targets that don't implement
FEAT_PAuth".  OK with that change, thanks.

Richard


  ;; This lets the user write portable software which authenticates pointers
-;; when run on something which implements ARMv8.3-A, and which runs
-;; correctly, but does not authenticate pointers, where ARMv8.3-A is not
+;; when run on something which implements FEAT_PAuth, and which runs
+;; correctly, but does not authenticate pointers, where FEAT_PAuth is not
  ;; implemented.
  
  ;; Signing/Authenticating R30 using SP as the salt.

Re: [PATCH] RISC-V: Recognized Svrsw60t59b extension

[Craig Blackmore]

On 20/03/2025 08:11, Mingzhu Yan wrote:

This patch support svrsw60t59b extension[1].
To enable GCC to recognize and process svrsw60t59b extension correctly at 
compile time.

[1] https://github.com/riscv/Svrsw60t59b

gcc/ChangeLog:

 * common/config/riscv/riscv-common.cc: New extension.
 * config/riscv/riscv-opts.h: New mask.

gcc/testsuite/ChangeLog:

 * gcc.target/riscv/arch-45.c: New test.

Signed-off-by: Mingzhu Yan 
---
  gcc/common/config/riscv/riscv-common.cc  | 16 +---
  gcc/config/riscv/riscv.opt   |  2 ++
  gcc/doc/invoke.texi  |  8 
  gcc/testsuite/gcc.target/riscv/arch-45.c |  5 +
  4 files changed, 24 insertions(+), 7 deletions(-)
  create mode 100644 gcc/testsuite/gcc.target/riscv/arch-45.c

diff --git a/gcc/common/config/riscv/riscv-common.cc 
b/gcc/common/config/riscv/riscv-common.cc
index 5038f0eb959..418bd10a132 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -409,10 +409,11 @@ static const struct riscv_ext_version 
riscv_ext_version_table[] =
{"ssstateen", ISA_SPEC_CLASS_NONE, 1, 0},
{"sstc",  ISA_SPEC_CLASS_NONE, 1, 0},
  
-  {"svinval", ISA_SPEC_CLASS_NONE, 1, 0},

-  {"svnapot", ISA_SPEC_CLASS_NONE, 1, 0},
-  {"svpbmt",  ISA_SPEC_CLASS_NONE, 1, 0},
-  {"svvptc",  ISA_SPEC_CLASS_NONE, 1, 0},
+  {"svinval", ISA_SPEC_CLASS_NONE, 1, 0},
+  {"svnapot", ISA_SPEC_CLASS_NONE, 1, 0},
+  {"svpbmt",  ISA_SPEC_CLASS_NONE, 1, 0},
+  {"svvptc",  ISA_SPEC_CLASS_NONE, 1, 0},
+  {"svrsw60t59b", ISA_SPEC_CLASS_NONE, 1, 0},
  
{"xcvmac", ISA_SPEC_CLASS_NONE, 1, 0},

{"xcvalu", ISA_SPEC_CLASS_NONE, 1, 0},
@@ -1732,9 +1733,10 @@ static const riscv_ext_flag_table_t 
riscv_ext_flag_table[] =
RISCV_EXT_FLAG_ENTRY ("zcmp", x_riscv_zc_subext, MASK_ZCMP),
RISCV_EXT_FLAG_ENTRY ("zcmt", x_riscv_zc_subext, MASK_ZCMT),
  
-  RISCV_EXT_FLAG_ENTRY ("svinval", x_riscv_sv_subext, MASK_SVINVAL),

-  RISCV_EXT_FLAG_ENTRY ("svnapot", x_riscv_sv_subext, MASK_SVNAPOT),
-  RISCV_EXT_FLAG_ENTRY ("svvptc", x_riscv_sv_subext, MASK_SVVPTC),
+  RISCV_EXT_FLAG_ENTRY ("svinval", x_riscv_sv_subext, MASK_SVINVAL),
+  RISCV_EXT_FLAG_ENTRY ("svnapot", x_riscv_sv_subext, MASK_SVNAPOT),
+  RISCV_EXT_FLAG_ENTRY ("svvptc",  x_riscv_sv_subext, MASK_SVVPTC),
+  RISCV_EXT_FLAG_ENTRY ("svrsw60t59b", x_riscv_sv_subext, MASK_SVVPTC),


I think this should be MASK_SVRSW60T59B.

  
RISCV_EXT_FLAG_ENTRY ("ztso", x_riscv_ztso_subext, MASK_ZTSO),
  
diff --git a/gcc/config/riscv/riscv.opt b/gcc/config/riscv/riscv.opt

index 7515c8ea13d..4c6387ab709 100644
--- a/gcc/config/riscv/riscv.opt
+++ b/gcc/config/riscv/riscv.opt
@@ -472,6 +472,8 @@ Mask(SVNAPOT) Var(riscv_sv_subext)
  
  Mask(SVVPTC) Var(riscv_sv_subext)
  
+Mask(SVRSW60T59B) Var(riscv_sv_subext)

+
  TargetVariable
  int riscv_ztso_subext
  
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi

index 0c7adc039b5..5adc27b45e0 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi


This file is missing from the ChangeLog.


@@ -31188,6 +31188,14 @@ to @samp{zvks} and @samp{zvkg}.
  @tab 1.0
  @tab Page-based memory types extension.
  
+@item svvptc

+@tab 1.0
+@tab Obviating Memory-Management Instructions after Marking PTEs Valid 
extension.


Adding missing documentation for svvptc seems unrelated, so may be 
better as a separate patch.


Thanks,
Craig


+
+@item svrsw60t59b
+@tab 1.0
+@tab PTE Reserved-for-Software Bits 60-59 extension.
+
  @item xcvmac
  @tab 1.0
  @tab Core-V multiply-accumulate extension.
diff --git a/gcc/testsuite/gcc.target/riscv/arch-45.c 
b/gcc/testsuite/gcc.target/riscv/arch-45.c
new file mode 100644
index 000..fe3ee441d49
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/arch-45.c
@@ -0,0 +1,5 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gc_svrsw60t59b -mabi=lp64" } */
+int foo()
+{
+}

Re: [PATCH v2 2/2] PR119376: Disable clang musttail

[Jason Merrill]

On 3/19/25 9:31 PM, Andi Kleen wrote:

From: Andi Kleen 

There are multiple reports (see PR 119376) now where semantic differences
in the gcc musttail implementation break existing programs written for the clang
variant.

Even though that can be all hopefully fixed eventually,
for the gcc 15 release it seems safer to disable clang::musttail,
and only keep gnu::musttail.


This seems like a last resort to take if we aren't able to fix the 
issues by the time we're ready to release.  Looks like Jakub has a patch 
to fix 119376.



That means that programs that use __has_c_attribute to check for
clang::musttail must opt-in explicitly.

Reported-by: Sam James

gcc/c/ChangeLog:

PR ipa/119376
* c-parser.cc (c_parser_handle_musttail): Drop clang namespace
check.

gcc/cp/ChangeLog:

PR ipa/119376
* parser.cc (cp_parser_jump_statement): Drop clang namespace
check.

gcc/ChangeLog:

PR ipa/119376
* doc/extend.texi: Drop clang::musttail reference.

gcc/testsuite/ChangeLog:

PR ipa/119376
* c-c++-common/musttail23.c: Don't use clang::musttail
* c-c++-common/musttail24.c: Dito.
* c-c++-common/musttail3.c: Dito.
* g++.dg/musttail14.C: Dito.
---
  gcc/c/c-parser.cc   |  5 -
  gcc/cp/parser.cc|  6 --
  gcc/doc/extend.texi |  2 +-
  gcc/testsuite/c-c++-common/musttail23.c | 10 +-
  gcc/testsuite/c-c++-common/musttail24.c |  6 --
  gcc/testsuite/c-c++-common/musttail3.c  |  6 +++---
  gcc/testsuite/g++.dg/musttail14.C   |  4 ++--
  7 files changed, 11 insertions(+), 28 deletions(-)

diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index d49d5c58659..79654448aca 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -7409,11 +7409,6 @@ c_parser_handle_musttail (c_parser *parser, tree std_attrs, 
attr_state &attr)
  std_attrs = remove_attribute ("gnu", "musttail", std_attrs);
  attr.musttail_p = true;
}
-  if (lookup_attribute ("clang", "musttail", std_attrs))
-   {
- std_attrs = remove_attribute ("clang", "musttail", std_attrs);
- attr.musttail_p = true;
-   }
  }
return std_attrs;
  }
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 2fb1dc5992d..da7700b55c6 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -15342,12 +15342,6 @@ cp_parser_jump_statement (cp_parser* parser, tree 
&std_attrs)
musttail_p = true;
std_attrs = remove_attribute ("gnu", "musttail", std_attrs);
  }
-   /* Support this for compatibility.  */
-   if (lookup_attribute ("clang", "musttail", std_attrs))
- {
-   musttail_p = true;
-   std_attrs = remove_attribute ("clang", "musttail", std_attrs);
- }
  
  	tree ret_expr = expr;

if (ret_expr && TREE_CODE (ret_expr) == TARGET_EXPR)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index b919df91464..50f95e968ff 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -10241,7 +10241,7 @@ have to optimize it to just @code{return 42 + 42;}.
  @cindex @code{musttail} statement attribute
  @item musttail
  
-The @code{gnu::musttail} or @code{clang::musttail} standard attribute

+The @code{gnu::musttail} standard attribute
  or @code{musttail} GNU attribute can be applied to a @code{return} statement
  with a return-value expression that is a function call.  It asserts that the
  call must be a tail call that does not allocate extra stack space, so it is
diff --git a/gcc/testsuite/c-c++-common/musttail23.c 
b/gcc/testsuite/c-c++-common/musttail23.c
index d2ba70b0325..1ceab116512 100644
--- a/gcc/testsuite/c-c++-common/musttail23.c
+++ b/gcc/testsuite/c-c++-common/musttail23.c
@@ -19,10 +19,10 @@ foo (int x)
  [[gnu::musttail (1, "", 3)]] return bar (); /* { dg-error 
"'musttail' attribute does not take any arguments" } */
/* { dg-error "expected" 
"" { target c } .-1 } */
if (x == 3)
-[[clang::musttail (1)]] return bar (); /* { dg-error "'musttail' 
attribute does not take any arguments" } */
+[[gnu::musttail (1)]] return bar ();   /* { dg-error "'musttail' 
attribute does not take any arguments" } */
/* { dg-error "expected" 
"" { target c } .-1 } */
if (x == 4)
-[[clang::musttail (1, "", 3)]] return bar ();/* { dg-error "'musttail' 
attribute does not take any arguments" } */
+[[gnu::musttail (1, "", 3)]] return bar ();  /* { dg-error "'musttail' 
attribute does not take any arguments" } */
/* { dg-error "expected" 
"" { target c } .-1 } */
if (x == 5)
  __attribute__((fallthrough, musttail)) return bar (); /* { dg-warning "attribute 
'musttail' mixed with other attribu

Re: [PATCH] libstdc++: Add from_range_t constructors to debug ordered containers

[Jonathan Wakely]

On Thu, 20 Mar 2025 at 11:18, Tomasz Kamiński  wrote:
>
> libstdc++-v3/ChangeLog:
>
> * include/debug/unordered_map (unordered_map): Add from_range
> constructors and deduction guides.
> (unordered_multimap): Likewise.
> * include/debug/unordered_set (unordered_set): Add from_range
> constructors and deduction guides.
> (unordered_multiset): Likewise.
> ---
> As noticed by Jonathan, new ctors and deduction guides where not
> added to debug versions
>
> Testing on x86_64-linux, unordered_* test passed with -D_GLIBCXX_DEBUG.
> OK for trunk?

OK, thanks for the quick fix.


>  libstdc++-v3/include/debug/unordered_map | 141 +++
>  libstdc++-v3/include/debug/unordered_set | 131 +
>  2 files changed, 272 insertions(+)
>
> diff --git a/libstdc++-v3/include/debug/unordered_map 
> b/libstdc++-v3/include/debug/unordered_map
> index eb9590ac8e7..16d4a4a98e0 100644
> --- a/libstdc++-v3/include/debug/unordered_map
> +++ b/libstdc++-v3/include/debug/unordered_map
> @@ -201,6 +201,34 @@ namespace __debug
>: unordered_map(__l, __n, __hf, key_equal(), __a)
>{ }
>
> +#if __glibcxx_ranges_to_container // C++ >= 23
> +  template<__detail::__container_compatible_range _Rg>
> +   unordered_map(from_range_t, _Rg&& __rg,
> + size_type __n = 0,
> + const hasher& __hf = hasher(),
> + const key_equal& __eql = key_equal(),
> + const allocator_type& __a = allocator_type())
> +   : _Base(from_range, std::forward<_Rg>(__rg), __n, __hf, __eql, __a)
> +{ }
> +
> +  template<__detail::__container_compatible_range _Rg>
> +   unordered_map(from_range_t, _Rg&& __rg, const allocator_type& __a)
> +   : _Base(from_range, std::forward<_Rg>(__rg), __a)
> +{ }
> +
> +  template<__detail::__container_compatible_range _Rg>
> +   unordered_map(from_range_t, _Rg&& __rg, size_type __n,
> + const allocator_type& __a)
> +   : _Base(from_range, std::forward<_Rg>(__rg), __n, __a)
> +{ }
> +
> +  template<__detail::__container_compatible_range _Rg>
> +   unordered_map(from_range_t, _Rg&& __rg, size_type __n,
> + const hasher& __hf, const allocator_type& __a)
> +   : _Base(from_range, std::forward<_Rg>(__rg), __n, __hf, __a)
> +{ }
> +#endif
> +
>~unordered_map() = default;
>
>unordered_map&
> @@ -841,6 +869,47 @@ namespace __debug
>   _Hash, _Allocator)
>  -> unordered_map<_Key, _Tp, _Hash, equal_to<_Key>, _Allocator>;
>
> +#if __glibcxx_ranges_to_container // C++ >= 23
> +  template +  __not_allocator_like _Hash = hash<__detail::__range_key_type<_Rg>>,
> +  __not_allocator_like _Pred = 
> equal_to<__detail::__range_key_type<_Rg>>,
> +  __allocator_like _Allocator =
> +allocator<__detail::__range_to_alloc_type<_Rg>>>
> +unordered_map(from_range_t, _Rg&&, unordered_map::size_type = 
> {},
> + _Hash = _Hash(), _Pred = _Pred(), _Allocator = _Allocator())
> +-> unordered_map<__detail::__range_key_type<_Rg>,
> +__detail::__range_mapped_type<_Rg>,
> +_Hash, _Pred, _Allocator>;
> +
> +  template +  __allocator_like _Allocator>
> +unordered_map(from_range_t, _Rg&&, unordered_map::size_type,
> + _Allocator)
> +-> unordered_map<__detail::__range_key_type<_Rg>,
> +__detail::__range_mapped_type<_Rg>,
> +hash<__detail::__range_key_type<_Rg>>,
> +equal_to<__detail::__range_key_type<_Rg>>,
> +_Allocator>;
> +
> +  template +  __allocator_like _Allocator>
> +unordered_map(from_range_t, _Rg&&, _Allocator)
> +-> unordered_map<__detail::__range_key_type<_Rg>,
> +__detail::__range_mapped_type<_Rg>,
> +hash<__detail::__range_key_type<_Rg>>,
> +equal_to<__detail::__range_key_type<_Rg>>,
> +_Allocator>;
> +
> +  template +  __not_allocator_like _Hash,
> +  __allocator_like _Allocator>
> +unordered_map(from_range_t, _Rg&&, unordered_map::size_type,
> + _Hash, _Allocator)
> +-> unordered_map<__detail::__range_key_type<_Rg>,
> +__detail::__range_mapped_type<_Rg>,
> +_Hash, equal_to<__detail::__range_key_type<_Rg>>,
> +_Allocator>;
> +#endif
>  #endif
>
>template @@ -1008,6 +1077,34 @@ namespace __debug
>: unordered_multimap(__l, __n, __hf, key_equal(), __a)
>{ }
>
> +#if __glibcxx_ranges_to_container // C++ >= 23
> +  template<__detail::__container_compatible_range _Rg>
> +   unordered_multimap(from_range_t, _Rg&& __rg,
> +  size_type __n = 0,
> +  const hasher& __hf = hasher

[PATCH] wwwdocs: Document changes to the D front-end

[Iain Buclaw]

Hi,

This patch adds D front-end section to the GCC changes pages. When
inspecting this, I noticed that the previous two releases has been
missed/forgot about as well.

Ran all pages through the w3c validator and got no reported errors.

OK?

Thanks,
Iain.

---
* htdocs/gcc-13/changes.html: Add D changes section.
* htdocs/gcc-14/changes.html: Likewise.
* htdocs/gcc-15/changes.html: Likewise.
---
 htdocs/gcc-13/changes.html | 69 +-
 htdocs/gcc-14/changes.html | 10 +-
 htdocs/gcc-15/changes.html | 14 +++-
 3 files changed, 90 insertions(+), 3 deletions(-)

diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 4860c500..aa7556a2 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -434,7 +434,74 @@ You may also want to check out our
   
 
 
-
+D
+
+  Support for the D programming language has been updated to version
+2.103.1 of the language and run-time library. Full changelog for this
+release and previous releases can be found on the
+https://dlang.org/changelog/2.103.1.html";>dlang.org
+website.
+  
+  The following GCC attributes are now recognized and available from
+the gcc.attributes module with short-hand aliases for
+convenience:
+
+  @attribute("no_sanitize", arguments) or
+@no_sanitize(arguments).
+  
+  @attribute("register") or
+@register.
+  
+  @attribute("simd") or @simd.
+  @attribute("simd_clones", mask) or
+@simd_clones(mask).
+  
+  @attribute("visibility", arguments) or
+@visibility(arguments).
+  
+
+  
+  New aliases have been added to gcc.attributes for
+compatibility with ldc.attributes.
+
+  The @hidden attribute is an alias for
+@attribute("visibility", "hidden").
+  
+  The @noSanitize attribute is an alias for
+@attribute("no_sanitize").
+  
+
+  
+  Vector operation intrinsics prefetch,
+  loadUnaligned, storeUnaligned,
+  shuffle, shufflevector,
+  extractelement, insertelement,
+  convertvector, and blendvector have been added
+  to the gcc.simd module.
+  
+  New warnings:
+
+  https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gdc/Warnings.html#index-Wno-builtin-declaration-mismatch";>-Wbuiltin-declaration-mismatch=
+   warns when a built-in function is declared with the wrong signature.
+  
+  https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gdc/Warnings.html#index-Wmismatched-special-enum";>-Wmismatched-special-enum
+   warns when a special enum is declared with the wrong base type.
+  
+
+  
+  New version identifier D_Optimized is now predefined when 
the
+-O option, or any higher optimization level is used.
+  
+  The predefinition of version D_Exceptions can now by
+controlled by the option -fexception.
+  
+  The predefinition of version D_TypeInfo can now by
+  controlled by the option -frtti.
+  
+  The -fdebug= and -fversion= compiler
+switches no longer accept an integer argument.
+  
+
 
 Fortran
 
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 8ff84582..df5ebc6e 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -602,7 +602,15 @@ You may also want to check out our
   
 
 
-
+D
+
+  Support for the D programming language has been updated to version
+2.108.1 of the language and run-time library. Full changelog for this
+release and previous releases can be found on the
+https://dlang.org/changelog/2.108.1.html";>dlang.org
+website.
+  
+
 
 Fortran
 
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index 42b713a2..968d5c17 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -423,7 +423,19 @@ asm (".text; %cc0: mov %cc2, %%r0; .previous;"
   
 
 
-
+D
+
+  Support for the D programming language has been updated to version
+2.111.0 of the language and run-time library. Full changelog for this
+release and previous releases can be found on the
+https://dlang.org/changelog/2.111.0.html";>dlang.org
+website.
+  
+  On supported targets, the version GNU_CET is now predefined
+when the option -fcf-protection is used. The protection level
+is also set in the traits key __traits(getTargetInfo, "CET").
+  
+
 
 Fortran
 
-- 
2.43.0

[PATCH] gimple: sccopy: Don't increment i after vec::unordered_remove()

[Filip Kastl]

Hi,

Ok to push if bootstrap and regtest (on x86_64 linux) succeeds?

Thanks,
Filip Kastl


-- 8< --


I increment the index variable in a loop even when I do
vec::unordered_remove() which causes the vector traversal to miss some
elements.  Mikael notified me of this mistake I made in my last patch.

gcc/ChangeLog:

* gimple-ssa-sccopy.cc (scc_copy_prop::propagate): Don't
increment after vec::unordered_remove().

Reported-by: Mikael Morin 
Signed-off-by: Filip Kastl 
---
 gcc/gimple-ssa-sccopy.cc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/gimple-ssa-sccopy.cc b/gcc/gimple-ssa-sccopy.cc
index 298feb05571..ee2a7fa8a72 100644
--- a/gcc/gimple-ssa-sccopy.cc
+++ b/gcc/gimple-ssa-sccopy.cc
@@ -582,9 +582,11 @@ scc_copy_prop::propagate ()
 get removed.  That means parts of CFG get removed.  Those may
 contain copy statements.  For that reason we prune SCCs here.  */
   unsigned i;
-  for (i = 0; i < scc.length (); i++)
+  for (i = 0; i < scc.length ();)
if (gimple_bb (scc[i]) == NULL)
  scc.unordered_remove (i);
+   else
+ i++;
   if (scc.is_empty ())
{
  scc.release ();
-- 
2.47.1

Re: [PATCH] cobol: Fifteen new cobol.dg testscases.

[Andreas Schwab]

On Mär 17 2025, Robert Dubner wrote:

> diff --git a/gcc/testsuite/cobol.dg/group1/check_88.cob
> b/gcc/testsuite/cobol.dg/group1/check_88.cob
> new file mode 100644
> index ..4a7723eb92a3
> --- /dev/null
> +++ b/gcc/testsuite/cobol.dg/group1/check_88.cob
> @@ -0,0 +1,101 @@
> +*> { dg-do run }
> +*> { dg-output {\-><\-(\n|\r\n|\r)} }
> +*> { dg-output {\->   <\-(\n|\r\n|\r)} }
> +*> { dg-output {\->"""<\-(\n|\r\n|\r)} }
> +*> { dg-output {\->000<\-(\n|\r\n|\r)} }
> +*> { dg-output {\->ÿÿÿ<\-(\n|\r\n|\r)} }
> +*> { dg-output { (\n|\r\n|\r)} }
> +*> { dg-output {\-><\-(\n|\r\n|\r)} }
> +*> { dg-output {\-><\-(\n|\r\n|\r)} }
> +*> { dg-output {\-><\-(\n|\r\n|\r)} }
> +*> { dg-output {\-><\-(\n|\r\n|\r)} }
> +*> { dg-output {\-><\-(\n|\r\n|\r)} }

That doesn't match.  The output contains "\377\377\377\377", but "ÿ" is
"\303\277".

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[PATCH] cobol: Do not overload int64_t, overload long and long long.

[Iain Sandoe]

Tested on x86_64 linux/darwin, aarch64 linux, OK for trunk?
thanks
Iain

--- 8< ---

Since the type that is used for int64_t varies between platforms trying
to overload it creates ambiguous or conflicting overloads.  Therefore,
just overload 'long' and 'long long'.

gcc/cobol/ChangeLog:

* cdfval.h (struct cdfval_t): Overload long instead of int64_t.

Signed-off-by: Iain Sandoe 
---
 gcc/cobol/cdfval.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/cobol/cdfval.h b/gcc/cobol/cdfval.h
index 1453f2af5f8..4682db8074b 100644
--- a/gcc/cobol/cdfval.h
+++ b/gcc/cobol/cdfval.h
@@ -79,7 +79,7 @@ struct cdfval_t : public cdfval_base_t {
 cdfval_base_t::string = NULL;
 cdfval_base_t::number = value;
   }
-  cdfval_t( int64_t value )
+  cdfval_t( long value )
 : lineno(yylineno), filename(cobol_filename())
   {
 cdfval_base_t::off  = false;
-- 
2.39.2 (Apple Git-143)

[COMMITTED 054/144] gccrs: Perform lowering hir output operand to tree

[arthur . cohen]

From: badumbatish 

gcc/rust/ChangeLog:

* backend/rust-compile-asm.cc (CompileAsm::asm_build_expr):
Add debug comment
(CompileAsm::asm_construct_outputs):
Perform lowering hir output operand to tree
---
 gcc/rust/backend/rust-compile-asm.cc | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/gcc/rust/backend/rust-compile-asm.cc 
b/gcc/rust/backend/rust-compile-asm.cc
index 32ad84e60e7..d179c355f21 100644
--- a/gcc/rust/backend/rust-compile-asm.cc
+++ b/gcc/rust/backend/rust-compile-asm.cc
@@ -26,6 +26,7 @@ CompileAsm::asm_build_expr (HIR::InlineAsm &expr)
   ASM_BASIC_P (asm_expr) = expr.is_simple_asm ();
   ASM_VOLATILE_P (asm_expr) = false;
   ASM_INLINE_P (asm_expr) = expr.is_inline_asm ();
+  /*Backend::debug (asm_expr);*/
   return asm_expr;
 }
 
@@ -91,8 +92,17 @@ CompileAsm::asm_construct_outputs (HIR::InlineAsm &expr)
  == AST::InlineAsmOperand::RegisterType::Out)
{
  auto out = output.get_out ();
+
  tree out_tree = CompileExpr::Compile (out.expr.get (), this->ctx);
- Backend::debug (out_tree);
+ // expects a tree list
+ // TODO: This assumes that the output is a register
+ std::string expr_name = "=r";
+ auto name = build_string (expr_name.size () + 1, expr_name.c_str ());
+ head
+   = chainon (head, build_tree_list (build_tree_list (NULL_TREE, name),
+ out_tree));
+
+ /*Backend::debug (head);*/
  /*head = chainon (head, out_tree);*/
}
 }
-- 
2.45.2

[COMMITTED 025/144] gccrs: Move errors with locations

[arthur . cohen]

From: Kushal Pal 

gcc/rust/ChangeLog:

* checks/errors/borrowck/rust-borrow-checker-diagnostics.cc
(BorrowCheckerDiagnostics::report_move_errors): Specify
locations for code causing errors and related moves.

gcc/testsuite/ChangeLog:

* rust/borrowck/test_move.rs: Test rich-errors related to moves.
* rust/borrowck/test_move_conditional.rs: Likewise.

Signed-off-by: Kushal Pal 
---
 .../rust-borrow-checker-diagnostics.cc| 39 ++--
 gcc/testsuite/rust/borrowck/test_move.rs  | 22 +++--
 .../rust/borrowck/test_move_conditional.rs| 45 +--
 3 files changed, 96 insertions(+), 10 deletions(-)

diff --git a/gcc/rust/checks/errors/borrowck/rust-borrow-checker-diagnostics.cc 
b/gcc/rust/checks/errors/borrowck/rust-borrow-checker-diagnostics.cc
index dc010291073..f2e4c38cfa0 100644
--- a/gcc/rust/checks/errors/borrowck/rust-borrow-checker-diagnostics.cc
+++ b/gcc/rust/checks/errors/borrowck/rust-borrow-checker-diagnostics.cc
@@ -34,11 +34,42 @@ BorrowCheckerDiagnostics::report_errors ()
 void
 BorrowCheckerDiagnostics::report_move_errors ()
 {
-  if (!move_errors.empty ())
+  for (const auto &pair : move_errors)
 {
-  rust_error_at (hir_function->get_locus (),
-"Found move errors in function %s",
-hir_function->get_function_name ().as_string ().c_str ());
+  auto error_location = get_statement (pair.first).get_location ();
+
+  // in future, we can use the assigned at location to hint the
+  // user to implement copy trait for the type
+  /*
+  for (auto it : facts.path_assigned_at_base)
+   {
+ if (pair.second[0] == it.first)
+   {
+ auto point_assigned_at = it.second;
+ auto assigned_at_location
+   = get_statement (point_assigned_at).get_location ();
+   }
+   }
+   */
+
+  std::vector labels{
+   {"moved value used here", error_location}};
+  // add labels to all the moves for the given path
+  for (auto it : facts.path_moved_at_base)
+   {
+ if (pair.second[0] == it.first)
+   {
+ auto point_moved_at = it.second;
+ // don't label the move location where the error occured
+ if (pair.first != point_moved_at)
+   {
+ auto move_at_location
+   = get_statement (point_moved_at).get_location ();
+ labels.push_back ({"value moved here", move_at_location});
+   }
+   }
+   }
+  multi_label_error ("use of moved value", error_location, labels);
 }
 }
 
diff --git a/gcc/testsuite/rust/borrowck/test_move.rs 
b/gcc/testsuite/rust/borrowck/test_move.rs
index 26a1a5b7bde..b6475839c04 100644
--- a/gcc/testsuite/rust/borrowck/test_move.rs
+++ b/gcc/testsuite/rust/borrowck/test_move.rs
@@ -1,11 +1,27 @@
-// { dg-additional-options "-frust-compile-until=compilation 
-frust-borrowcheck" }
-fn test_move() { // { dg-error "Found move errors in function test_move" }
+// { dg-additional-options "-frust-compile-until=compilation 
-frust-borrowcheck -fdiagnostics-show-caret -fdiagnostics-show-line-numbers" }
+// { dg-enable-nn-line-numbers "" }
+
+fn test_move() {
 struct A {
 i: i32,
 }
 let a = A { i: 1 };
 let b = a;
-let c = a;
+let c = a; //~ ERROR
+// { dg-error "use of moved value" "" { target *-*-* } .-1 }
+/*
+ { dg-begin-multiline-output "" }
+   NN | let b = a;
+  | ~
+  | |
+  | value moved here
+   NN | let c = a; //~ ERROR
+  | ^
+  | |
+  | moved value used here
+ { dg-end-multiline-output "" }
+ */
+
 }
 
 fn test_move_fixed() {
diff --git a/gcc/testsuite/rust/borrowck/test_move_conditional.rs 
b/gcc/testsuite/rust/borrowck/test_move_conditional.rs
index e1e8e2025cf..94882bca5a7 100644
--- a/gcc/testsuite/rust/borrowck/test_move_conditional.rs
+++ b/gcc/testsuite/rust/borrowck/test_move_conditional.rs
@@ -1,6 +1,7 @@
-// { dg-additional-options "-frust-compile-until=compilation 
-frust-borrowcheck" }
+// { dg-additional-options "-frust-compile-until=compilation 
-frust-borrowcheck -fdiagnostics-show-caret -fdiagnostics-show-line-numbers" }
+// { dg-enable-nn-line-numbers "" }
 
-fn test_move_conditional(b1: bool, b2:bool) { // { dg-error "Found move errors 
in function test_move" }
+fn test_move_conditional(b1: bool, b2:bool) {
 struct A {
 i: i32,
 }
@@ -9,9 +10,47 @@ fn test_move_conditional(b1: bool, b2:bool) { // { dg-error 
"Found move errors i
 let b = a;
 if b1 {
 let b = a;
+// { dg-error "use of moved value" "" { target *-*-* } .-1 }
+/*
+ { dg-begin-multiline-output "" }
+   NN | let b = a;
+  | ~
+  | |
+  | value moved here
+   NN | if b1 {
+   NN | let b =

Re: [PATCH 1/1] aarch64: Use PAUTH instead of V8_3A in some places

[Alex Coplan]

On 20/03/2025 14:31, Alfie Richards wrote:
> From: Andrew Carlotti 
> 
> gcc/ChangeLog:
> 

I think you need to add:

PR target/119372

here, so that the backport commits get tracked in bugzilla.

Thanks,
Alex

>   * config/aarch64/aarch64.cc
>   (aarch64_expand_epilogue): Use TARGET_PAUTH.
>   * config/aarch64/aarch64.md: Update comment.
> ---
>  gcc/config/aarch64/aarch64.cc | 6 +++---
>  gcc/config/aarch64/aarch64.md | 8 
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
> index 0a98f005b71..b211f9abd60 100644
> --- a/gcc/config/aarch64/aarch64.cc
> +++ b/gcc/config/aarch64/aarch64.cc
> @@ -10363,12 +10363,12 @@ aarch64_expand_epilogue (bool for_sibcall)
>   1) Sibcalls don't return in a normal way, so if we're about to call one
>  we must authenticate.
>  
> - 2) The RETAA instruction is not available before ARMv8.3-A, so if we are
> -generating code for !TARGET_ARMV8_3 we can't use it and must
> + 2) The RETAA instruction is not available without FEAT_PAuth, so if we
> +are generating code for !TARGET_PAUTH we can't use it and must
>  explicitly authenticate.
>  */
>if (aarch64_return_address_signing_enabled ()
> -  && (for_sibcall || !TARGET_ARMV8_3))
> +  && (for_sibcall || !TARGET_PAUTH))
>  {
>switch (aarch_ra_sign_key)
>   {
> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index b585604cbe0..ff74e7dcef6 100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -7280,11 +7280,11 @@ (define_insn "aarch64_fjcvtzs"
>[(set_attr "type" "f_cvtf2i")]
>  )
>  
> -;; Pointer authentication patterns are always provided.  In architecture
> -;; revisions prior to ARMv8.3-A these HINT instructions operate as NOPs.
> +;; Pointer authentication patterns are always provided.  On targets that
> +;; don't implement FEAT_PAuth these HINT instructions operate as NOPs.
>  ;; This lets the user write portable software which authenticates pointers
> -;; when run on something which implements ARMv8.3-A, and which runs
> -;; correctly, but does not authenticate pointers, where ARMv8.3-A is not
> +;; when run on something which implements FEAT_PAuth, and which runs
> +;; correctly, but does not authenticate pointers, where FEAT_PAuth is not
>  ;; implemented.
>  
>  ;; Signing/Authenticating R30 using SP as the salt.
> -- 
> 2.34.1
> 

RE: [PATCH][RFC] [cobol] change cbl_field_data_t::etc_t::value from _Float128 to tree

[Robert Dubner]

Okay, I managed to figure out a way of getting the debug information back
into the libgcobol.

The addition is done by the routine __gg__add_fixed_phase1()

The run-tiome inputs to that routine should be 1 and 555.

What's coming through in the patched code are 1 and 554

I haven't looked at the compile-time code yet.  But I have a nickel that
says somebody is converting "555." to floating-point, and getting
an internal value of 555.5554999, and that's getting truncated
to the internal value of 554

I haven't checked for sure, but I suppose I've been counting on the
strfromf128 routines to round sensibly.  I guess if mpfr can handle that
kind of thing, then we should switch to mpfr.  I am not that familiar with
mpfr.

> -Original Message-
> From: Robert Dubner 
> Sent: Thursday, March 20, 2025 17:50
> To: Jakub Jelinek 
> Cc: Richard Biener ; gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH][RFC] [cobol] change cbl_field_data_t::etc_t::value
> from _Float128 to tree
> 
> It's time to slow down a bit and give me a chance to catch up.
> 
> First, all those tests are not arbitrary.  I was getting the correct
> answers before, and it was not an insignificant effort to get them
correct
> in the first place.
> 
> If we don't get the same answers, then something isn't the same as it
was
> before.
> 
> I need to know what.
> 
> First-prime:
> 
> Also, keep in mind that this is COBOL, where words don't mean what you
> think they mean.  Under Rounding, we have
> 
> The following forms of rounding are provided (examples presume an
integer
> destination):
> 
> -AWAY-FROM-ZERO: Rounding is to the nearest value farther from zero.
> 
> -NEAREST-AWAY-FROM-ZERO: Rounding is to the nearest value. If two values
> are equally near, the value farther from zero is selected. This mode has
> historically been associated with the ROUNDED clause in earlier versions
> of standard COBOL.
> 
> -NEAREST-EVEN: Rounding is to the nearest value. If two values are
equally
> near, the value whose rightmost digit is even is selected. This mode is
> sometimes called "Banker's rounding".
> 
> -NEAREST-TOWARD-ZERO: Rounding is to the nearest value. If two values
are
> equally near, the value nearer to zero is selected.
> 
> -PROHIBITED: No rounding is performed. If the value cannot be
represented
> exactly in the desired format, the EC-SIZE-TRUNCATION condition is set
to
> exist and the results of the operation are undefined.
> 
> -TOWARD-GREATER: Rounding is toward the nearest value whose algebraic
> value is larger.
> 
> -TOWARD-LESSER: Rounding is toward the nearest value whose algebraic
value
> is smaller.
> 
> -TRUNCATION: Rounding is to the nearest value that is nearer to zero
than
> the algebraic value. This mode has historically been associated with the
> absence of the ROUNDED clause as well as for the formation of
intermediate
> results in the prior COBOL standard.
> 
> Any of those can be set as the default.
> 
> Second, I just tried to debug the way I have been debugging for years --
> and I can't.
> 
> I wanted to check that the attempt to add 0.0001 to 555. was
> actually adding those two numbers.  This wasn't a rounding problem.
Both
> of those numbers have eight decimal places.  So, internally, 1 is
supposed
> to be added to a 64-bit integer value 555 to get 556
> 
> I am suspicious that the 0.0001 is becoming zero, which would result
> in the 555. being unchanged.
> 
> To do an initial check of this, I tried to trap at
__gg__add_fixed_phase1
> 
> But libgcobol.so has no debug info.  So, somehow, the way I used to
cause
> it to be "-ggdb -O0" has gotten lost.  I need it back.
> 
> What I have been doing, lo these many months, is compiling after doing
> this ../configure
> 
> CFLAGS="-ggdb -O0" \
> CXXFLAGS="-ggdb -O0" \
> CFLAGS_FOR_BUILD="-ggdb" \
> CXXFLAGS_FOR_BUILD="-ggdb" \
> LIBCFLAGS_FOR_BUILD="-ggdb" \
> LIBCXXFLAGS_FOR_BUILD="-ggdb" \
> CFLAGS_FOR_TARGET="-ggdb -O0" \
> CXXFLAGS_FOR_TARGET="-ggdb -O0" \
> LIBCFLAGS_FOR_TARGET="-ggdb -O0" \
> LIBCXXFLAGS_FOR_TARGET="-ggdb -O0" \
> ../configure \
> --with-pkgversion="$PKGVERSION" \
> --enable-languages=c,c++,cobol \
> --prefix=/usr/local/gcobol \
> --with-gcc-major-version-only \
> --program-suffix=-$MAJOR_VERSION \
> --enable-shared \
> --enable-linker-build-id \
> --without-included-gettext \
> --enable-threads=posix \
> --disable-bootstrap \
> --enable-clocale=gnu \
> --enable-libstdcxx-debug \
> --enable-libstdcxx-time=yes \
> --with-default-libstdcxx-abi=new \
> --enable-gnu-unique-object \
> --disable-vtable-verify \
> --enable-plugin \
> --enable-default-pie \
> --with-system-zlib \
> --with-target-system-zlib=auto \
> --disable-werror \
> --disable-cet \
>   $arch_options   \
> --disable-multilib \
> --without-cuda-driver \
> --enable-checking \
> --build=$arch-linux-gnu \
> --host=$arch-linux-gnu \
> --target=$arch-linux-gnu \
> --with-build-config=bootstrap-lto-lean \
> 

Re: [PATCH] cobol: Replace quadratic loop removing std::set elements

[Jonathan Wakely]

On Thu, 20 Mar 2025 at 21:27, James K. Lowden  wrote:
>
> On Wed, 19 Mar 2025 20:33:36 +
> Jonathan Wakely  wrote:
>
> > There's no need to keep using std::find_if from the beginning of the
> > container after every removal, just update the iterator after erasing
> > an element.
> >
> > This is how C++20 std::erase_if is implemented.\
>
> LGTM.  I am gun-shy about using iterators while modifying containers.
> I know there are rules.  :-/

Yes, the erased iterator is invalidated, but it returns an iterator to
the next element after the erased one, so we can continue iterating
from there instead of using the no-invalid one. That's what the
p=erase(p) patter does.
The important thing is to _not_ increment in that case, because
erasing *p and then pointing to the next element replaces the
increment.

> Likely you'll find other examples.  The arrays are small and the
> performance impact is too, but neatness counts and simpler is better.
>
> Jonathan, if your patches to the FE so far are awaiting *my* approval,
> consider it done.  I've read them and they're straightforward.  If I
> need to do more than just say that, please direct me.

OK, thanks. On that topic, should you be listed in the MAINTAINERS
file? I see Bob in there, but don't see your name.

I won't make the changes to use 'auto' which Bob didn't like. I'll
send another patch with a more minimal change for the remove_if call
using isspace.

Re: [PATCH] cobol: Replace quadratic loop removing std::set elements

[James K. Lowden]

On Wed, 19 Mar 2025 20:33:36 +
Jonathan Wakely  wrote:

> There's no need to keep using std::find_if from the beginning of the
> container after every removal, just update the iterator after erasing
> an element.
> 
> This is how C++20 std::erase_if is implemented.\

LGTM.  I am gun-shy about using iterators while modifying containers.
I know there are rules.  :-/  

Likely you'll find other examples.  The arrays are small and the
performance impact is too, but neatness counts and simpler is better.  

Jonathan, if your patches to the FE so far are awaiting *my* approval,
consider it done.  I've read them and they're straightforward.  If I
need to do more than just say that, please direct me.  

--jkl

[PATCH 08/10] testsuite: aarch64: arm: Fix -mcpu=unset support in some effective targets

[Christophe Lyon]

Many tests became unsupported on aarch64 when -mcpu=unset was added to
arm_v8_2a_fp16_neon_ok and arm_v8_2a_bf16_neon_ok effective targets,
because this flag is only supported on arm.

Since these effective targets are used on arm and aarch64, the patch
adds -mcpu=unset on arm only, and restores "" on aarch64.

This re-enables bf16 tests on aarch64, and I noticed
  #PASS: 6838 -> 8290
  #UNSUPPORTED: 1491 -> 1030 in gcc.target/aarch64/advsimd-intrinsics

gcc/testsuite/
* lib/target-supports.exp
(check_effective_target_arm_v8_2a_fp16_neon_ok_nocache): Use
-mcpu=unset on arm only.
(check_effective_target_arm_v8_2a_bf16_neon_ok_nocache): Likewise.
---
 gcc/testsuite/lib/target-supports.exp | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 09b16a14024..c2df22d2255 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -6660,11 +6660,16 @@ proc check_effective_target_arm_v8_2a_fp16_scalar_ok { 
} {
 proc check_effective_target_arm_v8_2a_fp16_neon_ok_nocache { } {
 global et_arm_v8_2a_fp16_neon_flags
 set et_arm_v8_2a_fp16_neon_flags ""
+set cpu_unset ""
 
 if { ![istarget arm*-*-*] && ![istarget aarch64*-*-*] } {
return 0;
 }
 
+if { [istarget arm*-*-*] } {
+   set cpu_unset "-mcpu=unset"
+}
+
 # Iterate through sets of options to find the compiler flags that
 # need to be added to the -march option.
 foreach flags {"" "-mfpu=neon-fp-armv8" "-mfloat-abi=softfp" \
@@ -6674,8 +6679,8 @@ proc 
check_effective_target_arm_v8_2a_fp16_neon_ok_nocache { } {
#if !defined (__ARM_FEATURE_FP16_VECTOR_ARITHMETIC)
#error "__ARM_FEATURE_FP16_VECTOR_ARITHMETIC not defined"
#endif
-   } "$flags -mcpu=unset -march=armv8.2-a+fp16"] } {
-   set et_arm_v8_2a_fp16_neon_flags "$flags -mcpu=unset 
-march=armv8.2-a+fp16"
+   } "$flags $cpu_unset -march=armv8.2-a+fp16"] } {
+   set et_arm_v8_2a_fp16_neon_flags "$flags $cpu_unset 
-march=armv8.2-a+fp16"
return 1
}
 }
@@ -6871,6 +6876,7 @@ proc add_options_for_arm_fp16fml_neon { flags } {
 proc check_effective_target_arm_v8_2a_bf16_neon_ok_nocache { } {
 global et_arm_v8_2a_bf16_neon_flags
 set et_arm_v8_2a_bf16_neon_flags ""
+set cpu_unset ""
 set fpu_auto ""
 
 if { ![istarget arm*-*-*] && ![istarget aarch64*-*-*] } {
@@ -6878,6 +6884,7 @@ proc 
check_effective_target_arm_v8_2a_bf16_neon_ok_nocache { } {
 }
 
 if { [istarget arm*-*-*] } {
+   set cpu_unset "-mcpu=unset"
set fpu_auto "-mfpu=auto"
 }
 
@@ -6889,8 +6896,8 @@ proc 
check_effective_target_arm_v8_2a_bf16_neon_ok_nocache { } {
#if !defined (__ARM_FEATURE_BF16_VECTOR_ARITHMETIC)
#error "__ARM_FEATURE_BF16_VECTOR_ARITHMETIC not defined"
#endif
-   } "$flags -mcpu=unset -march=armv8.2-a+bf16"] } {
-   set et_arm_v8_2a_bf16_neon_flags "$flags -mcpu=unset 
-march=armv8.2-a+bf16"
+   } "$flags $cpu_unset -march=armv8.2-a+bf16"] } {
+   set et_arm_v8_2a_bf16_neon_flags "$flags $cpu_unset 
-march=armv8.2-a+bf16"
return 1
}
 }
-- 
2.34.1

[committed] d: Fix quoted command-line options to match lang.opt [PR118545]

[Iain Buclaw]

Hi,

It was noticed that not all D language options get a url in diagnostics.
These have been checked and fixed as necessary.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32, and
committed to mainline.

Regards,
Iain.

---
PR d/118545

gcc/d/ChangeLog:

* d-lang.cc (d_handle_option): Adjust quoted options.
---
 gcc/d/d-lang.cc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/d/d-lang.cc b/gcc/d/d-lang.cc
index 8e37fed2b60..21f46ffb6aa 100644
--- a/gcc/d/d-lang.cc
+++ b/gcc/d/d-lang.cc
@@ -460,7 +460,7 @@ d_handle_option (size_t scode, const char *arg, 
HOST_WIDE_INT value,
  break;
}
 
-  error ("bad argument for %<-fdebug%>: %qs", arg);
+  error ("bad argument for %<-fdebug=%>: %qs", arg);
   break;
 
 case OPT_fdoc:
@@ -533,7 +533,7 @@ d_handle_option (size_t scode, const char *arg, 
HOST_WIDE_INT value,
 case OPT_fmodule_file_:
   global.params.modFileAliasStrings.push (arg);
   if (!strchr (arg, '='))
-   error ("bad argument for %<-fmodule-file%>: %qs", arg);
+   error ("bad argument for %<-fmodule-file=%>: %qs", arg);
   break;
 
 case OPT_fmoduleinfo:
@@ -700,7 +700,7 @@ d_handle_option (size_t scode, const char *arg, 
HOST_WIDE_INT value,
  break;
}
 
-  error ("bad argument for %<-fversion%>: %qs", arg);
+  error ("bad argument for %<-fversion=%>: %qs", arg);
   break;
 
 case OPT_H:
-- 
2.43.0

New German PO file for 'gcc' (version 15.1-b20250316)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators.  The file is available at:

https://translationproject.org/latest/gcc/de.po

(This file, 'gcc-15.1-b20250316.de.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH v2 2/2] PR119376: Disable clang musttail

[Andi Kleen]

On Thu, Mar 20, 2025 at 06:25:26PM +0100, Jakub Jelinek wrote:
> On Thu, Mar 20, 2025 at 10:01:02AM -0700, Andi Kleen wrote:
> > So it could be as simple as that patch?  It solves your test case at least
> > for x86.
> 
> Not sure I like this, but if others (e.g. Richi, Joseph, Jason) are ok with
> it I can live with it.  But we'd need a good documentation, ideally some
> some new warning about it (perhaps enabled in -Wextra) and testcase
> coverage.
> Looking around, clang warns for
> int foo (int *);
> int bar (int *x)
> {
>   *x = 42;
>   int a = 0;
>   [[clang::musttail]] return foo (&a);
> }
> by default (without -Wall/-Wextra) with
> warning: address of stack memory associated with local variable 'a' passed to 
> musttail function [-Wreturn-stack-address]
> Dunno if that warning is about other stuff or just that.
> If just that, perhaps we'd need multiple levels for it, diagnose passing
> those to musttail arguments by default and have in -Wextra stronger variant
> that would diagnose even the
> int baz (int *x)
> {
>   *x = 42;
>   int a = 0;
>   foo (&a);
>   [[clang::musttail]] return foo (nullptr);
> }
> case, i.e. escaped variables that are still in scope.
> That variant of the warning perhaps should suggest to users to end the
> lifetime of those variables before the musttail call.

It looks like it's reasonably easy to provide a single warning
covering both the escape and the passing case. Doing it more
fine grained would need much more code by redoing parts
of ref_may_be_used_by_stmt_p etc.

Perhaps that is good enough?

This version also fixes a memory leak in my earlier variant.

diff --git a/gcc/tree-tailcall.cc b/gcc/tree-tailcall.cc
index f97df31eb3cf..066037ed09c6 100644
--- a/gcc/tree-tailcall.cc
+++ b/gcc/tree-tailcall.cc
@@ -714,29 +714,36 @@ find_tail_calls (basic_block bb, struct tailcall **ret, 
bool only_musttail,
 {
   if (TREE_CODE (var) != PARM_DECL
  && auto_var_in_fn_p (var, cfun->decl)
- && may_be_aliased (var)
- && (ref_maybe_used_by_stmt_p (call, var, false)
- || call_may_clobber_ref_p (call, var, false)))
+ && may_be_aliased (var))
{
- if (!VAR_P (var))
+ if (VAR_P (var)
+   && !bitmap_bit_p (local_live_vars,
+   *live_vars->get (DECL_UID (var
+   continue;
+ if (ref_maybe_used_by_stmt_p (call, var, false))
{
- if (local_live_vars)
-   BITMAP_FREE (local_live_vars);
- maybe_error_musttail (call,
-   _("call invocation refers to locals"));
- return;
+ if (gimple_call_must_tail_p (call))
+   {
+ warning_at (call->location, 0,
+ "Address of local variable %qE may be used by 
musttail call",
+ var);
+ continue;
+   }
}
- else
+ else if (call_may_clobber_ref_p (call, var, false))
{
- unsigned int *v = live_vars->get (DECL_UID (var));
- if (bitmap_bit_p (local_live_vars, *v))
+ if (gimple_call_must_tail_p (call))
{
- BITMAP_FREE (local_live_vars);
- maybe_error_musttail (call,
-   _("call invocation refers to locals"));
- return;
+ warning_at (call->location, 0,
+ "musttail call may clobber escaped variable %qE", 
var);
+ continue;
}
}
+ else
+   continue;
+ if (local_live_vars)
+   BITMAP_FREE (local_live_vars);
+ return;
}
 }
 

[PATCH] Pass CPPFLAGS in HOST_EXPORTS for --build != --host

[Wataru Ashihara]

This fixes the build of libiberty for --build=x86_64-pc-linux-gnu 
--host=x86_64-netbsd:

$ ../configure \
  --build=x86_64-pc-linux-gnu \
  --host=x86_64--netbsd \
  CPPFLAGS="--sysroot=/netbsd-sysroot" \
  CC=x86_64--netbsd-gcc CFLAGS="--sysroot=/netbsd-sysroot" \
  CXX=x86_64--netbsd-g++ CXXFLAGS="--sysroot=/netbsd-sysroot" \
  LDFLAGS="--sysroot=/netbsd-sysroot -static" \
  ;

$ make all-libiberty
...
../../libiberty/cp-demangle.c:119:11: fatal error: alloca.h: No such file 
or directory

$ grep HAVE_ALLOCA_H libiberty/config.h
#define HAVE_ALLOCA_H 1  // incorrect on NetBSD

ChangeLog:

* Makefile.in: Regenerate.
* Makefile.tpl: Export CPPFLAGS in HOST_EXPORTS.

Signed-off-by: Wataru Ashihara 
---
 Makefile.in  | 2 ++
 Makefile.tpl | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/Makefile.in b/Makefile.in
index 87880c62ad2..334d7b806f2 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -200,6 +200,7 @@ HOST_EXPORTS = \
CRAB1_LIBS="$(CRAB1_LIBS)"; export CRAB1_LIBS; \
CFLAGS="$(CFLAGS)"; export CFLAGS; \
CONFIG_SHELL="$(SHELL)"; export CONFIG_SHELL; \
+   CPPFLAGS="$(CPPFLAGS)"; export CPPFLAGS; \
CXX="$(CXX)"; export CXX; \
CXXFLAGS="$(CXXFLAGS)"; export CXXFLAGS; \
GFORTRAN="$(GFORTRAN)"; export GFORTRAN; \
@@ -443,6 +444,7 @@ GNATBIND = @GNATBIND@
 GNATMAKE = @GNATMAKE@
 
 CFLAGS = @CFLAGS@
+CPPFLAGS = @CPPFLAGS@
 LDFLAGS = @LDFLAGS@
 LIBCFLAGS = $(CFLAGS)
 CXXFLAGS = @CXXFLAGS@
diff --git a/Makefile.tpl b/Makefile.tpl
index da38dca697a..e29fb344542 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -203,6 +203,7 @@ HOST_EXPORTS = \
CRAB1_LIBS="$(CRAB1_LIBS)"; export CRAB1_LIBS; \
CFLAGS="$(CFLAGS)"; export CFLAGS; \
CONFIG_SHELL="$(SHELL)"; export CONFIG_SHELL; \
+   CPPFLAGS="$(CPPFLAGS)"; export CPPFLAGS; \
CXX="$(CXX)"; export CXX; \
CXXFLAGS="$(CXXFLAGS)"; export CXXFLAGS; \
GFORTRAN="$(GFORTRAN)"; export GFORTRAN; \
@@ -446,6 +447,7 @@ GNATBIND = @GNATBIND@
 GNATMAKE = @GNATMAKE@
 
 CFLAGS = @CFLAGS@
+CPPFLAGS = @CPPFLAGS@
 LDFLAGS = @LDFLAGS@
 LIBCFLAGS = $(CFLAGS)
 CXXFLAGS = @CXXFLAGS@
-- 
2.48.1

Re: [PATCH] i386: Fix AVX10.2 SAT CVT testcases.

[Hongtao Liu]

On Thu, Mar 20, 2025 at 3:14 PM Hu, Lin1  wrote:
>
> Hi,
>
> res_ref will be modified after MASK_ZERO, init res_ref2 for rounding
> control intrinsics.
>
> Bootstrapped and regtested on x86-64-pc-linux-gnu{-m32,-m64}, OK for trunk?
Ok.
>
> BRs,
> Lin
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/avx10_2-512-vcvtph2ibs-2.c: Fix testcase.
> * gcc.target/i386/avx10_2-512-vcvtph2iubs-2.c: Ditto.
> * gcc.target/i386/avx10_2-512-vcvtps2ibs-2.c: Ditto.
> * gcc.target/i386/avx10_2-512-vcvtps2iubs-2.c: Ditto.
> * gcc.target/i386/avx10_2-512-vcvttpd2dqs-2.c: Ditto.
> * gcc.target/i386/avx10_2-512-vcvttpd2qqs-2.c: Ditto.
> * gcc.target/i386/avx10_2-512-vcvttpd2udqs-2.c: Ditto.
> * gcc.target/i386/avx10_2-512-vcvttpd2uqqs-2.c: Ditto.
> * gcc.target/i386/avx10_2-512-vcvttph2ibs-2.c: Ditto.
> * gcc.target/i386/avx10_2-512-vcvttps2dqs-2.c: Ditto.
> * gcc.target/i386/avx10_2-512-vcvttps2ibs-2.c: Ditto.
> * gcc.target/i386/avx10_2-512-vcvttps2iubs-2.c: Ditto.
> * gcc.target/i386/avx10_2-512-vcvttps2qqs-2.c: Ditto.
> * gcc.target/i386/avx10_2-512-vcvttps2udqs-2.c: Ditto.
> * gcc.target/i386/avx10_2-512-vcvttps2uqqs-2.c: Ditto.
> ---
>  .../gcc.target/i386/avx10_2-512-vcvtph2ibs-2.c  | 17 +++--
>  .../gcc.target/i386/avx10_2-512-vcvtph2iubs-2.c | 17 +++--
>  .../gcc.target/i386/avx10_2-512-vcvtps2ibs-2.c  | 17 +++--
>  .../gcc.target/i386/avx10_2-512-vcvtps2iubs-2.c | 17 +++--
>  .../gcc.target/i386/avx10_2-512-vcvttpd2dqs-2.c | 17 +++--
>  .../gcc.target/i386/avx10_2-512-vcvttpd2qqs-2.c | 17 +++--
>  .../i386/avx10_2-512-vcvttpd2udqs-2.c   | 17 +++--
>  .../i386/avx10_2-512-vcvttpd2uqqs-2.c   | 17 +++--
>  .../gcc.target/i386/avx10_2-512-vcvttph2ibs-2.c | 17 +++--
>  .../gcc.target/i386/avx10_2-512-vcvttps2dqs-2.c | 17 +++--
>  .../gcc.target/i386/avx10_2-512-vcvttps2ibs-2.c | 17 +++--
>  .../i386/avx10_2-512-vcvttps2iubs-2.c   | 17 +++--
>  .../gcc.target/i386/avx10_2-512-vcvttps2qqs-2.c | 17 +++--
>  .../i386/avx10_2-512-vcvttps2udqs-2.c   | 17 +++--
>  .../i386/avx10_2-512-vcvttps2uqqs-2.c   | 17 +++--
>  15 files changed, 165 insertions(+), 90 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/i386/avx10_2-512-vcvtph2ibs-2.c 
> b/gcc/testsuite/gcc.target/i386/avx10_2-512-vcvtph2ibs-2.c
> index 0c860b02046..523b3f0a4cb 100644
> --- a/gcc/testsuite/gcc.target/i386/avx10_2-512-vcvtph2ibs-2.c
> +++ b/gcc/testsuite/gcc.target/i386/avx10_2-512-vcvtph2ibs-2.c
> @@ -9,6 +9,7 @@
>  #endif
>  #include "avx10-helper.h"
>  #include 
> +#include 
>
>  #define SIZE (AVX512F_LEN / 16)
>  #include "avx512f-mask-type.h"
> @@ -37,7 +38,7 @@ TEST (void)
>UNION_TYPE (AVX512F_LEN, h) s;
>UNION_TYPE (AVX512F_LEN, i_w) res1, res2, res3;
>MASK_TYPE mask = MASK_VALUE;
> -  short res_ref[SIZE] = { 0 };
> +  short res_ref[SIZE] = { 0 }, res_ref2[SIZE] = { 0 };
>int i, sign = 1;
>
>for (i = 0; i < SIZE; i++)
> @@ -54,6 +55,7 @@ TEST (void)
>res3.x = INTRINSIC (_maskz_ipcvts_ph_epi8) (mask, s.x);
>
>CALC (s.a, res_ref);
> +  memcpy(res_ref2, res_ref, sizeof(res_ref));
>
>if (UNION_CHECK (AVX512F_LEN, i_w) (res1, res_ref))
>  abort ();
> @@ -67,19 +69,22 @@ TEST (void)
>  abort ();
>
>  #if AVX512F_LEN != 128
> +  for (i = 0; i < SIZE; i++)
> +res2.a[i] = DEFAULT_VALUE;
> +
>res1.x = INTRINSIC (_ipcvts_roundph_epi8) (s.x, 8);
>res2.x = INTRINSIC (_mask_ipcvts_roundph_epi8) (res2.x, mask, s.x, 8);
>res3.x = INTRINSIC (_maskz_ipcvts_roundph_epi8) (mask, s.x, 8);
>
> -  if (UNION_CHECK (AVX512F_LEN, i_w) (res1, res_ref))
> +  if (UNION_CHECK (AVX512F_LEN, i_w) (res1, res_ref2))
>  abort ();
>
> -  MASK_MERGE (i_w) (res_ref, mask, SIZE);
> -  if (UNION_CHECK (AVX512F_LEN, i_w) (res2, res_ref))
> +  MASK_MERGE (i_w) (res_ref2, mask, SIZE);
> +  if (UNION_CHECK (AVX512F_LEN, i_w) (res2, res_ref2))
>  abort ();
>
> -  MASK_ZERO (i_w) (res_ref, mask, SIZE);
> -  if (UNION_CHECK (AVX512F_LEN, i_w) (res3, res_ref))
> +  MASK_ZERO (i_w) (res_ref2, mask, SIZE);
> +  if (UNION_CHECK (AVX512F_LEN, i_w) (res3, res_ref2))
>  abort ();
>  #endif
>  }
> diff --git a/gcc/testsuite/gcc.target/i386/avx10_2-512-vcvtph2iubs-2.c 
> b/gcc/testsuite/gcc.target/i386/avx10_2-512-vcvtph2iubs-2.c
> index 75e4e1141be..a8f6e57d46a 100644
> --- a/gcc/testsuite/gcc.target/i386/avx10_2-512-vcvtph2iubs-2.c
> +++ b/gcc/testsuite/gcc.target/i386/avx10_2-512-vcvtph2iubs-2.c
> @@ -9,6 +9,7 @@
>  #endif
>  #include "avx10-helper.h"
>  #include 
> +#include 
>
>  #define SIZE (AVX512F_LEN / 16)
>  #include "avx512f-mask-type.h"
> @@ -37,7 +38,7 @@ TEST (void)
>UNION_TYPE (AVX512F_LEN, h) s;
>UNION_TYPE (AVX512F_LEN, i_w) res1, res2, res3;
>MASK_TYPE mask = MASK_VALUE;
>

Re: [PATCH v2]RISC-V:Add xuantie C908, C910, C920v1 and C920v2 to -mcpu

[Jin Ma]

On Mon, 17 Mar 2025 17:31:36 +0800, Yixuan Chen wrote:
> gcc/ChangeLog:
> 
> * config/riscv/riscv-cores.def (RISCV_TUNE): Add xt-c908, xt-c910.
> (RISCV_CORE): Add xt-c908, xt-c910 and xt-c920v1 and xt-c920v2.
> * config/riscv/riscv.cc: Add xt-c908, xt-c910 tune info.
> * doc/invoke.texi: Add xt-c908, xt-c910 and xt-c920v1 and xt-c920v2.
> 
> gcc/testsuite/ChangeLog:
> 
> * gcc.target/riscv/mcpu-xt-c908.c: New test.
> * gcc.target/riscv/mcpu-xt-c910.c: New test.
> * gcc.target/riscv/mcpu-xt-c920v1.c: New test.
> * gcc.target/riscv/mcpu-xt-c920v2.c: New test.
> 
> Fix v1 Subject issue and ISA string issue.
> 
> Add xuantie C909, C910, C920v1 and C920v2 to -mcpu

Hi, Yixuan,

I suggest changing C920v1 to C920, as this would better align with the actual 
naming conventions of the CPU.

> Tune info copied 
> from:https://github.com/XUANTIE-RV/gcc/blob/xuantie-gcc-10.2.0/gcc/config/riscv/riscv-xuantie-tune.h
> No C920 related tune info, use generic_ooo.

This is feasible for now; we can make further modifications later.

> Add xuantie C909, C910, C920v1 and C920v2 to -mcpu
> Tune info copied 
> from:https://github.com/XUANTIE-RV/gcc/blob/xuantie-gcc-10.2.0/gcc/config/riscv/riscv-xuantie-tune.h
> No C920 related tune info, use generic_ooo.
> ---
>  gcc/config/riscv/riscv-cores.def  | 25 ++
>  gcc/config/riscv/riscv.cc | 34 +++
>  gcc/doc/invoke.texi   |  4 +--
>  gcc/testsuite/gcc.target/riscv/mcpu-xt-c908.c | 34 +++
>  gcc/testsuite/gcc.target/riscv/mcpu-xt-c910.c | 29 
>  .../gcc.target/riscv/mcpu-xt-c920v1.c | 30 
>  .../gcc.target/riscv/mcpu-xt-c920v2.c | 30 
>  7 files changed, 184 insertions(+), 2 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/riscv/mcpu-xt-c908.c
>  create mode 100644 gcc/testsuite/gcc.target/riscv/mcpu-xt-c910.c
>  create mode 100644 gcc/testsuite/gcc.target/riscv/mcpu-xt-c920v1.c
>  create mode 100644 gcc/testsuite/gcc.target/riscv/mcpu-xt-c920v2.c
> 
> diff --git a/gcc/config/riscv/riscv-cores.def 
> b/gcc/config/riscv/riscv-cores.def
> index 2918496bcd0..af45ec57e90 100644
> --- a/gcc/config/riscv/riscv-cores.def
> +++ b/gcc/config/riscv/riscv-cores.def
> @@ -41,6 +41,10 @@ RISCV_TUNE("sifive-p400-series", sifive_p400, 
> sifive_p400_tune_info)
>  RISCV_TUNE("sifive-p600-series", sifive_p600, sifive_p600_tune_info)
>  RISCV_TUNE("tt-ascalon-d8", generic_ooo, tt_ascalon_d8_tune_info)
>  RISCV_TUNE("thead-c906", generic, thead_c906_tune_info)
> +RISCV_TUNE("xt-c908", generic, xt_c908_tune_info)
> +RISCV_TUNE("xt-c910", generic, xt_c910_tune_info)
> +RISCV_TUNE("xt-c920v1", generic, generic_ooo_tune_info)
> +RISCV_TUNE("xt-c920v2", generic, generic_ooo_tune_info)
>  RISCV_TUNE("xiangshan-nanhu", xiangshan, xiangshan_nanhu_tune_info)
>  RISCV_TUNE("generic-ooo", generic_ooo, generic_ooo_tune_info)
>  RISCV_TUNE("size", generic, optimize_size_tune_info)
> @@ -93,6 +97,27 @@ RISCV_CORE("thead-c906",  
> "rv64imafdc_xtheadba_xtheadbb_xtheadbs_xtheadcmo_"
> "xtheadmemidx_xtheadmempair_xtheadsync",
> "thead-c906")
>  
> +RISCV_CORE("xt-c908", "rv64imafdc_zihintpause_zfh_zba_zbb_zbc_zbs_"
> +   "xtheadba_xtheadbb_xtheadbs_xtheadcmo_"
> +   "xtheadcondmov_xtheadfmemidx_xtheadmac_"
> +   "xtheadmemidx_xtheadmempair_xtheadsync",
> +   "xt-c908")
> +
> +RISCV_CORE("xt-c910", 
> "rv64imafdc_zfh_xtheadba_xtheadbb_xtheadbs_xtheadcmo_"
> +   "xtheadcondmov_xtheadfmemidx_xtheadint_xtheadmac_"
> +   "xtheadmemidx_xtheadmempair_xtheadsync",
> +   "xt-c910")
> +
> +RISCV_CORE("xt-c920v1",   
> "rv64imafdc_zfh_xtheadba_xtheadbb_xtheadbs_xtheadcmo_"
> +   "xtheadcondmov_xtheadfmemidx_xtheadint_xtheadmac_"
> +   
> "xtheadmemidx_xtheadmempair_xtheadsync_xtheadvector",
> +   "xt-c920v1")
> +
> +RISCV_CORE("xt-c920v2",   
> "rv64imafdcv_zfh_xtheadba_xtheadbb_xtheadbs_xtheadcmo_"
> +   "xtheadcondmov_xtheadfmemidx_xtheadint_xtheadmac_"
> +   "xtheadmemidx_xtheadmempair_xtheadsync",
> +   "xt-c920v2")
> +

We can add the extension xtheadfmv to all of these models. Additionally, the 
C920v2 also supports zfa, zfbfmin, zcb, zba, zbb, zbc, zbs, zvfbfmin, zvfbfwma, 
and zvfh.

>  RISCV_CORE("tt-ascalon-d8",   "rv64imafdcv_zic64b_zicbom_zicbop_zicboz_"
> "ziccamoa_ziccif_zicclsm_ziccrse_zicond_zicsr_"
> "zifencei_zihintntl_zihintpause_zimop_za64rs_"
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 38f3ae7cd84..

Re: [PATCH v2 1/2] PR118442: Don't instrument exit edges after musttail

[Jakub Jelinek]

On Thu, Mar 20, 2025 at 09:08:25AM +0100, Richard Biener wrote:
> Hmm.  I do wonder whether your earlier patch was more "correct" in the
> sense that a tail call does not return to the calling function but its caller.
> That means it should not have a fallthru edge, so our representation
> with feeding a return value to a function-local return stmt isn't a good one.

Tail call certainly doesn't.
But what we have in the IL right now, i.e. musttail marked call in the
middle, isn't actually a tail call, it is a call that should be turned into
a tail call or error should be reported.
And that certainly returns to the caller (if it is not non-marked noreturn
or say exits/aborts/longjmp/throws) and performs the statements in there and
only then returns.
So pretending it doesn't return is IMHO risky.  We could only do that if
we had in the IL something that would be a GIMPLE_RETURN combined with the
GIMPLE_CALL.  I bet that is how LLVM implements it, but then the discovery
needs to be done in the FE, not late, clearly they don't bother with
discovering address escaped automatic vars still in scope and just declare
that UB, ...

All we should ensure is that we don't add after such calls code which would
turn those calls from successfully tail-callable into ones on which we
error.

Jakub

Re: [PATCH v2]RISC-V:Add xuantie C908, C910, C920v1 and C920v2 to -mcpu

[Yixuan Chen]

Hi Majin,

 Thanks for your suggestion,
Look like the document don't contain the following tune information:
/* fmv_cost */, /* vector_unaligned_access */, /* use_divmod_expansion */,
and /* overlap_op_by_pieces */
, I will follow your further modification and wait for the gcc16 window to
send the patch v3 fixing the c920v1 name issue. But it's ok for me that
either of you and me to send the patch,
If you have any concern please contact me.

Best regards
Yixuan Chen



Jin Ma  于2025年3月20日周四 16:12写道：

> On Mon, 17 Mar 2025 17:31:36 +0800, Yixuan Chen wrote:
> > gcc/ChangeLog:
> >
> > * config/riscv/riscv-cores.def (RISCV_TUNE): Add xt-c908,
> xt-c910.
> > (RISCV_CORE): Add xt-c908, xt-c910 and xt-c920v1 and xt-c920v2.
> > * config/riscv/riscv.cc: Add xt-c908, xt-c910 tune info.
> > * doc/invoke.texi: Add xt-c908, xt-c910 and xt-c920v1 and
> xt-c920v2.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/riscv/mcpu-xt-c908.c: New test.
> > * gcc.target/riscv/mcpu-xt-c910.c: New test.
> > * gcc.target/riscv/mcpu-xt-c920v1.c: New test.
> > * gcc.target/riscv/mcpu-xt-c920v2.c: New test.
> >
> > Fix v1 Subject issue and ISA string issue.
> >
> > Add xuantie C909, C910, C920v1 and C920v2 to -mcpu
>
> Hi, Yixuan,
>
> I suggest changing C920v1 to C920, as this would better align with the
> actual naming conventions of the CPU.
>
> > Tune info copied from:
> https://github.com/XUANTIE-RV/gcc/blob/xuantie-gcc-10.2.0/gcc/config/riscv/riscv-xuantie-tune.h
> > No C920 related tune info, use generic_ooo.
>
> This is feasible for now; we can make further modifications later.
>
> > Add xuantie C909, C910, C920v1 and C920v2 to -mcpu
> > Tune info copied from:
> https://github.com/XUANTIE-RV/gcc/blob/xuantie-gcc-10.2.0/gcc/config/riscv/riscv-xuantie-tune.h
> > No C920 related tune info, use generic_ooo.
> > ---
> >  gcc/config/riscv/riscv-cores.def  | 25 ++
> >  gcc/config/riscv/riscv.cc | 34 +++
> >  gcc/doc/invoke.texi   |  4 +--
> >  gcc/testsuite/gcc.target/riscv/mcpu-xt-c908.c | 34 +++
> >  gcc/testsuite/gcc.target/riscv/mcpu-xt-c910.c | 29 
> >  .../gcc.target/riscv/mcpu-xt-c920v1.c | 30 
> >  .../gcc.target/riscv/mcpu-xt-c920v2.c | 30 
> >  7 files changed, 184 insertions(+), 2 deletions(-)
> >  create mode 100644 gcc/testsuite/gcc.target/riscv/mcpu-xt-c908.c
> >  create mode 100644 gcc/testsuite/gcc.target/riscv/mcpu-xt-c910.c
> >  create mode 100644 gcc/testsuite/gcc.target/riscv/mcpu-xt-c920v1.c
> >  create mode 100644 gcc/testsuite/gcc.target/riscv/mcpu-xt-c920v2.c
> >
> > diff --git a/gcc/config/riscv/riscv-cores.def
> b/gcc/config/riscv/riscv-cores.def
> > index 2918496bcd0..af45ec57e90 100644
> > --- a/gcc/config/riscv/riscv-cores.def
> > +++ b/gcc/config/riscv/riscv-cores.def
> > @@ -41,6 +41,10 @@ RISCV_TUNE("sifive-p400-series", sifive_p400,
> sifive_p400_tune_info)
> >  RISCV_TUNE("sifive-p600-series", sifive_p600, sifive_p600_tune_info)
> >  RISCV_TUNE("tt-ascalon-d8", generic_ooo, tt_ascalon_d8_tune_info)
> >  RISCV_TUNE("thead-c906", generic, thead_c906_tune_info)
> > +RISCV_TUNE("xt-c908", generic, xt_c908_tune_info)
> > +RISCV_TUNE("xt-c910", generic, xt_c910_tune_info)
> > +RISCV_TUNE("xt-c920v1", generic, generic_ooo_tune_info)
> > +RISCV_TUNE("xt-c920v2", generic, generic_ooo_tune_info)
> >  RISCV_TUNE("xiangshan-nanhu", xiangshan, xiangshan_nanhu_tune_info)
> >  RISCV_TUNE("generic-ooo", generic_ooo, generic_ooo_tune_info)
> >  RISCV_TUNE("size", generic, optimize_size_tune_info)
> > @@ -93,6 +97,27 @@ RISCV_CORE("thead-c906",
> "rv64imafdc_xtheadba_xtheadbb_xtheadbs_xtheadcmo_"
> > "xtheadmemidx_xtheadmempair_xtheadsync",
> > "thead-c906")
> >
> > +RISCV_CORE("xt-c908",
>  "rv64imafdc_zihintpause_zfh_zba_zbb_zbc_zbs_"
> > +   "xtheadba_xtheadbb_xtheadbs_xtheadcmo_"
> > +   "xtheadcondmov_xtheadfmemidx_xtheadmac_"
> > +   "xtheadmemidx_xtheadmempair_xtheadsync",
> > +   "xt-c908")
> > +
> > +RISCV_CORE("xt-c910",
>  "rv64imafdc_zfh_xtheadba_xtheadbb_xtheadbs_xtheadcmo_"
> > +
>  "xtheadcondmov_xtheadfmemidx_xtheadint_xtheadmac_"
> > +   "xtheadmemidx_xtheadmempair_xtheadsync",
> > +   "xt-c910")
> > +
> > +RISCV_CORE("xt-c920v1",
>  "rv64imafdc_zfh_xtheadba_xtheadbb_xtheadbs_xtheadcmo_"
> > +
>  "xtheadcondmov_xtheadfmemidx_xtheadint_xtheadmac_"
> > +
>  "xtheadmemidx_xtheadmempair_xtheadsync_xtheadvector",
> > +   "xt-c920v1")
> > +
> > +RISCV_CORE("xt-c920v2",
>  "rv64imafdcv_zfh_xtheadba_xtheadbb_xtheadbs_xtheadcmo_"
> > +
>  "xtheadcondmov_xtheadfmemidx_xtheadint_xtheadmac_"
> > +   "xtheadmemidx_xtheadmempair_xtheadsync",
> >

Re: [PATCH 2/2] [cobol] make sources coretypes.h and tree.h clean

[Jakub Jelinek]

On Wed, Mar 19, 2025 at 06:03:16PM -0400, James K. Lowden wrote:
> I'm not convinced this effort is either good or necessary. I'm a 
> afraid of ending up with code no one including me understands, for the
> sake of portability to architectures no one will ever use.  I think
> you're assuming I understand things I don't, and possibly assuming
> something to be necessary that isn't, in this context.  

I think Richard already posted some reasons.
Add to that that if the compiler uses host math library for floating
point computations during compilation, then code generation is dependent
on the ulp errors of the exact implementation.  So you might get
different compiled code from the same source on say Linux x86_64 host with 
glibc,
another on Linux x86_64 host with musl, another on Linux aarch64 host
with glibc, ...  If it was e.g. float rather than _Float128, it would also
depend on excess precision (ia32 would evaluate those as long double
sometimes and as float at other times, s390x would evaluate those as double
sometimes and float at other times, ...).  Also, _Float128 is implemented
differently on different hosts, sometimes in hardware (e.g. s390x,
powerpc64le), often in software emulation, while the basic arithmetics
ideally should have ultimate precision, bugs could affect that.
And more importantly, _Float128 and __int128 are only available on small
subsets of hosts.  Many of the __int128 uses in the COBOL FE are just
wrong because they lose the upper 64 bits when turning it into a tree,
so just using wide_int there designed for arbitrary precision arithmetics
at compile time fixes that.

> On the 3rd hand, it's very nice while debugging the parser to see
> these numbers as numbers, not as some abstract tree type.  

When you have a tree REAL_CST instead of _Float128, you can just
pt var_or_expression
in the debugger (which calls debug_tree on var_or_expression),
or
pgs var_or_expression
(which calls debug_generic_stmt on it).
Or generally, for many types like REAL_VALUE_TYPE, there is just
overloaded debug function, so you can
call debug (var)
and it will DTRT.

Jakub

[committed] libstdc++: Fix comment typo

[Jakub Jelinek]

On Wed, Mar 19, 2025 at 11:29:55PM +, Jonathan Wakely wrote:
> libstdc++-v3/ChangeLog:
> 
>   * include/bits/locale_facets_nonio.tcc (time_put::do_put): Fix
>   typo in comment.

Another one, committed as obvious.

2025-03-20  Jakub Jelinek  

* testsuite/18_support/numeric_limits/traps.cc (main): Fix comment
typo.

--- libstdc++-v3/testsuite/18_support/numeric_limits/traps.cc.jj
2025-01-02 20:54:32.945118626 +0100
+++ libstdc++-v3/testsuite/18_support/numeric_limits/traps.cc   2025-03-20 
00:49:52.935180684 +0100
@@ -48,7 +48,7 @@ int main()
 For floating points, trapping is a different, more complicated
 story.  If is_iecxxx is true, then division by zero would not trap
 (infinity).  If is_iecxxx is false, we don't know (VAX may trap for
-0/0 -- I have to check).  For most cases (i.e. IEE-754), trapping
+0/0 -- I have to check).  For most cases (i.e. IEEE-754), trapping
 for floating points have to do with whether there is a support for
 signaling NaN.
 - Gaby.


Jakub

Re: [PATCH] Fix GCN SIMD libm bug

[Andrew Stubbs]

I meant to send this to the newlib list.

Apparently yesterday was a bad day for sending emails correctly. :(

Andrew

On 19/03/2025 15:04, Andrew Stubbs wrote:

Since January, GCC has been miscompiling Newlib libm on AMD GCN due to
undefined behaviour in the RESIZE_VECTOR macro.  It was "working" but expanding
the size of a vector would no longer zero the additional lanes, as it expected.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119325
---
  newlib/libm/machine/amdgcn/amdgcn_veclib.h | 17 +++--
  1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/newlib/libm/machine/amdgcn/amdgcn_veclib.h 
b/newlib/libm/machine/amdgcn/amdgcn_veclib.h
index bd67740ac..9e9d3ebf0 100644
--- a/newlib/libm/machine/amdgcn/amdgcn_veclib.h
+++ b/newlib/libm/machine/amdgcn/amdgcn_veclib.h
@@ -85,8 +85,21 @@ typedef union {
  
  #define RESIZE_VECTOR(to_t, from) \

  ({ \
-  __auto_type __from = (from); \
-  *((to_t *) &__from); \
+  to_t __to; \
+  if (VECTOR_WIDTH (to_t) < VECTOR_WIDTH (__typeof (from))) \
+asm ("; no-op cast %0" : "=v"(__to) : "0"(from)); \
+  else \
+{ \
+  unsigned long __mask = -1L; \
+  int lanes = VECTOR_WIDTH (__typeof (from)); \
+  __mask <<= lanes; \
+  __builtin_choose_expr ( \
+   V_SF_SI_P (to_t), \
+   ({asm ("v_mov_b32 %0, 0" : "=v"(__to) : "0"(from), "e"(__mask));}), \
+   ({asm ("v_mov_b32 %H0, 0\n\t" \
+  "v_mov_b32 %L0, 0" : "=v"(__to) : "0"(from), "e"(__mask));})); \
+} \
+  __to; \
  })
  
  /* Bit-wise cast vector FROM to type TO_T.  */

Re: [PATCH] OpenMP: 'interop' construct - add ME support + target-independent libgomp

[Jakub Jelinek]

On Tue, Mar 18, 2025 at 03:36:58PM +0100, Paul-Antoine Arras wrote:
> This patch partially enables use of the OpenMP interop construct by adding
> middle end support, mostly in the omplower pass, and in the target-independent
> part of the libgomp runtime. It follows up on previous patches for C, C++ and
> Fortran front ends support. The full interop feature requires another patch to
> enable foreign runtime support in libgomp plugins.

Deferring most of review to Tobias, just nits from my side:

> +/* Generate code to implement the action-clauses (destroy, init, use) of an
> +   OpenMP interop construct.  */
> +
> +static void
> +lower_omp_interop_action_clauses (gimple_seq *seq, vec &objs,
> +   vec *interop_types = NULL,
> +   vec *prefer_types = NULL)
...
> +  /* If there is only one object then we pass a single pointer,
> + if there are multiple objects then we build an array. */
> +  if (objs.length () == 1)
> +{
> +  tree obj = OMP_CLAUSE_DECL (objs.pop ());
> +  if (TREE_CODE (TREE_TYPE (obj)) == REFERENCE_TYPE)
> + obj = build1 (INDIRECT_REF, TREE_TYPE (TREE_TYPE (obj)), obj);
> +  if (action != OMP_CLAUSE_USE
> +   && TREE_CODE (TREE_TYPE (obj)) != POINTER_TYPE)
> + {
> +   // For modifying actions, we need a pointer.

Please don't mix comment styles, if /* comments are common in some source
file, just use them everywhere.

> +   tree obj_ptr = create_tmp_var (build_pointer_type (TREE_TYPE (obj)));
> +   gimplify_assign (obj_ptr, build_fold_addr_expr (obj), seq);
> +   obj = obj_ptr;
> + }
> +  else if (action == OMP_CLAUSE_USE
> +&& TREE_CODE (TREE_TYPE (obj)) == POINTER_TYPE)
> + {
> +   // For use action, we need the value.

Ditto.

> +   tree prefer_type = prefer_types->pop ();
> +   tree pref = prefer_type == NULL_TREE
> + ? null_pointer_node
> + : build_fold_addr_expr (prefer_type);

I think Emacs users would like ()s around here, so
  tree pref = (prefer_type == NULL_TREE
   ? null_pointer_node
   : build_fold_addr_expr (prefer_type));

> +  gcc_assert (objs.is_empty () && (!interop_types || interop_types->is_empty 
> ())
> +   && (!prefer_types || prefer_types->is_empty ()));

The rule is if some &&/|| using condition fits on one line, it is on
one line, if it doesn't, each && or || operand goes on its own.
So
  gcc_assert (objs.is_empty ()
  && (!interop_types || interop_types->is_empty ())
  && (!prefer_types || prefer_types->is_empty ()));
here.

> +  /* Emit call to GOMP_interop:
> +  void
> +  GOMP_interop (int device_num, int n_init, void *init,
> + const void *target_targetsync, const void *prefer_type,
> + int n_use, void *use, int n_destroy, void *destroy,
> + unsigned int nowait, void **depend)  */

Is nowait just 0/1?  I wonder if it wouldn't be better to have the argument
called flags and accept a bitmask to make it more extensible for the
future (like we have unsigned int flags on GOMP_target_ext or on GOMP_task).

> + target_targetsync.safe_push (
> +   build_int_cst (integer_type_node, target_targetsync_bits));

This kind of formatting is too ugly and can be easily avoided.
Just do
tree t = build_int_cst (integer_type_node, target_targetsync_bits);
target_targetsync.safe_push (t);

> +  gcall *call = gimple_build_call (
> +fn, 11, device_num, n_init,
> +init_objs.length () ? init_objs.pop () : null_pointer_node,
> +target_targetsync.length () ? target_targetsync.pop () : 
> null_pointer_node,
> +prefer_type.length () ? prefer_type.pop () : null_pointer_node, n_use,
> +use_objs.length () ? use_objs.pop () : null_pointer_node, n_destroy,
> +destroy_objs.length () ? destroy_objs.pop () : null_pointer_node, nowait,
> +depend);

And here too.
Add temporaries for the vars that need large expressions.
  tree initarg = init_objs.length () ? init_objs.pop () : null_pointer_node;
  tree syncarg = (target_targetsync.length ()
  ? target_targetsync.pop () : null_pointer_node);
  tree preferarg
= prefer_type.length () ? prefer_type.pop () : null_pointer_node;
  tree usearg = use_objs.length () ? use_objs.pop () : null_pointer_node;
  tree destroyarg
= destroy_objs.length () ? destroy_objs.pop () : null_pointer_node;
  gcall *call = gimple_build_call (fn, 11, device_num, n_init, initarg,
   syncarg, preferarg, n_use, usearg,
   n_destroy, destroyarg, nowait, depend);
or so.

> +void
> +GOMP_interop (int device_num, int n_init, void *init,
> +   const void *target_targetsync, const void *prefer_type,
> +   int n_use, void *use, int n_destroy, void *destro

[PATCH] libstdc++: Add from_range_t constructors to debug ordered containers

[Jonathan Wakely]

libstdc++-v3/ChangeLog:

* include/debug/map.h (map): Add from_range constructors and
deduction guides.
* include/debug/multimap.h (multimap): Likewise.
* include/debug/multiset.h (multiset): Likewise.
* include/debug/set.h (set): Likewise.
---

When testing with -D_GLIBCXX_DEBUG I noticed we need the new ctors and
deduction guides for the debug mode containers. This adds them for 
and , but we also need them for the unordered containers.

Tested x86_64-linux.

 libstdc++-v3/include/debug/map.h  | 36 +++
 libstdc++-v3/include/debug/multimap.h | 36 +++
 libstdc++-v3/include/debug/multiset.h | 30 ++
 libstdc++-v3/include/debug/set.h  | 32 +++-
 4 files changed, 133 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/debug/map.h b/libstdc++-v3/include/debug/map.h
index a9fac790b1c..aa1c1dbd47a 100644
--- a/libstdc++-v3/include/debug/map.h
+++ b/libstdc++-v3/include/debug/map.h
@@ -133,6 +133,25 @@ namespace __debug
__gnu_debug::__base(__last), __a)
{ }
 
+#if __glibcxx_ranges_to_container // C++ >= 23
+  /**
+   * @brief Construct a map from a range.
+   * @since C++23
+   */
+  template _Rg>
+   map(std::from_range_t __t, _Rg&& __rg,
+   const _Compare& __c,
+   const allocator_type& __a = allocator_type())
+   : _Base(__t, std::forward<_Rg>(__rg), __c, __a)
+   { }
+
+  template _Rg>
+   map(std::from_range_t __t, _Rg&& __rg,
+   const allocator_type& __a = allocator_type())
+   : _Base(__t, std::forward<_Rg>(__rg), __a)
+   { }
+#endif
+
   ~map() = default;
 #endif
 
@@ -740,6 +759,23 @@ namespace __debug
 map(initializer_list>, _Allocator)
 -> map<_Key, _Tp, less<_Key>, _Allocator>;
 
+#if __glibcxx_ranges_to_container // C++ >= 23
+  template>,
+  __allocator_like _Alloc =
+ std::allocator<__detail::__range_to_alloc_type<_Rg>>>
+map(from_range_t, _Rg&&, _Compare = _Compare(), _Alloc = _Alloc())
+  -> map<__detail::__range_key_type<_Rg>,
+__detail::__range_mapped_type<_Rg>,
+_Compare, _Alloc>;
+
+  template
+map(from_range_t, _Rg&&, _Alloc)
+  -> map<__detail::__range_key_type<_Rg>,
+__detail::__range_mapped_type<_Rg>,
+less<__detail::__range_key_type<_Rg>>,
+_Alloc>;
+#endif
 #endif // deduction guides
 
   template= 23
+  /**
+   * @brief Construct a multimap from a range.
+   * @since C++23
+   */
+  template _Rg>
+   multimap(std::from_range_t __t, _Rg&& __rg,
+const _Compare& __c,
+const allocator_type& __a = allocator_type())
+   : _Base(__t, std::forward<_Rg>(__rg), __c, __a)
+   { }
+
+  template _Rg>
+   multimap(std::from_range_t __t, _Rg&& __rg,
+const allocator_type& __a = allocator_type())
+   : _Base(__t, std::forward<_Rg>(__rg), __a)
+   { }
+#endif
+
   ~multimap() = default;
 #endif
 
@@ -622,6 +641,23 @@ namespace __debug
 multimap(initializer_list>, _Allocator)
 -> multimap<_Key, _Tp, less<_Key>, _Allocator>;
 
+#if __glibcxx_ranges_to_container // C++ >= 23
+  template>,
+  __allocator_like _Alloc =
+ std::allocator<__detail::__range_to_alloc_type<_Rg>>>
+multimap(from_range_t, _Rg&&, _Compare = _Compare(), _Alloc = _Alloc())
+  -> multimap<__detail::__range_key_type<_Rg>,
+ __detail::__range_mapped_type<_Rg>,
+ _Compare, _Alloc>;
+
+  template
+multimap(from_range_t, _Rg&&, _Alloc)
+  -> multimap<__detail::__range_key_type<_Rg>,
+ __detail::__range_mapped_type<_Rg>,
+ less<__detail::__range_key_type<_Rg>>,
+ _Alloc>;
+#endif
 #endif
 
   template= 23
+  /**
+   * @brief Construct a multiset from a range.
+   * @since C++23
+   */
+  template _Rg>
+   multiset(std::from_range_t __t, _Rg&& __rg,
+const _Compare& __c,
+const allocator_type& __a = allocator_type())
+   : _Base(__t, std::forward<_Rg>(__rg), __c, __a)
+   { }
+
+  template _Rg>
+   multiset(std::from_range_t __t, _Rg&& __rg,
+const allocator_type& __a = allocator_type())
+   : _Base(__t, std::forward<_Rg>(__rg), __a)
+   { }
+#endif
+
   ~multiset() = default;
 #endif
 
@@ -594,6 +613,17 @@ namespace __debug
 multiset(initializer_list<_Key>, _Allocator)
 -> multiset<_Key, less<_Key>, _Allocator>;
 
+#if __glibcxx_ranges_to_container // C++ >= 23
+  template>,
+  __allocator_like _Alloc = std::allocator>>
+multiset(from_range_t, _Rg&&, _Compare = _Compare(), _Alloc = _Alloc())
+  -> multiset, _Compare, _Alloc>;
+
+  template
+multiset(from_range_t, _Rg&&, _Alloc)
+  -> multiset, 
less>, _Alloc>;
+#endif
 #endif // deduction guide

[PATCH 2/3] libstdc++: Fix localized D_T_FMT %c formatting for [PR117214]

[Jonathan Wakely]

From: XU Kailiang 

Formatting a time point with %c was implemented by calling
std::vprint_to with format string constructed from locale's D_T_FMT
string, but in some locales this string contains strftime specifiers
which are not valid for chrono-specs, e.g. %l. So just use _M_locale_fmt
to avoid this problem.

libstdc++-v3/ChangeLog:

PR libstdc++/117214
* include/bits/chrono_io.h (__formatter_chrono::_M_c): Use
_M_locale_fmt to format %c time point.
* testsuite/std/time/format/pr117214.cc: New test.

Signed-off-by: XU Kailiang 

Co-authored-by: Jonathan Wakely 
---

Tested x86_64-linux.

 libstdc++-v3/include/bits/chrono_io.h | 35 ++-
 .../testsuite/std/time/format/pr117214.cc | 34 ++
 2 files changed, 53 insertions(+), 16 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/std/time/format/pr117214.cc

diff --git a/libstdc++-v3/include/bits/chrono_io.h 
b/libstdc++-v3/include/bits/chrono_io.h
index 55ebd4ee061..86338d48d18 100644
--- a/libstdc++-v3/include/bits/chrono_io.h
+++ b/libstdc++-v3/include/bits/chrono_io.h
@@ -887,27 +887,30 @@ namespace __format
 
   template
typename _FormatContext::iterator
-   _M_c(const _Tp& __tt, typename _FormatContext::iterator __out,
+   _M_c(const _Tp& __t, typename _FormatContext::iterator __out,
 _FormatContext& __ctx, bool __mod = false) const
{
  // %c  Locale's date and time representation.
  // %Ec Locale's alternate date and time representation.
 
- basic_string<_CharT> __fmt;
- auto __t = _S_floor_seconds(__tt);
- locale __loc = _M_locale(__ctx);
- const auto& __tp = use_facet<__timepunct<_CharT>>(__loc);
- const _CharT* __formats[2];
- __tp._M_date_time_formats(__formats);
- if (*__formats[__mod]) [[likely]]
-   {
- __fmt = _GLIBCXX_WIDEN("{:L}");
- __fmt.insert(3u, __formats[__mod]);
-   }
- else
-   __fmt = _GLIBCXX_WIDEN("{:L%a %b %e %T %Y}");
- return std::vformat_to(std::move(__out), __loc, __fmt,
-std::make_format_args<_FormatContext>(__t));
+ using namespace chrono;
+ auto __d = _S_days(__t); // Either sys_days or local_days.
+ using _TDays = decltype(__d);
+ const year_month_day __ymd(__d);
+ const auto __y = __ymd.year();
+ const auto __hms = _S_hms(__t);
+
+ struct tm __tm{};
+ __tm.tm_year = (int)__y - 1900;
+ __tm.tm_yday = (__d - _TDays(__y/January/1)).count();
+ __tm.tm_mon = (unsigned)__ymd.month() - 1;
+ __tm.tm_mday = (unsigned)__ymd.day();
+ __tm.tm_wday = weekday(__d).c_encoding();
+ __tm.tm_hour = __hms.hours().count();
+ __tm.tm_min = __hms.minutes().count();
+ __tm.tm_sec = __hms.seconds().count();
+ return _M_locale_fmt(std::move(__out), _M_locale(__ctx), __tm, 'c',
+  __mod ? 'E' : '\0');
}
 
   template
diff --git a/libstdc++-v3/testsuite/std/time/format/pr117214.cc 
b/libstdc++-v3/testsuite/std/time/format/pr117214.cc
new file mode 100644
index 000..e7831832206
--- /dev/null
+++ b/libstdc++-v3/testsuite/std/time/format/pr117214.cc
@@ -0,0 +1,34 @@
+// { dg-do run { target c++20 } }
+// { dg-require-namedlocale "aa_DJ.UTF-8" }
+// { dg-require-namedlocale "ar_SA.UTF-8" }
+// { dg-require-namedlocale "ca_AD.UTF-8" }
+// { dg-require-namedlocale "az_IR.UTF-8" }
+// { dg-require-namedlocale "my_MM.UTF-8" }
+
+#include 
+#include 
+#include 
+
+void
+test_c()
+{
+  const char *test_locales[] = {
+"aa_DJ.UTF-8",
+"ar_SA.UTF-8",
+"ca_AD.UTF-8",
+"az_IR.UTF-8",
+"my_MM.UTF-8",
+  };
+  std::chrono::sys_seconds t{std::chrono::seconds{1}};
+
+  for (auto locale_name : test_locales)
+  {
+auto s = std::format(std::locale(locale_name), "{:L%c}", t);
+VERIFY( !s.empty() );
+  }
+}
+
+int main()
+{
+  test_c();
+}
-- 
2.48.1

Re: [PATCH] libstdc++: Add from_range_t constructors to debug ordered containers

[Tomasz Kaminski]

On Thu, Mar 20, 2025 at 10:31 AM Jonathan Wakely  wrote:

> libstdc++-v3/ChangeLog:
>
> * include/debug/map.h (map): Add from_range constructors and
> deduction guides.
> * include/debug/multimap.h (multimap): Likewise.
> * include/debug/multiset.h (multiset): Likewise.
> * include/debug/set.h (set): Likewise.
> ---
>
> When testing with -D_GLIBCXX_DEBUG I noticed we need the new ctors and
> deduction guides for the debug mode containers. This adds them for 
> and , but we also need them for the unordered containers.
>
> Tested x86_64-linux.
>
LGTM

>
>  libstdc++-v3/include/debug/map.h  | 36 +++
>  libstdc++-v3/include/debug/multimap.h | 36 +++
>  libstdc++-v3/include/debug/multiset.h | 30 ++
>  libstdc++-v3/include/debug/set.h  | 32 +++-
>  4 files changed, 133 insertions(+), 1 deletion(-)
>
> diff --git a/libstdc++-v3/include/debug/map.h
> b/libstdc++-v3/include/debug/map.h
> index a9fac790b1c..aa1c1dbd47a 100644
> --- a/libstdc++-v3/include/debug/map.h
> +++ b/libstdc++-v3/include/debug/map.h
> @@ -133,6 +133,25 @@ namespace __debug
> __gnu_debug::__base(__last), __a)
> { }
>
> +#if __glibcxx_ranges_to_container // C++ >= 23
> +  /**
> +   * @brief Construct a map from a range.
> +   * @since C++23
> +   */
> +  template
> _Rg>
> +   map(std::from_range_t __t, _Rg&& __rg,
> +   const _Compare& __c,
> +   const allocator_type& __a = allocator_type())
> +   : _Base(__t, std::forward<_Rg>(__rg), __c, __a)
> +   { }
> +
> +  template
> _Rg>
> +   map(std::from_range_t __t, _Rg&& __rg,
> +   const allocator_type& __a = allocator_type())
> +   : _Base(__t, std::forward<_Rg>(__rg), __a)
> +   { }
> +#endif
> +
>~map() = default;
>  #endif
>
> @@ -740,6 +759,23 @@ namespace __debug
>  map(initializer_list>, _Allocator)
>  -> map<_Key, _Tp, less<_Key>, _Allocator>;
>
> +#if __glibcxx_ranges_to_container // C++ >= 23
> +  template +  __not_allocator_like _Compare =
> less<__detail::__range_key_type<_Rg>>,
> +  __allocator_like _Alloc =
> + std::allocator<__detail::__range_to_alloc_type<_Rg>>>
> +map(from_range_t, _Rg&&, _Compare = _Compare(), _Alloc = _Alloc())
> +  -> map<__detail::__range_key_type<_Rg>,
> +__detail::__range_mapped_type<_Rg>,
> +_Compare, _Alloc>;
> +
> +  template
> +map(from_range_t, _Rg&&, _Alloc)
> +  -> map<__detail::__range_key_type<_Rg>,
> +__detail::__range_mapped_type<_Rg>,
> +less<__detail::__range_key_type<_Rg>>,
> +_Alloc>;
> +#endif
>  #endif // deduction guides
>
>template diff --git a/libstdc++-v3/include/debug/multimap.h
> b/libstdc++-v3/include/debug/multimap.h
> index 8feca2c7eeb..bef1f174a8e 100644
> --- a/libstdc++-v3/include/debug/multimap.h
> +++ b/libstdc++-v3/include/debug/multimap.h
> @@ -133,6 +133,25 @@ namespace __debug
>   __glibcxx_check_valid_constructor_range(__first,
> __last)),
> __gnu_debug::__base(__last), __a) { }
>
> +#if __glibcxx_ranges_to_container // C++ >= 23
> +  /**
> +   * @brief Construct a multimap from a range.
> +   * @since C++23
> +   */
> +  template
> _Rg>
> +   multimap(std::from_range_t __t, _Rg&& __rg,
> +const _Compare& __c,
> +const allocator_type& __a = allocator_type())
> +   : _Base(__t, std::forward<_Rg>(__rg), __c, __a)
> +   { }
> +
> +  template
> _Rg>
> +   multimap(std::from_range_t __t, _Rg&& __rg,
> +const allocator_type& __a = allocator_type())
> +   : _Base(__t, std::forward<_Rg>(__rg), __a)
> +   { }
> +#endif
> +
>~multimap() = default;
>  #endif
>
> @@ -622,6 +641,23 @@ namespace __debug
>  multimap(initializer_list>, _Allocator)
>  -> multimap<_Key, _Tp, less<_Key>, _Allocator>;
>
> +#if __glibcxx_ranges_to_container // C++ >= 23
> +  template +  __not_allocator_like _Compare =
> less<__detail::__range_key_type<_Rg>>,
> +  __allocator_like _Alloc =
> + std::allocator<__detail::__range_to_alloc_type<_Rg>>>
> +multimap(from_range_t, _Rg&&, _Compare = _Compare(), _Alloc =
> _Alloc())
> +  -> multimap<__detail::__range_key_type<_Rg>,
> + __detail::__range_mapped_type<_Rg>,
> + _Compare, _Alloc>;
> +
> +  template
> +multimap(from_range_t, _Rg&&, _Alloc)
> +  -> multimap<__detail::__range_key_type<_Rg>,
> + __detail::__range_mapped_type<_Rg>,
> + less<__detail::__range_key_type<_Rg>>,
> + _Alloc>;
> +#endif
>  #endif
>
>template diff --git a/libstdc++-v3/include/debug/multiset.h
> b/libstdc++-v3/include/debug/multiset.h
> index 09db81f8bae..bddcd282bfa 100644
> --- a/libstdc++-v3/include/debug/multiset.h
> ++

[PATCH] RISC-V: Recognized Svrsw60t59b extension

[Mingzhu Yan]

This patch support svrsw60t59b extension[1].
To enable GCC to recognize and process svrsw60t59b extension correctly at 
compile time.

[1] https://github.com/riscv/Svrsw60t59b

gcc/ChangeLog:

* common/config/riscv/riscv-common.cc: New extension.
* config/riscv/riscv-opts.h: New mask.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/arch-45.c: New test.

Signed-off-by: Mingzhu Yan 
---
 gcc/common/config/riscv/riscv-common.cc  | 16 +---
 gcc/config/riscv/riscv.opt   |  2 ++
 gcc/doc/invoke.texi  |  8 
 gcc/testsuite/gcc.target/riscv/arch-45.c |  5 +
 4 files changed, 24 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/arch-45.c

diff --git a/gcc/common/config/riscv/riscv-common.cc 
b/gcc/common/config/riscv/riscv-common.cc
index 5038f0eb959..418bd10a132 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -409,10 +409,11 @@ static const struct riscv_ext_version 
riscv_ext_version_table[] =
   {"ssstateen", ISA_SPEC_CLASS_NONE, 1, 0},
   {"sstc",  ISA_SPEC_CLASS_NONE, 1, 0},
 
-  {"svinval", ISA_SPEC_CLASS_NONE, 1, 0},
-  {"svnapot", ISA_SPEC_CLASS_NONE, 1, 0},
-  {"svpbmt",  ISA_SPEC_CLASS_NONE, 1, 0},
-  {"svvptc",  ISA_SPEC_CLASS_NONE, 1, 0},
+  {"svinval", ISA_SPEC_CLASS_NONE, 1, 0},
+  {"svnapot", ISA_SPEC_CLASS_NONE, 1, 0},
+  {"svpbmt",  ISA_SPEC_CLASS_NONE, 1, 0},
+  {"svvptc",  ISA_SPEC_CLASS_NONE, 1, 0},
+  {"svrsw60t59b", ISA_SPEC_CLASS_NONE, 1, 0},
 
   {"xcvmac", ISA_SPEC_CLASS_NONE, 1, 0},
   {"xcvalu", ISA_SPEC_CLASS_NONE, 1, 0},
@@ -1732,9 +1733,10 @@ static const riscv_ext_flag_table_t 
riscv_ext_flag_table[] =
   RISCV_EXT_FLAG_ENTRY ("zcmp", x_riscv_zc_subext, MASK_ZCMP),
   RISCV_EXT_FLAG_ENTRY ("zcmt", x_riscv_zc_subext, MASK_ZCMT),
 
-  RISCV_EXT_FLAG_ENTRY ("svinval", x_riscv_sv_subext, MASK_SVINVAL),
-  RISCV_EXT_FLAG_ENTRY ("svnapot", x_riscv_sv_subext, MASK_SVNAPOT),
-  RISCV_EXT_FLAG_ENTRY ("svvptc", x_riscv_sv_subext, MASK_SVVPTC),
+  RISCV_EXT_FLAG_ENTRY ("svinval", x_riscv_sv_subext, MASK_SVINVAL),
+  RISCV_EXT_FLAG_ENTRY ("svnapot", x_riscv_sv_subext, MASK_SVNAPOT),
+  RISCV_EXT_FLAG_ENTRY ("svvptc",  x_riscv_sv_subext, MASK_SVVPTC),
+  RISCV_EXT_FLAG_ENTRY ("svrsw60t59b", x_riscv_sv_subext, MASK_SVVPTC),
 
   RISCV_EXT_FLAG_ENTRY ("ztso", x_riscv_ztso_subext, MASK_ZTSO),
 
diff --git a/gcc/config/riscv/riscv.opt b/gcc/config/riscv/riscv.opt
index 7515c8ea13d..4c6387ab709 100644
--- a/gcc/config/riscv/riscv.opt
+++ b/gcc/config/riscv/riscv.opt
@@ -472,6 +472,8 @@ Mask(SVNAPOT) Var(riscv_sv_subext)
 
 Mask(SVVPTC) Var(riscv_sv_subext)
 
+Mask(SVRSW60T59B) Var(riscv_sv_subext)
+
 TargetVariable
 int riscv_ztso_subext
 
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 0c7adc039b5..5adc27b45e0 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -31188,6 +31188,14 @@ to @samp{zvks} and @samp{zvkg}.
 @tab 1.0
 @tab Page-based memory types extension.
 
+@item svvptc
+@tab 1.0
+@tab Obviating Memory-Management Instructions after Marking PTEs Valid 
extension.
+
+@item svrsw60t59b
+@tab 1.0
+@tab PTE Reserved-for-Software Bits 60-59 extension.
+
 @item xcvmac
 @tab 1.0
 @tab Core-V multiply-accumulate extension.
diff --git a/gcc/testsuite/gcc.target/riscv/arch-45.c 
b/gcc/testsuite/gcc.target/riscv/arch-45.c
new file mode 100644
index 000..fe3ee441d49
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/arch-45.c
@@ -0,0 +1,5 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gc_svrsw60t59b -mabi=lp64" } */
+int foo()
+{
+}
-- 
2.48.1

[COMMITTED 071/144] gccrs: Used `IndexVec` for Loans

[arthur . cohen]

From: Kushal Pal 

gcc/rust/ChangeLog:

* checks/errors/borrowck/rust-bir-place.h: Used `IndexVec` with
ScopeId as index.
* checks/errors/borrowck/rust-borrow-checker-diagnostics.cc
(BorrowCheckerDiagnostics::get_loan): Convert Polonius::Loan to
BIR::Loan, so we can use it as index.

Signed-off-by: Kushal Pal 
---
 gcc/rust/checks/errors/borrowck/rust-bir-place.h | 16 
 .../borrowck/rust-borrow-checker-diagnostics.cc  |  2 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/gcc/rust/checks/errors/borrowck/rust-bir-place.h 
b/gcc/rust/checks/errors/borrowck/rust-bir-place.h
index bf4dfe625a0..ae8bec2e273 100644
--- a/gcc/rust/checks/errors/borrowck/rust-bir-place.h
+++ b/gcc/rust/checks/errors/borrowck/rust-bir-place.h
@@ -215,10 +215,12 @@ public:
   {
 internal_vector.emplace_back (std::forward (args)...);
   }
+  std::vector &get_vector () { return internal_vector; }
   size_t size () const { return internal_vector.size (); }
 };
 
 using Scopes = IndexVec;
+using Loans = IndexVec;
 
 /** Allocated places and keeps track of paths. */
 class PlaceDB
@@ -230,7 +232,7 @@ private:
   Scopes scopes;
   ScopeId current_scope = ROOT_SCOPE;
 
-  std::vector loans;
+  Loans loans;
 
   FreeRegion next_free_region = {1};
 
@@ -251,11 +253,8 @@ public:
 
   size_t size () const { return places.size (); }
 
-  const std::vector &get_loans () const { return loans; }
-  const Loan &get_loan (LoanId loan_id) const
-  {
-return loans.at (loan_id.value);
-  }
+  const Loans &get_loans () const { return loans; }
+  const Loan &get_loan (LoanId loan_id) const { return loans.at (loan_id); }
 
   ScopeId get_current_scope_id () const { return current_scope; }
 
@@ -383,8 +382,9 @@ public:
   {
 LoanId id = {loans.size ()};
 loans.push_back (std::forward (loan));
-PlaceId borrowed_place = loans.rbegin ()->place;
-places[loans.rbegin ()->place.value].borrowed_by.push_back (id);
+PlaceId borrowed_place = loans.get_vector ().rbegin ()->place;
+places[loans.get_vector ().rbegin ()->place.value].borrowed_by.push_back (
+  id);
 if (places[borrowed_place.value].kind == Place::DEREF)
   {
places[places[borrowed_place.value].path.parent.value]
diff --git a/gcc/rust/checks/errors/borrowck/rust-borrow-checker-diagnostics.cc 
b/gcc/rust/checks/errors/borrowck/rust-borrow-checker-diagnostics.cc
index f2e4c38cfa0..4002ed4dd34 100644
--- a/gcc/rust/checks/errors/borrowck/rust-borrow-checker-diagnostics.cc
+++ b/gcc/rust/checks/errors/borrowck/rust-borrow-checker-diagnostics.cc
@@ -142,7 +142,7 @@ BorrowCheckerDiagnostics::get_statement (Polonius::Point 
point)
 const BIR::Loan &
 BorrowCheckerDiagnostics::get_loan (Polonius::Loan loan)
 {
-  return bir_function.place_db.get_loans ()[loan];
+  return bir_function.place_db.get_loans ()[{loan}];
 }
 
 const HIR::LifetimeParam *
-- 
2.45.2

Contents of PO file 'cpplib-15.1-b20250316.de.po'

[Translation Project Robot]

cpplib-15.1-b20250316.de.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH] SCC-Copy: Add More Debug dumps

[Filip Kastl]

On Mon 2025-03-17 15:52:53, Andrew Pinski wrote:
> While debugging a failure, I noticed that SCC copy didn't print
> out what it was doing, e.g. replacing name1 with name 2.
> This adds that dump.

That's useful indeed.  Thanks for that addition!

Filip Kastl

[committed] openmp: Fix up cloning of dynamic C++ initializers for OpenMP target [PR119370]

[Jakub Jelinek]

Hi!

The following testcase ICEs, because we emit the dynamic initialization twice,
once for host and once for target initialization, and although we use
copy_tree_body_r to unshare it, e.g. for the array initializers it can contain
TARGET_EXPRs with local temporaries (or local temporaries alone).
Now, these temporaries were created when current_function_decl was NULL,
they are outside of any particular function, so they have DECL_CONTEXT NULL.
That is normally fine, gimple_add_tmp_var will set DECL_CONTEXT for them
later on to the host __static_init* function into which they are gimplified.
The problem is that the copy_tree_body_r cloning happens before that (and has
to, gimplification is destructive and so we couldn't gimplify the same tree
again in __omp_static_init* function) and uses auto_var_in_fn_p to see what
needs to be remapped.  But that means it doesn't remap temporaries with
NULL DECL_CONTEXT and having the same temporaries in two different functions
results in ICEs (sure, one can e.g. use parent function's temporaries in a
nested function).

The following patch just arranges to set DECL_CONTEXT on the temporaries
to the host dynamic initialization function, so that they get remapped.
If gimplification cared whether DECL_CONTEXT is NULL or not, we could
remember those that we've changed in a vector and undo it afterwards,
but seems it doesn't really care.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed
to trunk.

2025-03-20  Jakub Jelinek  

PR c++/119370
* decl2.cc (set_context_for_auto_vars_r): New function.
(emit_partial_init_fini_fn): Call walk_tree with that function
on &init before walk_tree with copy_tree_body_r.

* g++.dg/gomp/pr119370.C: New test.

--- gcc/cp/decl2.cc.jj  2025-03-19 09:28:54.379608265 +0100
+++ gcc/cp/decl2.cc 2025-03-19 14:05:18.560526678 +0100
@@ -4603,6 +4603,23 @@ decomp_finalize_var_list (tree sl, int s
 }
 }
 
+/* Helper for emit_partial_init_fini_fn OpenMP target handling, called via
+   walk_tree.  Set DECL_CONTEXT on any automatic temporaries which still
+   have it NULL to id->src_fn, so that later copy_tree_body_r can remap those.
+   Otherwise DECL_CONTEXT would be set only during gimplification of the host
+   fn and when copy_tree_body_r doesn't remap those, we'd ICE during the
+   target fn gimplification because the same automatic VAR_DECL can't be
+   used in multiple functions (with the exception of nested functions).  */
+
+static tree
+set_context_for_auto_vars_r (tree *tp, int *, void *data)
+{
+  copy_body_data *id = (copy_body_data *) data;
+  if (auto_var_in_fn_p (*tp, NULL_TREE) && DECL_ARTIFICIAL (*tp))
+DECL_CONTEXT (*tp) = id->src_fn;
+  return NULL_TREE;
+}
+
 /* Generate code to do the initialization or destruction of the decls in VARS,
a TREE_LIST of VAR_DECL with static storage duration.
Whether initialization or destruction is performed is specified by INITP.  
*/
@@ -4661,6 +4678,7 @@ emit_partial_init_fini_fn (bool initp, u
  id.transform_new_cfg = true;
  id.transform_return_to_modify = false;
  id.eh_lp_nr = 0;
+ walk_tree (&init, set_context_for_auto_vars_r, &id, NULL);
  walk_tree (&init, copy_tree_body_r, &id, NULL);
}
   /* Do one initialization or destruction.  */
--- gcc/testsuite/g++.dg/gomp/pr119370.C.jj 2025-03-19 14:08:47.035621074 
+0100
+++ gcc/testsuite/g++.dg/gomp/pr119370.C2025-03-19 14:08:30.315854103 
+0100
@@ -0,0 +1,10 @@
+// PR c++/119370
+// { dg-do compile }
+
+#pragma omp declare target
+struct S {
+  int s;
+  S () : s (0) {}
+};
+S a[2];
+#pragma omp end declare target

Jakub

[PATCH][v2] Make function_decl_type a scoped enum

[Richard Biener]

The enum currently has a member named NONE which pollutes the global
namespace unnecessarily.  Use a scoped enum instead.

v2 makes the scoped enum unsigned and fixes up a bogus use of NONE
in the aarch64 backend.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

gcc/
* tree-core.h (function_decl_type): Make a scoped enum.
* tree.h (set_function_decl_type): Adjust.
(DECL_IS_OPERATOR_NEW_P): Likewise.
(DECL_SET_IS_OPERATOR_NEW): Likewise.
(DECL_IS_OPERATOR_DELETE_P): Likewise.
(DECL_SET_IS_OPERATOR_DELETE): Likewise.
(DECL_LAMBDA_FUNCTION_P): Likewise.
(DECL_SET_LAMBDA_FUNCTION): Likewise.
* lto-streamer-out.cc (hash_tree): Hash all of
FUNCTION_DECL_DECL_TYPE.
* tree-streamer-out.cc (pack_ts_function_decl_value_fields):
Adjust.
* config/aarch64/aarch64-simd-pragma-builtins.def (vcombine_mf8):
Use literal zero instead of NONE.

gcc/cp/
* module.cc (trees_out::core_bools): Convert scoped enum
explicitly.
---
 .../aarch64/aarch64-simd-pragma-builtins.def  |  2 +-
 gcc/cp/module.cc  |  2 +-
 gcc/lto-streamer-out.cc   |  2 +-
 gcc/tree-core.h   |  2 +-
 gcc/tree-streamer-out.cc  |  2 +-
 gcc/tree.h| 22 ---
 6 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/gcc/config/aarch64/aarch64-simd-pragma-builtins.def 
b/gcc/config/aarch64/aarch64-simd-pragma-builtins.def
index 2c0dc11b055..77682365103 100644
--- a/gcc/config/aarch64/aarch64-simd-pragma-builtins.def
+++ b/gcc/config/aarch64/aarch64-simd-pragma-builtins.def
@@ -203,7 +203,7 @@ ENTRY_TERNARY (vbslq_mf8, mf8q, u8q, mf8q, mf8q, 
UNSPEC_BSL, QUIET)
 #undef REQUIRED_EXTENSIONS
 
 // combine
-#define REQUIRED_EXTENSIONS nonstreaming_only (NONE)
+#define REQUIRED_EXTENSIONS nonstreaming_only (0)
 ENTRY_BINARY (vcombine_mf8, mf8q, mf8, mf8, UNSPEC_COMBINE, QUIET)
 #undef REQUIRED_EXTENSIONS
 
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 0d9e50bba7f..beceafe05f6 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -5757,7 +5757,7 @@ trees_out::core_bools (tree t, bits_out& bits)
   WB (t->function_decl.replaceable_operator);
 
   /* decl_type is a (misnamed) 2 bit discriminator. */
-  unsigned kind = t->function_decl.decl_type;
+  unsigned kind = (unsigned)t->function_decl.decl_type;
   WB ((kind >> 0) & 1);
   WB ((kind >> 1) & 1);
 }
diff --git a/gcc/lto-streamer-out.cc b/gcc/lto-streamer-out.cc
index acaf5b71c75..48a67f52143 100644
--- a/gcc/lto-streamer-out.cc
+++ b/gcc/lto-streamer-out.cc
@@ -1343,7 +1343,7 @@ hash_tree (struct streamer_tree_cache_d *cache, 
hash_map *map,
   hstate.add_int (DECL_BUILT_IN_CLASS (t));
   hstate.add_flag (DECL_STATIC_CONSTRUCTOR (t));
   hstate.add_flag (DECL_STATIC_DESTRUCTOR (t));
-  hstate.add_flag (FUNCTION_DECL_DECL_TYPE (t));
+  hstate.add_int ((unsigned)FUNCTION_DECL_DECL_TYPE (t));
   hstate.add_flag (DECL_UNINLINABLE (t));
   hstate.add_flag (DECL_POSSIBLY_INLINED (t));
   hstate.add_flag (DECL_IS_NOVOPS (t));
diff --git a/gcc/tree-core.h b/gcc/tree-core.h
index 6e76d2bdb80..bd19c99d326 100644
--- a/gcc/tree-core.h
+++ b/gcc/tree-core.h
@@ -2023,7 +2023,7 @@ struct GTY(()) tree_decl_non_common {
 
 /* Classify a special function declaration type.  */
 
-enum function_decl_type
+enum class function_decl_type : unsigned
 {
   NONE,
   OPERATOR_NEW,
diff --git a/gcc/tree-streamer-out.cc b/gcc/tree-streamer-out.cc
index 0b61422c541..34227259b8a 100644
--- a/gcc/tree-streamer-out.cc
+++ b/gcc/tree-streamer-out.cc
@@ -306,7 +306,7 @@ pack_ts_function_decl_value_fields (struct bitpack_d *bp, 
tree expr)
   bp_pack_value (bp, DECL_IS_NOVOPS (expr), 1);
   bp_pack_value (bp, DECL_IS_RETURNS_TWICE (expr), 1);
   bp_pack_value (bp, DECL_IS_MALLOC (expr), 1);
-  bp_pack_value (bp, FUNCTION_DECL_DECL_TYPE (expr), 2);
+  bp_pack_value (bp, (unsigned)FUNCTION_DECL_DECL_TYPE (expr), 2);
   bp_pack_value (bp, DECL_IS_OPERATOR_DELETE_P (expr), 1);
   bp_pack_value (bp, DECL_DECLARED_INLINE_P (expr), 1);
   bp_pack_value (bp, DECL_STATIC_CHAIN (expr), 1);
diff --git a/gcc/tree.h b/gcc/tree.h
index 6f45359f103..55f97f9f999 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -3424,12 +3424,12 @@ set_function_decl_type (tree decl, function_decl_type 
t, bool set)
 {
   if (set)
 {
-  gcc_assert (FUNCTION_DECL_DECL_TYPE (decl) == NONE
+  gcc_assert (FUNCTION_DECL_DECL_TYPE (decl) == function_decl_type::NONE
  || FUNCTION_DECL_DECL_TYPE (decl) == t);
   FUNCTION_DECL_DECL_TYPE (decl) = t;
 }
   else if (FUNCTION_DECL_DECL_TYPE (decl) == t)
-FUNCTION_DECL_DECL_TYPE (decl) = NONE;
+FUNCTION_DECL_DECL_TYPE (decl) = function_decl_type::NONE;
 }
 
 /* Nonzero in a FUNCTION_DECL means this function is a replaceable
@@ -3441,21 +3441,25 @

[PATCH] i386: Fix AVX10.2 SAT CVT testcases.

[Hu, Lin1]

Hi,

res_ref will be modified after MASK_ZERO, init res_ref2 for rounding
control intrinsics.

Bootstrapped and regtested on x86-64-pc-linux-gnu{-m32,-m64}, OK for trunk?

BRs,
Lin

gcc/testsuite/ChangeLog:

* gcc.target/i386/avx10_2-512-vcvtph2ibs-2.c: Fix testcase.
* gcc.target/i386/avx10_2-512-vcvtph2iubs-2.c: Ditto.
* gcc.target/i386/avx10_2-512-vcvtps2ibs-2.c: Ditto.
* gcc.target/i386/avx10_2-512-vcvtps2iubs-2.c: Ditto.
* gcc.target/i386/avx10_2-512-vcvttpd2dqs-2.c: Ditto.
* gcc.target/i386/avx10_2-512-vcvttpd2qqs-2.c: Ditto.
* gcc.target/i386/avx10_2-512-vcvttpd2udqs-2.c: Ditto.
* gcc.target/i386/avx10_2-512-vcvttpd2uqqs-2.c: Ditto.
* gcc.target/i386/avx10_2-512-vcvttph2ibs-2.c: Ditto.
* gcc.target/i386/avx10_2-512-vcvttps2dqs-2.c: Ditto.
* gcc.target/i386/avx10_2-512-vcvttps2ibs-2.c: Ditto.
* gcc.target/i386/avx10_2-512-vcvttps2iubs-2.c: Ditto.
* gcc.target/i386/avx10_2-512-vcvttps2qqs-2.c: Ditto.
* gcc.target/i386/avx10_2-512-vcvttps2udqs-2.c: Ditto.
* gcc.target/i386/avx10_2-512-vcvttps2uqqs-2.c: Ditto.
---
 .../gcc.target/i386/avx10_2-512-vcvtph2ibs-2.c  | 17 +++--
 .../gcc.target/i386/avx10_2-512-vcvtph2iubs-2.c | 17 +++--
 .../gcc.target/i386/avx10_2-512-vcvtps2ibs-2.c  | 17 +++--
 .../gcc.target/i386/avx10_2-512-vcvtps2iubs-2.c | 17 +++--
 .../gcc.target/i386/avx10_2-512-vcvttpd2dqs-2.c | 17 +++--
 .../gcc.target/i386/avx10_2-512-vcvttpd2qqs-2.c | 17 +++--
 .../i386/avx10_2-512-vcvttpd2udqs-2.c   | 17 +++--
 .../i386/avx10_2-512-vcvttpd2uqqs-2.c   | 17 +++--
 .../gcc.target/i386/avx10_2-512-vcvttph2ibs-2.c | 17 +++--
 .../gcc.target/i386/avx10_2-512-vcvttps2dqs-2.c | 17 +++--
 .../gcc.target/i386/avx10_2-512-vcvttps2ibs-2.c | 17 +++--
 .../i386/avx10_2-512-vcvttps2iubs-2.c   | 17 +++--
 .../gcc.target/i386/avx10_2-512-vcvttps2qqs-2.c | 17 +++--
 .../i386/avx10_2-512-vcvttps2udqs-2.c   | 17 +++--
 .../i386/avx10_2-512-vcvttps2uqqs-2.c   | 17 +++--
 15 files changed, 165 insertions(+), 90 deletions(-)

diff --git a/gcc/testsuite/gcc.target/i386/avx10_2-512-vcvtph2ibs-2.c 
b/gcc/testsuite/gcc.target/i386/avx10_2-512-vcvtph2ibs-2.c
index 0c860b02046..523b3f0a4cb 100644
--- a/gcc/testsuite/gcc.target/i386/avx10_2-512-vcvtph2ibs-2.c
+++ b/gcc/testsuite/gcc.target/i386/avx10_2-512-vcvtph2ibs-2.c
@@ -9,6 +9,7 @@
 #endif
 #include "avx10-helper.h"
 #include 
+#include 
 
 #define SIZE (AVX512F_LEN / 16)
 #include "avx512f-mask-type.h"
@@ -37,7 +38,7 @@ TEST (void)
   UNION_TYPE (AVX512F_LEN, h) s;
   UNION_TYPE (AVX512F_LEN, i_w) res1, res2, res3;
   MASK_TYPE mask = MASK_VALUE;
-  short res_ref[SIZE] = { 0 };
+  short res_ref[SIZE] = { 0 }, res_ref2[SIZE] = { 0 };
   int i, sign = 1;
 
   for (i = 0; i < SIZE; i++)
@@ -54,6 +55,7 @@ TEST (void)
   res3.x = INTRINSIC (_maskz_ipcvts_ph_epi8) (mask, s.x);
 
   CALC (s.a, res_ref);
+  memcpy(res_ref2, res_ref, sizeof(res_ref));
 
   if (UNION_CHECK (AVX512F_LEN, i_w) (res1, res_ref))
 abort ();
@@ -67,19 +69,22 @@ TEST (void)
 abort ();
 
 #if AVX512F_LEN != 128
+  for (i = 0; i < SIZE; i++)
+res2.a[i] = DEFAULT_VALUE;
+
   res1.x = INTRINSIC (_ipcvts_roundph_epi8) (s.x, 8);
   res2.x = INTRINSIC (_mask_ipcvts_roundph_epi8) (res2.x, mask, s.x, 8);
   res3.x = INTRINSIC (_maskz_ipcvts_roundph_epi8) (mask, s.x, 8);
 
-  if (UNION_CHECK (AVX512F_LEN, i_w) (res1, res_ref))
+  if (UNION_CHECK (AVX512F_LEN, i_w) (res1, res_ref2))
 abort ();
 
-  MASK_MERGE (i_w) (res_ref, mask, SIZE);
-  if (UNION_CHECK (AVX512F_LEN, i_w) (res2, res_ref))
+  MASK_MERGE (i_w) (res_ref2, mask, SIZE);
+  if (UNION_CHECK (AVX512F_LEN, i_w) (res2, res_ref2))
 abort ();
 
-  MASK_ZERO (i_w) (res_ref, mask, SIZE);
-  if (UNION_CHECK (AVX512F_LEN, i_w) (res3, res_ref))
+  MASK_ZERO (i_w) (res_ref2, mask, SIZE);
+  if (UNION_CHECK (AVX512F_LEN, i_w) (res3, res_ref2))
 abort ();
 #endif
 }
diff --git a/gcc/testsuite/gcc.target/i386/avx10_2-512-vcvtph2iubs-2.c 
b/gcc/testsuite/gcc.target/i386/avx10_2-512-vcvtph2iubs-2.c
index 75e4e1141be..a8f6e57d46a 100644
--- a/gcc/testsuite/gcc.target/i386/avx10_2-512-vcvtph2iubs-2.c
+++ b/gcc/testsuite/gcc.target/i386/avx10_2-512-vcvtph2iubs-2.c
@@ -9,6 +9,7 @@
 #endif
 #include "avx10-helper.h"
 #include 
+#include 
 
 #define SIZE (AVX512F_LEN / 16)
 #include "avx512f-mask-type.h"
@@ -37,7 +38,7 @@ TEST (void)
   UNION_TYPE (AVX512F_LEN, h) s;
   UNION_TYPE (AVX512F_LEN, i_w) res1, res2, res3;
   MASK_TYPE mask = MASK_VALUE;
-  short res_ref[SIZE] = { 0 };
+  short res_ref[SIZE] = { 0 }, res_ref2[SIZE] = { 0 };
   int i, sign = 1;
 
   for (i = 0; i < SIZE; i++)
@@ -54,6 +55,7 @@ TEST (void)
   res3.x = INTRINSIC (_maskz_ipcvts_ph_epu8) (mask, s.x);
 
   CALC (s.a, res_ref);
+  memcpy(res_ref

Re: [PATCH 00/27] Use avx10.x as the only option for AVX10 with 512 bit vector support while remove avx10.x-256/512 option and 256 bit rounding support

[Richard Biener]

On Thu, Mar 20, 2025 at 2:37 AM Liu, Hongtao  wrote:
>
>
>
> > -Original Message-
> > From: Jiang, Haochen 
> > Sent: Wednesday, March 19, 2025 3:38 PM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Liu, Hongtao ; ubiz...@gmail.com
> > Subject: [PATCH 00/27] Use avx10.x as the only option for AVX10 with 512 bit
> > vector support while remove avx10.x-256/512 option and 256 bit rounding
> > support
> >
> > Hi all,
> >
> > It is a little late for this change but I hope this will be a welcoming 
> > change since
> > it will greatly simplify the compiler options and reduce confusion for AVX10
> > option combination with AVX512.
> >
> > AVX10 whitepaper just got a major change and it will impact how we design
> > the compiler option, which will actually simplify everything.
> I like the decision.

I also like the decision.  Hopefully they stick to it this time ...

Richard.

> Ok for the series.
> But I'd like to leave a little time for others to comment. so please COMMIT 
> this series in next week if there's no objection.
> >
> > Ref: https://cdrdv2.intel.com/v1/dl/getContent/784343
> >
> > In this new whitepaper, all the platforms will support 512 bit vector width
> > (previously, E-core is up to 256 bit, leading to hybrid clients and Atom 
> > Server
> > 256 bit only). Also, 256 bit rounding is not that useful because we 
> > currently
> > have rounding feature directly on E-core now and no need to use 256-bit
> > rounding as somehow a workaround. HW will remove that support.
> >
> > Thus, there is no need to add avx10.x-256/512 into compiler options. A
> > simple avx10.x supporting all vector length is all we need. The change also
> > makes -mno-evex512 not that useful. It is introduced with avx10.1-256 for
> > compiling 256 bit only binary on legacy platforms to have a partial trial 
> > for
> > avx10.x-256. What we also need to do is to remove 256 bit rounding.
> >
> > For new features added in GCC 15 (i.e., option avx10.2-256/512 and 256 bit
> > rounding), we will just simply remove them. Since avx10.2 has been directed
> > to 512 bit previously. No need to change that option. We will keep the 
> > testcase
> > and intrin file structure for now since it is late in GCC 15 release cycle 
> > and do
> > clean up in GCC 16.
> >
> > For features added in GCC 14 (i.e., option avx10.1-256/512 and no-evex512),
> > we will raise a deprecate warning in GCC 15 and finally remove them in GCC
> > 16. Also, we will need to add avx10.1 back (it was removed just less than 
> > one
> > month ago) and direct it to 512 bit with a warning in GCC 15 since it was
> > aliased to 256 bit previously. The deprecate and re-alias warning would also
> > like to be backported to GCC 14 and landed into GCC 14.3.
> >
> > The change will also lead to AVX10 and AVX512 option combination design
> > simplification. Since we do not need to consider vector width enabled
> > anymore, it is much more natural to just treat avx10.1 to an alias of all
> > avx512xxx in SPR. Thus, "-mavx10.1 -mno-avx512fp16" should enable all
> > AVX512 features while disabling AVX512FP16. And "-mavx512f -mno-
> > avx10.1"
> > should disable all AVX512 features. Both of the two combinations currently
> > will ignore "-mno-". In GCC 15, we will raise a warning to mention that we 
> > are
> > going to change that behavior in GCC 16.
> >
> > Upcoming would be the patches we want to landed in GCC 15. The first two
> > patches are removing 256 bit roundings added with AVX10.2 new
> > instructions.
> > Then the following 22 are simple revert patch for the legacy instruction
> > 256 bit ymm rounding addition. The last three patch is for avx10.x option
> > change.
> >
> > Thx,
> > Haochen
> >
>

Re: [PATCH v2 1/2] PR118442: Don't instrument exit edges after musttail

[Richard Biener]

On Thu, Mar 20, 2025 at 2:34 AM Andi Kleen  wrote:
>
> From: Andi Kleen 
>
> When -fprofile-generate is used musttail often fails because the
> compiler adds instrumentation after the tail calls.
>
> This patch prevents adding exit extra edges after musttail because for a
> tail call the execution leaves the function and can never come back
> even on a unwind or exception.
>
> This is only done for musttail. In principle it could be done
> for any tail calls, but the problem is that there might be other reasons
> why the tail fails later, and then the edge might be still needed.
>
> Passes bootstrap and full testing on x86_64 with no new failures.
>
> [v2 version: Don't affect stmt_can_terminate_bb_p. Fix changelog.
> Adjust test case for clang:: removal.]
>
> Co-authored-by: Andrew Pinski
>
> gcc/ChangeLog:
>
> PR gcov-profile/118442
> * tree-cfg.cc (must_tail_call_p): New function.
> (gimple_flow_call_edges_add): Avoid exit edges for musttail
> calls.
>
> gcc/testsuite/ChangeLog:
>
> * c-c++-common/pr118442.c: New test.
> ---
>  gcc/testsuite/c-c++-common/pr118442.c | 15 +++
>  gcc/tree-cfg.cc   | 16 ++--
>  2 files changed, 29 insertions(+), 2 deletions(-)
>  create mode 100644 gcc/testsuite/c-c++-common/pr118442.c
>
> diff --git a/gcc/testsuite/c-c++-common/pr118442.c 
> b/gcc/testsuite/c-c++-common/pr118442.c
> new file mode 100644
> index 000..24b7f546c98
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/pr118442.c
> @@ -0,0 +1,15 @@
> +/* PR118442 */
> +/* { dg-do compile { target { struct_musttail && { c || c++11 } } } } */
> +/* { dg-options "-fprofile-generate -O2" } */
> +
> +struct Span {
> +int test[5];
> +};
> +
> +void resolveToBufferSlow(struct Span *buffer);
> +
> +void resolveToBuffer(struct Span *buffer)
> +{
> +buffer->test[0] = 4;
> +[[gnu::musttail]] return resolveToBufferSlow(buffer);
> +}
> diff --git a/gcc/tree-cfg.cc b/gcc/tree-cfg.cc
> index 2fa5678051a..85c8082c297 100644
> --- a/gcc/tree-cfg.cc
> +++ b/gcc/tree-cfg.cc
> @@ -8894,6 +8894,18 @@ stmt_can_terminate_bb_p (gimple *t)
>return false;
>  }
>
> +/* Is T a gimple must tail call?  */
> +
> +static bool
> +must_tail_call_p (gimple *t)
> +{
> +  /* When it's a enforced tail call there is no edge because
> + the control flow has left the function and can never come back.
> + This prevents instrumenting the edge which would make the must
> + tail call fail.  */
> +  return is_gimple_call (t)
> +&& gimple_call_must_tail_p (as_a  (t));
> +}
>
>  /* Add fake edges to the function exit for any non constant and non
> noreturn calls (or noreturn calls with EH/abnormal edges),
> @@ -8942,7 +8954,7 @@ gimple_flow_call_edges_add (sbitmap blocks)

Hmm.  I do wonder whether your earlier patch was more "correct" in the
sense that a tail call does not return to the calling function but its caller.
That means it should not have a fallthru edge, so our representation
with feeding a return value to a function-local return stmt isn't a good one.

That said, the CFG hook you are patching is supposed to add edges when
a function call can possibly not reach the return stmt and I think that's
the case for tail-calls.  So IMO the patch is wrong.  Iff instead the
instrumentation confuses later tail-call verification then this instrumentation
should be either not emitted or handled there.

It seems the hook is only used from GIMPLE, so the hookizing could be
undone and the code moved to profile.cc where then special-casing it
in this function would be OK.  You'll see there

  flow_call_edges_add (NULL);
  add_noreturn_fake_exit_edges ();

so it adds noreturn edges that flow_call_edges_add avoids to add.  Pruning
edges added for tail-calls here might be another option then.

Richard.


>if (!gsi_end_p (gsi))
> t = gsi_stmt (gsi);
>
> -  if (t && stmt_can_terminate_bb_p (t))
> +  if (t && stmt_can_terminate_bb_p (t) && !must_tail_call_p (t))
> {
>   edge e;
>
> @@ -8977,7 +8989,7 @@ gimple_flow_call_edges_add (sbitmap blocks)
>   do
> {
>   stmt = gsi_stmt (gsi);
> - if (stmt_can_terminate_bb_p (stmt))
> + if (stmt_can_terminate_bb_p (stmt) && !must_tail_call_p (stmt))
> {
>   edge e;
>
> --
> 2.47.1
>

Re: [PATCH 2/2] [cobol] make sources coretypes.h and tree.h clean

[Jakub Jelinek]

On Thu, Mar 20, 2025 at 10:32:17AM +0100, Jakub Jelinek wrote:
> And more importantly, _Float128 and __int128 are only available on small
> subsets of hosts.  Many of the __int128 uses in the COBOL FE are just
> wrong because they lose the upper 64 bits when turning it into a tree,
> so just using wide_int there designed for arbitrary precision arithmetics
> at compile time fixes that.

Also note that uses of _Float128 in the FE require pretty recent
GCC (>= 13) and clang doesn't support it in C++ at all even in trunk.
Currently, we try hard to make the compiler buildable with GCC as old as
5.4, so the _Float128 uses would mean
--enable-languages=c,c++,cobol --disable-bootstrap
configured compiler doesn't build.
And the uses of *f128 APIs in the FE mean also a dependency on fairly recent
host glibc, many people use new gcc on long term supported distros with
much older glibc.

While on the libgcobol side (like other target libraries) we know they
are built with the new gcc and so can assume features that gcc provides
and for stuff like lack of *f128 APIs in glibc there are libgcobol
patches to make it work with *l APIs when long double is IEEE quad
or with *q APIs from libquadmath, in a GCC FE we certainly don't want
to depend on libquadmath and make stuff conditionally relying on *l or *q or
*f128 APIs.

Jakub

[PATCH 0/1][RFC] middle-end: target support checks for vectorizable_induction

[Spencer Abson]

Hi all,

While tinkering with AArch64's SVE port, I noticed (by means of ICE) that 
vetorizable_induction does not accurately
test target support of the vectorized operations it emits.

This would only give an ICE for variable-length vectors (see 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103523),
so the patch I've attached here covers those only.

The question I'd like to raise is whether we should apply more scrutiny here; a 
vectorized MULT_EXPR is emitted to
calculate the step vector for each IV in SLP induction vectorization, as well 
as whenever we need to calucalate the
initial values of float inductions with variable-length vectors.

Is it worth moving some code around to test for support of MULT_EXPR with the 
mode of STEP_VECTYPE whenver we know
that the transformation will use it?
Is there a reason that testing for target support was omitted from the 
originial code?

While this is an RFC, the patch itself has been bootstrapped and regtested on 
aarch64-linux-gnu.

Thank you very much for any discussion.
Spencer Abson

Spencer Abson (1):
  Induction vectorizer: prevent ICE for scalable types

 gcc/tree-vect-loop.cc | 39 ++-
 1 file changed, 30 insertions(+), 9 deletions(-)

-- 
2.34.1

[PATCH 1/1][RFC] Induction vectorizer: prevent ICE for scalable types

[Spencer Abson]

We currently check that the target suppports PLUS_EXPR and MINUS_EXPR
with step_vectype (a fix for pr103523).  However, vectorizable_induction
can emit a vectorized MULT_EXPR when calculating the step of each IV for
SLP, and both MULT_EXPR/FLOAT_EXPR when calculating VEC_INIT for float
inductions.

gcc/ChangeLog:

* tree-vect-loop.cc (vectorizable_induction): Add target support
checks for vectorized MULT_EXPR and FLOAT_EXPR where necessary for
scalable types.
Prefer target_supports_op_p over directly_supports_p for these tree
codes.
(vect_update_nonlinear_iv): Fix a doc comment while I'm here.
---
 gcc/tree-vect-loop.cc | 39 ++-
 1 file changed, 30 insertions(+), 9 deletions(-)

diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 9413dcef702..cce57978ae2 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -10053,7 +10053,7 @@ vect_update_nonlinear_iv (gimple_seq* stmts, tree 
vectype,
 
 }
 
-/* Function vectorizable_induction
+/* Function vectorizable_nonlinear_induction
 
Check if STMT_INFO performs an nonlinear induction computation that can be
vectorized. If VEC_STMT is also passed, vectorize the induction PHI: create
@@ -10402,6 +10402,7 @@ vectorizable_induction (loop_vec_info loop_vinfo,
   poly_uint64 vf = LOOP_VINFO_VECT_FACTOR (loop_vinfo);
   unsigned i;
   tree expr;
+  tree index_vectype = NULL_TREE;
   gimple_stmt_iterator si;
   enum vect_induction_op_type induction_type
 = STMT_VINFO_LOOP_PHI_EVOLUTION_TYPE (stmt_info);
@@ -10513,12 +10514,29 @@ vectorizable_induction (loop_vec_info loop_vinfo,
 "supported.\n");
   return false;
 }
-  tree step_vectype = get_same_sized_vectype (TREE_TYPE (step_expr), vectype);
+  tree stept = TREE_TYPE (step_expr);
+  tree step_vectype = get_same_sized_vectype (stept, vectype);
 
-  /* Check for backend support of PLUS/MINUS_EXPR. */
-  if (!directly_supported_p (PLUS_EXPR, step_vectype)
-  || !directly_supported_p (MINUS_EXPR, step_vectype))
-return false;
+  /* Check for target support of the vectorized arithmetic used here.  */
+  if (!target_supports_op_p (step_vectype, PLUS_EXPR, optab_default)
+  || !target_supports_op_p (step_vectype, MINUS_EXPR, optab_default))
+  return false;
+  if (!nunits.is_constant ())
+{
+  if (!target_supports_op_p (step_vectype, MULT_EXPR, optab_default))
+   return false;
+  /* FLOAT_EXPR when computing VEC_INIT for float inductions.  */
+  if (SCALAR_FLOAT_TYPE_P (stept))
+   {
+ tree index_type = build_nonstandard_integer_type
+   (GET_MODE_BITSIZE (SCALAR_TYPE_MODE (stept)), 1);
+
+ index_vectype = build_vector_type (index_type, nunits);
+ if (!can_float_p (TYPE_MODE (step_vectype),
+   TYPE_MODE (index_vectype), 1))
+   return false;
+   }
+}
 
   if (!vec_stmt) /* transformation not required.  */
 {
@@ -10637,7 +10655,6 @@ vectorizable_induction (loop_vec_info loop_vinfo,
  nivs = 1;
}
   gimple_seq init_stmts = NULL;
-  tree stept = TREE_TYPE (step_vectype);
   tree lupdate_mul = NULL_TREE;
   if (!nested_in_vect_loop)
{
@@ -10741,7 +10758,9 @@ vectorizable_induction (loop_vec_info loop_vinfo,
   + (vectype) [0, 1, 2, ...] * [step, step, step, ...].  */
  gcc_assert (SCALAR_FLOAT_TYPE_P (TREE_TYPE (steps[0])));
  gcc_assert (flag_associative_math);
- tree index = build_index_vector (step_vectype, 0, 1);
+ gcc_assert (index_vectype != NULL_TREE);
+
+ tree index = build_index_vector (index_vectype, 0, 1);
  new_name = gimple_convert (&init_stmts, TREE_TYPE (steps[0]),
 inits[0]);
  tree base_vec = gimple_build_vector_from_val (&init_stmts,
@@ -11016,7 +11035,9 @@ vectorizable_induction (loop_vec_info loop_vinfo,
+ (vectype) [0, 1, 2, ...] * [step, step, step, ...].  */
  gcc_assert (SCALAR_FLOAT_TYPE_P (TREE_TYPE (step_expr)));
  gcc_assert (flag_associative_math);
- tree index = build_index_vector (step_vectype, 0, 1);
+ gcc_assert (index_vectype != NULL_TREE);
+
+ tree index = build_index_vector (index_vectype, 0, 1);
  tree base_vec = gimple_build_vector_from_val (&stmts, step_vectype,
new_name);
  tree step_vec = gimple_build_vector_from_val (&stmts, step_vectype,
-- 
2.34.1

[PATCH] libgcobol: Add configure checks for iconv.

[Iain Sandoe]

Tested on x86_64 Linux, Darwin, OK for trunk?
thanks
Iain

--- 8< ---

Some targets might need to add libraries to get iconv support.

libgcobol/ChangeLog:

* Makefile.am: Use LIBICONV.
* Makefile.in: Regenerate.
* aclocal.m4: Regenerate.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Check for iconv support.

Signed-off-by: Iain Sandoe 
---
 libgcobol/Makefile.am  |   2 +-
 libgcobol/Makefile.in  |   8 +-
 libgcobol/aclocal.m4   |   4 +
 libgcobol/config.h.in  |   6 +
 libgcobol/configure| 914 -
 libgcobol/configure.ac |   3 +
 6 files changed, 933 insertions(+), 4 deletions(-)

diff --git a/libgcobol/Makefile.am b/libgcobol/Makefile.am
index eddf209807e..888cbf2b0b0 100644
--- a/libgcobol/Makefile.am
+++ b/libgcobol/Makefile.am
@@ -48,7 +48,7 @@ libgcobol_la_LINK = $(LIBTOOL) --mode=link --tag=CXX $(CXX)   
\
-Wc,-shared-libgcc  \
-version-info $(LIBGCOBOL_VERSION)  \
-lstdc++\
-   $(LTLDFLAGS)
+   $(LTLDFLAGS) $(LTLIBICONV)
 
 WARN_CFLAGS = -W -Wall -Wwrite-strings
 
diff --git a/libgcobol/Makefile.in b/libgcobol/Makefile.in
index a6096d2a64a..1a1e2ee39eb 100644
--- a/libgcobol/Makefile.in
+++ b/libgcobol/Makefile.in
@@ -113,7 +113,11 @@ target_triplet = @target@
 subdir = .
 ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
 am__aclocal_m4_deps = $(top_srcdir)/../config/depstand.m4 \
+   $(top_srcdir)/../config/iconv.m4 \
$(top_srcdir)/../config/lead-dot.m4 \
+   $(top_srcdir)/../config/lib-ld.m4 \
+   $(top_srcdir)/../config/lib-link.m4 \
+   $(top_srcdir)/../config/lib-prefix.m4 \
$(top_srcdir)/../config/multi.m4 \
$(top_srcdir)/../config/override.m4 \
$(top_srcdir)/../config/toolexeclibdir.m4 \
@@ -300,11 +304,13 @@ INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
 LD = @LD@
 LDFLAGS = @LDFLAGS@
 LIBGCOBOL_VERSION = @LIBGCOBOL_VERSION@
+LIBICONV = @LIBICONV@
 LIBOBJS = @LIBOBJS@
 LIBS = @LIBS@
 LIBTOOL = @LIBTOOL@
 LIPO = @LIPO@
 LN_S = @LN_S@
+LTLIBICONV = @LTLIBICONV@
 LTLIBOBJS = @LTLIBOBJS@
 MAINT = @MAINT@
 MAKEINFO = @MAKEINFO@
@@ -422,7 +428,7 @@ libgcobol_la_LINK = $(LIBTOOL) --mode=link --tag=CXX $(CXX) 
\
-Wc,-shared-libgcc  \
-version-info $(LIBGCOBOL_VERSION)  \
-lstdc++\
-   $(LTLDFLAGS)
+   $(LTLDFLAGS) $(LTLIBICONV)
 
 WARN_CFLAGS = -W -Wall -Wwrite-strings
 
diff --git a/libgcobol/aclocal.m4 b/libgcobol/aclocal.m4
index 1d5125ec2f0..25c8b71df87 100644
--- a/libgcobol/aclocal.m4
+++ b/libgcobol/aclocal.m4
@@ -1188,7 +1188,11 @@ AC_SUBST([am__untar])
 ]) # _AM_PROG_TAR
 
 m4_include([../config/depstand.m4])
+m4_include([../config/iconv.m4])
 m4_include([../config/lead-dot.m4])
+m4_include([../config/lib-ld.m4])
+m4_include([../config/lib-link.m4])
+m4_include([../config/lib-prefix.m4])
 m4_include([../config/multi.m4])
 m4_include([../config/override.m4])
 m4_include([../config/toolexeclibdir.m4])
diff --git a/libgcobol/config.h.in b/libgcobol/config.h.in
index 39b20448078..a7e5675c43c 100644
--- a/libgcobol/config.h.in
+++ b/libgcobol/config.h.in
@@ -6,6 +6,9 @@
 /* Define to 1 if you have the  header file. */
 #undef HAVE_DLFCN_H
 
+/* Define if you have the iconv() function and it works. */
+#undef HAVE_ICONV
+
 /* Define to 1 if you have the  header file. */
 #undef HAVE_INTTYPES_H
 
@@ -36,6 +39,9 @@
 /* Define to 1 if you have the  header file. */
 #undef HAVE_UNISTD_H
 
+/* Define as const if the declaration of iconv() needs const. */
+#undef ICONV_CONST
+
 /* Define to the sub-directory in which libtool stores uninstalled libraries.
*/
 #undef LT_OBJDIR
diff --git a/libgcobol/configure b/libgcobol/configure
index 73433ebb13d..1db4e792e03 100755
--- a/libgcobol/configure
+++ b/libgcobol/configure
@@ -634,6 +634,8 @@ ac_subst_vars='am__EXEEXT_FALSE
 am__EXEEXT_TRUE
 LTLIBOBJS
 LIBOBJS
+LTLIBICONV
+LIBICONV
 extra_darwin_ldflags_libgcobol
 VERSION_SUFFIX
 LIBGCOBOL_VERSION
@@ -804,6 +806,9 @@ enable_fast_install
 with_gnu_ld
 enable_libtool_lock
 enable_darwin_at_rpath
+enable_rpath
+with_libiconv_prefix
+with_libiconv_type
 '
   ac_precious_vars='build_alias
 host_alias
@@ -1456,6 +1461,7 @@ Optional Features:
   --enable-darwin-at-rpath
   install libraries with @rpath/library-name, requires
   rpaths to be added to executables
+  --disable-rpath do not hardcode runtime library paths
 
 Optional Packages:
   --with-PACKAGE[=ARG]use PACKAGE [ARG=yes]
@@ -1471,6 +1477,10 @@ Optional Packages:
   --with-pic  try to use only PIC/non-PIC objects [default=use
   both]
   --with-gnu-ld   assume the C compiler uses GNU ld [default=no

[PATCH] [cobol] move global data to symbol_table_init

[Richard Biener]

The following avoids early runtime initialization of cbl_field_t
objects which, when using tree to represent the current _Float128
data, segfaults as tree data like float128_type_node is not yet
initialized.  The solution is to move the global data to
symbol_table_init which is the only user and it already has one
such instance locally, the 'constants' array.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

OK?

* symbols.cc (empty_float, empty_comp5, empty_literal,
empty_conditional, debug_registers, special_registers): Move
global cbl_field_t typed data to ...
(symbol_table_init): ... local scope here.
---
 gcc/cobol/symbols.cc | 173 +--
 1 file changed, 84 insertions(+), 89 deletions(-)

diff --git a/gcc/cobol/symbols.cc b/gcc/cobol/symbols.cc
index 17583e002a1..b8d785f2531 100644
--- a/gcc/cobol/symbols.cc
+++ b/gcc/cobol/symbols.cc
@@ -295,81 +295,12 @@ symbol_valid_udf_args( size_t function, 
std::list args ) {
 
 static const struct cbl_occurs_t nonarray = cbl_occurs_t();
 
-static const struct cbl_field_t empty_float = {
-0, FldFloat, FldInvalid,
-intermediate_e,
-0, 0, 0, nonarray, 0, "",
-0, cbl_field_t::linkage_t(),
-{16, 16, 32, 0, NULL}, NULL };
-
-static const struct cbl_field_t empty_comp5 = {
-0, FldNumericBin5, FldInvalid,
-signable_e | intermediate_e,
-0, 0, 0, nonarray, 0, "",
-0, cbl_field_t::linkage_t(),
-{16, 16, MAX_FIXED_POINT_DIGITS, 0, NULL}, 
NULL };
-
 #if 0
 # define CONSTANT_E constant_e
 #else
 # define CONSTANT_E intermediate_e
 #endif
 
-static struct cbl_field_t empty_literal = {
-0, FldInvalid, FldInvalid, CONSTANT_E,
-0, 0, 0, nonarray, 0, "",
-0, cbl_field_t::linkage_t(),
-{}, NULL };
-
-static const struct cbl_field_t empty_conditional = {
-0, FldConditional, FldInvalid, intermediate_e,
-0, 0, 0, nonarray, 0, "",
-0, cbl_field_t::linkage_t(),
-{}, NULL };
-
-
-/**
- * Debug register record
- 01 DEBUG-ITEM.
-02 DEBUG-LINE PIC X(6).
-02 FILLER PIC X VALUE SPACE.
-02 DEBUG-NAME PIC X(30).
-02 FILLER PIC X VALUE SPACE.
-02 DEBUG-SUB-1 PIC S SIGN IS LEADING SEPARATE CHARACTER.
-02 FILLER PIC X VALUE SPACE.
-02 DEBUG-SUB-2 PIC S SIGN IS LEADING SEPARATE CHARACTER.
-02 FILLER PIC X VALUE SPACE.
-02 DEBUG-SUB-3 PIC S SIGN IS LEADING SEPARATE CHARACTER.
-02 FILLER PIC X VALUE SPACE.
-02 DEBUG-CONTENTS PIC X(76).
- **/
-
-static cbl_field_t debug_registers[] = {
-{ 0, FldGroup, FldInvalid, global_e, 0,0,1, nonarray, 0,
-  "DEBUG-ITEM", 0, {}, {132,132,0,0, NULL}, NULL },
-{ 0, FldAlphanumeric, FldInvalid, global_e, 0,0,2, nonarray, 0,
-  "DEBUG-LINE", 0, {}, {6,6,0,0, "  "}, NULL },
-{ 0, FldAlphanumeric, FldInvalid, 0, 0,0,2, nonarray, 0,
-  "FILLER", 0, {}, {1,1,0,0, " "}, NULL },
-{ 0, FldAlphanumeric, FldInvalid, global_e, 0,0,2, nonarray, 0,
-  "DEBUG-NAME", 0, {}, {30,30,0,0, NULL}, NULL },
-{ 0, FldAlphanumeric, FldInvalid, 0, 0,0,2, nonarray, 0,
-  "FILLER", 0, {}, {1,1,0,0, " "}, NULL },
-{ 0, FldNumericDisplay, FldInvalid, signable_e | global_e | leading_e | 
separate_e, 0,0,2, nonarray, 0,
-  "DEBUG-SUB-1", 0, {}, {5,5,3,0, NULL}, NULL },
-{ 0, FldAlphanumeric, FldInvalid, 0, 0,0,2, nonarray, 0,
-  "FILLER", 0, {}, {1,1,0,0, " "}, NULL },
-{ 0, FldNumericDisplay, FldInvalid, signable_e | global_e | leading_e | 
separate_e, 0,0,2, nonarray, 0,
-  "DEBUG-SUB-2", 0, {}, {5,5,3,0, NULL}, NULL },
-{ 0, FldAlphanumeric, FldInvalid, 0, 0,0,2, nonarray, 0,
-  "FILLER", 0, {}, {1,1,0,0, " "}, NULL },
-{ 0, FldNumericDisplay, FldInvalid, signable_e | global_e | leading_e | 
separate_e, 0,0,2, nonarray, 0,
-  "DEBUG-SUB-3", 0, {}, {5,5,3,0, NULL}, NULL },
-{ 0, FldAlphanumeric, FldInvalid, 0, 0,0,2, nonarray, 0,
-  "FILLER", 0, {}, {1,1,0,0, " "}, NULL },
-{ 0, FldAlphanumeric, FldInvalid, signable_e | global_e, 0,0,2, nonarray, 
0,
-  "DEBUG-CONTENTS", 0, {}, {76,76,0,0, NULL}, NULL },
-};
 
 class group_size_t {
   size_t size;
@@ -384,26 +315,6 @@ class group_size_t {
 
 enum  { constq = constant_e | quoted_e };
 
-static cbl_field_t special_registers[] = {
-{ 0, FldNumericDisplay, FldInvalid, 0, 0, 0, 0, nonarray, 0, 
"_FILE_STATUS",
-  0, {}, {2,2,2,0, NULL}, NULL },
-{ 0, FldNumericBin5, FldInvalid, 0, 0, 0, 0, nonarray

Re: [PATCH v3, backport] c++: Don't prune constant capture proxies only used in array dimensions [PR114292]

[Jason Merrill]

On 3/19/25 12:40 PM, Simon Martin wrote:

Hi Jason,

On Mon Jan 27, 2025 at 9:10 PM CET, Simon Martin wrote:

Hi Jason,

On 27 Jan 2025, at 20:53, Jason Merrill wrote:


On 1/27/25 2:34 PM, Simon Martin wrote:

Hi Jason,

On 27 Jan 2025, at 15:23, Jason Merrill wrote:


On 1/27/25 8:14 AM, Simon Martin wrote:

Hi Jason,

On 24 Jan 2025, at 16:51, Jason Merrill wrote:


On 1/24/25 6:19 AM, Simon Martin wrote:

Hi Jason,

On 23 Jan 2025, at 22:56, Jason Merrill wrote:


On 1/23/25 12:06 PM, Simon Martin wrote:

Hi Marek,

On 23 Jan 2025, at 16:45, Marek Polacek wrote:


On Thu, Jan 23, 2025 at 02:40:09PM +, Simon Martin wrote:



Hi Jason,

On 20 Jan 2025, at 22:49, Jason Merrill wrote:


On 1/20/25 2:11 PM, Simon Martin wrote:

Hi Jason,

On 15 Jan 2025, at 22:42, Jason Merrill wrote:


On 12/12/24 2:07 PM, Simon Martin wrote:

We currently ICE upon the following valid (under
-Wno-vla)



code




=== cut here ===
void f(int c) {
 constexpr int r = 4;
 [&](auto) { int t[r * c]; }(0);
}
=== cut here ===

The problem is that when parsing the lambda body, and



more
specifically
the multiplication, we mark the lambda as
LAMBDA_EXPR_CAPTURE_OPTIMIZED
even though the replacement of r by 4 is "undone" by the



call



to
build_min_non_dep in build_x_binary_op. This makes
prune_lambda_captures
remove the proxy declaration while it should not, and we



trip



on
an



assert at instantiation time.


Why does prune_lambda_captures remove the declaration if
it's
still
used in the function body?  Setting
LAMBDA_EXPR_CAPTURE_OPTIMIZED
just
means "we might have optimized away some captures", the
tree
walk
should have found the use put back by build_x_binary_op.

I think that this is due to a bug in mark_const_cap_r,
that’s
been
here since the beginning, i.e. r8-7213-g1577f10a637352: it



decides



NOT
to walk sub-trees when encountering a DECL_EXPR for a
constant
capture
proxy (at lambda.cc:1769). I don’t understand why we



wouldn’t
want
to continue.


Because that's the declaration of the capture proxy, not a
use
of
it.

Indeed, thanks for clarifying.


Why aren't we finding the use in the declaration of t?

After further investigation, the problem is rather that
neither
walk_tree_1 nor cp_walk_subtrees walk the dimensions of array
types,
so
we miss the uses.


Removing that line fixes the PR, but breaks 3 existing
tests
(lambda-capture1.C, lambda-const11.C and lambda-const11a.C,
that
all
assert that we optimise out the capture); that’s why I
did
not
pursue
it in the first place.


Right.


But taking another look, it might not be that big a deal
that
we
don’t
optimise those out: as soon as we use -O1 or above, the
assignment
to



the closure field actually disappears.


Completely breaking this optimization is a big deal,
particularly
since it affects the layout of closure objects.  We can't
always



optimize everything away.

ACK.

The attached updated patch makes cp_walk_subtrees walk array



type



dimensions, which fixes the initial PR without those 3
regressions.




Successfully tested on x86_64-pc-linux-gnu. Is it OK?

Simon

PS: In theory I think it’d make sense to do do this change
in

walk_tree_1 since C also supports VLAs, but doing so breaks
some



OMP
tests. OMP can do interesting things with array bounds (see
r9-5354-gda972c05f48637), and fixing those would require
teaching



walk_tree_1 about the “omp dummy var” array bounds, which
I
think
would be a bit ugly. And I’m not aware of any C case that
would
be
improved/fixed by doing this change, so we’re probably fine
not
doing
it.



 From e19bb6c943a422b1201c5c9a2a1d4f32141baf84 Mon Sep 17



00:00:00
2001
From: Simon Martin 
Date: Wed, 22 Jan 2025 16:19:47 +0100
Subject: [PATCH] c++: Don't prune constant capture proxies
only
used
in array
  dimensions [PR114292]

We currently ICE upon the following valid (under -Wno-vla)
code

=== cut here ===
void f(int c) {
   constexpr int r = 4;
   [&](auto) { int t[r * c]; }(0);
}
=== cut here ===

When parsing the lambda body, and more specifically the
multiplication,
we mark the lambda as LAMBDA_EXPR_CAPTURE_OPTIMIZED, which
indicates
to
prune_lambda_captures that it might be possible to optimize
out
some
captures.

The problem is that prune_lambda_captures then misses the use
of



the
r
capture (because neither walk_tree_1 nor cp_walk_subtrees



walks
the



dimensions of array types - here "r * c"), hence believes the
capture
can be pruned... and we trip on an assert when instantiating



the
lambda.

This patch changes cp_walk_subtrees so that when walking a
declaration
with an array type, it walks that array type's dimensions.
Since
C
also
supports VLAs, I thought it'd make sense to do this in
walk_tree_1,



but
this breaks some omp-low related test cases (because OMP can
do
funky
things with array bounds when adjust_array_error_bounds is
set),



and
I
don't really want to add code to walk_tree_1 to skips arrays



whose
dimension is a temporary variable w

Re: [TO-BE-COMMITED,PATCH] s390: Deprecate ESA/390 support

[Stefan Schulze Frielinghaus]

On Wed, Mar 12, 2025 at 12:38:59PM +, Joseph Myers wrote:
> This commit has changed int __attribute__ ((__mode__ (__word__))) on s390 
> -m31 from int to long long.  That introduces a glibc testsuite failure - 
> the glibc testsuite verifies the expected C++ name mangling of various 
> types, including register_t (which is defined with that attribute).
> 
> https://sourceware.org/pipermail/libc-testresults/2025q1/013529.html

Thank you very much for pointing this out.  The intention of -m31 -mesa and
-m31 -mzarch was that they are (ABI) compatible which is almost true except as
it turns out they are not for attribute mode(word).

After doing some archaeology and digging out an over 18 year old thread [1,2]
which is about this very attribute, I come to the conclusion to revert this
patch.  The intention by deprecating and eventually removing ESA/390 support
was to prepare for a future removal of -m31; though in smaller steps.  Thus,
instead of introducing some potential hick ups along the route, I will revert
this patch and will revisit this topic when time for -m31 in its entirety has
come---independent of -mesa/-mzarch.

Cheers,
Stefan

[1] https://gcc.gnu.org/pipermail/gcc-patches/2006-September/200465.html
[2] https://gcc.gnu.org/pipermail/gcc-patches/2006-October/201154.html

[PATCH] libstdc++: Add from_range_t constructors to debug ordered containers

[Tomasz Kamiński]

libstdc++-v3/ChangeLog:

* include/debug/unordered_map (unordered_map): Add from_range
constructors and deduction guides.
(unordered_multimap): Likewise.
* include/debug/unordered_set (unordered_set): Add from_range
constructors and deduction guides.
(unordered_multiset): Likewise.
---
As noticed by Jonathan, new ctors and deduction guides where not 
added to debug versions

Testing on x86_64-linux, unordered_* test passed with -D_GLIBCXX_DEBUG.
OK for trunk?

 libstdc++-v3/include/debug/unordered_map | 141 +++
 libstdc++-v3/include/debug/unordered_set | 131 +
 2 files changed, 272 insertions(+)

diff --git a/libstdc++-v3/include/debug/unordered_map 
b/libstdc++-v3/include/debug/unordered_map
index eb9590ac8e7..16d4a4a98e0 100644
--- a/libstdc++-v3/include/debug/unordered_map
+++ b/libstdc++-v3/include/debug/unordered_map
@@ -201,6 +201,34 @@ namespace __debug
   : unordered_map(__l, __n, __hf, key_equal(), __a)
   { }
 
+#if __glibcxx_ranges_to_container // C++ >= 23
+  template<__detail::__container_compatible_range _Rg>
+   unordered_map(from_range_t, _Rg&& __rg,
+ size_type __n = 0,
+ const hasher& __hf = hasher(),
+ const key_equal& __eql = key_equal(),
+ const allocator_type& __a = allocator_type())
+   : _Base(from_range, std::forward<_Rg>(__rg), __n, __hf, __eql, __a)
+{ }
+
+  template<__detail::__container_compatible_range _Rg>
+   unordered_map(from_range_t, _Rg&& __rg, const allocator_type& __a)
+   : _Base(from_range, std::forward<_Rg>(__rg), __a)
+{ }
+
+  template<__detail::__container_compatible_range _Rg>
+   unordered_map(from_range_t, _Rg&& __rg, size_type __n,
+ const allocator_type& __a)
+   : _Base(from_range, std::forward<_Rg>(__rg), __n, __a)
+{ }
+
+  template<__detail::__container_compatible_range _Rg>
+   unordered_map(from_range_t, _Rg&& __rg, size_type __n,
+ const hasher& __hf, const allocator_type& __a)
+   : _Base(from_range, std::forward<_Rg>(__rg), __n, __hf, __a)
+{ }
+#endif
+
   ~unordered_map() = default;
 
   unordered_map&
@@ -841,6 +869,47 @@ namespace __debug
  _Hash, _Allocator)
 -> unordered_map<_Key, _Tp, _Hash, equal_to<_Key>, _Allocator>;
 
+#if __glibcxx_ranges_to_container // C++ >= 23
+  template>,
+  __not_allocator_like _Pred = 
equal_to<__detail::__range_key_type<_Rg>>,
+  __allocator_like _Allocator =
+allocator<__detail::__range_to_alloc_type<_Rg>>>
+unordered_map(from_range_t, _Rg&&, unordered_map::size_type = {},
+ _Hash = _Hash(), _Pred = _Pred(), _Allocator = _Allocator())
+-> unordered_map<__detail::__range_key_type<_Rg>,
+__detail::__range_mapped_type<_Rg>,
+_Hash, _Pred, _Allocator>;
+
+  template
+unordered_map(from_range_t, _Rg&&, unordered_map::size_type,
+ _Allocator)
+-> unordered_map<__detail::__range_key_type<_Rg>,
+__detail::__range_mapped_type<_Rg>,
+hash<__detail::__range_key_type<_Rg>>,
+equal_to<__detail::__range_key_type<_Rg>>,
+_Allocator>;
+
+  template
+unordered_map(from_range_t, _Rg&&, _Allocator)
+-> unordered_map<__detail::__range_key_type<_Rg>,
+__detail::__range_mapped_type<_Rg>,
+hash<__detail::__range_key_type<_Rg>>,
+equal_to<__detail::__range_key_type<_Rg>>,
+_Allocator>;
+
+  template
+unordered_map(from_range_t, _Rg&&, unordered_map::size_type,
+ _Hash, _Allocator)
+-> unordered_map<__detail::__range_key_type<_Rg>,
+__detail::__range_mapped_type<_Rg>,
+_Hash, equal_to<__detail::__range_key_type<_Rg>>,
+_Allocator>;
+#endif
 #endif
 
   template= 23
+  template<__detail::__container_compatible_range _Rg>
+   unordered_multimap(from_range_t, _Rg&& __rg,
+  size_type __n = 0,
+  const hasher& __hf = hasher(),
+  const key_equal& __eql = key_equal(),
+  const allocator_type& __a = allocator_type())
+   : _Base(from_range, std::forward<_Rg>(__rg), __n, __hf, __eql, __a)
+{ }
+
+  template<__detail::__container_compatible_range _Rg>
+   unordered_multimap(from_range_t, _Rg&& __rg, const allocator_type& __a)
+   : _Base(from_range, std::forward<_Rg>(__rg), __a)
+{ }
+
+  template<__detail::__container_compatible_range _Rg>
+   unordered_multimap(from_range_t, _Rg&& __rg, size_type __n,
+  const allocator_type& __a)
+   : _Base(from_range, std::forward<_Rg>(__rg), __n, __a)
+   

[PATCH 0/1] Cherry pick of patch for gcc-13 fixing PR119372

[Alfie Richards]

Hello,

This is a cherry pick of 20385cb92cbd4a1934661ab97a162c1e25935836 which didn't 
apply cleanly
so needed a very minor edit to for it to apply for GCC 12 and 13.

Regtested and bootstrapped for gcc-13 on aarch64-linux-gnu.

This applies cleanly to gcc-12 but there is a regression for
`c-c++-common/hwasan/large-aligned-1.c`. 

The output of execution was

```
==2242916==ERROR: HWAddressSanitizer: tag-mismatch on address 0xf680 at 
pc 0xf780e08c
READ of size 4 at 0xf680 tags: 02/01(00) (ptr/mem) in thread T0
#0 0xf780e08c in SigTrap<2> 
../../../../src/libsanitizer/hwasan/hwasan_checks.h:28
```

and has changed to

```
==2242927==ERROR: HWAddressSanitizer: tag-mismatch on address 0xf690 at 
pc 0xf780e08c
READ of size 4 at 0xf690 tags: 02/00 (ptr/mem) in thread T0
#0 0xf780e08c in SigTrap<2> 
../../../../src/libsanitizer/hwasan/hwasan_checks.h:28
```

Note the difference in the tags.

Does anyone with experience of HWAddressSanitizer know what caused this and if 
it's an issue?

Kind regards,
Alfie Richards


Andrew Carlotti (1):
  aarch64: Use PAUTH instead of V8_3A in some places

 gcc/config/aarch64/aarch64.cc | 6 +++---
 gcc/config/aarch64/aarch64.md | 8 
 2 files changed, 7 insertions(+), 7 deletions(-)

-- 
2.34.1

[PATCH 00/10] testsuite: aarch64: arm: Fixes in effective-targets

[Christophe Lyon]

While looking at enabling vld1x?.c and vst1x?.c tests on arm, I
noticed several inconsistencies in testcases under advsimd-intrinsics
and related effective-targets.

1- The dg-do-what action is computed by advsimd-intrinsics.exp
   depending on the actual target, so there normally should be no
   'dg-do' directive except if we want to make sure we never try to
   run or compile a given testcase.

2- Similarly, advsimd-intrinsics.exp makes use of the torture
   framework, so we should not use dg-options.

3- When an effective target tries to detect which flags to use to
   enable an architectural feature, the current first option "" does
   not work when the testsuite is executed with overridden flags
   (e.g. forcing an M-profile target).  It has to use -mfpu=auto to
   achieve the intended effect.

4- Such effective targets also use -mcpu=unset which is not supported
   on aarch64, resulting in many testcases being UNSUPPORTED when they
   used to PASS.

Patch 1 is obvious, it fixes a probable typo.
Patches 2-5 address points 1 and 2 above.
Patches 6 and 8-10 address points 3 and 4.
Patch 7 actually enables vld1x?.c and vst1x.c tests on arm.

The series globally extends testing coverage, especially on aarch64
where many tests had inadvertently become unsupported.

Christophe Lyon (10):
  testsuite: arm: remove duplicate -mcpu=unset in arm_v8_1_lob_ok
  testsuite: aarch64: arm: move saturating_arithmetic_autovect tests to
simd/
  testsuite: aarch64: restore torture options in bf16_dup.c
  testsuite: aarch64: restore torture options in
vml[as]_float_not_used.c
  testsuite: aarch64: arm: Remove redundant dg-do run in
advsimd-intrinsics tests
  testsuite: aarch64: arm: Add -mfpu=auto to arm_v8_2a_bf16_neon_ok
  testsuite: aarch64: arm: Enable vld1x?.c and vst1x?.c on arm [PR71233]
  testsuite: aarch64: arm: Fix -mcpu=unset support in some effective
targets
  testsuite: aarch64: arm: Fix -mfpu=auto support in fp16_neon_ok
  testsuite: aarch64: arm: Fix -mcpu=unset -mfpu=auto support in more
effective targets

 .../aarch64/advsimd-intrinsics/bf16_dup.c |   2 +-
 .../aarch64/advsimd-intrinsics/vabdh_f16_1.c  |   1 -
 .../aarch64/advsimd-intrinsics/vabsh_f16_1.c  |   1 -
 .../aarch64/advsimd-intrinsics/vaddh_f16_1.c  |   1 -
 .../aarch64/advsimd-intrinsics/vcageh_f16_1.c |   1 -
 .../aarch64/advsimd-intrinsics/vcagth_f16_1.c |   1 -
 .../aarch64/advsimd-intrinsics/vcaleh_f16_1.c |   1 -
 .../aarch64/advsimd-intrinsics/vcalth_f16_1.c |   1 -
 .../aarch64/advsimd-intrinsics/vceqh_f16_1.c  |   1 -
 .../aarch64/advsimd-intrinsics/vceqzh_f16_1.c |   1 -
 .../aarch64/advsimd-intrinsics/vcgeh_f16_1.c  |   1 -
 .../aarch64/advsimd-intrinsics/vcgezh_f16_1.c |   1 -
 .../aarch64/advsimd-intrinsics/vcgth_f16_1.c  |   1 -
 .../aarch64/advsimd-intrinsics/vcgtzh_f16_1.c |   1 -
 .../aarch64/advsimd-intrinsics/vcleh_f16_1.c  |   1 -
 .../aarch64/advsimd-intrinsics/vclezh_f16_1.c |   1 -
 .../aarch64/advsimd-intrinsics/vclth_f16_1.c  |   1 -
 .../aarch64/advsimd-intrinsics/vcltzh_f16_1.c |   1 -
 .../advsimd-intrinsics/vcvtah_s16_f16_1.c |   1 -
 .../advsimd-intrinsics/vcvtah_s32_f16_1.c |   1 -
 .../advsimd-intrinsics/vcvtah_s64_f16_1.c |   1 -
 .../advsimd-intrinsics/vcvtah_u16_f16_1.c |   1 -
 .../advsimd-intrinsics/vcvtah_u32_f16_1.c |   1 -
 .../advsimd-intrinsics/vcvtah_u64_f16_1.c |   1 -
 .../advsimd-intrinsics/vcvth_f16_s16_1.c  |   1 -
 .../advsimd-intrinsics/vcvth_f16_s32_1.c  |   1 -
 .../advsimd-intrinsics/vcvth_f16_s64_1.c  |   1 -
 .../advsimd-intrinsics/vcvth_f16_u16_1.c  |   1 -
 .../advsimd-intrinsics/vcvth_f16_u32_1.c  |   1 -
 .../advsimd-intrinsics/vcvth_f16_u64_1.c  |   1 -
 .../advsimd-intrinsics/vcvth_n_f16_s16_1.c|   1 -
 .../advsimd-intrinsics/vcvth_n_f16_s32_1.c|   1 -
 .../advsimd-intrinsics/vcvth_n_f16_s64_1.c|   1 -
 .../advsimd-intrinsics/vcvth_n_f16_u16_1.c|   1 -
 .../advsimd-intrinsics/vcvth_n_f16_u32_1.c|   1 -
 .../advsimd-intrinsics/vcvth_n_f16_u64_1.c|   1 -
 .../advsimd-intrinsics/vcvth_n_s16_f16_1.c|   1 -
 .../advsimd-intrinsics/vcvth_n_s32_f16_1.c|   1 -
 .../advsimd-intrinsics/vcvth_n_s64_f16_1.c|   1 -
 .../advsimd-intrinsics/vcvth_n_u16_f16_1.c|   1 -
 .../advsimd-intrinsics/vcvth_n_u32_f16_1.c|   1 -
 .../advsimd-intrinsics/vcvth_n_u64_f16_1.c|   1 -
 .../advsimd-intrinsics/vcvth_s16_f16_1.c  |   1 -
 .../advsimd-intrinsics/vcvth_s32_f16_1.c  |   1 -
 .../advsimd-intrinsics/vcvth_s64_f16_1.c  |   1 -
 .../advsimd-intrinsics/vcvth_u16_f16_1.c  |   1 -
 .../advsimd-intrinsics/vcvth_u32_f16_1.c  |   1 -
 .../advsimd-intrinsics/vcvth_u64_f16_1.c  |   1 -
 .../advsimd-intrinsics/vcvtmh_s16_f16_1.c |   1 -
 .../advsimd-intrinsics/vcvtmh_s32_f16_1.c |   1 -
 .../advsimd-intrinsics/vcvtmh_s64_f16_1.c |   1 -
 .../advsimd-intrinsics/vcvtmh_u16_f16_1.c |   1 -
 .../advsimd-intrinsics/vcvtmh_u32_f16_1.c |   1 -
 .../advsimd-intrinsic

Re: C++/v3 PATCH to add/throw std::bad_array_new_length

[Jason Merrill]

On 3/19/25 1:35 PM, Thomas Schwinge wrote:

Hi Jason!

On 2013-05-03T16:24:43-0400, Jason Merrill  wrote:

Last year Florian fixed the compiler to detect overflow in array new
size calculations and pass (size_t)-1 in that case.  But C++11 specifies
that in case of overflow the program throws std::bad_array_new_length
(http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#624), so
I've adjusted the checking code accordingly.

This patch also adds the type to libsupc++, and several exports to
libstdc++.

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


Subversion r198731 (Git commit 7d5e76c8de1b6c4b2ae5576ab909dc9e580b216b).


Core 624/N2932: Throw bad_array_new_length on overflow
in array new size calculation.
 
 libstdc++-v3/

* libsupc++/new: Add std::bad_array_new_length.
* libsupc++/bad_array_new.cc: New.
* libsupc++/eh_aux_runtime.cc: Add __cxa_bad_array_new_length.
* libsupc++/Makefile.in: Build them.
* config/abi/pre/gnu.ver: Add new symbols.
* config/abi/pre/gnu-versioned-namespace.ver: Add new symbols.
 gcc/cp/
* init.c (throw_bad_array_new_length): New.
(build_new_1): Use it.  Don't warn about braced-init-list.
(build_vec_init): Use it.
* call.c (build_operator_new_call): Use it.


Here:


--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c



+/* Call __cxa_bad_array_new_length to indicate that the size calculation
+   overflowed.  Pretend it returns sizetype so that it plays nicely in the
+   COND_EXPR.  */
+
+tree
+throw_bad_array_new_length (void)
+{
+  tree fn = get_identifier ("__cxa_bad_array_new_length");
+  if (!get_global_value_if_present (fn, &fn))
+fn = push_throw_library_fn (fn, build_function_type_list (sizetype,
+ NULL_TREE));
+
+  return build_cxx_call (fn, 0, NULL, tf_warning_or_error);
+}


"Pretend it returns sizetype", doesn't work with nvptx, which complains
that the front end-synthesized prototype with the fake 'sizetype' return
type:

 .extern .func (.param .u64 %value_out) __cxa_throw_bad_array_new_length;

... doesn't match the library code with 'void' return type:


--- a/libstdc++-v3/libsupc++/cxxabi.h
+++ b/libstdc++-v3/libsupc++/cxxabi.h



+  void
+  __cxa_bad_array_new_length() __attribute__((__noreturn__));



--- a/libstdc++-v3/libsupc++/eh_aux_runtime.cc
+++ b/libstdc++-v3/libsupc++/eh_aux_runtime.cc



+extern "C" void
+__cxxabiv1::__cxa_bad_array_new_length ()
+{ _GLIBCXX_THROW_OR_ABORT(std::bad_array_new_length()); }


 .visible .func __cxa_throw_bad_array_new_length
 {
 [...]
 }

..., and thus results in execution test FAILs:

 error   : Prototype doesn't match for '__cxa_throw_bad_array_new_length' 
in 'input file 5 at offset 14095', first defined in 'input file 5 at offset 
14095'
 nvptx-run: cuLinkAddData failed: device kernel image is invalid 
(CUDA_ERROR_INVALID_SOURCE, 300)

How can we improve on "Pretend it returns sizetype"?  Is there a standard
way to "bend" the types in the front end?


Seems like we can just fix the return type, I don't see any regressions 
from this:


From cfc6e295ea19cb570c06d3281f41fd5ae0ba076b Mon Sep 17 00:00:00 2001
From: Jason Merrill 
Date: Thu, 20 Mar 2025 09:55:40 -0400
Subject: [PATCH] c++: fix return typye of __cxa_bad_array_new_length
To: gcc-patches@gcc.gnu.org

We were lying about the return type, but that's not necessary; we already
need to handle a COND_EXPR where one side is void for THROW_EXPR.

gcc/cp/ChangeLog:

	* init.cc (throw_bad_array_new_length): Returns void.
---
 gcc/cp/init.cc | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/gcc/cp/init.cc b/gcc/cp/init.cc
index ce6e58e05f2..e589e45e891 100644
--- a/gcc/cp/init.cc
+++ b/gcc/cp/init.cc
@@ -2810,8 +2810,7 @@ diagnose_uninitialized_cst_or_ref_member (tree type, bool using_new, bool compla
 }
 
 /* Call __cxa_bad_array_new_length to indicate that the size calculation
-   overflowed.  Pretend it returns sizetype so that it plays nicely in the
-   COND_EXPR.  */
+   overflowed.  */
 
 tree
 throw_bad_array_new_length (void)
@@ -2823,7 +2822,7 @@ throw_bad_array_new_length (void)
   fn = get_global_binding (name);
   if (!fn)
 	fn = push_throw_library_fn
-	  (name, build_function_type_list (sizetype, NULL_TREE));
+	  (name, build_function_type_list (void_type_node, NULL_TREE));
 }
 
   return build_cxx_call (fn, 0, NULL, tf_warning_or_error);
-- 
2.48.1

[PATCH v2 1/3] libstdc++: Use formatting locale for std::time_put formats

[Jonathan Wakely]

When using std::time_put to format a chrono value, we should imbue the
formatting locale into the stream. This ensures that when
std::time_put::do_put uses a ctype or __timepunct facet from the locale,
it gets the correct facets.

libstdc++-v3/ChangeLog:

* include/bits/chrono_io.h (__formatter_chrono::_M_locale_fmt):
Imbue locale into ostringstream.
* testsuite/std/time/format/localized.cc: Check that correct
locale is used for call to time_put::put.
---

Now with a test that shows the bug independent of the PR117214 patches
to use std::time_put for %c formats.

Tested x86_64-linux.

 libstdc++-v3/include/bits/chrono_io.h |  1 +
 .../testsuite/std/time/format/localized.cc| 30 +++
 2 files changed, 31 insertions(+)

diff --git a/libstdc++-v3/include/bits/chrono_io.h 
b/libstdc++-v3/include/bits/chrono_io.h
index c16b555df29..55ebd4ee061 100644
--- a/libstdc++-v3/include/bits/chrono_io.h
+++ b/libstdc++-v3/include/bits/chrono_io.h
@@ -1697,6 +1697,7 @@ namespace __format
  char __fmt, char __mod) const
{
  basic_ostringstream<_CharT> __os;
+ __os.imbue(__loc);
  const auto& __tp = use_facet>(__loc);
  __tp.put(__os, __os, _S_space, &__tm, __fmt, __mod);
  if (__os)
diff --git a/libstdc++-v3/testsuite/std/time/format/localized.cc 
b/libstdc++-v3/testsuite/std/time/format/localized.cc
index 393d0d200e4..437a4a011b2 100644
--- a/libstdc++-v3/testsuite/std/time/format/localized.cc
+++ b/libstdc++-v3/testsuite/std/time/format/localized.cc
@@ -13,6 +13,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -81,6 +82,35 @@ test_en()
 }
 }
 
+void
+test_locale_imbued()
+{
+  // Custom time_put facet which returns %b string for %Om
+  struct TimePut : std::time_put
+  {
+iter_type
+do_put(iter_type out, std::ios_base& io, char_type fill, const tm* t,
+  char format, char modifier) const override
+{
+  if (format == 'm' && modifier == 'O')
+   format = 'b';
+  return std::time_put::do_put(out, io, fill, t, format, 0);
+}
+  };
+
+  auto m = std::chrono::March;
+
+  std::locale fr(ISO_8859(1,fr_FR));
+  std::locale fr2(fr, new TimePut);
+  auto s1 = std::format(fr2, "{:L%Om}", m);
+  VERIFY( s1 == std::format(fr, "{:L}", m) );
+
+  std::locale es(ISO_8859(1,es_ES));
+  std::locale es2(es, new TimePut);
+  auto s2 = std::format(es2, "{:L%Om}", m);
+  VERIFY( s2 == std::format(es, "{:L}", m) );
+}
+
 int main()
 {
   test_ru();
-- 
2.49.0

[PATCH 01/10] testsuite: arm: remove duplicate -mcpu=unset in arm_v8_1_lob_ok

[Christophe Lyon]

This was probably a typo / oversight.

gcc/testsuite/
* lib/target-supports.exp
(check_effective_target_arm_v8_1_lob_ok): Remove duplicate
-mcpu=unset.
---
 gcc/testsuite/lib/target-supports.exp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index c456f7d2c6f..e2622a445c5 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -13512,7 +13512,7 @@ proc check_effective_target_arm_v8_1_lob_ok { } {
  asm goto ("le lr, %l0" : : : "lr" : loop);
  return i != 10;
}
-   } "-mcpu=unset -mcpu=unset -march=armv8.1-m.main -mthumb" ]
+   } "-mcpu=unset -march=armv8.1-m.main -mthumb" ]
 }
 }
 
-- 
2.34.1

[PATCH 05/10] testsuite: aarch64: arm: Remove redundant dg-do run in advsimd-intrinsics tests

[Christophe Lyon]

Tests under advsimd-intrinsics are controlled by
advsimd-intrinsics.exp which computes the adequate dg-do-what
depending on the actual target, it should not be redefined in the
tests, except when the action can never be 'run'.

This currently makes no difference, but it would when we remove
dg-skip-if for arm targets from tests that could at least be compiled
(e.g. vst1x2.c)

gcc/testsuite/

* gcc.target/aarch64/advsimd-intrinsics/vabdh_f16_1.c: Remove
dg-do directive.
* gcc.target/aarch64/advsimd-intrinsics/vabsh_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vaddh_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcageh_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcagth_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcaleh_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcalth_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vceqh_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vceqzh_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcgeh_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcgezh_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcgth_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcgtzh_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcleh_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vclezh_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vclth_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcltzh_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvtah_s16_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvtah_s32_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvtah_s64_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvtah_u16_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvtah_u32_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvtah_u64_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvth_f16_s16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvth_f16_s32_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvth_f16_s64_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvth_f16_u16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvth_f16_u32_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvth_f16_u64_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvth_n_f16_s16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvth_n_f16_s32_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvth_n_f16_s64_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvth_n_f16_u16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvth_n_f16_u32_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvth_n_f16_u64_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvth_n_s16_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvth_n_s32_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvth_n_s64_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvth_n_u16_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvth_n_u32_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvth_n_u64_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvth_s16_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvth_s32_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvth_s64_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvth_u16_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvth_u32_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvth_u64_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvtmh_s16_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvtmh_s32_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvtmh_s64_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvtmh_u16_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvtmh_u32_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvtmh_u64_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvtnh_s16_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvtnh_s32_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvtnh_s64_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvtnh_u16_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvtnh_u32_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcvtnh_u64_f16_1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/

Re: [PATCH v2 2/2] PR119376: Disable clang musttail

[Andi Kleen]

On Thu, Mar 20, 2025 at 11:45:33AM -0400, Jason Merrill wrote:
> On 3/19/25 9:31 PM, Andi Kleen wrote:
> > From: Andi Kleen 
> > 
> > There are multiple reports (see PR 119376) now where semantic differences
> > in the gcc musttail implementation break existing programs written for the 
> > clang
> > variant.
> > 
> > Even though that can be all hopefully fixed eventually,
> > for the gcc 15 release it seems safer to disable clang::musttail,
> > and only keep gnu::musttail.
> 
> This seems like a last resort to take if we aren't able to fix the issues by
> the time we're ready to release.  Looks like Jakub has a patch to fix
> 119376.


Yes it's last resort.

The inlining was just one of the issue, there are some related to
different semantics of escaped locals. gcc always errors out while
LLVM declares it undefined.

But maybe we can fix that one too.


-Andi

[PATCH 02/10] testsuite: aarch64: arm: move saturating_arithmetic_autovect tests to simd/

[Christophe Lyon]

These tests force dg-options because they rely on -ftree-vectorize and
do not make use of torture options, so move them to simd/ where they
belong.

gcc/testsuite/
* 
gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect.inc:
Move to gcc.target/aarch64/simd/.
* 
gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect_1.c: 
Likewise.
* 
gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect_2.c: 
Likewise.
* 
gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect_3.c: 
Likewise.
* 
gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect_4.c: 
Likewise.
---
 .../saturating_arithmetic_autovect.inc| 0
 .../saturating_arithmetic_autovect_1.c| 0
 .../saturating_arithmetic_autovect_2.c| 0
 .../saturating_arithmetic_autovect_3.c| 0
 .../saturating_arithmetic_autovect_4.c| 0
 5 files changed, 0 insertions(+), 0 deletions(-)
 rename gcc/testsuite/gcc.target/aarch64/{advsimd-intrinsics => 
simd}/saturating_arithmetic_autovect.inc (100%)
 rename gcc/testsuite/gcc.target/aarch64/{advsimd-intrinsics => 
simd}/saturating_arithmetic_autovect_1.c (100%)
 rename gcc/testsuite/gcc.target/aarch64/{advsimd-intrinsics => 
simd}/saturating_arithmetic_autovect_2.c (100%)
 rename gcc/testsuite/gcc.target/aarch64/{advsimd-intrinsics => 
simd}/saturating_arithmetic_autovect_3.c (100%)
 rename gcc/testsuite/gcc.target/aarch64/{advsimd-intrinsics => 
simd}/saturating_arithmetic_autovect_4.c (100%)

diff --git 
a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect.inc
 b/gcc/testsuite/gcc.target/aarch64/simd/saturating_arithmetic_autovect.inc
similarity index 100%
rename from 
gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect.inc
rename to 
gcc/testsuite/gcc.target/aarch64/simd/saturating_arithmetic_autovect.inc
diff --git 
a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect_1.c
 b/gcc/testsuite/gcc.target/aarch64/simd/saturating_arithmetic_autovect_1.c
similarity index 100%
rename from 
gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect_1.c
rename to 
gcc/testsuite/gcc.target/aarch64/simd/saturating_arithmetic_autovect_1.c
diff --git 
a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect_2.c
 b/gcc/testsuite/gcc.target/aarch64/simd/saturating_arithmetic_autovect_2.c
similarity index 100%
rename from 
gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect_2.c
rename to 
gcc/testsuite/gcc.target/aarch64/simd/saturating_arithmetic_autovect_2.c
diff --git 
a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect_3.c
 b/gcc/testsuite/gcc.target/aarch64/simd/saturating_arithmetic_autovect_3.c
similarity index 100%
rename from 
gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect_3.c
rename to 
gcc/testsuite/gcc.target/aarch64/simd/saturating_arithmetic_autovect_3.c
diff --git 
a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect_4.c
 b/gcc/testsuite/gcc.target/aarch64/simd/saturating_arithmetic_autovect_4.c
similarity index 100%
rename from 
gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect_4.c
rename to 
gcc/testsuite/gcc.target/aarch64/simd/saturating_arithmetic_autovect_4.c
-- 
2.34.1

Re: [PATCH v2 2/2] PR119376: Disable clang musttail

[Andi Kleen]

On Thu, Mar 20, 2025 at 05:28:48PM +0100, Jakub Jelinek wrote:
> On Thu, Mar 20, 2025 at 09:19:02AM -0700, Andi Kleen wrote:
> > The inlining was just one of the issue, there are some related to
> > different semantics of escaped locals. gcc always errors out while
> > LLVM declares it undefined.
> > 
> > But maybe we can fix that one too.
> 
> I have 3 patches to be tested, the inline one, fnsplit one and ipa-icf one.
> For the escaped locals, I guess we need to decide if [[clang::musttail]]
> will be something different from [[gnu::musttail]] in GCC or not (and if
> yes, what __attribute__((musttail)) will be).

There were more differences. clang is better to handle various
cases with structs at -O0 and then there are some target specific differences
too (e.g. some of our targets always reject externs)

But maybe it's good enough.

I don't think multiple flavors of musttail are a good idea because 
it will be confusing to users. I guess we should just match what clang does
even for gnu::musttail. Since they were the pioneer they get to chose
the semantics.


> The current difference in behavior is on
> int foo (void);
> void bar (int *);
> int
> baz (void)
> {
>   int a;
>   bar (&a);
>   [[clang::musttail]] return foo ();
> }
> Clang makes the attribute not just a request to tail call it or fail,
> but also changes behavior and says if the code ever accesses a from the
> above during foo () (which without the attribute is completely valid), then
> it is UB.


So it could be as simple as that patch?  It solves your test case at least
for x86.

diff --git a/gcc/tree-tailcall.cc b/gcc/tree-tailcall.cc
index f97df31eb3cf..b87a92e95e3d 100644
--- a/gcc/tree-tailcall.cc
+++ b/gcc/tree-tailcall.cc
@@ -722,8 +722,9 @@ find_tail_calls (basic_block bb, struct tailcall **ret, 
bool only_musttail,
{
  if (local_live_vars)
BITMAP_FREE (local_live_vars);
- maybe_error_musttail (call,
-   _("call invocation refers to locals"));
+ /* Allow this for musttail to match clang semantics of musttail.  
*/
+ if (gimple_call_must_tail_p (call))
+   continue;
  return;
}
  else
@@ -732,8 +733,9 @@ find_tail_calls (basic_block bb, struct tailcall **ret, 
bool only_musttail,
  if (bitmap_bit_p (local_live_vars, *v))
{
  BITMAP_FREE (local_live_vars);
- maybe_error_musttail (call,
-   _("call invocation refers to locals"));
+ /* Allow this for musttail to match clang semantics of 
musttail.  */
+ if (gimple_call_must_tail_p (call))
+   continue;
  return;
}
}

[PATCH][RFC] [cobol] change cbl_field_data_t::etc_t::value from _Float128 to tree

[Richard Biener]

The following removes the main instance of _Float128 use in the cobol
frontend and replaces it with a tree for cbl_field_data_t::etc_t::value
and with REAL_VALUE_TYPE in some helpers.

The default value is changed to a float128_type_node zero from 0.0.

get_power_of_ten was picked from Jakubs PR119242 patch, it doesn't build on
its own so I've included it here.

Together with the other two pending changes (the one already approved
and '[cobol] move global data to symbol_table_init'), this compiles
and passes the majority of cobol tests.  As expected there is some
fallout which is at the moment

FAIL: cobol.dg/group1/display2.cob   -O0  output pattern test

(fails at all optimization levels), probably related to the
_Float128 <-> string conversions.  The failure is

Output was:
1.e+0 
2.e+0

Should match:
1 2

I don't know which of the many _Float128 <-> string conversions is
guilty here.

PR cobol/119241
PR cobol/119242
* genutil.h (get_power_of_ten): Return FIXED_WIDE_INT(128).
* genutil.cc (get_power_of_ten): Produce FIXED_WIDE_INT(128)
instead of __int128.
(scale_by_power_of_ten_N): Adjust.
(copy_little_endian_into_place): Likewise.
* genapi.cc (mh_source_is_literalN): Likewise.
* symbols.h (cbl_field_data_t::etc_t::value): Make a tree.
(cbl_field_data_t::etc_t::etc_t): Adjust.
(cbl_field_data_t::cbl_field_data_t): Likewise.
(cbl_field_data_t::value_of): Likewise.
(cbl_field_data_t::operator=): Likewise.
(cbl_field_data_t::valify): Likewise.
* symbols.cc (cbl_occurs_t::subscript_ok): Likewise.
* genapi.h (initial_from_float128): Remove.
* genapi.cc (initial_from_float128): Make local and adjust.
(initialize_variable_internal): Adjust.
(get_binary_value_from_float): Likewise.
(psa_FldLiteralN): Simplify.
(parser_display_internal): Adjust.
(mh_source_is_literalN): Likewise.
(real_powi10): New helper.
(binary_initial_from_float128): Adjust.
(digits_from_float128): Likewise.
(parser_symbol_add): Likewise.
* parse.y (YYVAL): Use REAL_VALUE_TYPE instead of _Float128.
(string_of): Adjust and add overload from tree.
(field): Adjust.
(const_value): Likewise.
(value78): Likewise.
(data_descr1): Likewise.
(value_clause): Likewise.
(allocate): Likewise.
(move_tgt): Likewise.
(cc_expr): Likewise.
(cce_factor): Likewise.
(literal_refmod_valid): Likewise.

Co-authored-by: Jakub Jelinek 
---
 gcc/cobol/genapi.cc  | 196 +--
 gcc/cobol/genapi.h   |   3 -
 gcc/cobol/genutil.cc |  26 +++---
 gcc/cobol/genutil.h  |   2 +-
 gcc/cobol/parse.y| 118 +++---
 gcc/cobol/symbols.cc |  15 ++--
 gcc/cobol/symbols.h  |  21 +++--
 7 files changed, 201 insertions(+), 180 deletions(-)

diff --git a/gcc/cobol/genapi.cc b/gcc/cobol/genapi.cc
index 8f4f9b21370..86ff3da2965 100644
--- a/gcc/cobol/genapi.cc
+++ b/gcc/cobol/genapi.cc
@@ -52,6 +52,7 @@
 #include "../../libgcobol/charmaps.h"
 #include "../../libgcobol/valconv.h"
 #include "show_parse.h"
+#include "fold-const.h"
 
 extern int yylineno;
 
@@ -1041,7 +1042,9 @@ initialize_variable_internal( cbl_refer_t refer,
   default:
 {
 char ach[128];
-strfromf128(ach, sizeof(ach), "%.16E", 
parsed_var->data.value_of());
+   real_to_decimal (ach,
+TREE_REAL_CST_PTR (parsed_var->data.value_of()),
+sizeof(ach), 16, 0);
 SHOW_PARSE_TEXT(ach);
 break;
 }
@@ -1296,8 +1299,8 @@ get_binary_value_from_float(tree value,
   gg_assign(fvalue,
 gg_multiply(fvalue,
 gg_float(ftype,
- build_int_cst_type(INT,
-
get_power_of_ten(rdigits);
+ wide_int_to_tree(INT,
+  
get_power_of_ten(rdigits);
 
   // And we need to throw away any digits to the left of the leftmost digits:
   // At least, we need to do so in principl.  I am deferring this problem until
@@ -4025,11 +4028,7 @@ psa_FldLiteralN(struct cbl_field_t *field )
 field->literal_decl_node = gg_define_variable(DOUBLE, id_string, 
vs_static);
 TREE_READONLY(field->literal_decl_node) = 1;
 TREE_CONSTANT(field->literal_decl_node) = 1;
-char ach[128];
-strfromf128(ach, sizeof(ach), "%.36E", field->data.value_of());
-REAL_VALUE_TYPE real;
-real_from_string(&real, ach);
-tree initer = build_real (DOUBLE, real);
+tree initer = fold_convert (DOUBLE, field->data.value_of());
 DECL_INITIAL(field->literal_decl_node) = initer;
 
 }
@@ -4884,7 +4883

Re: [PATCH] nvptx: In offloading compilation, special-case certain host-setup symbol aliases [PR101544]

[Thomas Schwinge]

Hi Jason!

On 2025-03-20T11:59:07-0400, Jason Merrill  wrote:
> On 3/20/25 11:35 AM, Thomas Schwinge wrote:
>> Appears that I'm too dumb to implement
>> :
>> 
>> | We "simply" need to transform any symbol aliases into thunks calling the 
>> aliasee (or duplicate the bodies, if we must).
>> 
>> ..., and implementing proper support for symbol aliases via the nvptx
>> 'ld':  "[nvptx] Need better alias support",
>> won't be complete any time soon, but fortunately there's a way to handle
>> the cases that we're concerned about here in an even simpler way, for
>> reasonably modern configurations; any comments before I push the attached
>> "nvptx: In offloading compilation, special-case certain host-setup symbol 
>> aliases [PR101544]"?
>> In particular, is the use of a new 'c++ cdtor alias' attribute OK?
>
> Hmm, seems weird to use aliases in that one case but not others.

Yeah...  The problem is the mismatch between host and offload target:
the host of course typically is 'TARGET_SUPPORTS_ALIASES', but nvptx
offloading typically is '!TARGET_SUPPORTS_ALIASES', because:

> If 
> you're going to use aliases, why not just turn on alias support?

We can't unconditionally enable GCC/nvptx' '-malias', because the support
is incomplete, and if enabled, will cause GCC target library build
failures, for example.

> If aliases aren't supported, I think you want to fix can_alias_cdtor to 
> return false.

We can't: we don't want to pessimize host code generation.  Therefore, we
have to handle this in the nvptx offloading flow.


Grüße
 Thomas

[PATCH 10/10] testsuite: aarch64: arm: Fix -mcpu=unset -mfpu=auto support in more effective targets

[Christophe Lyon]

Like previous patches, fix the use of -mcpu=unset and -mfpu=auto in
several effective target shared between aarch64 and arm.

aarch64 does not support these flags, so we use them only on arm.

Replace "" with -mfpu=auto in the first flags we try on arm to make
sure the intended FPU effect of -march is taken into account in case
the whole testsuite is executed with flags overridden. (e.g. forcing
M-profile)

This re-enables many tests, including:
vdot-3-[134].c (aarch64)
vdot-exec.c (aarch64)
vector-complex.c (aarch64)
vector-complex_f16.c (aarch64)
some tests from vect/complex.exp (arm and aarch64)
vqrdmlah* (aarch64)
vqrdmlsh* (aarch64)
f16 tests in advsimd-intrinsics (arm and aarch64)

gcc/testsuite/
* lib/target-supports.exp
(check_effective_target_arm_v8_1a_neon_ok_nocache): Fix use of
-mcpu=unset and -mfpu=auto.
(check_effective_target_arm_v8_2a_fp16_scalar_ok_nocache): Likewise.
(check_effective_target_arm_v8_2a_dotprod_neon_ok_nocache): Likewise.
(check_effective_target_arm_v8_2a_i8mm_ok_nocache): Likewise.
(check_effective_target_arm_v8_3a_complex_neon_ok_nocache): Likewise.
(check_effective_target_arm_v8_3a_fp16_complex_neon_ok_nocache): 
Likewise.
---
 gcc/testsuite/lib/target-supports.exp | 93 +--
 1 file changed, 74 insertions(+), 19 deletions(-)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 587db04b95e..aa0d18a0dc5 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -6588,17 +6588,27 @@ proc add_options_for_arm_v8_1m_mve_fp { flags } {
 proc check_effective_target_arm_v8_1a_neon_ok_nocache { } {
 global et_arm_v8_1a_neon_flags
 set et_arm_v8_1a_neon_flags ""
+set cpu_unset ""
+set fpu_auto ""
 
 if { ![istarget arm*-*-*] && ![istarget aarch64*-*-*] } {
return 0;
 }
 
+if { [istarget arm*-*-*] } {
+   set cpu_unset "-mcpu=unset"
+   set fpu_auto "-mfpu=auto"
+}
+
 # Iterate through sets of options to find the compiler flags that
 # need to be added to the -march option.  Start with the empty set
 # since AArch64 only needs the -march setting.
-foreach flags {"" "-mfpu=neon-fp-armv8" "-mfloat-abi=softfp" \
-  "-mfpu=neon-fp-armv8 -mfloat-abi=softfp"} {
-   foreach arches { "-mcpu=unset -march=armv8-a+rdma" "-mcpu=unset 
-march=armv8.1-a" } {
+foreach flags [list "$fpu_auto" \
+  "-mfpu=neon-fp-armv8" \
+  "-mfloat-abi=softfp" \
+  "-mfpu=neon-fp-armv8 -mfloat-abi=softfp" ] {
+   foreach arches [list "$cpu_unset -march=armv8-a+rdma" \
+   "$cpu_unset -march=armv8.1-a" ] {
if { [check_no_compiler_messages_nocache arm_v8_1a_neon_ok object {
#if !defined (__ARM_FEATURE_QRDMX)
#error "__ARM_FEATURE_QRDMX not defined"
@@ -6625,22 +6635,31 @@ proc check_effective_target_arm_v8_1a_neon_ok { } {
 proc check_effective_target_arm_v8_2a_fp16_scalar_ok_nocache { } {
 global et_arm_v8_2a_fp16_scalar_flags
 set et_arm_v8_2a_fp16_scalar_flags ""
+set cpu_unset ""
+set fpu_auto ""
 
 if { ![istarget arm*-*-*] && ![istarget aarch64*-*-*] } {
return 0;
 }
 
+if { [istarget arm*-*-*] } {
+   set cpu_unset "-mcpu=unset"
+   set fpu_auto "-mfpu=auto"
+}
+
 # Iterate through sets of options to find the compiler flags that
 # need to be added to the -march option.
-foreach flags {"" "-mfpu=fp-armv8" "-mfloat-abi=softfp" \
-  "-mfpu=fp-armv8 -mfloat-abi=softfp"} {
+foreach flags [list "$fpu_auto" \
+  "-mfpu=fp-armv8" \
+  "-mfloat-abi=softfp" \
+  "-mfpu=fp-armv8 -mfloat-abi=softfp" ] {
if { [check_no_compiler_messages_nocache \
  arm_v8_2a_fp16_scalar_ok object {
#if !defined (__ARM_FEATURE_FP16_SCALAR_ARITHMETIC)
#error "__ARM_FEATURE_FP16_SCALAR_ARITHMETIC not defined"
#endif
-   } "$flags -mcpu=unset -march=armv8.2-a+fp16"] } {
-   set et_arm_v8_2a_fp16_scalar_flags "$flags -mcpu=unset 
-march=armv8.2-a+fp16"
+   } "$flags $cpu_unset -march=armv8.2-a+fp16"] } {
+   set et_arm_v8_2a_fp16_scalar_flags "$flags $cpu_unset 
-march=armv8.2-a+fp16"
return 1
}
 }
@@ -6704,22 +6723,31 @@ proc check_effective_target_arm_v8_2a_fp16_neon_ok { } {
 proc check_effective_target_arm_v8_2a_dotprod_neon_ok_nocache { } {
 global et_arm_v8_2a_dotprod_neon_flags
 set et_arm_v8_2a_dotprod_neon_flags ""
+set cpu_unset ""
+set fpu_auto ""
 
 if { ![istarget arm*-*-*] && ![istarget aarch64*-*-*] } {
return 0;
 }
 
+if { [istarget arm*-*-*] } {
+   set cpu_unset "-mcpu=unset"
+   set fpu_auto "-mfpu=auto"
+}
+
 # Iterate through se

Re: [PATCH 0/1] Cherry pick of patch for gcc-13 fixing PR119372

[Alex Coplan]

On 20/03/2025 14:31, Alfie Richards wrote:
> Hello,
> 
> This is a cherry pick of 20385cb92cbd4a1934661ab97a162c1e25935836 which 
> didn't apply cleanly
> so needed a very minor edit to for it to apply for GCC 12 and 13.
> 
> Regtested and bootstrapped for gcc-13 on aarch64-linux-gnu.
> 
> This applies cleanly to gcc-12 but there is a regression for
> `c-c++-common/hwasan/large-aligned-1.c`. 
> 
> The output of execution was
> 
> ```
> ==2242916==ERROR: HWAddressSanitizer: tag-mismatch on address 0xf680 
> at pc 0xf780e08c
> READ of size 4 at 0xf680 tags: 02/01(00) (ptr/mem) in thread T0
> #0 0xf780e08c in SigTrap<2> 
> ../../../../src/libsanitizer/hwasan/hwasan_checks.h:28
> ```
> 
> and has changed to
> 
> ```
> ==2242927==ERROR: HWAddressSanitizer: tag-mismatch on address 0xf690 
> at pc 0xf780e08c
> READ of size 4 at 0xf690 tags: 02/00 (ptr/mem) in thread T0
> #0 0xf780e08c in SigTrap<2> 
> ../../../../src/libsanitizer/hwasan/hwasan_checks.h:28
> ```
> 
> Note the difference in the tags.
> 
> Does anyone with experience of HWAddressSanitizer know what caused this and 
> if it's an issue?

Yeah, I ran into this too in the past when testing GCC 12 backports.
I think those hwasan tests are flaky due to the dg-output checks being
overly strict.  Martin Liska pushed a fix to GCC 13 to relax them
(r13-100-g3771486daa1e904ceae6f3e135b28e58af33849).  I think that patch
needs backporting to the GCC 12 branch, which I requested here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645278.html but
that backport request was never ACKed.  I still think we should backport
it.

Alex

> 
> Kind regards,
> Alfie Richards
> 
> 
> Andrew Carlotti (1):
>   aarch64: Use PAUTH instead of V8_3A in some places
> 
>  gcc/config/aarch64/aarch64.cc | 6 +++---
>  gcc/config/aarch64/aarch64.md | 8 
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> -- 
> 2.34.1
> 

Re: [PATCH][PUSHED] hwasan: support new dg-output format.

[Alex Coplan]

On 09/02/2024 15:32, Alex Coplan wrote:
> Hi,
> 
> On 04/05/2022 09:59, Martin Liška wrote:
> > Supports change in libsanitizer where it newly reports:
> > READ of size 4 at 0xc3d4 tags: 02/01(00) (ptr/mem) in thread T0
> > 
> > So the 'tags' contains now 3 entries compared to 2 entries.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * c-c++-common/hwasan/alloca-outside-caught.c: Update dg-output.
> > * c-c++-common/hwasan/heap-overflow.c: Likewise.
> > * c-c++-common/hwasan/hwasan-thread-access-parent.c: Likewise.
> > * c-c++-common/hwasan/large-aligned-1.c: Likewise.
> 
> I noticed the above test (large-aligned-1.c) failing on the GCC 12
> branch due to the change in output format mentioned above.  This patch
> (committed as r13-100-g3771486daa1e904ceae6f3e135b28e58af33849f) seems
> to apply cleanly on the GCC 12 branch too, is it OK to backport to GCC 12?

Ping.

> 
> Thanks,
> Alex
> 
> > * c-c++-common/hwasan/stack-tagging-basic-1.c: Likewise.
> > ---
> >  gcc/testsuite/c-c++-common/hwasan/alloca-outside-caught.c   | 2 +-
> >  gcc/testsuite/c-c++-common/hwasan/heap-overflow.c   | 2 +-
> >  gcc/testsuite/c-c++-common/hwasan/hwasan-thread-access-parent.c | 2 +-
> >  gcc/testsuite/c-c++-common/hwasan/large-aligned-1.c | 2 +-
> >  gcc/testsuite/c-c++-common/hwasan/stack-tagging-basic-1.c   | 2 +-
> >  5 files changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/gcc/testsuite/c-c++-common/hwasan/alloca-outside-caught.c 
> > b/gcc/testsuite/c-c++-common/hwasan/alloca-outside-caught.c
> > index 60d7a9a874f..6f3825bee7c 100644
> > --- a/gcc/testsuite/c-c++-common/hwasan/alloca-outside-caught.c
> > +++ b/gcc/testsuite/c-c++-common/hwasan/alloca-outside-caught.c
> > @@ -20,6 +20,6 @@ main ()
> >  }
> >  
> >  /* { dg-output "HWAddressSanitizer: tag-mismatch on address 
> > 0x\[0-9a-f\]*.*" } */
> > -/* { dg-output "READ of size 4 at 0x\[0-9a-f\]* tags: 
> > \[\[:xdigit:\]\]\[\[:xdigit:\]\]/00 \\(ptr/mem\\) in thread T0.*" } */
> > +/* { dg-output "READ of size 4 at 0x\[0-9a-f\]* tags: 
> > \[\[:xdigit:\]\]\[\[:xdigit:\]\]/00.* \\(ptr/mem\\) in thread T0.*" } */
> >  /* { dg-output "Address 0x\[0-9a-f\]* is located in stack of thread T0.*" 
> > } */
> >  /* { dg-output "SUMMARY: HWAddressSanitizer: tag-mismatch \[^\n\]*.*" } */
> > diff --git a/gcc/testsuite/c-c++-common/hwasan/heap-overflow.c 
> > b/gcc/testsuite/c-c++-common/hwasan/heap-overflow.c
> > index 137466800de..bddb38c81f1 100644
> > --- a/gcc/testsuite/c-c++-common/hwasan/heap-overflow.c
> > +++ b/gcc/testsuite/c-c++-common/hwasan/heap-overflow.c
> > @@ -23,7 +23,7 @@ int main(int argc, char **argv) {
> >  }
> >  
> >  /* { dg-output "HWAddressSanitizer: tag-mismatch on address 
> > 0x\[0-9a-f\]*.*" } */
> > -/* { dg-output "READ of size 1 at 0x\[0-9a-f\]* tags: 
> > \[\[:xdigit:\]\]\[\[:xdigit:\]\]/\[\[:xdigit:\]\]\[\[:xdigit:\]\] 
> > \\(ptr/mem\\) in thread T0.*" } */
> > +/* { dg-output "READ of size 1 at 0x\[0-9a-f\]* tags: 
> > \[\[:xdigit:\]\]\[\[:xdigit:\]\]/\[\[:xdigit:\]\]\[\[:xdigit:\]\].* 
> > \\(ptr/mem\\) in thread T0.*" } */
> >  /* { dg-output "located 0 bytes to the right of 10-byte region.*" } */
> >  /* { dg-output "allocated here:.*" } */
> >  /* { dg-output "#1 0x\[0-9a-f\]+ +in _*main \[^\n\r]*heap-overflow.c:18" } 
> > */
> > diff --git 
> > a/gcc/testsuite/c-c++-common/hwasan/hwasan-thread-access-parent.c 
> > b/gcc/testsuite/c-c++-common/hwasan/hwasan-thread-access-parent.c
> > index 828909d3b3b..eca27c8cd2c 100644
> > --- a/gcc/testsuite/c-c++-common/hwasan/hwasan-thread-access-parent.c
> > +++ b/gcc/testsuite/c-c++-common/hwasan/hwasan-thread-access-parent.c
> > @@ -46,6 +46,6 @@ main (int argc, char **argv)
> >  }
> >  
> >  /* { dg-output "HWAddressSanitizer: tag-mismatch on address 
> > 0x\[0-9a-f\]*.*" } */
> > -/* { dg-output "READ of size 4 at 0x\[0-9a-f\]* tags: 
> > 00/\[\[:xdigit:\]\]\[\[:xdigit:\]\] \\(ptr/mem\\) in thread T1.*" } */
> > +/* { dg-output "READ of size 4 at 0x\[0-9a-f\]* tags: 
> > 00/\[\[:xdigit:\]\]\[\[:xdigit:\]\].* \\(ptr/mem\\) in thread T1.*" } */
> >  /* { dg-output "Address 0x\[0-9a-f\]* is located in stack of thread T0.*" 
> > } */
> >  /* { dg-output "SUMMARY: HWAddressSanitizer: tag-mismatch \[^\n\]*.*" } */
> > diff --git a/gcc/testsuite/c-c++-common/hwasan/large-aligned-1.c 
> > b/gcc/testsuite/c-c++-common/hwasan/large-aligned-1.c
> > index 1aa13032396..6158ba4bdbc 100644
> > --- a/gcc/testsuite/c-c++-common/hwasan/large-aligned-1.c
> > +++ b/gcc/testsuite/c-c++-common/hwasan/large-aligned-1.c
> > @@ -9,6 +9,6 @@
> >  /* { dg-output "HWAddressSanitizer: tag-mismatch on address 
> > 0x\[0-9a-f\]*.*" } */
> >  /* NOTE: This assumes the current tagging mechanism (one at a time from the
> > base and large aligned variables being handled first).  */
> > -/* { dg-output "READ of size 4 at 0x\[0-9a-f\]* tags: 
> > \[\[:xdigit:\]\]\[\[:xdigit:\]\]/\[\[:xdigit:\]\]\[\[:xdigit:\]\] 
> > \\(ptr/mem\\) in thread T0.*" } */
> > +

Re: [PATCH 0/1] Cherry pick of patch for gcc-13 fixing PR119372

[Alfie Richards]

On 20/03/2025 14:31, Alfie Richards wrote:

Hello,

This is a cherry pick of 20385cb92cbd4a1934661ab97a162c1e25935836 which didn't 
apply cleanly
so needed a very minor edit to for it to apply for GCC 12 and 13.

Regtested and bootstrapped for gcc-13 on aarch64-linux-gnu.

This applies cleanly to gcc-12 but there is a regression for
`c-c++-common/hwasan/large-aligned-1.c`.

The output of execution was

```
==2242916==ERROR: HWAddressSanitizer: tag-mismatch on address 0xf680 at 
pc 0xf780e08c
READ of size 4 at 0xf680 tags: 02/01(00) (ptr/mem) in thread T0
 #0 0xf780e08c in SigTrap<2> 
../../../../src/libsanitizer/hwasan/hwasan_checks.h:28
```

and has changed to

```
==2242927==ERROR: HWAddressSanitizer: tag-mismatch on address 0xf690 at 
pc 0xf780e08c
READ of size 4 at 0xf690 tags: 02/00 (ptr/mem) in thread T0
 #0 0xf780e08c in SigTrap<2> 
../../../../src/libsanitizer/hwasan/hwasan_checks.h:28
```

Note the difference in the tags.

Does anyone with experience of HWAddressSanitizer know what caused this and if 
it's an issue?


Yeah, I ran into this too in the past when testing GCC 12 backports.
I think those hwasan tests are flaky due to the dg-output checks being
overly strict.  Martin Liska pushed a fix to GCC 13 to relax them
(r13-100-g3771486daa1e904ceae6f3e135b28e58af33849).  I think that patch
needs backporting to the GCC 12 branch, which I requested here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645278.html but
that backport request was never ACKed.  I still think we should backport
it.

Alex


Ah fantastic, yeah that looks great, thank you for passing it on.
That makes sense then why I didn't see the same regression on GCC-13.

I've applied this and the regression does then go away, so if possible I 
would like to commit both?


Alfie





Kind regards,
Alfie Richards


Andrew Carlotti (1):
   aarch64: Use PAUTH instead of V8_3A in some places

  gcc/config/aarch64/aarch64.cc | 6 +++---
  gcc/config/aarch64/aarch64.md | 8 
  2 files changed, 7 insertions(+), 7 deletions(-)

--
2.34.1

[PATCH 1/1] aarch64: Use PAUTH instead of V8_3A in some places

[Alfie Richards]

From: Andrew Carlotti 

gcc/ChangeLog:

* config/aarch64/aarch64.cc
(aarch64_expand_epilogue): Use TARGET_PAUTH.
* config/aarch64/aarch64.md: Update comment.
---
 gcc/config/aarch64/aarch64.cc | 6 +++---
 gcc/config/aarch64/aarch64.md | 8 
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 0a98f005b71..b211f9abd60 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -10363,12 +10363,12 @@ aarch64_expand_epilogue (bool for_sibcall)
1) Sibcalls don't return in a normal way, so if we're about to call one
   we must authenticate.
 
-   2) The RETAA instruction is not available before ARMv8.3-A, so if we are
-  generating code for !TARGET_ARMV8_3 we can't use it and must
+   2) The RETAA instruction is not available without FEAT_PAuth, so if we
+  are generating code for !TARGET_PAUTH we can't use it and must
   explicitly authenticate.
 */
   if (aarch64_return_address_signing_enabled ()
-  && (for_sibcall || !TARGET_ARMV8_3))
+  && (for_sibcall || !TARGET_PAUTH))
 {
   switch (aarch_ra_sign_key)
{
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index b585604cbe0..ff74e7dcef6 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -7280,11 +7280,11 @@ (define_insn "aarch64_fjcvtzs"
   [(set_attr "type" "f_cvtf2i")]
 )
 
-;; Pointer authentication patterns are always provided.  In architecture
-;; revisions prior to ARMv8.3-A these HINT instructions operate as NOPs.
+;; Pointer authentication patterns are always provided.  On targets that
+;; don't implement FEAT_PAuth these HINT instructions operate as NOPs.
 ;; This lets the user write portable software which authenticates pointers
-;; when run on something which implements ARMv8.3-A, and which runs
-;; correctly, but does not authenticate pointers, where ARMv8.3-A is not
+;; when run on something which implements FEAT_PAuth, and which runs
+;; correctly, but does not authenticate pointers, where FEAT_PAuth is not
 ;; implemented.
 
 ;; Signing/Authenticating R30 using SP as the salt.
-- 
2.34.1

[PATCH 2/2] libstdc++: Fix std.compat exports of and

[Jonathan Wakely]

libstdc++-v3/ChangeLog:

* src/c++23/std.compat.cc.in: Only export  and
 contents for C++26 and later.
---

Tested by compiling and importing both std and std.compat.

 libstdc++-v3/src/c++23/std.compat.cc.in | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/src/c++23/std.compat.cc.in 
b/libstdc++-v3/src/c++23/std.compat.cc.in
index ba7ed0312ab..344502195b1 100644
--- a/libstdc++-v3/src/c++23/std.compat.cc.in
+++ b/libstdc++-v3/src/c++23/std.compat.cc.in
@@ -21,11 +21,15 @@
 // see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 // .
 
+module;
+
+#include 
+#include 
+
 export module std.compat;
 export import std;
 
-#include 
-
+#ifdef __STDC_VERSION_STDBIT_H__
 // 
 export
 {
@@ -52,7 +56,9 @@ _GLIBCXX_STDBIT_FUNC(stdc_bit_floor);
 _GLIBCXX_STDBIT_FUNC(stdc_bit_ceil);
 #undef _GLIBCXX_STDBIT_FUNC
 }
+#endif
 
+#ifdef __STDC_VERSION_STDCKDINT_H__
 // 
 export
 {
@@ -60,6 +66,7 @@ export
   using __gnu_cxx::ckd_sub;
   using __gnu_cxx::ckd_mul;
 }
+#endif
 
 #define STD_COMPAT 1
 
-- 
2.49.0

[PATCH 1/2] libstdc++: Add views::cache_latest and views::to_input to std module

[Jonathan Wakely]

Also export the tuple-like helpers from , and the
std::from_range_t and std::from_range tag.

libstdc++-v3/ChangeLog:

* src/c++23/std.cc.in (tuple_element, tuple_element_t)
(tuple_size, tuple_size_v, get): Export.
(ranges::cache_latest_view, views::cache_latest): Export.
(ranges::to_input_view, views::to_input): Export.
(from_range_t, from_range): Export.
---

Tested by compiling and importing std and briefly testing the imported
features.

 libstdc++-v3/src/c++23/std.cc.in | 23 ---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/libstdc++-v3/src/c++23/std.cc.in b/libstdc++-v3/src/c++23/std.cc.in
index c0b7e1dc727..12253b95c5a 100644
--- a/libstdc++-v3/src/c++23/std.cc.in
+++ b/libstdc++-v3/src/c++23/std.cc.in
@@ -924,6 +924,13 @@ export namespace std
   using std::sqrt;
   using std::tan;
   using std::tanh;
+#if __cpp_lib_tuple_like >= 202311L
+  using std::tuple_element;
+  using std::tuple_element_t;
+  using std::tuple_size;
+  using std::tuple_size_v;
+  using std::get;
+#endif
 }
 export namespace std::inline literals::inline complex_literals
 {
@@ -2383,14 +2390,24 @@ export namespace std
 using ranges::enumerate_view;
 namespace views { using views::enumerate; }
 #endif
-#if __cpp_lib_ranges_to_container // C++ >= 23
-using ranges::to;
-#endif // __cpp_lib_ranges_to_container
 #if __cpp_lib_ranges_concat // C++ >= C++26
 using ranges::concat_view;
 namespace views { using views::concat; }
+#endif
+#if __cpp_lib_ranges_cache_latest // C++ >= C++26
+using ranges::cache_latest_view;
+namespace views { using views::cache_latest; }
+#endif
+#if __glibcxx_ranges_to_input // C++ >= 26
+using ranges::to_input_view;
+namespace views { using views::to_input; }
 #endif
   }
+#if __glibcxx_ranges_to_container // C++ >= 23
+  namespace ranges { using ranges::to; }
+  using std::from_range_t;
+  using std::from_range;
+#endif
 }
 
 // 
-- 
2.49.0