RE: [PATCH] cobol: Implement CXXFLAGS_FOR_COBOL.
Thank you. I didn't respond sooner because I was away from the computer for a few days. And thank you for giving me some clarity on that line I labeled, "I don't understand..." > -Original Message- > From: Iain Buclaw > Sent: Thursday, July 10, 2025 15:11 > To: Robert Dubner ; Andreas Schwab > Cc: gcc-patches@gcc.gnu.org; Rainer Orth > Subject: RE: [PATCH] cobol: Implement CXXFLAGS_FOR_COBOL. > > Excerpts from Robert Dubner's message of Juli 9, 2025 4:32 pm: > > With respect, this is another example of "I have been unable to make it > > work." > > > > The gcc/Makefile.in has this line in it: > > > > $(foreach file,$(ALL_HOST_FRONTEND_OBJS),$(eval CFLAGS-$(file) += > > -DIN_GCC_FRONTEND)) > > > > At the point where gcc/cobol files are compiled, the environment > variable > > has this value: > > > > CFLAGS-cobol/genapi.o is -DIN_GCC_FRONTEND > > > > An attempt to override that with > > > > make CFLAGS-cobol/genapi.o=-DHARMLESS > > > > has no effect on the value of the CFLAGS-cobol/genapi.o > > > > I commented out the $(foreach... line and tried to set the variable with > > the make command. > > > > Even then, CFLAGS-cobol/genapi.o did not seem to be set as a result. > > > > I do not know why my attempts to set CFLAGS-cobol/genapi.o are failing. > > > > Hi Robert, > > This is to be set in cobol/Make-lang.in > > --- a/gcc/cobol/Make-lang.in > +++ b/gcc/cobol/Make-lang.in > @@ -122,6 +122,7 @@ cobol_OBJS = \ > # Frankly, I can't figure out what this does: > # > CFLAGS-cobol/gcobolspec.o += $(DRIVER_DEFINES) > +CFLAGS-cobol/genapi.o += -DHARMLESS > > # > # This controls the build of the gcobol "driver" > --- > > Then when running make, you'll eventually see. > > g++ -fno-PIE -c -DHARMLESS -DIN_GCC_FRONTEND -g -O2 -DIN_GCC > -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall > -Wno-error=narrowing -Wwrite-strings -Wcast-qual > -Wmissing-format-attribute -Wconditionally-supported > -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros > -Wno-overlength-strings -DHAVE_CONFIG_H -fno-PIE -I. -Icobol > -I../../gcc -I../../gcc/cobol -I../../gcc/../include > -I../../gcc/../libcpp/include -I../../gcc/../libcody > -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid > -I../libdecnumber -I../../gcc/../libbacktrace -o cobol/genapi.o > -MT cobol/genapi.o -MMD -MP -MF cobol/.deps/genapi.TPo > ../../gcc/cobol/genapi.cc > > Iain.
[wwwdocs] Remove contribute.html text about including ChangeLog in the patch
--- This is an anachronism: ChangeLog entries should never be part of the patch, because nobody should be editing them locally and including them in a commit. Whether you can self-approve or not isn't relevant. OK for wwwdocs? htdocs/contribute.html | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/htdocs/contribute.html b/htdocs/contribute.html index 3ab65323..4dfb186d 100644 --- a/htdocs/contribute.html +++ b/htdocs/contribute.html @@ -254,9 +254,8 @@ the Linux kernel documentation for ways to work around this. (Everything listed here still applies if you can check in the patch without further approval under the GCC write access policies, except -that ChangeLog entries may be included as part of the patch and diffs -representing new files may be omitted, especially if large, since they +href="gitwrite.html#policies">GCC write access policies, except that +diffs representing new files may be omitted, especially if large, since they can be accessed directly from the repository.) E-mail subject lines -- 2.50.1
[PATCH] Factor out thread model detection with `GCC_AC_THREAD_MODEL`
From: John Ericson This macro deduplicates the $CC -v 2>&1 | sed -n 's/^Thread model: //p' check that was occurring in various runtime libs. Additionally, as a bit of an Easter egg, this also allows overriding what the compiler would return by setting the `gcc_cv_target_thread_file` cache variable first. I admit that it is in fact this Easter egg that led me to write the patch. The use-case for it is for making multilib builds where the library sets do not all share the same thread model easier. See also `THREAD_MODEL_SPEC` for more about the varying thread models use-case. Arguably one could could try to define on `THREAD_MODEL_SPEC` on more platforms (besides e.g. AIX) but the ramifications of this are a bit unclear. Setting `gcc_cv_target_thread_file` directly is a "low tech" solution that will work for now for sure. Of course, since setting a cache variable like this a hacky trick, I will not expect this to be at all stable/guaranteed to work, going forward. Thanks to Arsen who on IRC discussed these things with me, including in particular making it a cache var not `--with-model` flag, to not prematurely foster expectations that this is stable. Suggested-by: Arsen Arsenović --- config/gthr.m4 | 23 +++ libatomic/configure.ac | 4 +--- libgcc/configure.ac | 4 +--- libphobos/m4/druntime/os.m4 | 2 +- libstdc++-v3/acinclude.m4 | 8 +++- 5 files changed, 29 insertions(+), 12 deletions(-) diff --git a/config/gthr.m4 b/config/gthr.m4 index 11996247f15..e8fac4a5721 100644 --- a/config/gthr.m4 +++ b/config/gthr.m4 @@ -5,6 +5,26 @@ dnl Public License, this file may be distributed as part of a program dnl that contains a configuration script generated by Autoconf, under dnl the same distribution terms as the rest of that program. +dnl Define thread model + +dnl usage: GCC_AC_THREAD_MODEL +AC_DEFUN([GCC_AC_THREAD_MODEL], +[ +# Specify the threading model for this GCC runtime library +# Pass with no value to take from compiler's metadata +# Pass with a value to specify a thread package +# 'single' means single threaded -- without threads. +AC_CACHE_CHECK([for the threading model used by GCC], [gcc_cv_target_thread_file], [ + # Set new cache variable + gcc_cv_target_thread_file=`$CC -v 2>&1 | sed -n 's/^Thread model: //p'` +]) +# Set variable name (not prefixed enough to be a good cache variable +# name) traditionally used for this purpose, to avoid having to change +# a bunch of configure scripts. +target_thread_file="$gcc_cv_target_thread_file" +]) + + dnl Define header location by thread model dnl usage: GCC_AC_THREAD_HEADER([thread_model]) @@ -23,6 +43,9 @@ case $1 in vxworks) thread_header=config/gthr-vxworks.h ;; win32) thread_header=config/i386/gthr-win32.h ;; mcf) thread_header=config/i386/gthr-mcf.h ;; +*) +AC_MSG_ERROR([No known header for threading model '$1'.]) +;; esac AC_SUBST(thread_header) ]) diff --git a/libatomic/configure.ac b/libatomic/configure.ac index aafae71028d..a1aa3bdf69f 100644 --- a/libatomic/configure.ac +++ b/libatomic/configure.ac @@ -162,9 +162,7 @@ libtool_VERSION=3:0:2 AC_SUBST(libtool_VERSION) # Check for used threading-model -AC_MSG_CHECKING([for thread model used by GCC]) -target_thread_file=`$CC -v 2>&1 | sed -n 's/^Thread model: //p'` -AC_MSG_RESULT([$target_thread_file]) +GCC_AC_THREAD_MODEL case "$target" in *aarch64*) diff --git a/libgcc/configure.ac b/libgcc/configure.ac index 85e4f1bc48b..d44493f9653 100644 --- a/libgcc/configure.ac +++ b/libgcc/configure.ac @@ -305,9 +305,7 @@ AC_SUBST([use_tm_clone_registry]) AC_LIB_PROG_LD_GNU -AC_MSG_CHECKING([for thread model used by GCC]) -target_thread_file=`$CC -v 2>&1 | sed -n 's/^Thread model: //p'` -AC_MSG_RESULT([$target_thread_file]) +GCC_AC_THREAD_MODEL # Check for assembler CFI support. AC_CACHE_CHECK([whether assembler supports CFI directives], [libgcc_cv_cfi], diff --git a/libphobos/m4/druntime/os.m4 b/libphobos/m4/druntime/os.m4 index ef8ca434407..7bb91362dbe 100644 --- a/libphobos/m4/druntime/os.m4 +++ b/libphobos/m4/druntime/os.m4 @@ -32,7 +32,7 @@ case $1 in # TODO: These targets need porting. dce|mipssde|rtems|tpf|vxworks) DCFG_THREAD_MODEL="Single" ;; -*) as_fn_error "Thread implementation '$1' not recognised" "$LINENO" 5 ;; +*) AC_MSG_ERROR([Thread implementation '$1' not recognised]) ;; esac AC_SUBST(DCFG_THREAD_MODEL) ]) diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4 index a0094c2dd95..66fc3abe4fd 100644 --- a/libstdc++-v3/acinclude.m4 +++ b/libstdc++-v3/acinclude.m4 @@ -4345,9 +4345,7 @@ dnl Substs: dnl thread_header dnl AC_DEFUN([GLIBCXX_ENABLE_THREADS], [ - AC_MSG_CHECKING([for thread model used by GCC]) - target_thread_file=`$CXX -v 2>&1 | sed -n 's/^Thread model: //p'` - AC_MSG_RESULT([$target_thread_file]) + GCC_AC_THREAD_MODEL GCC_AC_THREAD_HEADER([$target_thread_file]) ]) @@ -435
Re: [wwwdocs] Remove contribute.html text about including ChangeLog in the patch
On Sun, Jul 13, 2025 at 05:28:21PM +0100, Jonathan Wakely wrote: > --- > > This is an anachronism: ChangeLog entries should never be part of the > patch, because nobody should be editing them locally and including them > in a commit. Whether you can self-approve or not isn't relevant. > > OK for wwwdocs? LGTM. Jakub
[PUSHED] tree: Add include to tm_p.h to tree.cc [PR120866]
After r16-1738-g0337e3c2743ca0, a call to ASM_GENERATE_INTERNAL_LABEL was done without including tm_p.h. This does not break most targets as ASM_GENERATE_INTERNAL_LABEL macro function does not call target specific functions from it; mostly just sprintf. It does however break pdp11-aout and powerpc-aix* because those two call a target specific function to do create the internal label. Pushed as obvious after a build of gcc for pdp11-aout and x86_64-linux-gnu. PR middle-end/120866 gcc/ChangeLog: * tree.cc: Add include to tm_p.h. Signed-off-by: Andrew Pinski --- gcc/tree.cc | 1 + 1 file changed, 1 insertion(+) diff --git a/gcc/tree.cc b/gcc/tree.cc index 6a055c8c2d0..9d3d0ecf324 100644 --- a/gcc/tree.cc +++ b/gcc/tree.cc @@ -32,6 +32,7 @@ along with GCC; see the file COPYING3. If not see #include "coretypes.h" #include "backend.h" #include "target.h" +#include "tm_p.h" #include "tree.h" #include "gimple.h" #include "tree-pass.h" -- 2.43.0
[RFC 0/1] fortran: TARGET_CLONES attribute argument parsing syntax
From: ZAMBAR
Hi all,
I would like to seek feedback on the implementation approach for the
TARGET_CLONES attribute in gfortran, specifically regarding the syntax
for parsing multiple target specifications.
Currently, I have implemented TARGET_CLONES support for Fortran using
a C-style comma-separated argument list within parentheses, following
the same pattern as the C/C++ front ends. The syntax looks like:
!GCC$ ATTRIBUTES TARGET_CLONES("default", "avx", "avx512f") :: function_name
This allows both double and single quoted strings:
!GCC$ ATTRIBUTES TARGET_CLONES('default', 'avx', 'avx512f') :: function_name
The key design question I'd like feedback on is whether this C-style
comma-separated syntax is appropriate for Fortran, or if we should
consider alternative approaches that might be more idiomatic to Fortran.
The current implementation:
- Parses comma-separated quoted string arguments
- Stores the target specifications in the symbol structure
- Integrates with the existing multiple target infrastructure
- Follows the same semantics as C/C++ TARGET_CLONES
I have a working patch (attached) that implements C-like syntax, but before
proceeding further, I wanted to get community input on whether this syntax
feels appropriate for Fortran users, or if there are better alternatives
that would be more consistent with Fortran conventions.
Thanks for your time and feedback.
Best regards,
ZAMBAR
ZAMBAR (1):
feat: gfortran target_clones mversion
gcc/fortran/decl.cc | 116
gcc/fortran/f95-lang.cc | 34
gcc/fortran/gfortran.h | 5 ++
gcc/fortran/symbol.cc | 8 +++
gcc/multiple_target.cc | 9 +++-
5 files changed, 170 insertions(+), 2 deletions(-)
--
2.34.1
Re: [PATCH] middle-end: Fix typo in gimple.h
On 13/07/25 07:50 +, Benjamin Wu wrote:
2025-07-13 Ben Wu
* gimple.h (GTMA_DOES_GO_IRREVOCABLE): Fix typo.
Tested on x86_64-pc-linux-gnu. Will someone be able to commit this typo fix for
me?
The patch doesn't apply, because of the ChangeLog part. Please do
*not* include changes to the ChangeLog files, those are autogenerated
from the Git commit messages:
https://gcc.gnu.org/codingconventions.html#ChangeLogs
(Historically the ChangeLog entry needed to be part of the patch, but
that hasn't been true for several years.)
I'll take take of applying it manually, thanks for the patch.
Thanks!
---
7 gcc/ChangeLog | 4
8 gcc/gimple.h | 2 +-
9 2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 711d0409f00..9a6a17d9eef 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+2025-07-13 Ben Wu
+
+* gimple.h (GTMA_DOES_GO_IRREVOCABLE): Fix typo.
+
2025-07-12 Jan Hubicka
* auto-profile.cc (function_instance::~function_instance):
diff --git a/gcc/gimple.h b/gcc/gimple.h
index 268884677e1..5c970cee7e6 100644
--- a/gcc/gimple.h
+++ b/gcc/gimple.h
@@ -865,7 +865,7 @@ struct GTY((tag("GSS_ASSUME")))
tell the runtime that it should begin the transaction in
serial-irrevocable mode. */
#define GTMA_DOES_GO_IRREVOCABLE (1u << 6)
-/* The transaction contains no instrumentation code whatsover, most
+/* The transaction contains no instrumentation code whatsoever, most
likely because it is guaranteed to go irrevocable upon entry. */
#define GTMA_HAS_NO_INSTRUMENTATION (1u << 7)
--
2.43.0
Re: [PATCH] Allow explicitly specifying the thread model for runtime libs
I reached out on IRC, and got some feedback on this patch. In particular, Arsen thought the idea made some sense, but that while there was as-yet no long-term policy or design decision on this sort of thing, a proper --with-* flag would wrongly appear to instantly-stable, but a mere autoconf cache variable (which could still be sneakily overridden) would not convey that, reducing the chance of fostering incorrect stability expectations downstream. (Having some trouble sending emails now it seems? This is yet another attempt. We'll see if it goes through.) On Fri, Jul 11, 2025, at 11:02 AM, John Ericson wrote: > Hello, this 4-year-old patch of mine was never reviewed. Per > https://github.com/NixOS/nixpkgs/pull/414299, we in a package set / distro, > Nixpkgs/NixOS, just began (albeit on an experimental basis) packaging GCC > with this patch (among others) applied. It would thus be nice to get it > applied upstream --- if changes are needed, of course we can make them and > resubmit. > > (The is also visible at > https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/gcc/ng/15/gcc/custom-threading-model.patch.) > > This is I think the conceptually simplest patch/series of the ones we have in > there, so a good one to start with. (I think it would be unnecessary > complicated to discuss them all at once.) > > Thanks in advance, > > John > > On Wed, Aug 18, 2021, at 4:38 PM, John Ericson wrote: >> From: John Ericson >> >> Previously, they always scraped the thread mode from `$CC -v', now, that >> is the default but one may pass `--with-threads=MODEL` to be explicit >> instead. >> >> One use-case is bootstraping with a shorter critical path. The >> traditionally route was to build an entire "static stage" GCC, build >> libc, and then build GCC again supporting dynamic linking, >> multithreading, etc. But this is wasteful in that GCC itself is built >> twice. >> >> With this change, rather than having to mess with spec files we can just >> configure the runtime libraries the way we want directly. In turn, that >> opens to just building libgcc twice rather than all of GCC. >> >> Frankly, specs were always a rather indirect approach to coordinate this >> during GCC's bootstrap, since GCC itself really doesn't care what the >> threading model is, just that the runtime libraries agree among >> themselves. Relying on a hard-coded spec for this also keeps us one step >> further from the long-term goal of multi-target GCC, for what it's >> worth. >> >> For the record, "single stage" builds of GCC have some precedent in >> downstream packaging, for example with [1]. That one, as far as I can >> tell, builds libgcc once, but with the headers of the libc >> implementation provided and then cyclic linking down later. They are >> both fine approaches, but I don't think one should have to be forced >> into cyclic dependencies if they don't want to. That opens the door to >> non-terminating programs due to, e.g., atomics used in a threads >> implementation being lowered to threads absent hardware support. >> >> Finally, I understand that such custom bootstrapping is not officially >> supported. I don't mean to imply it should be --- a lot more cleanup >> work to the build system would be necessary before supporting it >> wouldn't be a huge additional maintainer burden --- I just hope to add a >> reasonable knob for those comfortable with doing unsupported things >> already. >> >> [1]: https://github.com/richfelker/musl-cross-make >> --- >> config/gthr.m4 | 32 >> libatomic/configure.ac | 4 +--- >> libgcc/configure.ac | 4 +--- >> libphobos/m4/druntime/os.m4 | 2 +- >> libstdc++-v3/acinclude.m4 | 8 +++- >> 5 files changed, 38 insertions(+), 12 deletions(-) >> >> diff --git a/config/gthr.m4 b/config/gthr.m4 >> index 4b937306ad0..c585b618e40 100644 >> --- a/config/gthr.m4 >> +++ b/config/gthr.m4 >> @@ -5,6 +5,35 @@ dnl Public License, this file may be distributed as part of >> a program >> dnl that contains a configuration script generated by Autoconf, under >> dnl the same distribution terms as the rest of that program. >> >> +dnl Define thread model >> + >> +dnl usage: GCC_AC_THREAD_MODEL >> +AC_DEFUN([GCC_AC_THREAD_MODEL], >> +[ >> +# With threads >> +# Pass with no value to take from compiler's metadata >> +# Pass with a value to specify a thread package >> +# 'single' means single threaded -- without threads. >> +AC_ARG_WITH(threads, >> +[AS_HELP_STRING([[--with-threads=MODEL]], >> + [specify thread model for this GCC >> + runtime library])],, >> +[with_threads='']) >> + >> +if test x"$with_threads" = x'yes'; then >> +AC_MSG_ERROR([Cannot pass bare --with-threads, must pass explicit >> --with-threads=MODEL]) >> +elif test x"$with_threads" = x'no'; then >> +target_thread_file=single >> +elif test x"$with_threads" = ''; then >> +AC_MSG_CHECKING([for thread model used by GCC]) >> +target_thread_f
[RFC 1/1] fortran: Add TARGET_CLONES attribute support
From: ZAMBAR
This patch implements the TARGET_CLONES attribute for Fortran functions,
using C-style comma-separated syntax for target specifications.
The implementation adds:
- Parsing support for TARGET_CLONES("target1", "target2", ...)
- Integration with existing multiple target infrastructure
- Proper memory management for target arguments
- Error handling for malformed syntax
Example usage:
!GCC$ ATTRIBUTES TARGET_CLONES("default", "avx", "avx512f") :: function_name
---
gcc/fortran/decl.cc | 116
gcc/fortran/f95-lang.cc | 34
gcc/fortran/gfortran.h | 5 ++
gcc/fortran/symbol.cc | 8 +++
gcc/multiple_target.cc | 9 +++-
5 files changed, 170 insertions(+), 2 deletions(-)
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 69acd2da981..ed7c82dd8a3 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -11879,6 +11879,7 @@ const ext_attr_t ext_attr_list[] = {
{ "noinline", EXT_ATTR_NOINLINE, NULL },
{ "noreturn", EXT_ATTR_NORETURN, NULL },
{ "weak",EXT_ATTR_WEAK, NULL},
+ { "target_clones", EXT_ATTR_TARGET_CLONES, NULL },
{ NULL, EXT_ATTR_LAST, NULL}
};
@@ -11896,6 +11897,13 @@ const ext_attr_t ext_attr_list[] = {
As there is absolutely no risk of confusion, we should never return
MATCH_NO. */
+
+/* Structure to temporarily hold target_clones arguments during parsing */
+typedef struct {
+ char **args;
+ int count;
+} target_clones_args_t;
+
match
gfc_match_gcc_attributes (void)
{
@@ -11904,6 +11912,7 @@ gfc_match_gcc_attributes (void)
unsigned id;
gfc_symbol *sym;
match m;
+ target_clones_args_t target_clones_data = { NULL, 0 };
gfc_clear_attr (&attr);
for(;;)
@@ -11926,6 +11935,85 @@ gfc_match_gcc_attributes (void)
if (!gfc_add_ext_attribute (&attr, (ext_attr_id_t)id,
&gfc_current_locus))
return MATCH_ERROR;
+ /* Handle target_clones attribute with arguments */
+ if (id == EXT_ATTR_TARGET_CLONES)
+ {
+ /* Expect opening parenthesis for target_clones */
+ if (gfc_match_char ('(') != MATCH_YES)
+ {
+ gfc_error ("Expected '(' after TARGET_CLONES attribute at %C");
+ return MATCH_ERROR;
+ }
+
+ /* Parse comma-separated list of target specifications */
+ for (;;)
+ {
+ gfc_expr *expr = NULL;
+
+ /* Match quoted string argument */
+ if (gfc_match_literal_constant (&expr, 0) == MATCH_YES)
+ {
+ /* Verify it's a character constant */
+ if (expr->expr_type == EXPR_CONSTANT && expr->ts.type ==
BT_CHARACTER)
+ {
+ target_clones_data.count++;
+ target_clones_data.args = (char **) xrealloc
(target_clones_data.args,
+
target_clones_data.count * sizeof (char *));
+
+ /* Convert gfc_char_t* to char* */
+ int len = expr->value.character.length;
+ char *arg_str = (char *) xmalloc (len + 1);
+ for (int i = 0; i < len; i++)
+ arg_str[i] = (char) expr->value.character.string[i];
+ arg_str[len] = '\0';
+
+ target_clones_data.args[target_clones_data.count - 1] =
arg_str;
+ gfc_free_expr (expr);
+
+ /* Check for comma (more arguments) or closing
parenthesis */
+ gfc_gobble_whitespace ();
+ if (gfc_match_char (',') == MATCH_YES)
+ {
+ gfc_gobble_whitespace ();
+ continue;
+ }
+ else if (gfc_match_char (')') == MATCH_YES)
+ break;
+ else
+ {
+ gfc_error ("Expected ',' or ')' in TARGET_CLONES
argument list at %C");
+ goto target_clones_error;
+ }
+ }
+ else
+ {
+ gfc_free_expr (expr);
+ gfc_error ("TARGET_CLONES arguments must be character
constants at %C");
+ goto target_clones_error;
+ }
+ }
+ else
+ {
+ gfc_error ("Expected quoted string argument in TARGET_CLONES
at %C");
+ goto target_clones_error;
+ }
+ }
+
+ goto attribute_parsed;
+
+target_clones_error:
+ if (target_clones_data.args)
+ {
+ for (int i = 0; i < target_clones_data.count; i++)
+
[committed] cobol: Minor changes to genapi.cc to eliminate CPPCHECK warnings.
Subject: [PATCH] cobol: Minor changes to genapi.cc to eliminate CPPCHECK warnings. Several hundred cppcheck warnings were eliminated. Most of these changes were replacing C-style casts, checking for NULL pointers, establishing some variables and formal parameters as const, and moving some variables around to tidy up their scopes. One memory leak was found and eliminated as a result of the cppcheck. gcc/cobol/ChangeLog: * Make-lang.in: Eliminate the .cc.o override. * genapi.cc (level_88_helper): Eliminate cppcheck warning. (get_level_88_domain): Likewise. (get_class_condition_string): Likewise. (parser_call_targets_dump): Likewise. (parser_compile_ecs): Likewise. (initialize_variable_internal): Likewise. (move_tree): Likewise. (combined_name): Likewise. (assembler_label): Likewise. (find_procedure): Likewise. (parser_perform): Likewise. (parser_perform_times): Likewise. (internal_perform_through): Likewise. (internal_perform_through_times): Likewise. (psa_FldLiteralN): Likewise. (psa_FldBlob): Likewise. (parser_accept): Likewise. (parser_accept_exception): Likewise. (parser_accept_exception_end): Likewise. (parser_accept_command_line): Likewise. (parser_accept_envar): Likewise. (parser_display_internal): Likewise. (parser_display): Likewise. (parser_assign): Likewise. (parser_initialize_table): Likewise. (parser_arith_error): Likewise. (parser_arith_error_end): Likewise. (parser_division): Likewise. (label_fetch): Likewise. (parser_label_label): Likewise. (parser_label_goto): Likewise. (parser_perform_start): Likewise. (parser_perform_conditional): Likewise. (parser_perform_conditional_end): Likewise. (parser_perform_until): Likewise. (parser_file_delete): Likewise. (parser_intrinsic_subst): Likewise. (create_lsearch_address_pairs): Likewise. (parser_bsearch_start): Likewise. (is_ascending_key): Likewise. (parser_sort): Likewise. (parser_file_sort): Likewise. (parser_return_start): Likewise. (parser_file_merge): Likewise. (parser_string_overflow): Likewise. (parser_unstring): Likewise. (parser_string): Likewise. (parser_call_exception): Likewise. (create_and_call): Likewise. (mh_identical): Likewise. (move_helper): Likewise. (binary_initial_from_float128): Likewise. (initial_from_initial): Likewise. (psa_FldLiteralA): Likewise. (parser_local_add): Likewise. (parser_symbol_add): Likewise. * genapi.h (parser_display): Likewise. * gengen.cc (gg_call_expr): Explict check for NULL_TREE. (gg_call): Likewise. * show_parse.h (SHOW_PARSE_LABEL_OK): Likewise. (TRACE1_FIELD_VALUE): Likewise. (CHECK_FIELD): Likewise. (CHECK_FIELD2): Likewise. (CHECK_LABEL): Likewise. * util.cc (cbl_internal_error): Apply [[noreturn]] attribute. * util.h (cbl_internal_error): Likewise. libgcobol/ChangeLog: * common-defs.h (PTRCAST): Moved here from libgcobol.h. * libgcobol.h (PTRCAST): Deleted. --- gcc/cobol/Make-lang.in | 28 +-- gcc/cobol/genapi.cc | 433 gcc/cobol/genapi.h | 4 +- gcc/cobol/gengen.cc | 4 +- gcc/cobol/show_parse.h | 49 - gcc/cobol/util.cc | 2 + gcc/cobol/util.h| 2 +- libgcobol/common-defs.h | 8 + libgcobol/libgcobol.h | 7 - 9 files changed, 334 insertions(+), 203 deletions(-) 0001-cobol-Minor-changes-to-genapi.cc-to-eliminate-CPPCHE.patch Description: Binary data
[PATCH v3] x86: Update MMX moves to support all 1s vectors
On Sat, Jul 12, 2025 at 7:51 PM Uros Bizjak wrote:
>
> On Sat, Jul 12, 2025 at 1:41 PM H.J. Lu wrote:
> >
> > On Sat, Jul 12, 2025 at 5:58 PM Uros Bizjak wrote:
> > >
> > > On Sat, Jul 12, 2025 at 11:52 AM H.J. Lu wrote:
> > > >
> > > > On Sat, Jul 12, 2025 at 5:03 PM Uros Bizjak wrote:
> > > > >
> > > > > On Fri, Jul 11, 2025 at 6:05 AM H.J. Lu wrote:
> > > > > >
> > > > > > commit 77473a27bae04da99d6979d43e7bd0a8106f4557
> > > > > > Author: H.J. Lu
> > > > > > Date: Thu Jun 26 06:08:51 2025 +0800
> > > > > >
> > > > > > x86: Also handle all 1s float vector constant
> > > > > >
> > > > > > replaces
> > > > > >
> > > > > > (insn 29 28 30 5 (set (reg:V2SF 107)
> > > > > > (mem/u/c:V2SF (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0
> > > > > > S8 A64])) 2031
> > > > > > {*movv2sf_internal}
> > > > > > (expr_list:REG_EQUAL (const_vector:V2SF [
> > > > > > (const_double:SF -QNaN [-QNaN]) repeated x2
> > > > > > ])
> > > > > > (nil)))
> > > > > >
> > > > > > with
> > > > > >
> > > > > > (insn 98 13 14 3 (set (reg:V8QI 112)
> > > > > > (const_vector:V8QI [
> > > > > > (const_int -1 [0x]) repeated x8
> > > > > > ])) -1
> > > > > > (nil))
> > > > > > ...
> > > > > > (insn 29 28 30 5 (set (reg:V2SF 107)
> > > > > > (subreg:V2SF (reg:V8QI 112) 0)) 2031 {*movv2sf_internal}
> > > > > > (expr_list:REG_EQUAL (const_vector:V2SF [
> > > > > > (const_double:SF -QNaN [-QNaN]) repeated x2
> > > > > > ])
> > > > > > (nil)))
> > > > > >
> > > > > > which leads to
> > > > > >
> > > > > > pr121015.c: In function ‘render_result_from_bake_h’:
> > > > > > pr121015.c:34:1: error: unrecognizable insn:
> > > > > >34 | }
> > > > > > | ^
> > > > > > (insn 98 13 14 3 (set (reg:V8QI 112)
> > > > > > (const_vector:V8QI [
> > > > > > (const_int -1 [0x]) repeated x8
> > > > > > ])) -1
> > > > > > (expr_list:REG_EQUIV (const_vector:V8QI [
> > > > > > (const_int -1 [0x]) repeated x8
> > > > > > ])
> > > > > > (nil)))
> > > > > > during RTL pass: ira
> > > > > >
> > > > > > 1. Add vector_const0_or_m1_operand for vector 0 or integer vector
> > > > > > -1.
> > > > > > 2. Add nonimm_or_vector_const0_or_m1_operand for nonimmediate,
> > > > > > vector 0
> > > > > > or integer vector -1 operand.
> > > > > > 3. Add BX constraint for MMX vector constant all 0s/1s operand.
> > > > > > 4. Update MMXMODE:*mov_internal to support integer all 1s
> > > > > > vectors.
> > > > > > Replace with to generate
> > > > > >
> > > > > > pcmpeqd %xmm0, %xmm0
> > > > > >
> > > > > > for
> > > > > >
> > > > > > (set (reg/i:V8QI 20 xmm0)
> > > > > > (const_vector:V8QI [(const_int -1 [0x])
> > > > > > repeated x8]))
> > > > > >
> > > > > > NB: The upper 64 bits in XMM0 are all 1s, instead of all 0s.
> > > > >
> > > > > Actually, we don't want this, we should keep the top 64 bits zero,
> > > > > especially for floating point, where the pattern represents NaN.
> > > > >
> > > > > So, I think the correct way is to avoid the transformation for
> > > > > narrower modes in the first place.
> > > > >
> > > >
> > > > How does your latest patch handle this?
> > > >
> > > > typedef char __v8qi __attribute__ ((__vector_size__ (8)));
> > > >
> > > > __v8qi
> > > > m1 (void)
> > > > {
> > > > return __extension__(__v8qi){-1, -1, -1, -1, -1, -1, -1, -1};
> > > > }
> > >
> > > No, my patch is also not appropriate, because it also introduces
> > > "pcmpeq %xmm, %xmm". We should not generate 8-byte all-ones load using
> > > pcmpeq, because upper 64 bits are also all 1s.
> > >
> > > The correct way is to avoid generating 64 bit all-ones, because this
> > > constant is not supported and standard_sse_constant_p () correctly
> > > reports this.
> >
> > We can generate
> >
> > pcmpeqd %xmm0, %xmm0
> > movq %xmm0, %xmm0
> >
> > for V8QI and
> >
> > pcmpeqd %xmm0, %xmm0
> > movd %xmm0, %xmm0
> >
> > for V4QI.
>
> I don't think this is better than skipping the transformation for
> instructions that we in fact emulate altogether. While loading
> all-zero is OK in any mode, loading all-one is not OK for narrow
> modes. So, this transformation should simply be skipped for all-one in
> narrow modes.
Here is the v3 patch, which allows 4-byte/8-byte all 1s in mmx.md
and split to load from memory if the destination is an XMM register.
OK for master?
Thanks.
H.J.
---
commit 77473a27bae04da99d6979d43e7bd0a8106f4557
Author: H.J. Lu
Date: Thu Jun 26 06:08:51 2025 +0800
x86: Also handle all 1s float vector constant
replaces
(insn 29 28 30 5 (set (reg:V2SF 107)
(mem/u/c:V2SF (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0 S8 A64])) 2031
{*movv2sf_internal}
(expr_list:REG_EQUAL (const_vector:V2SF [
(const_double:SF -QNaN [-QNaN]) repeated x2
])
Re: [PATCH v3] x86: Update MMX moves to support all 1s vectors
On Mon, Jul 14, 2025 at 2:14 AM H.J. Lu wrote:
>
> On Sat, Jul 12, 2025 at 7:51 PM Uros Bizjak wrote:
> >
> > On Sat, Jul 12, 2025 at 1:41 PM H.J. Lu wrote:
> > >
> > > On Sat, Jul 12, 2025 at 5:58 PM Uros Bizjak wrote:
> > > >
> > > > On Sat, Jul 12, 2025 at 11:52 AM H.J. Lu wrote:
> > > > >
> > > > > On Sat, Jul 12, 2025 at 5:03 PM Uros Bizjak wrote:
> > > > > >
> > > > > > On Fri, Jul 11, 2025 at 6:05 AM H.J. Lu wrote:
> > > > > > >
> > > > > > > commit 77473a27bae04da99d6979d43e7bd0a8106f4557
> > > > > > > Author: H.J. Lu
> > > > > > > Date: Thu Jun 26 06:08:51 2025 +0800
> > > > > > >
> > > > > > > x86: Also handle all 1s float vector constant
> > > > > > >
> > > > > > > replaces
> > > > > > >
> > > > > > > (insn 29 28 30 5 (set (reg:V2SF 107)
> > > > > > > (mem/u/c:V2SF (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0
> > > > > > > S8 A64])) 2031
> > > > > > > {*movv2sf_internal}
> > > > > > > (expr_list:REG_EQUAL (const_vector:V2SF [
> > > > > > > (const_double:SF -QNaN [-QNaN]) repeated x2
> > > > > > > ])
> > > > > > > (nil)))
> > > > > > >
> > > > > > > with
> > > > > > >
> > > > > > > (insn 98 13 14 3 (set (reg:V8QI 112)
> > > > > > > (const_vector:V8QI [
> > > > > > > (const_int -1 [0x]) repeated x8
> > > > > > > ])) -1
> > > > > > > (nil))
> > > > > > > ...
> > > > > > > (insn 29 28 30 5 (set (reg:V2SF 107)
> > > > > > > (subreg:V2SF (reg:V8QI 112) 0)) 2031 {*movv2sf_internal}
> > > > > > > (expr_list:REG_EQUAL (const_vector:V2SF [
> > > > > > > (const_double:SF -QNaN [-QNaN]) repeated x2
> > > > > > > ])
> > > > > > > (nil)))
> > > > > > >
> > > > > > > which leads to
> > > > > > >
> > > > > > > pr121015.c: In function ‘render_result_from_bake_h’:
> > > > > > > pr121015.c:34:1: error: unrecognizable insn:
> > > > > > >34 | }
> > > > > > > | ^
> > > > > > > (insn 98 13 14 3 (set (reg:V8QI 112)
> > > > > > > (const_vector:V8QI [
> > > > > > > (const_int -1 [0x]) repeated x8
> > > > > > > ])) -1
> > > > > > > (expr_list:REG_EQUIV (const_vector:V8QI [
> > > > > > > (const_int -1 [0x]) repeated x8
> > > > > > > ])
> > > > > > > (nil)))
> > > > > > > during RTL pass: ira
> > > > > > >
> > > > > > > 1. Add vector_const0_or_m1_operand for vector 0 or integer vector
> > > > > > > -1.
> > > > > > > 2. Add nonimm_or_vector_const0_or_m1_operand for nonimmediate,
> > > > > > > vector 0
> > > > > > > or integer vector -1 operand.
> > > > > > > 3. Add BX constraint for MMX vector constant all 0s/1s operand.
> > > > > > > 4. Update MMXMODE:*mov_internal to support integer all 1s
> > > > > > > vectors.
> > > > > > > Replace with to generate
> > > > > > >
> > > > > > > pcmpeqd %xmm0, %xmm0
> > > > > > >
> > > > > > > for
> > > > > > >
> > > > > > > (set (reg/i:V8QI 20 xmm0)
> > > > > > > (const_vector:V8QI [(const_int -1 [0x])
> > > > > > > repeated x8]))
> > > > > > >
> > > > > > > NB: The upper 64 bits in XMM0 are all 1s, instead of all 0s.
> > > > > >
> > > > > > Actually, we don't want this, we should keep the top 64 bits zero,
> > > > > > especially for floating point, where the pattern represents NaN.
> > > > > >
> > > > > > So, I think the correct way is to avoid the transformation for
> > > > > > narrower modes in the first place.
> > > > > >
> > > > >
> > > > > How does your latest patch handle this?
> > > > >
> > > > > typedef char __v8qi __attribute__ ((__vector_size__ (8)));
> > > > >
> > > > > __v8qi
> > > > > m1 (void)
> > > > > {
> > > > > return __extension__(__v8qi){-1, -1, -1, -1, -1, -1, -1, -1};
> > > > > }
> > > >
> > > > No, my patch is also not appropriate, because it also introduces
> > > > "pcmpeq %xmm, %xmm". We should not generate 8-byte all-ones load using
> > > > pcmpeq, because upper 64 bits are also all 1s.
> > > >
> > > > The correct way is to avoid generating 64 bit all-ones, because this
> > > > constant is not supported and standard_sse_constant_p () correctly
> > > > reports this.
> > >
> > > We can generate
> > >
> > > pcmpeqd %xmm0, %xmm0
> > > movq %xmm0, %xmm0
> > >
> > > for V8QI and
> > >
> > > pcmpeqd %xmm0, %xmm0
> > > movd %xmm0, %xmm0
> > >
> > > for V4QI.
> >
> > I don't think this is better than skipping the transformation for
> > instructions that we in fact emulate altogether. While loading
> > all-zero is OK in any mode, loading all-one is not OK for narrow
> > modes. So, this transformation should simply be skipped for all-one in
> > narrow modes.
>
> Here is the v3 patch, which allows 4-byte/8-byte all 1s in mmx.md
> and split to load from memory if the destination is an XMM register.
Why don't we just skip the generation of narrow-mode all-ones vector
constants in the new pass altogether? It is not worth complicating
move patterns for a very seld
Re: [PATCH] MicroBlaze : Enhance support for atomics. Fix PR118280
On Fri, Jul 11, 2025 at 8:12 PM Michael Eager wrote: > On 7/10/25 4:41 AM, Gopi Kumar Bulusu wrote: > > > > namaskaaram > > Hi Gopi! > > > > > Please find the patch attached. This addresses regression for MicroBlaze > > (PR118280) > > Neal Frager posted a different patch (or an RFC) to address pr118280 on > 7/1/25: > https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg376017.html > > The patches are different. Is your patch a replacement for Neal's? > Can you either reconcile the differences or tell me which patch is > correct or better? > This patch overrides the previous one - it works with/without barrel shifter. > > You might also update the PR with this patch and a comment. > pr118280 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118280 > Will do. > > Atomic support enhanced to fix existing atomic_compare_and_swapsi pattern > > to handle side effects; new patterns atomic_fetch_op and > atomic_test_and_set > > added. As MicroBlaze has no QImode test/set instruction, use shift magic > > to implement atomic_test_and_set. Make -mxl-barrel-shift the default to > keep > > the default atomics code tight. > > Include the PR which is resolved in the patch comments. > It is already there (Subject) > > I'm not quite sure what you mean by "keep the default atomics code tight". > > Neal suggested making -mxl-barrel-shift default for linux, but not > default for bare-metal. This might be better for backward > compatibility, but depends on whether there are any MB configurations > which do not include a barrel shifter. If someone does have a MB config > without a barrel shifter and tries to recompile after this patch, it's > possible that invalid code would be silently generated. > I will address this and submit a revision-2 patch. dhanyavaadaaha gopi > > > > > Files Changed > > > > * gcc/config/microblaze/iterators.md: New > > * microblaze-protos.h/microblaze.cc : Add microblaze_subword_address > > * gcc/config/microblaze/microblaze.md: constants: Add UNSPECV_CAS_BOOL, > >UNSPECV_CAS_MEM, UNSPECV_CAS_VAL, UNSPECV_ATOMIC_FETCH_OP > >type: add atomic > > * gcc/config/microblaze/microblaze.h: TARGET_DEFAULT : Add > MASK_BARREL_SHIFT > > * gcc/config/microblaze/sync.md: Add atomic_fetch_si > >atomic_test_and_set > > > > Target Checked > > microblazeel-amd-linux > > > > Testing > > > > deja-g++ > > > > === g++ Summary === > > > > # of expected passes237906 > > # of unexpected failures4165 > > # of unexpected successes 3 > > # of expected failures 2180 > > # of unresolved testcases 645 > > # of unsupported tests 2658 > > > > > > deja-libstdcpp > > > > === libstdc++ Summary === > > > > # of expected passes18180 > > # of unexpected failures311 > > # of expected failures 133 > > # of unresolved testcases 18 > > # of unsupported tests 853 > > > > Includes Test case 29_atomics/atomic_flag/clear/1.cc (which checks for > > atomic_test_and_set) > > I don't have a baseline to compare these test results with, or test > results before applying this patch, so the results don't have any > meaning to me. Was the test case 29 failing before applying the patch > and succeeding after? Were there any other differences? > > Neal indicated that patch was tested using buildroot with > target=microblazeel-buildroot-linux-gnu. It looks like you have > target=microblazeel-amd-linux. How are you running the test suite? > > > -- > Michael Eager > >
Re: [RFC v2] c++: Quoting in -fmodules-mapper [PR110153]
Am Freitag, 11. Juli 2025, 18:42:34 Mitteleuropäische Sommerzeit schrieb Jason
Merrill:
> On 7/10/25 4:41 PM, Nicolas Werner wrote:
> > Users might be using a space in their build directory path. To allow
> > specifying such a root for the module mapper started by GCC, we need the
> > command to allow quotes. Previously quoting a path passed to the module
> > mapper was not possible, so replace the custom argv parsing with
> > the argv parsing logic from libiberty, that supports fairly standard
> > shell quoting using single and double quotes.
> >
> > This also should fix PR110153, although my intention was really to fix
> > passing parameters to the "--root" parameter.
> >
> > I don't know how to best add a test with this yet, since I am unsure
> > about how to best deal with spaces in test folders.
>
> Can you be more specific?
I don't know how to reliably pass a space through the test files and on IRC
people mostly agreed, that leaving out a test for this could be an option.
But more specifically, I am trying to test invocations like
-fmodule-mapper="@g++-module-mapper --root 'path with space'"
or
-fmodule-mapper="@g++-module-mapper --root 'path with space'"
I don't know what quoting rules apply to dg-additional-options and I also
don't know if spaces in file names are even supported on all platforms the
tests need to run on.
>
> > - if (!arg_no)
> > - {
> > - /* @name means look in the compiler's install dir. */
> > - if (ptr[0] == '@')
> > - ptr++;
> > - else
> > - full_program_name = nullptr;
> > - }
> > -
> > - argv[arg_no++] = ptr;
> > - while (*ptr && *ptr != ' ')
> > - ptr++;
> > - if (!*ptr)
> > - break;
> > - *ptr = 0;
> > -}
> > + // Split mapper argument into parameters
> > + char** original_argv = buildargv (name.c_str () + 1);
> > + int arg_no = countargv (original_argv);
> > + char **argv = new char *[arg_no + 1];
>
> Can we drop original_argv so argv is the result of buildargv without
> copying?
If we do that, then I think freeargv() won't work properly, since it will call
free() on a char* incremented by 1. I couldn't think if a simpler way to avoid
that. Decrementing that argument again doesn't seem like a good solution.
Swapping the arg 0 with a different pointer might work.
>
> > + for (int i = 0; i < arg_no; i++)
> > +argv[i] = original_argv[i];
> > +
> > + if (arg_no && argv[0][0] == '@')
> > +argv[0] = argv[0] + 1;
>
> Let's keep the comment from the old code.
Oops, yes, will do!
>
> > @@ -108,8 +89,8 @@ spawn_mapper_program (char const **errmsg, std::string
> > &name,
>
> Word wrap in your mail client corrupted the patch here; it may be easier
> to attach it to avoid that.
>
> Jason
Ah, my bad, I will fix that. I only checked if it didn't wrap any +- lines, I
didn't notice this one. I'll just turn the wrapping off next time.
Thanks for the feedback!
Nico
[PATCH] middle-end: Fix typo in gimple.h
2025-07-13 Ben Wu
* gimple.h (GTMA_DOES_GO_IRREVOCABLE): Fix typo.
Tested on x86_64-pc-linux-gnu. Will someone be able to commit this typo fix for
me?
Thanks!
---
7 gcc/ChangeLog | 4
8 gcc/gimple.h | 2 +-
9 2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 711d0409f00..9a6a17d9eef 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+2025-07-13 Ben Wu
+
+* gimple.h (GTMA_DOES_GO_IRREVOCABLE): Fix typo.
+
2025-07-12 Jan Hubicka
* auto-profile.cc (function_instance::~function_instance):
diff --git a/gcc/gimple.h b/gcc/gimple.h
index 268884677e1..5c970cee7e6 100644
--- a/gcc/gimple.h
+++ b/gcc/gimple.h
@@ -865,7 +865,7 @@ struct GTY((tag("GSS_ASSUME")))
tell the runtime that it should begin the transaction in
serial-irrevocable mode. */
#define GTMA_DOES_GO_IRREVOCABLE (1u << 6)
-/* The transaction contains no instrumentation code whatsover, most
+/* The transaction contains no instrumentation code whatsoever, most
likely because it is guaranteed to go irrevocable upon entry. */
#define GTMA_HAS_NO_INSTRUMENTATION (1u << 7)
--
2.43.0
[PATCH] fortran: Factor array descriptor references
Regression tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Save subexpressions of array descriptor references to variables, so that
all the expressions using the descriptor as base object benefit from a
simplified reference using the variables.
This limits the size of the expressions generated in the original tree
dump, easing analysis of the code involving those expressions.
This is especially helpful with chains of array references where each
array in the chain uses a descriptor.
After optimizations, the effect of the change shouldn't be visible in
the vast majority of cases. In rare cases it seems to permit a couple
more jump threadings.
gcc/fortran/ChangeLog:
* trans-array.cc (gfc_conv_ss_descriptor): Move the descriptor
expression initialisation...
(set_factored_descriptor_value): ... to this new function.
Before initialisation, walk the reference expression passed as
argument and save some of its subexpressions to a variable.
(substitute_t): New struct.
(maybe_substitute_expr): New function.
(substitute_subexpr_in_expr): New function.
---
gcc/fortran/trans-array.cc | 144 -
1 file changed, 143 insertions(+), 1 deletion(-)
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 1561936daf1..af62e17442b 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -3437,6 +3437,148 @@ save_descriptor_data (tree descr, tree data)
}
+/* Type of the DATA argument passed to walk_tree by substitute_subexpr_in_expr
+ and used by maybe_substitute_expr. */
+
+typedef struct
+{
+ tree target, repl;
+}
+substitute_t;
+
+
+/* Check if the expression in *TP is equal to the substitution target provided
+ in DATA->TARGET and replace it with DATA->REPL in that case. This is a
+ callback function for use with walk_tree. */
+
+static tree
+maybe_substitute_expr (tree *tp, int *walk_subtree, void *data)
+{
+ substitute_t *subst = (substitute_t *) data;
+ if (*tp == subst->target)
+{
+ *tp = subst->repl;
+ *walk_subtree = 0;
+}
+
+ return NULL_TREE;
+}
+
+
+/* Substitute in EXPR any occurence of TARGET with REPLACEMENT. */
+
+static void
+substitute_subexpr_in_expr (tree target, tree replacement, tree expr)
+{
+ substitute_t subst;
+ subst.target = target;
+ subst.repl = replacement;
+
+ walk_tree (&expr, maybe_substitute_expr, &subst, nullptr);
+}
+
+
+/* Save the descriptor reference VALUE to storage pointed by DESC_PTR. Before
+ that, try to factor subexpressions of VALUE to variables, adding extra code
+ to BLOCK.
+
+ The candidate references to factoring are dereferenced pointers because they
+ are cheap to copy and array descriptors because they are often the base of
+ multiple subreferences.*/
+
+static void
+set_factored_descriptor_value (tree *desc_ptr, tree value, stmtblock_t *block)
+{
+ /* As the reference is processed from outer to inner, variable definitions
+ will be generated in reversed order, so can't be put directly in BLOCK.
+ We use TMP_BLOCK instead. */
+ stmtblock_t tmp_block;
+ tree accumulated_code = NULL_TREE;
+
+ gfc_init_block (&tmp_block);
+
+ /* The current candidate to factoring. */
+ tree saveable_ref = NULL_TREE;
+
+ /* The root expressions in which we look for subexpressions to replace with
+ variables. */
+ auto_vec replacement_roots;
+ replacement_roots.safe_push (value);
+
+ tree data_ref = value;
+ tree next_ref = NULL_TREE;
+
+ /* If the candidate reference is not followed by a subreference, it can't be
+ saved to a variable as it may be reallocatable, and we have to keep the
+ parent reference to be able to store the new pointer value in case of
+ reallocation. */
+ bool maybe_reallocatable = true;
+
+ while (true)
+{
+ if (!maybe_reallocatable
+ && GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (data_ref)))
+ saveable_ref = data_ref;
+
+ if (TREE_CODE (data_ref) == INDIRECT_REF)
+ {
+ next_ref = TREE_OPERAND (data_ref, 0);
+
+ if (!maybe_reallocatable)
+ {
+ /* Don't evaluate the pointer to a variable yet; do it only if the
+ variable would be significantly more simple than the reference
+ it replaces. That is if the reference contains anything
+ different from NOPs, COMPONENTs and DECLs. */
+ saveable_ref = next_ref;
+ }
+ }
+ else if (TREE_CODE (data_ref) == COMPONENT_REF)
+ {
+ maybe_reallocatable = false;
+ next_ref = TREE_OPERAND (data_ref, 0);
+ }
+ else if (TREE_CODE (data_ref) == NOP_EXPR)
+ next_ref = TREE_OPERAND (data_ref, 0);
+ else
+ {
+ if (DECL_P (data_ref))
+ break;
+
+ if (TREE_CODE (data_ref) == ARRAY_REF)
+ {
+ maybe_reallocatable = false;
+ next_ref = TREE_OPERAND (data_ref, 0);
+ }
+
+ if (saveable_ref != NULL_TREE)
+ {
+ /* We have seen a reference worth saving. Do it now. */
+ tree var = gfc_evaluate_now
[PATCH] i386: Remove KEYLOCKER related feature since Panther Lake and Clearwater Forest
Hi all, According to July 2025 SDM, Key locker will no longer be supported on hardware 2025 onwards. This means for Panther Lake and Clearwater Forest, the feature will not be enabled. Remove them from those two platforms. Ok for trunk and backport to GCC14/15? Thx, Haochen gcc/ChangeLog: * config/i386/i386.h (PTA_PANTHERLAKE): Revmoe KL and WIDEKL. (PTA_CLEARWATERFOREST): Ditto. * doc/invoke.texi: Revise documentation. --- gcc/config/i386/i386.h | 9 + gcc/doc/invoke.texi| 12 ++-- 2 files changed, 11 insertions(+), 10 deletions(-) diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h index 3f7ad68db3a..bfc6c6f3507 100644 --- a/gcc/config/i386/i386.h +++ b/gcc/config/i386/i386.h @@ -2465,10 +2465,11 @@ constexpr wide_int_bitmask PTA_ARROWLAKE = PTA_ALDERLAKE | PTA_AVXIFMA | PTA_AVXVNNIINT8 | PTA_AVXNECONVERT | PTA_CMPCCXADD | PTA_UINTR; constexpr wide_int_bitmask PTA_ARROWLAKE_S = PTA_ARROWLAKE | PTA_AVXVNNIINT16 | PTA_SHA512 | PTA_SM3 | PTA_SM4; -constexpr wide_int_bitmask PTA_CLEARWATERFOREST = PTA_SIERRAFOREST - | PTA_AVXVNNIINT16 | PTA_SHA512 | PTA_SM3 | PTA_SM4 | PTA_USER_MSR - | PTA_PREFETCHI; -constexpr wide_int_bitmask PTA_PANTHERLAKE = PTA_ARROWLAKE_S | PTA_PREFETCHI; +constexpr wide_int_bitmask PTA_CLEARWATERFOREST = + (PTA_SIERRAFOREST & (~(PTA_KL | PTA_WIDEKL))) | PTA_AVXVNNIINT16 | PTA_SHA512 + | PTA_SM3 | PTA_SM4 | PTA_USER_MSR | PTA_PREFETCHI; +constexpr wide_int_bitmask PTA_PANTHERLAKE = + (PTA_ARROWLAKE_S & (~(PTA_KL | PTA_WIDEKL))) | PTA_PREFETCHI; constexpr wide_int_bitmask PTA_DIAMONDRAPIDS = PTA_GRANITERAPIDS_D | PTA_AVXIFMA | PTA_AVXNECONVERT | PTA_AVXVNNIINT16 | PTA_AVXVNNIINT8 | PTA_CMPCCXADD | PTA_SHA512 | PTA_SM3 | PTA_SM4 | PTA_AVX10_2 diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 74f5ee26042..9fc00cad82a 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -34886,9 +34886,9 @@ Intel Panther Lake CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL, RDRND, XSAVE, XSAVEC, XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX, GFNI-SSE, CLWB, MOVDIRI, MOVDIR64B, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C, FMA, LZCNT, PCONFIG, PKU, -VAES, VPCLMULQDQ, SERIALIZE, HRESET, KL, WIDEKL, AVX-VNNI, UINTR, AVXIFMA, -AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, AVXVNNIINT16, SHA512, SM3, SM4 and -PREFETCHI instruction set support. +VAES, VPCLMULQDQ, SERIALIZE, HRESET, AVX-VNNI, UINTR, AVXIFMA, AVXVNNIINT8, +AVXNECONVERT, CMPCCXADD, AVXVNNIINT16, SHA512, SM3, SM4 and PREFETCHI +instruction set support. @item sapphirerapids @itemx emeraldrapids @@ -34991,9 +34991,9 @@ Intel Clearwater Forest CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL, RDRND, XSAVE, XSAVEC, XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX, GFNI-SSE, CLWB, MOVDIRI, MOVDIR64B, CLDEMOTE, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C, FMA, -LZCNT, PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, KL, WIDEKL, AVX-VNNI, -ENQCMD, UINTR, AVXIFMA, AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, AVXVNNIINT16, -SHA512, SM3, SM4, USER_MSR and PREFETCHI instruction set support. +LZCNT, PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, AVX-VNNI, ENQCMD, +UINTR, AVXIFMA, AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, AVXVNNIINT16, SHA512, +SM3, SM4, USER_MSR and PREFETCHI instruction set support. @item k6 AMD K6 CPU with MMX instruction set support. -- 2.31.1
Re: [PATCH] libstdc++: Do not use list-initialization in std::span members [PR120997]
On Tue, Jul 8, 2025 at 11:46 PM Jonathan Wakely wrote:
> As the bug report shows, for span the return statements of
> the form `return {data(), count};` will use the new C++26 constructor,
> span(initializer_list).
>
> Although the conversions from data() to bool and count to bool are
> narrowing and should be ill-formed, in system headers the narrowing
> diagnostics are suppressed. In any case, even if the compiler diagnosed
> them as ill-formed, we still don't want the initializer_list constructor
> to be used. We want to use the span(element_type*, size_t) constructor
> instead.
>
> Replace the braced-init-list uses with S(data(), count) where S is the
> correct return type. We need to make similar changes in the C++26
> working draft, which will be taken care of via an LWG issue.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/120997
> * include/std/span (span::first, span::last, span::subspan): Do
> not use braced-init-list for return statements.
> * testsuite/23_containers/span/120997.cc: New test.
> ---
>
> Tested x86_64-linux.
>
LGTM.
>
> libstdc++-v3/include/std/span | 15 +++---
> .../testsuite/23_containers/span/120997.cc| 46 +++
> 2 files changed, 54 insertions(+), 7 deletions(-)
> create mode 100644 libstdc++-v3/testsuite/23_containers/span/120997.cc
>
> diff --git a/libstdc++-v3/include/std/span b/libstdc++-v3/include/std/span
> index 5629a71b9bd2..44f9b36a7efe 100644
> --- a/libstdc++-v3/include/std/span
> +++ b/libstdc++-v3/include/std/span
> @@ -376,7 +376,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> else
> static_assert(_Count <= extent);
> using _Sp = span;
> - return _Sp{ _SizedPtr{this->data()} };
> + return _Sp(_SizedPtr{this->data()});
> }
>
>[[nodiscard]]
> @@ -384,7 +384,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>first(size_type __count) const noexcept
>{
> __glibcxx_assert(__count <= size());
> - return { this->data(), __count };
> + return span(this->data(), __count);
>}
>
>template
> @@ -397,7 +397,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> else
> static_assert(_Count <= extent);
> using _Sp = span;
> - return _Sp{ _SizedPtr{this->data() + (this->size() - _Count)} };
> + return _Sp(_SizedPtr{this->data() + (this->size() - _Count)});
> }
>
>[[nodiscard]]
> @@ -405,7 +405,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>last(size_type __count) const noexcept
>{
> __glibcxx_assert(__count <= size());
> - return { this->data() + (this->size() - __count), __count };
> + return span(this->data() + (this->size() - __count),
> + __count);
>}
>
>template
> @@ -424,7 +425,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> using _Sp = span _Count>()>;
>
> if constexpr (_Count == dynamic_extent)
> - return _Sp{ this->data() + _Offset, this->size() - _Offset };
> + return _Sp(this->data() + _Offset, this->size() - _Offset);
> else
> {
> if constexpr (_Extent == dynamic_extent)
> @@ -437,7 +438,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> static_assert(_Count <= extent);
> static_assert(_Count <= (extent - _Offset));
> }
> - return _Sp{ _SizedPtr{this->data() + _Offset} };
> + return _Sp(_SizedPtr{this->data() + _Offset});
> }
> }
>
> @@ -454,7 +455,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> __glibcxx_assert(__count <= size());
> __glibcxx_assert(__offset + __count <= size());
> }
> - return {this->data() + __offset, __count};
> + return span(this->data() + __offset, __count);
>}
>
> private:
> diff --git a/libstdc++-v3/testsuite/23_containers/span/120997.cc
> b/libstdc++-v3/testsuite/23_containers/span/120997.cc
> new file mode 100644
> index ..fbf194c87388
> --- /dev/null
> +++ b/libstdc++-v3/testsuite/23_containers/span/120997.cc
> @@ -0,0 +1,46 @@
> +// { dg-do run { target c++26 } }
> +
> +#include
> +#include
> +
> +void
> +test_first()
> +{
> + bool arr[5];
> + std::span s(arr);
> + std::span s2 = s.first(5);
> + VERIFY( s2.data() == s.data() );
> + std::span s3 = s.first<5>();
> + VERIFY( s3.data() == s.data() );
> +}
> +
> +void
> +test_last()
> +{
> + bool arr[5];
> + std::span s(arr);
> + std::span s2 = s.last(5);
> + VERIFY( s2.data() == s.data() );
> + std::span s3 = s.last<5>();
> + VERIFY( s3.data() == s.data() );
> +}
> +
> +void
> +test_subspan()
> +{
> + bool arr[5];
> + std::span s(arr);
> + std::span s2 = s.subspan(0, 5);
> + VERIFY( s2.data() == s.data() );
> + std::span s3 = s.subspan<0>();
> + VERIFY( s3.data() == s.data() );
> + std::span s4 = s.subspan<0, 5>();
> + VERIFY( s4.data() == s.data() );
> +}
> +
> +int main()
[r16-2197 Regression] FAIL: g++.dg/torture/pr58552.C -Os (test for excess errors) on Linux/x86_64
On Linux/x86_64,
385d9937f0e23cbf9c62f0b2553a33ff70e56ecf is the first bad commit
commit 385d9937f0e23cbf9c62f0b2553a33ff70e56ecf
Author: Jan Hubicka
Date: Fri Jul 11 13:01:13 2025 +0200
Rewrite assign_discriminators
caused
FAIL: c-c++-common/torture/pr116156-1.c -O1 (test for excess errors)
FAIL: c-c++-common/torture/pr116156-1.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none (test for excess errors)
FAIL: c-c++-common/torture/pr116156-1.c -O2 (test for excess errors)
FAIL: c-c++-common/torture/pr116156-1.c -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess
errors)
FAIL: c-c++-common/torture/pr116156-1.c -O3 -g (test for excess errors)
FAIL: c-c++-common/torture/pr116156-1.c -Os (test for excess errors)
FAIL: g++.dg/torture/pr58552.C -O1 (test for excess errors)
FAIL: g++.dg/torture/pr58552.C -O2 -flto -fno-use-linker-plugin
-flto-partition=none (test for excess errors)
FAIL: g++.dg/torture/pr58552.C -O2 (test for excess errors)
FAIL: g++.dg/torture/pr58552.C -O3 -g (test for excess errors)
FAIL: g++.dg/torture/pr58552.C -Os (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/export/users3/haochenj/src/gcc-bisect/master/master/r16-2197/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg-torture.exp=c-c++-common/torture/pr116156-1.c
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg-torture.exp=c-c++-common/torture/pr116156-1.c
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg-torture.exp=c-c++-common/torture/pr116156-1.c
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg-torture.exp=c-c++-common/torture/pr116156-1.c
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg-torture.exp=g++.dg/torture/pr58552.C
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg-torture.exp=g++.dg/torture/pr58552.C
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg-torture.exp=g++.dg/torture/pr58552.C
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg-torture.exp=g++.dg/torture/pr58552.C
--target_board='unix{-m64\ -march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at haochen dot jiang at intel.com.)
(If you met problems with cascadelake related, disabling AVX512F in command
line might save that.)
(However, please make sure that there is no potential problems with AVX512.)
RE: [PATCH] i386: Remove KEYLOCKER related feature since Panther Lake and Clearwater Forest
> -Original Message- > From: Jiang, Haochen > Sent: Monday, July 14, 2025 10:59 AM > To: gcc-patches@gcc.gnu.org > Cc: Liu, Hongtao ; ubiz...@gmail.com > Subject: [PATCH] i386: Remove KEYLOCKER related feature since Panther Lake > and Clearwater Forest > > Hi all, > > According to July 2025 SDM, Key locker will no longer be supported on > hardware 2025 onwards. This means for Panther Lake and Clearwater Forest, > the feature will not be enabled. Remove them from those two platforms. > > Ok for trunk and backport to GCC14/15? Ok. > > Thx, > Haochen > > gcc/ChangeLog: > > * config/i386/i386.h (PTA_PANTHERLAKE): Revmoe KL and WIDEKL. > (PTA_CLEARWATERFOREST): Ditto. > * doc/invoke.texi: Revise documentation. > --- > gcc/config/i386/i386.h | 9 + > gcc/doc/invoke.texi| 12 ++-- > 2 files changed, 11 insertions(+), 10 deletions(-) > > diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h index > 3f7ad68db3a..bfc6c6f3507 100644 > --- a/gcc/config/i386/i386.h > +++ b/gcc/config/i386/i386.h > @@ -2465,10 +2465,11 @@ constexpr wide_int_bitmask PTA_ARROWLAKE = > PTA_ALDERLAKE | PTA_AVXIFMA >| PTA_AVXVNNIINT8 | PTA_AVXNECONVERT | PTA_CMPCCXADD | > PTA_UINTR; constexpr wide_int_bitmask PTA_ARROWLAKE_S = > PTA_ARROWLAKE | PTA_AVXVNNIINT16 >| PTA_SHA512 | PTA_SM3 | PTA_SM4; > -constexpr wide_int_bitmask PTA_CLEARWATERFOREST = PTA_SIERRAFOREST > - | PTA_AVXVNNIINT16 | PTA_SHA512 | PTA_SM3 | PTA_SM4 | > PTA_USER_MSR > - | PTA_PREFETCHI; > -constexpr wide_int_bitmask PTA_PANTHERLAKE = PTA_ARROWLAKE_S | > PTA_PREFETCHI; > +constexpr wide_int_bitmask PTA_CLEARWATERFOREST = > + (PTA_SIERRAFOREST & (~(PTA_KL | PTA_WIDEKL))) | PTA_AVXVNNIINT16 | > +PTA_SHA512 > + | PTA_SM3 | PTA_SM4 | PTA_USER_MSR | PTA_PREFETCHI; constexpr > +wide_int_bitmask PTA_PANTHERLAKE = > + (PTA_ARROWLAKE_S & (~(PTA_KL | PTA_WIDEKL))) | PTA_PREFETCHI; > constexpr wide_int_bitmask PTA_DIAMONDRAPIDS = > PTA_GRANITERAPIDS_D >| PTA_AVXIFMA | PTA_AVXNECONVERT | PTA_AVXVNNIINT16 | > PTA_AVXVNNIINT8 >| PTA_CMPCCXADD | PTA_SHA512 | PTA_SM3 | PTA_SM4 | PTA_AVX10_2 > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index > 74f5ee26042..9fc00cad82a 100644 > --- a/gcc/doc/invoke.texi > +++ b/gcc/doc/invoke.texi > @@ -34886,9 +34886,9 @@ Intel Panther Lake CPU with 64-bit extensions, > MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, > PREFETCHW, PCLMUL, RDRND, XSAVE, XSAVEC, XSAVES, XSAVEOPT, > FSGSBASE, PTWRITE, RDPID, SGX, GFNI-SSE, CLWB, MOVDIRI, MOVDIR64B, > WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C, FMA, LZCNT, PCONFIG, PKU, - > VAES, VPCLMULQDQ, SERIALIZE, HRESET, KL, WIDEKL, AVX-VNNI, UINTR, > AVXIFMA, -AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, AVXVNNIINT16, > SHA512, SM3, SM4 and -PREFETCHI instruction set support. > +VAES, VPCLMULQDQ, SERIALIZE, HRESET, AVX-VNNI, UINTR, AVXIFMA, > +AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, AVXVNNIINT16, SHA512, > SM3, SM4 > +and PREFETCHI instruction set support. > > @item sapphirerapids > @itemx emeraldrapids > @@ -34991,9 +34991,9 @@ Intel Clearwater Forest CPU with 64-bit > extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, > AES, PREFETCHW, PCLMUL, RDRND, XSAVE, XSAVEC, XSAVES, XSAVEOPT, > FSGSBASE, PTWRITE, RDPID, SGX, GFNI-SSE, CLWB, MOVDIRI, MOVDIR64B, > CLDEMOTE, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C, FMA, -LZCNT, > PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, KL, WIDEKL, AVX- > VNNI, -ENQCMD, UINTR, AVXIFMA, AVXVNNIINT8, AVXNECONVERT, > CMPCCXADD, AVXVNNIINT16, -SHA512, SM3, SM4, USER_MSR and > PREFETCHI instruction set support. > +LZCNT, PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, AVX-VNNI, > +ENQCMD, UINTR, AVXIFMA, AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, > +AVXVNNIINT16, SHA512, SM3, SM4, USER_MSR and PREFETCHI instruction > set support. > > @item k6 > AMD K6 CPU with MMX instruction set support. > -- > 2.31.1
Re: [PATCH] aarch64: Implement sme2+faminmax extension.
On 09/07/2025 09:28, Kyrylo Tkachov wrote: Hi Alfie, On 7 Jul 2025, at 10:46, Alfie Richards wrote: Hello all, This patch implements the couple of amin/amax instructions that are part of SME2 + faminmax. Regression testsed and bootstrapped for Aarch64. Thanks, Alfie -- >8 -- Implements the sme2+faminmax svamin and svamax intrinsics. gcc/ChangeLog: * config/aarch64/aarch64-sme.md (@aarch64_sme_): New patterns. * config/aarch64/aarch64-sve-builtins-sme.def (svamin): New intrinsics. (svamax): New intrinsics. * config/aarch64/aarch64-sve-builtins-sve2.cc (class faminmaximpl): New class. (svamin): New function. (svamax): New function. +#define REQUIRED_EXTENSIONS streaming_only (AARCH64_FL_SME2) Do these also need an FAMINMAX guard? Looks ok to me otherwise. Thanks, Kyrill Hi Kyrill, Ah yes they do, thank you! Fixed and committed. Thanks, Alfie +DEF_SME_FUNCTION_GS (svamin, binary_opt_single_n, all_float, x24, none) +DEF_SME_FUNCTION_GS (svamax, binary_opt_single_n, all_float, x24, none) +#undef REQUIRED_EXTENSIONS
Re: [PATCH v4 0/6] Implement mdspan.
Hi Luc,
While running the libc++ test on libstdc++ we have found the following
issue in our implementation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121061
Would you be interested in looking into fixing this?
Also, libc++ makes the default constructor of mdpsan conditionally noexcept
as extension
(standard does not require it
https://eel.is/c++draft/views.multidim#mdspan.mdspan.cons).
We could do the same. Instead of writing a big conditional noexcept
specification, I would suggest
defaultint the constructor on first declaration:
constexpr
mdspan()
requires (rank_dynamic() > 0)
&& is_default_constructible_v
&& is_default_constructible_v
&& is_default_constructible_v
= default;
And then having default member initializers:
private:
[[no_unique_address]] accessor_type _M_accessor = accessor_type();
[[no_unique_address]] mapping_type _M_mapping = mapping_type();
[[no_unique_address]] data_handle_type _M_handle = data_handle_type();
We do not want to use "{}" as the samantis is a bit differnt.
Regards,
Tomasz
On Tue, Jul 8, 2025 at 3:44 PM Tomasz Kaminski wrote:
> All patches were merged. I will double check that we got all the papers
> listed and the issue, and close it.
> Thanks again for your submissions.
>
> On Tue, Jul 8, 2025 at 10:26 AM Luc Grosheintz
> wrote:
>
>> Patches 1/5 ... 4/5 aren't sent because corresponding commits from v3
>> should be used. The changes for 5/5 are:
>>
>> * Fix ADL issue in swap and create tests.
>> * Replace pragma once with include guard in layout_like.h.
>> * Use VERIFY(md.empty()) when checking value initialization.
>>
>> Since the code for swap is identical for all three members of mdspan,
>> this commit intentionally checks that the accessor is ADL swappable, but
>> not the other two memebers. Doing so allows us to have a single, short
>> class purely dedicated to ADL. Otherwise we'd need to put OpaqueLayout
>> and LayoutLike into a namespace and add ADL related logic. I tried it
>> and wasn't too happy with the result. This felt shorter, more directly
>> to the point while still checking that the implemented swap function
>> allows ADL for swapping all members variables. I tested effectiveness
>> of the test by reverting the fix and making sure the test fails.
>>
>> This version of the patch series also adds the commit to update the
>> FTM. The changes are:
>>
>> * Update the commit message to mention the related ticket.
>> * Rename the file.
>> * Implement a more verbose version of the test.
>>
>> Luc Grosheintz (6):
>> libstdc++: Check prerequisites of layout_*::operator().
>> libstdc++: Check prerequisite of extents::extents.
>> libstdc++: Restructure mdspan tests to reuse IntLike.
>> libstdc++: Implement __mdspan::__size.
>> libstdc++: Implement mdspan and tests [PR107761].
>> libstdc++: Set FMT for complete C++23 mdspan [PR107761].
>>
>> libstdc++-v3/include/bits/version.def | 3 +-
>> libstdc++-v3/include/bits/version.h | 3 +-
>> libstdc++-v3/include/std/mdspan | 315 -
>> libstdc++-v3/src/c++23/std.cc.in | 3 +-
>> .../23_containers/mdspan/class_mandate_neg.cc | 41 ++
>> .../mdspan/extents/class_mandates_neg.cc | 2 +
>> .../mdspan/extents/custom_integer.cc | 27 +-
>> .../mdspan/extents/extents_mismatch_neg.cc| 35 +
>> .../23_containers/mdspan/extents/int_like.h | 28 +
>> .../testsuite/23_containers/mdspan/ftm.cc | 9 +
>> .../23_containers/mdspan/layout_like.h| 83 +++
>> .../mdspan/layouts/debug/out_of_bounds_neg.cc | 30 +
>> .../testsuite/23_containers/mdspan/mdspan.cc | 643 ++
>> .../23_containers/mdspan/out_of_bounds_neg.cc | 24 +
>> 14 files changed, 1212 insertions(+), 34 deletions(-)
>> create mode 100644
>> libstdc++-v3/testsuite/23_containers/mdspan/class_mandate_neg.cc
>> create mode 100644
>> libstdc++-v3/testsuite/23_containers/mdspan/extents/extents_mismatch_neg.cc
>> create mode 100644
>> libstdc++-v3/testsuite/23_containers/mdspan/extents/int_like.h
>> create mode 100644 libstdc++-v3/testsuite/23_containers/mdspan/ftm.cc
>> create mode 100644
>> libstdc++-v3/testsuite/23_containers/mdspan/layout_like.h
>> create mode 100644
>> libstdc++-v3/testsuite/23_containers/mdspan/layouts/debug/out_of_bounds_neg.cc
>> create mode 100644 libstdc++-v3/testsuite/23_containers/mdspan/mdspan.cc
>> create mode 100644
>> libstdc++-v3/testsuite/23_containers/mdspan/out_of_bounds_neg.cc
>>
>> --
>> 2.49.0
>>
>>
