[PATCH] c++: Update TYPE_FIELDS of variant types if cp_parser_late_parsing_default_args etc. modify it [PR98533]

[Jakub Jelinek]

Hi!

The following testcases ICE during type verification, because TYPE_FIELDS
of e.g. S RECORD_TYPE in pr119123.C is different from TYPE_FIELDS of const S.
Various decls are added to S's TYPE_FIELDS first, then finish_struct
indirectly calls fixup_type_variants to sync the variant copies.
But later on cp_parser_class_specifier calls
cp_parser_late_parsing_default_args and that apparently adds a lambda
type (from default argument) to TYPE_FIELDS of S.
Dunno if that is right or not, assuming it is right, the following
patch fixes it by updating TYPE_FIELDS of variant types if there were
any changes in the various functions cp_parser_class_specifier defers and
calls on the outermost enclosing class.
There was quite a lot of code repetition already before, so the patch
uses a lambda to avoid the repetitions.
To my surprise, in some of the contract testcases (
g++.dg/contracts/contracts-friend1.C
g++.dg/contracts/contracts-nested-class1.C
g++.dg/contracts/contracts-nested-class2.C
g++.dg/contracts/contracts-redecl7.C
g++.dg/contracts/contracts-redecl8.C
) it is actually setting class_type and pushing TRANSLATION_UNIT_DECL
rather than some class types in some cases.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Or should the lambda pushing into the containing class be somehow avoided?

2025-03-06  Jakub Jelinek  

PR c++/98533
PR c++/119123
* parser.cc (cp_parser_class_specifier): Update TYPE_FIELDS of
variant types in case cp_parser_late_parsing_default_args etc. change
TYPE_FIELDS on the main variant.  Add switch_to_class lambda and
use it to simplify repeated class switching code.

* g++.dg/cpp0x/pr98533.C: New test.
* g++.dg/cpp0x/pr119123.C: New test.

