[COMMITTED 17/31] ada: Avoid conversion from String to Name_Id at runtime

2025-01-07 Thread Marc Poulhiès
From: Piotr Trojanek 

Code cleanup.

gcc/ada/ChangeLog:

* sem_prag.adb (Analyze_Attribute): Replace runtime conversion
with existing constant.

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

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

diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
index 64b5b01869d..defa0d78794 100644
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -14791,7 +14791,7 @@ package body Sem_Prag is
 GNAT_Pragma;
 Check_Valid_Configuration_Pragma;
 Check_Arg_Count (1);
-Check_Optional_Identifier (Arg1, "max_size");
+Check_Optional_Identifier (Arg1, Name_Max_Size);
 
 Arg := Get_Pragma_Arg (Arg1);
 Check_Arg_Is_OK_Static_Expression (Arg, Any_Integer);
-- 
2.43.0



[COMMITTED 02/31] ada: Preserve Warning_Doc_Switch in gnatprove invocation

2025-01-07 Thread Marc Poulhiès
From: Johannes Kanig 

When invoked by gnat2why, the Warning_Doc_Switch was unintenionally
reset.

gcc/ada/ChangeLog:

* gnat1drv.adb: (SPARK_Library_Warning): preserve Warning_Doc_Switch

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

---
 gcc/ada/gnat1drv.adb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gcc/ada/gnat1drv.adb b/gcc/ada/gnat1drv.adb
index 120de4afb71..39aa89c43a3 100644
--- a/gcc/ada/gnat1drv.adb
+++ b/gcc/ada/gnat1drv.adb
@@ -523,6 +523,8 @@ procedure Gnat1drv is
  Restore_Warnings
((Warnings_Package.Elab_Warnings => True,
  Warnings_Package.Warn_On_Suspicious_Contract => True,
+ Warnings_Package.Warning_Doc_Switch =>
+   Warnsw.Warning_Doc_Switch,
  others => False));
 
  --  Suppress the generation of name tables for enumerations, which are
-- 
2.43.0



[COMMITTED 16/31] ada: Untangle check for restriction No_Implementation_Attributes

2025-01-07 Thread Marc Poulhiès
From: Piotr Trojanek 

Code cleanup; given that no attribute is both defined by Ada 83 and specific to
GNAT, the semantics is unaffected.

gcc/ada/ChangeLog:

* sem_attr.adb (Analyze_Attribute): Simplify logic.

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

---
 gcc/ada/sem_attr.adb | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/gcc/ada/sem_attr.adb b/gcc/ada/sem_attr.adb
index 53b96501d78..39725d23442 100644
--- a/gcc/ada/sem_attr.adb
+++ b/gcc/ada/sem_attr.adb
@@ -3214,26 +3214,23 @@ package body Sem_Attr is
 
  --  Deal with Ada 83 issues
 
- if not Attribute_83 (Attr_Id) then
-if Ada_Version = Ada_83 then
-   Error_Msg_Name_1 := Aname;
-   Error_Msg_N ("(Ada 83) attribute% is not standard??", N);
-end if;
-
-if Attribute_Impl_Def (Attr_Id) then
-   Check_Restriction (No_Implementation_Attributes, N);
-end if;
+ if not Attribute_83 (Attr_Id) and then Ada_Version = Ada_83 then
+Error_Msg_Name_1 := Aname;
+Error_Msg_N ("(Ada 83) attribute% is not standard??", N);
  end if;
 
  --  Deal with Ada 2005 attributes that are implementation attributes
  --  because they appear in a version of Ada before Ada 2005, ditto for
  --  Ada 2012 and Ada 2022 attributes appearing in an earlier version.
+ --  Likewise for GNAT implementation-defined attributes.
 
  if (Attribute_05 (Attr_Id) and then Ada_Version < Ada_2005)
or else
 (Attribute_12 (Attr_Id) and then Ada_Version < Ada_2012)
or else
 (Attribute_22 (Attr_Id) and then Ada_Version < Ada_2022)
+   or else
+Attribute_Impl_Def (Attr_Id)
  then
 Check_Restriction (No_Implementation_Attributes, N);
  end if;
-- 
2.43.0



[COMMITTED 29/31] ada: Drop g-cpp* units not needed by the compiler

2025-01-07 Thread Marc Poulhiès
From: Alexandre Oliva 

Having moved __gnat_convert_caught_object to g-cstyin.o, we can drop
other g-cpp* units that are now needed by programs that actually use
their APIs to get more information about C++ exceptions and type_info
objects.

gcc/ada/ChangeLog:

* gcc-interface/Make-lang.in (GNAT_ADA_OBJS, GNATBIND_OBJS):
Drop g-cpp, g-cppexc and g-cppstd.

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

---
 gcc/ada/gcc-interface/Make-lang.in | 6 --
 1 file changed, 6 deletions(-)

diff --git a/gcc/ada/gcc-interface/Make-lang.in 
b/gcc/ada/gcc-interface/Make-lang.in
index b0c568ad60b..1fefd6aa31f 100644
--- a/gcc/ada/gcc-interface/Make-lang.in
+++ b/gcc/ada/gcc-interface/Make-lang.in
@@ -513,9 +513,6 @@ GNAT_ADA_OBJS+= \
  ada/libgnat/a-numeri.o\
  ada/libgnat/ada.o \
  ada/libgnat/g-byorma.o\
- ada/libgnat/g-cpp.o   \
- ada/libgnat/g-cppexc.o\
- ada/libgnat/g-cppstd.o\
  ada/libgnat/g-cstyin.o\
  ada/libgnat/g-heasor.o\
  ada/libgnat/g-htable.o\
@@ -697,9 +694,6 @@ GNATBIND_OBJS +=  \
  ada/libgnat/a-numeri.o   \
  ada/libgnat/ada.o\
  ada/libgnat/g-byorma.o   \
- ada/libgnat/g-cpp.o  \
- ada/libgnat/g-cppexc.o   \
- ada/libgnat/g-cppstd.o   \
  ada/libgnat/g-cstyin.o   \
  ada/libgnat/g-hesora.o   \
  ada/libgnat/g-htable.o   \
-- 
2.43.0



RE: [PATCH] COBOL 3/8 gen: GENERIC interface

2025-01-07 Thread Richard Biener
On Mon, 23 Dec 2024, Robert Dubner wrote:

> Richard, a bunch of things you address are in my bailwick.
> 
> When Jim and I set out to create a COBOL front end, I knew *NOTHING*
> about, well, anything vis-à-vis GCC.  I barely knew how it worked.  Some
> things I had to figure out even before I knew how to figure anything outl
> notably, creating functions.  Creating a function was practically the
> first thing I had to do, and I spent a bunch of time trapping through GCC
> compiling simple functions to devine how it might be done.  By definition,
> I simply did not know what I was doing, and learned as I went.

I guess that's expected - we always hope people doing new frontends
have spare time left to fill gaps in documentation with knowledge
they gained ;)  Or maybe write a blog post about how to do a new
GCC frontend (there are multiple such for backends).  But I know time
is scarce.

> So, if there are peculiarities, that's probably why.  And I am going to
> eagerly go through this message, and others, to apply the knowledge you
> are conveying; I am in a far better position to understand what you are
> saying than I would have been three years ago.



> 
> > -Original Message-
> > From: Richard Biener 
> > Sent: Sunday, December 22, 2024 07:18
> > To: jklow...@symas.com
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH] COBOL 3/8 gen: GENERIC interface
> >
> >
> > (sorry for breaking threading, but quoting the whole mail made my MUA
> > unbearably slow)
> >
> > From 64bcb34e12371f61a8958645e1668e0ac2704391gen.patch 4 Oct 2024
> 12:01:22
> > -0400
> > From: "James K. Lowden" 
> > Date: Thu 12 Dec 2024 06:28:07 PM EST
> > Subject: [PATCH]  Add 'cobol' to 4 files
> >
> > gcc/cobol/ChangeLog
> > * genapi.cc: New file.
> > * gengen.cc: New file.
> > * genmath.cc: New file.
> > * genutil.cc: New file.
> >
> >
> > I'm skimming over this part of the frontend, taking notes on general
> > things I notice, partly quoting parts of the patch
> >
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "config.h"
> > +#include "system.h"
> >
> > all system headers need to be included by system.h, C++ includes should
> be
> > included by defining INCLUDE_UNORDERED_MAP and INCLUDE_UNORDERED_SET,
> etc.
> > - includes definitely have to come after including config.h
> 
> I now see that many of the front ends seem to have their own lang-system.h
> that wraps the gcc/system.h.  Under the assumption that the recently-added
> GO and RUST are doing that in an acceptable fashion, I will model that
> behavior.

Sounds good to me.