--- gcc/cp/parser.cc.jj 2025-02-27 22:04:36.007028112 +0100
+++ gcc/cp/parser.cc2025-03-06 16:35:12.770694734 +0100
@@ -27718,6 +27718,7 @@ cp_parser_class_specifier (cp_parser* pa
 {
   tree decl;
   tree class_type = NULL_TREE;
+  tree class_type_fields = NULL_TREE;
   tree pushed_scope = NULL_TREE;
   unsigned ix;
   cp_default_arg_entry *e;
@@ -27731,6 +27732,33 @@ cp_parser_class_specifier (cp_parser* pa
  vec_safe_truncate (unparsed_funs_with_definitions, 0);
}
 
+  auto switch_to_class = [&] (tree t)
+   {
+ if (class_type != t)
+   {
+ /* cp_parser_late_parsing_default_args etc. could have changed
+TYPE_FIELDS (class_type), propagate that to all variants.  */
+ if (class_type
+ && RECORD_OR_UNION_TYPE_P (class_type)
+ && TYPE_FIELDS (class_type) != class_type_fields)
+   for (tree variant = TYPE_NEXT_VARIANT (class_type);
+variant; variant = TYPE_NEXT_VARIANT (variant))
+ TYPE_FIELDS (variant) = TYPE_FIELDS (class_type);
+ if (pushed_scope)
+   pop_scope (pushed_scope);
+ class_type = t;
+ class_type_fields = NULL_TREE;
+ if (t)
+   {
+ if (RECORD_OR_UNION_TYPE_P (class_type))
+   class_type_fields = TYPE_FIELDS (class_type);
+ pushed_scope = push_scope (class_type);
+   }
+ else
+   pushed_scope = NULL_TREE;
+   }
+   };
+
   /* In a first pass, parse default arguments to the functions.
 Then, in a second pass, parse the bodies of the functions.
 This two-phased approach handles cases like:
@@ -27746,13 +27774,7 @@ cp_parser_class_specifier (cp_parser* pa
  decl = e->decl;
  /* If there are default arguments that have not yet been processed,
 take care of them now.  */
- if (class_type != e->class_type)
-   {
- if (pushed_scope)
-   pop_scope (pushed_scope);
- class_type = e->class_type;
- pushed_scope = push_scope (class_type);
-   }
+ switch_to_class (e->class_type);
  /* Make sure that any template parameters are in scope.  */
  maybe_begin_member_template_processing (decl);
  /* Parse the default argument expressions.  */
@@ -27768,13 +27790,7 @@ cp_parser_class_specifier (cp_parser* pa
   FOR_EACH_VEC_SAFE_ELT (unparsed_noexcepts, ix, decl)
{
  tree ctx = DECL_CONTEXT (decl);
- if (class_type != ctx)
-   {
- if (pushed_scope)
-   pop_scope (pushed_scope);
- class_type = ctx;
- pushed_scope = push_scope (class_type);
-   }
+ switch_to_class (ctx);
 
  tree def_parse = TYPE_RAISES_EXCEPTIONS (TREE_TYPE (decl));
  def_parse = TREE_PURPOSE (def_parse);
@@ -27830,13 +27846,7 @@ cp_parser_class_specifier (cp_parser* pa
   FOR_EACH_VEC_SAFE_ELT (unparsed_nsdmis, ix, decl)
{
  tree ctx = type_context_for_name_lookup (decl);
- 

[committed] testsuite: Add test for already fixed PR [PR104826]

[Jakub Jelinek]

Hi!

ICE on this test was fixed by r15-2131.  This just adds test for it.

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

2025-03-06  Jakub Jelinek  

PR fortran/104826
* gfortran.dg/gomp/pr104826.f90: New test.

--- gcc/testsuite/gfortran.dg/gomp/pr104826.f90.jj  2025-03-06 
14:28:53.910892006 +0100
+++ gcc/testsuite/gfortran.dg/gomp/pr104826.f90 2025-03-06 14:28:45.766004575 
+0100
@@ -0,0 +1,8 @@
+! PR fortran/104826
+program pr104826
+  character(:), allocatable :: x
+  save
+  !$omp target
+  x = 'abc'
+  !$omp end target
+end

Jakub

Re: [PATCH] middle-end/118801 - excessive redundant DEBUG BEGIN_STMT

[Alexandre Oliva]

On Feb 11, 2025, Richard Biener  wrote:

> Alex, is this OK for trunk?

>> PR middle-end/118801
>> * tree-ssa-dce.cc (eliminate_unnecessary_stmts): Prune
>> sequences of uninterrupted DEBUG BEGIN_STMTs, keeping only
>> the last of a set with unique location.

It seems like a reasonable trade-off.  Without consumers for location
views, there's no use in carrying these duplicates.

I'd have added an option or a parameter to control this compression, but
that's just me.


If we had consumers for views, this would be discarding potentially
useful and correct information, but we can cross that bridge if we ever
get to it.

Then, instead of deleting debug begin stmts, we could compress them, so
that a single debug stmt could carry a sequence of any number of debug
begin stmts without intervening code or even side effects (debug binds).
One might benefit from being able to single-step, in a debugger, source
stmts for which some code and state was expected, even if nothing
remained in the end.

With this compression I propose, we'd be able to output all location
information without slowing down stmt walks.

But we have no use for that now, so please go ahead with your patch.

Sorry about the delay.

-- 
Alexandre Oliva, happy hackerhttps://blog.lx.oliva.nom.br/
Free Software Activist FSFLA co-founder GNU Toolchain Engineer
Learn the truth about Richard Stallman at https://stallmansupport.org/

Re: [RFC][C]New syntax for the argument of counted_by attribute for C language

[Yeoul Na]

Hi Qing,

Thanks for writing up the RFC and keeping us in the loop. Are you planning to 
add “__self.” to GCC's C++ compiler as well in the future? The problem we have 
with “__self” being a default way of annotating bounds is that C++ 
compatibility because bounds annotations are supposed to work in headers shared 
between C and C++ and C++ should be able to parse it to secure the boundary 
between the two languages. Another problem is the usability. The user will have 
to write more code “__self.” all the time in the most common use cases, which 
would be a huge regression for the usability of the language.

We are planning to write up alternative proposal without having to introduce a 
new syntax to the C standard. We’ll discuss how we address problems raised 
here. Please see my inlined comments.

Best,
Yeoul


> On Mar 6, 2025, at 2:03 PM, Yeoul Na  wrote:
> 
> + John & Félix & Patryk & Henrik
> 
>> On Mar 6, 2025, at 1:44 PM, Qing Zhao  wrote:
>> 
>> Hi,
>> 
>> Since I sent the patch series for “extend counted_by attribute to pointer 
>> fields of structure” two months ago, a lot of discussion were invoked both in
>> GCC community and CLANG community:
>> 
>> https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673837.html
>> https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-c-fbounds-safety/70854/131?u=gwelymernans
>> 
>> After reading all these discussions, understanding, studying, more 
>> discussions,  
>> and finally making the whole picture clearer, we came up with a proposal to 
>> change
>> the current design and add a new syntax for the argument of counted_by 
>> attribute. 
>> 
>> The original idea of the new syntax was from Joseph, Michael and Martin, 
>> Bill and Kees
>> involved in the whole process of the proposal, providing a lot of 
>> suggestions and
>> comments. Really appreciate for the help from all of them. 
>> 
>> In this thread, I am also CC’ing several people from Apple who worked on the 
>> -fbounds-safety
>> project on CLANG side: yeoul...@apple.com , 
>> d_tard...@apple.com , dl...@apple.com 
>> ,
>> and dcough...@apple.com .  
>> 
>> Please take a look at the proposal in below.
>> 
>> Let me know if you have any comments and suggestions.
>> 
>> Thanks.
>> 
>> Qing.
>> 
>> =
>> 
>> New syntax for the argument of counted_by attribute
>> --An extension to C language  
>> 
>> Outline
>> 
>> 0. A simple summary of the proposal
>> 
>> 1. The motivation
>> 1.1 The current syntax of the counted_by argument might break existing legal 
>> C code
>> 1.2 New requests from the users of the counted_by attribute
>> 1.2.1 Refer to a field in the nested structure
>> 1.2.2 Refer to globals or locals
>> 1.2.3 Represent simple expression
>> 1.2.4 Forward referencing
>> 
>> 2. The requirement
>> 
>> 3. The proposed new syntax
>> 3.1 Legal C code with VLA works correctly when mixing with counted_by
>> 3.2 Satisfy all the new requests
>> 3.2.1  Refer to a field in the nested structure
>> 3.2.2 Refer to globals or locals
>> 3.2.3 Represent simple expression
>> 3.3 How to resolve the forward reference issue in section 1.2.4?
>> 
>> Appendix A: Scope of variables in C and C++
>> --The hints to the design of counted_by in C
>> Appendix B: An example in linux kernel that the global cannot be "const" 
>> qualified
>> 
>> 
>> 0. A simple summary of the proposal
>> 
>> We propose a new syntax to the argument of the counted_by attribute:  
>> * Introduce a new keyword, __self, to represent the new concept, 
>>  "the current object" of the nearest non-anonymous enclosing structure, 
>>  which allows the object of the structure to refer to its own member inside
>>  the structure definition.  
>> 
>> * With the new keyword, __self, the member variable can be referenced 
>>   by appending the member access operator "." to "__self", such as, 
>>   __self.member.
>> 
>> * This new keyword is invalid except in the bounds checking attributes, 
>>   such as "counted_by", etc., inside a structure definition.
>> 
>> * Simple expression is enabled by this new keyword inside the attribute 
>>   counted_by with the following limitation:
>> A. no side-effect is allowed;
>> and
>> B. the operators of the expression are simple arithmetic operators, and the 
>>operands could be one of:
>>  B.1 __self.member or __self.member1.member2...(for nested structure);
>>  B.2 constant;
>>  B.3 locals that will not be changed after initialization;
>>  B.4 globals that will not be changed after initialization;
>> 
>> 
>> 1. The motivation  
>> 
>> There are two major motivations for this new syntax.  
>> 
>> 1.1 The current syntax of the counted_by argument might break existing legal 
>> C code
>> 
>> The counted_by attribute is currently defined as:  
>> (https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-counted_005fby-variable-attribute)
>> 
>> c

Re: [PATCH v3 8/8] LoongArch: Implement [su]dot_prod* for LSX and LASX modes

[Lulu Cheng]

在 2025/3/7 下午2:37, Lulu Cheng 写道:


在 2025/2/14 下午8:21, Xi Ruoyao 写道:

Despite it's just a special case of "a widening product of which the
result used for reduction," having these standard names allows to
recognize the dot product pattern earlier and it may be beneficial to
optimization.  Also fix some test failures with the test cases:

- gcc.dg/vect/vect-reduc-chain-2.c
- gcc.dg/vect/vect-reduc-chain-3.c
- gcc.dg/vect/vect-reduc-chain-dot-slp-3.c
- gcc.dg/vect/vect-reduc-chain-dot-slp-4.c

gcc/ChangeLog:

* config/loongarch/simd.md (wvec_half): New define_mode_attr.
(dot_prod): New define_expand.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/wide-mul-reduc-2.c (dg-final): Scan
DOT_PROD_EXPR in optimized tree.
---
  gcc/config/loongarch/simd.md  | 29 +++
  .../gcc.target/loongarch/wide-mul-reduc-2.c   |  3 +-
  2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/gcc/config/loongarch/simd.md b/gcc/config/loongarch/simd.md
index 661f5dc8dda..45d2bcaec2e 100644
--- a/gcc/config/loongarch/simd.md
+++ b/gcc/config/loongarch/simd.md

/* snip */

  +(define_expand "dot_prod"
+  [(match_operand: 0 "register_operand" "=f,f")
+   (match_operand:IVEC  1 "register_operand" " f,f")
+   (match_operand:IVEC  2 "register_operand" " f,f")
+   (match_operand: 3 "reg_or_0_operand" " 0,YG")


Hi,

I have a question, why should operands[3] be the same operand as 
operands[0]?


Oh, I think I get it now, because we need to use vmaddw{ev/add}.

Thanks.





+   (any_extend (const_int 0))]
+  ""

RE: [1/3 PATCH]AArch64: add support for partial modes to last extractions [PR118464]

[Tamar Christina]

> > diff --git a/gcc/config/aarch64/aarch64-sve.md b/gcc/config/aarch64/aarch64-
> sve.md
> > index
> a93bc463a909ea28460cc7877275fce16e05f7e6..205eeec2e35544de848e0dbb
> 48e3f5ae59391a88 100644
> > --- a/gcc/config/aarch64/aarch64-sve.md
> > +++ b/gcc/config/aarch64/aarch64-sve.md
> > @@ -3107,12 +3107,12 @@ (define_insn "@extract__"
> >[(set (match_operand: 0 "register_operand")
> > (unspec:
> >   [(match_operand: 1 "register_operand")
> > -  (match_operand:SVE_FULL 2 "register_operand")]
> > +  (match_operand:SVE_ALL 2 "register_operand")]
> >   LAST))]
> >"TARGET_SVE"
> >{@ [ cons: =0 , 1   , 2  ]
> > - [ ?r   , Upl , w  ] last\t%0, %1, %2.
> > - [ w, Upl , w  ] last\t%0, %1, %2.
> > + [ ?r   , Upl , w  ] last\t%0, %1, %2.
> 
> This looks good for the Vetype->Vctype part, but it still needs the
> vwcore->vccore change too.  If we don't do that, we could end up pairing
> a w destination with a .d source, which would trigger an assembler error.
> 

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

Ok for master?

Thanks,
Tamar

gcc/ChangeLog:


PR tree-optimization/118464
PR tree-optimization/116855
* config/aarch64/aarch64-sve.md (@extract__,
@fold_extract__,
@aarch64_fold_extract_vector__): Change SVE_FULL to
SVE_ALL.
* config/aarch64/iterators.md (vccore): Add more partial types.

-- inline copy of patch --

diff --git a/gcc/config/aarch64/aarch64-sve.md 
b/gcc/config/aarch64/aarch64-sve.md
index 
a93bc463a909ea28460cc7877275fce16e05f7e6..3dbd65986ec70b95f01fbf6c992570d895d9d548
 100644
--- a/gcc/config/aarch64/aarch64-sve.md
+++ b/gcc/config/aarch64/aarch64-sve.md
@@ -3107,12 +3107,12 @@ (define_insn "@extract__"
   [(set (match_operand: 0 "register_operand")
(unspec:
  [(match_operand: 1 "register_operand")
-  (match_operand:SVE_FULL 2 "register_operand")]
+  (match_operand:SVE_ALL 2 "register_operand")]
  LAST))]
   "TARGET_SVE"
   {@ [ cons: =0 , 1   , 2  ]
- [ ?r   , Upl , w  ] last\t%0, %1, %2.
- [ w, Upl , w  ] last\t%0, %1, %2.
+ [ ?r   , Upl , w  ] last\t%0, %1, %2.
+ [ w, Upl , w  ] last\t%0, %1, %2.
   }
 )
 
@@ -8899,26 +8899,26 @@ (define_insn "@fold_extract__"
(unspec:
  [(match_operand: 1 "register_operand")
   (match_operand: 2 "register_operand")
-  (match_operand:SVE_FULL 3 "register_operand")]
+  (match_operand:SVE_ALL 3 "register_operand")]
  CLAST))]
   "TARGET_SVE"
   {@ [ cons: =0 , 1 , 2   , 3  ]
- [ ?r   , 0 , Upl , w  ] clast\t%0, %2, %0, 
%3.
- [ w, 0 , Upl , w  ] clast\t%0, %2, %0, 
%3.
+ [ ?r   , 0 , Upl , w  ] clast\t%0, %2, %0, 
%3.
+ [ w, 0 , Upl , w  ] clast\t%0, %2, %0, 
%3.
   }
 )
 
 (define_insn "@aarch64_fold_extract_vector__"
-  [(set (match_operand:SVE_FULL 0 "register_operand")
-   (unspec:SVE_FULL
- [(match_operand:SVE_FULL 1 "register_operand")
+  [(set (match_operand:SVE_ALL 0 "register_operand")
+   (unspec:SVE_ALL
+ [(match_operand:SVE_ALL 1 "register_operand")
   (match_operand: 2 "register_operand")
-  (match_operand:SVE_FULL 3 "register_operand")]
+  (match_operand:SVE_ALL 3 "register_operand")]
  CLAST))]
   "TARGET_SVE"
   {@ [ cons: =0 , 1 , 2   , 3  ]
- [ w, 0 , Upl , w  ] clast\t%0., %2, %0., 
%3.
- [ ?&w  , w , Upl , w  ] movprfx\t%0, %1\;clast\t%0., %2, 
%0., %3.
+ [ w, 0 , Upl , w  ] clast\t%0., %2, %0., 
%3.
+ [ ?&w  , w , Upl , w  ] movprfx\t%0, %1\;clast\t%0., %2, 
%0., %3.
   }
 )
 
diff --git a/gcc/config/aarch64/iterators.md b/gcc/config/aarch64/iterators.md
index 
5bfd6e7d362af0b5160d50c6d117e60790af7f3d..146453b0516848acd40e5f34fd8843fe74c18dbf
 100644
--- a/gcc/config/aarch64/iterators.md
+++ b/gcc/config/aarch64/iterators.md
@@ -2025,8 +2025,12 @@ (define_mode_attr vwcore [(V8QI "w") (V16QI "w")
 ;; Like vwcore, but for the container mode rather than the element mode.
 (define_mode_attr vccore [(VNx16QI "w") (VNx8QI "w") (VNx4QI "w") (VNx2QI "x")
  (VNx8HI "w") (VNx4HI "w") (VNx2HI "x")
+ (VNx8HF "w") (VNx4HF "w") (VNx2HF "x")
+ (VNx8BF "w") (VNx4BF "w") (VNx2BF "x")
  (VNx4SI "w") (VNx2SI "x")
- (VNx2DI "x")])
+ (VNx4SF "w") (VNx2SF "x")
+ (VNx2DI "x")
+ (VNx2DF "x")])
 
 ;; Double vector types for ALLX.
 (define_mode_attr Vallxd [(QI "8b") (HI "4h") (SI "2s")])


rb19246.patch
Description: rb19246.patch

[PATCH] c: Fix warning after an error on a return statment [PR60440]

[Andrew Pinski]

Like r5-6912-g3dbb84276aca10 but this is for the C front-end.
Basically we have an error on a return statement, we just return
error_mark_node and then the warning happens as there is no return
statement. Anyways instead mark the current function for supression
of the warning instead.

PR c/60440

gcc/c/ChangeLog:

* c-typeck.cc (c_finish_return): Mark the current function
for supression of the -Wreturn-type if there was an error
on the return statement.

gcc/testsuite/ChangeLog:

* gcc.dg/Wreturn-mismatch-2.c: Change dg-warning
for the last -Wreturn-type to dg-bogus.
* gcc.dg/pr60440-1.c: New test.

Signed-off-by: Andrew Pinski 
---
 gcc/c/c-typeck.cc |  7 ++-
 gcc/testsuite/gcc.dg/Wreturn-mismatch-2.c |  2 +-
 gcc/testsuite/gcc.dg/pr60440-1.c  | 10 ++
 3 files changed, 17 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr60440-1.c

diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index 691b583db3f..a13989a6607 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -12765,7 +12765,12 @@ c_finish_return (location_t loc, tree retval, tree 
origtype, bool musttail_p)
 
   current_function_returns_value = 1;
   if (t == error_mark_node)
-   return NULL_TREE;
+   {
+ /* Suppress -Wreturn-type for this function.  */
+ if (warn_return_type)
+   suppress_warning (current_function_decl, OPT_Wreturn_type);
+ return NULL_TREE;
+   }
 
   save = in_late_binary_op;
   if (C_BOOLEAN_TYPE_P (TREE_TYPE (res))
diff --git a/gcc/testsuite/gcc.dg/Wreturn-mismatch-2.c 
b/gcc/testsuite/gcc.dg/Wreturn-mismatch-2.c
index 08811024b7e..52852261a0d 100644
--- a/gcc/testsuite/gcc.dg/Wreturn-mismatch-2.c
+++ b/gcc/testsuite/gcc.dg/Wreturn-mismatch-2.c
@@ -37,5 +37,5 @@ int
 f7 (void)
 {
   return f1 (); /* { dg-error "void value not ignored as it ought to be" } */
-} /* { dg-warning "control reaches end of non-void\[^\n\r\]*-Wreturn-type" } */
+} /* { dg-bogus "control reaches end of non-void\[^\n\r\]*-Wreturn-type" } */
 
diff --git a/gcc/testsuite/gcc.dg/pr60440-1.c b/gcc/testsuite/gcc.dg/pr60440-1.c
new file mode 100644
index 000..cd179cf1c52
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr60440-1.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-Wreturn-type" } */
+
+/* PR c/60440 */
+/* Don't warn for a missing return when there was an error
+   on the return stamtent. */
+
+int f(int a) {
+  return a + b; /* { dg-error "undeclared" } */
+} /* { dg-bogus "control reaches end of non-void function" } */
-- 
2.34.1

[PATCH 2/3] LoongArch: testsuite: Fix gcc.dg/vect/bb-slp-77.c.

[Lulu Cheng]

The issue is the same as 12383255fe4e82c31f5e42c72a8fbcb1b5dea35d.
Neither is .REDUC_PLUS set for V2SImode on LoongArch, so add it
to the list of targets not expecting BB vectorization.

gcc/testsuite/ChangeLog:

* gcc.dg/vect/bb-slp-77.c: Add loongarch*-*-* to the list
of expected failing targets.

---
 gcc/testsuite/gcc.dg/vect/bb-slp-77.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-77.c 
b/gcc/testsuite/gcc.dg/vect/bb-slp-77.c
index bc74f6a4db3..2057f038f2f 100644
--- a/gcc/testsuite/gcc.dg/vect/bb-slp-77.c
+++ b/gcc/testsuite/gcc.dg/vect/bb-slp-77.c
@@ -71,4 +71,4 @@ void test(const int n, float * restrict s, const void * 
restrict vx, const void
 *s = sumf;
 }
 
-/* { dg-final { scan-tree-dump-times "optimized: basic block" 1 "slp1"  { 
target { { vect_int_mult && vect_element_align } && { ! { powerpc*-*-* 
x86_64-*-* i?86-*-* } } } } } } */
+/* { dg-final { scan-tree-dump-times "optimized: basic block" 1 "slp1"  { 
target { { vect_int_mult && vect_element_align } && { ! { powerpc*-*-* 
x86_64-*-* i?86-*-* loongarch*-*-* } } } } } } */
-- 
2.34.1

[PATCH 1/3] LoongArch: testsuite: Fix pr112325.c and pr117888-1.c.

[Lulu Cheng]

By default, vectorization is not enabled on LoongArch,
resulting in the failure of these two test cases.

gcc/testsuite/ChangeLog:

* gcc.dg/vect/pr112325.c: Add the vector compilation
option '-mlsx' for LoongArch.
* gcc.dg/vect/pr117888-1.c: Likewise.

---
 gcc/testsuite/gcc.dg/vect/pr112325.c   | 1 +
 gcc/testsuite/gcc.dg/vect/pr117888-1.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/gcc/testsuite/gcc.dg/vect/pr112325.c 
b/gcc/testsuite/gcc.dg/vect/pr112325.c
index 143903beab2..8689fbfe092 100644
--- a/gcc/testsuite/gcc.dg/vect/pr112325.c
+++ b/gcc/testsuite/gcc.dg/vect/pr112325.c
@@ -4,6 +4,7 @@
 /* { dg-require-effective-target vect_shift } */
 /* { dg-additional-options "-mavx2" { target x86_64-*-* i?86-*-* } } */
 /* { dg-additional-options "--param max-completely-peeled-insns=200" { target 
powerpc64*-*-* } } */
+/* { dg-additional-options "-mlsx" { target loongarch64-*-* } } */
 
 typedef unsigned short ggml_fp16_t;
 static float table_f32_f16[1 << 16];
diff --git a/gcc/testsuite/gcc.dg/vect/pr117888-1.c 
b/gcc/testsuite/gcc.dg/vect/pr117888-1.c
index 4796a7c83c1..0b31fcdc423 100644
--- a/gcc/testsuite/gcc.dg/vect/pr117888-1.c
+++ b/gcc/testsuite/gcc.dg/vect/pr117888-1.c
@@ -4,6 +4,7 @@
 /* { dg-require-effective-target vect_shift } */
 /* { dg-additional-options "-mavx2" { target x86_64-*-* i?86-*-* } } */
 /* { dg-additional-options "--param max-completely-peeled-insns=200" { target 
powerpc64*-*-* } } */
+/* { dg-additional-options "-mlsx" { target loongarch64-*-* } } */
 
 typedef unsigned short ggml_fp16_t;
 static float table_f32_f16[1 << 16];
-- 
2.34.1

Re: [PATCH v3 8/8] LoongArch: Implement [su]dot_prod* for LSX and LASX modes

[Lulu Cheng]

在 2025/2/14 下午8:21, Xi Ruoyao 写道:

Despite it's just a special case of "a widening product of which the
result used for reduction," having these standard names allows to
recognize the dot product pattern earlier and it may be beneficial to
optimization.  Also fix some test failures with the test cases:

- gcc.dg/vect/vect-reduc-chain-2.c
- gcc.dg/vect/vect-reduc-chain-3.c
- gcc.dg/vect/vect-reduc-chain-dot-slp-3.c
- gcc.dg/vect/vect-reduc-chain-dot-slp-4.c

gcc/ChangeLog:

* config/loongarch/simd.md (wvec_half): New define_mode_attr.
(dot_prod): New define_expand.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/wide-mul-reduc-2.c (dg-final): Scan
DOT_PROD_EXPR in optimized tree.
---
  gcc/config/loongarch/simd.md  | 29 +++
  .../gcc.target/loongarch/wide-mul-reduc-2.c   |  3 +-
  2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/gcc/config/loongarch/simd.md b/gcc/config/loongarch/simd.md
index 661f5dc8dda..45d2bcaec2e 100644
--- a/gcc/config/loongarch/simd.md
+++ b/gcc/config/loongarch/simd.md

/* snip */
  
+(define_expand "dot_prod"

+  [(match_operand: 0 "register_operand" "=f,f")
+   (match_operand:IVEC   1 "register_operand" " f,f")
+   (match_operand:IVEC   2 "register_operand" " f,f")
+   (match_operand: 3 "reg_or_0_operand" " 0,YG")


Hi,

I have a question, why should operands[3] be the same operand as 
operands[0]?




+   (any_extend (const_int 0))]
+  ""

[COMMITTED] Documentation: Improve -Wstringop-overflow documentation [PR 113515]

[Sandra Loosemore]

This option can warn about things other than string and memory functions.
Say so explicitly, and give an example.  I also did some copy-editing
of the text and added some paragraph breaks.

gcc/ChangeLog
PR c/113515
* doc/invoke.texi (Warning Options): Improve -Wstringop-overflow
documentation.
---
 gcc/doc/invoke.texi | 35 +--
 1 file changed, 29 insertions(+), 6 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 304de88db07..fd1ce063a37 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -8229,20 +8229,28 @@ void f (char *d)
 @item -Wno-stringop-overflow
 @item -Wstringop-overflow
 @itemx -Wstringop-overflow=@var{type}
-Warn for calls to string manipulation functions such as @code{memcpy} and
-@code{strcpy} that are determined to overflow the destination buffer.  The
+Warn for code that can be statically determined to cause buffer overflows or
+memory overruns, such as calls to @code{memcpy} and
+@code{strcpy} that overflow the destination buffer.  The
 optional argument is one greater than the type of Object Size Checking to
 perform to determine the size of the destination.  @xref{Object Size Checking}.
-The argument is meaningful only for functions that operate on character arrays
-but not for raw memory functions like @code{memcpy} which always make use
-of Object Size type-0.  The option also warns for calls that specify a size
+The argument is meaningful only for string functions
+that operate on character arrays; raw memory functions like @code{memcpy}
+always use type-zero Object Size Checking.
+
+The option also warns for calls that specify a size
 in excess of the largest possible object or at most @code{SIZE_MAX / 2} bytes.
+
 The option produces the best results with optimization enabled but can detect
 a small subset of simple buffer overflows even without optimization in
 calls to the GCC built-in functions like @code{__builtin_memcpy} that
 correspond to the standard functions.  In any case, the option warns about
 just a subset of buffer overflows detected by the corresponding overflow
-checking built-ins.  For example, the option issues a warning for
+checking built-ins, such as @code{__builtin___memcpy_chk}, which can perform
+run-time checking if the access cannot be identified as safe
+at compile time.
+
+For example, the option issues a warning for
 the @code{strcpy} call below because it copies at least 5 characters
 (the string @code{"blue"} including the terminating NUL) into the buffer
 of size 4.
@@ -8264,6 +8272,21 @@ const char* f (enum Color clr)
 @}
 @end smallexample
 
+The effect of this option is not limited to string or memory
+manipulation functions.  In this example, a warning is diagnosed
+because a 1-element array is passed to a function requiring at least a
+4-element array argument:
+
+@smallexample
+void f (int[static 4]);
+
+void g (void)
+@{
+  int *p = (int *) malloc (1 * sizeof(int));
+  f (p);   // warning here
+@}
+@end smallexample
+
 Option @option{-Wstringop-overflow=2} is enabled by default.
 
 @table @gcctabopt
-- 
2.34.1

Re: [Fortran, Patch, PR107143, v1] Fix gimplification error in forall' pointer remapping

[Andre Vehreschild]

Hi Harald,

I try to explain why I think my patch although solving the issue for this case,
does not do so in every case:

My patch lets dependency analysis figure that the two objects can not have any
dependencies on each other or memory they are pointing to when the types are
different. Lets assume a simple list with a head node:

type node
  type(node), pointer :: prev, next
end type

type head
  type(node), pointer :: first, last
end type

(Just as an example; this might not be correct Fortran). Setting up a node

  type(head) :: h
  type(node), allocatable, target :: n

  allocate(n)
  n%prev = n%next = NULL()
  h%first => n
  h%last => n

The patched dependency analysis will deem `h%first => n` operands to be
independent of each other based on both having different types. Note,
dependency analysis looks at the object's type first, i.e. `head` vs. `node`
where I patched it!

While the patch may be correct for the example, it may not be for every case.
Just look one ref further: `h%first`'s type is `node` this would be deemed
having (potentially) a dependency on the type of the target `n`, because both
are of type `node`. Just having the same type is enough here!

So much just for the consequences of my change. Now let me try to explain, why
I think the patch is insufficient:

Assume a type (again pseudo-Fortran):

type T
  type(T), pointer :: n(:,:)
end type

Now doing something like

type(T) :: v1, v2

v1%n(n:m, m:n) => v2%n(m:n, n:m)

The types on lhs and rhs need to be the same. Then even the patched dependency
analysis concludes that in a `forall` a temporary is needed, because the
pointer assignment may overlap (trans-stmt.cc:5411):

need_temp = gfc_check_dependency (c->expr1, c->expr2, 0);

The indexes don't really matter here. They just need to be complicated, i.e.not
just a AR_FULL or AR_ELEMENT. Now `gfc_trans_pointer_assign_need_temp()` is
chosen. That routine in line trans-stmt.cc:5072 converts the lhs into a
descriptor. But because of the non-full/complicated array addressing (note, the
non-contiguous indexes !) `gfc_conv_expr_descriptor()` creates a `parm.12` (in
my case) temporary descriptor. That temporary descriptor, hence the name, is
usually used as actual argument to call a function. But the next line in
`gfc_trans_pointer_assign_need_temp` just assigns the rhs` temporary to that
`parm.12` (I have omitted only some casts, but in the code generated there are
*no* member-references):

parm.12 = lhs-temp

This leads to the gimplification error, because the types of the rhs
temporary and the temporary `parm.12` are not compatible. Furthermore is
the assignment as it is done there non-sense in my eyes, because it is literally
`parm.12 = rhs-temp`. I.e. in the code generated just before that, `parm.12` is
constructed an initialized laboriously and then shall be overwritten completely.
I assume that we would rather need something like (pseudo-pseudo code):

for (n = 1: #elem(rhs-temp))
  parm.12.data[i] = rhs-temp.data[i]
end for

But I have no clue how to easily accomplish that. I tried putting the rhs-temp
into the se of the `gfc_conv_expr_descriptor()` and setting `se.direct_byref =
1`, but that does it the wrong way around, i.e. rhs = lhs (Side note: having a
routine doing an assignment, that is otherwise just delivering a descriptor, is
some odd design decision). So I am at a loss here.

I hope to not have confused everyone. The possibility that I am mislead or
overlooking something or even thinking to complicated here is very likely.
So please correct me!

Therefore let's discuss this a bit more. I hold the patch back until we come to
a conclusion, that it is worth merging w/o breaking too much (which could be
possible, because that dependency analysis is used in many locations).

Regards,
Andre


On Wed, 5 Mar 2025 20:53:37 +0100
Harald Anlauf  wrote:

> Hi Andre,
>
> Jerry already OK'ed your patch, but:
>
> Am 05.03.25 um 15:34 schrieb Andre Vehreschild:
> > This fixes the PR, but not really the problem, because when say a
> > obj(i)%arr(2:5) => obj(i)%arr(1:4) is done we run into the same issue. I
> > don't have a solution for that error. It might  be needed to prevent
> > generating the parm.NN variable for the lhs, because that is mostly useless
> > there. (Or I don't understand (yet) how to use it).
>
> can you explain where you do see an issue here?
>
> A pointer assignment in the way you describe seems perfectly legal
> Fortran and works here.
>
> If we are missing anything, would you please open a PR with more
> details?
>
> Thanks,
> Harald
>


--
Andre Vehreschild * Email: vehre ad gmx dot de

[PATCH] Locality cloning pass (was: Introduce -flto-partition=locality)

[Kyrylo Tkachov]

Hi all,

Implement partitioning and cloning in the callgraph to help locality.
A new -fipa-reorder-for-locality flag is used to enable this.
The majority of the logic is in the new IPA pass in ipa-locality-cloning.cc
The optimization has two components:
* Partitioning the callgraph so as to group callers and callees that frequently
call each other in the same partition
* Cloning functions that straddle multiple callchains and allowing each clone
to be local to the partition of its callchain.

The majority of the logic is in the new IPA pass in ipa-locality-cloning.cc.
It creates a partitioning plan and does the prerequisite cloning.
The partitioning is then implemented during the existing LTO partitioning pass.

To guide these locality heuristics we use PGO data.
In the absence of PGO data we use a static heuristic that uses the accumulated
estimated edge frequencies of the callees for each function to guide the
reordering.
We are investigating some more elaborate static heuristics, in particular using
the demangled C++ names to group template instantiatios together.
This is promising but we are working out some kinks in the implementation
currently and want to send that out as a follow-up once we're more confident
in it.

A new bootstrap-lto-locality bootstrap config is added that allows us to test
this on GCC itself with either static or PGO heuristics.
GCC bootstraps with both (normal LTO bootstrap and profiledbootstrap).

As this new pass enables a new partitioning scheme it is incompatible with
explicit -flto-partition= options so an error is introduced when the user
uses both flags explicitly.

With this optimization we are seeing good performance gains on some large
internal workloads that stress the parts of the processor that is sensitive
to code locality, but we'd appreciate wider performance evaluation.

Bootstrapped and tested on aarch64-none-linux-gnu.
Ok for mainline?
Thanks,
Kyrill

Signed-off-by: Prachi Godbole 
Co-authored-by: Kyrylo Tkachov 

config/ChangeLog:

* bootstrap-lto-locality.mk: New file.

gcc/ChangeLog:

* Makefile.in (OBJS): Add ipa-locality-cloning.o.
* cgraph.h (set_new_clone_decl_and_node_flags): Declare prototype.
* cgraphclones.cc (set_new_clone_decl_and_node_flags): Remove static
qualifier.
* common.opt (fipa-reorder-for-locality): New flag.
(LTO_PARTITION_DEFAULT): Declare.
(flto-partition): Change default to LTO_PARTITION_DFEAULT.
* doc/invoke.texi: Document -fipa-reorder-for-locality.
* flag-types.h (enum lto_locality_cloning_model): Declare.
(lto_partitioning_model): Add LTO_PARTITION_DEFAULT.
* lto-cgraph.cc (lto_set_symtab_encoder_in_partition): Add dumping of
node and index.
* opts.cc (validate_ipa_reorder_locality_lto_partition): Define.
(finish_options): Handle LTO_PARTITION_DEFAULT.
* params.opt (lto_locality_cloning_model): New enum.
(lto-partition-locality-cloning): New param.
(lto-partition-locality-frequency-cutoff): Likewise.
(lto-partition-locality-size-cutoff): Likewise.
(lto-max-locality-partition): Likewise.
* passes.def: Register pass_ipa_locality_cloning.
* timevar.def (TV_IPA_LC): New timevar.
* tree-pass.h (make_pass_ipa_locality_cloning): Declare.
* ipa-locality-cloning.cc: New file.
* ipa-locality-cloning.h: New file.

gcc/lto/ChangeLog:

* lto-partition.cc (add_node_references_to_partition): Define.
(create_partition): Likewise.
(lto_locality_map): Likewise.
(lto_promote_cross_file_statics): Add extra dumping.
* lto-partition.h (lto_locality_map): Declare prototype.
* lto.cc (do_whole_program_analysis): Handle
flag_ipa_reorder_for_locality.



0001-Locality-cloning-pass-was-Introduce-flto-partition-l.patch
Description: 0001-Locality-cloning-pass-was-Introduce-flto-partition-l.patch

Re: [PATCH v2] c++: Don't replace INDIRECT_REFs by a const capture proxy too eagerly [PR117504]

[Simon Martin]

On Wed Mar 5, 2025 at 10:32 PM CET, Jason Merrill wrote:
> On 3/5/25 6:58 AM, Simon Martin wrote:
>> Hi Jason,
>> 
>> On Tue Mar 4, 2025 at 11:47 PM CET, Jason Merrill wrote:
>>> On 2/14/25 12:08 PM, Simon Martin wrote:
 We have been miscompiling the following valid code since GCC8, and
 r8-3497-g281e6c1d8f1b4c

 === cut here ===
 struct span {
 span (const int (&__first)[1]) : _M_ptr (__first) {}
 int operator[] (long __i) { return _M_ptr[__i]; }
 const int *_M_ptr;
 };
 void foo () {
 constexpr int a_vec[]{1};
 auto vec{[&a_vec]() -> span { return a_vec; }()};
 }
 === cut here ===

 The problem is that perform_implicit_conversion_flags (via
 mark_rvalue_use) replaces "a_vec" in the return statement by a
 CONSTRUCTOR representing a_vec's constant value, and then takes its
 address when invoking span's constructor. So we end up with an instance
 that points to garbage instead of a_vec's storage.

 I've tried many things to somehow recover from this replacement, but I
 actually think we should not do it when converting to a class type: we
 have no idea whether the conversion will involve a constructor taking an
 address or reference. So we should assume it's the case, and call
 mark_lvalue_use, not mark_rvalue_use (I might very weel be overseeing
 things, and feedback is more than welcome).
>>>
>>> Yeah, those mark_*_use calls seem misplaced, they should be called
>>> instead by the code that actually does the conversion.
>>>
>>> What if we replace all of them here with just mark_exp_read?  Or nothing?
>> Thanks for the suggestions; simply removing those calls actually works. This
>> is what the attached updated patch does.
>> 
>> Successfully tested on x86_64-pc-linux-gnu. OK for trunk? And if so, OK for
>> branches after 2-3 weeks since it's a wrong code bug?
>
> OK, yes.
Thanks, merged as r15-7849-gfdf846fdddcc04.

I'll reply to this thread when I've backported this patch to active branches,
in 2-3 weeks.

Simon

Re: [PATCH] lto: Fix missing cleanup with incremental LTO.

[Michal Jireš]

On 3/6/25 9:49 AM, Richard Biener wrote:

On Thu, 6 Mar 2025, Michal Jires wrote:


Incremental LTO disabled cleanup of output_files since they have to
persist in ltrans cache.
This unintetionally also kept temporary early debug "*.debug.temp.o"
files.

Bootstrapped/regtested on x86_64-linux.
Ok for trunk?


So are the early debug files then re-generated for each new
incremental LTO link?  That's possibly an area for improvement then
(well, how we handle early debug needs some improvements).


Yes. The early debug sections are copied into these temporary files in 
each LTO link.


Thanks,
Michal

(Sent again, now including the mailing list..)


OK.

Thanks,
Richard.

Re: [PATCH] Introduce -flto-partition=locality

[Kyrylo Tkachov]

Hi Honza,

Thanks a lot for the review!
Answers inline.
I’ve resent an updated version of the patch incorporating the feedback:
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/676958.html

Thanks,
Kyrill

> On 5 Jan 2025, at 18:06, Jan Hubicka  wrote:
> 
>> Hi all,
>> 
>> This is a patch submission following-up from the RFC at:
>> https://gcc.gnu.org/pipermail/gcc/2024-November/245076.html
>> The patch is rebased and retested against current trunk, some debugging code
>> removed, comments improved and some fixes added as I've we've done more
>> testing.
>> 
>> >8-
>> Implement partitioning and cloning in the callgraph to help locality.
>> A new -flto-partition=locality flag is used to enable this.
>> The majority of the logic is in the new IPA pass in ipa-locality-cloning.cc
>> The optimization has two components:
>> * Partitioning the callgraph so as to group callers and callees that 
>> frequently
>> call each other in the same partition
>> * Cloning functions that straddle multiple callchains and allowing each clone
>> to be local to the partition of its callchain.
>> 
>> The majority of the logic is in the new IPA pass in ipa-locality-cloning.cc.
>> It creates a partitioning plan and does the prerequisite cloning.
>> The partitioning is then implemented during the existing LTO partitioning 
>> pass.
>> 
>> To guide these locality heuristics we use PGO data.
>> In the absence of PGO data we use a static heuristic that uses the 
>> accumulated
>> estimated edge frequencies of the callees for each function to guide the
>> reordering.
>> We are investigating some more elaborate static heuristics, in particular 
>> using
>> the demangled C++ names to group template instantiatios together.
>> This is promising but we are working out some kinks in the implementation
>> currently and want to send that out as a follow-up once we're more confident
>> in it.
>> 
>> A new bootstrap-lto-locality bootstrap config is added that allows us to test
>> this on GCC itself with either static or PGO heuristics.
>> GCC bootstraps with both (normal LTO bootstrap and profiledbootstrap).
>> 
>> With this optimization we are seeing good performance gains on some large
>> internal workloads that stress the parts of the processor that is sensitive
>> to code locality, but we'd appreciate wider performance evaluation.
>> 
>> Bootstrapped and tested on aarch64-none-linux-gnu.
>> Ok for mainline?
>> Thanks,
>> Kyrill
>> 
>> Signed-off-by: Prachi Godbole 
>> Co-authored-by: Kyrylo Tkachov 
>> 
>>config/ChangeLog:
>> * bootstrap-lto-locality.mk: New file.
>> 
>> gcc/ChangeLog:
>>* Makefile.in (OBJS): Add ipa-locality-cloning.o
>>(GTFILES): Add ipa-locality-cloning.cc dependency.
>>* common.opt (lto_partition_model): Add locality value.
>>* flag-types.h (lto_partition_model): Add LTO_PARTITION_LOCALITY 
>> value.
>>(enum lto_locality_cloning_model): Define.
>>* lto-cgraph.cc (lto_set_symtab_encoder_in_partition): Add 
>> dumping of node
>>and index.
>>* params.opt (lto_locality_cloning_model): New enum.
>>(lto-partition-locality-cloning): New param.
>>(lto-partition-locality-frequency-cutoff): Likewise.
>>(lto-partition-locality-size-cutoff): Likewise.
>>(lto-max-locality-partition): Likewise.
>>* passes.def: Add pass_ipa_locality_cloning.
>>* timevar.def (TV_IPA_LC): New timevar.
>>* tree-pass.h (make_pass_ipa_locality_cloning): Declare.
>>* ipa-locality-cloning.cc: New file.
>>* ipa-locality-cloning.h: New file.
>> 
>>  gcc/lto/ChangeLog:
>> * lto-partition.cc: Include ipa-locality-cloning.h
>>(add_node_references_to_partition): Define.
>>(create_partition): Likewise.
>>(lto_locality_map): Likewise.
>>(lto_promote_cross_file_statics): Add extra dumping.
>>* lto-partition.h (lto_locality_map): Declare.
>>* lto.cc (do_whole_program_analysis): Handle 
>> LTO_PARTITION_LOCALITY.
>> 
>> 
>> diff --git a/config/bootstrap-lto-locality.mk 
>> b/config/bootstrap-lto-locality.mk
>> new file mode 100644
>> index 000..7792bbe6823
>> --- /dev/null
>> +++ b/config/bootstrap-lto-locality.mk
>> @@ -0,0 +1,20 @@
>> +# This option enables LTO and locality partitioning for stage2 and stage3 
>> in slim mode
>> +
>> +STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -flto-partition=locality
>> +STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 -flto-partition=locality
>> +STAGEprofile_CFLAGS += -flto=jobserver -frandom-seed=1 
>> -flto-partition=locality
>> +STAGEtrain_CFLAGS += -flto=jobserver -frandom-seed=1 
>> -flto-partition=locality
>> +STAGEfeedback_CFLAGS += -flto=jobserver -frandom-seed=1 
>> -flto-partition=locality
>> +
>> +# assumes the host suppo

Re: [PATCH] arm: testsuite: improve guard checks for arm_neon.h

[Christophe Lyon]

On Wed, 5 Mar 2025 at 12:59, Richard Earnshaw  wrote:
>
> The header file arm_neon.h provides the Advanced SIMD intrinsics that
> are available on armv7 or later A & R profile cores.  However, they
> are not compatible with M-profile and we also need to ensure that the
> FP instructions are enabled (with -mfloat-abi=softfp/hard).  That
> leads to some complicated checking as arm_neon.h includes stdint.h
> and, at least on linux, that can require that the appropriate ABI
> bits/ headers are also installed.
>
> This patch adds a new check to target-supports.exp to establish the
> minimal set of option overrides needed to enable use of this header in
> a test.
>
> gcc/testsuite:
> * lib/target-supports.exp
> (check_effective_target_arm_neon_h_ok_nocache): New function.
> (check_effective_target_arm_neon_h_ok): Likewise.
> (add_options_for_arm_neon_h): Likewise.
> (check_effective_target_arm_libc_fp_abi_ok_nocache): Allow any
> Arm target, not just arm32.
> * gcc.target/arm/attr-neon-builtin-fail.c: Use it.
> * gcc.target/arm/attr-neon-builtin-fail2.c: Likewise.
> * gcc.target/arm/attr-neon-fp16.c: Likewise.
> * gcc.target/arm/attr-neon2.c: Likewise.
> ---
>
> I'm going to wait 24 hrs before committing this as I'd like to see the
> results of the CI first.
>

I've manually started precommit tests which are not executed by
default (targeting arm-none-eabi with runtest flags overridden), and
results look good:

* NO CHANGE (except for line number change in attr-neon-builtin-fail.c):
v7a_softfp_eabi -marm/-march=armv7-a/-mfpu=vfpv3-d16/-mfloat-abi=softfp
thumb_m33_hard 
-mthumb/-march=armv8-m.main+dsp+fp/-mtune=cortex-m33/-mfloat-abi=hard/-mfpu=auto

* UNSUPPORTED -> PASS:
gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon-builtin-fail.c
gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon-fp16.c
gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon2.c
default flags ""
thumb_m3_softfp
-mthumb/-march=armv7-m/-mtune=cortex-m3/-mfloat-abi=softfp/-mfpu=auto
thumb_m7_hard 
-mthumb/-march=armv7e-m+fp.dp/-mtune=cortex-m7/-mfloat-abi=hard/-mfpu=auto
thumb_v8a_hard -mthumb/-march=armv8-a+simd/-mfpu=auto/-mfloat-abi=hard

* UNSUPPORTED -> PASS:
gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon-builtin-fail.c
gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon-builtin-fail2.c
gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon-fp16.c
gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon2.c
gcc:gcc.target/arm/arm.exp=gcc.target/arm/pr68620.c
thumb_m0_soft 
-mthumb/-march=armv6s-m/-mtune=cortex-m0/-mfloat-abi=soft/-mfpu=auto
thumb_m23_soft 
-mthumb/-march=armv8-m.base/-mtune=cortex-m23/-mfloat-abi=soft/-mfpu=auto

* FAIL / UNRESOLVED -> PASS:
gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon-builtin-fail.c
(test for excess errors)
gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon-builtin-fail.c
 (test for warnings, line 14)
gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon-builtin-fail.c
 at line 17 (test for errors, line )
gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon-builtin-fail2.c
 (test for errors, line 13)
gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon-builtin-fail2.c
(test for excess errors)
gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon-fp16.c (test
for excess errors)
gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon2.c (test for
excess errors)
gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon2.c
check-function-bodies my
gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon2.c
check-function-bodies my1
gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon2.c
scan-assembler .fpu\\s+neon\n
gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon2.c
scan-assembler .fpu\\s+vfp\n
thumb_m55_hard 
-mthumb/-march=armv8.1-m.main+mve.fp+fp.dp/-mtune=cortex-m55/-mfloat-abi=hard/-mfpu=auto

so we actually get more coverage, which is nice, thanks!

> R.
>
>  .../gcc.target/arm/attr-neon-builtin-fail.c   |  6 +--
>  .../gcc.target/arm/attr-neon-builtin-fail2.c  |  5 +-
>  gcc/testsuite/gcc.target/arm/attr-neon-fp16.c |  4 +-
>  gcc/testsuite/gcc.target/arm/attr-neon2.c |  5 +-
>  gcc/testsuite/lib/target-supports.exp | 53 ++-
>  5 files changed, 60 insertions(+), 13 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail.c 
> b/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail.c
> index fb6e0b9cd66..645d708f005 100644
> --- a/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail.c
> +++ b/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail.c
> @@ -1,9 +1,8 @@
>  /* Check that calling a neon builtin from a function compiled with vfp 
> fails.  */
>  /* { dg-do compile } */
> -/* { dg-require-effective-target arm_fp_ok } */
> -/* { dg-require-effective-target arm_neon_ok } */
> +/* { dg-require-effective-target arm_neon_h_ok } */
>  /* { dg-options "-O2" } */
> -/* { dg-add-options arm_fp } */
> +/* { dg-add-opti

Re: [PATCH] arm: testsuite: improve guard checks for arm_neon.h

[Christophe Lyon]

On Thu, 6 Mar 2025 at 11:03, Christophe Lyon  wrote:
>
> On Wed, 5 Mar 2025 at 12:59, Richard Earnshaw  wrote:
> >
> > The header file arm_neon.h provides the Advanced SIMD intrinsics that
> > are available on armv7 or later A & R profile cores.  However, they
> > are not compatible with M-profile and we also need to ensure that the
> > FP instructions are enabled (with -mfloat-abi=softfp/hard).  That
> > leads to some complicated checking as arm_neon.h includes stdint.h
> > and, at least on linux, that can require that the appropriate ABI
> > bits/ headers are also installed.
> >
> > This patch adds a new check to target-supports.exp to establish the
> > minimal set of option overrides needed to enable use of this header in
> > a test.
> >
> > gcc/testsuite:
> > * lib/target-supports.exp
> > (check_effective_target_arm_neon_h_ok_nocache): New function.
> > (check_effective_target_arm_neon_h_ok): Likewise.
> > (add_options_for_arm_neon_h): Likewise.

Sorry forgot to ask: do these new functions need an entry in sourcebuild.texi?

> > (check_effective_target_arm_libc_fp_abi_ok_nocache): Allow any
> > Arm target, not just arm32.
> > * gcc.target/arm/attr-neon-builtin-fail.c: Use it.
> > * gcc.target/arm/attr-neon-builtin-fail2.c: Likewise.
> > * gcc.target/arm/attr-neon-fp16.c: Likewise.
> > * gcc.target/arm/attr-neon2.c: Likewise.
> > ---
> >
> > I'm going to wait 24 hrs before committing this as I'd like to see the
> > results of the CI first.
> >
>
> I've manually started precommit tests which are not executed by
> default (targeting arm-none-eabi with runtest flags overridden), and
> results look good:
>
> * NO CHANGE (except for line number change in attr-neon-builtin-fail.c):
> v7a_softfp_eabi -marm/-march=armv7-a/-mfpu=vfpv3-d16/-mfloat-abi=softfp
> thumb_m33_hard 
> -mthumb/-march=armv8-m.main+dsp+fp/-mtune=cortex-m33/-mfloat-abi=hard/-mfpu=auto
>
> * UNSUPPORTED -> PASS:
> gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon-builtin-fail.c
> gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon-fp16.c
> gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon2.c
> default flags ""
> thumb_m3_softfp
> -mthumb/-march=armv7-m/-mtune=cortex-m3/-mfloat-abi=softfp/-mfpu=auto
> thumb_m7_hard 
> -mthumb/-march=armv7e-m+fp.dp/-mtune=cortex-m7/-mfloat-abi=hard/-mfpu=auto
> thumb_v8a_hard -mthumb/-march=armv8-a+simd/-mfpu=auto/-mfloat-abi=hard
>
> * UNSUPPORTED -> PASS:
> gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon-builtin-fail.c
> gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon-builtin-fail2.c
> gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon-fp16.c
> gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon2.c
> gcc:gcc.target/arm/arm.exp=gcc.target/arm/pr68620.c
> thumb_m0_soft 
> -mthumb/-march=armv6s-m/-mtune=cortex-m0/-mfloat-abi=soft/-mfpu=auto
> thumb_m23_soft 
> -mthumb/-march=armv8-m.base/-mtune=cortex-m23/-mfloat-abi=soft/-mfpu=auto
>
> * FAIL / UNRESOLVED -> PASS:
> gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon-builtin-fail.c
> (test for excess errors)
> gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon-builtin-fail.c
>  (test for warnings, line 14)
> gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon-builtin-fail.c
>  at line 17 (test for errors, line )
> gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon-builtin-fail2.c
>  (test for errors, line 13)
> gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon-builtin-fail2.c
> (test for excess errors)
> gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon-fp16.c (test
> for excess errors)
> gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon2.c (test for
> excess errors)
> gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon2.c
> check-function-bodies my
> gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon2.c
> check-function-bodies my1
> gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon2.c
> scan-assembler .fpu\\s+neon\n
> gcc:gcc.target/arm/arm.exp=gcc.target/arm/attr-neon2.c
> scan-assembler .fpu\\s+vfp\n
> thumb_m55_hard 
> -mthumb/-march=armv8.1-m.main+mve.fp+fp.dp/-mtune=cortex-m55/-mfloat-abi=hard/-mfpu=auto
>
> so we actually get more coverage, which is nice, thanks!
>
> > R.
> >
> >  .../gcc.target/arm/attr-neon-builtin-fail.c   |  6 +--
> >  .../gcc.target/arm/attr-neon-builtin-fail2.c  |  5 +-
> >  gcc/testsuite/gcc.target/arm/attr-neon-fp16.c |  4 +-
> >  gcc/testsuite/gcc.target/arm/attr-neon2.c |  5 +-
> >  gcc/testsuite/lib/target-supports.exp | 53 ++-
> >  5 files changed, 60 insertions(+), 13 deletions(-)
> >
> > diff --git a/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail.c 
> > b/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail.c
> > index fb6e0b9cd66..645d708f005 100644
> > --- a/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail.c
> > +++ b/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail.c
> > @@ -1,9 +1,8 @@
> >  /* Check that 

[PATCH] libstdc++: Ensure defines __pair_like

[Jonathan Wakely]

We need to include  in C++23 and later, so that
__pair_like_convertible_from can use __pair_like.

libstdc++-v3/ChangeLog:

* include/bits/ranges_util.h: Include .
---

Very lightly tested on x86_64-linux.

I noticed this because I wanted to use ranges::subrange in a new header
which didn't include .

 libstdc++-v3/include/bits/ranges_util.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libstdc++-v3/include/bits/ranges_util.h 
b/libstdc++-v3/include/bits/ranges_util.h
index 51024ecbebe..d9039e75bf9 100644
--- a/libstdc++-v3/include/bits/ranges_util.h
+++ b/libstdc++-v3/include/bits/ranges_util.h
@@ -35,6 +35,9 @@
 # include 
 # include 
 # include  // __can_use_memchr_for_find
+#if __glibcxx_tuple_like // >= C++23
+# include  // __pair_like
+#endif
 
 #ifdef __glibcxx_ranges
 namespace std _GLIBCXX_VISIBILITY(default)
-- 
2.48.1

Re: [1/3 PATCH]AArch64: add support for partial modes to last extractions [PR118464]

[Richard Sandiford]

Tamar Christina  writes:
>> -Original Message-
>> From: Richard Sandiford 
>> Sent: Wednesday, March 5, 2025 11:27 AM
>> To: Tamar Christina 
>> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
>> ; ktkac...@gcc.gnu.org
>> Subject: Re: [1/3 PATCH]AArch64: add support for partial modes to last
>> extractions [PR118464]
>> 
>> Tamar Christina  writes:
>> >> > diff --git a/gcc/config/aarch64/aarch64-sve.md
>> b/gcc/config/aarch64/aarch64-
>> >> sve.md
>> >> > index
>> >>
>> e975286a01904bec0b283b7ba4afde6f0fd60bf1..6c0be3c1a51449274720175b
>> >> 5e6e7d7535928de6 100644
>> >> > --- a/gcc/config/aarch64/aarch64-sve.md
>> >> > +++ b/gcc/config/aarch64/aarch64-sve.md
>> >> > @@ -3107,7 +3107,7 @@ (define_insn "@extract__"
>> >> >[(set (match_operand: 0 "register_operand")
>> >> > (unspec:
>> >> >   [(match_operand: 1 "register_operand")
>> >> > -  (match_operand:SVE_FULL 2 "register_operand")]
>> >> > +  (match_operand:SVE_ALL 2 "register_operand")]
>> >> >   LAST))]
>> >> >"TARGET_SVE"
>> >> >{@ [ cons: =0 , 1   , 2  ]
>> >>
>> >> It looks like this will use (say):
>> >>
>> >>   lasta b, pg, z.b
>> >>
>> >> for VNx4QI, is that right?  I don't think that's safe, since the .b form
>> >> treats all bits of the pg input as significant, whereas only one in every
>> >> four bits of pg is defined for VNx4BI (the predicate associated with 
>> >> VNx4QI).
>> >>
>> >> I think converting these patterns to partial vectors means operating
>> >> on containers rather than elements.  E.g. the VNx4QI case should use
>> >> .s rather than .b.  That should just be a case of changing vwcore to
>> >> vccore and Vetype to Vctype, but I haven't looked too deeply.
>> >
>> > Ah I see, so for partial types, the values are not expected to be packed 
>> > in the
>> lower
>> > part of the vector, but instead are "padded"?
>> 
>> Right.
>> 
>> > That explains some of the other patterns
>> > I was confused about.
>> >
>> > Any ideas how to test these? It's hard to control what modes the vectorizer
>> picks..
>> 
>> Yeah, agreed.  I think it'd be difficult to trigger it reliably from the
>> vectoriser given its current limited use of the ifns.
>> 
>> A gimple frontend test might work though, with a predicate/mask
>> generated from (say) 16-bit elements, then bitcast to a predicate/mask
>> for 32-bit elements and used as an input to an explicit ifn on 32-bit
>> elements.  If the 16-bit predicate contains 0, 1 for some even-aligned
>> pair, after the last 1, 0 aligned pair, then the code would likely have
>> picked the wrong element.
>
> *insert chaos emoji* I realized the testcases in the testsuite early break
> vect tests needed this since that's how I noticed it anyway.. so it's enough
> to run that with SVE enabled (as there are tests depending on partial vectors
> anyway)
>
> So...
>
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>
> Ok for master?
>
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
>
>   PR tree-optimization/118464
>   PR tree-optimization/116855
>   * config/aarch64/aarch64-sve.md (@extract__,
>   @fold_extract__,
>   @aarch64_fold_extract_vector__): Change SVE_FULL to
>   SVE_ALL/
>
> -- inline copy of patch --
>
> diff --git a/gcc/config/aarch64/aarch64-sve.md 
> b/gcc/config/aarch64/aarch64-sve.md
> index 
> a93bc463a909ea28460cc7877275fce16e05f7e6..205eeec2e35544de848e0dbb48e3f5ae59391a88
>  100644
> --- a/gcc/config/aarch64/aarch64-sve.md
> +++ b/gcc/config/aarch64/aarch64-sve.md
> @@ -3107,12 +3107,12 @@ (define_insn "@extract__"
>[(set (match_operand: 0 "register_operand")
>   (unspec:
> [(match_operand: 1 "register_operand")
> -(match_operand:SVE_FULL 2 "register_operand")]
> +(match_operand:SVE_ALL 2 "register_operand")]
> LAST))]
>"TARGET_SVE"
>{@ [ cons: =0 , 1   , 2  ]
> - [ ?r   , Upl , w  ] last\t%0, %1, %2.
> - [ w, Upl , w  ] last\t%0, %1, %2.
> + [ ?r   , Upl , w  ] last\t%0, %1, %2.

This looks good for the Vetype->Vctype part, but it still needs the
vwcore->vccore change too.  If we don't do that, we could end up pairing
a w destination with a .d source, which would trigger an assembler error.

Thanks,
Richard


> + [ w, Upl , w  ] last\t%0, %1, %2.
>}
>  )
>  
> @@ -8899,26 +8899,26 @@ (define_insn "@fold_extract__"
>   (unspec:
> [(match_operand: 1 "register_operand")
>  (match_operand: 2 "register_operand")
> -(match_operand:SVE_FULL 3 "register_operand")]
> +(match_operand:SVE_ALL 3 "register_operand")]
> CLAST))]
>"TARGET_SVE"
>{@ [ cons: =0 , 1 , 2   , 3  ]
> - [ ?r   , 0 , Upl , w  ] clast\t%0, %2, %0, 
> %3.
> - [ w, 0 , Upl , w  ] clast\t%0, %2, %0, 
> %3.
> + [ ?r   , 0 , Upl , w  ] clast\t%0, %2, %0, 
> %3.
> + [ w, 0 , Upl , w  ] clast\t%0, %2, %0, 
> %3.
>}
>  )
>  
>  (define_insn "@aarch64_fold_extract_vector__"

RE: [1/3 PATCH]AArch64: add support for partial modes to last extractions [PR118464]

[Tamar Christina]

> -Original Message-
> From: Richard Sandiford 
> Sent: Thursday, March 6, 2025 10:40 AM
> To: Tamar Christina 
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; ktkac...@gcc.gnu.org
> Subject: Re: [1/3 PATCH]AArch64: add support for partial modes to last
> extractions [PR118464]
> 
> Tamar Christina  writes:
> >> -Original Message-
> >> From: Richard Sandiford 
> >> Sent: Wednesday, March 5, 2025 11:27 AM
> >> To: Tamar Christina 
> >> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> >> ; ktkac...@gcc.gnu.org
> >> Subject: Re: [1/3 PATCH]AArch64: add support for partial modes to last
> >> extractions [PR118464]
> >>
> >> Tamar Christina  writes:
> >> >> > diff --git a/gcc/config/aarch64/aarch64-sve.md
> >> b/gcc/config/aarch64/aarch64-
> >> >> sve.md
> >> >> > index
> >> >>
> >>
> e975286a01904bec0b283b7ba4afde6f0fd60bf1..6c0be3c1a51449274720175b
> >> >> 5e6e7d7535928de6 100644
> >> >> > --- a/gcc/config/aarch64/aarch64-sve.md
> >> >> > +++ b/gcc/config/aarch64/aarch64-sve.md
> >> >> > @@ -3107,7 +3107,7 @@ (define_insn "@extract__"
> >> >> >[(set (match_operand: 0 "register_operand")
> >> >> >   (unspec:
> >> >> > [(match_operand: 1 "register_operand")
> >> >> > -(match_operand:SVE_FULL 2 "register_operand")]
> >> >> > +(match_operand:SVE_ALL 2 "register_operand")]
> >> >> > LAST))]
> >> >> >"TARGET_SVE"
> >> >> >{@ [ cons: =0 , 1   , 2  ]
> >> >>
> >> >> It looks like this will use (say):
> >> >>
> >> >>   lasta b, pg, z.b
> >> >>
> >> >> for VNx4QI, is that right?  I don't think that's safe, since the .b form
> >> >> treats all bits of the pg input as significant, whereas only one in 
> >> >> every
> >> >> four bits of pg is defined for VNx4BI (the predicate associated with 
> >> >> VNx4QI).
> >> >>
> >> >> I think converting these patterns to partial vectors means operating
> >> >> on containers rather than elements.  E.g. the VNx4QI case should use
> >> >> .s rather than .b.  That should just be a case of changing vwcore to
> >> >> vccore and Vetype to Vctype, but I haven't looked too deeply.
> >> >
> >> > Ah I see, so for partial types, the values are not expected to be packed 
> >> > in the
> >> lower
> >> > part of the vector, but instead are "padded"?
> >>
> >> Right.
> >>
> >> > That explains some of the other patterns
> >> > I was confused about.
> >> >
> >> > Any ideas how to test these? It's hard to control what modes the 
> >> > vectorizer
> >> picks..
> >>
> >> Yeah, agreed.  I think it'd be difficult to trigger it reliably from the
> >> vectoriser given its current limited use of the ifns.
> >>
> >> A gimple frontend test might work though, with a predicate/mask
> >> generated from (say) 16-bit elements, then bitcast to a predicate/mask
> >> for 32-bit elements and used as an input to an explicit ifn on 32-bit
> >> elements.  If the 16-bit predicate contains 0, 1 for some even-aligned
> >> pair, after the last 1, 0 aligned pair, then the code would likely have
> >> picked the wrong element.
> >
> > *insert chaos emoji* I realized the testcases in the testsuite early break
> > vect tests needed this since that's how I noticed it anyway.. so it's enough
> > to run that with SVE enabled (as there are tests depending on partial 
> > vectors
> > anyway)
> >
> > So...
> >
> > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> >
> > Ok for master?
> >
> > Thanks,
> > Tamar
> >
> > gcc/ChangeLog:
> >
> >
> > PR tree-optimization/118464
> > PR tree-optimization/116855
> > * config/aarch64/aarch64-sve.md (@extract__,
> > @fold_extract__,
> > @aarch64_fold_extract_vector__): Change SVE_FULL to
> > SVE_ALL/
> >
> > -- inline copy of patch --
> >
> > diff --git a/gcc/config/aarch64/aarch64-sve.md b/gcc/config/aarch64/aarch64-
> sve.md
> > index
> a93bc463a909ea28460cc7877275fce16e05f7e6..205eeec2e35544de848e0dbb
> 48e3f5ae59391a88 100644
> > --- a/gcc/config/aarch64/aarch64-sve.md
> > +++ b/gcc/config/aarch64/aarch64-sve.md
> > @@ -3107,12 +3107,12 @@ (define_insn "@extract__"
> >[(set (match_operand: 0 "register_operand")
> > (unspec:
> >   [(match_operand: 1 "register_operand")
> > -  (match_operand:SVE_FULL 2 "register_operand")]
> > +  (match_operand:SVE_ALL 2 "register_operand")]
> >   LAST))]
> >"TARGET_SVE"
> >{@ [ cons: =0 , 1   , 2  ]
> > - [ ?r   , Upl , w  ] last\t%0, %1, %2.
> > - [ w, Upl , w  ] last\t%0, %1, %2.
> > + [ ?r   , Upl , w  ] last\t%0, %1, %2.
> 
> This looks good for the Vetype->Vctype part, but it still needs the
> vwcore->vccore change too.  If we don't do that, we could end up pairing
> a w destination with a .d source, which would trigger an assembler error.
> 

The sad part is, I went and checked the instruction before posting this and 
missed
that that wasn't allowed.. arggg..

Tamar

> Thanks,
> Richard
> 
> 
> > + [ w, Upl , w  ] last\t%0, %1, %2.
> >}
> >  )
> >
> > @@ -8899,26 +8

[PATCH] libstdc++: Add assertions to std::list::pop_{front,back}

[Jonathan Wakely]

The recently-approved Standard Library Hardening proposal (P3471R4)
gives pop_front and pop_back member functions hardened preconditions,
but std::list was missing assertions on them. Our other sequence
containers do have assertions on those members.

libstdc++-v3/ChangeLog:

* include/bits/stl_list.h (list::pop_front, list::pop_back):
Add non-empty assertions.
---

Tested x86_64-linux.

Since it's a conformance requirement that we diagnose Hardened
Preconditions, we should probably have tests that verify these
assertions exist, but ... I ... haven't done that.

 libstdc++-v3/include/bits/stl_list.h | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/include/bits/stl_list.h 
b/libstdc++-v3/include/bits/stl_list.h
index f987d8b9d0a..82ccb50ff18 100644
--- a/libstdc++-v3/include/bits/stl_list.h
+++ b/libstdc++-v3/include/bits/stl_list.h
@@ -1784,7 +1784,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
*/
   void
   pop_front() _GLIBCXX_NOEXCEPT
-  { this->_M_erase(begin()); }
+  {
+   __glibcxx_requires_nonempty();
+   this->_M_erase(begin());
+  }
 
   /**
*  @brief  Add data to the end of the %list.
@@ -1833,7 +1836,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
*/
   void
   pop_back() _GLIBCXX_NOEXCEPT
-  { this->_M_erase(iterator(this->_M_impl._M_node._M_prev)); }
+  {
+   __glibcxx_requires_nonempty();
+   this->_M_erase(iterator(this->_M_impl._M_node._M_prev));
+  }
 
 #if __cplusplus >= 201103L
   /**
-- 
2.48.1

[PATCH] lto/114501 - missed free-lang-data for CONSTRUCTOR index

[Richard Biener]

The following makes sure to also walk CONSTRUCTOR element indexes
which can be FIELD_DECLs, referencing otherwise unused types we
need to clean.  walk_tree only walks CONSTRUCTOR element data.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress, will
push when that succeeds.

Richard.

PR lto/114501
* ipa-free-lang-data.cc (find_decls_types_r): Explicitly
handle CONSTRUCTORs as walk_tree handling of those is
incomplete.

* g++.dg/pr114501_0.C: New testcase.
---
 gcc/ipa-free-lang-data.cc | 14 ++
 gcc/testsuite/g++.dg/pr114501_0.C | 20 
 2 files changed, 34 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/pr114501_0.C

diff --git a/gcc/ipa-free-lang-data.cc b/gcc/ipa-free-lang-data.cc
index a865332ddf1..8c4fb3c6b64 100644
--- a/gcc/ipa-free-lang-data.cc
+++ b/gcc/ipa-free-lang-data.cc
@@ -846,6 +846,20 @@ find_decls_types_r (tree *tp, int *ws, void *data)
fld_worklist_push (tem, fld);
   fld_worklist_push (BLOCK_ABSTRACT_ORIGIN (t), fld);
 }
+  /* walk_tree does not visit ce->index which can be a FIELD_DECL, pulling
+ in otherwise unused structure fields so handle CTORs explicitly.  */
+  else if (TREE_CODE (t) == CONSTRUCTOR)
+{
+  unsigned HOST_WIDE_INT idx;
+  constructor_elt *ce;
+  for (idx = 0; vec_safe_iterate (CONSTRUCTOR_ELTS (t), idx, &ce); idx++)
+   {
+ if (ce->index)
+   fld_worklist_push (ce->index, fld);
+ fld_worklist_push (ce->value, fld);
+   }
+  *ws = 0;
+}
 
   if (TREE_CODE (t) != IDENTIFIER_NODE
   && CODE_CONTAINS_STRUCT (TREE_CODE (t), TS_TYPED))
diff --git a/gcc/testsuite/g++.dg/pr114501_0.C 
b/gcc/testsuite/g++.dg/pr114501_0.C
new file mode 100644
index 000..0439ee5f6e2
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr114501_0.C
@@ -0,0 +1,20 @@
+// { dg-do compile }
+// { dg-require-effective-target c++17 }
+// { dg-require-effective-target lto }
+// { dg-options "-flto" }
+
+typedef long unsigned int size_t;
+struct basic_string_view {
+  typedef long unsigned int size_type;
+  constexpr size_type size() const { return 0; }
+};
+struct array {
+  char _M_elems[1];
+};
+inline constexpr auto make_it() {
+  constexpr basic_string_view view;
+  array arr{};
+  arr._M_elems[view.size()] = 'a';
+  return arr;
+}
+auto bar = make_it();
-- 
2.43.0

[PUSHED] libstdc++: Avoid '-Wunused-parameter' for '__what' in function 'void std::__throw_format_error(const char*)'

[Thomas Schwinge]

In a '-fno-exceptions' configuration:

In file included from 
../../../../../source-gcc/libstdc++-v3/src/c++20/format.cc:29:
[...]/build-gcc/[...]/libstdc++-v3/include/format: In function ‘void 
std::__throw_format_error(const char*)’:
[...]/build-gcc/[...]/libstdc++-v3/include/format:200:36: error: unused 
parameter ‘__what’ [-Werror=unused-parameter]
  200 |   __throw_format_error(const char* __what)
  |^~

libstdc++-v3/
* include/bits/c++config [!__cpp_exceptions]
(_GLIBCXX_THROW_OR_ABORT): Reference '_EXC'.

Co-authored-by: Jonathan Wakely 
---
 libstdc++-v3/include/bits/c++config | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/bits/c++config 
b/libstdc++-v3/include/bits/c++config
index 6a73507d074..676f5eecbbb 100644
--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -261,7 +261,7 @@
 # if __cpp_exceptions
 #  define _GLIBCXX_THROW_OR_ABORT(_EXC) (throw (_EXC))
 # else
-#  define _GLIBCXX_THROW_OR_ABORT(_EXC) (__builtin_abort())
+#  define _GLIBCXX_THROW_OR_ABORT(_EXC) (__builtin_abort(), (void)(_EXC))
 # endif
 #endif
 
-- 
2.34.1

Re: [PATCH] libstdc++: Fix constexpr memory algo tests for COW std::string

[Jonathan Wakely]

On Thu, 6 Mar 2025 at 11:36, Giuseppe D'Angelo
 wrote:
>
> Hi,
>
> On 06/03/2025 12:26, Jonathan Wakely wrote:
> > The old COW std::string is not usable in constant expressions, so these
> > new tests fail with -D_GLIBCXX_USE_CXX11_ABI=0.
>
> LGTM; is there a specific incantation to run the testsuite with both
> libstdc++ ABIs? Clearly I just tested the new one...

You can use:
make check RUNTESTFLAGS="--target_board=unix\{,-D_GLIBCXX_USE_CXX11_ABI=0\}"

I do it a little differently, using the ~/.dejagnurc file below which
runs every test for every -std option from 98 to 26, and with
assertions enabled, with the old ABI, and with -m32. This takes about
20 times longer than normal to run the tests, so choose wisely!

# Need to test if $tool exists prior to the r11-551 change.
if { [info exists tool] && "$tool" == "libstdc++" } {
global tool_timeout
set tool_timeout 90
puts "dejagnu - timeout default set to ${tool_timeout}s"
if { [info exists v3-use-std-list] } {
 # v3-dg-runtest supports running tests with multiple -std options.
 set v3_std_list { 98 11 14 17 20 23 26 }
 set target_list {
"unix{-D_GLIBCXX_ASSERTIONS,-D_GLIBCXX_USE_CXX11_ABI=0,-m32}" }
} else {
 # set target_list { "unix{,-m32/-D_GLIBCXX_USE_CXX11_ABI=0,-std=gnu++23}" }
 set target_list {
"unix{,-D_GLIBCXX_USE_CXX11_ABI=0,-std=gnu++2b,-std=gnu++11}" }
}
}

[PATCH] libstdc++: Fix constexpr memory algo tests for COW std::string

[Jonathan Wakely]

The old COW std::string is not usable in constant expressions, so these
new tests fail with -D_GLIBCXX_USE_CXX11_ABI=0.

The parts of the tests using std::string can be conditionally skipped.

libstdc++-v3/ChangeLog:

* 
testsuite/20_util/specialized_algorithms/uninitialized_copy/constexpr.cc:
Do not test COW std::string in constexpr contexts.
* 
testsuite/20_util/specialized_algorithms/uninitialized_default_construct/constexpr.cc:
Likewise.
* 
testsuite/20_util/specialized_algorithms/uninitialized_fill/constexpr.cc:
Likewise.
* 
testsuite/20_util/specialized_algorithms/uninitialized_move/constexpr.cc:
Likewise.
* 
testsuite/20_util/specialized_algorithms/uninitialized_value_construct/constexpr.cc:
Likewise.
---

Tested x86_64-linux.

 .../specialized_algorithms/uninitialized_copy/constexpr.cc  | 2 ++
 .../uninitialized_default_construct/constexpr.cc| 2 ++
 .../specialized_algorithms/uninitialized_fill/constexpr.cc  | 2 ++
 .../specialized_algorithms/uninitialized_move/constexpr.cc  | 2 ++
 .../uninitialized_value_construct/constexpr.cc  | 2 ++
 5 files changed, 10 insertions(+)

diff --git 
a/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/constexpr.cc
 
b/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/constexpr.cc
index 6f05b0ce309..faf69689ee7 100644
--- 
a/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/constexpr.cc
+++ 
b/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/constexpr.cc
@@ -51,7 +51,9 @@ test01()
 test01_impl({'a', 'b', 'c'}) &&
 test01_impl({1, 2, 3, 4}) &&
 test01_impl({1.0, 2.0, 3.0, 4.0}) &&
+#if _GLIBCXX_USE_CXX11_ABI
 test01_impl({"a", "b", "cc", "", ""}) &&
+#endif
 test01_impl>({ {0}, {0, 1}, {0, 1, 2}});
 }
 
diff --git 
a/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_default_construct/constexpr.cc
 
b/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_default_construct/constexpr.cc
index db39c8b4d05..151c1f95a30 100644
--- 
a/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_default_construct/constexpr.cc
+++ 
b/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_default_construct/constexpr.cc
@@ -59,7 +59,9 @@ test01()
 test01_impl() &&
 test01_impl() &&
 test01_impl() &&
+#if _GLIBCXX_USE_CXX11_ABI
 test01_impl() &&
+#endif
 test01_impl>() &&
 test01_impl>();
 }
diff --git 
a/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_fill/constexpr.cc
 
b/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_fill/constexpr.cc
index e43cd35a92d..27461fa452e 100644
--- 
a/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_fill/constexpr.cc
+++ 
b/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_fill/constexpr.cc
@@ -58,8 +58,10 @@ test01()
 test01_impl(0) &&
 test01_impl(42) &&
 test01_impl(3.14) &&
+#if _GLIBCXX_USE_CXX11_ABI
 test01_impl() &&
 test01_impl(std::string("test")) &&
+#endif
 test01_impl>() &&
 test01_impl>({1, 2, 3, 4}) &&
 test01_impl>(nullptr);
diff --git 
a/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_move/constexpr.cc
 
b/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_move/constexpr.cc
index 47403ae706d..f122a03991f 100644
--- 
a/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_move/constexpr.cc
+++ 
b/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_move/constexpr.cc
@@ -43,7 +43,9 @@ test01()
 test01_impl({'a', 'b', 'c'}) &&
 test01_impl({1, 2, 3, 4}) &&
 test01_impl({1.0, 2.0, 3.0, 4.0}) &&
+#if _GLIBCXX_USE_CXX11_ABI
 test01_impl({"a", "b", "cc", "", ""}) &&
+#endif
 test01_impl>({ {0}, {0, 1}, {0, 1, 2}}) &&
 test01_impl>(std::vector>(10));
 }
diff --git 
a/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_value_construct/constexpr.cc
 
b/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_value_construct/constexpr.cc
index 55dfc59b5ef..f943973b015 100644
--- 
a/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_value_construct/constexpr.cc
+++ 
b/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_value_construct/constexpr.cc
@@ -56,7 +56,9 @@ test01()
 test01_impl() &&
 test01_impl() &&
 test01_impl() &&
+#if _GLIBCXX_USE_CXX11_ABI
 test01_impl() &&
+#endif
 test01_impl>() &&
 test01_impl>();
 }
-- 
2.48.1

[PATCH] target: Adjust gcc.target/powerpc/pr103515.c test [PR117207]

[Jakub Jelinek]

Hi!

Starting with r15-4225 the loop in foo1 is vectorized even at -O2 and that
implies later some small unrolling, regardless of -funroll-loops flag being
added in
#pragma GCC optimize("O3,unroll-loops")
only for foo2.
My understanding of the intent of the test was that before r12-5920 test the
backend caused -funroll-loops to be set even for foo1 despite the pragma
only appeared after it and the test just wanted to make sure unrolling is
done just in the function with -funroll-loops.
Now, seems the unrolling was happening with -O2 -fno-tree-vectorize as well,
the test would have FAILed with the following patch before r12-5920 and
PASSes since r12-5920 the same as with -O2, except that it still PASSes even
starting with r15-4225.

Tested with x86_64-linux -> powerpc64le-linux cross, ok for trunk?

2025-03-06  Jakub Jelinek  

PR target/117207
PR target/103515
* gcc.target/powerpc/pr103515.c: Add -fno-tree-vectorize to
dg-options.

--- gcc/testsuite/gcc.target/powerpc/pr103515.c.jj  2022-01-11 
23:11:23.207278673 +0100
+++ gcc/testsuite/gcc.target/powerpc/pr103515.c 2025-03-06 15:57:48.507247453 
+0100
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-rtl-loop2_unroll-optimized" } */
+/* { dg-options "-O2 -fno-tree-vectorize -fdump-rtl-loop2_unroll-optimized" } 
*/
 
 /* The pragma specified for foo2 should not affect foo1.
Verify compiler won't perform unrolling for foo1.  */

Jakub

Re: [PATCH v3 2/5] c++/modules: Ignore TU-local entities where necessary

[Jason Merrill]

On 3/5/25 8:00 AM, Nathaniel Shead wrote:

Ping for this.  Or should this cleanup wait till GCC16?


OK, let's go ahead with it now.


On Wed, Feb 12, 2025 at 12:49:03AM +1100, Nathaniel Shead wrote:

On Mon, Jan 27, 2025 at 10:20:05AM -0500, Patrick Palka wrote:

[snip]


@@ -18486,6 +18562,12 @@ dependent_operand_p (tree t)
  {
while (TREE_CODE (t) == IMPLICIT_CONV_EXPR)
  t = TREE_OPERAND (t, 0);
+
+  /* If we contain a TU_LOCAL_ENTITY assume we're non-dependent; we'll error
+ later when instantiating.  */
+  if (expr_contains_tu_local_entity (t))
+return false;


I think it'd be more robust and cheaper (avoiding a separate tree walk)
to teach the general constexpr/dependence predicates about
TU_LOCAL_ENTITY instead of handling it only here.


+
++processing_template_decl;
bool r = (potential_constant_expression (t)
? value_dependent_expression_p (t)
@@ -20255,6 +20337,9 @@ tsubst_expr (tree t, tree args, tsubst_flags_t 
complain, tree in_decl)
else
  object = NULL_TREE;
  
+	if (function_contains_tu_local_entity (templ))

+ RETURN (error_mark_node);
+
tree tid = lookup_template_function (templ, targs);
protected_set_expr_location (tid, EXPR_LOCATION (t));
  
@@ -20947,6 +21032,9 @@ tsubst_expr (tree t, tree args, tsubst_flags_t complain, tree in_decl)

  qualified_p = true;
  }
  
+	if (function_contains_tu_local_entity (function))

+ RETURN (error_mark_node);


Similarly, maybe it'd suffice to check this more generally in the
OVERLOAD case of tsubst_expr?



So I'd completely missed the idea of handling it in the OVERLOAD case;
doing this also fixes the issues I'd been having trying to handle it in
potential_constant_expression.  I think this should be a lot cleaner
now.

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?

-- >8 --

Subject: [PATCH] c++: Handle TU_LOCAL_ENTITY in tsubst_expr and
  potential_constant_expression

This cleans up the TU_LOCAL_ENTITY handling to avoid unnecessary
tree walks and make the logic more robust.

gcc/cp/ChangeLog:

* constexpr.cc (potential_constant_expression_1): Handle
TU_LOCAL_ENTITY.
* pt.cc (expr_contains_tu_local_entity): Remove.
(function_contains_tu_local_entity): Remove.
(dependent_operand_p): Remove special handling for
TU_LOCAL_ENTITY.
(tsubst_expr): Handle TU_LOCAL_ENTITY when tsubsting OVERLOADs;
remove now-unnecessary extra handling.
(type_dependent_expression_p): Handle TU_LOCAL_ENTITY.

Signed-off-by: Nathaniel Shead 
---
  gcc/cp/constexpr.cc |  5 +++
  gcc/cp/pt.cc| 80 -
  2 files changed, 19 insertions(+), 66 deletions(-)

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index f142dd32bc8..b36705fd4ce 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -10825,6 +10825,11 @@ potential_constant_expression_1 (tree t, bool 
want_rval, bool strict, bool now,
  case CO_RETURN_EXPR:
return false;
  
+/* Assume a TU-local entity is not constant, we'll error later when

+   instantiating.  */
+case TU_LOCAL_ENTITY:
+  return false;
+
  case NONTYPE_ARGUMENT_PACK:
{
tree args = ARGUMENT_PACK_ARGS (t);
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index f857b3f1180..966050a6608 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -9935,61 +9935,6 @@ complain_about_tu_local_entity (tree e)
inform (TU_LOCAL_ENTITY_LOCATION (e), "declared here");
  }
  
-/* Checks if T contains a TU-local entity.  */

-
-static bool
-expr_contains_tu_local_entity (tree t)
-{
-  if (!modules_p ())
-return false;
-
-  auto walker = [](tree *tp, int *walk_subtrees, void *) -> tree
-{
-  if (TREE_CODE (*tp) == TU_LOCAL_ENTITY)
-   return *tp;
-  if (!EXPR_P (*tp))
-   *walk_subtrees = false;
-  return NULL_TREE;
-};
-  return cp_walk_tree (&t, walker, nullptr, nullptr);
-}
-
-/* Errors and returns TRUE if X is a function that contains a TU-local
-   entity in its overload set.  */
-
-static bool
-function_contains_tu_local_entity (tree x)
-{
-  if (!modules_p ())
-return false;
-
-  if (!x || x == error_mark_node)
-return false;
-
-  if (TREE_CODE (x) == OFFSET_REF
-  || TREE_CODE (x) == COMPONENT_REF)
-x = TREE_OPERAND (x, 1);
-  x = MAYBE_BASELINK_FUNCTIONS (x);
-  if (TREE_CODE (x) == TEMPLATE_ID_EXPR)
-x = TREE_OPERAND (x, 0);
-
-  if (OVL_P (x))
-for (tree ovl : lkp_range (x))
-  if (TREE_CODE (ovl) == TU_LOCAL_ENTITY)
-   {
- x = ovl;
- break;
-   }
-
-  if (TREE_CODE (x) == TU_LOCAL_ENTITY)
-{
-  complain_about_tu_local_entity (x);
-  return true;
-}
-
-  return false;
-}
-
  /* Return a TEMPLATE_ID_EXPR corresponding to the indicated FNS and
 ARGLIST.  Valid choices for FNS are given in the cp-tree.def
 documentation for TEMPLATE_ID_EXPR.  */
@@ -18797,11 +18742,6 @@ de

[committed] pair-fusion: Add singleton move_range asserts [PR114492]

[Alex Coplan]

The PR claims that pair-fusion has invalid uses of gcc_assert (such that
the pass will misbehave with --disable-checking).  As noted in the
comments, in the case of the calls to restrict_movement, the only way we
can possibly depend on the side effects is if we call it with a
non-singleton move range.  However, the intent is that we always have a
singleton move range here, and thus we do not rely on the side effects.

This patch therefore adds asserts to check for a singleton move range
before calling restrict_movement, thus clarifying the intent and
hopefully dispelling any concerns that having the calls wrapped in
asserts is problematic here.

Tested on aarch64-linux-gnu, pushed to trunk.

Alex

gcc/ChangeLog:

PR rtl-optimization/114492
* pair-fusion.cc (pair_fusion_bb_info::fuse_pair): Check for singleton
move range before calling restrict_movement.
(pair_fusion::try_promote_writeback): Likewise.
diff --git a/gcc/pair-fusion.cc b/gcc/pair-fusion.cc
index 72e64246534..a4ef7287967 100644
--- a/gcc/pair-fusion.cc
+++ b/gcc/pair-fusion.cc
@@ -1994,7 +1994,8 @@ pair_fusion_bb_info::fuse_pair (bool load_p,
 
   auto ignore = ignore_changing_insns (changes);
   for (unsigned i = 0; i < changes.length (); i++)
-gcc_assert (rtl_ssa::restrict_movement (*changes[i], ignore));
+gcc_assert (changes[i]->move_range.singleton ()
+   && rtl_ssa::restrict_movement (*changes[i], ignore));
 
   // Check the pair pattern is recog'd.
   if (!rtl_ssa::recog (attempt, *pair_change, ignore))
@@ -3084,7 +3085,8 @@ pair_fusion::try_promote_writeback (insn_info *insn, bool 
load_p)
 
   auto ignore = ignore_changing_insns (changes);
   for (unsigned i = 0; i < ARRAY_SIZE (changes); i++)
-gcc_assert (rtl_ssa::restrict_movement (*changes[i], ignore));
+gcc_assert (changes[i]->move_range.singleton ()
+   && rtl_ssa::restrict_movement (*changes[i], ignore));
 
   if (!rtl_ssa::recog (attempt, pair_change, ignore))
 {

Re: [PATCH] libstdc++: Fix constexpr memory algo tests for COW std::string

[Giuseppe D'Angelo]

Hi,

On 06/03/2025 12:26, Jonathan Wakely wrote:

The old COW std::string is not usable in constant expressions, so these
new tests fail with -D_GLIBCXX_USE_CXX11_ABI=0.


LGTM; is there a specific incantation to run the testsuite with both 
libstdc++ ABIs? Clearly I just tested the new one...


Thank you,

--
Giuseppe D'Angelo


smime.p7s
Description: S/MIME Cryptographic Signature

[to-be-committed][RISC-V][PR rtl-optimization/119099] Avoid infinite loop in ext-dce.

[Jeff Law]

This fixes the ping-ponging of live sets in ext-dce which is left 
unresolved can lead to infinite loops in the ext-dce pass as seen by the 
P1 regression 119099.


At its core instead of replacing the livein set with the just recomputed 
data, we IOR in the just recomputed data to the existing livein set. 
That ensures the  existing livein set never shrinks.


Bootstrapped and regression tested on x86.  I've also thrown this into 
my tester to verify it across multiple targets and that we aren't 
regressing the (limited) tests we have in place for ext-dce's 
optimization behavior.


While it's a generic patch, I'll wait for the RISC-V tester to run is 
course before committing.


Jeff

PR rtl-optimization/119099
gcc/
* ext-dce.cc (ext_dce_rd_transfer_n): Do not allow the livein
set to shrink.

gcc/testsuite/
* gcc.dg/torture/pr119099.c: New test.

diff --git a/gcc/ext-dce.cc b/gcc/ext-dce.cc
index e257e3bc873..626c431f601 100644
--- a/gcc/ext-dce.cc
+++ b/gcc/ext-dce.cc
@@ -1089,16 +1089,9 @@ ext_dce_rd_transfer_n (int bb_index)
 
   ext_dce_process_bb (bb);
 
-  /* We may have narrowed the set of live objects at the start
- of this block.  If so, update the bitmaps and indicate to
- the generic dataflow code that something changed.  */
-  if (!bitmap_equal_p (&livein[bb_index], livenow))
-{
-  bitmap_copy (&livein[bb_index], livenow);
-  return true;
-}
-
-  return false;
+  /* We only allow widening the set of objects live at the start
+ of a block.  Otherwise we run the risk of not converging.  */
+  return bitmap_ior_into (&livein[bb_index], livenow);
 }
 
 /* Dummy function for the df_simple_dataflow API.  */
diff --git a/gcc/testsuite/gcc.dg/torture/pr119099.c 
b/gcc/testsuite/gcc.dg/torture/pr119099.c
new file mode 100644
index 000..21898593373
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr119099.c
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+
+int a, b;
+
+void func2(short);
+
+void func1() {
+  while (1) {
+int loc = 8;
+while (1) {
+  func2(loc);
+  if (a)
+loc = 3;
+  else if (b)
+break;
+  loc |= a;
+}
+  }
+}

[PUSHED] Fix 'libstdc++-v3/src/c++20/tzdb.cc' build for '__GTHREADS && !__GTHREADS_CXX0X' configurations

[Thomas Schwinge]

From: Jonathan Wakely 

libstdc++-v3/
* src/c++20/tzdb.cc [__GTHREADS && !__GTHREADS_CXX0X]: Use
'__gnu_cxx::__mutex'.

Co-authored-by: Thomas Schwinge 
---
 libstdc++-v3/src/c++20/tzdb.cc | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/src/c++20/tzdb.cc b/libstdc++-v3/src/c++20/tzdb.cc
index 9cf9eeccc59..1a1130f9b7b 100644
--- a/libstdc++-v3/src/c++20/tzdb.cc
+++ b/libstdc++-v3/src/c++20/tzdb.cc
@@ -35,6 +35,9 @@
 #include  // atomic, atomic
 #include  // atomic>
 #include   // mutex
+#if defined __GTHREADS && ! defined _GLIBCXX_HAS_GTHREADS
+# include  // __gnu_cxx::__mutex
+#endif
 #include  // filesystem::read_symlink
 
 #ifndef _AIX
@@ -97,11 +100,18 @@ namespace std::chrono
 {
   namespace
   {
-#if ! USE_ATOMIC_SHARED_PTR
 #ifndef __GTHREADS
 // Dummy no-op mutex type for single-threaded targets.
 struct mutex { void lock() { } void unlock() { } };
+#elif ! defined _GLIBCXX_HAS_GTHREADS
+// Use __gnu_cxx::__mutex if std::mutex isn't available.
+using mutex = __gnu_cxx::__mutex;
+# if ! USE_ATOMIC_SHARED_PTR && defined __GTHREAD_MUTEX_INIT
+#  error "TODO: __gnu_cxx::__mutex can't be initialized with 'constinit'"
+# endif
 #endif
+
+#if ! USE_ATOMIC_SHARED_PTR
 inline mutex& list_mutex()
 {
 #ifdef __GTHREAD_MUTEX_INIT
-- 
2.34.1

Re: [PATCH 3/3] c++/modules: Handle exposures of TU-local types in uninstantiated member templates

[Jason Merrill]

On 2/8/25 7:32 AM, Nathaniel Shead wrote:

On Fri, Feb 07, 2025 at 11:11:21AM -0500, Jason Merrill wrote:

On 2/7/25 9:28 AM, Nathaniel Shead wrote:

On Fri, Feb 07, 2025 at 08:14:23AM -0500, Jason Merrill wrote:

On 1/31/25 8:46 AM, Nathaniel Shead wrote:

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?

Happy to remove the custom inform for lambdas, but I felt that the
original message (which suggests that defining it within a class should
make it OK) was unhelpful here.

Similarly the 'is_exposure_of_member_type' function is not necessary to
fix the bug, and is just for slightly nicer diagnostics.

-- >8 --

Previously, 'is_tu_local_entity' wouldn't detect the exposure of the (in
practice) TU-local lambda in the following example, unless instantiated:

 struct S {
   template 
   static inline decltype([]{}) x = {};
 };

This is for two reasons.  Firstly, when traversing the TYPE_FIELDS of S
we only see the TEMPLATE_DECL, and never end up building a dependency on
its DECL_TEMPLATE_RESULT (due to not being instantiated).  This patch
fixes this by stripping any templates before checking for unnamed types.

The second reason is that we currently assume all class-scope entities
are not TU-local.  Despite this being unambiguous in the standard, this
is not actually true in our implementation just yet, due to issues with
mangling lambdas in some circumstances.  Allowing these lambdas to be
exported can cause issues in importers with apparently conflicting
declarations, so this patch treats them as TU-local as well.

After these changes, we now get double diagnostics from the two ways
that we can see the above lambda being exposed, via 'S' (through
TYPE_FIELDS) or via 'S::x'.  To workaround this we hide diagnostics from
the first case, so we only get errors from 'S::x' which will be closer
to the point the offending lambda is declared.

gcc/cp/ChangeLog:

* module.cc (trees_out::type_node): Adjust assertion.
(depset::hash::is_tu_local_entity): Handle unnamed template
types, treat lambdas specially.
(is_exposure_of_member_type): New function.
(depset::hash::add_dependency): Use it.
(depset::hash::finalize_dependencies): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/modules/internal-10.C: New test.

Signed-off-by: Nathaniel Shead 
---
gcc/cp/module.cc   | 67 ++
gcc/testsuite/g++.dg/modules/internal-10.C | 25 
2 files changed, 81 insertions(+), 11 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/modules/internal-10.C

diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index c89834c1abd..59b7270f4a5 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -9261,7 +9261,9 @@ trees_out::type_node (tree type)
/* We'll have either visited this type or have newly discovered
   that it's TU-local; either way we won't need to visit it again.  */
-   gcc_checking_assert (TREE_VISITED (type) || has_tu_local_dep (name));
+   gcc_checking_assert (TREE_VISITED (type)
+|| has_tu_local_dep (TYPE_NAME (type))
+|| has_tu_local_dep (TYPE_TI_TEMPLATE (type)));


Why doesn't the template having a TU-local dep imply that the TYPE_NAME
does?


I may not have written this the most clearly; the type doesn't
necessarily even have a template, but if it's not visited and its
TYPE_NAME hasn't had a TU-local dep made then we must instead have seen
a TYPE_TI_TEMPLATE that does have a TU-local dep.


My question is why has_tu_local_dep (name) can be false while
has_tu_local_dep (tmpl) is true.


In this case it's an early exit thing; when walking the TYPE_NAME, we
find that it's a TEMPLATE_DECL_RESULT in 'trees_out::decl_node', and
walk the TI_TEMPLATE of that decl there.

When walking this TEMPLATE_DECL we end up calling 'add_dependency' on
it, which creates the depset and adds it to the worklist.  This doesn't
add the TYPE_DECL in this pass (we don't walk the TEMPLATE_DECL dep
we've just made yet, we're still walking whatever decl we were
processing when we saw this type), so when we come back to this checking
assertion we haven't made a dep for the TYPE_NAME yet.


So the problem is that we never make_dependency for 'name' because it 
happens to be a DECL_TEMPLATE_RESULT, so find_dependency returns null, 
so has_tu_local_dep gives the wrong answer.



I notice that find_tu_local_decl doesn't walk into TYPE_TI_TEMPLATE.


So my thinking had been that 'find_tu_local_decl' doesn't need to handle
this case, because it's only ran when '!is_initial_scan', so all
dependencies that we could possibly have seen will have been created by
now.

But because 'decl_value' early exits when we see a TU-local dep, we
never end up building the TYPE_NAME depset at all, which would indeed
cause 'find_tu_local_decl' to break.  I haven't been able to make a
testcase for this however, as to actually reach this point we would have

[PATCH] middle-end/119119 - re-gimplification of empty CTOR assignments

[Richard Biener]

The following testcase runs into a re-gimplification issue during
inlining when processing

  MEM[(struct e *)this_2(D)].a = {};

where re-gimplification does not handle assignments in the same
way than the gimplifier but instead relies on rhs_predicate_for
and gimplifying the RHS standalone.  This fails to handle
special-casing of CTORs.  The is_gimple_mem_rhs_or_call predicate
already handles clobbers but not empty CTORs so we end up in
the fallback code trying to force the CTOR into a separate stmt
using a temporary - but as we have a non-copyable type here that ICEs.

The following generalizes empty CTORs in is_gimple_mem_rhs_or_call
since those need no additional re-gimplification.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Richard.

PR middle-end/119119
* gimplify.cc (is_gimple_mem_rhs_or_call): All empty CTORs
are OK when not a register type.

* g++.dg/torture/pr11911.C: New testcase.
---
 gcc/gimplify.cc|  2 +-
 gcc/testsuite/g++.dg/torture/pr11911.C | 21 +
 2 files changed, 22 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/torture/pr11911.C

diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index 07942bcc3f1..2f43060ebad 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -611,7 +611,7 @@ is_gimple_mem_rhs_or_call (tree t)
   else
 return (is_gimple_val (t)
|| is_gimple_lvalue (t)
-   || TREE_CLOBBER_P (t)
+   || (TREE_CODE (t) == CONSTRUCTOR && CONSTRUCTOR_NELTS (t) == 0)
|| TREE_CODE (t) == CALL_EXPR);
 }
 
diff --git a/gcc/testsuite/g++.dg/torture/pr11911.C 
b/gcc/testsuite/g++.dg/torture/pr11911.C
new file mode 100644
index 000..7dc836ff9b5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/torture/pr11911.C
@@ -0,0 +1,21 @@
+// { dg-do compile }
+// { dg-require-effective-target c++17 }
+
+struct b {
+  int a;
+};
+struct c {
+  b d{};
+  c() = default;
+  c(c &) = delete;
+};
+struct e {
+  c a{};
+  e() {}
+};
+inline e f() { return {}; }
+struct g {
+  e cx;
+  g() : cx{f()} {}
+};
+void h() { g i; }
-- 
2.43.0

Re: [PATCH] lto: Fix missing cleanup with incremental LTO.

[Richard Biener]

On Thu, 6 Mar 2025, Michal Jires wrote:

> Incremental LTO disabled cleanup of output_files since they have to
> persist in ltrans cache.
> This unintetionally also kept temporary early debug "*.debug.temp.o"
> files.
> 
> Bootstrapped/regtested on x86_64-linux.
> Ok for trunk?

So are the early debug files then re-generated for each new
incremental LTO link?  That's possibly an area for improvement then
(well, how we handle early debug needs some improvements).

OK.

Thanks,
Richard.

> lto-plugin/ChangeLog:
> 
>   * lto-plugin.c (cleanup_handler): Keep only files in ltrans
>   cache.
> ---
>  lto-plugin/lto-plugin.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/lto-plugin/lto-plugin.c b/lto-plugin/lto-plugin.c
> index 3d272551fed..09d5441ecc7 100644
> --- a/lto-plugin/lto-plugin.c
> +++ b/lto-plugin/lto-plugin.c
> @@ -945,6 +945,17 @@ cleanup_handler (void)
>if (!flto_incremental)
>  for (i = 0; i < num_output_files; i++)
>maybe_unlink (output_files[i]);
> +  else
> +{
> +  /* Keep files in ltrans cache.  */
> +  const char* suffix = ".ltrans.o";
> +  for (i = 0; i < num_output_files; i++)
> + {
> +   int offset = strlen (output_files[i]) - strlen (suffix);
> +   if (offset < 0 || strcmp (output_files[i] + offset, suffix))
> + maybe_unlink (output_files[i]);
> + }
> +}
>  
>free_2 ();
>return LDPS_OK;
> 

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

Re: [PATCH] middle-end/119119 - re-gimplification of empty CTOR assignments

[Jakub Jelinek]

On Thu, Mar 06, 2025 at 09:50:33AM +0100, Richard Biener wrote:
> The following testcase runs into a re-gimplification issue during
> inlining when processing
> 
>   MEM[(struct e *)this_2(D)].a = {};
> 
> where re-gimplification does not handle assignments in the same
> way than the gimplifier but instead relies on rhs_predicate_for
> and gimplifying the RHS standalone.  This fails to handle
> special-casing of CTORs.  The is_gimple_mem_rhs_or_call predicate
> already handles clobbers but not empty CTORs so we end up in
> the fallback code trying to force the CTOR into a separate stmt
> using a temporary - but as we have a non-copyable type here that ICEs.
> 
> The following generalizes empty CTORs in is_gimple_mem_rhs_or_call
> since those need no additional re-gimplification.
> 
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
> 
> Richard.
> 
>   PR middle-end/119119
>   * gimplify.cc (is_gimple_mem_rhs_or_call): All empty CTORs
>   are OK when not a register type.
> 
>   * g++.dg/torture/pr11911.C: New testcase.

LGTM.

Jakub

[r15-7852 Regression] FAIL: 29_atomics/atomic_flag/test_and_set/explicit-hle.cc -std=gnu++17 (test for excess errors) on Linux/x86_64

[haochen.jiang]

On Linux/x86_64,

e836d80374aa03a5ea5bd6cca00d826020c461da is the first bad commit
commit e836d80374aa03a5ea5bd6cca00d826020c461da
Author: Richard Sandiford 
Date:   Thu Mar 6 11:06:25 2025 +

ira: Add new hooks for callee-save vs spills [PR117477]

caused

FAIL: 29_atomics/atomic_flag/test_and_set/explicit-hle.cc  -std=gnu++17 (test 
for excess errors)
FAIL: c-c++-common/gomp/atomic-29.c (internal compiler error: in 
ix86_callee_save_cost, at config/i386/i386.cc:20620)
FAIL: c-c++-common/gomp/atomic-29.c  -std=c++17 (internal compiler error: in 
ix86_callee_save_cost, at config/i386/i386.cc:20620)
FAIL: c-c++-common/gomp/atomic-29.c  -std=c++17 (test for excess errors)
FAIL: c-c++-common/gomp/atomic-29.c  -std=c++26 (internal compiler error: in 
ix86_callee_save_cost, at config/i386/i386.cc:20620)
FAIL: c-c++-common/gomp/atomic-29.c  -std=c++26 (test for excess errors)
FAIL: c-c++-common/gomp/atomic-29.c  -std=c++98 (internal compiler error: in 
ix86_callee_save_cost, at config/i386/i386.cc:20620)
FAIL: c-c++-common/gomp/atomic-29.c  -std=c++98 (test for excess errors)
FAIL: c-c++-common/gomp/atomic-29.c (test for excess errors)
FAIL: gcc.c-torture/compile/pr52555.c   -Os  (internal compiler error: in 
ix86_callee_save_cost, at config/i386/i386.cc:20620)
FAIL: gcc.c-torture/compile/pr52555.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/execute/20010129-1.c   -O1  (internal compiler error: in 
ix86_callee_save_cost, at config/i386/i386.cc:20620)
FAIL: gcc.c-torture/execute/20010129-1.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/execute/20010129-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  (internal compiler error: in ix86_callee_save_cost, at 
config/i386/i386.cc:20620)
FAIL: gcc.c-torture/execute/20010129-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  (test for excess errors)
FAIL: gcc.c-torture/execute/20010129-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  (internal compiler error: in ix86_callee_save_cost, at 
config/i386/i386.cc:20620)
FAIL: gcc.c-torture/execute/20010129-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  (test for excess errors)
FAIL: gcc.c-torture/execute/20010129-1.c   -O2  (internal compiler error: in 
ix86_callee_save_cost, at config/i386/i386.cc:20620)
FAIL: gcc.c-torture/execute/20010129-1.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/execute/20010129-1.c   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler 
error: in ix86_callee_save_cost, at config/i386/i386.cc:20620)
FAIL: gcc.c-torture/execute/20010129-1.c   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess 
errors)
FAIL: gcc.c-torture/execute/20010129-1.c   -O3 -g  (internal compiler error: in 
ix86_callee_save_cost, at config/i386/i386.cc:20620)
FAIL: gcc.c-torture/execute/20010129-1.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/execute/pr114396.c   -Os  (internal compiler error: in 
ix86_callee_save_cost, at config/i386/i386.cc:20620)
FAIL: gcc.c-torture/execute/pr114396.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/execute/pr60072.c   -Os  (internal compiler error: in 
ix86_callee_save_cost, at config/i386/i386.cc:20620)
FAIL: gcc.c-torture/execute/pr60072.c   -Os  (test for excess errors)
FAIL: gcc.dg/20020108-1.c (internal compiler error: in ix86_callee_save_cost, 
at config/i386/i386.cc:20620)
FAIL: gcc.dg/20020108-1.c (test for excess errors)
FAIL: gcc.dg/20020206-1.c (internal compiler error: in ix86_callee_save_cost, 
at config/i386/i386.cc:20620)
FAIL: gcc.dg/20020206-1.c (test for excess errors)
FAIL: gcc.dg/20020310-1.c (internal compiler error: in ix86_callee_save_cost, 
at config/i386/i386.cc:20620)
FAIL: gcc.dg/20020310-1.c (test for excess errors)
FAIL: gcc.dg/20020418-2.c (internal compiler error: in ix86_callee_save_cost, 
at config/i386/i386.cc:20620)
FAIL: gcc.dg/20020418-2.c (test for excess errors)
FAIL: gcc.dg/20020426-2.c (internal compiler error: in ix86_callee_save_cost, 
at config/i386/i386.cc:20620)
FAIL: gcc.dg/20020426-2.c (test for excess errors)
FAIL: gcc.dg/20030204-1.c (internal compiler error: in ix86_callee_save_cost, 
at config/i386/i386.cc:20620)
FAIL: gcc.dg/20030204-1.c (test for excess errors)
FAIL: gcc.dg/20030826-2.c (internal compiler error: in ix86_callee_save_cost, 
at config/i386/i386.cc:20620)
FAIL: gcc.dg/20030826-2.c (test for excess errors)
FAIL: gcc.dg/20031202-1.c (internal compiler error: in ix86_callee_save_cost, 
at config/i386/i386.cc:20620)
FAIL: gcc.dg/20031202-1.c (test for excess errors)
FAIL: gcc.dg/20050111-1.c (internal compiler error: in ix86_callee_save_cost, 
at config/i386/i386.cc:20620)
FAIL: gcc.dg/20050111-1.c (test for excess errors)
FAIL: gcc.dg/array-init-1.c (internal compiler error: in ix86_callee_save_cost, 
at config/i386/i386.cc:20620)
FAIL: gcc.dg/array-init-1.c (test for excess errors)
FAIL: gcc.dg/ifcvt-fabs-1.c (internal compiler error: in i

Re: [PATCH 2/4] cfgloopmanip: Add infrastructure for scaling of multi-exit loops [PR117790]

[Alex Coplan]

Ping^6

On 19/02/2025 12:15, Alex Coplan wrote:
> Ping^5 for patches 2-4:
> https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672677.html
> https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672678.html
> https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672679.html
> 
> On 12/02/2025 11:20, Alex Coplan wrote:
> > Ping
> > 
> > On 03/02/2025 14:46, Tamar Christina wrote:
> > > Ping
> > > 
> > > > -Original Message-
> > > > From: Tamar Christina
> > > > Sent: Friday, January 24, 2025 9:18 AM
> > > > To: Alex Coplan ; gcc-patches@gcc.gnu.org
> > > > Cc: Richard Biener ; Jan Hubicka 
> > > > Subject: RE: [PATCH 2/4] cfgloopmanip: Add infrastructure for scaling 
> > > > of multi-exit
> > > > loops [PR117790]
> > > > 
> > > > ping
> > > > 
> > > > > -Original Message-
> > > > > From: Tamar Christina
> > > > > Sent: Wednesday, January 15, 2025 2:08 PM
> > > > > To: Alex Coplan ; gcc-patches@gcc.gnu.org
> > > > > Cc: Richard Biener ; Jan Hubicka 
> > > > > Subject: RE: [PATCH 2/4] cfgloopmanip: Add infrastructure for scaling 
> > > > > of multi-
> > > > exit
> > > > > loops [PR117790]
> > > > >
> > > > > Ping
> > > > >
> > > > > > -Original Message-
> > > > > > From: Alex Coplan 
> > > > > > Sent: Monday, January 6, 2025 11:35 AM
> > > > > > To: gcc-patches@gcc.gnu.org
> > > > > > Cc: Richard Biener ; Jan Hubicka 
> > > > > > ;
> > > > Tamar
> > > > > > Christina 
> > > > > > Subject: [PATCH 2/4] cfgloopmanip: Add infrastructure for scaling 
> > > > > > of multi-exit
> > > > > > loops [PR117790]
> > > > > >
> > > > > > As it stands, scale_loop_profile doesn't correctly handle loops with
> > > > > > multiple exits.  In particular, in the case where the expected 
> > > > > > niters
> > > > > > exceeds iteration_bound, scale_loop_profile attempts to reduce the
> > > > > > number of iterations with a call to scale_loop_frequencies, which
> > > > > > multiplies the count of each BB by a given probability.  This
> > > > > > transformation preserves the relationships between the counts of 
> > > > > > the BBs
> > > > > > within the loop (and thus the edge probabilities stay the same) but 
> > > > > > this
> > > > > > cannot possibly work for loops with multiple exits, since in order 
> > > > > > for
> > > > > > the expected niters to reduce (and counts along exit edges to 
> > > > > > remain the
> > > > > > same), the exit edge probabilities must increase, thus decreasing 
> > > > > > the
> > > > > > probabilities of the internal edges, meaning that the ratios of the
> > > > > > counts of the BBs inside the loop must change.  So we need a 
> > > > > > different
> > > > > > approach (not a straightforward multiplicative scaling) to adjust 
> > > > > > the
> > > > > > expected niters of a loop with multiple exits.
> > > > > >
> > > > > > This patch introduces a new helper, flow_scale_loop_freqs, which 
> > > > > > can be
> > > > > > used to correctly scale the profile of a loop with multiple exits.  
> > > > > > It
> > > > > > is parameterized by a probability (with which to scale the header 
> > > > > > and
> > > > > > therefore the expected niters) and a lambda which gives the desired
> > > > > > counts for the exit edges.  In this patch, to make things simpler,
> > > > > > flow_scale_loop_freqs only handles loop shapes without internal 
> > > > > > control
> > > > > > flow, and we introduce a predicate can_flow_scale_loop_freqs_p to 
> > > > > > test
> > > > > > whether a given loop meets these criteria.  This restriction is
> > > > > > reasonable since this patch is motivated by fixing the profile
> > > > > > consistency for early break vectorization, and we don't currently
> > > > > > vectorize loops with internal control flow.  We also fall back to a
> > > > > > multiplicative scaling (the status quo) for loops that
> > > > > > flow_scale_loop_freqs can't handle, so the patch should be a net
> > > > > > improvement.
> > > > > >
> > > > > > We wrap the call to flow_scale_loop_freqs in a helper
> > > > > > scale_loop_freqs_with_exit_counts which handles the above-mentioned
> > > > > > fallback.  This wrapper is still generic in that it accepts a 
> > > > > > lambda to
> > > > > > allow overriding the desired exit edge counts.  We specialize this 
> > > > > > with
> > > > > > another wrapper, scale_loop_freqs_hold_exit_counts (keeping the
> > > > > > counts along exit edges fixed), which is then used to implement the
> > > > > > niters-scaling case of scale_loop_profile, thus fixing this path 
> > > > > > through
> > > > > > the function for loops with multiple exits.
> > > > > >
> > > > > > Finally, we expose two new wrapper functions in cfgloopmanip.h for 
> > > > > > use
> > > > > > in subsequent vectorizer patches.  
> > > > > > scale_loop_profile_hold_exit_counts
> > > > > > is a variant of scale_loop_profile which assumes we want to keep the
> > > > > > counts along exit edges of the loop fixed through both parts of the
> > > > > > transformation (including the initial probab

[PATCH] libstdc++: Add missing static_assert to std::expected

[Jonathan Wakely]

The r15-2326-gea435261ad58ea change missed a static_assert for
is_move_constructible_v in expected::value()&&. When
exceptions are enabled, the program is ill-formed if the error type is
not move constructible, because we can't construct the
std::bad_expected_access. But when using -fno-exceptions, we never
construct an exception, so don't need to copy/move the error value. So
that the same code compiles with/without exceptions enabled, we should
enforce the requirement explicitly.

Add the static_assert, and a test that verifies the Mandates:
conditions added by LWG 3843 and 3490 are enforced even with
-fno-exceptions.

libstdc++-v3/ChangeLog:

* include/std/expected (expected::value()&&):
Add missing static_assert for LWG 3940.
* testsuite/20_util/expected/lwg3843.cc: New test.
---

Tested x86_64-linux.

 libstdc++-v3/include/std/expected |  1 +
 .../testsuite/20_util/expected/lwg3843.cc | 69 +++
 2 files changed, 70 insertions(+)
 create mode 100644 libstdc++-v3/testsuite/20_util/expected/lwg3843.cc

diff --git a/libstdc++-v3/include/std/expected 
b/libstdc++-v3/include/std/expected
index 7de2aeffc70..5dc1dfbe5b8 100644
--- a/libstdc++-v3/include/std/expected
+++ b/libstdc++-v3/include/std/expected
@@ -1541,6 +1541,7 @@ namespace __expected
   value() &&
   {
static_assert( is_copy_constructible_v<_Er> );
+   static_assert( is_move_constructible_v<_Er> );
if (_M_has_value) [[likely]]
  return;
_GLIBCXX_THROW_OR_ABORT(bad_expected_access<_Er>(std::move(_M_unex)));
diff --git a/libstdc++-v3/testsuite/20_util/expected/lwg3843.cc 
b/libstdc++-v3/testsuite/20_util/expected/lwg3843.cc
new file mode 100644
index 000..2afb9cc680b
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/expected/lwg3843.cc
@@ -0,0 +1,69 @@
+// { dg-do compile { target c++23 } }
+// { dg-options "-fno-exceptions" }
+
+#include 
+
+// 3843. std::expected::value() & assumes E is copy constructible
+void
+test_lwg3843()
+{
+  struct E1 {
+  E1(int) { }
+  E1(E1&) { }
+  E1(const E1&) = delete;
+  };
+  std::expected v1;
+  v1.value(); // { dg-error "here" }
+  const auto& v1c = v1;
+  v1c.value(); // { dg-error "here" }
+
+  struct E2 {
+E2(int) { }
+E2(const E2&) { }
+E2(E2&&) = delete;
+  };
+  std::expected v2;
+  v2.value();
+  std::move(v2).value(); // { dg-error "here" }
+  const auto& v2c = v2;
+  v2c.value();
+  std::move(v2c).value();
+
+  struct E3 {
+E3(int) { }
+E3(const E3&) { }
+E3(E3&&) { }
+E3(const E3&&) = delete;
+  };
+  std::expected v3;
+  v3.value();
+  std::move(v3).value();
+  const auto& v3c = v3;
+  v3c.value();
+  std::move(v3c).value(); // { dg-error "here" }
+}
+
+// 3940. std::expected::value() also needs E to be copy constructible
+void
+test_lwg3940()
+{
+  struct E1 {
+  E1(int) { }
+  E1(E1&) { }
+  E1(const E1&) = delete;
+  };
+  std::expected v1;
+  v1.value(); // { dg-error "here" }
+
+  struct E2 {
+E2(int) { }
+E2(const E2&) { }
+E2(E2&&) = delete;
+  };
+  std::expected v2;
+  std::move(v2).value(); // { dg-error "here" }
+}
+
+// { dg-error "static assertion failed" "" { target *-*-* } 0 }
+// { dg-prune-output "use of deleted function" }
+// { dg-prune-output "control reaches end of non-void function" }
-- 
2.48.1

libstdc++: Allow 'configure.host' to pre-set 'EXTRA_CFLAGS', 'EXTRA_CXX_FLAGS' (was: [PATCH] libstdc++: Allow 'configure.host' to modify 'EXTRA_CFLAGS', 'EXTRA_CXX_FLAGS')

[Thomas Schwinge]

Hi!

On 2025-02-26T23:08:29+, Jonathan Wakely  wrote:
> On Wed, 26 Feb 2025 at 20:53, Thomas Schwinge  wrote:
>> On 2025-02-26T10:50:11+, Jonathan Wakely  wrote:
>> > On Wed, 26 Feb 2025 at 10:47, Jonathan Wakely  wrote:
>> >> On Wed, 26 Feb 2025 at 10:19, Thomas Schwinge wrote:
>> >> > In particular, 'GLIBCXX_ENABLE_CXX_FLAGS' shouldn't overwrite 
>> >> > 'EXTRA_CXX_FLAGS'
>> >> > (and prepend any additional '--enable-cxx-flags=[...]').
>> >>
>> >> This seems good, but why prepend instead of append here?
>> >> If there are important flags passed down from top-level configure that
>> >> shouldn't be replaced by the libstdc++ --enable-cxx-flags option, can
>> >> we mention that in the new comment in acinclude.m4?
>> >
>> > Oh sorry, they're more likely to be from configure.host not from the
>> > top-level, right?
>>
>> That's right: for GCN, nvptx configurations inject '-fno-exceptions' etc.
>> via 'libstdc++-v3/configure.host'.
>>
>> > But if we prepend, then when users put bad options in
>> > --enable-cxx-flags we silently override that with good target-specific
>> > ones from configure.host
>>
>> That was my intention indeed -- but not a strong one.  ;-) (I've myself
>> never used '--enable-cxx-flags=[...]'.)
>
> I have used it occasionally, but long ago.
>
>> > Maybe if users explicitly give bad options, they should get an error,
>> > or a bad result?
>>
>> That's fine for me.  So if you think that makes more sense, then I'll be
>> happy to swap it around.  I agree that it would be more standard to allow
>> user-specified flags to override the default ones.
>
> Yeah, I think I'd prefer that. OK with that change, and maybe change
> the comment in acinclude.m4 from "Prepend the additional flags." to
> something like:
>
> # Append the additional flags to any that came from configure.host

Like in the attached
"libstdc++: Allow 'configure.host' to pre-set 'EXTRA_CFLAGS', 
'EXTRA_CXX_FLAGS'"?


Grüße
 Thomas


>From e1fb37969e915442536c7f9bafdd862c06e2d3cd Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 26 Feb 2025 10:13:51 +0100
Subject: [PATCH] libstdc++: Allow 'configure.host' to pre-set 'EXTRA_CFLAGS',
 'EXTRA_CXX_FLAGS'

In particular, 'GLIBCXX_ENABLE_CXX_FLAGS' shouldn't overwrite 'EXTRA_CXX_FLAGS'
(and instead append any additional '--enable-cxx-flags=[...]').

	libstdc++-v3/
	* acinclude.m4 (GLIBCXX_ENABLE_CXX_FLAGS): Append to
	'EXTRA_CXX_FLAGS' any additional flags.
	* configure: Regenerate.
	* configure.host: Document 'EXTRA_CFLAGS', 'EXTRA_CXX_FLAGS'.
---
 libstdc++-v3/acinclude.m4   | 4 +++-
 libstdc++-v3/configure  | 4 +++-
 libstdc++-v3/configure.host | 4 
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index b3423d7957a..e668d2dba27 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -3267,9 +3267,11 @@ AC_DEFUN([GLIBCXX_ENABLE_CXX_FLAGS], [dnl
 	 AC_MSG_ERROR([compiler flags start with a -]) ;;
   esac
 done
+
+# Append the additional flags to any that came from 'configure.host'.
+EXTRA_CXX_FLAGS="$EXTRA_CXX_FLAGS $enable_cxx_flags"
   fi
 
-  EXTRA_CXX_FLAGS="$enable_cxx_flags"
   AC_MSG_RESULT($EXTRA_CXX_FLAGS)
   AC_SUBST(EXTRA_CXX_FLAGS)
 ])
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index e115ee55739..78758285f21 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -19450,9 +19450,11 @@ fi
 	 as_fn_error $? "compiler flags start with a -" "$LINENO" 5 ;;
   esac
 done
+
+# Append the additional flags to any that came from 'configure.host'.
+EXTRA_CXX_FLAGS="$EXTRA_CXX_FLAGS $enable_cxx_flags"
   fi
 
-  EXTRA_CXX_FLAGS="$enable_cxx_flags"
   { $as_echo "$as_me:${as_lineno-$LINENO}: result: $EXTRA_CXX_FLAGS" >&5
 $as_echo "$EXTRA_CXX_FLAGS" >&6; }
 
diff --git a/libstdc++-v3/configure.host b/libstdc++-v3/configure.host
index 7bc43071616..933a43f241c 100644
--- a/libstdc++-v3/configure.host
+++ b/libstdc++-v3/configure.host
@@ -61,6 +61,10 @@
 #
 # It possibly modifies the following variables:
 #
+#   EXTRA_CFLAGS   extra flags to pass when compiling C code
+#
+#   EXTRA_CXX_FLAGSextra flags to pass when compiling C++ code
+#
 #   OPT_LDFLAGSextra flags to pass when linking the library, of
 #  the form '-Wl,blah'
 #  (defaults to empty in acinclude.m4)
-- 
2.34.1

[RFC][C]New syntax for the argument of counted_by attribute for C language

[Qing Zhao]

Hi,

Since I sent the patch series for “extend counted_by attribute to pointer 
fields of structure” two months ago, a lot of discussion were invoked both in
GCC community and CLANG community:

https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673837.html
https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-c-fbounds-safety/70854/131?u=gwelymernans

After reading all these discussions, understanding, studying, more discussions, 
 
and finally making the whole picture clearer, we came up with a proposal to 
change
the current design and add a new syntax for the argument of counted_by 
attribute. 

The original idea of the new syntax was from Joseph, Michael and Martin, Bill 
and Kees
involved in the whole process of the proposal, providing a lot of suggestions 
and
comments. Really appreciate for the help from all of them. 

In this thread, I am also CC’ing several people from Apple who worked on the 
-fbounds-safety
project on CLANG side: yeoul...@apple.com , 
d_tard...@apple.com , dl...@apple.com 
,
and dcough...@apple.com .  

Please take a look at the proposal in below.

Let me know if you have any comments and suggestions.

Thanks.

Qing.

=

New syntax for the argument of counted_by attribute
--An extension to C language  

Outline

0. A simple summary of the proposal

1. The motivation
 1.1 The current syntax of the counted_by argument might break existing legal C 
code
 1.2 New requests from the users of the counted_by attribute
  1.2.1 Refer to a field in the nested structure
  1.2.2 Refer to globals or locals
  1.2.3 Represent simple expression
  1.2.4 Forward referencing

2. The requirement

3. The proposed new syntax
 3.1 Legal C code with VLA works correctly when mixing with counted_by
 3.2 Satisfy all the new requests
  3.2.1  Refer to a field in the nested structure
  3.2.2 Refer to globals or locals
  3.2.3 Represent simple expression
 3.3 How to resolve the forward reference issue in section 1.2.4?

Appendix A: Scope of variables in C and C++
  --The hints to the design of counted_by in C
Appendix B: An example in linux kernel that the global cannot be "const" 
qualified


0. A simple summary of the proposal

We propose a new syntax to the argument of the counted_by attribute:  
 * Introduce a new keyword, __self, to represent the new concept, 
   "the current object" of the nearest non-anonymous enclosing structure, 
   which allows the object of the structure to refer to its own member inside
   the structure definition.  

 * With the new keyword, __self, the member variable can be referenced 
by appending the member access operator "." to "__self", such as, 
__self.member.

 * This new keyword is invalid except in the bounds checking attributes, 
such as "counted_by", etc., inside a structure definition.

 * Simple expression is enabled by this new keyword inside the attribute 
counted_by with the following limitation:
A. no side-effect is allowed;
and
B. the operators of the expression are simple arithmetic operators, and the 
 operands could be one of:
   B.1 __self.member or __self.member1.member2...(for nested structure);
   B.2 constant;
   B.3 locals that will not be changed after initialization;
   B.4 globals that will not be changed after initialization;


1. The motivation  

There are two major motivations for this new syntax.  

1.1 The current syntax of the counted_by argument might break existing legal C 
code

The counted_by attribute is currently defined as:  
(https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-counted_005fby-variable-attribute)

counted_by (count)
The counted_by attribute may be attached to the C99 flexible array member 
of a structure. It indicates that the number of the elements of the array is 
given by the field "count" in the same structure as the flexible array member.

For example:

int count;
struct X {
  int count;
  char array[] __attribute__ ((counted_by (count)));  
};

In the above, the argument of the attribute "count" is an identifier that will 
be 
looked up in the scope of the enclosing structure "X". Due to this new scope 
of variable, the identifier "count" refers to the member variable "count" of 
this 
structure but not the global variable defined outside of the structure.   

This is a new scope of variable that is added to the C language. In C, the 
default available scopes of variable include only two scopes, global scope 
and local scope.  

The global scope refers to the region outside any function or block. 
The variables declared here are accessible throughout the entire program.

The local scope refers to the region enclosed between the { } braces, which 
represent the boundary of a function or a block inside functions. The variables 
declared within a function or a block are only accessible locally inside that 
function or

Re: [Fortran, Patch, PR107143, v1] Fix gimplification error in forall' pointer remapping

[Harald Anlauf]

Hi Andre,

Am 06.03.25 um 09:15 schrieb Andre Vehreschild:

Hi Harald,

I try to explain why I think my patch although solving the issue for this case,
does not do so in every case:

My patch lets dependency analysis figure that the two objects can not have any
dependencies on each other or memory they are pointing to when the types are
different. Lets assume a simple list with a head node:

type node
   type(node), pointer :: prev, next
end type

type head
   type(node), pointer :: first, last
end type

(Just as an example; this might not be correct Fortran). Setting up a node

   type(head) :: h
   type(node), allocatable, target :: n

   allocate(n)
   n%prev = n%next = NULL()
   h%first => n
   h%last => n

The patched dependency analysis will deem `h%first => n` operands to be
independent of each other based on both having different types. Note,
dependency analysis looks at the object's type first, i.e. `head` vs. `node`
where I patched it!

While the patch may be correct for the example, it may not be for every case.
Just look one ref further: `h%first`'s type is `node` this would be deemed
having (potentially) a dependency on the type of the target `n`, because both
are of type `node`. Just having the same type is enough here!

So much just for the consequences of my change. Now let me try to explain, why
I think the patch is insufficient:

Assume a type (again pseudo-Fortran):

type T
   type(T), pointer :: n(:,:)
end type

Now doing something like

type(T) :: v1, v2

v1%n(n:m, m:n) => v2%n(m:n, n:m)

The types on lhs and rhs need to be the same. Then even the patched dependency
analysis concludes that in a `forall` a temporary is needed, because the
pointer assignment may overlap (trans-stmt.cc:5411):

need_temp = gfc_check_dependency (c->expr1, c->expr2, 0);

The indexes don't really matter here. They just need to be complicated, i.e.not
just a AR_FULL or AR_ELEMENT. Now `gfc_trans_pointer_assign_need_temp()` is
chosen. That routine in line trans-stmt.cc:5072 converts the lhs into a
descriptor. But because of the non-full/complicated array addressing (note, the
non-contiguous indexes !) `gfc_conv_expr_descriptor()` creates a `parm.12` (in
my case) temporary descriptor. That temporary descriptor, hence the name, is
usually used as actual argument to call a function. But the next line in
`gfc_trans_pointer_assign_need_temp` just assigns the rhs` temporary to that
`parm.12` (I have omitted only some casts, but in the code generated there are
*no* member-references):

parm.12 = lhs-temp

This leads to the gimplification error, because the types of the rhs
temporary and the temporary `parm.12` are not compatible. Furthermore is
the assignment as it is done there non-sense in my eyes, because it is literally
`parm.12 = rhs-temp`. I.e. in the code generated just before that, `parm.12` is
constructed an initialized laboriously and then shall be overwritten completely.
I assume that we would rather need something like (pseudo-pseudo code):

for (n = 1: #elem(rhs-temp))
   parm.12.data[i] = rhs-temp.data[i]
end for

But I have no clue how to easily accomplish that. I tried putting the rhs-temp
into the se of the `gfc_conv_expr_descriptor()` and setting `se.direct_byref =
1`, but that does it the wrong way around, i.e. rhs = lhs (Side note: having a
routine doing an assignment, that is otherwise just delivering a descriptor, is
some odd design decision). So I am at a loss here.

I hope to not have confused everyone. The possibility that I am mislead or
overlooking something or even thinking to complicated here is very likely.
So please correct me!

Therefore let's discuss this a bit more. I hold the patch back until we come to
a conclusion, that it is worth merging w/o breaking too much (which could be
possible, because that dependency analysis is used in many locations).


ok, I think I understand the potential issue you are bringing up here.
After the patch, we might not generate a temporary when it is actually
needed.  But does the current code do it right?

If not, we (= you) might proceed by committing the present patch,
open a PR about a missing / improper dependency analysis, and
link to the current discussion on the ML so that your arguments
are properly tracked.  Especially if the discussion and the solution
takes a little longer.

Or you do think your patch makes anything worse?

Thanks,
Harald


Regards,
Andre


On Wed, 5 Mar 2025 20:53:37 +0100
Harald Anlauf  wrote:


Hi Andre,

Jerry already OK'ed your patch, but:

Am 05.03.25 um 15:34 schrieb Andre Vehreschild:

This fixes the PR, but not really the problem, because when say a
obj(i)%arr(2:5) => obj(i)%arr(1:4) is done we run into the same issue. I
don't have a solution for that error. It might  be needed to prevent
generating the parm.NN variable for the lhs, because that is mostly useless
there. (Or I don't understand (yet) how to use it).


can you explain where you do see an issue here?

A pointer assignment in the way you describ

Re: [PATCH] Fortran: improve checking of substring bounds [PR119118]

[Harald Anlauf]

Hi Steve,

Am 06.03.25 um 22:32 schrieb Steve Kargl:

On Thu, Mar 06, 2025 at 10:04:08PM +0100, Harald Anlauf wrote:


this patch fixes an interesting regression that prevented substring
bounds checks from being generated if the substring start was not a
variable, but rather a constant or an expression.

The fix I chose turned out to be a little larger than I anticipated:
handling the case of an expression being used needs scanning for
implied-do indices.  See attached patch for details.

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



Bene quidem!

Thanks for expanded the testcases to include implied-do.

One nit below.

OK to comment.


+
+/* Traverse expr, checking all EXPR_VARIABLE symbols for their
+   implied_index attribute.  Return true if any variable may be
+   being used as an implied-do index.  Its safe to pessimistically


The word "being" can be deleted.


+   return true, and assume a dependency.  */




Indeed.  Fixed and pushed as r15-7873-gac8a70db59ac30.

Thanks for the speedy review!

Harald

Re: [PATCH v1] RISC-V: Tweak asm check for test case multiple_rgroup_zbb.c

[Jeff Law]

On 3/5/25 6:34 PM, pan2...@intel.com wrote:

From: Pan Li 

The changes to vsetvl pass since 14 result in the asm check failure,
update the asm check to meet the newest behavior.

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

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/partial/multiple_rgroup_zbb.c: Tweak
the asm check for vsetvl.

OK.

jeff

Re: [PATCH v2] c++: ICE with operator new[] in constexpr [PR118775]

[Marek Polacek]

On Wed, Mar 05, 2025 at 05:28:49PM -0500, Jason Merrill wrote:
> On 3/5/25 4:00 PM, Marek Polacek wrote:
> > On Wed, Mar 05, 2025 at 03:31:59PM -0500, Jason Merrill wrote:
> > > On 3/5/25 12:09 PM, Marek Polacek wrote:
> > > > On Tue, Mar 04, 2025 at 05:34:10PM -0500, Jason Merrill wrote:
> > > > > On 2/11/25 6:24 PM, Marek Polacek wrote:
> > > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > > > > > 
> > > > > > -- >8 --
> > > > > > Here we ICE since r11-7740 because we no longer say that (long)&a
> > > > > > (where a is a global var) is non_constant_p.  So VERIFY_CONSTANT
> > > > > > does not return and we crash on tree_to_uhwi.  We should check
> > > > > > tree_fits_uhwi_p before calling tree_to_uhwi.
> > > > > > 
> > > > > > PR c++/118775
> > > > > > 
> > > > > > gcc/cp/ChangeLog:
> > > > > > 
> > > > > > * constexpr.cc (cxx_eval_call_expression): Check 
> > > > > > tree_fits_uhwi_p.
> > > > > > 
> > > > > > gcc/testsuite/ChangeLog:
> > > > > > 
> > > > > > * g++.dg/cpp2a/constexpr-new24.C: New test.
> > > > > > * g++.dg/cpp2a/constexpr-new25.C: New test.
> > > > > > ---
> > > > > > gcc/cp/constexpr.cc  |  7 +
> > > > > > gcc/testsuite/g++.dg/cpp2a/constexpr-new24.C | 25 
> > > > > > ++
> > > > > > gcc/testsuite/g++.dg/cpp2a/constexpr-new25.C | 27 
> > > > > > 
> > > > > > 3 files changed, 59 insertions(+)
> > > > > > create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-new24.C
> > > > > > create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-new25.C
> > > > > > 
> > > > > > diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
> > > > > > index f142dd32bc8..f8f9a9df1a2 100644
> > > > > > --- a/gcc/cp/constexpr.cc
> > > > > > +++ b/gcc/cp/constexpr.cc
> > > > > > @@ -2909,6 +2909,13 @@ cxx_eval_call_expression (const 
> > > > > > constexpr_ctx *ctx, tree t,
> > > > > >   gcc_assert (arg0);
> > > > > >   if (new_op_p)
> > > > > > {
> > > > > > + if (!tree_fits_uhwi_p (arg0))
> > > > > > +   {
> > > > > > + if (!ctx->quiet)
> > > > > > +   error_at (loc, "cannot allocate array: size too 
> > > > > > large");
> > > > > 
> > > > > "too large" seems misleading in this case, where it just isn't a
> > > > > compile-time constant.
> > > > 
> > > > Fair, how about "size not constant"?
> > > > > Why didn't the VERIFY_CONSTANT just above already reject this?
> > > > 
> > > > This is about *non_constant_p.  Since r11-7740 
> > > > cxx_eval_constant_expression
> > > > returns early less often:
> > > > 
> > > > @@ -6656,7 +6656,8 @@ cxx_eval_constant_expression (const constexpr_ctx 
> > > > *ctx, tree t,
> > > > 
> > > >   if (TREE_CODE (t) == CONVERT_EXPR
> > > >   && ARITHMETIC_TYPE_P (type)
> > > > -   && INDIRECT_TYPE_P (TREE_TYPE (op)))
> > > > +   && INDIRECT_TYPE_P (TREE_TYPE (op))
> > > > +   && ctx->manifestly_const_eval)
> > > 
> > > Aha.  I think this should check ctx->strict instead of
> > > ctx->manifestly_const_eval.
> > 
> > In the r11-7740 patch Jakub mentioned he had tried that, but it regressed
> > some tests.  I've tried to see if that is still the case and it is; at
> > least
> > g++.dg/cpp1y/constexpr-shift1.C
> > g++.dg/cpp1y/constexpr-82304.C
> > g++.dg/cpp0x/constexpr-ex1.C
> > FAIL with ctx->strict.
> 
> This seems to be because maybe_constant_init_1 wrongly chooses non-strict
> mode for static constexpr variables.  After correcting that, only
> constexpr-new3.C fails, which seems to be a latent bug that we can otherwise
> see by moving v7 into a function.

Ah yeah,

@@ -9649,7 +9651,9 @@ maybe_constant_init_1 (tree t, tree decl, bool 
allow_non_constant,
 static or thread storage duration even if it isn't required, but we
 shouldn't bend the rules the same way for automatic variables.  */
   bool is_static = (decl && DECL_P (decl)
-   && (TREE_STATIC (decl) || DECL_EXTERNAL (decl)));
+   && ((TREE_STATIC (decl)
+&& !DECL_DECLARED_CONSTEXPR_P (decl))
+   || DECL_EXTERNAL (decl)));
   if (is_static)
manifestly_const_eval = true;
 
does seem to work.  I don't know how I would fix constexpr-new3.C though.
 
> > Also, while using ctx->strict fixes constexpr-new25.C, it doesn't fix
> > the constexpr-new24.C crash.
> 
> Why?

Took me a sec but it's because there's no CONVERT_EXPR, only NOP_EXPR.
In that test we start off with:

  1 * (sizetype) (long int) &a

where (long int) &a is a CONVERT_EXPR, but after the

   size = cp_fully_fold (size);

in build_new_1 we get:

  (sizetype) &a

and the CONVERT_EXPR is gone.  Expanding the "conversion from pointer type"
check to NOP_EXPR breaks a lot of other tests.  Sigh.

Marek

Re: The COBOL front end, version 3, now in 14 easy pieces

[James K. Lowden]

On Wed, 5 Mar 2025 11:43:16 +0100
Richard Biener  wrote:

> > In short, despite not trying to support DESTDIR, we do anyway, by
> > happy accident.  And we are now better informed.
> 
> Thanks.  Checking cobol-patched again I see

Hi Richard,

I have regenerated and force-pushed cobol-patched.  It is now based on

commit 49ac89e03f2f171b401ac8b9d7c3cef72efbdc63
Author: Jakub Jelinek 
Date:   Thu Mar 6 17:29:03 2025 +0100

https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/-/tree/cobol-patched?ref_type=heads

There are still 15 patches.  The texi file updates that I thought would
cause a problem merged cleanly.  Yay, git.

At your suggestion, we tested a bootstrap build with multilib.

Our thanks to you and Jakub for your patience and guidance.  

The issues raised are addressed: 

- test for 32-bit code generation in the compiler instead of checking
for -m32 in gcobol.
- use GCC_WITH_TOOLEXECLIBDIR in libgcobol/configure.am
- support DESTDIR in libgcobol/Automake.am
- verify --enable-version-specific-runtime-libs 

Status of issues, with reference to email:

On Wed, Mar 05, 2025 at 12:46:48PM +0100, Richard Biener wrote:
> and the installed compiler behaves as intended.  I can trick -m32 to
"work"
> by using the generic gcc driver:
>
> > ./install/gcc-cobol/usr/local/bin/gcc -x cobol t.cob -m32 -c

Fixed by applying Jakub's suggestion,

  if (!targetm.scalar_mode_supported_p (TImode) || !float128_type_node)
sorry ("COBOL not supported in this configuration");

$ /tmp/build-try/bin/gcobol -oo -m32 -ffixed-form
gcc/cobol/nist/NC/NC101A.cbl : sorry, unimplemented: COBOL
requires a 64-bit configuration

(I don't think "configuration" is the best nomenclature here, if
"configuration" is the product of the "configure" script.  Suggestions
welcome.)

> > make install DESTDIR=/home/rguenther/install/gcc-cobol
> libtool: install: error: cannot install `libgcobol.la' to a directory

Fixed by point-and-grunt comparison with libatomic.  Observed

+   $(top_srcdir)/../config/toolexeclibdir.m4 \

in libgcobol/Makefile.in.

> ... aaand it fails: (../gcc-cobol/configure --enable-languages=cobol
> --disable-bootstrap --enable-checking=release
> --enable-version-specific-runtime-libs)

Tested with that specific command line after applying above changes.
Observed "make install" works correctly.

--jkl

Re: [PATCH] libstdc++: Make std::unique_lock self-move-assignable

[Patrick Palka]

On Thu, Mar 6, 2025 at 8:53 AM Jonathan Wakely  wrote:
>
> LWG 4172 was approved in Hagenberg, February 2025, fixing
> std::unique_lock and std::shared_lock to work correctly for
> self-move-assignment.
>
> Our std::shared_lock was already doing the right thing (contradicting
> the standard) so just add a comment there. Our std::unique_lock needs to
> be fixed to do the right thing.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/unique_lock.h (unique_lock::operator=): Fix for
> self-move-assignment.
> * include/std/shared_mutex (shared_lock::operator=): Add
> comment.
> * testsuite/30_threads/shared_lock/cons/lwg4172.cc: New test.
> * testsuite/30_threads/unique_lock/cons/lwg4172.cc: New test.

LGTM

> ---
>
> Tested x86_64-linux.
>
>  libstdc++-v3/include/bits/unique_lock.h   |  9 ++
>  libstdc++-v3/include/std/shared_mutex |  2 ++
>  .../30_threads/shared_lock/cons/lwg4172.cc| 28 +++
>  .../30_threads/unique_lock/cons/lwg4172.cc| 27 ++
>  4 files changed, 59 insertions(+), 7 deletions(-)
>  create mode 100644 
> libstdc++-v3/testsuite/30_threads/shared_lock/cons/lwg4172.cc
>  create mode 100644 
> libstdc++-v3/testsuite/30_threads/unique_lock/cons/lwg4172.cc
>
> diff --git a/libstdc++-v3/include/bits/unique_lock.h 
> b/libstdc++-v3/include/bits/unique_lock.h
> index 22ea7e9d772..5b1518745ca 100644
> --- a/libstdc++-v3/include/bits/unique_lock.h
> +++ b/libstdc++-v3/include/bits/unique_lock.h
> @@ -126,14 +126,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>
>unique_lock& operator=(unique_lock&& __u) noexcept
>{
> -   if(_M_owns)
> - unlock();
> -
> +   // _GLIBCXX_RESOLVE_LIB_DEFECTS
> +   // 4172. unique_lock self-move-assignment is broken
> unique_lock(std::move(__u)).swap(*this);
> -
> -   __u._M_device = 0;
> -   __u._M_owns = false;
> -
> return *this;
>}
>
> diff --git a/libstdc++-v3/include/std/shared_mutex 
> b/libstdc++-v3/include/std/shared_mutex
> index cbdf58f403b..94c8532399d 100644
> --- a/libstdc++-v3/include/std/shared_mutex
> +++ b/libstdc++-v3/include/std/shared_mutex
> @@ -780,6 +780,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>shared_lock&
>operator=(shared_lock&& __sl) noexcept
>{
> +   // _GLIBCXX_RESOLVE_LIB_DEFECTS
> +   // 4172. unique_lock self-move-assignment is broken
> shared_lock(std::move(__sl)).swap(*this);
> return *this;
>}
> diff --git a/libstdc++-v3/testsuite/30_threads/shared_lock/cons/lwg4172.cc 
> b/libstdc++-v3/testsuite/30_threads/shared_lock/cons/lwg4172.cc
> new file mode 100644
> index 000..0a3bf10b8bb
> --- /dev/null
> +++ b/libstdc++-v3/testsuite/30_threads/shared_lock/cons/lwg4172.cc
> @@ -0,0 +1,28 @@
> +// { dg-do run { target c++14 } }
> +
> +// LWG 4172. unique_lock self-move-assignment is broken
> +
> +#include 
> +#include 
> +
> +void
> +test_self_move()
> +{
> +  struct Lockable
> +  {
> +bool locked = false;
> +void lock_shared() { locked = true; }
> +void unlock_shared() { locked = false; }
> +bool try_lock_shared() { if (locked) return false; return locked = true; 
> }
> +  };
> +
> +  Lockable x;
> +  std::shared_lock l(x);
> +  l = std::move(l);
> +  VERIFY(x.locked);
> +}
> +
> +int main()
> +{
> +  test_self_move();
> +}
> diff --git a/libstdc++-v3/testsuite/30_threads/unique_lock/cons/lwg4172.cc 
> b/libstdc++-v3/testsuite/30_threads/unique_lock/cons/lwg4172.cc
> new file mode 100644
> index 000..37542b586a9
> --- /dev/null
> +++ b/libstdc++-v3/testsuite/30_threads/unique_lock/cons/lwg4172.cc
> @@ -0,0 +1,27 @@
> +// { dg-do run { target c++11 } }
> +
> +// LWG 4172. unique_lock self-move-assignment is broken
> +
> +#include 
> +#include 
> +
> +void
> +test_self_move()
> +{
> +  struct Lockable
> +  {
> +bool locked = false;
> +void lock() { locked = true; }
> +void unlock() { locked = false; }
> +  };
> +
> +  Lockable x;
> +  std::unique_lock l(x);
> +  l = std::move(l);
> +  VERIFY(x.locked);
> +}
> +
> +int main()
> +{
> +  test_self_move();
> +}
> --
> 2.48.1
>

Re: [PATCH] libstdc++: Remove redundant std::span destructor

[Patrick Palka]

On Thu, Mar 6, 2025 at 6:33 AM Jonathan Wakely  wrote:
>
> This destructor declaration serves no purpose, as pointed out by LWG
> 3903 which was approved at Varna, June 2023.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/span (span::~span): Remove, as per LWG 3903.

LGTM

> ---
>
> Tested x86_64-linux.
>
>  libstdc++-v3/include/std/span | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/libstdc++-v3/include/std/span b/libstdc++-v3/include/std/span
> index 247b942dc3b..49ab9109d83 100644
> --- a/libstdc++-v3/include/std/span
> +++ b/libstdc++-v3/include/std/span
> @@ -257,8 +257,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> : _M_ptr(__s.data()), _M_extent(__s.size())
> { }
>
> -  ~span() noexcept = default;
> -
>constexpr span&
>operator=(const span&) noexcept = default;
>
> --
> 2.48.1
>

[PATCH] libstdc++: Fix failures in new std::complex test [PR119144]

[Jonathan Wakely]

This test fails due to duplicate explicit instantiations on targets
where size_t and unsigned int are the same type. It also fails with
-D_GLIBCXX_USE_CXX11_ABI=0 due to using std::string in constexpr
functions, and with --disable-libstdcxx-pch due to not including
 for ranges::fold_left.

libstdc++-v3/ChangeLog:

PR libstdc++/119144
* testsuite/26_numerics/complex/tuple_like.cc: Include
, replace std::string with std::string_view,
instantiate tests for long instead of size_t.
---

Tested x86_64-linux (with -m32 and -D_GLIBCXX_USE_CXX11_ABI=0 and
--disable-libstdcxx-pch).

Pushed to trunk.

 libstdc++-v3/testsuite/26_numerics/complex/tuple_like.cc | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/libstdc++-v3/testsuite/26_numerics/complex/tuple_like.cc 
b/libstdc++-v3/testsuite/26_numerics/complex/tuple_like.cc
index 7d8d2ee99ce..1150861ae0a 100644
--- a/libstdc++-v3/testsuite/26_numerics/complex/tuple_like.cc
+++ b/libstdc++-v3/testsuite/26_numerics/complex/tuple_like.cc
@@ -2,7 +2,8 @@
 
 #include 
 #include 
-#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -83,10 +84,10 @@ void
 test_tuple_cat()
 {
   std::complex cpx(T(1), T(2));
-  std::pair p(42, "hello");
+  std::pair p(42, "hello");
 
   auto r = std::tuple_cat(cpx, p, cpx);
-  static_assert(std::is_same_v>);
+  static_assert(std::is_same_v>);
   VERIFY(std::get<0>(r) == T(1));
   VERIFY(std::get<1>(r) == T(2));
   VERIFY(std::get<2>(r) == 42);
@@ -176,4 +177,4 @@ TEST(__gnu_cxx::__bfloat16_t)
 TEST(char)
 TEST(int)
 TEST(unsigned int)
-TEST(size_t)
+TEST(long)
-- 
2.48.1

[PATCH] c++: Fix up instantiation of pointer/reference/array types with attributes [PR119138]

[Jakub Jelinek]

Hi!

My r15-7822 PR118787 change unfortunately broke build on x86_64-w64-mingw32.
The reduced testcase below shows what is going on.
va_list on this target is char * with extra (non-dependent) attributes
on it.
Before my r15-7822 change, instantiation of such type used the fast path and
just returned t, but as it has non-NULL TYPE_ATTRIBUTES, it now falls
through, builds a pointer type and then calls
apply_late_template_attributes.  And in there triggers a bug, that function
has been written for types with RECORD_TYPE/UNION_TYPE (or ENUMERAL_TYPE?)
in mind, where we call apply_late_template_attributes with
ATTR_FLAG_TYPE_IN_PLACE and can just apply the non-dependent attributes
directly to TYPE_ATTRIBUTES.  That is wrong for shared types like
{POINTER,REFERENCE,ARRAY}_TYPE etc., we should just force
cp_build_type_attribute_variant to build a variant type for the
non-dependent attributes and then process dependent attributes (which
given attr_flag will DTRT already).

The second change in the patch is an optimization, we can actually return
back to returning t even when TYPE_ATTRIBUTES is non-NULL, as long as it
is non-dependent (dependent attributes are stored first, so it is enough
to check the first attribute).

Bootstrapped/regtested on x86_64-linux and i686-linux and tested with
x86_64-linux -> x86_64-w64-mingw32 cross build (which failed before during
libstdc++-v3 build).  Ok for trunk?

2025-03-06  Jakub Jelinek  

PR c++/119138
* pt.cc (apply_late_template_attributes): Set p to NULL if
ATTR_FLAG_TYPE_IN_PLACE is not set in attr_flags.
(tsubst) :
Reuse original type even if TYPE_ATTRIBUTES is non-NULL, but all
the attributes are non-dependent.

* g++.dg/template/pr119138.C: New test.

--- gcc/cp/pt.cc.jj 2025-03-05 06:40:52.406421999 +0100
+++ gcc/cp/pt.cc2025-03-06 11:54:10.127739493 +0100
@@ -12393,7 +12393,8 @@ apply_late_template_attributes (tree *de
  to our attributes parameter.  */
   gcc_assert (*p == attributes);
 }
-  else if (FUNC_OR_METHOD_TYPE_P (*decl_p))
+  else if (FUNC_OR_METHOD_TYPE_P (*decl_p)
+  || (attr_flags & ATTR_FLAG_TYPE_IN_PLACE) == 0)
 p = NULL;
   else
 {
@@ -16867,7 +16868,8 @@ tsubst (tree t, tree args, tsubst_flags_
   {
if (type == TREE_TYPE (t)
&& TREE_CODE (type) != METHOD_TYPE
-   && TYPE_ATTRIBUTES (t) == NULL_TREE)
+   && (TYPE_ATTRIBUTES (t) == NULL_TREE
+   || !ATTR_IS_DEPENDENT (TYPE_ATTRIBUTES (t
  return t;
 
/* [temp.deduct]
@@ -17029,7 +17031,8 @@ tsubst (tree t, tree args, tsubst_flags_
   it will obviously be the same as T.  */
if (type == TREE_TYPE (t)
&& domain == TYPE_DOMAIN (t)
-   && TYPE_ATTRIBUTES (t) == NULL_TREE)
+   && (TYPE_ATTRIBUTES (t) == NULL_TREE
+   || !ATTR_IS_DEPENDENT (TYPE_ATTRIBUTES (t
  return t;
 
/* These checks should match the ones in create_array_type_for_decl.
--- gcc/testsuite/g++.dg/template/pr119138.C.jj 2025-03-06 11:29:17.811634125 
+0100
+++ gcc/testsuite/g++.dg/template/pr119138.C2025-03-06 12:04:02.077480568 
+0100
@@ -0,0 +1,16 @@
+// PR c++/119138
+// { dg-do compile }
+
+#include 
+
+template 
+void
+foo (va_list)
+{
+}
+
+void
+bar (va_list ap)
+{
+  foo  (ap);
+}

Jakub

Re: [PATCH] c++/modules: Better handle no-linkage decls in unnamed namespaces [PR118799]

[Jason Merrill]

On 2/9/25 6:38 AM, Nathaniel Shead wrote:

On Sun, Feb 09, 2025 at 01:16:00AM +1100, Nathaniel Shead wrote:

Tested on x86_64-pc-linux-gnu, OK for trunk if full bootstrap + regtest
passes?

-- >8 --

There are two issues with no-linkage decls (e.g. explicit type aliases)
in unnamed namespaces that this patch fixes.

Firstly, we don't currently handle exporting no-linkage decls in unnamed
namespaces.  This should be ill-formed in [module.export], since having
an exported declaration within a namespace-definition makes the
namespace definition exported (p2), but an unnamed namespace has
internal linkage thus violating p3.

Secondly, by the standard it appears to be possible to emit unnamed
namespaces from named modules in certain scenarios.  This patch makes
the adjustments needed to ensure we don't error in this case.



One thing to note with this is that it means that the following sample:

   export module M;
   namespace {
 struct Internal {};
 using Alias = Internal;
   }

will still error:

test.cpp:4:9: error: ‘using {anonymous}::Alias = struct {anonymous}::Internal’ 
exposes TU-local entity ‘struct {anonymous}::Internal’
 4 |   using Alias = Internal;
   | ^
test.cpp:3:10: note: ‘struct {anonymous}::Internal’ declared with internal 
linkage
 3 |   struct Internal {};
   |  ^~~~

https://eel.is/c++draft/basic.link#17 is the relevant paragraph here,
but I'm not 100% sure what it says about this example; I suppose that
given Alias isn't really an entity maybe this should be OK?


Right; a non-template alias isn't an entity, and p17 only makes exposure 
ill-formed if the declaration declares an entity.



But either way we definitely don't want to emit this alias.

Maybe the correct approach here is to mark an explicit type alias
TU-local iff the type it refers to is itself TU-local?  So something
like this on top of this patch:


Hmm, since it isn't an entity, it also isn't a TU-local entity.  Maybe 
in finalize_dependencies, ignore is_exposure if the dep is not an entity?


Jason

[pushed] Fix comment typos

[Simon Martin]

While investigating PR c++/99538 I noticed two comment typos: "delared"
and "paramter". The first has a single occurrence, but the second a few
more. This patch fixes all of them.

I'll commit it as obvious.

gcc/ChangeLog:

* config/i386/x86-tune-sched.cc (ix86_fuse_mov_alu_p): Fix
comment typo, paramter -> parameter.
* config/lm32/lm32.cc (lm32_std_gimplify_va_arg_expr): Likewise.

gcc/cp/ChangeLog:

* cp-tree.h (processing_contract_condition): Fix comment typo,
paramter -> parameter.
* parser.cc (cp_parser_requires_expression): Fix comment typo,
delared -> declared.

gcc/rust/ChangeLog:

* rust-diagnostics.h (RUST_ATTRIBUTE_GCC_DIAG): Fix comment
typo, paramter -> parameter.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/ppc64-abi-1.c: Fix comment typos, paramter
-> parameter.
* gcc.target/powerpc/ppc64-abi-2.c: Likewise.

---
 gcc/config/i386/x86-tune-sched.cc  |  3 +--
 gcc/config/lm32/lm32.cc|  2 +-
 gcc/cp/cp-tree.h   |  2 +-
 gcc/cp/parser.cc   |  2 +-
 gcc/rust/rust-diagnostics.h|  2 +-
 gcc/testsuite/gcc.target/powerpc/ppc64-abi-1.c | 12 ++--
 gcc/testsuite/gcc.target/powerpc/ppc64-abi-2.c | 12 ++--
 7 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/gcc/config/i386/x86-tune-sched.cc 
b/gcc/config/i386/x86-tune-sched.cc
index a51764e078c..685a83c4311 100644
--- a/gcc/config/i386/x86-tune-sched.cc
+++ b/gcc/config/i386/x86-tune-sched.cc
@@ -633,7 +633,7 @@ ix86_fuse_mov_alu_p (rtx_insn *mov, rtx_insn *alu)
   && !REG_P (op1)
   && !x86_64_immediate_operand (op1, VOIDmode))
 return false;
-  /* Only one of two paramters must be move destination.  */
+  /* Only one of two parameters must be move destination.  */
   if (op1 && REG_P (op1) && REGNO (op1) == REGNO (reg))
 return false;
   return true;
@@ -786,4 +786,3 @@ ix86_macro_fusion_pair_p (rtx_insn *condgen, rtx_insn 
*condjmp)
 
   return true;
 }
-
diff --git a/gcc/config/lm32/lm32.cc b/gcc/config/lm32/lm32.cc
index 15728969fad..9ec756cd478 100644
--- a/gcc/config/lm32/lm32.cc
+++ b/gcc/config/lm32/lm32.cc
@@ -831,7 +831,7 @@ lm32_builtin_va_start (tree valist, rtx nextarg)
 
 /*
  * This was copied from "standard" implementation of va_arg, and then
- * handling for overflow of the register paramters added
+ * handling for overflow of the register parameters added.
  */
 
 static tree
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 583d0496364..a839ad6d28a 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -2025,7 +2025,7 @@ extern GTY(()) struct saved_scope *scope_chain;
 #define processing_omp_trait_property_expr 
scope_chain->x_processing_omp_trait_property_expr
 
 /* Nonzero if we are parsing the conditional expression of a contract
-   condition. These expressions appear outside the paramter list (like a
+   condition. These expressions appear outside the parameter list (like a
trailing return type), but are potentially evaluated.  */
 
 #define processing_contract_condition 
scope_chain->x_processing_contract_condition
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 69c27aa7b6e..171ea2c81e0 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -32296,7 +32296,7 @@ cp_parser_requires_expression (cp_parser *parser)
 
   tree parms, reqs;
   {
-/* Local parameters are delared as variables within the scope
+/* Local parameters are declared as variables within the scope
of the expression.  They are not visible past the end of
the expression.  Expressions within the requires-expression
are unevaluated.  */
diff --git a/gcc/rust/rust-diagnostics.h b/gcc/rust/rust-diagnostics.h
index 42f3ba7fc6d..a13dc6a2eaf 100644
--- a/gcc/rust/rust-diagnostics.h
+++ b/gcc/rust/rust-diagnostics.h
@@ -25,7 +25,7 @@
 #include "util/optional.h"
 
 // This macro is used to specify the position of format string & it's
-// arguments within the function's paramter list.
+// arguments within the function's parameter list.
 // 'm' specifies the position of the format string parameter.
 // 'n' specifies the position of the first argument for the format string.
 #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 1)
diff --git a/gcc/testsuite/gcc.target/powerpc/ppc64-abi-1.c 
b/gcc/testsuite/gcc.target/powerpc/ppc64-abi-1.c
index 731c0d880aa..4a3329042bc 100644
--- a/gcc/testsuite/gcc.target/powerpc/ppc64-abi-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/ppc64-abi-1.c
@@ -102,7 +102,7 @@ typedef struct sf
 } stack_frame_t;
 
 
-/* Paramter passing.
+/* Parameter passing.
s : gpr 3
l : gpr 4
d : fpr 1
@@ -124,7 +124,7 @@ void __attribute__ ((noinline)) fcld_check (char *s, long 
l, double d)
 abort ();
 }
 
-/* Paramter passing.
+/* Parameter passing.
s : gpr 3
l : gpr 4
d : fpr 2
@@ -152,7 +152,7 @@ fcldi_check (char *s, long l, double 

[PATCH] Fortran: improve checking of substring bounds [PR119118]

[Harald Anlauf]

Dear all,

this patch fixes an interesting regression that prevented substring
bounds checks from being generated if the substring start was not a
variable, but rather a constant or an expression.

The fix I chose turned out to be a little larger than I anticipated:
handling the case of an expression being used needs scanning for
implied-do indices.  See attached patch for details.

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

Thanks,
Harald

From c100ca04bb5b540732837d92f67529212a7c0899 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Thu, 6 Mar 2025 21:45:42 +0100
Subject: [PATCH] Fortran: improve checking of substring bounds [PR119118]

After the fix for pr98490 no substring bounds check was generated if the
substring start was not a variable.  While the purpose of that fix was to
suppress a premature check before implied-do indices were substituted, this
prevented a check if the substring start was an expression or a constant.
A better solution is to defer the check until implied-do indices have been
substituted in the start and end expressions.

	PR fortran/119118

gcc/fortran/ChangeLog:

	* dependency.cc (gfc_contains_implied_index_p): Helper function to
	determine if an expression has a dependence on an implied-do index.
	* dependency.h (gfc_contains_implied_index_p): Add prototype.
	* trans-expr.cc (gfc_conv_substring): Adjust logic to not generate
	substring bounds checks before implied-do indices have been
	substituted.

gcc/testsuite/ChangeLog:

	* gfortran.dg/bounds_check_23.f90: Generalize test.
	* gfortran.dg/bounds_check_26.f90: New test.
---
 gcc/fortran/dependency.cc | 81 +++
 gcc/fortran/dependency.h  |  1 +
 gcc/fortran/trans-expr.cc |  4 +-
 gcc/testsuite/gfortran.dg/bounds_check_23.f90 | 18 -
 gcc/testsuite/gfortran.dg/bounds_check_26.f90 | 24 ++
 5 files changed, 125 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/bounds_check_26.f90

diff --git a/gcc/fortran/dependency.cc b/gcc/fortran/dependency.cc
index 6b3affa6057..9f1ff574545 100644
--- a/gcc/fortran/dependency.cc
+++ b/gcc/fortran/dependency.cc
@@ -1888,6 +1888,87 @@ contains_forall_index_p (gfc_expr *expr)
   return false;
 }
 
+
+/* Traverse expr, checking all EXPR_VARIABLE symbols for their
+   implied_index attribute.  Return true if any variable may be
+   being used as an implied-do index.  Its safe to pessimistically
+   return true, and assume a dependency.  */
+
+bool
+gfc_contains_implied_index_p (gfc_expr *expr)
+{
+  gfc_actual_arglist *arg;
+  gfc_constructor *c;
+  gfc_ref *ref;
+  int i;
+
+  if (!expr)
+return false;
+
+  switch (expr->expr_type)
+{
+case EXPR_VARIABLE:
+  if (expr->symtree->n.sym->attr.implied_index)
+	return true;
+  break;
+
+case EXPR_OP:
+  if (gfc_contains_implied_index_p (expr->value.op.op1)
+	  || gfc_contains_implied_index_p (expr->value.op.op2))
+	return true;
+  break;
+
+case EXPR_FUNCTION:
+  for (arg = expr->value.function.actual; arg; arg = arg->next)
+	if (gfc_contains_implied_index_p (arg->expr))
+	  return true;
+  break;
+
+case EXPR_CONSTANT:
+case EXPR_NULL:
+case EXPR_SUBSTRING:
+  break;
+
+case EXPR_STRUCTURE:
+case EXPR_ARRAY:
+  for (c = gfc_constructor_first (expr->value.constructor);
+	   c; gfc_constructor_next (c))
+	if (gfc_contains_implied_index_p (c->expr))
+	  return true;
+  break;
+
+default:
+  gcc_unreachable ();
+}
+
+  for (ref = expr->ref; ref; ref = ref->next)
+switch (ref->type)
+  {
+  case REF_ARRAY:
+	for (i = 0; i < ref->u.ar.dimen; i++)
+	  if (gfc_contains_implied_index_p (ref->u.ar.start[i])
+	  || gfc_contains_implied_index_p (ref->u.ar.end[i])
+	  || gfc_contains_implied_index_p (ref->u.ar.stride[i]))
+	return true;
+	break;
+
+  case REF_COMPONENT:
+	break;
+
+  case REF_SUBSTRING:
+	if (gfc_contains_implied_index_p (ref->u.ss.start)
+	|| gfc_contains_implied_index_p (ref->u.ss.end))
+	  return true;
+	break;
+
+  default:
+	gcc_unreachable ();
+  }
+
+  return false;
+}
+
+
 /* Determines overlapping for two single element array references.  */
 
 static gfc_dependency
diff --git a/gcc/fortran/dependency.h b/gcc/fortran/dependency.h
index 3f81d406082..2fc2e567a4c 100644
--- a/gcc/fortran/dependency.h
+++ b/gcc/fortran/dependency.h
@@ -41,6 +41,7 @@ bool gfc_dep_resolver (gfc_ref *, gfc_ref *, gfc_reverse *,
 		  bool identical = false);
 bool gfc_are_equivalenced_arrays (gfc_expr *, gfc_expr *);
 bool gfc_omp_expr_prefix_same (gfc_expr *, gfc_expr *);
+bool gfc_contains_implied_index_p (gfc_expr *);
 
 gfc_expr * gfc_discard_nops (gfc_expr *);
 
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index fbe7333fd71..d965539f11e 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -2814,8 +2814,8 @@ gfc_conv_substring (gfc_se * se, gfc_ref * ref, int kind

Re: [wwwdocs] gcc-15/changes: Mention the new -mveclibabi=aocl option in the IA-32/x86-64 section

[Gerald Pfeifer]

On Thu, 6 Mar 2025, Filip Kastl wrote:
> I would like to gently ping this.

Ooops, sorry.

> > +  GCC now supports generating vectorized math calls to the math library
> > +from AMD Optimizing CPU Libraries (AOCL LibM). This option is available
> > +through the -mveclibabi=aocl compiler switch. GCC 
> > continues to
> > +support generating calls to AMD Core Math Library (ACML). However, that
> > +library is end-of-life and AOCL offers many more vectorized functions.
> > +  

This is fine, though I suggest to work out a bit more clearly what the 
default is. I guess it's neither of these two, unless... ?

And one specific suggestion (which you may opt to implement or not): How 
about "GCC still supports generating" to avoid having three verb forms in
sequence (which made my head hurt a bit ;-)?

Gerald

Re: [PATCH 2/4] c++/modules: Track module purview for deferred instantiations [PR114630]

[Jason Merrill]

On 3/5/25 7:54 AM, Nathaniel Shead wrote:

On Wed, Feb 26, 2025 at 10:29:59AM -0500, Jason Merrill wrote:

On 2/21/25 6:05 AM, Nathaniel Shead wrote:

After seeing PR c++/118964 I'm coming back around to this [1] patch
series, since it appears that this can cause errors on otherwise valid
code by instantiations coming into module purview that reference
TU-local entities.

[1]: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650324.html

We'd previously discussed that the best way to solve this in general
would be to perform all deferred instantiations at the end of the GMF to
ensure that they would not leak into the module purview.  I still
tentatively agree that this would be the "nicer" way to go (though I've
since come across https://eel.is/c++draft/temp.point#7 and wonder if
this may not be strictly conforming according to the current wording?).


Hmm, interesting point.


I've not yet managed to implement this however, and even if I had, at
this stage it would definitely not be appropriate for GCC15; would the
approach described below be appropriate for GCC15 as a stop-gap to
reduce these issues?


As I suggested earlier in this discussion, it seems to me that the
purviewness of an implicit instantiation shouldn't matter, they should all
be treated as discardable.


So looking further I believe that currently they are not, in that
implicit instantiations themselves are only ever emitted if they are
reached from elsewhere (regardless of their purviewness), so the issues
are mostly just with deferred explicit instantiations etc.  However...


Could we instead set DECL_MODULE_PURVIEW_P as appropriate when we see an
explicit instantiation and use that + DECL_EXPLICIT_INSTANTIATION to
recompute module_kind?


As in the attached, which works for me.  Do you see a problem with this 
approach?



Or go with this patch but only look at the saved module_kind if
DECL_EXPLICIT_INSTANTIATION, but that seems a bit of a waste of space. Might
be safer at this point, though.


Part of the issue is handling things that are "implicit instantiations"
that we don't track were as such; the obvious case here is friend decls,
which get instantiated with the current purviewness but might only have
been instantiated due to a deferred implicit instantiation, and for
which we remove any evidence that they were created due to an implicit
instantiation.

So maybe looking at the problem from that side would also work, but I'm
not sure exactly how best to do that just yet.


Another approach would be to maybe lower the error to a permerror, so
that users that 'know better' could compile such modules anyway (at risk
of various link errors and ODR issues), though I would also need to
adjust the streaming logic to handle this better.  Thoughts?


This also sounds desirable.  With a warning flag so it can be disabled for
certain deliberate cases like the gthr stuff.


OK, I'll try and took a look if I get a chance (unfortunately life has
interrupted me again for the time being...).  I'm not sure that this
would work for the gthr case though (since the error occurs at the point
of use not at the point of declaration); for that we would probably need
some kind of attribute I guess?


We frequently use warning_enabled_at to suppress a diagnostic based on 
whether the diagnostic is enabled at the point of definition of some entity.


JasonFrom c4b03fed1b6f1bad193a90ddfc64b175fdb92f7b Mon Sep 17 00:00:00 2001
From: Jason Merrill 
Date: Thu, 6 Mar 2025 12:39:36 -0500
Subject: [PATCH] c++/modules: purview of explicit instantiations [PR114630]
To: gcc-patches@gcc.gnu.org

When calling instantiate_pending_templates at end of parsing, any new
functions that are instantiated from this point have their module
purview set based on the current value of module_kind.

This is unideal, however, as the modules code will then treat these
instantiations as reachable and cause large swathes of the GMF to be
emitted into the module CMI, despite no code in the actual module
purview referencing it.

This patch fixes this by setting DECL_MODULE_PURVIEW_P as appropriate when
we see an explicit instantiation, and adjusting module_kind accordingly
during deferred instantiation, meaning that GMF entities won't be counted
as reachable unless referenced by an actually reachable entity.

Note that purviewness and attachment etc. is generally only determined
by the base template: this is purely for determining whether an
explicit instantiation is in the module purview and hence whether it
should be streamed out.  See the comment on 'set_instantiating_module'.

	PR c++/114630
	PR c++/114795

gcc/cp/ChangeLog:

	* pt.cc (reopen_tinst_level): Set or clear MK_PURVIEW.
	(mark_decl_instantiated): Call set_instantiating_module.

gcc/testsuite/ChangeLog:

	* g++.dg/modules/gmf-3.C: New test.
	* g++.dg/modules/gmf-4.C: New test.

Signed-off-by: Nathaniel Shead 
Co-authored-by: Nathaniel Shead 
---
 gcc/cp/pt.cc | 12 +++-
 gcc/testsuite/g++.dg

Re: [Ping, Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

[Steve Kargl]

Andre,

Here's a bit of wordsmith.  I removed the abbreviation "Esp."
I'm not sure if there is additional markup needed; especially,
with the "-fcoarray=single" I inserted.

  Coarray support has been reworked to allow access to components
  in derived types that have not been compiled with coarray support
  enabled; especially, when the derived type is in a binary only
  module.  This has changed the ABI and may lead to link-time errors
  with libraries compiled with a previous GCC version and the
  -fcoarray=single option.  If this option has been used, it is
  recommended to recompile the libraries.  The OpenCoarrays library
  is not affected, because it provides support backwards compatibility
  with the older ABI.

I'm not sure how to test the change.

OK to commit with or without my suggested change.

-- 
steve


On Thu, Mar 06, 2025 at 03:42:43PM +0100, Andre Vehreschild wrote:
> PING!
> 
> On Thu, 20 Feb 2025 10:54:30 +0100
> Andre Vehreschild  wrote:
> 
> > Hi all,
> >
> > attached patch makes an attempt to announce the ABI-changes in the coarrays
> > library. Me being German always has difficulties to find a proper wording. 
> > So
> > please propose improvements.
> >
> > Stupid question: How to I test this? The change looks good in my browser. Is
> > there a style checker, I don't see?
> >
> > Regards,
> > Ande
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
> 
> 
> --
> Andre Vehreschild * Email: vehre ad gmx dot de

> From 8b1ba25dd27c89dc6ff860835431e09f3895a4e1 Mon Sep 17 00:00:00 2001
> From: Andre Vehreschild 
> Date: Thu, 20 Feb 2025 10:47:22 +0100
> Subject: [PATCH] gcc-15/changes: Document coarray changes.
> 
> ABI of coarrays has changed.  Document possible linker errors for
> caf_single.
> ---
>  htdocs/gcc-15/changes.html | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
> index 853fad03..ea1e7553 100644
> --- a/htdocs/gcc-15/changes.html
> +++ b/htdocs/gcc-15/changes.html
> @@ -436,6 +436,12 @@ asm (".text; %cc0: mov %cc2, %%r0; .previous;"
>incompatible with the module format generated by GCC 8 - 14, but GCC
>15 can for compatibility still read GCC 8 - 14 created module
>files.
> +  Coarray support has been reworked to allow access to data in derived 
> types
> +  that have not been compiled with coarray support enabled.  Esp. when 
> the
> +  derived type is in a binary only module.  This may lead to linking 
> errors
> +  with the provided caf_single-libraries of previous GCC versions.  It is
> +  recommended to only use the newest version of caf_single.  The 
> OpenCoarrays
> +  library is not affected and provides all ABIs.
>  
> 
>  
> --
> 2.48.1
> 


-- 
Steve

Re: [Ping, Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

[Jerry D]

On 3/6/25 10:02 AM, Steve Kargl wrote:

Andre,

Here's a bit of wordsmith.  I removed the abbreviation "Esp."
I'm not sure if there is additional markup needed; especially,
with the "-fcoarray=single" I inserted.

   Coarray support has been reworked to allow access to components
   in derived types that have not been compiled with coarray support
   enabled; especially, when the derived type is in a binary only
   module.  This has changed the ABI and may lead to link-time errors
   with libraries compiled with a previous GCC version and the
   -fcoarray=single option.  If this option has been used, it is
   recommended to recompile the libraries.  The OpenCoarrays library
   is not affected, because it provides support backwards compatibility
   with the older ABI.

I'm not sure how to test the change.

OK to commit with or without my suggested change.



For www-docs there is an html check script provided. You can also review 
by looking with a web browser.


For texi files, if make info succeeds and review the resulting info 
files installed in the usr/share if I recall correctly.


Jerry

Re: [PUSHED] libstdc++: Avoid '-Wunused-parameter' for '__what' in function 'void std::__throw_format_error(const char*)'

[Jonathan Wakely]

On Thu, 6 Mar 2025 at 14:28, Thomas Schwinge wrote:
>
> In a '-fno-exceptions' configuration:
>
> In file included from 
> ../../../../../source-gcc/libstdc++-v3/src/c++20/format.cc:29:
> [...]/build-gcc/[...]/libstdc++-v3/include/format: In function ‘void 
> std::__throw_format_error(const char*)’:
> [...]/build-gcc/[...]/libstdc++-v3/include/format:200:36: error: unused 
> parameter ‘__what’ [-Werror=unused-parameter]
>   200 |   __throw_format_error(const char* __what)
>   |^~
>
> libstdc++-v3/
> * include/bits/c++config [!__cpp_exceptions]
> (_GLIBCXX_THROW_OR_ABORT): Reference '_EXC'.
>
> Co-authored-by: Jonathan Wakely 

Hmm, I didn't like this change (my original review said "I don't think
we want/need this at all, but it could be done like this...") and it
turns out that it causes diagnostic regressions. The problem is in the
front-end so I've filed it as https://gcc.gnu.org/PR119149

I think we can live with the diagnostic regressions, since it's only
for code that's ill-formed anyway, and only for -fno-exceptions.

[r15-7853 Regression] FAIL: 26_numerics/complex/tuple_like.cc -std=gnu++26 (test for excess errors) on Linux/x86_64

[haochen.jiang]

On Linux/x86_64,

de231924b73bc120bf2b7ada4eeccd884c249ee1 is the first bad commit
commit de231924b73bc120bf2b7ada4eeccd884c249ee1
Author: Giuseppe D'Angelo 
Date:   Thu Feb 27 22:47:27 2025 +0100

libstdc++: implement tuple protocol for std::complex (P2819R2)

caused

FAIL: 26_numerics/complex/tuple_like.cc  -std=gnu++26 (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-7853/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check 
RUNTESTFLAGS="conformance.exp=26_numerics/complex/tuple_like.cc 
--target_board='unix{-m32}'"
$ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check 
RUNTESTFLAGS="conformance.exp=26_numerics/complex/tuple_like.cc 
--target_board='unix{-m32\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at haochen dot jiang at intel.com.)
(If you met problems with cascadelake related, disabling AVX512F in command 
line might save that.)
(However, please make sure that there is no potential problems with AVX512.)

Re: [PUSHED] libstdc++: Avoid '-Wunused-parameter' for '__what' in function 'void std::__throw_format_error(const char*)'

[Jonathan Wakely]

On Thu, 6 Mar 2025 at 19:48, Jonathan Wakely wrote:
>
> On Thu, 6 Mar 2025 at 14:28, Thomas Schwinge wrote:
> >
> > In a '-fno-exceptions' configuration:
> >
> > In file included from 
> > ../../../../../source-gcc/libstdc++-v3/src/c++20/format.cc:29:
> > [...]/build-gcc/[...]/libstdc++-v3/include/format: In function ‘void 
> > std::__throw_format_error(const char*)’:
> > [...]/build-gcc/[...]/libstdc++-v3/include/format:200:36: error: unused 
> > parameter ‘__what’ [-Werror=unused-parameter]
> >   200 |   __throw_format_error(const char* __what)
> >   |^~
> >
> > libstdc++-v3/
> > * include/bits/c++config [!__cpp_exceptions]
> > (_GLIBCXX_THROW_OR_ABORT): Reference '_EXC'.
> >
> > Co-authored-by: Jonathan Wakely 
>
> Hmm, I didn't like this change (my original review said "I don't think
> we want/need this at all, but it could be done like this...") and it
> turns out that it causes diagnostic regressions. The problem is in the
> front-end so I've filed it as https://gcc.gnu.org/PR119149

Which seems to be a dup of my own much older https://gcc.gnu.org/PR91388

> I think we can live with the diagnostic regressions, since it's only
> for code that's ill-formed anyway, and only for -fno-exceptions.