> >
> > +//#define XXX do{gg_printf("LINE %d\n", build_int_cst_type(INT,
> > __LINE__), NULL_TREE);}while(0);
> > +#define XXX
> > ...
> > +bool bSHOW_PARSE = getenv("SHOW_PARSE");
> >
> > there seems to be debugging wired in - at least the getenv call above
> > should probably be be behind a more global COBOL_DEBUG conditional?
> > There's a langhook for frontend initialization - that's a convenient
> place
> > to conditionally (re-)initialize bSHOW_PARSE (when you default it to
> > false).
> >
> > +  // One strongly suspects, one does, that creating the constructor one
> > + // character at a time isn't the best possible way of accomplishing
> > + the  // desired goal. But I lost interest in trying to find a better
> > way.
> > +  TYPE_NAME(array_of_characters) = get_identifier("cblc_string");  tree
> > + constr = make_node(CONSTRUCTOR);
> > +  TREE_TYPE(constr) = array_of_characters;
> >
> > indeed, you should be able to use build_string (strlen(var_contents)+1,
> > var_contents) and use that as DECL_INTIIAL (it builds a STRING_CST
> node).
> 
> That worked, thank you.
> 
> >
> > +tree
> > +gg_fprintf(tree fd, int nargs, const char *format_string, ...)
> > +  {
> > ...
> > +  tree stmt = build_call_array_loc (location_from_lineno(),
> > +INT,
> > +function,
> > +argc,
> > +args);
> >
> > instead of constructing args[] you should be able to directly call
> > build_call_valist () with the va_list.
> >
> 
> In this case, I don't see how to use build_call_valist ().
> 
> gg_fprintf() takes a format_string and 'nargs' following arguments. It
> then builds a call to
> 
> sprintf (buffer, format_string,  
> I don't see how to pass 'format string' to build_call_valist ().

Ah, true ... it isn't possible to expand an existing va_list.
I suppose exporting build_call_1 or simply open-coding what it does
would allow to elide the local array though (it's mainly the
artificial limit that had bugged me)

> > You seem to, in function_decl_from_name or gg_get_function_address,
> build
> > function decls for externs, mainly from the C library.  Elsewhere we are
> > using what GCC calls 

Re: [PATCH v1 1/4] Match: Refactor the signed SAT_SUB match patterns [NFC]

2025-01-07 Thread Jeff Law




On 1/6/25 7:47 PM, Li, Pan2 wrote:

Kindly ping for the series>
Pan

-Original Message-
From: Li, Pan2
Sent: Monday, December 23, 2024 3:09 PM
To: gcc-patches@gcc.gnu.org
Cc: richard.guent...@gmail.com; tamar.christ...@arm.com; juzhe.zh...@rivai.ai; 
kito.ch...@gmail.com; jeffreya...@gmail.com; rdapp@gmail.com
Subject: RE: [PATCH v1 1/4] Match: Refactor the signed SAT_SUB match patterns 
[NFC]

Kindly ping for this series, and Merry Christmas!

Pan

-Original Message-
From: Li, Pan2 
Sent: Thursday, December 12, 2024 4:42 PM
To: gcc-patches@gcc.gnu.org
Cc: richard.guent...@gmail.com; tamar.christ...@arm.com; juzhe.zh...@rivai.ai; 
kito.ch...@gmail.com; jeffreya...@gmail.com; rdapp@gmail.com; Li, Pan2 

Subject: [PATCH v1 1/4] Match: Refactor the signed SAT_SUB match patterns [NFC]

From: Pan Li 

This patch would like to refactor the all signed SAT_ADD patterns,
aka:
* Extract type check outside.
* Re-arrange the related match pattern forms together.

The below test suites are passed for this patch.
* The rv64gcv fully regression test.
* The x86 bootstrap test.
* The x86 fully regression test.

gcc/ChangeLog:

* match.pd: Refactor sorts of signed SAT_SUB match patterns.

OK for the trunk.  Sorry for the delay.

jeff



[Patch] libgomp.texi: Minor update to omp_get_num_devices/omp_get_initial_device

2025-01-07 Thread Tobias Burnus

OpenMP 6 changed that omp_get_initial_device may not only return the
dynamic value of omp_get_num_devices() but also the constant value
omp_get_num_devices (== -1).

For now, GCC returns omp_get_num_devices() but we may want to change
this in the future as '-1' can be solved at compile time; in particular,
omp_get_device_num is also permitted to return -1 (= the value returned
by omp_get_initial_device), which might be more useful.
(I wouldn't be surprised if code will break if we start to return -1.)

Additionally, I tweaked the wording for omp_get_num_devices to be
a bit clearer and updatedomp_get_default_device as it is no longer the same as 
omp_get_num_devices.

Comments/suggestions before I commit it?

Tobias
libgomp.texi: Minor update to omp_get_num_devices/omp_get_initial_device

libgomp/ChangeLog:

	* libgomp.texi (omp_get_default_device): Update the wording as the
	value returned by omp_get_initial_device is now ambiguous.
	(omp_get_num_devices): Minor wording tweak.
	(omp_get_initial_device): Note that the function may also
	return omp_initial_device since OpenMP 6.
	
diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 9a42355ff5d..2113abf5c1a 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -1758,14 +1758,13 @@ The effect of running this routine in a @code{target} region is unspecified.
 @table @asis
 @item @emph{Description}:
 Get the value of the @emph{default-device-var} ICV, which is used
 for target regions without a device clause. The value is either a
 nonnegative device number, @code{omp_initial_device} or
-@code{omp_invalid_device}. Note that for the host, the ICV can have two values
-and, hence, this routine might return either the value of the named constant
-@code{omp_initial_device} or the value returned by the
-@code{omp_get_initial_device} routine.
+@code{omp_invalid_device}. Note that for the host, the ICV can have two values:
+either the value of the named constant @code{omp_initial_device} or the value
+returned by the @code{omp_get_num_devices} routine.
 
 The effect of running this routine in a @code{target} region is unspecified.
 
 @item @emph{C/C++}:
 @multitable @columnfractions .20 .80
@@ -1789,11 +1788,11 @@ The effect of running this routine in a @code{target} region is unspecified.
 
 @node omp_get_num_devices
 @subsection @code{omp_get_num_devices} -- Number of target devices
 @table @asis
 @item @emph{Description}:
-Returns the number of target devices.
+Returns the number of available non-host devices.
 
 The effect of running this routine in a @code{target} region is unspecified.
 
 @item @emph{C/C++}:
 @multitable @columnfractions .20 .80
@@ -1936,11 +1935,12 @@ run-time function is desired.
 @subsection @code{omp_get_initial_device} -- Return device number of initial device
 @table @asis
 @item @emph{Description}:
 This function returns a device number that represents the host device.
 Since OpenMP 5.1, this is equal to the value returned by the
-@code{omp_get_num_devices} function.
+@code{omp_get_num_devices} function; since OpenMP 6.0 it may also return
+the value of @code{omp_initial_device}.
 
 The effect of running this routine in a @code{target} region is unspecified.
 
 @item @emph{C/C++}
 @multitable @columnfractions .20 .80


Re: [PATCH] match.pd: Fold pattern of round semantics.

2025-01-07 Thread Richard Biener
On Thu, 2 Jan 2025, 赵洲 wrote:

> Add Reviewer Richard Biener.
> 
> 
> > -原始邮件-
> > 发件人: "Zhou Zhao" 
> > 发送时间:2025-01-02 19:37:07 (星期四)
> > 收件人: gcc-patches@gcc.gnu.org
> > 抄送: xry...@xry111.site, i...@xen0n.name, chengl...@loongson.cn, 
> > xucheng...@loongson.cn, zhaoz...@loongson.cn
> > 主题: [PATCH] match.pd: Fold pattern of round semantics.
> > 
> > This patch implements 4 rules for semantics of round func in match.pd under
> > -funsafe-math-optimizations:
> > 1) (x-floor(x)) < (ceil(x)-x) ? floor(x) : ceil(x) -> floor(x+0.5)
> > 2) (x-floor(x)) >= (ceil(x)-x) ? ceil(x) : floor(x) -> floor(x+0.5)
> > 3) (ceil(x)-x) > (x-floor(x)) ? floor(x) : ceil(x) -> floor(x+0.5)
> > 4) (ceil(x)-x) <= (x-floor(x)) ? ceil(x) : floor(x) -> floor(x+0.5)
> > 
> > The patch implements floor(x+0.5) operation to replace semantics of
> > round(x) function.
> > The patch was regtested on aarch64-linux-gnu and x86_64-linux-gnu, SPEC
> > 2017 and SPEC 2006 were run:
> > As for SPEC 2017, 538.imagick_r benchmark performance increased by 3%+
> > in base test of ratio mode.
> > As for SPEC 2006, while the transform does not seem to be triggered, we
> > also see no non-noise impact on performance.
> > OK for mainline?
> > 
> > gcc/ChangeLog:
> > 
> > * match.pd: Add new pattern for round.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * gcc.dg/fold-round-1.c: New test.
> > ---
> >  gcc/match.pd| 27 ++
> >  gcc/testsuite/gcc.dg/fold-round-1.c | 56 +
> >  2 files changed, 83 insertions(+)
> >  create mode 100644 gcc/testsuite/gcc.dg/fold-round-1.c
> > 
> > diff --git a/gcc/match.pd b/gcc/match.pd
> > index 83eca8b2e0a..7b22b7913ac 100644
> > --- a/gcc/match.pd
> > +++ b/gcc/match.pd
> > @@ -777,6 +777,33 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >   (rdiv @0 (negate @1))
> >   (rdiv (negate @0) @1))
> >  
> > +(if (flag_unsafe_math_optimizations)
> > +/* convert semantics of round(x) function to floor(x+0.5) */
> > +/* (x-floor(x)) < (ceil(x)-x) ? floor(x) : ceil(x) --> floor(x+0.5) */
> > +/* (x-floor(x)) >= (ceil(x)-x) ? ceil(x) : floor(x) --> floor(x+0.5) */
> > +/* (ceil(x)-x) > (x-floor(x)) ? floor(x) : ceil(x) --> floor(x+0.5) */
> > +/* (ceil(x)-x) <= (x-floor(x)) ? ceil(x) : floor(x) --> floor(x+0.5) */

I think you should be able to merge the cases for swapped compares
by just matching (cond (op:c (...)).

I do wonder about the compares itself though, (x-floor(x)) < (ceil(x)-x)
isn't that true exactly when x > 0?  With flag_unsafe_optimizations
< vs. <= and thus x not having a fractional component would be
unimportant.  That said, wouldn't we expect the compares to be
simplified?

I'm also curious where you got these expressions to be simplified from?

Note we're in stage3 so unless this fixes a bug it isn't appropriate
at this stage and should be re-posted/pinged when stage1 opens for 
GCC 16.

Richard.

> > +(for op (lt ge)
> > + bt (FLOOR CEIL)
> > + bf (CEIL FLOOR)
> > + floor (FLOOR FLOOR)
> > + ceil (CEIL CEIL)
> > + (simplify
> > +  (cond (op (minus:s SSA_NAME@0 (floor SSA_NAME@0))
> > +   (minus:s (ceil SSA_NAME@0) SSA_NAME@0))
> > +   (bt SSA_NAME@0) (bf SSA_NAME@0))
> > +  (floor (plus @0 { build_real (type, dconsthalf); }
> > +(for op (gt le)
> > + bt (FLOOR CEIL)
> > + bf (CEIL FLOOR)
> > + floor (FLOOR FLOOR)
> > + ceil (CEIL CEIL)
> > + (simplify
> > +  (cond (op (minus:s (ceil SSA_NAME@0) SSA_NAME@0)
> > +   (minus:s SSA_NAME@0 (floor SSA_NAME@0)))
> > +   (bt SSA_NAME@0) (bf SSA_NAME@0))
> > +  (floor (plus @0 { build_real (type, dconsthalf); })
> > +
> >  (if (flag_unsafe_math_optimizations)
> >   /* Simplify (C / x op 0.0) to x op 0.0 for C != 0, C != Inf/Nan.
> >  Since C / x may underflow to zero, do this only for unsafe math.  */
> > diff --git a/gcc/testsuite/gcc.dg/fold-round-1.c 
> > b/gcc/testsuite/gcc.dg/fold-round-1.c
> > new file mode 100644
> > index 000..845d6d2e475
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/fold-round-1.c
> > @@ -0,0 +1,56 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-Ofast -funsafe-math-optimizations" } */
> > +
> > +extern void link_error (void);
> > +
> > +#define TEST_ROUND(TYPE, FFLOOR, FCEIL)
> >\
> > +  void round_##FFLOOR##_1 (TYPE x) 
> >\
> > +  {
> >\
> > +TYPE t1 = 0;   
> >\
> > +TYPE t2 = __builtin_##FFLOOR (x + 0.5);
> >\
> > +if ((x - __builtin_##FFLOOR (x)) < (__builtin_##FCEIL (x) - x))
> >\
> > +  t1 = __builtin_##FFLOOR (x); 
> >\
> > +else   
> >\
> > +  t1 = __builtin_##FCEIL (x);

[committed][PR testsuite/118055] Trivial testsuite adjustment for m68k target

2025-01-07 Thread Jeff Law

After a bit of a prod from Hans...

Make the obvious change to these tests to get them passing again on m68k.

Jeff

commit a856b4d97b8d328fdcb169b792ac5456e40f8c00
Author: Jeff Law 
Date:   Tue Jan 7 07:43:19 2025 -0700

[PR testsuite/118055] Trivial testsuite adjustment for m68k target

After a bit of a prod from Hans...

Make the obvious change to these tests to get them passing again on m68k.

PR testsuite/118055

gcc/testsuite

* gcc.dg/tree-ssa/pr83403-1.c: Add m68k*-*-* to targets needing
additional arguments for peeling.
* gcc.dg/tree-ssa/pr83403-2.c: Similarly.

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr83403-1.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr83403-1.c
index 3cfda4f183c..64f2bbc76fe 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr83403-1.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr83403-1.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O3 -funroll-loops -fdump-tree-lim2-details" } */
 /* { dg-additional-options "--param max-completely-peeled-insns=200" { target 
{ s390*-*-* } } } */
-/* { dg-additional-options "--param max-completely-peeled-insns=300" { target 
{ arm*-*-* cris-*-* } } } */
+/* { dg-additional-options "--param max-completely-peeled-insns=300" { target 
{ arm*-*-* cris-*-* m68k*-*-* } } } */
 
 #define TYPE unsigned int
 
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr83403-2.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr83403-2.c
index 00fa04ecb85..3f520720ca2 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr83403-2.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr83403-2.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O3 -funroll-loops -fdump-tree-lim2-details" } */
 /* { dg-additional-options "--param max-completely-peeled-insns=200" { target 
{ s390*-*-* } } } */
-/* { dg-additional-options "--param max-completely-peeled-insns=300" { target 
{ arm*-*-* cris-*-* } } } */
+/* { dg-additional-options "--param max-completely-peeled-insns=300" { target 
{ arm*-*-* cris-*-* m68k*-*-* } } } */
 
 #define TYPE int
 


Re: [PATCH] middle-end/118325 - nonlocal goto lowering

2025-01-07 Thread Jakub Jelinek
On Tue, Jan 07, 2025 at 03:49:26PM +0100, Richard Biener wrote:
> When nonlocal goto lowering creates an artificial label it fails
> to adjust its context.
> 
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress
> (I doubt good test coverage is present for non-local gotos)
> 
> OK when testing succeeds?
> 
> Thanks,
> Richard.
> 
>   PR middle-end/118325
>   * tree-nested.cc (convert_nl_goto_reference): Assign proper
>   context to generated artificial label.
> 
>   * gcc.dg/pr118325.c: New testcase.

LGTM.

Jakub



Re: [PATCH] gcc-wwwdocs: Fix typo in GCC version number.

2025-01-07 Thread Jakub Jelinek
On Tue, Jan 07, 2025 at 11:20:11PM +0800, Gerald Pfeifer wrote:
> On Tue, 7 Jan 2025, Simon Martin wrote:
> > Noticed while trying to understand when I can expect the GCC 15 branch
> > to be created: the GCC 15 release criteria page still mentions GCC 14.
> > 
> > I'll push this as obvious.
> 
> Thank you, Simon!
> 
> > Are such pages created via a script? If so I am happy to fix it as well.
> 
> Unless our release managers (Jakub on this case) have been taken over by 

I usually just git diff the branching or releasing commit from a year ago
and hand edit everything that clearly needs to be adjusted in the diff, then
apply.
In this case I've clearly failed to do parts of that.

> ChatGPT/Gemini/you-name-it I believe this is manual work following 
>   https://gcc.gnu.org/releasing.html
> though I just noticed criteria.html (and creating the directory for 
> the new release) isn't actually covered.
> 
> That could be a nice contribution to add...

Jakub



Re: [PATCH] arm: [MVE intrinsics] Fix tuples field name (PR 118332)

2025-01-07 Thread Richard Sandiford
Christophe Lyon  writes:
> A recent commit mistakenly changed the field name for tuples from
> 'val' to '__val', but unlike SVE this name is mandated by ACLE.
>
> The patch simply switches back the name to 'val'.
>
>   PR target/118332
>
> gcc/ChangeLog:
>
>   * config/arm/arm-mve-builtins.cc (wrap_type_in_struct): Use 'val'
>   instead of '__val'.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.target/arm/mve/intrinsics/pr118332.c: New test.

OK.  Thanks for the super-quick fix :)

Richard

> ---
>  gcc/config/arm/arm-mve-builtins.cc | 5 ++---
>  gcc/testsuite/gcc.target/arm/mve/intrinsics/pr118332.c | 5 +
>  2 files changed, 7 insertions(+), 3 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/arm/mve/intrinsics/pr118332.c
>
> diff --git a/gcc/config/arm/arm-mve-builtins.cc 
> b/gcc/config/arm/arm-mve-builtins.cc
> index 2a87c41b3ff..609fbc4cd59 100644
> --- a/gcc/config/arm/arm-mve-builtins.cc
> +++ b/gcc/config/arm/arm-mve-builtins.cc
> @@ -450,13 +450,12 @@ register_vector_type (vector_type_index type)
>  }
>  
>  /* Return a structure type that contains a single field of type FIELD_TYPE.
> -   The field is called __val, but that's an internal detail rather than
> -   an exposed part of the API.  */
> +   The field is called 'val', as mandated by ACLE.  */
>  static tree
>  wrap_type_in_struct (tree field_type)
>  {
>tree field = build_decl (input_location, FIELD_DECL,
> -get_identifier ("__val"), field_type);
> +get_identifier ("val"), field_type);
>tree struct_type = lang_hooks.types.make_type (RECORD_TYPE);
>DECL_FIELD_CONTEXT (field) = struct_type;
>TYPE_FIELDS (struct_type) = field;
> diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/pr118332.c 
> b/gcc/testsuite/gcc.target/arm/mve/intrinsics/pr118332.c
> new file mode 100644
> index 000..a8f6389c58d
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/pr118332.c
> @@ -0,0 +1,5 @@
> +/* { dg-require-effective-target arm_v8_1m_mve_ok } */
> +/* { dg-add-options arm_v8_1m_mve } */
> +
> +#include 
> +uint32x4_t first(uint32x4x4_t a) { return a.val[0]; }


Ping re C++ parts of: [PATCH] c/c++: UX improvements to 'too {few,many} arguments' errors [PR118112]

2025-01-07 Thread David Malcolm
On Thu, 2024-12-19 at 18:40 -0500, David Malcolm wrote:

Jason: are the C++ changes OK?  Patch can also be seen at:
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672076.html

Joseph approved the C part of this in
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672473.html

Thanks
Dave



> Consider this case of a bad call to a callback function (perhaps
> due to C23 changing the meaning of () in function decls):
> 
> struct p {
>     int (*bar)();
> };
> 
> void baz() {
>     struct p q;
>     q.bar(1);
> }
> 
> Before this patch the C frontend emits:
> 
> t.c: In function 'baz':
> t.c:7:5: error: too many arguments to function 'q.bar'
>     7 | q.bar(1);
>   | ^
> 
> and the C++ frontend emits:
> 
> t.c: In function 'void baz()':
> t.c:7:10: error: too many arguments to function
>     7 | q.bar(1);
>   | ~^~~
> 
> neither of which give the user much help in terms of knowing what
> was expected, and where the relevant declaration is.
> 
> With this patch the C frontend emits:
> 
> t.c: In function 'baz':
> t.c:7:5: error: too many arguments to function 'q.bar'; expected 0,
> have 1
>     7 | q.bar(1);
>   | ^ ~
> t.c:2:15: note: declared here
>     2 | int (*bar)();
>   |   ^~~
> 
> (showing the expected vs actual counts, the pertinent field decl, and
> underlining the first extraneous argument at the callsite)
> 
> and the C++ frontend emits:
> 
> t.c: In function 'void baz()':
> t.c:7:10: error: too many arguments to function; expected 0, have 1
>     7 | q.bar(1);
>   | ~^~~
> 
> (showing the expected vs actual counts; the other data was not
> accessible
> without a more invasive patch)
> 
> Similarly, the patch also updates the "too few arguments" case to
> also
> show expected vs actual counts.  Doing so requires a tweak to the
> wording to say "at least" for the case of variadic fns, and for C++
> fns
> with default args, where e.g. previously the C FE emitted:
> 
> s.c: In function 'test':
> s.c:5:3: error: too few arguments to function 'callee'
>     5 |   callee ();
>   |   ^~
> s.c:1:6: note: declared here
>     1 | void callee (const char *, ...);
>   |  ^~
> 
> with this patch it emits:
> 
> s.c: In function 'test':
> s.c:5:3: error: too few arguments to function 'callee'; expected at
> least 1, have 0
>     5 |   callee ();
>   |   ^~
> s.c:1:6: note: declared here
>     1 | void callee (const char *, ...);
>   |  ^~
> 
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> OK for trunk?
> 
> gcc/c/ChangeLog:
>   PR c/118112
>   * c-typeck.cc (inform_declaration): Add "function_expr"
> param and
>   use it for cases where we couldn't show the function decl to
> show
>   field decls for callbacks.
>   (build_function_call_vec): Add missing
> auto_diagnostic_group.
>   Update for new param of inform_declaration.
>   (convert_arguments): Likewise.  For the "too many arguments"
> case
>   add the expected vs actual counts to the message, and if we
> have
>   it, add the location_t of the first surplus param as a
> secondary
>   location within the diagnostic.  For the "too few arguments"
> case,
>   determine the minimum number of arguments required and add
> the
>   expected vs actual counts to the message, tweaking it to "at
> least"
>   for variadic functions.
> 
> gcc/cp/ChangeLog:
>   PR c/118112
>   * typeck.cc (error_args_num): Add params "expected_num",
>   "actual_num", and "at_least_p".  Compute "too_many_p" from
> these
>   rather than have it be a param.  Add expected vs actual
> counts to
>   the messages and tweak them for the "at least" case.
>   (convert_arguments): Update calls to error_args_num to pass
> in
>   expected vs actual number, and the "at_least_p", determining
> this
>   for the "too few" case.
> 
> gcc/testsuite/ChangeLog:
>   PR c/118112
>   * c-c++-common/too-few-arguments.c: New test.
>   * c-c++-common/too-many-arguments.c: New test.
>   * g++.dg/cpp0x/variadic169.C: Verify the reported expected
> vs
>   actual argument counts.
>   * g++.dg/modules/macloc-1_c.C: Update regexp for addition of
> param
>   counts to error message.
>   * g++.dg/modules/macloc-1_d.C: Likewise.
> 
> Signed-off-by: David Malcolm 
> ---
>  gcc/c/c-typeck.cc | 77 ---
>  gcc/cp/typeck.cc  | 94 ++---
> -
>  .../c-c++-common/too-few-arguments.c  | 38 
>  .../c-c++-common/too-many-arguments.c | 96
> +++
>  gcc/testsuite/g++.dg/cpp0x/variadic169.C  |  2 +-
>  gcc/testsuite/g++.dg/modules/macloc-1_c.C |  4 +-
>  gcc/testsuite/g++.dg/modules/macloc-1_d.C |  4 +-
>  7 files changed, 280 insertions(+), 35 deletions(-)
>  create mode 100644 gcc/testsuite/c-c++-common/too-few-arguments.c
>  create mode 

RE: [RFC] PR81358: Enable automatic linking of libatomic

2025-01-07 Thread Prathamesh Kulkarni


> -Original Message-
> From: Joseph Myers 
> Sent: 03 January 2025 22:22
> To: Prathamesh Kulkarni 
> Cc: Tobias Burnus ; Xi Ruoyao
> ; Matthew Malcomson ; gcc-
> patc...@gcc.gnu.org
> Subject: RE: [RFC] PR81358: Enable automatic linking of libatomic
> 
> External email: Use caution opening links or attachments
> 
> 
> On Fri, 20 Dec 2024, Prathamesh Kulkarni wrote:
> 
> > Hi,
> > The previous patch (now reverted) had two different issues both
> stemming from the rule added in libatomic/Makefile.am:
> > (1) As mentioned above, it broke multilib builds because it
> > incorrectly copies libatomic.a in $(gcc_objdir). The attached patch
> > fixes it by instead copying libatomic.a  over to
> $(gcc_objdir)$(MULTISUBDIR)/, and can confirm that 64-bit libatomic.a
> is copied to $build/gcc/ and 32-bit libatomic.a is copied to
> $build/gcc/32/.
> >
> > (2) libatomic_convenience.la was not getting generated for some
> reason, which resulted in build failure while building libdruntime.
> > The patch adds libatomic_convenience.la as a dependency, and I can
> see it now getting generated, which seems to fix the build issue with
> libdruntime.
> >
> > Patch passes bootstrap+test with multilib enabled for --enable-
> languages=all on x86_64-linux-gnu, and for --enable-
> languages=c,c++,fortran on aarch64-linux-gnu.
> > Does this version look OK ?
> 
> This is OK.
Hi Joseph,
Thanks for the approval!
I requested for wider testing on PR, and there was following comment 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358#c29):
"I've now bootstrapped the patch on i386-pc-solaris2.11 (and
x86_64-pc-linux-gnu for comparison's sake, still running).  The good
news is that this version no longer breaks Solaris bootstrap.  However,
it has one fundamental problem: on anything but Linux, -flink-libatomic
is a no-op: LINK_LIBATOMIC_SPEC is only used in gcc/config/gnu-user.h
while the docs suggest this is a generic option.  I don't think this is
acceptable."

The attached patch makes formatting changes, and modifies the doc for 
flink-libatomic to:
"Enable linking of libatomic if it's supported by target. Enabled by default,
and currently supported on targets using glibc."

Does that look OK ?
I am not sure if the patch may need reworking for automatically linking 
libatomic for non glibc based systems, and can look into it as follow-up.

Thanks,
Prathamesh
> 
> To answer Jakub's question about passing -fno-link-libatomic when
> building target libraries, I think it's reasonable for target
> libraries to use atomic interfaces that may, on some targets, need
> libatomic.
> 
> (I'm not asserting that this patch by itself will make target
> libraries using atomic interfaces work in cases that are currently
> broken.
> Empirically, some such cases are broken already in ways that this
> patch wouldn't fix.  Bug 118280 reports libstdc++ for microblaze using
> __atomic_test_and_set, which is not defined in libatomic - libatomic
> for microblaze-linux-gnu has an undefined reference to that symbol
> itself, only defining __atomic_test_and_set_{1,2,4,8,16}.  And I'm not
> sure there's currently a bug open for it, but for m68k-linux-gnu built
> for ColdFire, libstdc++ has undefined references to hidden __sync_*
> symbols defined in libgcc.a, which also prevents linking with
> libstdc++, but I expect the fix for that would be to use t-slibgcc-
> libgcc in libgcc/config.host for those targets, nothing to do with
> libatomic since the symbols aren't in libatomic.  In both cases, we
> could also take the breakage as evidence that those targets are no
> longer being used outside of bots building many different targets and
> so might be ripe for
> obsolescence.)
> 
> --
> Joseph S. Myers
> josmy...@redhat.com

PR81358: Enable automatic linking of libatomic.

ChangeLog:
PR driver/81358
* Makefile.def: Add dependencies so libatomic is built before target
libraries are configured.
* Makefile.tpl: Export TARGET_CONFIGDIRS.
* configure.ac: Add libatomic to bootstrap_target_libs.
* Makefile.in: Regenerate.
* configure: Regenerate.

gcc/ChangeLog:
PR driver/81358
* common.opt: New option -flink-libatomic.
* gcc.cc (LINK_LIBATOMIC_SPEC): New macro.
* config/gnu-user.h (GNU_USER_TARGET_LINK_GCC_C_SEQUENCE_SPEC): Use
LINK_LIBATOMIC_SPEC.
* doc/invoke.texi: Document -flink-libatomic.
* configure.ac: Define TARGET_PROVIDES_LIBATOMIC.
* configure: Regenerate.
* config.in: Regenerate.

libatomic/ChangeLog:
PR driver/81358
* Makefile.am: Pass -fno-link-libatomic.
New rule all.
* configure.ac: Assert that CFLAGS is set and pass -fno-link-libatomic. 
* Makefile.in: Regenerate.
* configure: Regenerate.

Signed-off-by: Prathamesh Kulkarni 
Co-authored-by: Matthew Malcolmson 

diff --git a/Makefile.def b/Makefile.def
index 19954e7d731..90899fa28cf 100644
--- a/Makefile.def
+++ b/Makefile.

Re: [PATCH v1] LoongArch: Opitmize the cost of vec_construct.

2025-01-07 Thread Lulu Cheng



在 2025/1/7 下午12:47, chenxiaolong 写道:

   When analyzing 525 on LoongArch architecture, it was found that the
for loop of hotspot function x264_pixel_satd_8x4 could not be quantized
256-bit due to the cost of vec_construct setting. After re-adjusting
vec_construct, the performance of 525 program was improved by 16.57%.
It was found that this function can be vectorized on the aarch64 and
x86 architectures, see [PR98138].

Co-Authored-By: Deng Jianbo .

gcc/ChangeLog:

* config/loongarch/loongarch.cc
(loongarch_builtin_vectorization_cost): Modify the
 construction cost of the vec_construct vector.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/vect-slp-two-operator.c: New test.
---
  gcc/config/loongarch/loongarch.cc |  6 ++--
  .../loongarch/vect-slp-two-operator.c | 36 +++
  2 files changed, 39 insertions(+), 3 deletions(-)
  create mode 100644 gcc/testsuite/gcc.target/loongarch/vect-slp-two-operator.c

diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc
index 89237c377e7..ff27b96c31e 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -4127,10 +4127,10 @@ loongarch_builtin_vectorization_cost (enum 
vect_cost_for_stmt type_of_cost,
  
case vec_construct:

elements = TYPE_VECTOR_SUBPARTS (vectype);
-   if (ISA_HAS_LASX)
- return elements + 1;
+   if (LASX_SUPPORTED_MODE_P (mode) && !LSX_SUPPORTED_MODE_P (mode))
+ return elements / 2 + 3;
else
- return elements;
+ return elements / 2 + 1;
  
default:

gcc_unreachable ();
diff --git a/gcc/testsuite/gcc.target/loongarch/vect-slp-two-operator.c 
b/gcc/testsuite/gcc.target/loongarch/vect-slp-two-operator.c
new file mode 100644
index 000..f27492e10f0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vect-slp-two-operator.c
@@ -0,0 +1,36 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mlasx -ftree-vectorize -fdump-tree-vect 
-fdump-tree-vect-details" } */
+
+typedef unsigned char uint8_t;
+typedef unsigned int uint32_t;
+
+#define HADAMARD4(d0, d1, d2, d3, s0, s1, s2, s3) {\
+int t0 = s0 + s1;\
+int t1 = s0 - s1;\
+int t2 = s2 + s3;\
+int t3 = s2 - s3;\
+d0 = t0 + t2;\
+d1 = t1 + t3;\
+d2 = t0 - t2;\
+d3 = t1 - t3;\
+}
+
+void sink(uint32_t tmp[4][4]);
+
+int x264_pixel_satd_8x4( uint8_t *pix1, int i_pix1, uint8_t *pix2, int i_pix2 )


Hi,xiao long:

There is a problem with the format of the code here. There must be a 
space before '('.



+{
+uint32_t tmp[4][4];
+int sum = 0;
+for( int i = 0; i < 4; i++, pix1 += i_pix1, pix2 += i_pix2 )
+{
+uint32_t a0 = (pix1[0] - pix2[0]) + ((pix1[4] - pix2[4]) << 16);
+uint32_t a1 = (pix1[1] - pix2[1]) + ((pix1[5] - pix2[5]) << 16);
+uint32_t a2 = (pix1[2] - pix2[2]) + ((pix1[6] - pix2[6]) << 16);
+uint32_t a3 = (pix1[3] - pix2[3]) + ((pix1[7] - pix2[7]) << 16);
+HADAMARD4( tmp[i][0], tmp[i][1], tmp[i][2], tmp[i][3], a0,a1,a2,a3 );
+}
+sink(tmp);
+}
+
+/* { dg-final { scan-tree-dump "vectorizing stmts using SLP" "vect" } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */




RE: [RFC] PR81358: Enable automatic linking of libatomic

2025-01-07 Thread Thomas Schwinge
Hi Prathamesh!

Thanks for working on this!


Per my understanding, this patch won't automagically resolve the need to
(occasionally) having to specify '-foffload-options=nvptx-none=-latomic'
for nvptx offloading: it doesn't use 'LINK_LIBATOMIC_SPEC', currently
only used via 'GNU_USER_TARGET_LINK_GCC_C_SEQUENCE_SPEC' from
'gcc/config/gnu-user.h' (general issue, affecting a lot of
configurations, to be addressed as necessary):

> --- a/gcc/config/gnu-user.h
> +++ b/gcc/config/gnu-user.h

>  #define GNU_USER_TARGET_LINK_GCC_C_SEQUENCE_SPEC \
> -  "%{static|static-pie:--start-group} %G %{!nolibc:%L} \
> +  "%{static|static-pie:--start-group} %G %{!nolibc:" LINK_LIBATOMIC_SPEC 
> "%L} \
> %{static|static-pie:--end-group}%{!static:%{!static-pie:%G}}"

> --- a/gcc/gcc.cc
> +++ b/gcc/gcc.cc

>  /* Here is the spec for running the linker, after compiling all files.  */
>  
> +#if defined(TARGET_PROVIDES_LIBATOMIC) && defined(USE_LD_AS_NEEDED)
> +#define LINK_LIBATOMIC_SPEC "%{!fno-link-libatomic:" LD_AS_NEEDED_OPTION \
> + " -latomic " LD_NO_AS_NEEDED_OPTION "} "
> +#else
> +#define LINK_LIBATOMIC_SPEC ""
> +#endif
> +
>  /* This is overridable by the target in case they need to specify the
> -lgcc and -lc order specially, yet not require them to override all
> of LINK_COMMAND_SPEC.  */

..., and the nvptx linker doesn't support '--as-needed'.

I'll think about it; indeed it'd be good to get that resolved, too.


On 2024-12-20T15:37:42+, Prathamesh Kulkarni  wrote:
> [...] copying libatomic.a  over to $(gcc_objdir)$(MULTISUBDIR)/, and can 
> confirm that 64-bit libatomic.a is copied to $build/gcc/ and 32-bit
> libatomic.a is copied to $build/gcc/32/.

So this:

> --- a/libatomic/Makefile.am
> +++ b/libatomic/Makefile.am

> @@ -162,6 +162,11 @@ libatomic_convenience_la_LIBADD = $(libatomic_la_LIBADD)
>  # when it is reloaded during the build of all-multi.
>  all-multi: $(libatomic_la_LIBADD)
>  
> +gcc_objdir = $(MULTIBUILDTOP)../../$(host_subdir)/gcc
> +all: all-multi libatomic.la libatomic_convenience.la
> + $(INSTALL_DATA) .libs/libatomic.a $(gcc_objdir)$(MULTISUBDIR)/
> + chmod 644 $(gcc_objdir)$(MULTISUBDIR)/libatomic.a

... is conceptually modelled after libgcc, where the libraries get copied
into 'gcc/'?  However, here we only copy the static 'libatomic.a'; libgcc
does a 'make install-leaf', see 'libgcc/Makefile.in':

all: all-multi
# Now that we have built all the objects, we need to copy
# them back to the GCC directory.  Too many things (other
# in-tree libraries, and DejaGNU) know about the layout
# of the build tree, for now.
$(MAKE) install-leaf DESTDIR=$(gcc_objdir) \
  slibdir= libsubdir= MULTIOSDIR=$(MULTIDIR)

..., which also installs dynamic libraries.  Is that difference
intentional and/or possibly important?

Does libatomic even need a switch corresponding to '-static-libgcc'?

Given that libatomic libraries get copied into 'gcc/', will we be able
(later, incrementally) to remove some setup code from the test suites'
'*.exp' files, to locate build-tree libatomic?

Also, given the presumed similarity to how libgcc is handled (with, of
course, the difference that libatomic isn't built for all
configurations), should we maybe in the build system place the new
libatomic handling next to the existing libgcc handling?  Specifically,
instead of:

> --- a/Makefile.def
> +++ b/Makefile.def

> +dependencies = { module=configure-target-libbacktrace; 
> on=all-target-libatomic; };
> +dependencies = { module=configure-target-libgloss; on=all-target-libatomic; 
> };
> +dependencies = { module=configure-target-newlib; on=all-target-libatomic; };
> +dependencies = { module=configure-target-libgomp; on=all-target-libatomic; };
> +dependencies = { module=configure-target-libitm; on=all-target-libatomic; };
> +dependencies = { module=configure-target-libstdc++v3; 
> on=all-target-libatomic; };
> +dependencies = { module=configure-target-libsanitizer; 
> on=all-target-libatomic; };
> +dependencies = { module=configure-target-libvtv; on=all-target-libatomic; };
> +dependencies = { module=configure-target-libssp; on=all-target-libatomic; };
> +dependencies = { module=configure-target-libquadmath; 
> on=all-target-libatomic; };
> +dependencies = { module=configure-target-libgfortran; 
> on=all-target-libatomic; };
> +dependencies = { module=configure-target-libffi; on=all-target-libatomic; };
> +dependencies = { module=configure-target-libobjc; on=all-target-libatomic; };
> +dependencies = { module=configure-target-libada; on=all-target-libatomic; };
> +dependencies = { module=configure-target-libgm2; on=all-target-libatomic; };
> +dependencies = { module=configure-target-libgo; on=all-target-libatomic; };
> +dependencies = { module=configure-target-libgrust; on=all-target-libatomic; 
> };
> +dependencies = { module=configure-target-libphobos; on=all-target-libatomic; 
> };
> +dependencies = { module=configure-target-zl

RE: PR118200: note_simd_array_uses crashes in SIMT region with offloading to nvptx

2025-01-07 Thread Prathamesh Kulkarni



> -Original Message-
> From: Prathamesh Kulkarni 
> Sent: 26 December 2024 22:36
> To: gcc-patches@gcc.gnu.org; ja...@redhat.com; Thomas Schwinge
> 
> Subject: PR118200: note_simd_array_uses crashes in SIMT region with
> offloading to nvptx
> 
> External email: Use caution opening links or attachments
> 
> 
> Hi,
> As mentioned in PR, note_simd_array_uses (and
> adjust_simduid_builtins), crash while processing GOMP internal
> functions (GOMP_SIMD_VF) in SIMT region.
> This happens because in SIMT region, first argument to GOMP internal
> function is lhs of call to IFN_GOMP_SIMT_ENTER, rather than default
> definition, which results in segfault while accessing SSA_NAME_VAR
> (gimple_call_arg (stmt, 0)), where arg is simduid.
> 
> The attached patch simply skips processing of simduid if it's not
> default def (which'd indicate it's in SIMT region), which seems to fix
> the issue.
> I am assuming that'd be OK (instead of walking SSA use-def chain to
> obtain default def and corresponding simduid var) since SIMT region
> would be dead-code on host side ? On nvptx side, the builtins get
> folded in ompdevlow pass itself.
> 
> Patch passes libgomp testing on AArch64/nvptx offloading, and
> bootstrap+test on aarch64-linux-gnu.
> Does it look OK ?
Hi,
ping: https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672269.html

Thanks,
Prathamesh
> 
> Signed-off-by: Prathamesh Kulkarni 
> 
> Thanks,
> Prathamesh
> 
> 



[PATCH] tree-optimization/118269 - SLP reduction chain and early breaks

2025-01-07 Thread Richard Biener
When we create the SLP reduction chain epilogue for the PHIs for
the early exit we fail to properly classify the reduction as SLP
reduction chain.  The following fixes the corresponding checks.

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

Richard.

PR tree-optimization/118269
* tree-vect-loop.cc (vect_create_epilog_for_reduction):
Use the correct stmt for the REDUC_GROUP_FIRST_ELEMENT lookup.

* gcc.dg/vect/vect-early-break_131-pr118269.c: New testcase.
---
 .../gcc.dg/vect/vect-early-break_131-pr118269.c | 17 +
 gcc/tree-vect-loop.cc   |  8 +---
 2 files changed, 22 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/vect/vect-early-break_131-pr118269.c

diff --git a/gcc/testsuite/gcc.dg/vect/vect-early-break_131-pr118269.c 
b/gcc/testsuite/gcc.dg/vect/vect-early-break_131-pr118269.c
new file mode 100644
index 000..5f7abcee57c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/vect-early-break_131-pr118269.c
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-add-options vect_early_break } */
+/* { dg-additional-options "-O3" } */
+
+short g_113;
+int func_1_l_1273, func_1_l_1370, func_1_l_1258;
+void func_1() {
+  int l_1375;
+  for (; l_1375; l_1375--) {
+for (; func_1_l_1370;)
+  ;
+func_1_l_1273 &= !0;
+func_1_l_1273 &= g_113;
+if (func_1_l_1258)
+  break;
+  }
+}
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 2b9d5956635..bb1138bfcfb 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -6039,7 +6039,9 @@ vect_create_epilog_for_reduction (loop_vec_info 
loop_vinfo,
  # b1 = phi 
  a2 = operation (a1)
  b2 = operation (b1)  */
-  bool slp_reduc = (slp_node && !REDUC_GROUP_FIRST_ELEMENT (stmt_info));
+  bool slp_reduc
+= (slp_node
+   && !REDUC_GROUP_FIRST_ELEMENT (STMT_VINFO_REDUC_DEF (reduc_info)));
   bool direct_slp_reduc;
   tree induction_index = NULL_TREE;
 
@@ -6331,7 +6333,7 @@ vect_create_epilog_for_reduction (loop_vec_info 
loop_vinfo,
  a multiple of the SLP group size.
 
  The same is true if we couldn't use a single defuse cycle.  */
-  if (REDUC_GROUP_FIRST_ELEMENT (stmt_info)
+  if (REDUC_GROUP_FIRST_ELEMENT (STMT_VINFO_REDUC_DEF (reduc_info))
   || direct_slp_reduc
   || (slp_reduc
  && constant_multiple_p (TYPE_VECTOR_SUBPARTS (vectype), group_size))
@@ -6632,7 +6634,7 @@ vect_create_epilog_for_reduction (loop_vec_info 
loop_vinfo,
   if (slp_node)
{
  tree initial_value = NULL_TREE;
- if (REDUC_GROUP_FIRST_ELEMENT (stmt_info))
+ if (REDUC_GROUP_FIRST_ELEMENT (STMT_VINFO_REDUC_DEF (reduc_info)))
initial_value = reduc_info->reduc_initial_values[0];
  neutral_op = neutral_op_for_reduction (TREE_TYPE (vectype), code,
 initial_value, false);
-- 
2.43.0


Re: [PATCH] Accept commas between clauses in OpenMP declare variant

2025-01-07 Thread Tobias Burnus

Paul-Antoine Arras:

Add support to the Fortran parser for the new OpenMP syntax that allows a
comma after the directive name and between clauses of declare variant.
The C and C++ parsers already support this syntax so only a new test is added.


Note: only the optional comma between directive name and (first) clause
is new (since 5.2). The one between clauses is old (since OpenMP 2.5).

While the patch supports both, 'new OpenMP syntax' is a bit misleading.

For 'declare variant', the comma-between-clauses support is now required
as only with 5.1 and this patch set, more clauses ('adjust_args' and
'append_args') are supported.

This second type of comma (between directive and first clause) is
supported in C/C++ since OpenMP 5.1; I think mainly because of the
added [[omp::directive(...)]] C++11 attribute feature.

In Fortran, this comma is only permitted since 5.2; I think mostly
for consistency with C/C++.

* * *

BTW: Adding support for this comma for all directives is tracked as
to-be-done Fortran item for 5.2 (under other features as Appendix B
does not list it.)
→ https://gcc.gnu.org/onlinedocs/libgomp/OpenMP-5_002e2.html

* * *



--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -6595,6 +6595,10 @@ gfc_match_omp_declare_variant (void)
  
for (;;)

  {
+  gfc_gobble_whitespace ();
+  gfc_match_char (',');
+  gfc_gobble_whitespace ();
+


I think that will do, but having a better error would be IMHO better.

For the first fail, we get:

   13 | !$omp declare variant(f) ,,match(construct={dispatch}) 
adjust_args(need_device_ptr : c)

  |   1
Error: expected ‘match’ or ‘adjust_args’ at (1)

which is quite helpful. But moving the ,, later gives:


   13 | !$omp declare variant(f) 
match(construct={dispatch}),,adjust_args(need_device_ptr : c)

  |   1
Error: Invalid character in name at (1)

That's kind of helpful but not really useful.

And adding a valid but not yet supported clause (it's supported for C/C++):

   13 | !$omp declare variant(f) 
match(construct={dispatch}),adjust_args(need_device_ptr : c),append_args(a)
  | 
  1

Error: Unclassifiable statement at (1)


I think it would be better to replace the first_p by, e.g.,
'error_p = true; break;' – and do the this diagnostic
after the for(;;) loop. This seems to yield a better diagnostic.

* * *


diff --git a/gcc/testsuite/c-c++-common/gomp/adjust-args-5.c 
b/gcc/testsuite/c-c++-common/gomp/adjust-args-5.c
new file mode 100644
index 000..863b77458e4
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/gomp/adjust-args-5.c
@@ -0,0 +1,21 @@
+/* { dg-do compile } */
+
+/* Check that the OpenMP 6 syntax with commas after the directive name and
+   between clauses is supported. */


The comment is wrong - For C/C++, that's 5.1 syntax.


diff --git a/gcc/testsuite/gfortran.dg/gomp/adjust-args-11.f90 
b/gcc/testsuite/gfortran.dg/gomp/adjust-args-11.f90
new file mode 100644
index 000..3b26f1b0868
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/gomp/adjust-args-11.f90
@@ -0,0 +1,45 @@
+! { dg-do compile }
+
+! Check that the OpenMP 5.1 syntax with commas between clauses is supported.
+! A comma after the directive name is introduced in 5.2, which is not supported
+! yet.


OpenMP 5.1 is slightly misleading (it's 2.5 but new for declare variant
as it didn't have more than one clause before). I think I would remove
'5.1' (i.e. make it: "... that the OpenMP syntax with commas ...").

A side: It's supported by the parser, but you could vary the tests
by having no spaces around the comma vs. having a comma before, after,
or before and after the comma.


s/which is not supported yet/which currently is only partially supported/.

At least for 'declare variant' is is supported - as your testcase shows.

* * *


--- a/gcc/testsuite/gfortran.dg/gomp/declare-variant-2.f90
+++ b/gcc/testsuite/gfortran.dg/gomp/declare-variant-2.f90
@@ -182,9 +182,6 @@ contains
-  subroutine f75 ()
-!$omp declare variant (f1),match(construct={parallel}) ! { dg-error 
"expected 'match' or 'adjust_args' at .1." }
-  end subroutine


I think you could replace the removed test case by one or all snippets
from above. (Well, better not 'append_args' as that will be supported
soon, maybe something like 'unknown' or an existing but invalid clause
like 'nowait' or ...)

Tobias


Re: [PATCH 10/10] aarch64: Try to avoid passing new flags to assembler

2025-01-07 Thread Andrew Carlotti
On Mon, Nov 25, 2024 at 11:26:39PM +, Richard Sandiford wrote:
> Sorry for the slow review.
> 
> Andrew Carlotti  writes:
> > These new flags (+fcma, +jscvt, +rcpc2, +jscvt, +frintts, +wfxt and +xs)
> > were only recently added to the assembler.  To improve compatibility
> > with older assemblers, we try to avoid passing these new flags to the
> > assembler if we can express the targetted architecture without them. We
> > do so by using an almost-equivalent architecture string with a higher
> > architecture version.
> >
> > This should never reduce the set of instructions accepted by the
> > assembler.  It will make it more lenient in two cases:
> >
> > 1. Many system registers are currently gated behind architecture
> > versions instead of specific feature flags.  Increasing the base
> > architecture version may cause more system register accesses to be
> > accepted.
> >
> > 2. FEAT_XS doesn't have an HWCAP bit or cpuinfo entry.  We still want to
> > avoid passing +wfxt or +noxs to the assembler if possible, so we'll
> > instruct the assembler to accept FEAT_XS instructions as well whenever
> > the rest of the new features are enabled.
> >
> > gcc/ChangeLog:
> >
> > * common/config/aarch64/aarch64-common.cc
> > (aarch64_get_arch_string_for_assembler): New.
> > (aarch64_rewrite_march): New.
> > (aarch64_rewrite_selected_cpu): Call new function.
> > * config/aarch64/aarch64-elf.h (ASM_SPEC): Remove identity mapping.
> > * config/aarch64/aarch64-protos.h
> > (aarch64_get_arch_string_for_assembler): New.
> > * config/aarch64/aarch64.cc
> > (aarch64_declare_function_name): Call new function.
> > (aarch64_start_file): Ditto.
> > * config/aarch64/aarch64.h
> > * config/aarch64/aarch64.h
> > (EXTRA_SPEC_FUNCTIONS): Use new macro name.
> > (MCPU_TO_MARCH_SPEC): Rename to...
> > (MARCH_REWRITE_SPEC): ...this, and add new spec rule.
> > (aarch64_rewrite_march): New declaration.
> > (MCPU_TO_MARCH_SPEC_FUNCTIONS): Rename to...
> > (MARCH_REWRITE_SPEC_FUNCTIONS): ...this, and add new function.
> > (ASM_CPU_SPEC): Use new macro name.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/aarch64/cpunative/native_cpu_21.c: Update check.
> > * gcc.target/aarch64/cpunative/native_cpu_22.c: Update check.
> > * gcc.target/aarch64/cpunative/info_27: New test.
> > * gcc.target/aarch64/cpunative/info_28: New test.
> > * gcc.target/aarch64/cpunative/info_29: New test.
> > * gcc.target/aarch64/cpunative/native_cpu_27.c: New test.
> > * gcc.target/aarch64/cpunative/native_cpu_28.c: New test.
> > * gcc.target/aarch64/cpunative/native_cpu_29.c: New test.
> >
> >
> > diff --git a/gcc/common/config/aarch64/aarch64-common.cc 
> > b/gcc/common/config/aarch64/aarch64-common.cc
> > index 
> > 2bfc597e333b6018970a9ee6e370a66b6d0960ef..717b3238be16f39a6fd1b4143662eb540ccf292d
> >  100644
> > --- a/gcc/common/config/aarch64/aarch64-common.cc
> > +++ b/gcc/common/config/aarch64/aarch64-common.cc
> > @@ -371,6 +371,119 @@ aarch64_get_extension_string_for_isa_flags
> >return outstr;
> >  }
> >  
> > +/* Generate an arch string to be passed to the assembler.
> > +
> > +   Several flags were added retrospectively for features that were 
> > previously
> > +   enabled only by specifying an architecture version.  We want to avoid
> > +   passing these flags to the assembler if possible, to improve 
> > compatibility
> > +   with older assemblers.  */
> > +
> > +std::string
> > +aarch64_get_arch_string_for_assembler (aarch64_arch arch,
> > +  aarch64_feature_flags flags)
> > +{
> > +  if (!(flags & AARCH64_FL_FCMA) || !(flags & AARCH64_FL_JSCVT))
> > +goto done;
> > +
> > +  if (arch == AARCH64_ARCH_V8A
> > +  || arch == AARCH64_ARCH_V8_1A
> > +  || arch == AARCH64_ARCH_V8_2A)
> > +arch = AARCH64_ARCH_V8_3A;
> > +
> > +  if (!(flags & AARCH64_FL_RCPC2))
> > +goto done;
> > +
> > +  if (arch == AARCH64_ARCH_V8_3A)
> > +arch = AARCH64_ARCH_V8_4A;
> > +
> > +  if (!(flags & AARCH64_FL_FRINTTS) || !(flags & AARCH64_FL_FLAGM2))
> > +goto done;
> > +
> > +  if (arch == AARCH64_ARCH_V8_4A)
> > +arch = AARCH64_ARCH_V8_5A;
> > +
> > +  if (!(flags & AARCH64_FL_WFXT))
> > +goto done;
> > +
> > +  if (arch == AARCH64_ARCH_V8_5A || arch == AARCH64_ARCH_V8_6A)
> > +{
> > +  arch = AARCH64_ARCH_V8_7A;
> > +  /* We don't support native detection for FEAT_XS, so we'll assume 
> > it's
> > +present if the rest of these features are also present.  If we don't
> > +do this, then we would end up passing +noxs to the assembler.  */
> > +  flags |= AARCH64_FL_XS;
> > +}
> > +done:
> > +
> > +  const struct arch_to_arch_name* a_to_an;
> > +  for (a_to_an = all_architectures;
> > +   a_to_an->arch != aarch64_no_arch;
> > +   a_to_an++)
> > +{
> > +  if (a_to_an->arch == arch)
> > +   break;
> > +}
> > +
> > +  std::string outstr = a_to_an->arch_

Re: [RFC/RFA] [PR tree-optimization/92539] Improve code and avoid Warray-bounds false positive

2025-01-07 Thread Richard Biener
On Mon, Jan 6, 2025 at 5:40 PM Qing Zhao  wrote:
>
>
>
> > On Jan 6, 2025, at 11:01, Richard Biener  wrote:
> >
> > On Mon, Jan 6, 2025 at 3:43 PM Qing Zhao  wrote:
> >>
> >>
> >>
> >>> On Jan 6, 2025, at 09:21, Jeff Law  wrote:
> >>>
> >>>
> >>>
> >>> On 1/6/25 7:11 AM, Qing Zhao wrote:
> >
> > Given it doesn't cause user visible UB, we could insert the trap 
> > *before* the UB inducing statement.  That would then make the statement 
> > unreachable and it'd get removed avoiding the false positive diagnostic.
>  Yes, that’s a good idea.
>  However, in order to distinguish a user visible UB and a UB in the IL 
>  that is introduced purely by compiler, we might need some new marking in 
>  the IR?
> >>> I don't think we've ever really tackled that question; the closest I can 
> >>> think of would be things like integer overflow which we try to avoid 
> >>> allowing the compiler to introduce.  If we take the integer overflow as 
> >>> the model, then that would say we should be tackling this during loop 
> >>> unrolling.
> >>
> >> UB that is introduced by compiler transformation is one important cause of 
> >> false positive warnings.
> >>
> >> There are two approaches to tackle this problem from my understanding:
> >>
> >> 1. Avoid generating such UB from the beginning. i.e, for every compiler 
> >> transformation that might introduce such UB, we should add check to avoid 
> >> generating it.
> >>
> >> 2. Marking the IR portion that were generated by compiler transformations, 
> >> then check whether the UB is compiler generated when issue static checker 
> >> warnings.
> >>
> >> Are there other approaches?
> >
> > Note unrolling doesn't introduce UB - it makes conditional UB
> > "obvious”.
>
> So, you mean this is the same issue as PR109071 (and PR85788, PR88771, etc), 
> i.e, the compiler optimization make the conditional UB that’s originally in 
> the source code “obvious” after code duplication?
>
> (I need to study the testing case in PR92539 more carefully to make sure this 
> is the case...)
>
> If so, then the claimed false positive warning in PR92539 actually is a real 
> bug in the original source code,  and my patch that introduced the new option 
> “--fdiagnostics-details” should also include loop unrolling to provide more 
> details on the warning introduced by loop unrolling.
>
>
> >  Note -Warray-bounds wants to
> > diagnose UB, so doing path isolation and removing the UB would make
> > -Warray-bounds useless.
> >
> > So unless the condition guarding the UB unrolling exposes is visibly
> > false to the compiler but we fail
> > to exploit that (missed optimization) there's not much that we can do.
> > I think "folding" away the UB
> > like what Jeff proposes trades false negatives for the false positive
> > diagnostics.
> >
> > Note the unroller knows UB that effectively bounds the number of
> > iterations, even on conditional
> > paths and it uses this to limit the number of copies _and_ to prune
> > unreachable paths (exploiting
> > UB, avoiding diagnostics).  But one of the limitations is that it only
> > prunes paths in the last unrolled
> > copy which can be insufficient (ISTR some PR where I noticed this).
> >
> > That said - I think for these unroller exposed cases of apparent false
> > positives we should improve
> > the path pruning in the unroller itself.  For the other cases the path
> > diagnostic might help clarify
> > that the UB happens on the 'n-th' iteration of the loop when some
> > additional condition is true/false.
>
> So, the “other cases” refer to the situation similar as PR109071, i.e, 
> “conditional UB” in the original source code is made obvious after loop 
> unrolling?
> Yes, for such cases, the new option I have been trying to add, 
> “-fdiagnostic-details” should be able to track and provide more details on 
> the conditions that lead to the UB.
> Is this understanding correct?

I think so, but I didn't look into the testcase of the referenced PR.
Note the unroller explicitly tries to
prune those "bugs" given it happily exploits UB when computing the
number of iterations of a loop,
like for

int a[6];
for (int i = 0; i < n; ++i)
  a[i] = 1;

it knows the loop can at most iterate 5 times because a[i] = 1 with i
== 6 would invoke UB.

Richard.

>
> thanks.
>
> Qing
> >
> > So in the end Jeff - I think your patch isn't a good approach for the
> > issue at hand.
> >
> > Richard.
> >
> >> The above is very rough and initial idea at this moment.
> >>
> >> Qing
> >>
> >>>
> >>> jeff
>
>


[COMMITTED 06/31] ada: Fix comments about Subprogram_Variant and Exceptional_Cases

2025-01-07 Thread Marc Poulhiès
From: Piotr Trojanek 

The comment about Subprogram_Variant was outdated after more types have been
allowed by the corresponding SPARK RM rule; the comment about Exceptional_Cases
was incorrect, after being copy-pasted.

gcc/ada/ChangeLog:

* sem_prag.adb (Analyze_Exceptional_Contract, Analyze_Variant): Fix
comments.

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

---
 gcc/ada/sem_prag.adb | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
index 5b5ff320e80..04202873974 100644
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -2320,8 +2320,7 @@ package body Sem_Prag is
 
  Errors := Serious_Errors_Detected;
 
- --  Preanalyze_Assert_Expression, but without enforcing any of the two
- --  acceptable types.
+ --  Preanalyze_Assert_Expression enforcing the expression type
 
  Preanalyze_Assert_Expression (Consequence, Any_Boolean);
 
@@ -31380,7 +31379,7 @@ package body Sem_Prag is
 
  Errors := Serious_Errors_Detected;
 
- --  Preanalyze_Assert_Expression, but without enforcing any of the two
+ --  Preanalyze_Assert_Expression, but without enforcing any of the
  --  acceptable types.
 
  Preanalyze_Assert_Expression (Expr);
-- 
2.43.0



[COMMITTED 18/31] ada: Remove flag Is_Inherited_Pragma which is only set and never used

2025-01-07 Thread Marc Poulhiès
From: Piotr Trojanek 

Code cleanup; behavior is unaffected. Flag Is_Inherited_Pragma is only set in
GNAT, but is not actually used, neither by the compiler nor by any backend.

gcc/ada/ChangeLog:

* contracts.adb (Inherit_Pragma): Don't set flag Is_Inherited_Pragma.
* gen_il-fields.ads (Opt_Field_Enum): Remove field identifier.
* gen_il-gen-gen_nodes.adb (N_Pragma): Remove field from node.
* sinfo.ads (Is_Inherited_Pragma): Remove field description.
(N_Pragma): Remove field reference.

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

---
 gcc/ada/contracts.adb| 8 ++--
 gcc/ada/gen_il-fields.ads| 1 -
 gcc/ada/gen_il-gen-gen_nodes.adb | 1 -
 gcc/ada/sinfo.ads| 5 -
 4 files changed, 2 insertions(+), 13 deletions(-)

diff --git a/gcc/ada/contracts.adb b/gcc/ada/contracts.adb
index 365c3e61130..4aed4dff27b 100644
--- a/gcc/ada/contracts.adb
+++ b/gcc/ada/contracts.adb
@@ -3593,8 +3593,7 @@ package body Contracts is
   
 
   procedure Inherit_Pragma (Prag_Id : Pragma_Id) is
- Prag : constant Node_Id := Get_Pragma (From_Subp, Prag_Id);
- New_Prag : Node_Id;
+ Prag : constant Node_Id := Get_Pragma (From_Subp, Prag_Id);
 
   begin
  --  A pragma cannot be part of more than one First_Pragma/Next_Pragma
@@ -3602,10 +3601,7 @@ package body Contracts is
  --  flagged as inherited for distinction purposes.
 
  if Present (Prag) then
-New_Prag := New_Copy_Tree (Prag);
-Set_Is_Inherited_Pragma (New_Prag);
-
-Add_Contract_Item (New_Prag, Subp);
+Add_Contract_Item (New_Copy_Tree (Prag), Subp);
  end if;
   end Inherit_Pragma;
 
diff --git a/gcc/ada/gen_il-fields.ads b/gcc/ada/gen_il-fields.ads
index 70ece337e63..c778f00856d 100644
--- a/gcc/ada/gen_il-fields.ads
+++ b/gcc/ada/gen_il-fields.ads
@@ -266,7 +266,6 @@ package Gen_IL.Fields is
   Is_Ignored_Ghost_Pragma,
   Is_Implicit_With,
   Is_In_Discriminant_Check,
-  Is_Inherited_Pragma,
   Is_Initialization_Block,
   Is_Interpolated_String_Literal,
   Is_Known_Guaranteed_ABE,
diff --git a/gcc/ada/gen_il-gen-gen_nodes.adb b/gcc/ada/gen_il-gen-gen_nodes.adb
index af5049bf33e..c3a97e6e16e 100644
--- a/gcc/ada/gen_il-gen-gen_nodes.adb
+++ b/gcc/ada/gen_il-gen-gen_nodes.adb
@@ -1439,7 +1439,6 @@ begin -- Gen_IL.Gen.Gen_Nodes
 Sm (Is_Generic_Contract_Pragma, Flag),
 Sm (Is_Ignored, Flag),
 Sm (Is_Ignored_Ghost_Pragma, Flag),
-Sm (Is_Inherited_Pragma, Flag),
 Sm (Next_Pragma, Node_Id),
 Sm (Next_Rep_Item, Node_Id),
 Sm (Uneval_Old_Accept, Flag),
diff --git a/gcc/ada/sinfo.ads b/gcc/ada/sinfo.ads
index 6abda7474bb..e9b2f0f3c5c 100644
--- a/gcc/ada/sinfo.ads
+++ b/gcc/ada/sinfo.ads
@@ -1763,10 +1763,6 @@ package Sinfo is
--discriminant check has a correct value cannot be performed in this
--case (or the discriminant check may be optimized away).
 
-   --  Is_Inherited_Pragma
-   --This flag is set in an N_Pragma node that appears in a N_Contract node
-   --to indicate that the pragma has been inherited from a parent context.
-
--  Is_Initialization_Block
--Defined in block nodes. Set when the block statement was created by
--the finalization machinery to wrap initialization statements. This
@@ -2694,7 +2690,6 @@ package Sinfo is
   --  Next_Rep_Item
   --  Is_Generic_Contract_Pragma
   --  Is_Checked_Ghost_Pragma
-  --  Is_Inherited_Pragma
   --  Is_Analyzed_Pragma
   --  Class_Present set if from Aspect with 'Class
   --  Uneval_Old_Accept
-- 
2.43.0



[COMMITTED 26/31] ada: Do not raise exceptions from Exp_Aggr.Packed_Array_Aggregate_Handled

2025-01-07 Thread Marc Poulhiès
From: Eric Botcazou 

An exception is now raised during bootstrap and this causes compatibility
issues with older compilers.

gcc/ada/ChangeLog:

* exp_aggr.adb (Packed_Array_Aggregate_Handled): Remove declaration
and handler for Not_Handled local exception. Check the return value
of Get_Component_Val instead.
(Get_Component_Val): Return No_Uint instead of raising Not_Handled.

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

---
 gcc/ada/exp_aggr.adb | 29 -
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/gcc/ada/exp_aggr.adb b/gcc/ada/exp_aggr.adb
index 428115f81ba..378168fe40b 100644
--- a/gcc/ada/exp_aggr.adb
+++ b/gcc/ada/exp_aggr.adb
@@ -8962,9 +8962,6 @@ package body Exp_Aggr is
   Typ  : constant Entity_Id  := Etype (N);
   Ctyp : constant Entity_Id  := Component_Type (Typ);
 
-  Not_Handled : exception;
-  --  Exception raised if this aggregate cannot be handled
-
begin
   --  Handle one- or two dimensional bit packed array
 
@@ -8997,7 +8994,7 @@ package body Exp_Aggr is
  --  Given a expression value N of the component type Ctyp, returns a
  --  value of Csiz (component size) bits representing this value. If
  --  the value is nonstatic or any other reason exists why the value
- --  cannot be returned, then Not_Handled is raised.
+ --  cannot be returned, then No_Uint is returned.
 
  ---
  -- Get_Component_Val --
@@ -9020,7 +9017,7 @@ package body Exp_Aggr is
 if not Compile_Time_Known_Value (N)
   or else Nkind (N) = N_String_Literal
 then
-   raise Not_Handled;
+   return No_Uint;
 end if;
 
 Val := Expr_Rep_Value (N);
@@ -9098,6 +9095,9 @@ package body Exp_Aggr is
--  justified modular type processing), so we do not have to
--  worry about that here.
 
+   Val : Uint;
+   --  Temporary value
+
Lit : Node_Id;
--  Integer literal for resulting constructed value
 
@@ -9146,16 +9146,23 @@ package body Exp_Aggr is
 
if Len = 0 then
   Aggregate_Val := Uint_0;
+
else
   Expr := First (Expressions (N));
-  Aggregate_Val := Get_Component_Val (Expr) * Uint_2 ** Shift;
+  Val := Get_Component_Val (Expr);
+  if No (Val) then
+ return False;
+  end if;
+  Aggregate_Val := Val * Uint_2 ** Shift;
 
   for J in 2 .. Len loop
  Shift := Shift + Incr;
  Next (Expr);
- Aggregate_Val :=
-   Aggregate_Val +
-   Get_Component_Val (Expr) * Uint_2 ** Shift;
+ Val := Get_Component_Val (Expr);
+ if No (Val) then
+return False;
+ end if;
+ Aggregate_Val := Aggregate_Val + Val * Uint_2 ** Shift;
   end loop;
end if;
 
@@ -9182,10 +9189,6 @@ package body Exp_Aggr is
 end;
  end;
   end;
-
-   exception
-  when Not_Handled =>
- return False;
end Packed_Array_Aggregate_Handled;
 

-- 
2.43.0



[COMMITTED 08/31] ada: Reject references to attribute Result in Exceptional_Cases

2025-01-07 Thread Marc Poulhiès
From: Piotr Trojanek 

Functions with aspect Side_Effects should not reference attribute Result in
consequences of their aspect Exceptional_Cases.

gcc/ada/ChangeLog:

* sem_prag.adb (Analyze_Exceptional_Cases_In_Decl_Part): Reject
references to attribute Result.

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

---
 gcc/ada/sem_prag.adb | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
index b7de1cd8afa..64b5b01869d 100644
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -2216,7 +2216,8 @@ package body Sem_Prag is
   --  in the consequences of an exceptional contract unless they are either
   --  passed by reference or occur in the prefix of a reference to the 'Old
   --  attribute or as direct prefixes of attributes that do not actually
-  --  read data from the object (SPARK RM 6.1.9(1)).
+  --  read data from the object (SPARK RM 6.1.9(1)). References to
+  --  attribute Result should not occur either.
 
   -
   -- Check_Param --
@@ -2266,6 +2267,10 @@ package body Sem_Prag is
  then
 return Skip;
  end if;
+  when Name_Result =>
+ Error_Msg_N
+   ("attribute Result in consequence of Exceptional_Cases",
+N);
   when others => null;
end case;
 
-- 
2.43.0



[COMMITTED 14/31] ada: Remove unnecessary qualifiers for First/Next list operations

2025-01-07 Thread Marc Poulhiès
From: Piotr Trojanek 

Code cleanup related to work on expression functions for GNATprove
(which require accessibility checks even when they are not expanded
and thus have no explicit return statements).

gcc/ada/ChangeLog:

* accessibility.adb (First_Selector): Remove redundant and locally
inconsistent parenthesis.
(Check_Return_Construct_Accessibility): Remove qualifier from list
operation.
* sem_util.adb (Is_Prim_Of_Abst_Type_With_Nonstatic_CW_Pre_Post):
Likewise.

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

---
 gcc/ada/accessibility.adb | 6 +++---
 gcc/ada/sem_util.adb  | 3 +--
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/gcc/ada/accessibility.adb b/gcc/ada/accessibility.adb
index 376eb9d0bb9..1d7d3a13786 100644
--- a/gcc/ada/accessibility.adb
+++ b/gcc/ada/accessibility.adb
@@ -1213,7 +1213,7 @@ package body Accessibility is
 return First (Choices (Assoc));
 
  elsif Nkind (Assoc) = N_Discriminant_Association then
-return (First (Selector_Names (Assoc)));
+return First (Selector_Names (Assoc));
 
  else
 raise Program_Error;
@@ -1292,7 +1292,7 @@ package body Accessibility is
exit;
 end if;
 
-Nlists.Next (Return_Con);
+Next (Return_Con);
  end loop;
 
  pragma Assert (Present (Return_Con));
@@ -1693,7 +1693,7 @@ package body Accessibility is
  if not Is_List_Member (Assoc) then
 exit;
  else
-Nlists.Next (Assoc);
+Next (Assoc);
  end if;
   end loop;
end Check_Return_Construct_Accessibility;
diff --git a/gcc/ada/sem_util.adb b/gcc/ada/sem_util.adb
index 24f27d08167..a11afa8be2d 100644
--- a/gcc/ada/sem_util.adb
+++ b/gcc/ada/sem_util.adb
@@ -12654,8 +12654,7 @@ package body Sem_Util is
   and then Class_Present (Prag)
 then
Pragma_Arg :=
- Nlists.First
-   (Pragma_Argument_Associations (Prag));
+ First (Pragma_Argument_Associations (Prag));
 
if not Is_Static_Expression (Expression (Pragma_Arg)) then
   return True;
-- 
2.43.0



[COMMITTED 20/31] ada: Fix abort deferral for finally parts

2025-01-07 Thread Marc Poulhiès
From: Ronan Desplanques 

This patch fixes two problems with how abort was deferred in finally
parts. First, calls to runtime subprograms are now omitted when
aborting is disallowed by active restrictions. Second, Abort_Undefer is
now correctly called when the finally part propagates an exception.

gcc/ada/ChangeLog:

* exp_ch11.adb (Expand_N_Handled_Sequence_Of_Statements): Fix abort
deferral.

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

---
 gcc/ada/exp_ch11.adb | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/gcc/ada/exp_ch11.adb b/gcc/ada/exp_ch11.adb
index 66f38671008..189e0911fc4 100644
--- a/gcc/ada/exp_ch11.adb
+++ b/gcc/ada/exp_ch11.adb
@@ -1302,14 +1302,25 @@ package body Exp_Ch11 is
  Expand_Cleanup_Actions (Parent (N));
   end if;
 
-  if Present (Finally_Statements (N)) then
- Prepend_To
-   (Finally_Statements (N),
-Build_Runtime_Call (Sloc (N), RE_Abort_Defer));
-
- Append_To
-   (Finally_Statements (N),
-Build_Runtime_Call (Sloc (N), RE_Abort_Undefer));
+  if Present (Finally_Statements (N)) and then Abort_Allowed then
+ if Exceptions_OK then
+Set_Finally_Statements
+  (N,
+   New_List
+ (Build_Runtime_Call (Sloc (N), RE_Abort_Defer),
+  Build_Abort_Undefer_Block
+(Sloc (N),
+ Stmts   => Finally_Statements (N),
+ Context => N)));
+ else
+Prepend_To
+  (Finally_Statements (N),
+   Build_Runtime_Call (Sloc (N), RE_Abort_Defer));
+
+Append_To
+  (Finally_Statements (N),
+   Build_Runtime_Call (Sloc (N), RE_Abort_Undefer));
+ end if;
 
  Analyze_List (Finally_Statements (N));
   end if;
-- 
2.43.0



[COMMITTED 22/31] ada: Fix violations of GNAT-specific GNATcheck rules

2025-01-07 Thread Marc Poulhiès
From: Piotr Trojanek 

Code cleanup; semantics is unaffected.

gcc/ada/ChangeLog:

* diagnostics-pretty_emitter.adb (Get_Last_Line_Char): Fix whitespace.
* sem_aggr.adb (Resolve_Array_Aggregate): Fix style.

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

---
 gcc/ada/diagnostics-pretty_emitter.adb | 1 -
 gcc/ada/sem_aggr.adb   | 4 ++--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/gcc/ada/diagnostics-pretty_emitter.adb 
b/gcc/ada/diagnostics-pretty_emitter.adb
index e376ae12803..c624f400169 100644
--- a/gcc/ada/diagnostics-pretty_emitter.adb
+++ b/gcc/ada/diagnostics-pretty_emitter.adb
@@ -327,7 +327,6 @@ package body Diagnostics.Pretty_Emitter is
is
   Cur_Loc : Source_Ptr := Get_Line_End (Buf, Loc);
begin
-
   while Cur_Loc > Buf'First
 and then Buf (Cur_Loc) in ASCII.LF | ASCII.CR
   loop
diff --git a/gcc/ada/sem_aggr.adb b/gcc/ada/sem_aggr.adb
index 5bef9e22484..562240ca4ef 100644
--- a/gcc/ada/sem_aggr.adb
+++ b/gcc/ada/sem_aggr.adb
@@ -2968,8 +2968,8 @@ package body Sem_Aggr is
   Scope_Parent : Node_Id;
begin
   if Nkind (Exp) /= N_Identifier
-or else not Present (Entity (Exp))
-or else not Present (Scope (Entity (Exp)))
+or else No (Entity (Exp))
+or else No (Scope (Entity (Exp)))
 or else Ekind (Scope (Entity (Exp))) /= E_Loop
   then
  return OK;
-- 
2.43.0



Re: [PATCH] Prefer scalar_int_mode if the size - 1 is equal to UNITS_PER_WORD.

2025-01-07 Thread Jeff Law




On 1/7/25 2:09 AM, Tsung Chun Lin wrote:

Hi,

Could someone help merge this patch if there are no further concerns?
It'll get addressed.  Many contributors have been on holiday and are 
still catching up.


jeff



Re: [PATCH 1/2] Match:Support IMM=-1 for signed scalar SAT_ADD IMM form1

2025-01-07 Thread Jeff Law




On 1/2/25 1:34 AM, Li Xu wrote:

From: xuli 

This patch would like to support .SAT_ADD when IMM=-1.

Form1:
T __attribute__((noinline))  \
sat_s_add_imm_##T##_fmt_1##_##INDEX (T x) \
{\
   T sum = (UT)x + (UT)IMM; \
   return (x ^ IMM) < 0 \
 ? sum\
 : (sum ^ x) >= 0 \
   ? sum  \
   : x < 0 ? MIN : MAX;   \
}

Take below form1 as example:
DEF_SAT_S_ADD_IMM_FMT_1(0, int8_t, uint8_t, -1, INT8_MIN, INT8_MAX)

Before this patch:
__attribute__((noinline))
int8_t sat_s_add_imm_int8_t_fmt_1_0 (int8_t x)
{
   unsigned char x.0_1;
   unsigned char _2;
   unsigned char _3;
   int8_t iftmp.1_4;
   signed char _8;
   unsigned char _9;
   signed char _10;

[local count: 1073741824]:
   x.0_1 = (unsigned char) x_5(D);
   _3 = -x.0_1;
   _10 = (signed char) _3;
   _8 = x_5(D) & _10;
   if (_8 < 0)
 goto ; [1.40%]
   else
 goto ; [98.60%]

[local count: 434070867]:
   _2 = x.0_1 + 255;

[local count: 1073741824]:
   # _9 = PHI <_2(3), 128(2)>
   iftmp.1_4 = (int8_t) _9;
   return iftmp.1_4;

}

After this patch:
__attribute__((noinline))
int8_t sat_s_add_imm_int8_t_fmt_1_0 (int8_t x)
{
   int8_t _4;

[local count: 1073741824]:
   gimple_call <.SAT_ADD, _4, x_5(D), 255> [tail call]
   gimple_return <_4>

}

The below test suites are passed for this patch:
1. The rv64gcv fully regression tests.
2. The x86 bootstrap tests.
3. The x86 fully regression tests.

Signed-off-by: Li Xu 

gcc/ChangeLog:

* match.pd: Add signed scalar SAT_ADD IMM form1 with IMM=-1 matching.
* tree-ssa-math-opts.cc (match_unsigned_saturation_add): Adapt function 
name.
(match_saturation_add_with_assign): Match signed and unsigned SAT_ADD 
with assign.
(math_opts_dom_walker::after_dom_children): Match imm=-1 signed SAT_ADD 
with NOP_EXPR case.
Similarly.  This doesn't appear to be fixing a bug and should defer to 
gcc-16.


Jeff



Re: [PATCH 1/2] Match:Support signed vector SAT_ADD IMM form 1

2025-01-07 Thread Jeff Law




On 1/2/25 1:03 AM, Li Xu wrote:

From: xuli 

This patch would like to support vector SAT_ADD when one of the op
is singed IMM.

void __attribute__((noinline))   \
vec_sat_s_add_imm_##T##_fmt_1##_##INDEX (T *out, T *op_1, unsigned limit) \
{\
   unsigned i;\
   for (i = 0; i < limit; i++)\
 {\
   T x = op_1[i]; \
   T sum = (UT)x + (UT)IMM;   \
   out[i] = (x ^ IMM) < 0 \
 ? sum\
 : (sum ^ x) >= 0 \
   ? sum  \
   : x < 0 ? MIN : MAX;   \
 }\
}

Take below form1 as example:
DEF_VEC_SAT_S_ADD_IMM_FMT_1(0, int8_t, uint8_t, 9, INT8_MIN, INT8_MAX)

Before this patch:
__attribute__((noinline))
void vec_sat_s_add_imm_int8_t_fmt_1_0 (int8_t * restrict out, int8_t * restrict 
op_1, unsigned int limit)
{
   vector([16,16]) signed char * vectp_out.28;
   vector([16,16]) signed char vect_iftmp.27;
   vector([16,16])  mask__28.26;
   vector([16,16])  mask__29.25;
   vector([16,16])  mask__19.19;
   vector([16,16])  mask__31.18;
   vector([16,16]) signed char vect__6.17;
   vector([16,16]) signed char vect__5.16;
   vector([16,16]) signed char vect_sum_15.15;
   vector([16,16]) unsigned char vect__4.14;
   vector([16,16]) unsigned char vect_x.13;
   vector([16,16]) signed char vect_x_14.12;
   vector([16,16]) signed char * vectp_op_1.10;
   vector([16,16])  _78;
   vector([16,16]) unsigned char _79;
   vector([16,16]) unsigned char _80;
   unsigned long _92;
   unsigned long ivtmp_93;
   unsigned long ivtmp_94;
   unsigned long _95;

[local count: 118111598]:
   if (limit_12(D) != 0)
 goto ; [89.00%]
   else
 goto ; [11.00%]

[local count: 105119322]:
   _92 = (unsigned long) limit_12(D);

[local count: 955630226]:
   # vectp_op_1.10_62 = PHI 
   # vectp_out.28_89 = PHI 
   # ivtmp_93 = PHI 
   _95 = .SELECT_VL (ivtmp_93, POLY_INT_CST [16, 16]);
   vect_x_14.12_64 = .MASK_LEN_LOAD (vectp_op_1.10_62, 8B, { -1, ... }, _95, 0);
   vect_x.13_65 = VIEW_CONVERT_EXPR(vect_x_14.12_64);
   vect__4.14_67 = vect_x.13_65 + { 9, ... };
   vect_sum_15.15_68 = VIEW_CONVERT_EXPR(vect__4.14_67);
   vect__5.16_70 = vect_x_14.12_64 ^ { 9, ... };
   vect__6.17_71 = vect_x_14.12_64 ^ vect_sum_15.15_68;
   mask__31.18_73 = vect__5.16_70 >= { 0, ... };
   mask__19.19_75 = vect_x_14.12_64 < { 0, ... };
   mask__29.25_85 = vect__6.17_71 < { 0, ... };
   mask__28.26_86 = mask__31.18_73 & mask__29.25_85;
   _78 = ~mask__28.26_86;
   _79 = .VCOND_MASK (mask__19.19_75, { 128, ... }, { 127, ... });
   _80 = .COND_ADD (_78, vect_x.13_65, { 9, ... }, _79);
   vect_iftmp.27_87 = VIEW_CONVERT_EXPR(_80);
   .MASK_LEN_STORE (vectp_out.28_89, 8B, { -1, ... }, _95, 0, vect_iftmp.27_87);
   vectp_op_1.10_63 = vectp_op_1.10_62 + _95;
   vectp_out.28_90 = vectp_out.28_89 + _95;
   ivtmp_94 = ivtmp_93 - _95;
   if (ivtmp_94 != 0)
 goto ; [89.00%]
   else
 goto ; [11.00%]

[local count: 118111600]:
   return;

}

After this patch:
__attribute__((noinline))
void vec_sat_s_add_imm_int8_t_fmt_1_0 (int8_t * restrict out, int8_t * restrict 
op_1, unsigned int limit)
{
   vector([16,16]) signed char * vectp_out.12;
   vector([16,16]) signed char vect_patt_10.11;
   vector([16,16]) signed char vect_x_14.10;
   vector([16,16]) signed char D.2852;
   vector([16,16]) signed char * vectp_op_1.8;
   vector([16,16]) signed char _73(D);
   unsigned long _80;
   unsigned long ivtmp_81;
   unsigned long ivtmp_82;
   unsigned long _83;

[local count: 118111598]:
   if (limit_12(D) != 0)
 goto ; [89.00%]
   else
 goto ; [11.00%]

[local count: 105119322]:
   _80 = (unsigned long) limit_12(D);

[local count: 955630226]:
   # vectp_op_1.8_71 = PHI 
   # vectp_out.12_77 = PHI 
   # ivtmp_81 = PHI 
   _83 = .SELECT_VL (ivtmp_81, POLY_INT_CST [16, 16]);
   vect_x_14.10_74 = .MASK_LEN_LOAD (vectp_op_1.8_71, 8B, { -1, ... }, _73(D), 
_83, 0);
   vect_patt_10.11_75 = .SAT_ADD (vect_x_14.10_74, { 9, ... });
   .MASK_LEN_STORE (vectp_out.12_77, 8B, { -1, ... }, _83, 0, 
vect_patt_10.11_75);
   vectp_op_1.8_72 = vectp_op_1.8_71 + _83;
   vectp_out.12_78 = vectp_out.12_77 + _83;
   ivtmp_82 = ivtmp_81 - _83;
   if (ivtmp_82 != 0)
 goto ; [89.00%]
   else
 goto ; [11.00%]

[local count: 118111600]:
   return;

}

The below test suites are passed for this patch:
1. The rv64gcv fully regression tests.
2. The x86 bootstrap tests.
3. The x86 fully re

[patch, doc, Fortran] Further documentation of UNSIGNED

2025-01-07 Thread Thomas Koenig

Hello world,

the attached patch does what it says in the ChangeLog entry.

Tested with "make dvi" and "make pdf".

OK for trunk?

Best regards

Thomas


Document unsigned constants in intrinsic modules.

gcc/fortran/ChangeLog:

* intrinsic.texi (ISO_FORTRAN_ENV):  Also mention INT8 in the
text. Document UINT8, UINT16, UINT32 and UINT64.
(ISO_C_BINDING): New table for unsigned KIND numbers.
diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index 7c7e4c9372b..55933d23e18 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -15305,7 +15305,7 @@ Identifies the preconnected unit identified by the asterisk
 
 @item @code{INT8}, @code{INT16}, @code{INT32}, @code{INT64}:
 Kind type parameters to specify an INTEGER type with a storage
-size of 16, 32, and 64 bits. It is negative if a target platform
+size of 8, 16, 32, and 64 bits. It is negative if a target platform
 does not support the particular kind. (Fortran 2008 or later.)
 
 @item @code{INTEGER_KINDS}:
@@ -15368,6 +15368,12 @@ in the failed state. (TS 18508 or later.)
 @item @code{STAT_UNLOCKED}:
 Scalar default-integer constant used as @code{STAT=} return value by @code{UNLOCK} to
 denote that the lock variable is unlocked. (Fortran 2008 or later.)
+
+@item @code{UINT8}, @code{UINT16}, @code{UINT32}, @code{UINT64}:
+Kind type parameters to specify an UNSIGNED type with a storage
+size of 8, 16, 32, and 64 bits. It is negative if a target platform
+does not support the particular kind. (Extension, @pxref{Unsigned integers}.)
+
 @end table
 
 The module provides the following derived type:
@@ -15455,6 +15461,33 @@ Furthermore, if @code{_Float128} is supported in C, the named constants
 @item @code{CHARACTER}@tab @code{C_CHAR}@tab @code{char}
 @end multitable
 
+GNU Fortran also provides as an extension, named constants for
+@code{UNSIGNED} integers @pxref{Unsigned integers}.
+@multitable @columnfractions .20 0.40 0.40
+@headitem Fortran Type  @tab Named constant @tab C type
+@item @code{UNSIGNED}@tab @code{C_UNSIGNED}		@tab @code{unsigned int}
+@item @code{UNSIGNED}@tab @code{C_UNSIGNED_SHORT} 	@tab @code{unsigned short}
+@item @code{UNSIGNED}@tab @code{C_UNSIGNED_CHAR}	@tab @code{unsigned char}
+@item @code{UNSINGED}@tab @code{C_UNSIGNED_LONG}	@tab @code{unsigned long}
+@item @code{UNSINGED}@tab @code{C_UNSIGNED_LONG_LONG}	@tab @code{unsigned long long}
+@item @code{UNSIGNED}@tab @code{C_UINTMAX_T}		@tab @code{uintmax_t}
+@item @code{UNSIGNED}@tab @code{C_UINT8_T}		@tab @code{uint8_t}
+@item @code{UNSIGNED}@tab @code{C_UINT16_T}		@tab @code{uint16_t}
+@item @code{UNSIGNED}@tab @code{C_UINT32_T}		@tab @code{uint32_t}
+@item @code{UNSIGNED}@tab @code{C_UINT64_T}		@tab @code{uint64_t}
+@item @code{UNSIGNED}@tab @code{C_UINT128_T}		@tab @code{uint128_t}
+@item @code{UNSIGNED}@tab @code{C_UINT_FAST8_T}		@tab @code{uint_fast8_t}
+@item @code{UNSIGNED}@tab @code{C_UINT_FAST16_T}	@tab @code{uint_fast16_t}
+@item @code{UNSIGNED}@tab @code{C_UINT_FAST32_T}	@tab @code{uint_fast32_t}
+@item @code{UNSIGNED}@tab @code{C_UINT_FAST64_T}	@tab @code{uint_fast64_t}
+@item @code{UNSIGNED}@tab @code{C_UINT_FAST128_T}	@tab @code{uint_fast128_t}
+@item @code{UNSIGNED}@tab @code{C_UINT_LEAST8_T}	@tab @code{uint_least8_t}
+@item @code{UNSIGNED}@tab @code{C_UINT_LEAST16_T}	@tab @code{uint_least16_t}
+@item @code{UNSIGNED}@tab @code{C_UINT_LEAST32_T}	@tab @code{uint_least32_t}
+@item @code{UNSIGNED}@tab @code{C_UINT_LEAST64_T}	@tab @code{uint_least64_t}
+@item @code{UNSIGNED}@tab @code{C_UINT_LEAST128_T}	@tab @code{uint_least128_t}
+@end multitable
+
 Additionally, the following parameters of type @code{CHARACTER(KIND=C_CHAR)}
 are defined.
 


Re: [PATCH] riscv: add mising masking in lrsc expander (PR118137)

2025-01-07 Thread Kito Cheng
LGTM

Patrick O'Neill  於 2025年1月8日 週三 00:12 寫道:

>
> On 1/7/25 07:37, Andreas Schwab wrote:
> > gcc:
> >   PR target/118137
> >   * config/riscv/sync.md ("lrsc_atomic_exchange"): Apply mask
> >   to shifted value.
> >
> > gcc/testsuite:
> >   PR target/118137
> >   * gcc.dg/atomic/pr118137.c: New.
> > ---
> Thanks for fixing this - I can't give approvals but LGTM FWIW.
>


Re: [PATCH] libstdc++: add missing to_underlying to module std [PR106852]

2025-01-07 Thread Jonathan Wakely
On Sat, 4 Jan 2025 at 20:06, Nicolas Werner  wrote:
>
> std::to_underlying was missing from the std module introduced in
> 7db55c0ba1baaf0e323ef7f9ef8c9cda077d40e9. This patch adds the missing
> export for this utility.
>
> There might be more exports missing, but this is the one I found when
> trying to compile some test projects.

Thanks! I'll push this.


>
> PR libstdc++/106852
>
> libstdc++-v3/ChangeLog:
>
> * src/c++23/std.cc.in: Add std::to_underlying
>
> Signed-off-by: Nicolas Werner 
> ---
>  libstdc++-v3/src/c++23/std.cc.in | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/libstdc++-v3/src/c++23/std.cc.in 
> b/libstdc++-v3/src/c++23/std.cc.in
> index 0e5b41c5b3b..e251c1c1981 100644
> --- a/libstdc++-v3/src/c++23/std.cc.in
> +++ b/libstdc++-v3/src/c++23/std.cc.in
> @@ -3171,6 +3171,9 @@ export namespace std
>using std::make_pair;
>using std::piecewise_construct;
>using std::piecewise_construct_t;
> +#if __cpp_lib_to_underlying
> +  using std::to_underlying;
> +#endif
>using std::tuple_element;
>using std::tuple_size;
>  #pragma GCC diagnostic push
> --
> 2.47.1
>
>
>
>



[PATCH] testsuite: enable effective-target sync_char_short on RISC-V

2025-01-07 Thread Andreas Schwab
* lib/target-supports.exp
(check_effective_target_sync_char_short): Enable for riscv*-*-*.
---
 gcc/testsuite/lib/target-supports.exp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 5ce7b7976f9..b84b6ef5a8a 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -10033,6 +10033,7 @@ proc check_effective_target_sync_char_short { } {
 || ([istarget sparc*-*-*] && [check_effective_target_sparc_v9])
 || ([istarget arc*-*-*] && [check_effective_target_arc_atomic])
 || [istarget loongarch*-*-*]
+|| [istarget riscv*-*-*]
 || [check_effective_target_mips_llsc] }}]
 }
 
-- 
2.47.1


-- 
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] riscv: add mising masking in lrsc expander (PR118137)

2025-01-07 Thread Andreas Schwab
gcc:
PR target/118137
* config/riscv/sync.md ("lrsc_atomic_exchange"): Apply mask
to shifted value.

gcc/testsuite:
PR target/118137
* gcc.dg/atomic/pr118137.c: New.
---
 gcc/config/riscv/sync.md   |  1 +
 gcc/testsuite/gcc.dg/atomic/pr118137.c | 29 ++
 2 files changed, 30 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/atomic/pr118137.c

diff --git a/gcc/config/riscv/sync.md b/gcc/config/riscv/sync.md
index 58f32d253f1..726800a9662 100644
--- a/gcc/config/riscv/sync.md
+++ b/gcc/config/riscv/sync.md
@@ -467,6 +467,7 @@
 
   rtx shifted_value = gen_reg_rtx (SImode);
   riscv_lshift_subword (mode, value, shift, &shifted_value);
+  emit_move_insn (shifted_value, gen_rtx_AND (SImode, shifted_value, mask));
 
   emit_insn (gen_subword_atomic_exchange_strong (old, aligned_mem,
 shifted_value, model,
diff --git a/gcc/testsuite/gcc.dg/atomic/pr118137.c 
b/gcc/testsuite/gcc.dg/atomic/pr118137.c
new file mode 100644
index 000..7cdb2240aa3
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/atomic/pr118137.c
@@ -0,0 +1,29 @@
+/* Test that subword atomic operations only affect the subword.  */
+/* { dg-do run } */
+/* { dg-require-effective-target sync_char_short } */
+
+void
+foo (char *x)
+{
+  __sync_fetch_and_or (x, 0xff);
+}
+
+void
+bar (short *y)
+{
+  __atomic_fetch_or (y, 0x, 0);
+}
+
+
+int
+main ()
+{
+  char b[4] = {};
+  foo(b);
+
+  short h[2] = {};
+  bar(h);
+
+  if (b[1] || b[2] || b[3] || h[1])
+__builtin_abort();
+}
-- 
2.47.1


-- 
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."


[PING] [PATCH] c++: Relax checking assert about elision to support -fno-elide-constructors [PR114619]

2025-01-07 Thread Simon Martin
Hi,

On 11 Nov 2024, at 20:35, Simon Martin wrote:

> Hi,
>
> On 30 Oct 2024, at 11:46, Simon Martin wrote:
>
>> On 19 Oct 2024, at 11:09, Simon Martin wrote:
>>
>>> We currently ICE in checking mode with cxx_dialect < 17 on the
>>> following
>>> valid code
>>>
>>> === cut here ===
>>> struct X {
>>>   X(const X&) {}
>>> };
>>> extern X x;
>>> void foo () {
>>>   new X[1]{x};
>>> }
>>> === cut here ===
>>>
>>> The problem is that cp_gimplify_expr gcc_checking_asserts that a
>>> TARGET_EXPR is not TARGET_EXPR_ELIDING_P (or cannot be elided), while
>>> in
>>> this case with cxx_dialect < 17, it is TARGET_EXPR_ELIDING_P but we
>>> have
>>> not even tried to elide.
>>>
>>> This patch relaxes that gcc_checking_assert to not fail when using
>>> cxx_dialect < 17 and -fno-elide-constructors (I considered being more
>>> clever at setting TARGET_EXPR_ELIDING_P appropriately but it looks
>>> more
>>> risky and not worth the extra complexity for a checking assert).
>>>
>>> Successfully tested on x86_64-pc-linux-gnu.
>> Friendly ping. Thanks!
> Friendly ping. Thanks!
Ping. Thanks!

Simon
>>
>>>
>>> PR c++/114619
>>>
>>> gcc/cp/ChangeLog:
>>>
>>> * cp-gimplify.cc (cp_gimplify_expr): Relax gcc_checking_assert
>>> to support the usage of -fno-elide-constructors with c++ < 17.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> * g++.dg/init/no-elide3.C: New test.
>>>
>>> ---
>>>  gcc/cp/cp-gimplify.cc |  7 ++-
>>>  gcc/testsuite/g++.dg/init/no-elide3.C | 11 +++
>>>  2 files changed, 17 insertions(+), 1 deletion(-)
>>>  create mode 100644 gcc/testsuite/g++.dg/init/no-elide3.C
>>>
>>> diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc
>>> index 003e68f1ea7..354ea73c63b 100644
>>> --- a/gcc/cp/cp-gimplify.cc
>>> +++ b/gcc/cp/cp-gimplify.cc
>>> @@ -908,7 +908,12 @@ cp_gimplify_expr (tree *expr_p, gimple_seq
>>> *pre_p, gimple_seq *post_p)
>>>  gimplify_init_ctor_preeval can materialize subobjects of a
>>> CONSTRUCTOR
>>>  on the rhs of an assignment, as in constexpr-aggr1.C.  */
>>>gcc_checking_assert (!TARGET_EXPR_ELIDING_P (*expr_p)
>>> -  || !TREE_ADDRESSABLE (TREE_TYPE (*expr_p)));
>>> +  || !TREE_ADDRESSABLE (TREE_TYPE (*expr_p))
>>> +  /* If we explicitly asked not to elide and it's not
>>> + required by the standard, we can't expect elision
>>> + to have happened.  */
>>> +  || (cxx_dialect < cxx17
>>> +  && !flag_elide_constructors));
>>>ret = GS_UNHANDLED;
>>>break;
>>>
>>> diff --git a/gcc/testsuite/g++.dg/init/no-elide3.C
>>> b/gcc/testsuite/g++.dg/init/no-elide3.C
>>> new file mode 100644
>>> index 000..9377d9f0161
>>> --- /dev/null
>>> +++ b/gcc/testsuite/g++.dg/init/no-elide3.C
>>> @@ -0,0 +1,11 @@
>>> +// PR c++/114619
>>> +// { dg-do "compile" { target c++11 } }
>>> +// { dg-options "-fno-elide-constructors" }
>>> +
>>> +struct X {
>>> +  X(const X&) {}
>>> +};
>>> +extern X x;
>>> +void foo () {
>>> +  new X[1]{x};
>>> +}
>>> -- 
>>> 2.44.0


[PING] [PATCH v8] c++: Fix overeager Woverloaded-virtual with conversion operators [PR109918]

2025-01-07 Thread Simon Martin
Hi,

On 11 Nov 2024, at 20:36, Simon Martin wrote:

> Hi,
>
> On 30 Oct 2024, at 11:44, Simon Martin wrote:
>
>> Friendly ping.
> Friendly ping.
Ping. Thanks!

Simon
>>
>> On 16 Oct 2024, at 17:43, Simon Martin wrote:
>>
>>> Hi Jason,
>>>
>>> On 12 Oct 2024, at 4:51, Jason Merrill wrote:
>>>
 On 10/11/24 7:02 AM, Simon Martin wrote:
> Hi Jason,
>
> On 11 Oct 2024, at 0:35, Jason Merrill wrote:
>
>> On 10/7/24 3:35 PM, Simon Martin wrote:
>>> On 7 Oct 2024, at 18:58, Jason Merrill wrote:
 On 10/7/24 11:27 AM, Simon Martin wrote:
>>
>   /* Now give a warning for all base functions without 
> overriders,
>  as they are hidden.  */
>   for (tree base_fndecl : base_fndecls)
> +   {
> + if (!base_fndecl || overriden_base_fndecls.contains
> (base_fndecl))
> +   continue;
> + tree *hider = hidden_base_fndecls.get (base_fndecl);
> + if (hider)

 How about looping over hidden_base_fndecls instead of 
 base_fndecls?
>>
>>> Unfortunately it does not work because a given base method can 
>>> be
>>> hidden
>>> by one overload and overriden by another, in which case we 
>>> don’t
>>> want
>>> to warn (see for example AA:foo(int) in Woverloaded-virt7.C). So 
>>> we
>>>
>>> need
>>> to take both collections into account.
>>
>> Yes, you'd still need to check overridden_base_fndecls.contains, 
>> but
>>>
>> that doesn't seem any different iterating over 
>> hidden_base_fndecls
>> instead of base_fndecls.
> Sure, and I guess iterating over hidden_base_fndecls is more 
> coherent
>>>
>
> with what the warning is about. Changed in the attached updated 
> patch,
> successfully tested on x86_64-pc-linux-gnu. OK?

 OK, thanks.
>>> As you know the patch had to be reverted due to PR117114, that
>>> highlighted a bunch of issues with comparing DECL_VINDEXes: it might
>>> give false positives in case of multiple inheritance (the case in
>>> PR117114), but also if there’s single inheritance by the hierarchy 
>>> has
>>> more than two levels (another issue I found while bootstrapping with
>>> rust enabled).
>>>
>>> The attached updated patch introduces an overrides_p function, based 
>>> on
>>> the existing check_final_overrider, and uses it when the signatures 
>>> match.
>>>
>>> It’s been successfully tested on x86_64-pc-linux-gnu, and 
>>> bootstrap
>>> works fine with —enable-languages=all (and rust properly 
>>> configured, so
>>> included here). OK for trunk?
>>>
>>> Thanks, Simon



[PING] [PATCH] c++: Only prune capture proxies for constant variables at instantiation time [PR114292]

2025-01-07 Thread Simon Martin
Hi,

On 13 Dec 2024, at 13:50, Simon Martin wrote:

> Hi Marek,
>
> On 13 Dec 2024, at 0:44, Marek Polacek wrote:
>
>> On Thu, Dec 12, 2024 at 07:07:38PM +, 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
>>
>> Ah yeah, because build_min_non_dep gets the original operands.
>>
>>> remove the proxy declaration while it should not, and we trip on an
>>> assert at instantiation time.
>>>
>>> This patch fixes the ICE by making sure that lambdas are only marked
>>> as
>>> LAMBDA_EXPR_CAPTURE_OPTIMIZED when they're instantiated (I tried
>>> other
>>> strategies like not undoing constant folding in build_min_non_dep,
>
>>> but
>>> it is pretty intrusive and breaks lots of things).
>>
>> I've tried that too and I also ran into a number of issues.  I also
>
>> tried
>> checking p_t_d in prune_lambda_capture since it already says "Don't
>
>> bother
>> pruning in a template" but that doesn't work, either.
> Yeah, the fundamental “problem” is that for lambdas that are not
> within a template, we generate the closure before instantiating the
> lambda function, so prune_lambda_capture thinks (without my patch) that
> captures to constants have been folded out, which might be the case
> (e.g. with ok_3 in the test I added) or not (e.g. in this PR) depending
> on whether they’re part of an expression for which build_min_non_dep
> has been called.
>
>>> The test I added also shows that we don't always optimize out
>>> captures
>>> to constants for lambdas that are not within a template (see ok_2 for
>
>>> example, or ok_3 that unlike ok_2 "regresses" a bit with my patch) -
>>> I'm
>>> curious if we consider it a problem or not? If so, I can try to fix
>>> this
>>> in a follow-up patch.
>>
>> Since "P0588R1: Simplifying implicit lambda capture" they are
>> captures,
>> though [expr.prim.lambda.capture] gives us license to optimize the
>> captures if not ODR-used.  I couldn't find a test where this patch
>> would be an ABI change.
> Thanks for the pointer! Yeah, whether we optimise out the captures or
>
> not remains legit.
>
> And if you look specifically at ok_3 from the test case (without the
> patch, the capture is optimised out, with it it’s not anymore):
>   - I don’t think it’s an ABI change since we don’t do anything
> with captures in mangle.cc.
>   - Since captures are only relevant within the function calling them,
> we don’t have any issue if we link together object files generated
> without the patch and object files generated with the patch.
>
>>> Successfully tested on x86_64-pc-linux-gnu.
>>>
>>> PR c++/114292
>>>
>>> gcc/cp/ChangeLog:
>>>
>>> * cp-tree.h (mark_const_var_capture_optimized): Declare.
>>> * expr.cc (mark_use): Call mark_const_var_capture_optimized.
>>> * lambda.cc (mark_const_var_capture_optimized): New. Only set
>>> LAMBDA_EXPR_CAPTURE_OPTIMIZED at lambda instantiation time.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> * g++.dg/cpp1y/lambda-ice4.C: New test.
>>>
>>> ---
>>>  gcc/cp/cp-tree.h |  1 +
>>>  gcc/cp/expr.cc   | 10 ++
>>>  gcc/cp/lambda.cc | 13 +++
>>>  gcc/testsuite/g++.dg/cpp1y/lambda-ice4.C | 44
>>> 
>>>  4 files changed, 60 insertions(+), 8 deletions(-)
>>>  create mode 100644 gcc/testsuite/g++.dg/cpp1y/lambda-ice4.C
>>>
>>> diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
>>> index c5e0fc5c440..ce050032fdb 100644
>>> --- a/gcc/cp/cp-tree.h
>>> +++ b/gcc/cp/cp-tree.h
>>> @@ -8058,6 +8058,7 @@ extern bool is_constant_capture_proxy
>>> (tree);
>>>  extern void register_capture_members   (tree);
>>>  extern tree lambda_expr_this_capture(tree, int);
>>>  extern void maybe_generic_this_capture (tree, tree);
>>> +extern void mark_const_var_capture_optimized   (void);
>>>  extern tree maybe_resolve_dummy(tree, bool);
>>>  extern tree current_nonlambda_function (void);
>>>  extern tree nonlambda_method_basetype  (void);
>>> diff --git a/gcc/cp/expr.cc b/gcc/cp/expr.cc
>>> index de4991e616c..d6a2454c46e 100644
>>> --- a/gcc/cp/expr.cc
>>> +++ b/gcc/cp/expr.cc
>>> @@ -120,10 +120,7 @@ mark_use (tree expr, bool rvalue_p, bool read_p,
>
>>> {
>>>   tree val = RECUR (cap);
>>>   if (!is_capture_proxy (val))
>>> -   {
>>> - tree l = current_lambda_expr ();
>>> - LAMBDA_EXPR_CAPTURE_OPTIMIZED (l) = true;
>>> -   }
>>> +   mark_const_va

[PING] [PATCH] c++: Make sure fold_sizeof_expr returns the correct type [PR117775]

2025-01-07 Thread Simon Martin
Hi,

On 11 Dec 2024, at 22:27, Simon Martin wrote:

> Hi,
>
> On 29 Nov 2024, at 15:33, Simon Martin wrote:
>
>> We currently ICE upon the following code, that is valid under
>> -Wno-pointer-arith:
>>
>> === cut here ===
>> int main() {
>>   decltype( [](auto) { return sizeof(void); } ) x;
>>   return x.operator()(0);
>> }
>> === cut here ===
>>
>> The problem is that "fold_sizeof_expr (sizeof(void))" returns
>> size_one_node, that has a different TREE_TYPE from that of the sizeof
>> expression, which later triggers an assert in
>> cxx_eval_store_expression.
>>
>> This patch makes sure that fold_sizeof_expr always returns a tree with
>> the type requested.
>>
>> Successfully tested on x86_64-pc-linux-gnu.
> Ping.
Ping. Thanks!

Simon
>>
>>  PR c++/117775
>>
>> gcc/cp/ChangeLog:
>>
>>  * decl.cc (fold_sizeof_expr): Make sure the folded result has
>>  the requested TREE_TYPE.
>>
>> gcc/testsuite/ChangeLog:
>>
>>  * g++.dg/cpp2a/constexpr-117775.C: New test.
>>
>> ---
>>  gcc/cp/decl.cc|  1 +
>>  gcc/testsuite/g++.dg/cpp2a/constexpr-117775.C | 13 +
>>  2 files changed, 14 insertions(+)
>>  create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-117775.C
>>
>> diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
>> index 80485f0a428..fbe1407a2d2 100644
>> --- a/gcc/cp/decl.cc
>> +++ b/gcc/cp/decl.cc
>> @@ -11686,6 +11686,7 @@ fold_sizeof_expr (tree t)
>>  false, false);
>>if (r == error_mark_node)
>>  r = size_one_node;
>> +  r = cp_fold_convert (TREE_TYPE (t), r);
>>return r;
>>  }
>>
>> diff --git a/gcc/testsuite/g++.dg/cpp2a/constexpr-117775.C
>> b/gcc/testsuite/g++.dg/cpp2a/constexpr-117775.C
>> new file mode 100644
>> index 000..59fc0d332b9
>> --- /dev/null
>> +++ b/gcc/testsuite/g++.dg/cpp2a/constexpr-117775.C
>> @@ -0,0 +1,13 @@
>> +// PR c++/117775
>> +// Check that we don't ICE and have sizeof(void)==1 under
>> -Wno-pointer-arith
>> +// { dg-do run { target c++20 } }
>> +// { dg-additional-options "-Wno-pointer-arith" }
>> +
>> +int main() {
>> +  struct why :
>> +decltype( [](auto) {
>> +return sizeof(void);
>> +  })
>> +  {} x;
>> +  return 1 - x.operator()(0);
>> +}
>> -- 
>> 2.44.0


Re: [PATCH] gcc-wwwdocs: Fix typo in GCC version number.

2025-01-07 Thread Gerald Pfeifer
On Tue, 7 Jan 2025, Simon Martin wrote:
> Noticed while trying to understand when I can expect the GCC 15 branch
> to be created: the GCC 15 release criteria page still mentions GCC 14.
> 
> I'll push this as obvious.

Thank you, Simon!

> Are such pages created via a script? If so I am happy to fix it as well.

Unless our release managers (Jakub on this case) have been taken over by 
ChatGPT/Gemini/you-name-it I believe this is manual work following 
  https://gcc.gnu.org/releasing.html
though I just noticed criteria.html (and creating the directory for 
the new release) isn't actually covered.

That could be a nice contribution to add...

Gerald


Re: [PATCH] gcc-wwwdocs: Fix typo in GCC version number.

2025-01-07 Thread Gerald Pfeifer
On Tue, 7 Jan 2025, Gerald Pfeifer wrote:
>> Are such pages created via a script? If so I am happy to fix it as well.
> Unless our release managers (Jakub on this case) have been taken over by 
> ChatGPT/Gemini/you-name-it I believe this is manual work following 
>   https://gcc.gnu.org/releasing.html
> though I just noticed criteria.html (and creating the directory for 
> the new release) isn't actually covered.

My bad: This is actually part of branching for a new release, which is
covered by

  https://gcc.gnu.org/branching.html

Gerald


Re: [Patch] libgomp.texi: Minor update to omp_get_num_devices/omp_get_initial_device

2025-01-07 Thread Tobias Burnus

Now committed as r15-6659-gd3ccd89fa0d34d – with an additional typo fix:

stipe → stripe (OpenMP 6.0 loop transformation directive).

Tobias
commit d3ccd89fa0d34d44226af47fe82c27ba7833fe65
Author: Tobias Burnus 
Date:   Tue Jan 7 16:43:30 2025 +0100

libgomp.texi: Minor update to omp_get_num_devices/omp_get_initial_device

libgomp/ChangeLog:

* libgomp.texi (OpenMP 6.0): Fix typo.
(omp_get_default_device): Update the wording as the value
returned by omp_get_initial_device is now ambiguous.
(omp_get_num_devices): Minor wording tweak.
(omp_get_initial_device): Note that the function may also
return omp_initial_device since OpenMP 6.
---
 libgomp/libgomp.texi | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 9a42355ff5d..7d8cd70287e 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -550,7 +550,7 @@ to address of matching mapped list item per 5.1, Sect. 2.21.7.2 @tab N @tab
 @item @code{interchange} loop-transformation construct @tab N @tab
 @item @code{reverse} loop-transformation construct @tab N @tab
 @item @code{split} loop-transformation construct @tab N @tab
-@item @code{stipe} loop-transformation construct @tab N @tab
+@item @code{stripe} loop-transformation construct @tab N @tab
 @item @code{tile} permitting association of grid and inter-tile loops @tab N @tab
 @item @code{strict} modifier keyword to @code{num_threads} @tab N @tab
 @item @code{safesync} clause to the @code{parallel} construct @tab N @tab
@@ -1760,10 +1760,9 @@ The effect of running this routine in a @code{target} region is unspecified.
 Get the value of the @emph{default-device-var} ICV, which is used
 for target regions without a device clause. The value is either a
 nonnegative device number, @code{omp_initial_device} or
-@code{omp_invalid_device}. Note that for the host, the ICV can have two values
-and, hence, this routine might return either the value of the named constant
-@code{omp_initial_device} or the value returned by the
-@code{omp_get_initial_device} routine.
+@code{omp_invalid_device}. Note that for the host, the ICV can have two values:
+either the value of the named constant @code{omp_initial_device} or the value
+returned by the @code{omp_get_num_devices} routine.
 
 The effect of running this routine in a @code{target} region is unspecified.
 
@@ -1791,7 +1790,7 @@ The effect of running this routine in a @code{target} region is unspecified.
 @subsection @code{omp_get_num_devices} -- Number of target devices
 @table @asis
 @item @emph{Description}:
-Returns the number of target devices.
+Returns the number of available non-host devices.
 
 The effect of running this routine in a @code{target} region is unspecified.
 
@@ -1938,7 +1937,8 @@ run-time function is desired.
 @item @emph{Description}:
 This function returns a device number that represents the host device.
 Since OpenMP 5.1, this is equal to the value returned by the
-@code{omp_get_num_devices} function.
+@code{omp_get_num_devices} function; since OpenMP 6.0 it may also return
+the value of @code{omp_initial_device}.
 
 The effect of running this routine in a @code{target} region is unspecified.
 


[COMMITTED 01/31] ada: Restrict previous change made to expansion of allocators

2025-01-07 Thread Marc Poulhiès
From: Eric Botcazou 

There is no need to build a cleanup if exceptions cannot be propagated.

gcc/ada/ChangeLog:

* exp_ch4.adb (Expand_Allocator_Expression): Do not build a cleanup
if restriction No_Exception_Propagation is active.
* exp_ch6.adb (Make_Build_In_Place_Call_In_Allocator): Likewise.

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

---
 gcc/ada/exp_ch4.adb | 1 +
 gcc/ada/exp_ch6.adb | 1 +
 2 files changed, 2 insertions(+)

diff --git a/gcc/ada/exp_ch4.adb b/gcc/ada/exp_ch4.adb
index 75d79019f80..6e8c5c83da5 100644
--- a/gcc/ada/exp_ch4.adb
+++ b/gcc/ada/exp_ch4.adb
@@ -636,6 +636,7 @@ package body Exp_Ch4 is
   and then Nkind (Exp) = N_Function_Call
   and then not (Is_Entity_Name (Name (Exp))
  and then No_Raise (Entity (Name (Exp
+  and then not Restriction_Active (No_Exception_Propagation)
   and then RTE_Available (RE_Free)
   and then not Debug_Flag_QQ);
   --  Return True if a cleanup needs to be built to deallocate the memory
diff --git a/gcc/ada/exp_ch6.adb b/gcc/ada/exp_ch6.adb
index a339a223f09..37184fd28eb 100644
--- a/gcc/ada/exp_ch6.adb
+++ b/gcc/ada/exp_ch6.adb
@@ -8505,6 +8505,7 @@ package body Exp_Ch6 is
and then not For_Special_Return_Object (Allocator)
and then not (Is_Entity_Name (Name (Func_Call))
   and then No_Raise (Entity (Name (Func_Call
+   and then not Restriction_Active (No_Exception_Propagation)
and then RTE_Available (RE_Free)
and then not Debug_Flag_QQ
  then
-- 
2.43.0



[COMMITTED 21/31] ada: Remove dead code in detection of null record definitions

2025-01-07 Thread Marc Poulhiès
From: Piotr Trojanek 

Code cleanup; behavior is unaffected.

gcc/ada/ChangeLog:

* sem_util.adb (Is_Null_Record_Definition): Remove check for
Component_List being present after using it; replace check for
component item being a component declaration with an assertion;
fix style in comment.

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

---
 gcc/ada/sem_util.adb | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/gcc/ada/sem_util.adb b/gcc/ada/sem_util.adb
index a11afa8be2d..55e9979a215 100644
--- a/gcc/ada/sem_util.adb
+++ b/gcc/ada/sem_util.adb
@@ -18984,22 +18984,19 @@ package body Sem_Util is
function Is_Null_Record_Definition (Record_Def : Node_Id) return Boolean is
   Item : Node_Id;
begin
-  --  Testing Null_Present is just an optimization, not required.
+  --  Testing Null_Present is just an optimization, not required
 
   if Null_Present (Record_Def) then
  return True;
   elsif Present (Variant_Part (Component_List (Record_Def))) then
  return False;
-  elsif No (Component_List (Record_Def)) then
- return True;
   end if;
 
   Item := First_Non_Pragma (Component_Items (Component_List (Record_Def)));
 
   while Present (Item) loop
- if Nkind (Item) = N_Component_Declaration
-   and then Is_Internal_Name (Chars (Defining_Identifier (Item)))
- then
+ pragma Assert (Nkind (Item) = N_Component_Declaration);
+ if Is_Internal_Name (Chars (Defining_Identifier (Item))) then
 null;
  else
 return False;
-- 
2.43.0



Patch ping^3 (Re: [PATCH] analyzer: Handle nonnull_if_nonzero attribute [PR117023])

2025-01-07 Thread Jakub Jelinek
On Wed, Dec 18, 2024 at 12:15:15PM +0100, Jakub Jelinek wrote:
> On Fri, Dec 06, 2024 at 05:07:40PM +0100, Jakub Jelinek wrote:
> > I'd like to ping the
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668699.html
> > patch.
> > 
> > The patches it depended on are already committed and there is a patch
> > which depends on this (the builtins shift from nonnull to nonnull_if_nonzero
> > where needed) which has been approved but can't be committed.
> 
> Gentle ping on this one.

Ping.

Thanks

> > > 2024-11-14  Jakub Jelinek  
> > > 
> > >   PR c/117023
> > > gcc/analyzer/
> > >   * sm-malloc.cc (malloc_state_machine::on_stmt): Handle
> > >   also nonnull_if_nonzero attributes.
> > > gcc/testsuite/
> > >   * c-c++-common/analyzer/call-summaries-malloc.c
> > >   (test_use_without_check): Pass 4 rather than sz to memset.
> > >   * c-c++-common/analyzer/strncpy-1.c (test_null_dst,
> > >   test_null_src): Pass 42 rather than count to strncpy.

Jakub



[COMMITTED 15/31] ada: Handle attributes related to Ada 2012 iterators as internal

2025-01-07 Thread Marc Poulhiès
From: Piotr Trojanek 

Use existing machinery for internal attributes to handle attributes
related to Ada 2012 iterators. All these attributes exist exclusively
as a mean to delay processing.

Code cleanup. The only change in behavior is the wording of error
emitted when one of the internal attributes appears in source code:
from "illegal attribute" (which used to be emitted in the analysis)
to "unrecognized attribute (which is emitted by the parser).

gcc/ada/ChangeLog:

* exp_attr.adb (Expand_N_Attribute_Reference): Remove explicit
handling of attributes related to Ada 2012 iterators.
* sem_attr.adb (Analyze_Attribute, Eval_Attribute): Likewise;
move attribute Reduce according to alphabetic order.
* snames.adb-tmpl (Get_Attribute_Id): Add support for new internal
attributes.
* snames.ads-tmpl: Recognize names of new internal attributes.
(Attribute_Id): Recognize new internal attributes.
(Internal_Attribute_Id): Likewise.
(Is_Internal_Attribute_Name): Avoid duplication in comment.

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

---
 gcc/ada/exp_attr.adb| 12 
 gcc/ada/sem_attr.adb| 32 +++-
 gcc/ada/snames.adb-tmpl | 33 -
 gcc/ada/snames.ads-tmpl | 32 +++-
 4 files changed, 46 insertions(+), 63 deletions(-)

diff --git a/gcc/ada/exp_attr.adb b/gcc/ada/exp_attr.adb
index 904293bbd1d..911b9dcf807 100644
--- a/gcc/ada/exp_attr.adb
+++ b/gcc/ada/exp_attr.adb
@@ -2266,18 +2266,6 @@ package body Exp_Attr is
 
   case Id is
 
-  --  Attributes related to Ada 2012 iterators. They are only allowed in
-  --  attribute definition clauses and should never be expanded.
-
-  when Attribute_Constant_Indexing
- | Attribute_Default_Iterator
- | Attribute_Implicit_Dereference
- | Attribute_Iterable
- | Attribute_Iterator_Element
- | Attribute_Variable_Indexing
-  =>
- raise Program_Error;
-
   --  Internal attributes used to deal with Ada 2012 delayed aspects. These
   --  were already rejected by the parser. Thus they shouldn't appear here.
 
diff --git a/gcc/ada/sem_attr.adb b/gcc/ada/sem_attr.adb
index 7295784704f..53b96501d78 100644
--- a/gcc/ada/sem_attr.adb
+++ b/gcc/ada/sem_attr.adb
@@ -3423,18 +3423,6 @@ package body Sem_Attr is
 
   case Attr_Id is
 
-  --  Attributes related to Ada 2012 iterators. Attribute specifications
-  --  exist for these, but they cannot be queried.
-
-  when Attribute_Constant_Indexing
- | Attribute_Default_Iterator
- | Attribute_Implicit_Dereference
- | Attribute_Iterator_Element
- | Attribute_Iterable
- | Attribute_Variable_Indexing
-  =>
- Error_Msg_N ("illegal attribute", N);
-
   --  Internal attributes used to deal with Ada 2012 delayed aspects. These
   --  were already rejected by the parser. Thus they shouldn't appear here.
 
@@ -9015,19 +9003,6 @@ package body Sem_Attr is
 
   case Id is
 
-  --  Attributes related to Ada 2012 iterators; nothing to evaluate for
-  --  these.
-
-  when Attribute_Constant_Indexing
- | Attribute_Default_Iterator
- | Attribute_Implicit_Dereference
- | Attribute_Iterator_Element
- | Attribute_Iterable
- | Attribute_Reduce
- | Attribute_Variable_Indexing
-  =>
- null;
-
   --  Internal attributes used to deal with Ada 2012 delayed aspects.
   --  These were already rejected by the parser. Thus they shouldn't
   --  appear here.
@@ -10208,6 +10183,13 @@ package body Sem_Attr is
  end case;
   end Range_Length;
 
+  
+  -- Reduce --
+  
+
+  when Attribute_Reduce =>
+ null;
+
   -
   -- Ref --
   -
diff --git a/gcc/ada/snames.adb-tmpl b/gcc/ada/snames.adb-tmpl
index d49fdf4d74a..62ca4de4866 100644
--- a/gcc/ada/snames.adb-tmpl
+++ b/gcc/ada/snames.adb-tmpl
@@ -125,15 +125,30 @@ package body Snames is
 
function Get_Attribute_Id (N : Name_Id) return Attribute_Id is
begin
-  if N = Name_CPU then
- return Attribute_CPU;
-  elsif N = Name_Dispatching_Domain then
- return Attribute_Dispatching_Domain;
-  elsif N = Name_Interrupt_Priority then
- return Attribute_Interrupt_Priority;
-  else
- return Attribute_Id'Val (N - First_Attribute_Name);
-  end if;
+  case N is
+ when Name_Constant_Indexing =>
+return Attribute_Constant_Indexing;
+ when Name_CPU =>
+return Attribute_CPU;
+ when Name_Default_Iterator =>
+return Attribute_Default_Iterator;
+ when Name_Dispatching_Domain =>
+return Attribute_Dispatching_Domain;
+ when Name_Implicit_Dereference =>
+return Attribute_Implicit_Dereference;

[COMMITTED 09/31] ada: Elide the copy for bit-packed aggregates in (safe) assignments

2025-01-07 Thread Marc Poulhiès
From: Eric Botcazou 

The in-place expansion has been historically disabled for them, but there
does not seem to be any good reason left for this.

gcc/ada/ChangeLog:

* exp_aggr.adb (Expand_Array_Aggregate): Do not exclude aggregates
of bit-packed array types in assignments from in-place expansion.

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

---
 gcc/ada/exp_aggr.adb | 1 -
 1 file changed, 1 deletion(-)

diff --git a/gcc/ada/exp_aggr.adb b/gcc/ada/exp_aggr.adb
index f771660d23a..a51e02bc308 100644
--- a/gcc/ada/exp_aggr.adb
+++ b/gcc/ada/exp_aggr.adb
@@ -6129,7 +6129,6 @@ package body Exp_Aggr is
 Nkind (Parent_Node) = N_Assignment_Statement
   and then (Is_Limited_Type (Typ)
  or else (not Has_Default_Init_Comps (N)
-   and then not Is_Bit_Packed_Array (Typ)
and then
  In_Place_Assign_OK
(N, Get_Base_Object (Name (Parent_Node);
-- 
2.43.0



[COMMITTED 10/31] ada: Add "finally" GNAT extension

2025-01-07 Thread Marc Poulhiès
From: Ronan Desplanques 

This patch adds a new reserved word, "finally", and accompanying new
syntax that's similar to the Java equivalent.

gcc/ada/ChangeLog:

* atree.adb (Parent_Or_List_Containing): New function.
* atree.ads (Parent_Or_List_Containing): Likewise.
* gen_il-fields.ads: Add new field.
* gen_il-gen-gen_nodes.adb (Gen_Nodes): Extend handled sequence of
statements node.
* par-ch11.adb (P_Handled_Sequence_Of_Statements, P_Exception_Handler):
Add new syntactic construct.
* par-ch5.adb (P_Sequence_Of_Statements): Likewise.
* par.adb: Likewise.
* par-util.adb (Check_Future_Keyword): Warn that "finally" becomes a
reserved word with extensions.
* scans.adb (Initialize_Ada_Keywords): Add new reserved word.
* snames.adb-tmpl: Likewise.
* snames.ads-tmpl: Likewise.
* scans.ads: Likewise.
* sem_ch11.adb (Analyze_Handled_Statements): Adapt to new node field.
* sem_ch5.adb (Analyze_Exit_Statement): Add legality check.
(Analyze_Goto_Statement): Likewise.
* sem_ch6.adb (Analyze_Return_Statement): Likewise.
* sinfo-utils.adb (Lowest_Common_Ancestor, Destroy_Element): New
subprograms.
* sinfo-utils.ads (Lowest_Common_Ancestor): New function.
* sinfo.ads: Add documentation for new field.
* xsnamest.adb: Fix typo in comment.
* doc/gnat_rm/gnat_language_extensions.rst: Document new extension.
* warnsw.adb: Add new option.
* warnsw.ads: Likewise.
* exp_ch11.adb (Expand_N_Handled_Sequence_Of_Statements): Add abort
deferral to finally part.
* gnat_rm.texi: Regenerate.
* gnat_ugn.texi: Regenerate.
* gcc-interface/trans.cc (Handled_Sequence_Of_Statements_to_gnu):
Handle finally statements.

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

---
 gcc/ada/atree.adb |  15 ++
 gcc/ada/atree.ads |   5 +
 .../doc/gnat_rm/gnat_language_extensions.rst  |  43 ++
 gcc/ada/exp_ch11.adb  |  12 ++
 gcc/ada/gcc-interface/trans.cc|  23 
 gcc/ada/gen_il-fields.ads |   1 +
 gcc/ada/gen_il-gen-gen_nodes.adb  |   1 +
 gcc/ada/gnat_rm.texi  | 129 +-
 gcc/ada/gnat_ugn.texi |   2 +-
 gcc/ada/par-ch11.adb  |  11 +-
 gcc/ada/par-ch5.adb   |  19 +++
 gcc/ada/par-util.adb  |   8 ++
 gcc/ada/par.adb   |  20 +--
 gcc/ada/scans.adb |   3 +
 gcc/ada/scans.ads |   1 +
 gcc/ada/sem_ch11.adb  |   4 +
 gcc/ada/sem_ch5.adb   |  56 +++-
 gcc/ada/sem_ch6.adb   |  17 +++
 gcc/ada/sinfo-utils.adb   |  68 +
 gcc/ada/sinfo-utils.ads   |   4 +
 gcc/ada/sinfo.ads |   4 +
 gcc/ada/snames.adb-tmpl   |   4 +-
 gcc/ada/snames.ads-tmpl   |  10 ++
 gcc/ada/warnsw.adb|   1 +
 gcc/ada/warnsw.ads|   6 +
 gcc/ada/xsnamest.adb  |   2 +-
 26 files changed, 421 insertions(+), 48 deletions(-)

diff --git a/gcc/ada/atree.adb b/gcc/ada/atree.adb
index 8cc22394b0c..c2e026bcc6d 100644
--- a/gcc/ada/atree.adb
+++ b/gcc/ada/atree.adb
@@ -2076,6 +2076,21 @@ package body Atree is
   end if;
end Node_Parent;
 
+   ---
+   -- Parent_Or_List_Containing --
+   ---
+
+   function Parent_Or_List_Containing (X : Union_Id) return Union_Id is
+   begin
+  if X in Node_Range then
+ return Link (Node_Id (X));
+  elsif X in List_Range then
+ return Union_Id (List_Parent (List_Id (X)));
+  else
+ raise Program_Error;
+  end if;
+   end Parent_Or_List_Containing;
+
-
-- Present --
-
diff --git a/gcc/ada/atree.ads b/gcc/ada/atree.ads
index 834cc3150f5..3adfb824a17 100644
--- a/gcc/ada/atree.ads
+++ b/gcc/ada/atree.ads
@@ -456,6 +456,11 @@ package Atree is
--  Parent has the same name as the one in Nlists; Node_Parent can be used
--  more easily in the debugger.
 
+   function Parent_Or_List_Containing (X : Union_Id) return Union_Id;
+   --  X must be in Node_Range or in List_Range. If X is in Node_Range and is
+   --  contained in a list, returns that list, otherwise return the parent of
+   --  the list or node represented by X.
+
function Paren_Count (N : Node_Id) return Nat;
pragma Inline (Paren_Count);
--  Number of parentheses that surround an expression
diff --git a/gcc/ada/doc/gnat_rm/gnat_language_extensions.rst 
b/gcc/ada/doc/gnat_rm/gnat_language_ext

C++ patch ping

2025-01-07 Thread Jakub Jelinek
Hi!

I'd like to ping 10 C++ patches:

https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672040.html
  P1 - Fix ICEs with large initializer lists or ones including #embed [PR118124]

https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672041.html
  P1 - Fix up maybe_init_list_as_array for RAW_DATA_CST [PR118124]

https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671089.html
  P2 - c++: check_flexarray fixes [PR117516]

https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671442.html
  P3 - Clear zero padding in empty types [PR118002]

Stage1:

https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662379.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662380.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662381.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662545.html
  P2552R3 - On the ignorability of standard attributes - series [PR110345]

https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662507.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662750.html
  CWG 2867 - Order of initialization for structured bindings - rest of 
implementation [PR115769]

Thanks

Jakub



[COMMITTED 05/31] ada: Put_Image spec incorrectly ignored for Fixed_Point_Type'Base'Image call.

2025-01-07 Thread Marc Poulhiès
From: Steve Baird 

If a Put_Image aspect specification (introduced in Ada 2022) is given for a
fixed point type Fx, then in some cases a call to Fx'Base'Image would
incorrectly ignore the aspect specification and would instead return the
pre-Ada2022 version of the image. However, a call to Fx'Image would do the
right thing.

gcc/ada/ChangeLog:

* exp_put_image.adb (Image_Should_Call_Put_Image): Cope with the case
where the attribute prefix for an Image attribute reference
denotes an Itype constructed for a fixed point type. Calling
Has_Aspect with such an Itype misses applicable aspect
specifications; we need to look on the right list. This comes up
if the prefix of the attribute reference is
Some_Fixed_Point_Type'Base.

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

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

diff --git a/gcc/ada/exp_put_image.adb b/gcc/ada/exp_put_image.adb
index dff9bba55a8..ef4494b7f11 100644
--- a/gcc/ada/exp_put_image.adb
+++ b/gcc/ada/exp_put_image.adb
@@ -1176,11 +1176,28 @@ package body Exp_Put_Image is
   declare
  U_Type : constant Entity_Id := Underlying_Type (Entity (Prefix (N)));
   begin
- if Has_Aspect (U_Type, Aspect_Put_Image) then
+ if Has_Aspect (U_Type, Aspect_Put_Image)
+   or else not Is_Scalar_Type (U_Type)
+ then
+return True;
+ end if;
+
+ --  Deal with Itypes. One case where this is needed is for a
+ --  fixed-point type with a Put_Image aspect specification.
+
+ --  ??? Should we be checking for Itype case here, or in Has_Aspect?
+ --  In other words, do we want to do what we are doing here for all
+ --  aspects, not just for Put_Image?
+
+ if Is_Itype (U_Type)
+   and then Has_Aspect (Defining_Identifier
+  (Associated_Node_For_Itype (U_Type)),
+Aspect_Put_Image)
+ then
 return True;
  end if;
 
- return not Is_Scalar_Type (U_Type);
+ return False;
   end;
end Image_Should_Call_Put_Image;
 
-- 
2.43.0



[COMMITTED 19/31] ada: Improved checking of uses of package renamings

2025-01-07 Thread Marc Poulhiès
From: Steve Baird 

In some cases, the RM 8.5.1(3.1) legality rule about uses of renamings of
limited views of packages was implemented incorrectly, resulting in rejecting
legal uses.

gcc/ada/ChangeLog:

* gen_il-fields.ads: add new Renames_Limited_View field.
* gen_il-gen-gen_entities.adb: add Renames_Limited_View flag for
packages.
* einfo.ads: add comment documenting Renames_Limited_View flag.
* sem_ch8.adb (Analyze_Package_Renaming): Set new Renames_Limited_View
flag. Test new Renames_Limited_View flag instead of calling
Has_Limited_With. If Has_Limited_With is True, that just means
that somebody, sometime during this compilation needed to
reference the limited view of the package; so that function
returns True too often to be used here.
(Find_Expanded_Name): Test new Renames_Limited_View flag instead of
calling Has_Limited_With.

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

---
 gcc/ada/einfo.ads   | 9 +
 gcc/ada/gen_il-fields.ads   | 1 +
 gcc/ada/gen_il-gen-gen_entities.adb | 1 +
 gcc/ada/sem_ch8.adb | 7 ---
 4 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/gcc/ada/einfo.ads b/gcc/ada/einfo.ads
index 1946e68b3c7..a7c0584d8da 100644
--- a/gcc/ada/einfo.ads
+++ b/gcc/ada/einfo.ads
@@ -4247,6 +4247,15 @@ package Einfo is
 --   within an accept statement. For all remaining cases (discriminants,
 --   loop parameters) the field is Empty.
 
+--Renames_Limited_View
+--   Defined in package entities. True for a package renaming if either
+--   a) the renamed package is not itself a renaming, and the renaming
+--  denotes a limited view of the renamed package (as seen at the
+--  point of the renaming declaration, as opposed to later on when
+--  the renaming is referenced); or
+--   b) the renamed package is itself a renaming and the
+--  Renames_Limited_View flag is True for the renamed package.
+
 --Requires_Overriding
 --   Defined in all subprograms and entries. Set for subprograms that
 --   require overriding as defined by RM-2005-3.9.3(6/2). Note that this
diff --git a/gcc/ada/gen_il-fields.ads b/gcc/ada/gen_il-fields.ads
index c778f00856d..fe2da80c548 100644
--- a/gcc/ada/gen_il-fields.ads
+++ b/gcc/ada/gen_il-fields.ads
@@ -879,6 +879,7 @@ package Gen_IL.Fields is
   Relative_Deadline_Variable,
   Renamed_In_Spec,
   Renamed_Or_Alias, -- Shared among Alias, Renamed_Entity, Renamed_Object
+  Renames_Limited_View,
   Requires_Overriding,
   Return_Applies_To,
   Return_Present,
diff --git a/gcc/ada/gen_il-gen-gen_entities.adb 
b/gcc/ada/gen_il-gen-gen_entities.adb
index 8cf66b2611d..3df1f8e7284 100644
--- a/gcc/ada/gen_il-gen-gen_entities.adb
+++ b/gcc/ada/gen_il-gen-gen_entities.adb
@@ -1281,6 +1281,7 @@ begin -- Gen_IL.Gen.Gen_Entities
 Sm (Related_Instance, Node_Id),
 Sm (Renamed_In_Spec, Flag),
 Sm (Renamed_Or_Alias, Node_Id),
+Sm (Renames_Limited_View, Flag),
 Sm (Scope_Depth_Value, Unat),
 Sm (SPARK_Aux_Pragma, Node_Id),
 Sm (SPARK_Aux_Pragma_Inherited, Flag),
diff --git a/gcc/ada/sem_ch8.adb b/gcc/ada/sem_ch8.adb
index 533b62aef32..c6b8f6c5d7c 100644
--- a/gcc/ada/sem_ch8.adb
+++ b/gcc/ada/sem_ch8.adb
@@ -1665,8 +1665,7 @@ package body Sem_Ch8 is
  Set_Etype (New_P, Standard_Void_Type);
 
   elsif Present (Renamed_Entity (Old_P))
-and then (From_Limited_With (Renamed_Entity (Old_P))
-or else Has_Limited_View (Renamed_Entity (Old_P)))
+and then Renames_Limited_View (Old_P)
 and then not
   Unit_Is_Visible (Cunit (Get_Source_Unit (Renamed_Entity (Old_P
   then
@@ -1691,8 +1690,10 @@ package body Sem_Ch8 is
 
  if Present (Renamed_Entity (Old_P)) then
 Set_Renamed_Entity (New_P, Renamed_Entity (Old_P));
+Set_Renames_Limited_View (New_P, Renames_Limited_View (Old_P));
  else
 Set_Renamed_Entity (New_P, Old_P);
+Set_Renames_Limited_View (New_P, From_Limited_With (Old_P));
  end if;
 
  --  The package renaming declaration may become Ghost if it renames a
@@ -7077,7 +7078,7 @@ package body Sem_Ch8 is
   ("renaming of limited view of package & not usable in this"
& " context (RM 8.5.3(3.1/2))", Prefix (N), P_Name);
 
- elsif Has_Limited_View (P_Name)
+ elsif Renames_Limited_View (Entity (Prefix (N)))
and then not Unit_Is_Visible (Cunit (Get_Source_Unit (P_Name)))
and then not Is_Visible_Through_Renamings (P_Name)
  then
-- 
2.43.0



Re: C++ patch ping

2025-01-07 Thread Jakub Jelinek
On Tue, Jan 07, 2025 at 02:07:58PM +0100, Jakub Jelinek wrote:
> Stage1:
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662379.html
> https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662380.html
> https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662381.html
> https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662545.html

Sorry, the last URL was left there by mistake, just the first 3 (all just
additions of testcases) are left from PR110345.

>   P2552R3 - On the ignorability of standard attributes - series [PR110345]

Jakub



[COMMITTED 24/31] ada: Fix constants overlayed by variables

2025-01-07 Thread Marc Poulhiès
From: Piotr Trojanek 

Code cleanup suggested by GNATcheck rule Constant_Overlays.

gcc/ada/ChangeLog:

* repinfo-input.adb (Decode_Name, Read_Name_With_Prefix): Use constant
overlay with pragma Import.

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

---
 gcc/ada/repinfo-input.adb | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/ada/repinfo-input.adb b/gcc/ada/repinfo-input.adb
index 78de4412228..c5cc34a6350 100644
--- a/gcc/ada/repinfo-input.adb
+++ b/gcc/ada/repinfo-input.adb
@@ -341,7 +341,8 @@ package body Repinfo.Input is
 
  else
 declare
-   S : String (Integer (Lo) .. Integer (Hi));
+   S : constant String (Integer (Lo) .. Integer (Hi));
+   pragma Import (Ada, S);
for S'Address use Text (Lo)'Address;
 
 begin
@@ -627,7 +628,8 @@ package body Repinfo.Input is
 
  else
 declare
-   S : String (Integer (Lo) .. Integer (Hi));
+   S : constant String (Integer (Lo) .. Integer (Hi));
+   pragma Import (Ada, S);
for S'Address use Text (Lo)'Address;
 
 begin
-- 
2.43.0



[COMMITTED 23/31] ada: Improve protection against wrong use from GDB

2025-01-07 Thread Marc Poulhiès
From: Piotr Trojanek 

A code cleanup in routine intended to be used from DGB, suggested by running
GNATcheck rule Boolean_Negations. However, this code can be tuned to protect
against more illegal uses.

gcc/ada/ChangeLog:

* exp_disp.adb (Write_DT): Add guards that prevent crashes on illegal
node numbers.

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

---
 gcc/ada/exp_disp.adb | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gcc/ada/exp_disp.adb b/gcc/ada/exp_disp.adb
index f45c32356a9..6d0f2c87017 100644
--- a/gcc/ada/exp_disp.adb
+++ b/gcc/ada/exp_disp.adb
@@ -8674,9 +8674,10 @@ package body Exp_Disp is
 
begin
   --  Protect this procedure against wrong usage. Required because it will
-  --  be used directly from GDB
+  --  be used directly from GDB.
 
-  if not (Typ <= Last_Node_Id)
+  if Typ not in First_Node_Id .. Last_Node_Id
+or else Nkind (Typ) not in N_Entity
 or else not Is_Tagged_Type (Typ)
   then
  Write_Str ("wrong usage: Write_DT must be used with tagged types");
-- 
2.43.0



Re: Mark const parameters passed by invisible reference as readonly in the function body

2025-01-07 Thread Richard Biener
On Tue, 10 Dec 2024, Jan Hubicka wrote:

> Hi,
> int:
> struct foo
> {
>   int a;
>   void bar() const;
>   ~foo()
>   {
> if (a != 42)
>   __builtin_abort ();
>   }
> };
> __attribute__ ((noinline))
> void test(const struct foo a)
> {
> int b = a.a;
> a.bar();
> if (a.a != b)
>   __builtin_printf ("optimize me away");
> }
> struct foo is passed by invisible reference. As discussed in the PR,
> since it is declared const, it can not change before function test
> returns.  This makes it possible to optimize out the conditional.

Doesn't this break the case where 'a' is declared mutable?

Richard.

> We already support this for fnspec "r" attribute. This patch simply adds
> same logic for const parameters passed by invisible reference.
> To simplify the implementation I also extended attr-fnspec to allow
> NULL in the constructor, so we can use same loop no matter when fnspec
> is present.
> 
> Bootstrapped/regtested x86_64-linux, OK?
> 
> gcc/ChangeLog:
> 
>   PR tree-optimization/103827
>   * attr-fnspec.h (attr_fnspec constructor): Allow NULL_TREE.
>   * tree-into-ssa.cc (pass_build_ssa::execute): Also set
>   SSA_NAME_POINTS_TO_READONLY_MEMORY for parameters passed by
>   invisible reference and declared const.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/tree-ssa/pr103827.C: New test.
> 
> 
> diff --git a/gcc/attr-fnspec.h b/gcc/attr-fnspec.h
> index aef4701e6d1..76053d88b09 100644
> --- a/gcc/attr-fnspec.h
> +++ b/gcc/attr-fnspec.h
> @@ -93,8 +97,8 @@ public:
>verify ();
>}
>attr_fnspec (const_tree identifier)
> -  : str (TREE_STRING_POINTER (identifier)),
> -len (TREE_STRING_LENGTH (identifier))
> +  : str (identifier ? TREE_STRING_POINTER (identifier) : NULL),
> +len (identifier ? TREE_STRING_LENGTH (identifier) : 0)
>{
>  if (flag_checking)
>verify ();
> diff --git a/gcc/tree-into-ssa.cc b/gcc/tree-into-ssa.cc
> index df1fb186962..0267a86f1cc 100644
> --- a/gcc/tree-into-ssa.cc
> +++ b/gcc/tree-into-ssa.cc
> @@ -2555,25 +2556,23 @@ pass_build_ssa::execute (function *fun)
>   SET_SSA_NAME_VAR_OR_IDENTIFIER (name, DECL_NAME (decl));
>  }
>  
> -  /* Initialize SSA_NAME_POINTS_TO_READONLY_MEMORY.  */
> +  /* Initialize SSA_NAME_POINTS_TO_READONLY_MEMORY using fnspec or for
> + values passed by invisible reference declared const.  */
>tree fnspec_tree
>= lookup_attribute ("fn spec",
>TYPE_ATTRIBUTES (TREE_TYPE (fun->decl)));
> -  if (fnspec_tree)
> -{
> -  attr_fnspec fnspec (TREE_VALUE (TREE_VALUE (fnspec_tree)));
> -  unsigned i = 0;
> -  for (tree arg = DECL_ARGUMENTS (cfun->decl);
> -arg; arg = DECL_CHAIN (arg), ++i)
> +  attr_fnspec fnspec (fnspec_tree ? TREE_VALUE (TREE_VALUE (fnspec_tree)) : 
> NULL);
> +  i = 0;
> +  for (tree arg = DECL_ARGUMENTS (cfun->decl);
> +   arg; arg = DECL_CHAIN (arg), ++i)
> +{
> +  if ((fnspec.arg_specified_p (i) && fnspec.arg_readonly_p (i))
> +   || (DECL_BY_REFERENCE (arg)
> +   && TYPE_READONLY (TREE_TYPE (TREE_TYPE (arg)
>   {
> -   if (!fnspec.arg_specified_p (i))
> -break;
> -   if (fnspec.arg_readonly_p (i))
> - {
> -   tree name = ssa_default_def (fun, arg);
> -   if (name)
> - SSA_NAME_POINTS_TO_READONLY_MEMORY (name) = 1;
> - }
> +   tree name = ssa_default_def (fun, arg);
> +   if (name)
> + SSA_NAME_POINTS_TO_READONLY_MEMORY (name) = 1;
>   }
>  }
> diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr103827.C 
> b/gcc/testsuite/g++.dg/tree-ssa/pr103827.C
> new file mode 100644
> index 000..6059fe514b1
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/tree-ssa/pr103827.C
> @@ -0,0 +1,22 @@
> +// { dg-do compile }
> +// { dg-options "-O1 -fdump-tree-optimized" }
> +struct foo
> +{
> +  int a;
> +  void bar() const;
> +  ~foo()
> +  {
> +if (a != 42)
> +  __builtin_abort ();
> +  }
> +};
> +__attribute__ ((noinline))
> +void test(const struct foo a)
> +{
> +int b = a.a;
> +a.bar();
> +if (a.a != b)
> +  __builtin_printf ("optimize me away");
> +}
> +
> +/* { dg-final { scan-tree-dump-not "optimize me away" "optimized" } } */
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)


[PATCH] middle-end/118325 - nonlocal goto lowering

2025-01-07 Thread Richard Biener
When nonlocal goto lowering creates an artificial label it fails
to adjust its context.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress
(I doubt good test coverage is present for non-local gotos)

OK when testing succeeds?

Thanks,
Richard.

PR middle-end/118325
* tree-nested.cc (convert_nl_goto_reference): Assign proper
context to generated artificial label.

* gcc.dg/pr118325.c: New testcase.
---
 gcc/testsuite/gcc.dg/pr118325.c | 16 
 gcc/tree-nested.cc  |  1 +
 2 files changed, 17 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/pr118325.c

diff --git a/gcc/testsuite/gcc.dg/pr118325.c b/gcc/testsuite/gcc.dg/pr118325.c
new file mode 100644
index 000..74f92cc2bb6
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr118325.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-std=gnu17 -fchecking" } */
+
+void f(void*);
+
+void z()
+{
+void g()
+{
+__label__ out;
+int h(void) { goto out; }
+f(h);
+out:;
+}
+f(g);
+}
diff --git a/gcc/tree-nested.cc b/gcc/tree-nested.cc
index d538c8d2a47..8d75a2f3310 100644
--- a/gcc/tree-nested.cc
+++ b/gcc/tree-nested.cc
@@ -2694,6 +2694,7 @@ convert_nl_goto_reference (gimple_stmt_iterator *gsi, 
bool *handled_ops_p,
 {
   new_label = create_artificial_label (UNKNOWN_LOCATION);
   DECL_NONLOCAL (new_label) = 1;
+  DECL_CONTEXT (new_label) = target_context;
   *slot = new_label;
 }
   else
-- 
2.43.0


[COMMITTED 04/31] ada: Error on instantiation with defaulted formal type referencing other formal type

2025-01-07 Thread Marc Poulhiès
From: Gary Dismukes 

The compiler wasn't accounting for default subtypes on generic formal types
that reference other formal types of the same generic, leading to errors
about invalid subtypes. Several other problems that could lead to blowups
or incorrect errors were noticed through testing related cases and fixed
along the way.

gcc/ada/ChangeLog:

* sem_ch12.adb (Analyze_One_Association): In the case of a formal type
that has a Default_Subtype_Mark that does not have its Entity field set,
this means the default refers to another formal type of the same generic
formal part, so locate the matching subtype in the Result_Renamings and
set Match's Entity to that subtype prior to the call to 
Instantiate_Type.
(Validate_Formal_TypeDefault.Reference_Formal): Add test of Entity being
Present, to prevent blowups on End_Label ids (which don't have Entity 
set).
(Validate_Formal_Type_Default.Validate_Derived_Type_Default): Apply
Base_Type to Formal.
(Validate_Formal_Type_Default): Guard interface-related semantic checks
with a test of Is_Tagged_Type.

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

---
 gcc/ada/sem_ch12.adb | 78 
 1 file changed, 64 insertions(+), 14 deletions(-)

diff --git a/gcc/ada/sem_ch12.adb b/gcc/ada/sem_ch12.adb
index 625d291fc28..41ace8cc250 100644
--- a/gcc/ada/sem_ch12.adb
+++ b/gcc/ada/sem_ch12.adb
@@ -2512,6 +2512,52 @@ package body Sem_Ch12 is
 
if Present (Default_Subtype_Mark (Assoc.Un_Formal)) then
   Match := New_Copy (Default_Subtype_Mark (Assoc.Un_Formal));
+
+  --  If the Entity of the default subtype denoted by the
+  --  unanalyzed formal has not been set, then it must refer
+  --  to another formal type of the enclosing generic. So we
+  --  locate the subtype "renaming" in Result_Renamings that
+  --  corresponds to the formal type (by comparing the simple
+  --  names), and set Match's Entity to the entity denoted by
+  --  that subtype's subtype_indication (which will denote the
+  --  actual subtype corresponding to the other formal type).
+  --  This must be done before calling Instantiate_Type, since
+  --  that function relies heavily on the entity being set.
+  --  (Note also that there's similar code inside procedure
+  --  Validate_Derived_Type_Instance that deals with retrieving
+  --  the ancestor type of formal derived types.)
+
+  if No (Entity (Match)) then
+ declare
+pragma Assert (Is_Non_Empty_List (Result_Renamings));
+
+Decl : Node_Id := First (Result_Renamings);
+
+ begin
+--  Locate subtype referenced by the default subtype
+--  in the list of renamings.
+
+while Present (Decl) loop
+   if Nkind (Decl) = N_Subtype_Declaration
+ and then
+   Chars (Match) =
+ Chars (Defining_Identifier (Decl))
+   then
+  Set_Entity
+(Match,
+ Entity (Subtype_Indication (Decl)));
+
+  exit;
+
+   else
+  Next (Decl);
+   end if;
+end loop;
+
+pragma Assert (Present (Entity (Match)));
+ end;
+  end if;
+
   Append_List
(Instantiate_Type
   (Assoc.Un_Formal, Match, Assoc.An_Formal,
@@ -18161,6 +18207,7 @@ package body Sem_Ch12 is
   function Reference_Formal (N : Node_Id) return Traverse_Result is
   begin
  if Is_Entity_Name (N)
+   and then Present (Entity (N))
and then Scope (Entity (N)) = Current_Scope
  then
 return Abandon;
@@ -18356,7 +18403,7 @@ package body Sem_Ch12 is
 
   procedure Validate_Derived_Type_Default is
   begin
- if not Is_Ancestor (Etype (Formal), Def_Sub) then
+ if not Is_Ancestor (Etype (Base_Type (Formal)), Def_Sub) then
 Error_Msg_NE ("default must be a descendent of&",
   Default, Etype (Formal));
  end if;
@@ -18529,20 +18576,23 @@ package body Sem_Ch12 is
 end if;
 
  when N_Record_Definition =>   -- Formal interface type
-if not Is_Interface (Def_Sub) then
-   Error_Msg_NE
- ("default for formal interface type must be an interface",
-  Default, Formal

[COMMITTED 25/31] ada: Cleanup preanalysis of static expressions (part 2)

2025-01-07 Thread Marc Poulhiès
From: Javier Miranda 

According to RM 13.14(8/4), a static expression in an aspect specification
does not cause freezing; however, the frontend performs many calls to
Preanalyze_Spec_Expression made during the analysis of aspects. This
patch, suggested by Eric Botcazou, takes care of this additional code
cleanup which requires also replacing many occurrences of the global
variable In_Spec_Expression by calls to Preanalysis_Active.

gcc/ada/ChangeLog:

* exp_util.adb (Insert_Actions): Document behavior under strict
preanalysis.
* sem.ads (In_Strict_Preanalysis): New subprogram.
(Preanalysis_Active): Replace 'and' operator by 'and then'.
* sem.adb (In_Strict_Preanalysis): Ditto.
* sem_attr.adb (Check_Dereference): Replace In_Spec_Expression
occurrence by call to Preanalysis_Active, and document it.
(Resolve_Attribute [Atribute_Access]): Ditto.
(Eval_Attribute): No evaluation under strict preanalysis.
(Validate_Static_Object_Name): No action under strict preanalysis.
* sem_ch13.adb (Check_Aspect_At_End_Of_Declarations): Replace
calls to Preanalyze_Spec_Expression by calls to Preanalyze_And_Resolve.
(Check_Aspect_At_Freeze_Point): Ditto.
(Resolve_Aspect_Expressions [Dynamic/Static/Predicate aspects]): Code
cleanup adjusting the code to emulate Preanalyze_And_Resolve, instead
of Preanalyze_Spec_Expression.
(Resolve_Aspect_Expressions [CPU/Interrupt_Priority/Priority/
Storage_Size aspects]): Replace calls to Preanalyze_Spec_Expression
by call to Preanalyze_And _Resolve.
* sem_ch3.adb (Analyze_Object_Declaration): Replace In_Spec_Expression
occurrence by call to Preanalysis_Active.
(Find_Type_Of_Object): Add documentation.
* sem_ch4.adb (Analyze_Case_Expression): Replace In_Spec_Expression
occurrence by call to Preanalysis_Active.
* sem_ch6.adb (Analyze_Expression_Function): Minor code reorganization
moving the code preanalyzing the expression after the new body has
been inserted in the tree to ensure that its Parent attribute is
available for preanalysis.
* sem_cat.adb (Validate_Static_Object_Name): No action under strict
preanalysis.
* sem_elab.adb (Check_For_Eliminated_Subprogram): Replace 
In_Spec_Expression
occurrence by call to Preanalysis_Active.
* sem_eval.adb (Eval_Intrinsic_Call [Name_Enclosing_Entity]): Ditto.
* sem_elim.adb (Check_For_Eliminated_Subprogram): Ditto.
* sem_res.adb (Resolve_Entity_Name): Ditto.

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

---
 gcc/ada/exp_util.adb | 16 +++
 gcc/ada/sem.adb  | 11 ++-
 gcc/ada/sem.ads  |  5 +
 gcc/ada/sem_attr.adb | 25 
 gcc/ada/sem_cat.adb  |  1 +
 gcc/ada/sem_ch13.adb | 25 +++-
 gcc/ada/sem_ch3.adb  |  7 +--
 gcc/ada/sem_ch4.adb  |  2 +-
 gcc/ada/sem_ch6.adb  | 46 ++--
 gcc/ada/sem_elab.adb |  2 +-
 gcc/ada/sem_elim.adb |  5 +++--
 gcc/ada/sem_eval.adb |  2 +-
 gcc/ada/sem_res.adb  |  2 +-
 13 files changed, 87 insertions(+), 62 deletions(-)

diff --git a/gcc/ada/exp_util.adb b/gcc/ada/exp_util.adb
index 66ba73226ed..69d6e25794e 100644
--- a/gcc/ada/exp_util.adb
+++ b/gcc/ada/exp_util.adb
@@ -7708,20 +7708,20 @@ package body Exp_Util is
  return;
   end if;
 
-  --  Insert the action when the context is "Handling of Default and Per-
-  --  Object Expressions" only when requested by the caller.
-
-  if Spec_Expr_OK then
- null;
-
   --  Ignore insert of actions from inside default expression (or other
   --  similar "spec expression") in the special spec-expression analyze
   --  mode. Any insertions at this point have no relevance, since we are
   --  only doing the analyze to freeze the types of any static expressions.
   --  See section "Handling of Default and Per-Object Expressions" in the
-  --  spec of package Sem for further details.
+  --  spec of package Sem for further details. However, if the user does
+  --  nevertheless request the insert, then obey it.
+
+  --  Under strict preanalysis we cannot ignore insert of actions because
+  --  we may be adding to the tree a subtype declaration that is required
+  --  for proper preanalysis (see Sem_Ch3.Find_Type_Of_Object).
 
-  elsif In_Spec_Expression then
+  if In_Spec_Expression and then not Spec_Expr_OK then
+ pragma Assert (not In_Strict_Preanalysis);
  return;
   end if;
 
diff --git a/gcc/ada/sem.adb b/gcc/ada/sem.adb
index a7e3df9f06e..9b013995b8a 100644
--- a/gcc/ada/sem.adb
+++ b/gcc/ada/sem.adb
@@ -1338,13 +1338,22 @@ package body Sem is
   Scope_Stack.Locked := True;
end Lock;
 
+   ---
+   -- In_Strict_Preanalysis --
+   ---
+

Re: [PATCH] RISC-V: Add missing dg-runtest to run the testcase under gcc.target/riscv/rvv/

2025-01-07 Thread Jeff Law




On 1/2/25 10:46 PM, Tsung Chun Lin wrote:

 From c05d80e696b226444af26a981d78875a5767bf82 Mon Sep 17 00:00:00 2001
From: Jim Tsung-Chun Lin
Date: Fri, 3 Jan 2025 13:27:40 +0800
Subject: [PATCH] RISC-V: Add missing dg-runtest to run the testcase under
  gcc.target/riscv/rvv/

gcc/testsuite/ChangeLog:

 * gcc.target/riscv/rvv/rvv.exp: Add dg-runtest to run the
   testcase under gcc.target/riscv/rvv/

THanks.  Installed.
jeff



[PATCH] Fixup convert-dfp*.c

2025-01-07 Thread Richard Biener
The testcases use -save-temps which doesn't play nice with -flto
and multilib testing resulting in spurious UNRESOLVED like

/usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: 
i386:x86-64 architecture of input file `./convert-dfp-2.ltrans0.ltrans.o' is 
incompatible with i386 output

The following skips the testcases when using -flto.

Tested on x86_64-unknown-linux-gnu, pushed.

* gcc.dg/torture/convert-dfp-2.c: Skip with -flto.
* gcc.dg/torture/convert-dfp.c: Likewise.
---
 gcc/testsuite/gcc.dg/torture/convert-dfp-2.c | 1 +
 gcc/testsuite/gcc.dg/torture/convert-dfp.c   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/gcc/testsuite/gcc.dg/torture/convert-dfp-2.c 
b/gcc/testsuite/gcc.dg/torture/convert-dfp-2.c
index 3e4ecb57ba6..f62b4715912 100644
--- a/gcc/testsuite/gcc.dg/torture/convert-dfp-2.c
+++ b/gcc/testsuite/gcc.dg/torture/convert-dfp-2.c
@@ -1,4 +1,5 @@
 /* { dg-do run } */
+/* { dg-skip-if "" { *-*-* } { "-flto" } } */
 /* { dg-require-effective-target float16_runtime } */
 /* { dg-require-effective-target dfprt } */
 /* { dg-options "-save-temps" } */
diff --git a/gcc/testsuite/gcc.dg/torture/convert-dfp.c 
b/gcc/testsuite/gcc.dg/torture/convert-dfp.c
index ec136896ca7..a20253dd75b 100644
--- a/gcc/testsuite/gcc.dg/torture/convert-dfp.c
+++ b/gcc/testsuite/gcc.dg/torture/convert-dfp.c
@@ -1,4 +1,5 @@
 /* { dg-do run } */
+/* { dg-skip-if "" { *-*-* } { "-flto" } } */
 /* { dg-require-effective-target float16_runtime } */
 /* { dg-require-effective-target dfprt } */
 /* { dg-options "-save-temps" } */
-- 
2.43.0


RE: [PATCH] COBOL 3/8 gen: GENERIC interface

2025-01-07 Thread Richard Kenner
> Or maybe write a blog post about how to do a new
> GCC frontend (there are multiple such for backends).  But I know time
> is scarce.

I made a set of slides a few decades ago on doing that.  It's somewhat,
but not fully, out of date and I don't know how to find them, but it
does exist somewhere.


[PATCH] arm: [MVE intrinsics] Fix tuples field name (PR 118332)

2025-01-07 Thread Christophe Lyon
A recent commit mistakenly changed the field name for tuples from
'val' to '__val', but unlike SVE this name is mandated by ACLE.

The patch simply switches back the name to 'val'.

PR target/118332

gcc/ChangeLog:

* config/arm/arm-mve-builtins.cc (wrap_type_in_struct): Use 'val'
instead of '__val'.

gcc/testsuite/ChangeLog:

* gcc.target/arm/mve/intrinsics/pr118332.c: New test.
---
 gcc/config/arm/arm-mve-builtins.cc | 5 ++---
 gcc/testsuite/gcc.target/arm/mve/intrinsics/pr118332.c | 5 +
 2 files changed, 7 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/arm/mve/intrinsics/pr118332.c

diff --git a/gcc/config/arm/arm-mve-builtins.cc 
b/gcc/config/arm/arm-mve-builtins.cc
index 2a87c41b3ff..609fbc4cd59 100644
--- a/gcc/config/arm/arm-mve-builtins.cc
+++ b/gcc/config/arm/arm-mve-builtins.cc
@@ -450,13 +450,12 @@ register_vector_type (vector_type_index type)
 }
 
 /* Return a structure type that contains a single field of type FIELD_TYPE.
-   The field is called __val, but that's an internal detail rather than
-   an exposed part of the API.  */
+   The field is called 'val', as mandated by ACLE.  */
 static tree
 wrap_type_in_struct (tree field_type)
 {
   tree field = build_decl (input_location, FIELD_DECL,
-  get_identifier ("__val"), field_type);
+  get_identifier ("val"), field_type);
   tree struct_type = lang_hooks.types.make_type (RECORD_TYPE);
   DECL_FIELD_CONTEXT (field) = struct_type;
   TYPE_FIELDS (struct_type) = field;
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/pr118332.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/pr118332.c
new file mode 100644
index 000..a8f6389c58d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/pr118332.c
@@ -0,0 +1,5 @@
+/* { dg-require-effective-target arm_v8_1m_mve_ok } */
+/* { dg-add-options arm_v8_1m_mve } */
+
+#include 
+uint32x4_t first(uint32x4x4_t a) { return a.val[0]; }
-- 
2.34.1



[COMMITTED 03/31] ada: Use the syntax of Ada 2012 if-expression in -gnatR3 output

2025-01-07 Thread Marc Poulhiès
From: Eric Botcazou 

This uses the syntax of Ada 2012 if-expression in the output produced by the
-gnatR3 switch for dynamic expressions.

gcc/ada/ChangeLog:

* repinfo.adb (List_GCC_Expression.Print_Expr) : Do not
output the final "end".

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

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

diff --git a/gcc/ada/repinfo.adb b/gcc/ada/repinfo.adb
index c08a232a3ab..969aa63c698 100644
--- a/gcc/ada/repinfo.adb
+++ b/gcc/ada/repinfo.adb
@@ -683,7 +683,7 @@ package body Repinfo is
 Print_Expr (Node.Op2);
 Write_Str (" else ");
 Print_Expr (Node.Op3);
-Write_Str (" end)");
+Write_Str (")");
  end if;
 
   when Plus_Expr =>
-- 
2.43.0



[COMMITTED 12/31] ada: Add guard to System.Val_Real.Large_Powfive against pathological input

2025-01-07 Thread Marc Poulhiès
From: Eric Botcazou 

There is no need to keep multiplying the result once it saturates to +Inf.

gcc/ada/ChangeLog:

* libgnat/s-powflt.ads (Maxpow_Exact): Minor comment fix.
* libgnat/s-powlfl.ads (Maxpow_Exact): Likewise.
* libgnat/s-powllf.ads (Maxpow_Exact): Likewise.
* libgnat/s-valrea.adb (Large_Powfive) [1 parameter]: Exit the loop
as soon as the result saturates to +Inf.
(Large_Powfive) [2 parameters]: Likewise.

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

---
 gcc/ada/libgnat/s-powflt.ads |  2 +-
 gcc/ada/libgnat/s-powlfl.ads |  2 +-
 gcc/ada/libgnat/s-powllf.ads |  4 ++--
 gcc/ada/libgnat/s-valrea.adb | 16 
 4 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/gcc/ada/libgnat/s-powflt.ads b/gcc/ada/libgnat/s-powflt.ads
index eadea7f914d..ae904f05617 100644
--- a/gcc/ada/libgnat/s-powflt.ads
+++ b/gcc/ada/libgnat/s-powflt.ads
@@ -36,7 +36,7 @@ package System.Powten_Flt is
 
Maxpow_Exact : constant := 10;
--  Largest power of five exactly representable with Float. It is equal to
-   --  floor (M * log 2 / log 5), when M is the size of the mantissa (24).
+   --  floor (M * log 2 / log 5), where M is the size of the mantissa (24).
--  It also works for any number of the form 5*(2**N) and in particular 10.
 
Maxpow : constant := Maxpow_Exact * 2;
diff --git a/gcc/ada/libgnat/s-powlfl.ads b/gcc/ada/libgnat/s-powlfl.ads
index 13630fcad40..2bf72d9c17d 100644
--- a/gcc/ada/libgnat/s-powlfl.ads
+++ b/gcc/ada/libgnat/s-powlfl.ads
@@ -36,7 +36,7 @@ package System.Powten_LFlt is
 
Maxpow_Exact : constant := 22;
--  Largest power of five exactly representable with Long_Float. It is equal
-   --  to floor (M * log 2 / log 5), when M is the size of the mantissa (53).
+   --  to floor (M * log 2 / log 5), where M is the size of the mantissa (53).
--  It also works for any number of the form 5*(2**N) and in particular 10.
 
Maxpow : constant := Maxpow_Exact * 2;
diff --git a/gcc/ada/libgnat/s-powllf.ads b/gcc/ada/libgnat/s-powllf.ads
index b470ae044de..b184b31ea9c 100644
--- a/gcc/ada/libgnat/s-powllf.ads
+++ b/gcc/ada/libgnat/s-powllf.ads
@@ -37,8 +37,8 @@ package System.Powten_LLF is
Maxpow_Exact : constant :=
  (if Long_Long_Float'Machine_Mantissa = 64 then 27 else 22);
--  Largest power of five exactly representable with Long_Long_Float. It is
-   --  equal to floor (M * log 2 / log 5), when M is the size of the mantissa
-   --  assumed to be either 64 for IEEE Extended or 53 for IEEE Double.
+   --  equal to floor (M * log 2 / log 5), where M is the size of the mantissa
+   --  (assumed to be either 64 for IEEE Extended or 53 for IEEE Double).
--  It also works for any number of the form 5*(2**N) and in particular 10.
 
Maxpow : constant := Maxpow_Exact * 2;
diff --git a/gcc/ada/libgnat/s-valrea.adb b/gcc/ada/libgnat/s-valrea.adb
index f554280c0ea..3b0f0a99a63 100644
--- a/gcc/ada/libgnat/s-valrea.adb
+++ b/gcc/ada/libgnat/s-valrea.adb
@@ -336,6 +336,7 @@ package body System.Val_Real is
   pragma Import (Ada, Powfive_300);
   for Powfive_300'Address use Powfive_300_Address;
 
+  H : Double_T;
   R : Double_T;
   E : Natural;
 
@@ -359,8 +360,15 @@ package body System.Val_Real is
  E := Exp - Maxpow;
   end if;
 
+  --  Accumulate 5**Maxpow into R until E <= Maxpow or R saturates to +Inf
+
   while E > Maxpow loop
+ H := R;
  R := R * Powfive (Maxpow);
+ if R = H then
+E := Maxpow;
+exit;
+ end if;
  E := E - Maxpow;
   end loop;
 
@@ -381,6 +389,7 @@ package body System.Val_Real is
   pragma Import (Ada, Powfive);
   for Powfive'Address use Powfive_Address;
 
+  H : Double_T;
   R : Double_T;
   E : Natural;
 
@@ -407,8 +416,15 @@ package body System.Val_Real is
  S := 0;
   end if;
 
+  --  Accumulate 5**Maxpow into R until E <= Maxpow or R saturates to +Inf
+
   while E > Maxpow loop
+ H := R;
  R := R * Powfive (Maxpow);
+ if R = H then
+E := Maxpow;
+exit;
+ end if;
  E := E - Maxpow;
   end loop;
 
-- 
2.43.0



[COMMITTED 13/31] ada: Fix internal error on container aggregate for bounded vectors

2025-01-07 Thread Marc Poulhiès
From: Eric Botcazou 

The problem is that we analyze references to an object before the actual
subtype of the object is established, thus creating a type mismatch that
is flagged by the code generator.

gcc/ada/ChangeLog:

* exp_ch7.ads (Store_After_Actions_In_Scope_Without_Analysis): New
procedure declaration.
* exp_ch7.adb (Store_New_Actions_In_Scope): New procedure.
(Store_Actions_In_Scope): Call Store_New_Actions_In_Scope when the
target list is empty.
(Store_After_Actions_In_Scope_Without_Analysis): New procedure body.
* exp_aggr.adb (Expand_Container_Aggregate): For a declaration that
is wrapped in a transient scope, also defer the analysis of the new
code until after the declaration is analyzed.

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

---
 gcc/ada/exp_aggr.adb |  9 +++
 gcc/ada/exp_ch7.adb  | 56 +---
 gcc/ada/exp_ch7.ads  |  7 --
 3 files changed, 57 insertions(+), 15 deletions(-)

diff --git a/gcc/ada/exp_aggr.adb b/gcc/ada/exp_aggr.adb
index a51e02bc308..428115f81ba 100644
--- a/gcc/ada/exp_aggr.adb
+++ b/gcc/ada/exp_aggr.adb
@@ -7345,12 +7345,13 @@ package body Exp_Aggr is
 
  --  If a transient scope has been created around the declaration, we
  --  need to attach the code to it so that the finalization actions of
- --  the declaration will be inserted after it. Otherwise, we directly
- --  insert it after the declaration and it will be analyzed only once
- --  the declaration is processed.
+ --  the declaration will be inserted after it; otherwise, we directly
+ --  insert it after the declaration. In both cases, the code will be
+ --  analyzed after the declaration is processed, i.e. once the actual
+ --  subtype of the object is established.
 
  if Scope_Is_Transient and then Par = Node_To_Be_Wrapped then
-Insert_Actions_After (Par, Aggr_Code);
+Store_After_Actions_In_Scope_Without_Analysis (Aggr_Code);
  else
 Insert_List_After (Par, Aggr_Code);
  end if;
diff --git a/gcc/ada/exp_ch7.adb b/gcc/ada/exp_ch7.adb
index 171ad4ef395..a841d3af60f 100644
--- a/gcc/ada/exp_ch7.adb
+++ b/gcc/ada/exp_ch7.adb
@@ -514,7 +514,13 @@ package body Exp_Ch7 is
--  cleanup actions are performed at the end of the block.
 
procedure Store_Actions_In_Scope (AK : Scope_Action_Kind; L : List_Id);
-   --  Shared processing for Store_xxx_Actions_In_Scope
+   --  Shared processing for the Store_xxx_Actions_In_Scope routines: attach
+   --  the list L of actions to the list of actions stored in the top of the
+   --  scope stack specified by AK.
+
+   procedure Store_New_Actions_In_Scope (AK : Scope_Action_Kind; L : List_Id);
+   --  Same as above for the case where the list of actions stored in the top
+   --  of the scope stack specified by AK is empty.
 
---
-- Unnesting procedures for CCG and LLVM --
@@ -8907,14 +8913,7 @@ package body Exp_Ch7 is
 
begin
   if Is_Empty_List (Actions) then
- Actions := L;
-
- if Is_List_Member (SE.Node_To_Be_Wrapped) then
-Set_Parent (L, Parent (SE.Node_To_Be_Wrapped));
- else
-Set_Parent (L, SE.Node_To_Be_Wrapped);
- end if;
-
+ Store_New_Actions_In_Scope (AK, L);
  Analyze_List (L);
 
   elsif AK = Before then
@@ -8934,6 +8933,22 @@ package body Exp_Ch7 is
   Store_Actions_In_Scope (After, L);
end Store_After_Actions_In_Scope;
 
+   ---
+   -- Store_After_Actions_In_Scope_Without_Analysis --
+   ---
+
+   procedure Store_After_Actions_In_Scope_Without_Analysis (L : List_Id) is
+  SE  : Scope_Stack_Entry renames Scope_Stack.Table (Scope_Stack.Last);
+  Actions : List_Id renames SE.Actions_To_Be_Wrapped (After);
+
+   begin
+  if Is_Empty_List (Actions) then
+ Store_New_Actions_In_Scope (After, L);
+  else
+ Insert_List_Before (First (Actions), L);
+  end if;
+   end Store_After_Actions_In_Scope_Without_Analysis;
+
---
-- Store_Before_Actions_In_Scope --
---
@@ -8952,6 +8967,29 @@ package body Exp_Ch7 is
   Store_Actions_In_Scope (Cleanup, L);
end Store_Cleanup_Actions_In_Scope;
 
+   
+   -- Store_New_Actions_In_Scope --
+   
+
+   procedure Store_New_Actions_In_Scope (AK : Scope_Action_Kind; L : List_Id)
+   is
+  SE  : Scope_Stack_Entry renames Scope_Stack.Table (Scope_Stack.Last);
+  Actions : List_Id renames SE.Actions_To_Be_Wrapped (AK);
+
+   begin
+  pragma Assert (Is_Empty_List (Actions));
+
+  Actions := L;
+
+  --  Set the Parent link to provide the context for the

[COMMITTED 07/31] ada: Move checks for consequences of Exceptional_Cases to GNAT

2025-01-07 Thread Marc Poulhiès
From: Piotr Trojanek 

Previously checks for consequence expressions of Exceptional_Cases aspects were
done in GNATprove backend. However, we can do them in the frontend, where they
will apply to all subprograms, regardless of the SPARK_Mode aspect.

gcc/ada/ChangeLog:

* sem_prag.adb (Analyze_Exceptional_Cases_In_Decl_Part): Move check
from GNATprove backend to GNAT frontend.

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

---
 gcc/ada/sem_prag.adb | 68 
 1 file changed, 68 insertions(+)

diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
index 04202873974..b7de1cd8afa 100644
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -2211,6 +2211,72 @@ package body Sem_Prag is
   procedure Check_Duplication (Id : Node_Id; Contracts : List_Id);
   --  Iterate through the identifiers in each contract to find duplicates
 
+  function Check_Param (N : Node_Id) return Traverse_Result;
+  --  Parameters of modes OUT or IN OUT of the subprogram shall not occur
+  --  in the consequences of an exceptional contract unless they are either
+  --  passed by reference or occur in the prefix of a reference to the 'Old
+  --  attribute or as direct prefixes of attributes that do not actually
+  --  read data from the object (SPARK RM 6.1.9(1)).
+
+  -
+  -- Check_Param --
+  -
+
+  function Check_Param (N : Node_Id) return Traverse_Result is
+  begin
+ case Nkind (N) is
+when N_Identifier | N_Expanded_Name =>
+   declare
+  Id : constant Entity_Id := Entity (N);
+   begin
+  if Present (Id)
+and then Ekind (Id) in E_Out_Parameter
+ | E_In_Out_Parameter
+and then Scope (Id) = Spec_Id
+and then not Is_By_Reference_Type (Etype (Id))
+and then not Is_Aliased (Id)
+  then
+ declare
+Mode : constant String :=
+  (if Ekind (Id) = E_Out_Parameter then "out"
+   else "in out");
+ begin
+Error_Msg_N
+  ("formal parameter of mode """ & Mode
+   & """ in consequence of Exceptional_Cases", N);
+Error_Msg_N
+  ("\only parameters passed by reference are allowed",
+   N);
+ end;
+  end if;
+   end;
+
+when N_Attribute_Reference =>
+   case Attribute_Name (N) is
+  when Name_Old =>
+ return Skip;
+  when Name_Constrained
+ | Name_First
+ | Name_Last
+ | Name_Length
+ | Name_Range
+  =>
+ if Nkind (Prefix (N)) in N_Identifier
+| N_Expanded_Name
+ then
+return Skip;
+ end if;
+  when others => null;
+   end case;
+
+when others => null;
+ end case;
+
+ return OK;
+  end Check_Param;
+
+  procedure Check_Params is new Traverse_More_Proc (Check_Param);
+
   --
   -- Analyze_Exceptional_Contract --
   --
@@ -2324,6 +2390,8 @@ package body Sem_Prag is
 
  Preanalyze_Assert_Expression (Consequence, Any_Boolean);
 
+ Check_Params (Consequence);
+
  --  Emit a clarification message when the consequence contains at
  --  least one undefined reference, possibly due to contract freezing.
 
-- 
2.43.0



[COMMITTED 11/31] ada: Drop vxworks-smp-ppc-link.spec

2025-01-07 Thread Marc Poulhiès
From: Alexandre Oliva 

Adding -msmp to linker options in system-vxworks-ppc-rtp-smp.ads
obviated vxworks-smp-ppc-link.spec.  Drop it.

gcc/ada/ChangeLog:

* libgnat/system-vxworks-ppc-rtp-smp.ads: Drop
--specs=vxworks-ppc-link.spec from Linker_Options.
* vxworks-smp-ppc-link.spec: Delete.

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

---
 gcc/ada/libgnat/system-vxworks-ppc-rtp-smp.ads | 1 -
 gcc/ada/vxworks-smp-ppc-link.spec  | 4 
 2 files changed, 5 deletions(-)
 delete mode 100644 gcc/ada/vxworks-smp-ppc-link.spec

diff --git a/gcc/ada/libgnat/system-vxworks-ppc-rtp-smp.ads 
b/gcc/ada/libgnat/system-vxworks-ppc-rtp-smp.ads
index d4bcefd1a44..1896bfaec22 100644
--- a/gcc/ada/libgnat/system-vxworks-ppc-rtp-smp.ads
+++ b/gcc/ada/libgnat/system-vxworks-ppc-rtp-smp.ads
@@ -121,7 +121,6 @@ package System is
 private
 
pragma Linker_Options ("-msmp");
-   pragma Linker_Options ("--specs=vxworks-smp-ppc-link.spec");
pragma Linker_Options ("--specs=vxworks-ppc-link.spec");
--  Setup proper set of -L's for this configuration
 
diff --git a/gcc/ada/vxworks-smp-ppc-link.spec 
b/gcc/ada/vxworks-smp-ppc-link.spec
deleted file mode 100644
index b68cac22c14..000
--- a/gcc/ada/vxworks-smp-ppc-link.spec
+++ /dev/null
@@ -1,4 +0,0 @@
-*lib:
-+ %{mrtp:%{!shared: \
- -L%:getenv(WIND_BASE /target/lib_smp/usr/lib/ppc/PPC32/common) \
-   }}
-- 
2.43.0



[COMMITTED 28/31] ada: Do not create temporaries for initialization statements

2025-01-07 Thread Marc Poulhiès
From: Eric Botcazou 

Assignment statements marked with the No_Ctrl_Actions or No_Finalize_Actions
flag are initialization statements and, therefore, no temporaries are needed
to hold the value of the right-hand side for them.

gcc/ada/ChangeLog:

* gcc-interface/trans.cc (Call_to_gnu): Always use the return slot
optimization if the parent node is an initialization statement.
(gnat_to_gnu) : Build an INIT_EXPR instead
of a MODIFY_EXPR if this is an initialization statement.

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

---
 gcc/ada/gcc-interface/trans.cc | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/gcc/ada/gcc-interface/trans.cc b/gcc/ada/gcc-interface/trans.cc
index cda73d509e8..b65a846ee66 100644
--- a/gcc/ada/gcc-interface/trans.cc
+++ b/gcc/ada/gcc-interface/trans.cc
@@ -5517,10 +5517,17 @@ Call_to_gnu (Node_Id gnat_node, tree 
*gnu_result_type_p, tree gnu_target,
 
  gigi_checking_assert (!Do_Range_Check (gnat_node));
 
+ /* If the parent is an initialization statement, we can use the
+return slot optimization.  */
+ if (Nkind (gnat_parent) == N_Assignment_Statement
+ && (No_Ctrl_Actions (gnat_parent)
+ || No_Finalize_Actions (gnat_parent)))
+   op_code = INIT_EXPR;
+
  /* ??? If the return type has variable size, then force the return
 slot optimization as we would not be able to create a temporary.
 That's what has been done historically.  */
- if (return_type_with_variable_size_p (gnu_result_type))
+ else if (return_type_with_variable_size_p (gnu_result_type))
op_code = INIT_EXPR;
 
  /* If this is a call to a pure function returning an array of scalar
@@ -7811,6 +7818,12 @@ gnat_to_gnu (Node_Id gnat_node)
= build_unary_op (ADDR_EXPR, TREE_TYPE (arg), gnu_lhs);
}
 
+ /* If the statement is an initialization, build one too.  */
+  else if (No_Ctrl_Actions (gnat_node)
+  || No_Finalize_Actions (gnat_node))
+   gnu_result
+ = build_binary_op (INIT_EXPR, NULL_TREE, gnu_lhs, gnu_rhs);
+
  /* Otherwise build a regular assignment.  */
  else
gnu_result
-- 
2.43.0



[COMMITTED 27/31] ada: Remove unused AST flag Address_Warning_Posted

2025-01-07 Thread Marc Poulhiès
From: Piotr Trojanek 

Flag Address_Warning_Posted was only read and never written, so it can be
safely removed.

gcc/ada/ChangeLog:

* gen_il-fields.ads (Opt_Field_Enum): Remove flag.
* gen_il-gen-gen_nodes.adb (N_Attribute_Definition_Clause): Remove
field.
* sem_ch13.adb (Validate_Address_Clauses): Remove read of the flag.
* sinfo.ads (Address_Warning_Posted): Remove flag description.

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

---
 gcc/ada/gen_il-fields.ads| 1 -
 gcc/ada/gen_il-gen-gen_nodes.adb | 1 -
 gcc/ada/sem_ch13.adb | 6 ++
 gcc/ada/sinfo.ads| 6 --
 4 files changed, 2 insertions(+), 12 deletions(-)

diff --git a/gcc/ada/gen_il-fields.ads b/gcc/ada/gen_il-fields.ads
index fe2da80c548..789fb76875d 100644
--- a/gcc/ada/gen_il-fields.ads
+++ b/gcc/ada/gen_il-fields.ads
@@ -65,7 +65,6 @@ package Gen_IL.Fields is
   Activation_Chain_Entity,
   Acts_As_Spec,
   Actual_Designated_Subtype,
-  Address_Warning_Posted,
   Aggregate_Bounds_Or_Ancestor_Type,
   Aliased_Present,
   All_Others,
diff --git a/gcc/ada/gen_il-gen-gen_nodes.adb b/gcc/ada/gen_il-gen-gen_nodes.adb
index c3a97e6e16e..b361aeeca1d 100644
--- a/gcc/ada/gen_il-gen-gen_nodes.adb
+++ b/gcc/ada/gen_il-gen-gen_nodes.adb
@@ -98,7 +98,6 @@ begin -- Gen_IL.Gen.Gen_Nodes
(Sy (Name, Node_Id, Default_Empty),
 Sy (Chars, Name_Id, Default_No_Name),
 Sy (Expression, Node_Id, Default_Empty),
-Sm (Address_Warning_Posted, Flag),
 Sm (Check_Address_Alignment, Flag),
 Sm (Entity_Or_Associated_Node, Node_Id), -- just Entity
 Sm (From_Aspect_Specification, Flag),
diff --git a/gcc/ada/sem_ch13.adb b/gcc/ada/sem_ch13.adb
index 2beb6b95daf..00489722921 100644
--- a/gcc/ada/sem_ch13.adb
+++ b/gcc/ada/sem_ch13.adb
@@ -18055,11 +18055,9 @@ package body Sem_Ch13 is
 X_Offs : Uint;
 
  begin
---  Skip processing of this entry if warning already posted, or if
---  alignments are not set.
+--  Skip processing of this entry if alignments are not set
 
-if not Address_Warning_Posted (ACCR.N)
-  and then Known_Alignment (ACCR.X)
+if Known_Alignment (ACCR.X)
   and then Known_Alignment (ACCR.Y)
 then
Expr := Original_Node (Expression (ACCR.N));
diff --git a/gcc/ada/sinfo.ads b/gcc/ada/sinfo.ads
index e9b2f0f3c5c..94bbb2f974e 100644
--- a/gcc/ada/sinfo.ads
+++ b/gcc/ada/sinfo.ads
@@ -788,11 +788,6 @@ package Sinfo is
--created for the expansion of an allocator with a subtype_indication
--and the designated subtype is an unconstrained composite type.
 
-   --  Address_Warning_Posted
-   --Present in N_Attribute_Definition nodes. Set to indicate that we have
-   --posted a warning for the address clause regarding size or alignment
-   --issues. Used to inhibit multiple redundant messages.
-
--  Aggregate_Bounds
--Present in array N_Aggregate nodes. If the bounds of the aggregate are
--known at compile time, this field points to an N_Range node with those
@@ -7549,7 +7544,6 @@ package Sinfo is
   --  Check_Address_Alignment
   --  From_Aspect_Specification
   --  Is_Delayed_Aspect
-  --  Address_Warning_Posted
 
   --  Note: if From_Aspect_Specification is set, then Sloc points to the
   --  aspect name, and Entity is resolved already to reference the entity
-- 
2.43.0



[COMMITTED 30/31] ada: Adjust pragma obsolescent message

2025-01-07 Thread Marc Poulhiès
Do not mention an explicit version.

gcc/ada/ChangeLog:

* libgnat/a-calcon.ads: Adjust.
* libgnat/a-calend.ads: Adjust.

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

---
 gcc/ada/libgnat/a-calcon.ads | 16 
 gcc/ada/libgnat/a-calend.ads | 14 ++
 2 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/gcc/ada/libgnat/a-calcon.ads b/gcc/ada/libgnat/a-calcon.ads
index a7be1f7f3fd..a94d5c63dff 100644
--- a/gcc/ada/libgnat/a-calcon.ads
+++ b/gcc/ada/libgnat/a-calcon.ads
@@ -37,7 +37,8 @@ with Interfaces.C;
 package Ada.Calendar.Conversions is
 
function To_Ada_Time (Unix_Time : Interfaces.C.long) return Time;
-   pragma Obsolescent (To_Ada_Time, "Retires in v26");
+   pragma Obsolescent
+ (To_Ada_Time, "This function may be removed in a future version");
--  Old version which will overflow at the 2038 Epochalypse
 
function To_Ada_Time_64 (Unix_Time : Interfaces.C.long_long) return Time;
@@ -74,7 +75,9 @@ package Ada.Calendar.Conversions is
function To_Duration
  (tv_sec  : Interfaces.C.long;
   tv_nsec : Interfaces.C.long) return Duration;
-   pragma Obsolescent (To_Duration, "Retires in v26");
+   pragma
+ Obsolescent
+   (To_Duration, "This function may be removed in a future version");
--  Old version which will overflow at the 2038 Epochalypse
 
function To_Duration_64
@@ -90,7 +93,10 @@ package Ada.Calendar.Conversions is
  (D   : Duration;
   tv_sec  : out Interfaces.C.long;
   tv_nsec : out Interfaces.C.long);
-   pragma Obsolescent (To_Struct_Timespec, "Retires in v26");
+   pragma
+ Obsolescent
+   (To_Struct_Timespec,
+"This function may be removed in a future version");
--  Old version which will overflow at the 2038 Epochalypse
 
procedure To_Struct_Timespec_64
@@ -122,7 +128,9 @@ package Ada.Calendar.Conversions is
--  The input date is considered to be in UTC
 
function To_Unix_Time (Ada_Time : Time) return Interfaces.C.long;
-   pragma Obsolescent (To_Unix_Time, "Retires in v26");
+   pragma
+ Obsolescent
+   (To_Unix_Time, "This function may be removed in a future version");
--  Old version which will overflow at the 2038 Epochalypse
 
function To_Unix_Time_64 (Ada_Time : Time) return Interfaces.C.long_long;
diff --git a/gcc/ada/libgnat/a-calend.ads b/gcc/ada/libgnat/a-calend.ads
index 64907455896..032fad8294f 100644
--- a/gcc/ada/libgnat/a-calend.ads
+++ b/gcc/ada/libgnat/a-calend.ads
@@ -291,7 +291,8 @@ private
package Conversion_Operations is
 
   function To_Ada_Time (Unix_Time : Long_Integer) return Time;
-  pragma Obsolescent (To_Ada_Time, "Retires in v26");
+  pragma Obsolescent
+(To_Ada_Time, "This function may be removed in a future version");
   --  Old Unix to Ada Epoch conversion
 
   function To_Ada_Time_64 (Unix_Time : Long_Long_Integer) return Time;
@@ -310,7 +311,8 @@ private
   function To_Duration
 (tv_sec  : Long_Integer;
  tv_nsec : Long_Integer) return Duration;
-  pragma Obsolescent (To_Duration, "Retires in v26");
+  pragma Obsolescent
+(To_Duration, "This function may be removed in a future version");
   --  Old Struct timespec to Duration conversion
 
   function To_Duration_64
@@ -322,7 +324,10 @@ private
 (D   : Duration;
  tv_sec  : out Long_Integer;
  tv_nsec : out Long_Integer);
-  pragma Obsolescent (To_Struct_Timespec, "Retires in v26");
+  pragma
+Obsolescent
+  (To_Struct_Timespec,
+   "This function may be removed in a future version");
   --  Old Duration to struct timespec conversion
 
   procedure To_Struct_Timespec_64
@@ -342,7 +347,8 @@ private
   --  Time to struct tm conversion
 
   function To_Unix_Time (Ada_Time : Time) return Long_Integer;
-  pragma Obsolescent (To_Unix_Time, "Retires in v26");
+  pragma Obsolescent
+(To_Unix_Time, "This function may be removed in a future version");
   --  Old Ada to Unix Epoch conversion
 
   function To_Unix_Time_64 (Ada_Time : Time) return Long_Long_Integer;
-- 
2.43.0



[PATCH v2] LoongArch: Opitmize the cost of vec_construct.

2025-01-07 Thread chenxiaolong
  When analyzing 525 on LoongArch architecture, it was found that the
for loop of hotspot function x264_pixel_satd_8x4 could not be quantized
256-bit due to the cost of vec_construct setting. After re-adjusting
vec_construct, the performance of 525 program was improved by 16.57%.
It was found that this function can be vectorized on the aarch64 and
x86 architectures, see [PR98138].

Co-Authored-By: Deng Jianbo .

gcc/ChangeLog:

* config/loongarch/loongarch.cc
(loongarch_builtin_vectorization_cost): Modify the
construction cost of the vec_construct vector.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/vect-slp-two-operator.c: New test.
---
 gcc/config/loongarch/loongarch.cc |  6 +--
 .../loongarch/vect-slp-two-operator.c | 38 +++
 2 files changed, 41 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vect-slp-two-operator.c

diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc
index 89237c377e7..ff27b96c31e 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -4127,10 +4127,10 @@ loongarch_builtin_vectorization_cost (enum 
vect_cost_for_stmt type_of_cost,
 
   case vec_construct:
elements = TYPE_VECTOR_SUBPARTS (vectype);
-   if (ISA_HAS_LASX)
- return elements + 1;
+   if (LASX_SUPPORTED_MODE_P (mode) && !LSX_SUPPORTED_MODE_P (mode))
+ return elements / 2 + 3;
else
- return elements;
+ return elements / 2 + 1;
 
   default:
gcc_unreachable ();
diff --git a/gcc/testsuite/gcc.target/loongarch/vect-slp-two-operator.c 
b/gcc/testsuite/gcc.target/loongarch/vect-slp-two-operator.c
new file mode 100644
index 000..43b46759902
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vect-slp-two-operator.c
@@ -0,0 +1,38 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mlasx -ftree-vectorize -fdump-tree-vect 
-fdump-tree-vect-details" } */
+
+typedef unsigned char uint8_t;
+typedef unsigned int uint32_t;
+
+#define HADAMARD4(d0, d1, d2, d3, s0, s1, s2, s3) \
+  {   \
+int t0 = s0 + s1; \
+int t1 = s0 - s1; \
+int t2 = s2 + s3; \
+int t3 = s2 - s3; \
+d0 = t0 + t2; \
+d1 = t1 + t3; \
+d2 = t0 - t2; \
+d3 = t1 - t3; \
+  }
+
+void sink (uint32_t tmp[4][4]);
+
+void
+x264_pixel_satd_8x4 (uint8_t *pix1, int i_pix1, uint8_t *pix2, int i_pix2)
+{
+  uint32_t tmp[4][4];
+  int sum = 0;
+  for (int i = 0; i < 4; i++, pix1 += i_pix1, pix2 += i_pix2)
+{
+  uint32_t a0 = (pix1[0] - pix2[0]) + ((pix1[4] - pix2[4]) << 16);
+  uint32_t a1 = (pix1[1] - pix2[1]) + ((pix1[5] - pix2[5]) << 16);
+  uint32_t a2 = (pix1[2] - pix2[2]) + ((pix1[6] - pix2[6]) << 16);
+  uint32_t a3 = (pix1[3] - pix2[3]) + ((pix1[7] - pix2[7]) << 16);
+  HADAMARD4 (tmp[i][0], tmp[i][1], tmp[i][2], tmp[i][3], a0, a1, a2, a3);
+}
+  sink (tmp);
+}
+
+/* { dg-final { scan-tree-dump "vectorizing stmts using SLP" "vect" } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
-- 
2.20.1



[PATCH] rtl-optimization/118298 - constant iteration loops and #pragma unroll

2025-01-07 Thread Richard Biener
When the RTL unroller handles constant iteration loops it bails out
prematurely when heuristics wouldn't apply any unrolling before
checking #pragma unroll.

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

PR rtl-optimization/118298
* loop-unroll.cc (decide_unroll_constant_iterations): Honor
loop->unroll even if the loop is too big for heuristics.
---
 gcc/loop-unroll.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/loop-unroll.cc b/gcc/loop-unroll.cc
index 2bd6e888b26..b4952055318 100644
--- a/gcc/loop-unroll.cc
+++ b/gcc/loop-unroll.cc
@@ -372,7 +372,8 @@ decide_unroll_constant_iterations (class loop *loop, int 
flags)
 nunroll = targetm.loop_unroll_adjust (nunroll, loop);
 
   /* Skip big loops.  */
-  if (nunroll <= 1)
+  if (nunroll <= 1
+  && !(loop->unroll > 1 && loop->unroll < USHRT_MAX))
 {
   if (dump_file)
fprintf (dump_file, ";; Not considering loop, is too big\n");
-- 
2.43.0


Re: [PATCH 0/3] testsuite: RISC-V: Improve support for RV32E

2025-01-07 Thread Palmer Dabbelt

On Mon, 09 Dec 2024 08:13:22 PST (-0800), dimi...@dinux.eu wrote:

Many test cases implicitly require some form of I ABI variant for
RISC-V to be the default.  Hence they fail when ILP32E is configured as
the default ABI for the toolchain.  Example error:

  spawn ... -march=rv32gc_zbb ...
  cc1: error: ILP32E ABI does not support the 'D' extension

This patch series adds explicit RISC-V ABI configuration to the test
cases, in order to remove spurious errors for RV32E toolchain.  My end
goal is to start running bi-monthly regression tests for RV32E, and
publish to gcc-testretults.

My understanding is that RV32E is a popular choice for low-end
microcontrollers, and is here to stay.  The existing RV32I test runs
achieve somewhat limited coverage for RV32E.  So running regression
tests for RV32E should be beneficial for the community.


Thanks for doing this.  This came up in the patchwork meeting, but I'm 
not actually sure how widely used the E ISAs are.  That's why they don't 
get the testing bandwidth that some of the other sub-targets do, and 
thus why these sorts of bugs linger.


So if you're interested in E and want to test it that's great, it's just 
the sort of thing that needs someone who cares to make sure specific 
sub-targets stay clean.  You just might be in for a bit of an uphill 
battle, though, as there's a ton of RISC-V sub-targets so these uncommon 
ones don't get as much love.


If you've got some specific E sub-targets you're interested in then we 
should probably get them added to CI, though we're in a bit of a CI 
resourcing crunch right now so it might be a slower process than 
normal...


I think Jeff already said something (they're at least marked as 
"Accepted" in patchwork), but


Acked-by: Palmer Dabbelt 

if that helps any.  Thanks!


I tested this patch set for both RV32I and RV64I, with and without
the patches.  I ensured there are no new FAIL or UNSUPPORTED tests.
I used the current trunk r15-5950-gb3cb0c3302a7c1 as a base commit.

  Target is riscv64-unknown-linux-gnu
  Host   is x86_64-pc-linux-gnu
  Schedule of variations:
  riscv-sim/-march=rv64imafdc/-mabi=lp64d/-mcmodel=medlow
  # of expected passes244323
  # of unexpected failures1753
  # of expected failures  1670
  # of unresolved testcases   43
  # of unsupported tests  18938

  Target is riscv32-unknown-elf
  Host   is x86_64-pc-linux-gnu
  Schedule of variations:
  riscv-sim/-march=rv32ima/-mabi=ilp32/-mcmodel=medlow
  #  of expected passes220983
  # of unexpected failures1838
  # of expected failures  1084
  # of unresolved testcases   42
  # of unsupported tests  18892


When I test RV32E configured with:
  --target=riscv32-none-elf \
  --with-multilib-generator=rv32ec-ilp32e-- \
  --with-abi=ilp32e \
  --with-arch=rv32ec

then failures for RV32E are similar number to the RV32I
results above:

  Target is riscv32-none-elf
  Host   is x86_64-pc-linux-gnu
  Schedule of variations:
  riscv-rv32ec-sim
  # of expected passes224967
  # of unexpected failures1899
  # of expected failures  1084
  # of unresolved testcases   298
  # of unsupported tests  17711

Dimitar Dimitrov (3):
  testsuite: RISC-V: Explicitly specify ABI when adding V and Zvbb
options
  testsuite: RISC-V: Explicitly specify ABI when passing -mcpu=
  testsuite: RISC-V: Explicitly specify ABI when passing -march

 gcc/testsuite/gcc.dg/pr90838.c| 4 ++--
 gcc/testsuite/gcc.target/riscv/adddibeq.c | 2 +-
 gcc/testsuite/gcc.target/riscv/adddibfeq.c| 2 +-
 gcc/testsuite/gcc.target/riscv/adddibfge.c| 2 +-
 gcc/testsuite/gcc.target/riscv/adddibfgt.c| 2 +-
 gcc/testsuite/gcc.target/riscv/adddibfle.c| 2 +-
 gcc/testsuite/gcc.target/riscv/adddibflt.c| 2 +-
 gcc/testsuite/gcc.target/riscv/adddibfne.c| 2 +-
 gcc/testsuite/gcc.target/riscv/adddibge.c | 2 +-
 gcc/testsuite/gcc.target/riscv/adddibgeu.c| 2 +-
 gcc/testsuite/gcc.target/riscv/adddibgt.c | 2 +-
 gcc/testsuite/gcc.target/riscv/adddibgtu.c| 2 +-
 gcc/testsuite/gcc.target/riscv/adddible.c | 2 +-
 gcc/testsuite/gcc.target/riscv/adddibleu.c| 2 +-
 gcc/testsuite/gcc.target/riscv/adddiblt.c | 2 +-
 gcc/testsuite/gcc.target/riscv/adddibltu.c| 2 +-
 gcc/testsuite/gcc.target/riscv/adddibne.c | 2 +-
 gcc/testsuite/gcc.target/riscv/adddieq.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/adddifeq.c | 2 +-
 gcc/testsuite/gcc.target/riscv/adddifge.c | 2 +-
 gcc/testsuite/gcc.target/riscv/adddifgt.c | 2 +-
 gcc/testsuite/gcc.target/riscv/addd

[PATCH] c++: ICE with MODIFY_EXPR in constexpr [PR118169]

2025-01-07 Thread Marek Polacek
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

-- >8 --
Here, cxx_eval_outermost_expression gets a sequence of initialization
statements:

  D.2912.t = TARGET_EXPR <...>;
  TARGET_EXPR ;
  D.2922 = 0;

the last of which wasn't converted to void and so we, since r15-6369,
do not take the "if (VOID_TYPE_P (type))" path, and try to set
D.2912 to false.

The last statement comes from build_disable_temp_cleanup.
convert_to_void is typically called from finish_expr_stmt, but we are
adding the cleanup statement via add_stmt which doesn't convert to void.
So I think we can use finish_expr_stmt instead.

PR c++/118169

gcc/cp/ChangeLog:

* typeck2.cc (split_nonconstant_init): Call finish_expr_stmt instead
of add_stmt.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/constexpr-prvalue2.C: New test.
---
 gcc/cp/typeck2.cc   |  2 +-
 gcc/testsuite/g++.dg/cpp1y/constexpr-prvalue2.C | 13 +
 2 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-prvalue2.C

diff --git a/gcc/cp/typeck2.cc b/gcc/cp/typeck2.cc
index 381f198d0fe..5dae7fccf19 100644
--- a/gcc/cp/typeck2.cc
+++ b/gcc/cp/typeck2.cc
@@ -757,7 +757,7 @@ split_nonconstant_init (tree dest, tree init)
init = NULL_TREE;
 
   for (tree f : flags)
-   add_stmt (build_disable_temp_cleanup (f));
+   finish_expr_stmt (build_disable_temp_cleanup (f));
   release_tree_vector (flags);
 
   code = pop_stmt_list (code);
diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-prvalue2.C 
b/gcc/testsuite/g++.dg/cpp1y/constexpr-prvalue2.C
new file mode 100644
index 000..7076c65b96a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-prvalue2.C
@@ -0,0 +1,13 @@
+// PR c++/118169
+// { dg-do compile { target c++14 } }
+// { dg-options "-O" }
+
+struct A { constexpr A (int *x) : s(x) {} ~A (); int *s; };
+struct B { A t; int u = 0; };
+void foo (B &&);
+
+void
+bar (int &x)
+{
+  foo ({ &x });
+}

base-commit: d3ccd89fa0d34d44226af47fe82c27ba7833fe65
-- 
2.47.1



Re: [Ada] Fix PR ada/118247

2025-01-07 Thread Maciej W. Rozycki
On Mon, 6 Jan 2025, Eric Botcazou wrote:

> This is a regression introduced by
>   https://gcc.gnu.org/pipermail/gcc-cvs/2024-July/405522.html
> in the form of a spurious relinking of the gnatbind executable for the 
> install 
> target of cross Ada compilers.

 The fix feels hackish and I wonder how other frontends handle this, but 
overall thank you for taking care of this peculiarity.

  Maciej


Re: [PATCH] riscv: add mising masking in lrsc expander (PR118137)

2025-01-07 Thread Patrick O'Neill



On 1/7/25 07:37, Andreas Schwab wrote:

gcc:
PR target/118137
* config/riscv/sync.md ("lrsc_atomic_exchange"): Apply mask
to shifted value.

gcc/testsuite:
PR target/118137
* gcc.dg/atomic/pr118137.c: New.
---

Thanks for fixing this - I can't give approvals but LGTM FWIW.


[PATCH] docs: Document new hardreg PRE pass.

2025-01-07 Thread Andrew Carlotti
I forgot to include this in the earlier patch; is this ok for master (once the
pass is merged, of course)?

gcc/ChangeLog:

* doc/passes.texi: Document hardreg PRE pass.


diff --git a/gcc/doc/passes.texi b/gcc/doc/passes.texi
index 
639f6b325c8be47bffd64269340c4dd8ea0f321c..5c2a174a7495404de48002f54902cce846e62b53
 100644
--- a/gcc/doc/passes.texi
+++ b/gcc/doc/passes.texi
@@ -959,6 +959,11 @@ global constant and  copy propagation.
 The source file for this pass is @file{gcse.cc}, and the LCM routines
 are in @file{lcm.cc}.
 
+A third version of this pass is run on some targets to optimise assignments to
+specific hard registers.  This can be used in cases where a register has a
+single purpose, such as specifying a mode as an extra input for specific
+instructions (when these modes cannot be handled in the mode switching pass).
+
 @item Loop optimization
 
 This pass performs several loop related optimizations.


Re: [Ada] Fix PR ada/118247

2025-01-07 Thread Eric Botcazou
>  The fix feels hackish and I wonder how other frontends handle this, but
> overall thank you for taking care of this peculiarity.

You're welcome.  The main Makefile does the same for xgcc -> gcc-cross and,
as this example shows, every change is this area is almost guaranteed to break 
something, so the simpler, the better.

-- 
Eric Botcazou




Re: [PATCH] docs: Document new hardreg PRE pass.

2025-01-07 Thread Jeff Law




On 1/7/25 11:17 AM, Richard Sandiford wrote:

Andrew Carlotti  writes:

I forgot to include this in the earlier patch; is this ok for master (once the
pass is merged, of course)?

gcc/ChangeLog:

* doc/passes.texi: Document hardreg PRE pass.


diff --git a/gcc/doc/passes.texi b/gcc/doc/passes.texi
index 
639f6b325c8be47bffd64269340c4dd8ea0f321c..5c2a174a7495404de48002f54902cce846e62b53
 100644
--- a/gcc/doc/passes.texi
+++ b/gcc/doc/passes.texi
@@ -959,6 +959,11 @@ global constant and  copy propagation.
  The source file for this pass is @file{gcse.cc}, and the LCM routines
  are in @file{lcm.cc}.
  
+A third version of this pass is run on some targets to optimise assignments to

+specific hard registers.  This can be used in cases where a register has a
+single purpose, such as specifying a mode as an extra input for specific
+instructions (when these modes cannot be handled in the mode switching pass).


LGTM, but how about adding ", @pxref{Mode switching optimization}" after
"mode switching pass"?  (Untested.)

OK with that change, or without if it doesn't work.

I've got no significant concerns.  So no objections from me.

jeff



Re: [PATCH] testsuite: enable effective-target sync_char_short on RISC-V

2025-01-07 Thread Jeff Law




On 1/7/25 8:35 AM, Andreas Schwab wrote:

* lib/target-supports.exp
(check_effective_target_sync_char_short): Enable for riscv*-*-*.

I went ahead and pushed this as well.

Thanks again,
jeff


Re: [patch, doc, Fortran] Further documentation of UNSIGNED

2025-01-07 Thread Steve Kargl
On Tue, Jan 07, 2025 at 03:28:31PM +0100, Thomas Koenig wrote:
> Hello world,
> 
> the attached patch does what it says in the ChangeLog entry.
> 
> Tested with "make dvi" and "make pdf".
> 
> OK for trunk?
> 

OK.

-- 
Steve


[PATCH] aarch64: Fix overly restrictive sibcall check [PR107102]

2025-01-07 Thread Richard Sandiford
aarch64_function_ok_for_sibcall required the caller and callee
to use the same PCS variant.  However, it should be enough for the
callee to preserve at least as much register state as the caller;
preserving more state is fine.

ARM_PCS_AAPCS64, ARM_PCS_SIMD, and ARM_PCS_SVE agree on what
GPRs should be preserved.  For the others:

- ARM_PCS_AAPCS64 preserves D8-D15
- ARM_PCS_SIMD preserves Q8-Q23
- ARM_PCS_SVE preserves Z8-Z23 + P4-P15

Thus it's ok for something earlier in the list to tail call something
later in the list.

Tested on aarch64-linux-gnu.  I'll push tomorrow evening UTC if there
are no comments before then.

Richard


gcc/
PR target/107102
* config/aarch64/aarch64.cc (aarch64_function_ok_for_sibcall): Only
reject calls with different PCSes if the callee clobbers register
state that the caller must preserve.

gcc/testsuite/
PR target/107102
* gcc.target/aarch64/sve/sibcall_1.c: New test.
---
 gcc/config/aarch64/aarch64.cc | 12 ++-
 .../gcc.target/aarch64/sve/sibcall_1.c| 80 +++
 2 files changed, 91 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve/sibcall_1.c

diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 9e69bc74449..fa2f19467e3 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -6591,7 +6591,17 @@ aarch64_split_sve_subreg_move (rtx dest, rtx ptrue, rtx 
src)
 static bool
 aarch64_function_ok_for_sibcall (tree, tree exp)
 {
-  if (crtl->abi->id () != expr_callee_abi (exp).id ())
+  auto from_abi = crtl->abi->id ();
+  auto to_abi = expr_callee_abi (exp).id ();
+
+  /* ARM_PCS_SVE preserves strictly more than ARM_PCS_SIMD, which in
+ turn preserves strictly more than the base PCS.  The callee must
+ preserve everything that the caller is required to preserve.  */
+  if (from_abi != to_abi && to_abi == ARM_PCS_SVE)
+to_abi = ARM_PCS_SIMD;
+  if (from_abi != to_abi && to_abi == ARM_PCS_SIMD)
+to_abi = ARM_PCS_AAPCS64;
+  if (from_abi != to_abi)
 return false;
 
   tree fntype = TREE_TYPE (TREE_TYPE (CALL_EXPR_FN (exp)));
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/sibcall_1.c 
b/gcc/testsuite/gcc.target/aarch64/sve/sibcall_1.c
new file mode 100644
index 000..a54c107998e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/sve/sibcall_1.c
@@ -0,0 +1,80 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-final { check-function-bodies "**" "" "" { target { le } } } } */
+
+#define SIMD [[gnu::aarch64_vector_pcs]]
+
+void callee_base (void);
+void callee_simd (void) SIMD;
+void callee_sve (__SVBool_t);
+
+/*
+** base_to_base:
+** b   callee_base
+*/
+void base_to_base (void) { return callee_base (); }
+
+/*
+** base_to_simd:
+** b   callee_simd
+*/
+void base_to_simd (void) { return callee_simd (); }
+
+/*
+** base_to_sve:
+** ldr p0, \[x0\]
+** b   callee_sve
+*/
+void base_to_sve (__SVBool_t *ptr) { return callee_sve (*ptr); }
+
+/*
+** simd_to_base:
+** stp x29, x30, [^\n]+
+** ...
+** bl  callee_base
+** ...
+** ldp x29, x30, [^\n]+
+** ret
+*/
+void simd_to_base (void) SIMD { return callee_base (); }
+
+/*
+** simd_to_simd:
+** b   callee_simd
+*/
+void simd_to_simd (void) SIMD { return callee_simd (); }
+
+/*
+** simd_to_sve:
+** ldr p0, \[x0\]
+** b   callee_sve
+*/
+void simd_to_sve (__SVBool_t *ptr) SIMD { return callee_sve (*ptr); }
+
+/*
+** sve_to_base:
+** stp x29, x30, [^\n]+
+** ...
+** bl  callee_base
+** ...
+** ldp x29, x30, [^\n]+
+** ret
+*/
+void sve_to_base (__SVBool_t pg) { return callee_base (); }
+
+/*
+** sve_to_simd:
+** stp x29, x30, [^\n]+
+** ...
+** bl  callee_simd
+** ...
+** ldp x29, x30, [^\n]+
+** ret
+*/
+void sve_to_simd (__SVBool_t pg) { return callee_simd (); }
+
+/*
+** sve_to_sve:
+** b   callee_sve
+*/
+void sve_to_sve (__SVBool_t pg) { return callee_sve (pg); }
-- 
2.25.1



RE: [PATCH]AArch64: Fix costing of emulated gathers/scatters [PR118188]

2025-01-07 Thread Tamar Christina
> >> i.e. we use separate address arithmetic and avoid UMOVs.  Counting
> >> two loads and one store for each element of the scatter store seems
> >> like overkill for that.
> >
> > Hmm agreed..
> >
> > How about for stores we increase the load counts by count / 2?
> >
> > This would account for the fact that we know we have indexed stores
> > and so the data-to-scalar operation is free?
> 
> Yeah, sounds good.  We should probably divide count itself by 2,
> then apply the new count to both the load heuristic and the general ops,
> to avoid double-counting in both.  (The V pipe usage for stores is
> modelled as part of the scalar_store itself.)  But like you say,
> we should probably drop the - 1 from the load adjustment for stores,
> because that - 1 would also be applied twice.
> 

Here's a new version of the patch.  For now I've punted the data bound variant
as to do that properly we do need to model the transfer throughputs. So 
differing
that to GCC 16.

Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.

Ok for master?

Thanks,
Tamar

gcc/ChangeLog:

PR target/118188
* config/aarch64/aarch64.cc (aarch64_vector_costs::count_ops): Adjust
throughput of emulated gather and scatters.

gcc/testsuite/ChangeLog:

PR target/118188
* gcc.target/aarch64/sve/gather_load_12.c: New test.
* gcc.target/aarch64/sve/gather_load_13.c: New test.
* gcc.target/aarch64/sve/gather_load_14.c: New test.

-- inline copy of patch --

diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 
d6a8e4c209527f53e6292887b3fbc8a0ac3245da..efe9a935192748fba4e71e98a55693317f5ca786
 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -17348,6 +17348,47 @@ aarch64_vector_costs::count_ops (unsigned int count, 
vect_cost_for_stmt kind,
return;
 }
 
+  /* Detect the case where we are using an emulated gather/scatter.  When a
+ target does not support gathers and scatters directly the vectorizer
+ emulates these by constructing an index vector and then issuing an
+ extraction for every lane in the vector.  This is subsequently lowered
+ by veclower into a series of loads which creates the scalar indexes for
+ the subsequent loads.  After the final loads are done it issues a
+ vec_construct to recreate the vector from the scalar.  For costing when
+ we see a vec_to_scalar on a stmt with VMAT_GATHER_SCATTER we are dealing
+ with an emulated instruction and should adjust costing properly.  */
+  if (kind == vec_to_scalar
+  && (m_vec_flags & VEC_ADVSIMD)
+  && vect_mem_access_type (stmt_info, node) == VMAT_GATHER_SCATTER)
+{
+  auto dr = STMT_VINFO_DATA_REF (stmt_info);
+  tree dr_ref = DR_REF (dr);
+  /* Only really expect MEM_REF or ARRAY_REF here.  Ignore the rest.  */
+  switch (TREE_CODE (dr_ref))
+   {
+   case MEM_REF:
+   case ARRAY_REF:
+   case TARGET_MEM_REF:
+ {
+   tree offset = TREE_OPERAND (dr_ref, 1);
+   if (SSA_VAR_P (offset)
+   && gimple_vuse (SSA_NAME_DEF_STMT (offset)))
+ {
+   if (STMT_VINFO_TYPE (stmt_info) == load_vec_info_type)
+ ops->loads += count - 1;
+   else
+ /* Stores want to count both the index to array and data to
+array using vec_to_scalar.  However we have index stores in
+Adv.SIMD and so we only want to adjust the index loads.  */
+ ops->loads += count / 2;
+   return;
+ }
+   break;
+ }
+   default:
+ break;
+   }
+}
 
   /* Count the basic operation cost associated with KIND.  */
   switch (kind)
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/gather_load_12.c 
b/gcc/testsuite/gcc.target/aarch64/sve/gather_load_12.c
new file mode 100644
index 
..d550f005d638f260973312fbccd05e2bb9aef1a7
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/sve/gather_load_12.c
@@ -0,0 +1,20 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-Ofast -mcpu=neoverse-v2" } */
+
+#define iterations 10
+#define LEN_1D 32000
+
+float a[LEN_1D], b[LEN_1D];
+
+float
+s4115 (int *ip)
+{
+float sum = 0.;
+for (int i = 0; i < LEN_1D; i++)
+  {
+sum += a[i] * b[ip[i]];
+  }
+return sum;
+}
+
+/* { dg-final { scan-assembler {\s+ld1w\t} } } */
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/gather_load_13.c 
b/gcc/testsuite/gcc.target/aarch64/sve/gather_load_13.c
new file mode 100644
index 
..24da0646a75e41eae0c0dd6a2b8af58631ac94cb
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/sve/gather_load_13.c
@@ -0,0 +1,20 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-Ofast -mcpu=neoverse-v2" } */
+
+#define iterations 10
+#define LEN_1D 32000
+
+float a[LEN_1D], b[LEN_1D];
+
+float
+s

Re: [PATCH] docs: Document new hardreg PRE pass.

2025-01-07 Thread Richard Sandiford
Andrew Carlotti  writes:
> I forgot to include this in the earlier patch; is this ok for master (once the
> pass is merged, of course)?
>
> gcc/ChangeLog:
>
>   * doc/passes.texi: Document hardreg PRE pass.
>
>
> diff --git a/gcc/doc/passes.texi b/gcc/doc/passes.texi
> index 
> 639f6b325c8be47bffd64269340c4dd8ea0f321c..5c2a174a7495404de48002f54902cce846e62b53
>  100644
> --- a/gcc/doc/passes.texi
> +++ b/gcc/doc/passes.texi
> @@ -959,6 +959,11 @@ global constant and  copy propagation.
>  The source file for this pass is @file{gcse.cc}, and the LCM routines
>  are in @file{lcm.cc}.
>  
> +A third version of this pass is run on some targets to optimise assignments 
> to
> +specific hard registers.  This can be used in cases where a register has a
> +single purpose, such as specifying a mode as an extra input for specific
> +instructions (when these modes cannot be handled in the mode switching pass).

LGTM, but how about adding ", @pxref{Mode switching optimization}" after
"mode switching pass"?  (Untested.)

OK with that change, or without if it doesn't work.

Thanks,
Richard

> +
>  @item Loop optimization
>  
>  This pass performs several loop related optimizations.


[PATCH] c++: Fix up ICEs on constexpr inline asm strings in templates [PR118277]

2025-01-07 Thread Jakub Jelinek
Hi!

The following patch fixes ICEs when the new inline asm syntax
to use C++26 static_assert-like constant expressions in place
of string literals is used in templates.
As finish_asm_stmt doesn't do any checking for
processing_template_decl, this patch also just defers handling
those strings in templates rather than say trying fold_non_dependent_expr
and if the result is non-dependent and usable, try to extract.

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

There is one case I didn't handle and I'd like to discuss.
The initial commit to enable this new extension also changed
cp_parser_asm_specification_opt to use cp_parser_asm_string_expression.
That function doesn't have anything to do with asm statements though,
it is about asm redirection of declarations.
I couldn't find any testcase coverage for that nor documentation.
It is basically whether one can use something like
void foo () asm ((std::string_view ("bar")));
or not.  GCC 14 didn't support that obviously, now it works
when not used in templates (both before and after this patch), but
will crash when used on templates.  Say
template 
void baz () asm ((std::string_view ("qux")));
(or even worse when it is dependent).
Do we want to revert the cp_parser_asm_specification_opt
changes and only support void foo () asm ("bar");, or was it intentional
to add support for constant expressions even for those?
The problem with supporting those in templates is that
cp_finish_decl/grokfield really assume asmspec_tree is NULL,
error_mark_node or STRING_CST, they perform e.g. pragma renaming on those
and there is no obvious place to store the not yet finalized
constant expression for the asmspec, those are really stored as const char *
later transformed into INDENTIFIER_NODEs.  Or shall we sorry if it is
used in templates for now?  Or say temporarily turn into some internal
attribute?

2025-01-07  Jakub Jelinek  

PR c++/118277
* cp-tree.h (finish_asm_string_expression): Declare.
* semantics.cc (finish_asm_string_expression): New function.
(finish_asm_stmt): Use it.
* parser.cc (cp_parser_asm_string_expression): Likewise.

* g++.dg/cpp1z/constexpr-asm-4.C: New test.

--- gcc/cp/cp-tree.h.jj 2025-01-03 17:54:12.405906056 +0100
+++ gcc/cp/cp-tree.h2025-01-07 11:25:58.138829264 +0100
@@ -7946,6 +7946,7 @@ enum {
 extern tree begin_compound_stmt(unsigned int);
 
 extern void finish_compound_stmt   (tree);
+extern tree finish_asm_string_expression   (location_t, tree);
 extern tree finish_asm_stmt(location_t, int, tree, tree,
 tree, tree, tree, bool, bool);
 extern tree finish_label_stmt  (tree);
--- gcc/cp/semantics.cc.jj  2025-01-03 11:05:47.908986058 +0100
+++ gcc/cp/semantics.cc 2025-01-07 12:02:47.372041244 +0100
@@ -2133,6 +2133,26 @@ finish_compound_stmt (tree stmt)
   add_stmt (stmt);
 }
 
+/* Finish an asm string literal, which can be a string literal
+   or parenthesized constant expression.  Extract the string literal
+   from the latter.  */
+
+tree
+finish_asm_string_expression (location_t loc, tree string)
+{
+  if (string == error_mark_node
+  || TREE_CODE (string) == STRING_CST
+  || processing_template_decl)
+return string;
+  string = cxx_constant_value (string, tf_error);
+  cexpr_str cstr (string);
+  if (!cstr.type_check (loc))
+return error_mark_node;
+  if (!cstr.extract (loc, string))
+string = error_mark_node;
+  return string;
+}
+
 /* Finish an asm-statement, whose components are a STRING, some
OUTPUT_OPERANDS, some INPUT_OPERANDS, some CLOBBERS and some
LABELS.  Also note whether the asm-statement should be
@@ -2159,6 +2179,26 @@ finish_asm_stmt (location_t loc, int vol
 
   oconstraints = XALLOCAVEC (const char *, noutputs);
 
+  string = finish_asm_string_expression (cp_expr_loc_or_loc (string, loc),
+string);
+  if (string == error_mark_node)
+   return error_mark_node;
+  for (int i = 0; i < 2; ++i)
+   for (t = i ? input_operands : output_operands; t; t = TREE_CHAIN (t))
+ {
+   tree s = TREE_VALUE (TREE_PURPOSE (t));
+   s = finish_asm_string_expression (cp_expr_loc_or_loc (s, loc), s);
+   if (s == error_mark_node)
+ return error_mark_node;
+   TREE_VALUE (TREE_PURPOSE (t)) = s;
+ }
+  for (t = clobbers; t; t = TREE_CHAIN (t))
+   {
+ tree s = TREE_VALUE (t);
+ s = finish_asm_string_expression (cp_expr_loc_or_loc (s, loc), s);
+ TREE_VALUE (t) = s;
+   }
+
   string = resolve_asm_operand_names (string, output_operands,
  input_operands, labels);
 
--- gcc/cp/parser.cc.jj 2025-01-03 11:05:47.878986483 +0100
+++ gcc/cp/parser.cc2025-01-07 11:27:11.384808357 +0100
@@ -23107,15 +23107,8 @@ cp_parser_a

Re: [PATCH 10/10] aarch64: Try to avoid passing new flags to assembler

2025-01-07 Thread Richard Sandiford
Andrew Carlotti  writes:
> On Mon, Nov 25, 2024 at 11:26:39PM +, Richard Sandiford wrote:
>> Sorry for the slow review.
>> 
>> Andrew Carlotti  writes:
>> > These new flags (+fcma, +jscvt, +rcpc2, +jscvt, +frintts, +wfxt and +xs)
>> > were only recently added to the assembler.  To improve compatibility
>> > with older assemblers, we try to avoid passing these new flags to the
>> > assembler if we can express the targetted architecture without them. We
>> > do so by using an almost-equivalent architecture string with a higher
>> > architecture version.
>> >
>> > This should never reduce the set of instructions accepted by the
>> > assembler.  It will make it more lenient in two cases:
>> >
>> > 1. Many system registers are currently gated behind architecture
>> > versions instead of specific feature flags.  Increasing the base
>> > architecture version may cause more system register accesses to be
>> > accepted.
>> >
>> > 2. FEAT_XS doesn't have an HWCAP bit or cpuinfo entry.  We still want to
>> > avoid passing +wfxt or +noxs to the assembler if possible, so we'll
>> > instruct the assembler to accept FEAT_XS instructions as well whenever
>> > the rest of the new features are enabled.
>> >
>> > gcc/ChangeLog:
>> >
>> >* common/config/aarch64/aarch64-common.cc
>> >(aarch64_get_arch_string_for_assembler): New.
>> >(aarch64_rewrite_march): New.
>> >(aarch64_rewrite_selected_cpu): Call new function.
>> >* config/aarch64/aarch64-elf.h (ASM_SPEC): Remove identity mapping.
>> >* config/aarch64/aarch64-protos.h
>> >(aarch64_get_arch_string_for_assembler): New.
>> >* config/aarch64/aarch64.cc
>> >(aarch64_declare_function_name): Call new function.
>> >(aarch64_start_file): Ditto.
>> >* config/aarch64/aarch64.h
>> >* config/aarch64/aarch64.h
>> >(EXTRA_SPEC_FUNCTIONS): Use new macro name.
>> >(MCPU_TO_MARCH_SPEC): Rename to...
>> >(MARCH_REWRITE_SPEC): ...this, and add new spec rule.
>> >(aarch64_rewrite_march): New declaration.
>> >(MCPU_TO_MARCH_SPEC_FUNCTIONS): Rename to...
>> >(MARCH_REWRITE_SPEC_FUNCTIONS): ...this, and add new function.
>> >(ASM_CPU_SPEC): Use new macro name.
>> >
>> > gcc/testsuite/ChangeLog:
>> >
>> >* gcc.target/aarch64/cpunative/native_cpu_21.c: Update check.
>> >* gcc.target/aarch64/cpunative/native_cpu_22.c: Update check.
>> >* gcc.target/aarch64/cpunative/info_27: New test.
>> >* gcc.target/aarch64/cpunative/info_28: New test.
>> >* gcc.target/aarch64/cpunative/info_29: New test.
>> >* gcc.target/aarch64/cpunative/native_cpu_27.c: New test.
>> >* gcc.target/aarch64/cpunative/native_cpu_28.c: New test.
>> >* gcc.target/aarch64/cpunative/native_cpu_29.c: New test.
>> >
>> >
>> > diff --git a/gcc/common/config/aarch64/aarch64-common.cc 
>> > b/gcc/common/config/aarch64/aarch64-common.cc
>> > index 
>> > 2bfc597e333b6018970a9ee6e370a66b6d0960ef..717b3238be16f39a6fd1b4143662eb540ccf292d
>> >  100644
>> > --- a/gcc/common/config/aarch64/aarch64-common.cc
>> > +++ b/gcc/common/config/aarch64/aarch64-common.cc
>> > @@ -371,6 +371,119 @@ aarch64_get_extension_string_for_isa_flags
>> >return outstr;
>> >  }
>> >  
>> > +/* Generate an arch string to be passed to the assembler.
>> > +
>> > +   Several flags were added retrospectively for features that were 
>> > previously
>> > +   enabled only by specifying an architecture version.  We want to avoid
>> > +   passing these flags to the assembler if possible, to improve 
>> > compatibility
>> > +   with older assemblers.  */
>> > +
>> > +std::string
>> > +aarch64_get_arch_string_for_assembler (aarch64_arch arch,
>> > + aarch64_feature_flags flags)
>> > +{
>> > +  if (!(flags & AARCH64_FL_FCMA) || !(flags & AARCH64_FL_JSCVT))
>> > +goto done;
>> > +
>> > +  if (arch == AARCH64_ARCH_V8A
>> > +  || arch == AARCH64_ARCH_V8_1A
>> > +  || arch == AARCH64_ARCH_V8_2A)
>> > +arch = AARCH64_ARCH_V8_3A;
>> > +
>> > +  if (!(flags & AARCH64_FL_RCPC2))
>> > +goto done;
>> > +
>> > +  if (arch == AARCH64_ARCH_V8_3A)
>> > +arch = AARCH64_ARCH_V8_4A;
>> > +
>> > +  if (!(flags & AARCH64_FL_FRINTTS) || !(flags & AARCH64_FL_FLAGM2))
>> > +goto done;
>> > +
>> > +  if (arch == AARCH64_ARCH_V8_4A)
>> > +arch = AARCH64_ARCH_V8_5A;
>> > +
>> > +  if (!(flags & AARCH64_FL_WFXT))
>> > +goto done;
>> > +
>> > +  if (arch == AARCH64_ARCH_V8_5A || arch == AARCH64_ARCH_V8_6A)
>> > +{
>> > +  arch = AARCH64_ARCH_V8_7A;
>> > +  /* We don't support native detection for FEAT_XS, so we'll assume 
>> > it's
>> > +   present if the rest of these features are also present.  If we don't
>> > +   do this, then we would end up passing +noxs to the assembler.  */
>> > +  flags |= AARCH64_FL_XS;
>> > +}
>> > +done:
>> > +
>> > +  const struct arch_to_arch_name* a_to_an;
>> > +  for (a_to_an = all_architectures;
>> > +   a_to_an->arch != aarch64_no_arch;
>> > +   a_to_an++)
>> > + 

Re: [PATCH] Prefer scalar_int_mode if the size - 1 is equal to UNITS_PER_WORD.

2025-01-07 Thread Richard Sandiford
Jeff Law  writes:
> On 1/7/25 2:09 AM, Tsung Chun Lin wrote:
>> Hi,
>> 
>> Could someone help merge this patch if there are no further concerns?
> It'll get addressed.  Many contributors have been on holiday and are 
> still catching up.

FWIW, I'm happy to push the patch, but wasn't sure how to check the CI
results that Robin had asked for.

Thanks,
Richard


[PATCH] Prefer scalar_int_mode if the size - 1 is equal to UNITS_PER_WORD.

2025-01-07 Thread Patrick O'Neill
From: Jim Tsung-Chun Lin 

Re-sending this via git send-email to avoid the application/octet-stream
attachement type that prevents Patchworks/CI from finding the patch.

---

Don't use the QI vector if its size is equal to UNITS_PER_WORD for
better code generation.

Before patch:

vsetivlizero,4,e8,mf4,ta,ma
vmv.v.i v1,0
addia4,sp,12
vse8.v  v1,0(a4)

After patch:

sw  zero,12(sp)
---
 gcc/expr.cc   | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/autovec/pr113469.c | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/gcc/expr.cc b/gcc/expr.cc
index babf00f34dc..e2abef1f544 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -1062,7 +1062,7 @@ widest_fixed_size_mode_for_size (unsigned int size, 
by_pieces_operation op)
   gcc_checking_assert (size > 1);
 
   /* Use QI vector only if size is wider than a WORD.  */
-  if (can_use_qi_vectors (op) && size > UNITS_PER_WORD)
+  if (can_use_qi_vectors (op) && (size - 1) > UNITS_PER_WORD)
 {
   machine_mode mode;
   fixed_size_mode candidate;
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr113469.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr113469.c
index 52e2580c53e..6549ae61c67 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr113469.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr113469.c
@@ -51,5 +51,4 @@ void p(int buf, __builtin_va_list ab, int q) {
  } while (k);
 }
 
-/* { dg-final { scan-assembler-times 
{vsetivli\tzero,\s*4,\s*e8,\s*mf4,\s*t[au],\s*m[au]} 1 } } */
 /* { dg-final { scan-assembler-times 
{vsetivli\tzero,\s*8,\s*e8,\s*mf2,\s*t[au],\s*m[au]} 1 } } */
-- 
2.34.1



Re: [PATCH] testsuite: enable effective-target sync_char_short on RISC-V

2025-01-07 Thread Jeff Law




On 1/7/25 8:35 AM, Andreas Schwab wrote:

* lib/target-supports.exp
(check_effective_target_sync_char_short): Enable for riscv*-*-*.

OK
jeff



Re: [PATCH] c/c++: UX improvements to 'too {few, many} arguments' errors [PR118112]

2025-01-07 Thread Marek Polacek
On Thu, Dec 19, 2024 at 06:40:19PM -0500, David Malcolm wrote:
> Consider this case of a bad call to a callback function (perhaps
> due to C23 changing the meaning of () in function decls):
> 
> struct p {
> int (*bar)();
> };
> 
> void baz() {
> struct p q;
> q.bar(1);
> }
> 
> Before this patch the C frontend emits:
> 
> t.c: In function 'baz':
> t.c:7:5: error: too many arguments to function 'q.bar'
> 7 | q.bar(1);
>   | ^
> 
> and the C++ frontend emits:
> 
> t.c: In function 'void baz()':
> t.c:7:10: error: too many arguments to function
> 7 | q.bar(1);
>   | ~^~~
> 
> neither of which give the user much help in terms of knowing what
> was expected, and where the relevant declaration is.
> 
> With this patch the C frontend emits:
> 
> t.c: In function 'baz':
> t.c:7:5: error: too many arguments to function 'q.bar'; expected 0, have 1
> 7 | q.bar(1);
>   | ^ ~
> t.c:2:15: note: declared here
> 2 | int (*bar)();
>   |   ^~~
> 
> (showing the expected vs actual counts, the pertinent field decl, and
> underlining the first extraneous argument at the callsite)
> 
> and the C++ frontend emits:
> 
> t.c: In function 'void baz()':
> t.c:7:10: error: too many arguments to function; expected 0, have 1
> 7 | q.bar(1);
>   | ~^~~
> 
> (showing the expected vs actual counts; the other data was not accessible
> without a more invasive patch)
> 
> Similarly, the patch also updates the "too few arguments" case to also
> show expected vs actual counts.  Doing so requires a tweak to the
> wording to say "at least" for the case of variadic fns, and for C++ fns
> with default args, where e.g. previously the C FE emitted:
> 
> s.c: In function 'test':
> s.c:5:3: error: too few arguments to function 'callee'
> 5 |   callee ();
>   |   ^~
> s.c:1:6: note: declared here
> 1 | void callee (const char *, ...);
>   |  ^~
> 
> with this patch it emits:
> 
> s.c: In function 'test':
> s.c:5:3: error: too few arguments to function 'callee'; expected at least 1, 
> have 0
> 5 |   callee ();
>   |   ^~
> s.c:1:6: note: declared here
> 1 | void callee (const char *, ...);
>   |  ^~
> 
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> OK for trunk?
> 
> gcc/c/ChangeLog:
>   PR c/118112
>   * c-typeck.cc (inform_declaration): Add "function_expr" param and
>   use it for cases where we couldn't show the function decl to show
>   field decls for callbacks.
>   (build_function_call_vec): Add missing auto_diagnostic_group.
>   Update for new param of inform_declaration.
>   (convert_arguments): Likewise.  For the "too many arguments" case
>   add the expected vs actual counts to the message, and if we have
>   it, add the location_t of the first surplus param as a secondary
>   location within the diagnostic.  For the "too few arguments" case,
>   determine the minimum number of arguments required and add the
>   expected vs actual counts to the message, tweaking it to "at least"
>   for variadic functions.
> 
> gcc/cp/ChangeLog:
>   PR c/118112
>   * typeck.cc (error_args_num): Add params "expected_num",
>   "actual_num", and "at_least_p".  Compute "too_many_p" from these
>   rather than have it be a param.  Add expected vs actual counts to
>   the messages and tweak them for the "at least" case.
>   (convert_arguments): Update calls to error_args_num to pass in
>   expected vs actual number, and the "at_least_p", determining this
>   for the "too few" case.
> 
> gcc/testsuite/ChangeLog:
>   PR c/118112
>   * c-c++-common/too-few-arguments.c: New test.
>   * c-c++-common/too-many-arguments.c: New test.
>   * g++.dg/cpp0x/variadic169.C: Verify the reported expected vs
>   actual argument counts.
>   * g++.dg/modules/macloc-1_c.C: Update regexp for addition of param
>   counts to error message.
>   * g++.dg/modules/macloc-1_d.C: Likewise.
> 
> Signed-off-by: David Malcolm 

[...]

> diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
> index 964e549a6122..2966931ca8c1 100644
> --- a/gcc/cp/typeck.cc
> +++ b/gcc/cp/typeck.cc
> @@ -59,7 +59,7 @@ static tree get_delta_difference (tree, tree, bool, bool, 
> tsubst_flags_t);
>  static void casts_away_constness_r (tree *, tree *, tsubst_flags_t);
>  static bool casts_away_constness (tree, tree, tsubst_flags_t);
>  static bool maybe_warn_about_returning_address_of_local (tree, location_t = 
> UNKNOWN_LOCATION);
> -static void error_args_num (location_t, tree, bool);
> +static void error_args_num (location_t, tree, int, int, bool);
>  static int convert_arguments (tree, vec **, tree, int,
>tsubst_flags_t);
>  static bool is_std_move_p (tree);
> @@ -4533,11 +4533,16 @@ cp_build_function_call_vec (tree function, vec va_gc> **params,
>  }
>  
>  /* Subroutine of conver

Re: [PATCH 0/3] testsuite: RISC-V: Improve support for RV32E

2025-01-07 Thread Dimitar Dimitrov
On Tue, Jan 07, 2025 at 07:55:45AM -0800, Palmer Dabbelt wrote:
> On Mon, 09 Dec 2024 08:13:22 PST (-0800), dimi...@dinux.eu wrote:
> > Many test cases implicitly require some form of I ABI variant for
> > RISC-V to be the default.  Hence they fail when ILP32E is configured as
> > the default ABI for the toolchain.  Example error:
> > 
> >   spawn ... -march=rv32gc_zbb ...
> >   cc1: error: ILP32E ABI does not support the 'D' extension
> > 
> > This patch series adds explicit RISC-V ABI configuration to the test
> > cases, in order to remove spurious errors for RV32E toolchain.  My end
> > goal is to start running bi-monthly regression tests for RV32E, and
> > publish to gcc-testretults.
> > 
> > My understanding is that RV32E is a popular choice for low-end
> > microcontrollers, and is here to stay.  The existing RV32I test runs
> > achieve somewhat limited coverage for RV32E.  So running regression
> > tests for RV32E should be beneficial for the community.
> 
> Thanks for doing this.  This came up in the patchwork meeting, but I'm not
> actually sure how widely used the E ISAs are.  That's why they don't get the
> testing bandwidth that some of the other sub-targets do, and thus why these
> sorts of bugs linger.

I don't know the market share for E ISAs, either.  I simply noticed that
it is used in some ultra low cost microcontrollers (e.g. CH32V003 in
https://www.olimex.com/Products/Retro-Computers/RVPC/open-source-hardware).

> 
> So if you're interested in E and want to test it that's great, it's just the
> sort of thing that needs someone who cares to make sure specific sub-targets
> stay clean.  You just might be in for a bit of an uphill battle, though, as
> there's a ton of RISC-V sub-targets so these uncommon ones don't get as much
> love.

I don't anticipate a huge number of regressions.  So the effort required to 
monitor
and fix those should fit in my hobby time budget.

> 
> If you've got some specific E sub-targets you're interested in then we
> should probably get them added to CI, though we're in a bit of a CI
> resourcing crunch right now so it might be a slower process than normal...

I do not expect E targets to be added to RISE CI because I don't want to
distract the main RISC-V efforts.  I'm perfectly happy to run the
E ISA testsuite on my PC.  I'll start only with RV32EC sub-target
for now.

Regards,
Dimitar
> 
> I think Jeff already said something (they're at least marked as "Accepted"
> in patchwork), but
> 
> Acked-by: Palmer Dabbelt 
> 
> if that helps any.  Thanks!
> 


[PATCH] testsuite: arm: Add pattern for armv8-m.base to cmse-15.c test

2025-01-07 Thread Torbjörn SVENSSON
Ok for trunk and releases/gcc-14?

--

Since armv8-m.base uses thumb1 that does not suport sigcall/tailcall,
a pattern is needed that uses PUSH/BL/POP sequence instead of a single
B instruction to reuse an already existing function in the compile unit.

gcc/testsuite/ChangeLog:

* gcc.target/arm/cmse/cmse-15.c: Added pattern for armv8-m.base.

Signed-off-by: Torbjörn SVENSSON 
---
 gcc/testsuite/gcc.target/arm/cmse/cmse-15.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/gcc/testsuite/gcc.target/arm/cmse/cmse-15.c 
b/gcc/testsuite/gcc.target/arm/cmse/cmse-15.c
index 5188f1d697f..0e35830c35e 100644
--- a/gcc/testsuite/gcc.target/arm/cmse/cmse-15.c
+++ b/gcc/testsuite/gcc.target/arm/cmse/cmse-15.c
@@ -65,6 +65,10 @@ int nonsecure1 (ns_foo_t ** ns_foo_p)
 ** bl  __gnu_cmse_nonsecure_call
 ** |
 ** b   nonsecure0
+** |
+** push{r4, lr}
+** bl  nonsecure0
+** pop {r4, pc}
 ** )
 ** ...
 */
@@ -129,6 +133,10 @@ int secure1 (s_bar_t ** s_bar_p)
 ** blx r[0-3]
 ** |
 ** b   secure0
+** |
+** push{r4, lr}
+** bl  secure0
+** pop {r4, pc}
 ** )
 ** ...
 */
@@ -146,6 +154,10 @@ int secure2 (s_bar_ptr s_bar_p)
 ** blx r[0-3]
 ** |
 ** b   secure1
+** |
+** push{r4, lr}
+** bl  secure1
+** pop {r4, pc}
 ** )
 ** ...
 */
-- 
2.25.1



[COMMITTED] RISC-V: vector absolute difference expander [PR117722]

2025-01-07 Thread Vineet Gupta
This improves codegen for x264 sum of absolute difference routines.
The insn count is same, but we avoid double widening ops and ensuing
whole register moves.

Also for more general applicability, we chose to implement abs diff
vs. the sum of abs diff variant.

Suggested-by: Robin Dapp 
Co-authored-by: Pan Li 
Signed-off-by: Vineet Gupta 

PR target/117722

gcc/ChangeLog:
* config/riscv/autovec.md: Add uabd expander.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/pr117722.c: New test.

Signed-off-by: Vineet Gupta 
---
 gcc/config/riscv/autovec.md   | 26 +++
 .../gcc.target/riscv/rvv/autovec/pr117722.c   | 23 
 2 files changed, 49 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/pr117722.c

diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
index 8d22b5f9c59a..8426f12757f3 100644
--- a/gcc/config/riscv/autovec.md
+++ b/gcc/config/riscv/autovec.md
@@ -2928,3 +2928,29 @@
 riscv_vector::expand_strided_store (mode, operands);
 DONE;
   })
+
+; 
+; == Absolute difference (not including sum)
+; 
+(define_expand "uabd3"
+  [(match_operand:V_VLSI 0 "register_operand")
+   (match_operand:V_VLSI 1 "register_operand")
+   (match_operand:V_VLSI 2 "register_operand")]
+  "TARGET_VECTOR"
+  {
+rtx max = gen_reg_rtx (mode);
+insn_code icode = code_for_pred (UMAX, mode);
+rtx ops1[] = {max, operands[1], operands[2]};
+riscv_vector::emit_vlmax_insn (icode, riscv_vector::BINARY_OP, ops1);
+
+rtx min = gen_reg_rtx (mode);
+icode = code_for_pred (UMIN, mode);
+rtx ops2[] = {min, operands[1], operands[2]};
+riscv_vector::emit_vlmax_insn (icode, riscv_vector::BINARY_OP, ops2);
+
+icode = code_for_pred (MINUS, mode);
+rtx ops3[] = {operands[0], max, min};
+riscv_vector::emit_vlmax_insn (icode, riscv_vector::BINARY_OP, ops3);
+
+DONE;
+  });
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr117722.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr117722.c
new file mode 100644
index ..b675930818e1
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr117722.c
@@ -0,0 +1,23 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv_zvl256b -mabi=lp64d -O2" } */
+
+/* Generate sum of absolute difference as sub (max, min).
+   This helps with x264 sad routines.  */
+
+inline int abs(int i)
+{
+  return (i < 0 ? -i : i);
+}
+
+int pixel_sad_n(unsigned char *pix1, unsigned char *pix2, int n)
+{
+  int sum = 0;
+  for( int i = 0; i < n; i++ )
+   sum += abs(pix1[i] - pix2[i]);
+
+  return sum;
+}
+
+/* { dg-final { scan-assembler {vmin\.v} } } */
+/* { dg-final { scan-assembler {vmax\.v} } } */
+/* { dg-final { scan-assembler {vsub\.v} } } */
-- 
2.43.0



Re: [PATCH] config-ml.in: Fix multi-os-dir search

2025-01-07 Thread Jeff Law




On 1/1/25 6:42 PM, YunQiang Su wrote:

Matthias Klose  于2025年1月1日周三 22:37写道:


in https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641619.html

there are two typos in the patch, compared to the local Debian patch,



Oh, sorry it is not duplicated.


   - the subst macro has an additional parameter
   - the multilib subdirs are not subdirs in lib, but have
 their multilib suffix attached to lib.



It is not subdirectories, so we use string concat here.
the result will be like
/usr/lib/../lib32
since the output of
```
x86_64-linux-gnu-gcc -m32 --print-multi-os-directory
```
is
```
../lib32
```


ok for the trunk?
Matthias, given you probably have more insight into the patches Debian 
is carrying than anyone in the world, what's the state here?


YunQiang, can you clarify your responses?  It's unclear if you're 
objecting or not.


Jeff



[committed] Fix regression in ft32 port after recent switch table adjustments

2025-01-07 Thread Jeff Law
This is a trivial bug that showed up after Mark W's recent patch to not 
apply the size limit on jump tables.


The ft32 port has limited immediate ranges on comparisons and the casesi 
expander didn't honor those.  It'd blindly pass along an out of range 
constant.


This patch adds the trivial adjustment to force an out of range constant 
into a register.  It fixes these regressions:



Tests that now fail, but worked before (3 tests):

ft32-sim: gcc: gcc.c-torture/compile/pr34093.c   -O1  (test for excess errors)
ft32-sim: gcc: gcc.dg/torture/pr106809.c   -O1  (test for excess errors)
ft32-sim: gcc: gcc.dg/torture/pr106809.c   -O1  (test for excess errors)


Tested in my tester.No other tests were fixed.

Jeff

commit a550edc3fae828cef67aac050b80179a97bb2fad
Author: Jeff Law 
Date:   Tue Jan 7 12:20:15 2025 -0700

Fix regression in ft32 port after recent switch table adjustments

This is a trivial bug that showed up after Mark W's recent patch to not 
apply
the size limit on jump tables.

The ft32 port has limited immediate ranges on comparisons and the casesi
expander didn't honor those.  It'd blindly pass along an out of range 
constant.

This patch adds the trivial adjustment to force an out of range constant 
into a
register.  It fixes these regressions:

> Tests that now fail, but worked before (3 tests):
>
> ft32-sim: gcc: gcc.c-torture/compile/pr34093.c   -O1  (test for excess 
errors)
> ft32-sim: gcc: gcc.dg/torture/pr106809.c   -O1  (test for excess errors)
> ft32-sim: gcc: gcc.dg/torture/pr106809.c   -O1  (test for excess errors)
Tested in my tester.No other tests were fixed.

gcc/
* config/ft32/ft32.md (casesi expander): Force operands[2] into
a register if it's not a suitable rimm operand.

diff --git a/gcc/config/ft32/ft32.md b/gcc/config/ft32/ft32.md
index a1680666928..4d66abe009e 100644
--- a/gcc/config/ft32/ft32.md
+++ b/gcc/config/ft32/ft32.md
@@ -760,6 +760,12 @@ (define_expand "casesi"
   operands[0] = index;
 }
 
+  /* operands[2] could be an integer that is out of range for
+ the comparison insn we're going to emit.  If so, force
+ it into a register.  */
+  if (!ft32_rimm_operand (operands[2], SImode))
+operands[2] = force_reg (SImode, operands[2]);
+
   {
 rtx test = gen_rtx_GTU (VOIDmode, operands[0], operands[2]);
 emit_jump_insn (gen_cbranchsi4 (test, operands[0], operands[2], 
operands[4]));


[PATCH] dwarf2out: Emit DWARF 6 DW_AT_language_{name,version}

2025-01-07 Thread Jakub Jelinek
Hi!

DWARF has voted in yesterday https://dwarfstd.org/issues/241209.1.html ,
which is basically just a guarantee that the DWARF 6 draft
DW_AT_language_{name,version} attribute codes and content of
https://dwarfstd.org/languages-v6.html can be used as an extension
in DWARF 5 and won't be changed.

So, this patch is an alternative to the
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669671.html
patch, which had the major problem that it required changing all the
DWARF consumers to be able to debug C17 or later or C++17 or later
sources.
This patch uses still DWARF 5 DW_LANG_C11 or DW_LANG_C_plus_plus_14,
the latest code in DWARF 5 proper, so all DWARF 5 capable consumers
should be able to deal with that, but additionally emits the
DWARF 6 attributes so that newer DWARF consumers can see it isn't
just C++14 but say C++23 or C11 but C23.  Consumers which don't know
those DWARF 6 attributes would just ignore them.  This is like any other
-gno-strict-dwarf extension, except that normally we emit say DWARF 5
codes where possible only after DWARF 5 is released, while in this case
there is a guarantee it can be used before DWARF 6 is released.

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

2025-01-07  Jakub Jelinek  

include/
* dwarf2.h (enum dwarf_source_language): Fix comment pasto.
(enum dwarf_source_language_name): New type.
* dwarf2.def (DW_AT_language_name, DW_AT_language_version): New
DWARF 6 codes.
gcc/
* dwarf2out.cc (break_out_comdat_types): Copy over
DW_AT_language_{name,version} if present.
(output_skeleton_debug_sections): Remove also
DW_AT_language_{name,version}.
(gen_compile_unit_die): For C17, C23, C2Y, C++17, C++20, C++23
and C++26 emit for -gdwarf-5 -gno-strict-dwarf also
DW_AT_language_{name,version} attributes.
gcc/testsuite/
* g++.dg/debug/dwarf2/lang-cpp17.C: Add -gno-strict-dwarf to
dg-options.  Check also for DW_AT_language_{name,version} values.
* g++.dg/debug/dwarf2/lang-cpp20.C: Likewise.
* g++.dg/debug/dwarf2/lang-cpp23.C: New test.

--- include/dwarf2.h.jj 2025-01-02 11:47:47.431981968 +0100
+++ include/dwarf2.h2025-01-06 18:55:59.802378204 +0100
@@ -411,7 +411,7 @@ enum dwarf_source_language
 DW_LANG_Hylo = 0x0042,
 
 DW_LANG_lo_user = 0x8000,  /* Implementation-defined range start.  */
-DW_LANG_hi_user = 0x,  /* Implementation-defined range start.  */
+DW_LANG_hi_user = 0x,  /* Implementation-defined range end.  */
 
 /* MIPS.  */
 DW_LANG_Mips_Assembler = 0x8001,
@@ -428,6 +428,59 @@ enum dwarf_source_language
 DW_LANG_Rust_old = 0x9000
   };
 
+/* DWARF 6 source language names and codes.  */
+enum dwarf_source_language_name
+  {
+/* https://dwarfstd.org/languages-v6.html */
+DW_LNAME_Ada = 0x0001,
+DW_LNAME_BLISS = 0x0002,
+DW_LNAME_C = 0x0003,
+DW_LNAME_C_plus_plus = 0x0004,
+DW_LNAME_Cobol = 0x0005,
+DW_LNAME_Crystal = 0x0006,
+DW_LNAME_D = 0x0007,
+DW_LNAME_Dylan = 0x0008,
+DW_LNAME_Fortran = 0x0009,
+DW_LNAME_Go = 0x000a,
+DW_LNAME_Haskell = 0x000b,
+DW_LNAME_Java = 0x000c,
+DW_LNAME_Julia = 0x000d,
+DW_LNAME_Kotlin = 0x000e,
+DW_LNAME_Modula2 = 0x000f,
+DW_LNAME_Modula3 = 0x0010,
+DW_LNAME_ObjC = 0x0011,
+DW_LNAME_ObjC_plus_plus = 0x0012,
+DW_LNAME_OCaml = 0x0013,
+DW_LNAME_OpenCL_C = 0x0014,
+DW_LNAME_Pascal = 0x0015,
+DW_LNAME_PLI = 0x0016,
+DW_LNAME_Python = 0x0017,
+DW_LNAME_RenderScript = 0x0018,
+DW_LNAME_Rust = 0x0019,
+DW_LNAME_Swift = 0x001a,
+DW_LNAME_UPC = 0x001b,
+DW_LNAME_Zig = 0x001c,
+DW_LNAME_Assembly = 0x001d,
+DW_LNAME_C_sharp = 0x001e,
+DW_LNAME_Mojo = 0x001f,
+DW_LNAME_GLSL = 0x0020,
+DW_LNAME_GLSL_ES = 0x0021,
+DW_LNAME_HLSL = 0x0022,
+DW_LNAME_OpenCL_CPP = 0x0023,
+DW_LNAME_CPP_for_OpenCL = 0x0024,
+DW_LNAME_SYCL = 0x0025,
+DW_LNAME_Ruby = 0x0026,
+DW_LNAME_Move = 0x0027,
+DW_LNAME_Hylo = 0x0028,
+DW_LNAME_HIP = 0x0029,
+DW_LNAME_Odin = 0x002a,
+DW_LNAME_P4 = 0x002b,
+DW_LNAME_Metal = 0x002c,
+
+DW_LNAME_lo_user = 0x8000, /* Implementation-defined range start.  */
+DW_LNAME_hi_user = 0x  /* Implementation-defined range end.  */
+  };
+
 /* Names and codes for macro information.  */
 enum dwarf_macinfo_record_type
   {
--- include/dwarf2.def.jj   2025-01-02 11:47:47.191985318 +0100
+++ include/dwarf2.def  2025-01-06 18:39:02.642383150 +0100
@@ -364,6 +364,9 @@ DW_AT (DW_AT_export_symbols, 0x89)
 DW_AT (DW_AT_deleted, 0x8a)
 DW_AT (DW_AT_defaulted, 0x8b)
 DW_AT (DW_AT_loclists_base, 0x8c)
+/* DWARF 6.  */
+DW_AT (DW_AT_language_name, 0x90)
+DW_AT (DW_AT_language_version, 0x91)
 
 DW_AT_DUP (DW_AT_lo_user, 0x2000) /* Implementation-defined range start.  */
 DW_AT_DUP (DW_AT_hi_user, 0x3fff) /* Implementation-defined range end.  */
--- gcc/dwarf2out.cc.jj 2025-01-02 11:23:35

Re: [PATCH] riscv: add mising masking in lrsc expander (PR118137)

2025-01-07 Thread Jeff Law




On 1/7/25 8:37 AM, Andreas Schwab wrote:

gcc:
PR target/118137
* config/riscv/sync.md ("lrsc_atomic_exchange"): Apply mask
to shifted value.

gcc/testsuite:
PR target/118137
* gcc.dg/atomic/pr118137.c: New.

Thanks.  I went ahead and pushed this to the trunk.

jeff



Re: [PATCH v2 1/4] testsuite: RISC-V: Add effective target for E ABI variant

2025-01-07 Thread Dimitar Dimitrov
On Mon, Jan 06, 2025 at 07:52:23AM -0700, Jeff Law wrote:
> 
> 
> On 1/4/25 11:01 AM, Dimitar Dimitrov wrote:
> > Add new effective target check for either ILP32E or ILP64E ABI variants.
> > 
> > Initial implementation only checks for RV32E or RV64E ISA, which in turn
> > implies that ILP32E/ILP64E ABI is used.  The RV32I+ILP32E and
> > RV64I+ILP64E combinations are not yet caught by the check, but they
> > do not seem to be widely used currently.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * lib/target-supports.exp (check_effective_target_riscv_abi_e):
> > New procedure.
> All 4 patches in this series are fine.  I do fear that trying to keep the E
> variants "clean" will be a long term maintenance task though. Hell, we're
> struggling with keeping the existing stuff clean.
> 
> But IMHO that's not a good reason to reject, especially with someone that's
> planning to test this regularly (and presumably send fixes regularly).

Thanks, pushed as r15--gf56bca0bbae762.  Yes, I intend to share test
results, and will try to fix regressions.  That would be a good
opportunity for me to get to know the RISC-V backend.

Regards,
Dimitar
> 
> Jeff
> 
> 


Re: [PATCH] Prefer scalar_int_mode if the size - 1 is equal to UNITS_PER_WORD.

2025-01-07 Thread Patrick O'Neill



On 1/7/25 10:18, Richard Sandiford wrote:

Jeff Law  writes:

On 1/7/25 2:09 AM, Tsung Chun Lin wrote:

Hi,

Could someone help merge this patch if there are no further concerns?

It'll get addressed.  Many contributors have been on holiday and are
still catching up.

FWIW, I'm happy to push the patch, but wasn't sure how to check the CI
results that Robin had asked for.

Thanks,
Richard


The original patch was sent with application/octet-stream
attachment type which means it doesn't show up in patchworks
(so the CI bot doesn't know it exists).
Another instance of this: 
https://inbox.sourceware.org/gcc-patches/2342bfa1-c37f-4e57-bfc7-6dc46ceb1...@rivosinc.com/


I'll re-send it for the CI and ping this thread with a link to the
results when it's done.

Thanks,
Patrick


  1   2   >