Re: [PATCH] libgomp: Update SVE tests

[Jakub Jelinek]

On Thu, Apr 10, 2025 at 05:13:12PM +0530, Tejas Belagod wrote:
> Thanks for the explanation.  I looked into why some of the tests may have
> failed - my flawed understanding of the reduction clause was why I didn't
> have the += in the loops - it might have passed for me as I probably hit the
> exact omp_get_num_threads () number required for the final += reductions to
> trigger from the declare clause.  As Richard said, the += in the loops ought
> to fix the tests. I'm still analysing inscan_reduction_incl () to fix it
> properly.

For scan think about
  scan_a = 0;
#pragma omp parallel for reduction(inscan, +:scan_a)
  for (int i = 0; i < N; i++)
{
  simd_scan[i] = scan_a;
  #pragma omp scan exclusive(scan_a)
  scan_a += a[i];
}
and
  scan_a = 0;
#pragma omp parallel reduction(inscan, +:scan_a)
  for (int i = 0; i < N; i++)
{
  scan_a += a[i];
  #pragma omp scan inclusive(scan_a)
  simd_scan[i] = scan_a;
}
The directives arrange for the parallel version to compute the
same thing as the serial loops without the directives (at least
say for unsigned types, for signed or floating point it can
reassociate the additions (or whatever the reduction operation is).
OpenMP effectively breaks those halves of the loop bodies apart and
does magic in between.

Jakub

[Fortran, Patch, Teams, 5/5] Add teams support in image_index and num_images for F2018

[Andre Vehreschild]

Hi all,

attached patch reworks the NUM_IMAGES() implementation to adhere to the Fortran
2018 standard.

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

Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 1d0262dc068f4c6018d669a88387dbb7baaff39a Mon Sep 17 00:00:00 2001
From: Andre Vehreschild 
Date: Thu, 3 Apr 2025 10:11:50 +0200
Subject: [PATCH 5/6] Fortran: Add teams support in image_index and num_images
 for F2018

This more or less completes the set of functions that are affected by
teams.

gcc/fortran/ChangeLog:

	* check.cc (gfc_check_image_index): Check for team or
	team_number correctnes.
	(gfc_check_num_images): Same.
	* gfortran.texi: Update documentation on num_images' API
	function.
	* intrinsic.cc (add_functions): Update signature of image_index
	and num_images.  Both can take either a team handle or number.
	* intrinsic.h (gfc_check_num_images): Update signature to take
	either team or team_number.
	(gfc_check_image_index): Can take coarray, subscripts and team
	or team number now.
	(gfc_simplify_image_index): Same.
	(gfc_simplify_num_images): Same.
	(gfc_resolve_image_index): Same.
	* intrinsic.texi: Update documentation of num_images() Fortran
	function.
	* iresolve.cc (gfc_resolve_image_index): Update signature.
	* simplify.cc (gfc_simplify_num_images): Update signature and
	remove undocumented failed argument.
	(gfc_simplify_image_index): Add team or team number argument.
	* trans-intrinsic.cc (conv_stat_and_team): Because being
	optional teams need to be a pointer to the opaque pointer.
	(conv_caf_sendget): Correct call; was two arguments short.
	(trans_image_index): Support team or team_number.
	(trans_num_images): Same.
	(conv_intrinsic_cobound): Adapt to changed signature of
	num_images in call.
	* trans-stmt.cc (gfc_trans_sync): Same.

libgfortran/ChangeLog:

	* caf/libcaf.h (_gfortran_caf_num_images): Correct prototype.
	* caf/single.c (_gfortran_caf_num_images): Default
	implementation.

gcc/testsuite/ChangeLog:

	* gfortran.dg/coarray_49.f90: Adapt to changed error message.
	* gfortran.dg/coarray_collectives_12.f90: Adapt to changed
	function signature of num_images.
	* gfortran.dg/coarray_collectives_16.f90: Same.
	* gfortran.dg/coarray_lib_this_image_1.f90: Same.
	* gfortran.dg/coarray_lib_this_image_2.f90: Same.
	* gfortran.dg/coarray_this_image_1.f90: Adapt tests for
	num_images.
	* gfortran.dg/coarray_this_image_2.f90: Same.
	* gfortran.dg/coarray_this_image_3.f90: Same.
	* gfortran.dg/num_images_1.f90: Check that deprecated syntax is
	no longer supported.
---
 gcc/fortran/check.cc  | 63 --
 gcc/fortran/gfortran.texi | 26 
 gcc/fortran/intrinsic.cc  | 55 
 gcc/fortran/intrinsic.h   | 10 +--
 gcc/fortran/intrinsic.texi| 45 ++---
 gcc/fortran/iresolve.cc   |  3 +-
 gcc/fortran/simplify.cc   | 12 +---
 gcc/fortran/trans-intrinsic.cc| 66 +++
 gcc/fortran/trans-stmt.cc |  3 +-
 gcc/testsuite/gfortran.dg/coarray_49.f90  |  2 +-
 .../gfortran.dg/coarray_collectives_12.f90|  2 +-
 .../gfortran.dg/coarray_collectives_16.f90|  2 +-
 .../gfortran.dg/coarray_lib_this_image_1.f90  |  2 +-
 .../gfortran.dg/coarray_lib_this_image_2.f90  |  2 +-
 .../gfortran.dg/coarray_this_image_1.f90  | 14 ++--
 .../gfortran.dg/coarray_this_image_2.f90  | 16 ++---
 .../gfortran.dg/coarray_this_image_3.f90  | 15 ++---
 gcc/testsuite/gfortran.dg/num_images_1.f90|  2 +-
 libgfortran/caf/libcaf.h  |  2 +-
 libgfortran/caf/single.c  |  4 +-
 20 files changed, 171 insertions(+), 175 deletions(-)

diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index c27f653d3b0..356e0d7f678 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -6565,7 +6565,8 @@ gfc_check_stat_sub (gfc_expr *name, gfc_expr *array, gfc_expr *status)


 bool
-gfc_check_image_index (gfc_expr *coarray, gfc_expr *sub)
+gfc_check_image_index (gfc_expr *coarray, gfc_expr *sub,
+		   gfc_expr *team_or_team_number)
 {
   mpz_t nelems;

@@ -6585,12 +6586,8 @@ gfc_check_image_index (gfc_expr *coarray, gfc_expr *sub)
   return false;
 }

-  if (sub->ts.type != BT_INTEGER)
-{
-  gfc_error ("Type of %s argument of IMAGE_INDEX at %L shall be INTEGER",
-		 gfc_current_intrinsic_arg[1]->name, &sub->where);
-  return false;
-}
+  if (!type_check (sub, 1, BT_INTEGER))
+return false;

   if (gfc_array_size (sub, &nelems))
 {
@@ -6605,12 +6602,23 @@ gfc_check_image_index (gfc_expr *coarray, gfc_expr *sub)
   mpz_clear (nelems);
 }

+  if (team_or_team_number)
+{
+  if (!type_check2 (team_or_team_number, 2, BT_DERIVED, BT_INTEGER)
+	  || !scalar_check (team_or_team_number, 2))
+	return false;
+
+  /* Check team is of team_type.  */
+  if (team_

[Fortran, Patch, Teams, 0/5] Improve on Fortran 2018 teams support

[Andre Vehreschild]

Hi all,

I again have a series of patches. This time to improve the teams support in
gfortran.

1/5: Improves/Unifies handling of STAT= and ERRMSG= handling, which is part of
all TEAM statements. I wanted to prevent repeating myself over and over so I
factored this out (DRY principle). Because the standard's rule name for this is
sync_stat the structure to store the information in gfc_code is named like that.

2/5: Rework (FORM|CHANGE|END|SYNC) TEAM and CRITICAL to use sync_stat and
adhere to F2018 standard as much as possible. Because CHANGE TEAM has kind of
an association list (but for coarrays only), I choose to factor out that
parsing and other preparations from ASSOCIATE. Added support to caf_single for
testing.

3/5: Update/Implement get_team()/team_number() and image_status() parsing and
also add testcases as well as support in caf_single.

4/5: Update this_image() parsing and treatment as well as adding testcases and
support in caf_single.

5/5: Update image_index() and num_images() support also in caf_single.

All patches together have been bootstrapped and regtested ok on
x86_64-pc-linux-gnu.

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

[Fortran, Patch, Team, 2/5] Improve F2018 TEAM handling [PR87326, PR87556, PR88254, PR103896]

[Andre Vehreschild]

Hi all,

attached patch reworks (FORM|CHANGE|END|SYNC) TEAM to implement the Fortran
2018 as much as possible. This work has been done in sync with enhancing the
OpenCoarrays library. Because CHANGE TEAM has an association list very similar
to ASSOCIATE, the common code has been factored out to implement the DRY
principle.

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

Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 64c951fd2f64f5d4407076532fd57e8370254826 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild 
Date: Mon, 7 Apr 2025 09:36:24 +0200
Subject: [PATCH 2/6] Fortran: Improve F2018 TEAM handling [PR87326, PR87556,
 PR88254, PR103896]

Improve the implementation of F2018 TEAM handling routines. Add
runtime-functions to caf_single to allow testing.

	PR fortran/87326
	PR fortran/87556
	PR fortran/88254
	PR fortran/103796

gcc/fortran/ChangeLog:

	* coarray.cc (split_expr_at_caf_ref): Treat polymorphic types
	correctly.  Ensure resolve of expression after coindex.
	(create_allocated_callback): Fix parameter of allocated function
	for coarrays.
	(coindexed_expr_callback): Improve detection of coarrays in
	allocated function.
	* decl.cc (gfc_match_end): Add team block matching.
	* dump-parse-tree.cc (show_code_node): Dump change team block as
	such.
	* frontend-passes.cc (gfc_code_walker): Recognice team block.
	* gfortran.texi: Add documentation for team api functions.
	* intrinsic.texi: Add documentation about team_type in
	iso_fortran_env module.
	* iso-fortran-env.def (team_type): Use helper to get pointer
	kind.
	* match.cc (gfc_match_associate): Factor out matching of
	association list, because it is used in change team as well.
	(check_coarray_assoc): Ensure, that the association is to a
	coarray.
	(match_association_list): Match a list of association either in
	associate or in change team.
	(gfc_match_form_team): Match form team correctly include
	new_index.
	(gfc_match_change_team): Match change team with association
	list.
	(gfc_match_end_team): Match end team including stat and errmsg.
	(gfc_match_return): Prevent return from team block.
	* parse.cc (decode_statement): Sort team block.
	(next_statement): Same.
	(check_statement_label): Same.
	(accept_statement): Same.
	(verify_st_order): Same.
	(parse_associate): Renamed to move_associates_to_block...
	(move_associates_to_block): ... to enable reuse for change team.
	(parse_change_team): Parse it as block.
	(parse_executable): Same.
	* parse.h (enum gfc_compile_state): Add team block as compiler
	state.
	* resolve.cc (resolve_scalar_argument): New function to resolve
	an argument to a statement as a scalar.
	(resolve_form_team): Resolve its members.
	(resolve_change_team): Same.
	(resolve_branch): Prevent branch from jumping out of team block.
	(check_team): Removed.
	* trans-decl.cc (gfc_build_builtin_function_decls): Add stat and
	errmsg to team API functions and update their arguments.
	* trans-expr.cc (gfc_trans_subcomponent_assign): Also null the
	token when moving memory or an allocated() will not detect a
	free.
	* trans-intrinsic.cc (gfc_conv_intrinsic_caf_is_present_remote):
	Adapt to signature change no longer a pointer-pointer.
	* trans-stmt.cc (gfc_trans_form_team): Translate a form team
	including new_index.
	(gfc_trans_change_team): Translate a change team as a block.

libgfortran/ChangeLog:

	* caf/libcaf.h: Remove commented block.
	(_gfortran_caf_form_team): Allow for all relevant arguments.
	(_gfortran_caf_change_team): Same.
	(_gfortran_caf_end_team): Same.
	(_gfortran_caf_sync_team): Same.
	* caf/single.c (struct caf_single_team): Team handling
	structures.
	(_gfortran_caf_init): Initialize initial team.
	(free_team_list): Free all teams and the memory they hold.
	(_gfortran_caf_finalize): Free initial and sibling teams.
	(_gfortran_caf_register): Add memory registered to current team.
	(_gfortran_caf_deregister): Unregister memory from current team.
	(_gfortran_caf_is_present_on_remote): Check token's memptr for
	llocation.  May have been deallocated by an end team.
	(_gfortran_caf_form_team): Push a new team stub to the list.
	(_gfortran_caf_change_team): Push a formed team on top of the
	ctive teams stack.
	(_gfortran_caf_end_team): End the active team, free all memory
	allocated during its livespan.
	(_gfortran_caf_sync_team): Take stat and errmsg into account.

gcc/testsuite/ChangeLog:

	* gfortran.dg/team_change_2.f90: New test.
	* gfortran.dg/team_change_3.f90: New test.
	* gfortran.dg/team_end_2.f90: New test.
	* gfortran.dg/team_end_3.f90: New test.
	* gfortran.dg/team_form_2.f90: New test.
	* gfortran.dg/team_form_3.f90: New test.
	* gfortran.dg/team_sync_2.f90: New test.
---
 gcc/fortran/coarray.cc  |  12 +-
 gcc/fortran/decl.cc |  20 +-
 gcc/fortran/dump-parse-tree.cc  |  30 ++-
 gcc/fortran/frontend-passes.cc  |   1 +
 gcc/fortran/gfortran.texi   | 146 +-
 gcc/fortran/intrinsic.texi

[PATCH] riscv: Fix incorrect gnu property alignment on rv32

[Jesse Huang]

Codegen is incorrectly emitting a ".p2align 3" that coerces the
alignment of the .note.gnu.property section from 4 to 8 on rv32.
---
 gcc/config/riscv/riscv.cc  |  2 +-
 gcc/testsuite/gcc.target/riscv/gnu-property-rv32.c | 12 
 gcc/testsuite/gcc.target/riscv/gnu-property-rv64.c | 12 
 3 files changed, 25 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/gnu-property-rv32.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/gnu-property-rv64.c

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 38f3ae7cd84..d3656a7a430 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -10382,7 +10382,7 @@ riscv_file_end ()
   fprintf (asm_out_file, "1:\n");
 
   /* pr_type.  */
-  fprintf (asm_out_file, "\t.p2align\t3\n");
+  fprintf (asm_out_file, "\t.p2align\t%u\n", p2align);
   fprintf (asm_out_file, "2:\n");
   fprintf (asm_out_file, "\t.long\t0xc000\n");
   /* pr_datasz.  */
diff --git a/gcc/testsuite/gcc.target/riscv/gnu-property-rv32.c 
b/gcc/testsuite/gcc.target/riscv/gnu-property-rv32.c
new file mode 100644
index 000..d0c01d8cb99
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/gnu-property-rv32.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv32g_zicfiss -fcf-protection=return -mabi=ilp32d " { 
target { rv32 } } } */
+/* { dg-options "-march=rv32gc_zicfiss -fcf-protection=return -mabi=ilp32d " { 
target { rv32 } } } */
+/* { dg-options "-march=rv32g_zicfilp -fcf-protection=branch -mabi=ilp32d " { 
target { rv32 } } } */
+/* { dg-options "-march=rv32gc_zicfilp -fcf-protection=branch -mabi=ilp32d " { 
target { rv32 } } } */
+/* { dg-options "-march=rv32g_zicfiss_zicfilp -fcf-protection=full 
-mabi=ilp32d " { target { rv32 } } } */
+/* { dg-options "-march=rv32gc_zicfiss_zicfilp -fcf-protection=full 
-mabi=ilp32d " { target { rv32 } } } */
+
+void foo() {}
+
+/* { dg-final { scan-assembler-times ".p2align\t2" 3 } } */
+/* { dg-final { scan-assembler-not ".p2align\t3" } } */
diff --git a/gcc/testsuite/gcc.target/riscv/gnu-property-rv64.c 
b/gcc/testsuite/gcc.target/riscv/gnu-property-rv64.c
new file mode 100644
index 000..25847ba410a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/gnu-property-rv64.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64g_zicfiss -fcf-protection=return -mabi=lp64d " { 
target { rv64 } } } */
+/* { dg-options "-march=rv64gc_zicfiss -fcf-protection=return -mabi=lp64d " { 
target { rv64 } } } */
+/* { dg-options "-march=rv64g_zicfilp -fcf-protection=branch -mabi=lp64d " { 
target { rv64 } } } */
+/* { dg-options "-march=rv64gc_zicfilp -fcf-protection=branch -mabi=lp64d " { 
target { rv64 } } } */
+/* { dg-options "-march=rv64g_zicfiss_zicfilp -fcf-protection=full -mabi=lp64d 
" { target { rv64 } } } */
+/* { dg-options "-march=rv64gc_zicfiss_zicfilp -fcf-protection=full 
-mabi=lp64d " { target { rv64 } } } */
+
+void foo() {}
+
+/* { dg-final { scan-assembler-times ".p2align\t3" 3 } } */
+/* { dg-final { scan-assembler-not ".p2align\t2" } } */
-- 
2.39.3

[pushed] Darwin: Add spec substitution for static-libgcobol.

[Iain Sandoe]

Tested on x86_64 Darwin, Linux, pushed to trunk, thanks
Iain

--- 8< ---

This just follows the common pattern used for other runtime libs.

gcc/ChangeLog:

* config/darwin.h (LINK_SPEC): Add support for
-static-libgcobol.

Signed-off-by: Iain Sandoe 
---
 gcc/config/darwin.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
index 8c164fd4b75..9b9a3fe4038 100644
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@ -504,6 +504,7 @@ extern GTY(()) int darwin_ms_struct;
%{static|static-libgcc|static-libgfortran:%:replace-outfile(-lgfortran 
libgfortran.a%s)}\
%{static|static-libgcc|static-libquadmath:%:replace-outfile(-lquadmath 
libquadmath.a%s)}\
%{static|static-libgcc|static-libphobos:%:replace-outfile(-lgphobos 
libgphobos.a%s)}\
+   %{static|static-libgcc|static-libgcobol:%:replace-outfile(-lgcobol 
libgcobol.a%s)}\

%{static|static-libgcc|static-libstdc++|static-libgfortran:%:replace-outfile(-lgomp
 libgomp.a%s)}\
%{static|static-libgcc|static-libstdc++:%:replace-outfile(-lstdc++ 
libstdc++.a%s)}\
%{static|static-libgm2:%:replace-outfile(-lm2pim libm2pim.a%s)}\
-- 
2.39.2 (Apple Git-143)

Re: [PATCH] testsuite: Add support for GCOV_UNDER_TEST

[Hans-Peter Nilsson]

> From: Christophe Lyon 
> Date: Thu, 10 Apr 2025 15:21:23 +0200

Not sure why I'm CC:ed on this one, not being a maintainer
of the testsuite or targets where gcov tests are exercised,
but FWIW: LGTM except for the two nits:

> ping?
> 
> On Tue, 1 Apr 2025 at 22:37, Christophe Lyon  
> wrote:
> > diff --git a/gcc/testsuite/g++.dg/gcov/gcov.exp 
> > b/gcc/testsuite/g++.dg/gcov/gcov.exp
> > index 50f60c4a011..d85bf125d16 100644
> > --- a/gcc/testsuite/g++.dg/gcov/gcov.exp
> > +++ b/gcc/testsuite/g++.dg/gcov/gcov.exp
> > @@ -21,12 +21,19 @@ load_lib g++-dg.exp
> >  load_lib gcov.exp
> >
> >  global GXX_UNDER_TEST
> > +global GCOV_UNDER_TEST
> >
> > -# Find gcov in the same directory as $GXX_UNDER_TEST.
> > -if { ![is_remote host] && [string match "*/*" [lindex $GXX_UNDER_TEST 0]] 
> > } {
> > -set GCOV [file dirname [lindex $GXX_UNDER_TEST 
> > 0]]/[gcc-transform-out-of-tree gcov]
> > +# Find gcov in the same directory as $GXX_UNDER_TEST. under
> > +# GCOV_UNDER_TEST is defined.

Cutnpasto; s/. under/, unless/?

> > diff --git a/gcc/testsuite/gnat.dg/gcov/gcov.exp 
> > b/gcc/testsuite/gnat.dg/gcov/gcov.exp
> > index 4fa887d5bad..d5977a85e8a 100644
> > --- a/gcc/testsuite/gnat.dg/gcov/gcov.exp
> > +++ b/gcc/testsuite/gnat.dg/gcov/gcov.exp

> > +# GCOV_UNDER_TEST is defined..

Extra ".".

brgds, H-p

Re: [PATCH] libgomp: Update SVE tests

[Richard Sandiford]

Tejas Belagod  writes:
> On 4/10/25 5:13 PM, Tejas Belagod wrote:
>> On 4/9/25 4:13 PM, Jakub Jelinek wrote:
>>> On Wed, Apr 09, 2025 at 04:01:49PM +0530, Tejas Belagod wrote:
> It also looks like there might be a missing "+" in simd_reduction:
>
>     #pragma omp simd reduction (+:va, i)
>     for (j = 0; j < 16; j++)
>   va = svld1_s32 (svptrue_b32 (), a);
>
>     res = svaddv_s32 (svptrue_b32 (), va);
>
>     if (res != 8)
>   __builtin_abort ();
>
> since AFAICT the loop is not doing a reduction as things stand.
> But perhaps that's deliberate, since it does match the != 8 test.

 That's interesting. I thought the reduction definition in the
 'declare reduction' does the reduction from all the individual 
 interations
 according the the rules defined in the reduction irrespective of the 
 loop
 structure.  Maybe 'va' doesn't become implicit private and causes a race
 (which may be why I didn't see it in my testing) - I'll try to repro 
 this
 and have a look.
>>>
>>> No, reduction privatizes the variable, initializes the private 
>>> variable with
>>> the initializer from UDR and reduces at the end only from all the private
>>> variables to the original one.
>>>
>>> For simd, each SIMD lane has one private copy and there are # SIMD lanes
>>> reductions into the original, for e.g. worksharing constructs each thread
>>> has a private copy and there are omp_get_num_threads () reductions, etc.
>>>
>>> There is no special action at the end of each loop body, it is up to the
>>> user to merge state from each iteration.  In sane code the loop body does
>>> similar operation to what the reduction does.
>>> So say if you have
>>> float sum = 0;
>>> #pragma omp parallel for reduction (+:sum)
>>> for (int i = 0; i < 1024; ++i)
>>>    sum += a[i];
>>> then if OpenMP pragmas are ignored, all the array members
>>> are summed up in that order, while if say there are 4
>>> threads and each handles 256 iterations, then each thread will
>>> start with sum = 0; and do sum += a[i]; for i omp_get_thread_num () * 256
>>> to omp_get_thread_num () * 256 + 255 inclusive and finally in some random
>>> order the 4 private floats will be summed together.
>>> For floating point that can result in different behavior (different 
>>> rounding
>>> etc.) but user said it is ok like that.
>>>
>> 
>> Thanks for the explanation.  I looked into why some of the tests may 
>> have failed - my flawed understanding of the reduction clause was why I 
>> didn't have the += in the loops - it might have passed for me as I 
>> probably hit the exact omp_get_num_threads () number required for the 
>> final += reductions to trigger from the declare clause.  As Richard 
>> said, the += in the loops ought to fix the tests. I'm still analysing 
>> inscan_reduction_incl () to fix it properly.
>
> Sorry, forgot to ask - Richard, are you happy for me to work on a 
> separate patch to fix the test alongside your target +sve fix as a 
> couple more functions (eg simd_reduction () and inscan.. () ) also need 
> fixing?

Sure, that's fine with me.  Should I apply the patch, or would you
prefer to wait until your patch is ready?

Richard

Re: [PATCH] testsuite: Add support for GCOV_UNDER_TEST

[Christophe Lyon]

ping?

On Tue, 1 Apr 2025 at 22:37, Christophe Lyon  wrote:
>
> After commit r15-8947-g8ed2d5d219e999, which added new tests using
> gcov, the CI noticed failures because it was calling 'gcov' instead of
> $target-gcov.
>
> This is because the CI scripts override GXX_UNDER_TEST, but still run
> the testsuite in-tree, and gcc-transform-out-of-tree only depends on
> TESTING_IN_BUILD_TREE but the definition of GCOV uses GCC_UNDER_TEST,
> GXX_UNDER_TEST or GDC_UNDER_TEST (assuming their default values when
> TESTING_IN_BUILD_TREE).
>
> To handle such a case, this patch adds support for a new variable,
> GCOV_UNDER_TEST, which overrides the current behavior if defined, and
> has an effect similar to overriding GCC_UNDER_TEST etc...
>
> Unfortunately, the change needs to be duplicated in several places,
> which use either GCC_UNDER_TEST, GXX_UNDER_TEST or GDC_UNDER_TEST.
>
> Tested g++.dg/gcov/gcov.exp and now g++.dg/gcov/gcov-22.C passes
> (calling /bin/$target-gcov as instructed by the CI
> scripts).  No change observed on gcc.misc-tests/gcov.exp, and I could
> not test gdc.dg/gcov.exp and gnat.dg/gcov/gcov.exp.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/gcov/gcov.exp: Handle GCOV_UNDER_TEST.
> * gcc.misc-tests/gcov.exp: Likewise.
> * gdc.dg/gcov.exp: Likewise.
> * gnat.dg/gcov/gcov.exp: Likewise.
> ---
>  gcc/testsuite/g++.dg/gcov/gcov.exp| 15 +++
>  gcc/testsuite/gcc.misc-tests/gcov.exp | 15 +++
>  gcc/testsuite/gdc.dg/gcov.exp | 15 +++
>  gcc/testsuite/gnat.dg/gcov/gcov.exp   | 15 +++
>  4 files changed, 44 insertions(+), 16 deletions(-)
>
> diff --git a/gcc/testsuite/g++.dg/gcov/gcov.exp 
> b/gcc/testsuite/g++.dg/gcov/gcov.exp
> index 50f60c4a011..d85bf125d16 100644
> --- a/gcc/testsuite/g++.dg/gcov/gcov.exp
> +++ b/gcc/testsuite/g++.dg/gcov/gcov.exp
> @@ -21,12 +21,19 @@ load_lib g++-dg.exp
>  load_lib gcov.exp
>
>  global GXX_UNDER_TEST
> +global GCOV_UNDER_TEST
>
> -# Find gcov in the same directory as $GXX_UNDER_TEST.
> -if { ![is_remote host] && [string match "*/*" [lindex $GXX_UNDER_TEST 0]] } {
> -set GCOV [file dirname [lindex $GXX_UNDER_TEST 
> 0]]/[gcc-transform-out-of-tree gcov]
> +# Find gcov in the same directory as $GXX_UNDER_TEST. under
> +# GCOV_UNDER_TEST is defined.
> +
> +if ![info exists GCOV_UNDER_TEST] {
> +if { ![is_remote host] && [string match "*/*" [lindex $GXX_UNDER_TEST 
> 0]] } {
> +   set GCOV [file dirname [lindex $GXX_UNDER_TEST 
> 0]]/[gcc-transform-out-of-tree gcov]
> +} else {
> +   set GCOV [gcc-transform-out-of-tree gcov]
> +}
>  } else {
> -set GCOV [gcc-transform-out-of-tree gcov]
> +set GCOV $GCOV_UNDER_TEST
>  }
>
>  # Initialize harness.
> diff --git a/gcc/testsuite/gcc.misc-tests/gcov.exp 
> b/gcc/testsuite/gcc.misc-tests/gcov.exp
> index c8f20e1e70e..4278b625c0b 100644
> --- a/gcc/testsuite/gcc.misc-tests/gcov.exp
> +++ b/gcc/testsuite/gcc.misc-tests/gcov.exp
> @@ -21,12 +21,19 @@ load_lib gcc-dg.exp
>  load_lib gcov.exp
>
>  global GCC_UNDER_TEST
> +global GCOV_UNDER_TEST
>
> -# For now find gcov in the same directory as $GCC_UNDER_TEST.
> -if { ![is_remote host] && [string match "*/*" [lindex $GCC_UNDER_TEST 0]] } {
> -set GCOV [file dirname [lindex $GCC_UNDER_TEST 
> 0]]/[gcc-transform-out-of-tree gcov]
> +# For now find gcov in the same directory as $GCC_UNDER_TEST, unless
> +# GCOV_UNDER_TEST is defined..
> +
> +if ![info exists GCOV_UNDER_TEST] {
> +if { ![is_remote host] && [string match "*/*" [lindex $GCC_UNDER_TEST 
> 0]] } {
> +   set GCOV [file dirname [lindex $GCC_UNDER_TEST 
> 0]]/[gcc-transform-out-of-tree gcov]
> +} else {
> +   set GCOV [gcc-transform-out-of-tree gcov]
> +}
>  } else {
> -set GCOV [gcc-transform-out-of-tree gcov]
> +set GCOV $GCOV_UNDER_TEST
>  }
>
>  # Initialize harness.
> diff --git a/gcc/testsuite/gdc.dg/gcov.exp b/gcc/testsuite/gdc.dg/gcov.exp
> index a65dd34..3f0234e9f2f 100644
> --- a/gcc/testsuite/gdc.dg/gcov.exp
> +++ b/gcc/testsuite/gdc.dg/gcov.exp
> @@ -21,12 +21,19 @@ load_lib gdc-dg.exp
>  load_lib gcov.exp
>
>  global GDC_UNDER_TEST
> +global GCOV_UNDER_TEST
>
> -# For now find gcov in the same directory as $GDC_UNDER_TEST.
> -if { ![is_remote host] && [string match "*/*" [lindex $GDC_UNDER_TEST 0]] } {
> -set GCOV [file dirname [lindex $GDC_UNDER_TEST 
> 0]]/[gcc-transform-out-of-tree gcov]
> +# For now find gcov in the same directory as $GDC_UNDER_TEST, unless
> +# GCOV_UNDER_TEST is defined.
> +
> +if ![info exists GCOV_UNDER_TEST] {
> +if { ![is_remote host] && [string match "*/*" [lindex $GDC_UNDER_TEST 
> 0]] } {
> +   set GCOV [file dirname [lindex $GDC_UNDER_TEST 
> 0]]/[gcc-transform-out-of-tree gcov]
> +} else {
> +   set GCOV [gcc-transform-out-of-tree gcov]
> +}
>  } else {
> -set GCOV [gcc-transform-out-of-tree gcov]
> +set GCOV $GCOV_UNDER_TEST
>  }
>
>  # Initialize harness.
> diff --git a/gcc/testsuite/gnat.dg/gco

Re: [PATCH] riscv: Fix incorrect gnu property alignment on rv32

[Kito Cheng]

On Thu, Apr 10, 2025 at 9:12 PM Jesse Huang  wrote:
>
> Codegen is incorrectly emitting a ".p2align 3" that coerces the
> alignment of the .note.gnu.property section from 4 to 8 on rv32.
> ---
>  gcc/config/riscv/riscv.cc  |  2 +-
>  gcc/testsuite/gcc.target/riscv/gnu-property-rv32.c | 12 
>  gcc/testsuite/gcc.target/riscv/gnu-property-rv64.c | 12 
>  3 files changed, 25 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gcc.target/riscv/gnu-property-rv32.c
>  create mode 100644 gcc/testsuite/gcc.target/riscv/gnu-property-rv64.c
>
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 38f3ae7cd84..d3656a7a430 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -10382,7 +10382,7 @@ riscv_file_end ()
>fprintf (asm_out_file, "1:\n");
>
>/* pr_type.  */
> -  fprintf (asm_out_file, "\t.p2align\t3\n");
> +  fprintf (asm_out_file, "\t.p2align\t%u\n", p2align);
>fprintf (asm_out_file, "2:\n");
>fprintf (asm_out_file, "\t.long\t0xc000\n");
>/* pr_datasz.  */
> diff --git a/gcc/testsuite/gcc.target/riscv/gnu-property-rv32.c 
> b/gcc/testsuite/gcc.target/riscv/gnu-property-rv32.c
> new file mode 100644
> index 000..d0c01d8cb99
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/gnu-property-rv32.c
> @@ -0,0 +1,12 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv32g_zicfiss -fcf-protection=return -mabi=ilp32d " 
> { target { rv32 } } } */
> +/* { dg-options "-march=rv32gc_zicfiss -fcf-protection=return -mabi=ilp32d " 
> { target { rv32 } } } */
> +/* { dg-options "-march=rv32g_zicfilp -fcf-protection=branch -mabi=ilp32d " 
> { target { rv32 } } } */
> +/* { dg-options "-march=rv32gc_zicfilp -fcf-protection=branch -mabi=ilp32d " 
> { target { rv32 } } } */
> +/* { dg-options "-march=rv32g_zicfiss_zicfilp -fcf-protection=full 
> -mabi=ilp32d " { target { rv32 } } } */
> +/* { dg-options "-march=rv32gc_zicfiss_zicfilp -fcf-protection=full 
> -mabi=ilp32d " { target { rv32 } } } */

 GCC can only specify only one set of option...so just one
dg-options is enough, also  { target { rv32 } } is not needed.

> +
> +void foo() {}
> +
> +/* { dg-final { scan-assembler-times ".p2align\t2" 3 } } */
> +/* { dg-final { scan-assembler-not ".p2align\t3" } } */
> diff --git a/gcc/testsuite/gcc.target/riscv/gnu-property-rv64.c 
> b/gcc/testsuite/gcc.target/riscv/gnu-property-rv64.c
> new file mode 100644
> index 000..25847ba410a
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/gnu-property-rv64.c
> @@ -0,0 +1,12 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv64g_zicfiss -fcf-protection=return -mabi=lp64d " { 
> target { rv64 } } } */
> +/* { dg-options "-march=rv64gc_zicfiss -fcf-protection=return -mabi=lp64d " 
> { target { rv64 } } } */
> +/* { dg-options "-march=rv64g_zicfilp -fcf-protection=branch -mabi=lp64d " { 
> target { rv64 } } } */
> +/* { dg-options "-march=rv64gc_zicfilp -fcf-protection=branch -mabi=lp64d " 
> { target { rv64 } } } */
> +/* { dg-options "-march=rv64g_zicfiss_zicfilp -fcf-protection=full 
> -mabi=lp64d " { target { rv64 } } } */
> +/* { dg-options "-march=rv64gc_zicfiss_zicfilp -fcf-protection=full 
> -mabi=lp64d " { target { rv64 } } } */

^^^ Same here

> +
> +void foo() {}
> +
> +/* { dg-final { scan-assembler-times ".p2align\t3" 3 } } */
> +/* { dg-final { scan-assembler-not ".p2align\t2" } } */
> --
> 2.39.3
>

[PATCH 1/3][stage1] Remove --param vect-force-slp

[Richard Biener]

The following removes the ability to switch back to non SLP-only
operation of the vectorizer - a requirement to start cleaning out
non-SLP paths without risk of regressing that case.

* params.opt (--param=vect-force-slp): Remove.
* doc/invoke.texi (--param=vect-force-slp): Likewise.
* tree-vect-loop.cc (vect_analyze_loop_2): Assume
param_vect_force_slp is 1.
* tree-vect-stmts.cc (vect_analyze_stmt): Likewise.
---
 gcc/doc/invoke.texi| 3 ---
 gcc/params.opt | 4 
 gcc/tree-vect-loop.cc  | 2 +-
 gcc/tree-vect-stmts.cc | 2 +-
 4 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index a040d65af0e..7ec2498a12d 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -17171,9 +17171,6 @@ this parameter.  The default value of this parameter is 
50.
 @item vect-induction-float
 Enable loop vectorization of floating point inductions.
 
-@item vect-force-slp
-Force the use of SLP when vectorizing, fail if not possible.
-
 @item vrp-block-limit
 Maximum number of basic blocks before VRP switches to a lower memory algorithm.
 
diff --git a/gcc/params.opt b/gcc/params.opt
index 422d082b355..748272c9fb9 100644
--- a/gcc/params.opt
+++ b/gcc/params.opt
@@ -1230,10 +1230,6 @@ The maximum factor which the loop vectorizer applies to 
the cost of statements i
 Common Joined UInteger Var(param_vect_induction_float) Init(1) IntegerRange(0, 
1) Param Optimization
 Enable loop vectorization of floating point inductions.
 
--param=vect-force-slp=
-Common Joined UInteger Var(param_vect_force_slp) Init(1) IntegerRange(0, 1) 
Param Optimization
-Force the use of SLP when vectorizing, fail if not possible.
-
 -param=vrp-block-limit=
 Common Joined UInteger Var(param_vrp_block_limit) Init(15) Optimization 
Param
 Maximum number of basic blocks before VRP switches to a fast model with less 
memory requirements.
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 9413dcef702..792231e5cf6 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -2928,7 +2928,7 @@ start_over:
 
   /* When we arrive here with SLP disabled and we are supposed
  to use SLP for everything fail vectorization.  */
-  if (!slp && param_vect_force_slp)
+  if (!slp)
 return opt_result::failure_at (vect_location,
   "may need non-SLP handling\n");
 
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index 7f874354e75..5a1ab7e0e26 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -14006,7 +14006,7 @@ vect_analyze_stmt (vec_info *vinfo,
 
   /* When we arrive here with a non-SLP statement and we are supposed
  to use SLP for everything fail vectorization.  */
-  if (!node && param_vect_force_slp)
+  if (!node)
 return opt_result::failure_at (stmt_info->stmt,
   "needs non-SLP handling\n");
 
-- 
2.43.0

Re: Questions on replacing a structure pointer reference to a call to .ACCESS_WITH_SIZE in C FE

[Siddhesh Poyarekar]

On 2025-04-10 07:48, Martin Uecker wrote:

For the currently implemented subset, updates to the storage of the
annotated FAM and updates to its counted_by size need to be coupled to
prevent reordering because their relationship is otherwise implicit.

This proposed feature would need the counted_by size and the containing
struct of the FAM to be coupled to make that relationship explicit, but
it's not necessarily to prevent reordering because this case needs to
only be considered when the update of the storage for the struct (or its
containing FAM) is not visible.  That is, the pointer either comes in as
a parameter or a non-allocator call returning that pointer.


So the assumption here is that you never pass around a pointer
to an uninitialized (or otherwise not validely initialized)
structure.


Yes, that's the hairy bit I think, in the context of __bdos.  We tend to 
avoid generating code that dereferences the input pointer, but we ended 
up relaxing that with counted_by.  However, right now it's still limited 
to cases where the compiler can see the allocation, so this extension 
would indeed violate that self-imposed restriction.



Now it is entirely possible that further inlining gets the allocator in
and it would be possible to thread through the .ACCESS_WITH_SIZE to
reach the allocator, but I would argue that the counted_by + size of
struct should be the canonical result.


I am thinking about use cases where the user does its own memory
management, e.g. there is larger arena the structure is
allocated in or there is a capacity field because the structure
was overallocated.


Wouldn't it be even more true in that case though?  When an allocator 
sets up an arena and passes a chunk within it to the caller, it would 
expect the caller to limit its accesses to within the chunk, in this 
case being within bounds of counted_by.  A reasonable allocator should 
in fact expect a security mechanism to trap when this is violated even 
when the overallocation may make the access safe.


This rhymes with the malloc_usable_size discussion, where some 
applications (incorrectly) assume that the extra size available due to 
alignment requirements is available for them and in practice it is safe 
to use it.  However for a security-sensitive program, it would be a 
healthy habit to stay within the bounds they requested or explicitly 
agree with the compiler and runtime that the extra size is usable.  For 
systemd for example there's a dummy realloc that simply hints to the 
compiler that the pointer now has a larger size, encompassing the usable 
size.  I believe there was a C++ proposal with a similar goal, allowing 
the runtime to tell userspace what size was actually allocated.



that inserting the new accesses to the size field are ok (e.g.
one can assume the struct is accessible, there are no new race
conditions under some assumptions, it is initialized).  If you
now want to read the size at different points, all this is even
less clear to me.


I'm not sure about race conditions, the coupling was to prevent
reordering.  Would you be able to elaborate on the race condition question?


If you materialize a read to the size field it could race
with a write to this field in another thread.  I am not sure
whether there are use cases where this can happen, but it is
something to worry about.


This will likely be a problem even with present day use of counted_by. 
The barrier enforced by .ACCESS_WITH_SIZE will only prevent reordering 
within a thread, there's nothing really preventing concurrent access or 
updates.


I suppose one constraint that could be assumed to be imposed is that the 
FAM is currently allocated in the same routine as it is accessed, but it 
could well be that the pointer that's used to receive the allocation is 
shared, thus giving rise to this race.


Maybe we need wording that clearly outlines that allocation of a FAM (or 
containing struct) and update of the counted_by size should be atomic?



I may miss something, but I think one would have to first
define a clear criterion when it is ok to access the size
field.


This is a contentious issue I had not thought of; if the pointer ends up
being NULL at runtime, a dereference due to the size expression for the
containing struct will end up validating it for subsequent passes, which
may makes things even worse.  The size expression will also need a NULL
check to work around this.


Yes. But there could be other issues. The memory could be
protected.


True, or the pointer could be arbitrary/uninitialized like you mentioned 
above.  That is indeed a problem.  Maybe one way to hedge against this 
could be to generate the size expression (and consequently, 
.ACCESS_WITH_SIZE) only when the pointer is read *and* dereferenced 
(could be separate sites, but for the same pointer) in the routine? 
That way we only add a pointer dereference for the size expression when 
there already is a dereference; we're not adding any *new* potential 
undefine

Re: [PATCH] Makefile.tpl: Implement per-stage GDCFLAGS [PR116975]

[Sam James]

Iain Buclaw  writes:

> Hi,
>
> This patch implements STAGE1_GDCFLAGS and others to the configure
> machinery, allowing the GDCFLAGS for each bootstrap stage of building
> gdc to be overriden, as is the case with CXXFLAGS for other front-ends.
>
> This is limited to just the generation of recipes for the
> configure-stage-gcc and all-stage-gcc, as a D compiler is not optionally
> needed by any other module.
>
> OK for mainline?

This bootstraps fine on x86_64 and also does exactly what I needed it
to (tested STAGE1_GDCFLAGS, STAGE2_GDCFLAGS w/ diff values).

Thank you!

>
> Regards,
> Iain.
>
> ---
>   PR d/116975
>
> ChangeLog:
>
>   * Makefile.in: Regenerate.
>   * Makefile.tpl (STAGE[+id+]_GDCFLAGS): New.
>   (STAGE2_GDCFLAGS): Add -fno-checking.
>   (STAGE3_GDCFLAGS): Add -fchecking=1.
>   (BASE_FLAGS_TO_PASS): Pass STAGE[+id+]_GDCFLAGS down.
>   (configure-stage[+id+]-[+prefix+][+module+]): Set GDCFLAGS for all gcc
>   module stages.
>   (all-stage[+id+]-[+prefix+][+module+]): Likewise.
> ---
>  Makefile.in  | 51 +++
>  Makefile.tpl | 15 +--
>  2 files changed, 64 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile.in b/Makefile.in
> index 966d6045496..b80855ffc78 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -619,6 +619,26 @@ STAGE1_CONFIGURE_FLAGS = $(STAGE1_CHECKING) \
> --disable-build-format-warnings
>  
>  @if target-libphobos-bootstrap
> +# Defaults for each stage if we're bootstrapping D.
> +
> +STAGE1_GDCFLAGS = $(GDCFLAGS)
> +
> +STAGE2_GDCFLAGS = $(GDCFLAGS)
> +
> +STAGE3_GDCFLAGS = $(GDCFLAGS)
> +
> +STAGE4_GDCFLAGS = $(GDCFLAGS)
> +
> +STAGEprofile_GDCFLAGS = $(GDCFLAGS)
> +
> +STAGEtrain_GDCFLAGS = $(GDCFLAGS)
> +
> +STAGEfeedback_GDCFLAGS = $(GDCFLAGS)
> +
> +STAGEautoprofile_GDCFLAGS = $(GDCFLAGS)
> +
> +STAGEautofeedback_GDCFLAGS = $(GDCFLAGS)
> +
>  STAGE1_CONFIGURE_FLAGS += --with-libphobos-druntime-only
>  STAGE2_CONFIGURE_FLAGS += --with-libphobos-druntime-only
>  @endif target-libphobos-bootstrap
> @@ -632,6 +652,10 @@ STAGE2_CFLAGS += -fno-checking
>  STAGE2_TFLAGS += -fno-checking
>  STAGE3_CFLAGS += -fchecking=1
>  STAGE3_TFLAGS += -fchecking=1
> +@if target-libphobos-bootstrap
> +STAGE2_GDCFLAGS += -fno-checking
> +STAGE3_GDCFLAGS += -fchecking=1
> +@endif target-libphobos-bootstrap
>  
>  STAGEprofile_CFLAGS = $(STAGE2_CFLAGS) -fprofile-generate
>  STAGEprofile_TFLAGS = $(STAGE2_TFLAGS)
> @@ -921,38 +945,47 @@ BASE_FLAGS_TO_PASS = \
>   "LEAN=$(LEAN)" \
>   "STAGE1_CFLAGS=$(STAGE1_CFLAGS)" \
>   "STAGE1_CXXFLAGS=$(STAGE1_CXXFLAGS)" \
> + "STAGE1_GDCFLAGS=$(STAGE1_GDCFLAGS)" \
>   "STAGE1_GENERATOR_CFLAGS=$(STAGE1_GENERATOR_CFLAGS)" \
>   "STAGE1_TFLAGS=$(STAGE1_TFLAGS)" \
>   "STAGE2_CFLAGS=$(STAGE2_CFLAGS)" \
>   "STAGE2_CXXFLAGS=$(STAGE2_CXXFLAGS)" \
> + "STAGE2_GDCFLAGS=$(STAGE2_GDCFLAGS)" \
>   "STAGE2_GENERATOR_CFLAGS=$(STAGE2_GENERATOR_CFLAGS)" \
>   "STAGE2_TFLAGS=$(STAGE2_TFLAGS)" \
>   "STAGE3_CFLAGS=$(STAGE3_CFLAGS)" \
>   "STAGE3_CXXFLAGS=$(STAGE3_CXXFLAGS)" \
> + "STAGE3_GDCFLAGS=$(STAGE3_GDCFLAGS)" \
>   "STAGE3_GENERATOR_CFLAGS=$(STAGE3_GENERATOR_CFLAGS)" \
>   "STAGE3_TFLAGS=$(STAGE3_TFLAGS)" \
>   "STAGE4_CFLAGS=$(STAGE4_CFLAGS)" \
>   "STAGE4_CXXFLAGS=$(STAGE4_CXXFLAGS)" \
> + "STAGE4_GDCFLAGS=$(STAGE4_GDCFLAGS)" \
>   "STAGE4_GENERATOR_CFLAGS=$(STAGE4_GENERATOR_CFLAGS)" \
>   "STAGE4_TFLAGS=$(STAGE4_TFLAGS)" \
>   "STAGEprofile_CFLAGS=$(STAGEprofile_CFLAGS)" \
>   "STAGEprofile_CXXFLAGS=$(STAGEprofile_CXXFLAGS)" \
> + "STAGEprofile_GDCFLAGS=$(STAGEprofile_GDCFLAGS)" \
>   "STAGEprofile_GENERATOR_CFLAGS=$(STAGEprofile_GENERATOR_CFLAGS)" \
>   "STAGEprofile_TFLAGS=$(STAGEprofile_TFLAGS)" \
>   "STAGEtrain_CFLAGS=$(STAGEtrain_CFLAGS)" \
>   "STAGEtrain_CXXFLAGS=$(STAGEtrain_CXXFLAGS)" \
> + "STAGEtrain_GDCFLAGS=$(STAGEtrain_GDCFLAGS)" \
>   "STAGEtrain_GENERATOR_CFLAGS=$(STAGEtrain_GENERATOR_CFLAGS)" \
>   "STAGEtrain_TFLAGS=$(STAGEtrain_TFLAGS)" \
>   "STAGEfeedback_CFLAGS=$(STAGEfeedback_CFLAGS)" \
>   "STAGEfeedback_CXXFLAGS=$(STAGEfeedback_CXXFLAGS)" \
> + "STAGEfeedback_GDCFLAGS=$(STAGEfeedback_GDCFLAGS)" \
>   "STAGEfeedback_GENERATOR_CFLAGS=$(STAGEfeedback_GENERATOR_CFLAGS)" \
>   "STAGEfeedback_TFLAGS=$(STAGEfeedback_TFLAGS)" \
>   "STAGEautoprofile_CFLAGS=$(STAGEautoprofile_CFLAGS)" \
>   "STAGEautoprofile_CXXFLAGS=$(STAGEautoprofile_CXXFLAGS)" \
> + "STAGEautoprofile_GDCFLAGS=$(STAGEautoprofile_GDCFLAGS)" \
>   
> "STAGEautoprofile_GENERATOR_CFLAGS=$(STAGEautoprofile_GENERATOR_CFLAGS)" \
>   "STAGEautoprofile_TFLAGS=$(STAGEautoprofile_TFLAGS)" \
>   "STAGEautofeedback_CFLAGS=$(STAGEautofeedback_CFLAGS)" \
>   "STAGEautofeedback_CXXFLAGS=$(STAGEautofeedback_CXXFLAGS)" \
> + "STAGEautofeedback_GDCFLAGS=$(STAGEautofeedback_GDCFLAGS)" \
>   
> "STAGEautofeedback_GEN

[pushed] c++: lambda in constraint of lambda [PR119175]

[Jason Merrill]

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

-- 8< --

Here when we went to mangle the constraints of from<0>, the outer lambda has
no mangling scope, but the inner one was treated as having the outer one as
its scope.  And mangling the outer one means mangling its constraints, which
include the inner one.  So infinite recursion.

But a lambda closure type isn't a scope that anything should have for
mangling, the inner lambda should also have no mangling scope.

PR c++/119175

gcc/cp/ChangeLog:

* mangle.cc (decl_mangling_context): Look through lambda type.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-lambda23.C: New test.
---
 gcc/cp/mangle.cc   |  6 ++
 gcc/testsuite/g++.dg/cpp2a/concepts-lambda23.C | 12 
 2 files changed, 18 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-lambda23.C

diff --git a/gcc/cp/mangle.cc b/gcc/cp/mangle.cc
index 02129c6b89a..3d5e96b2c94 100644
--- a/gcc/cp/mangle.cc
+++ b/gcc/cp/mangle.cc
@@ -1048,6 +1048,12 @@ decl_mangling_context (tree decl)
   tree extra = LAMBDA_TYPE_EXTRA_SCOPE (TREE_TYPE (decl));
   if (extra)
return extra;
+  tcontext = CP_DECL_CONTEXT (decl);
+  if (LAMBDA_TYPE_P (tcontext))
+   /* Lambda type context means this lambda appears between the
+  lambda-introducer and the open brace of another lambda (c++/119175).
+  That isn't a real scope; look further into the enclosing scope.  */
+   return decl_mangling_context (TYPE_NAME (tcontext));
 }
   else if (template_type_parameter_p (decl))
  /* template type parms have no mangling context.  */
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-lambda23.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-lambda23.C
new file mode 100644
index 000..f44212031dd
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-lambda23.C
@@ -0,0 +1,12 @@
+// PR c++/119175
+// { dg-do compile { target c++20 } }
+
+template
+static void from() requires requires {
+  [] requires requires { [] {}; } {};
+}
+{}
+
+int main() {
+  from();
+}

base-commit: 911973a784aab34e13c683545f28177d0d7716cd
-- 
2.49.0

[PATCH 3/3][stage1] Prune non-SLP paths from vectorizer loop analysis

[Richard Biener]

The following prunes non-SLP iteration and the parts of non-SLP
stmt analysis that is no longer necessary - we need to keep the
parts that bail on stmts not covered by SLP discovery or that
failed SLP discovery.  This will only go away when a we can build
a fully covering single-lane SLP graph to fall back to.

Bootstrapped and tested on x86_64-unknown-linux-gnu, I plan to
push this series after 15.1 is released.

Richard.

* tree-vect-loop.cc (vect_analyze_loop_operations): Prune
all actual analysis and only fail when we discover a not
SLP covered stmt.
(vect_analyze_loop_2): Remove path trying without SLP.
---
 gcc/tree-vect-loop.cc | 152 --
 1 file changed, 43 insertions(+), 109 deletions(-)

diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index b5398ed2e99..81a95dc8b62 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -2114,13 +2114,9 @@ vect_analyze_loop_operations (loop_vec_info loop_vinfo)
   int nbbs = loop->num_nodes;
   int i;
   stmt_vec_info stmt_info;
-  bool need_to_vectorize = false;
-  bool ok;
 
   DUMP_VECT_SCOPE ("vect_analyze_loop_operations");
 
-  auto_vec cost_vec;
-
   for (i = 0; i < nbbs; i++)
 {
   basic_block bb = bbs[i];
@@ -2129,7 +2125,6 @@ vect_analyze_loop_operations (loop_vec_info loop_vinfo)
   gsi_next (&si))
 {
   gphi *phi = si.phi ();
-  ok = true;
 
  stmt_info = loop_vinfo->lookup_stmt (phi);
   if (dump_enabled_p ())
@@ -2138,6 +2133,10 @@ vect_analyze_loop_operations (loop_vec_info loop_vinfo)
  if (virtual_operand_p (gimple_phi_result (phi)))
continue;
 
+ /* ???  All of the below unconditional FAILs should be in
+done earlier after analyzing cycles, possibly when
+determining stmt relevancy?  */
+
   /* Inner-loop loop-closed exit phi in outer-loop vectorization
  (i.e., a phi in the tail of the outer-loop).  */
   if (! is_loop_header_bb_p (bb))
@@ -2174,9 +2173,7 @@ vect_analyze_loop_operations (loop_vec_info loop_vinfo)
  if ((STMT_VINFO_DEF_TYPE (stmt_info) == vect_internal_def
   || (STMT_VINFO_DEF_TYPE (stmt_info)
   == vect_double_reduction_def))
- && ! PURE_SLP_STMT (stmt_info)
- && !vectorizable_lc_phi (loop_vinfo,
-  stmt_info, NULL, NULL))
+ && ! PURE_SLP_STMT (stmt_info))
return opt_result::failure_at (phi, "unsupported phi\n");
 }
 
@@ -2194,36 +2191,8 @@ vect_analyze_loop_operations (loop_vec_info loop_vinfo)
   "not vectorized:"
   " scalar dependence cycle.\n");
 
-  if (STMT_VINFO_RELEVANT_P (stmt_info))
-{
-  need_to_vectorize = true;
-  if (STMT_VINFO_DEF_TYPE (stmt_info) == vect_induction_def
- && ! PURE_SLP_STMT (stmt_info))
-   ok = vectorizable_induction (loop_vinfo,
-stmt_info, NULL, NULL,
-&cost_vec);
- else if ((STMT_VINFO_DEF_TYPE (stmt_info) == vect_reduction_def
-   || (STMT_VINFO_DEF_TYPE (stmt_info)
-   == vect_double_reduction_def)
-   || STMT_VINFO_DEF_TYPE (stmt_info) == vect_nested_cycle)
-  && ! PURE_SLP_STMT (stmt_info))
-   ok = vectorizable_reduction (loop_vinfo,
-stmt_info, NULL, NULL, &cost_vec);
- else if ((STMT_VINFO_DEF_TYPE (stmt_info)
-   == vect_first_order_recurrence)
-  && ! PURE_SLP_STMT (stmt_info))
-   ok = vectorizable_recurr (loop_vinfo, stmt_info, NULL, NULL,
-  &cost_vec);
-}
-
- /* SLP PHIs are tested by vect_slp_analyze_node_operations.  */
- if (ok
- && STMT_VINFO_LIVE_P (stmt_info)
- && !PURE_SLP_STMT (stmt_info))
-   ok = vectorizable_live_operation (loop_vinfo, stmt_info, NULL, NULL,
- -1, false, &cost_vec);
-
-  if (!ok)
+ if (STMT_VINFO_RELEVANT_P (stmt_info)
+ && ! PURE_SLP_STMT (stmt_info))
return opt_result::failure_at (phi,
   "not vectorized: relevant phi not "
   "supported: %G",
@@ -2237,34 +2206,18 @@ vect_analyze_loop_operations (loop_vec_info loop_vinfo)
  if (!gimple_clobber_p (stmt)
  && !is_gimple_debug (stmt))
{
+ bool need_to_vectorize = false;
  opt_result res
= vect_analyze_stmt 

[PATCH 2/3][stage1] Remove non-SLP vector loop transform

[Richard Biener]

The following removes the stmt-based vectorization loop transform code.
This also removes some debug stmt handling (that looked incomplete)
which is also handled during peeling, and special-casing some stmts
that should be killed off early and not left to DCE.

Moving of dump from vect_transform_loop_stmt to vect_transform_stmt
is to avoid regressing a few testcases.

* tree-vect-loop.cc (vect_loop_kill_debug_uses): Remove.
(maybe_set_vectorized_backedge_value): Likewise.
(vect_transform_loop_stmt): Likewise.  Move dump printing
to vect_transform_stmt.
(vect_transform_loop): Remove loop over loop stmts transforming
them, but retain some DCE code still necessary.
* tree-vect-stmts.cc (vect_transform_stmt): Dump that
we're vectorizing a stmt.
---
 gcc/tree-vect-loop.cc  | 303 ++---
 gcc/tree-vect-stmts.cc |   4 +
 2 files changed, 19 insertions(+), 288 deletions(-)

diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 792231e5cf6..b5398ed2e99 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -9594,8 +9594,7 @@ vectorizable_phi (vec_info *,
vector PHI node and the permute since those together compute the
vectorized value of the scalar PHI.  We do not yet have the
backedge value to fill in there nor into the vec_perm.  Those
-   are filled in maybe_set_vectorized_backedge_value and
-   vect_schedule_scc.
+   are filled in vect_schedule_scc.
 
TODO:  Since the scalar loop does not have a use of the recurrence
outside of the loop the natural way to implement peeling via
@@ -11676,45 +11675,6 @@ vectorizable_live_operation (vec_info *vinfo, 
stmt_vec_info stmt_info,
   return true;
 }
 
-/* Kill any debug uses outside LOOP of SSA names defined in STMT_INFO.  */
-
-static void
-vect_loop_kill_debug_uses (class loop *loop, stmt_vec_info stmt_info)
-{
-  ssa_op_iter op_iter;
-  imm_use_iterator imm_iter;
-  def_operand_p def_p;
-  gimple *ustmt;
-
-  FOR_EACH_PHI_OR_STMT_DEF (def_p, stmt_info->stmt, op_iter, SSA_OP_DEF)
-{
-  FOR_EACH_IMM_USE_STMT (ustmt, imm_iter, DEF_FROM_PTR (def_p))
-   {
- basic_block bb;
-
- if (!is_gimple_debug (ustmt))
-   continue;
-
- bb = gimple_bb (ustmt);
-
- if (!flow_bb_inside_loop_p (loop, bb))
-   {
- if (gimple_debug_bind_p (ustmt))
-   {
- if (dump_enabled_p ())
-   dump_printf_loc (MSG_NOTE, vect_location,
- "killing debug use\n");
-
- gimple_debug_bind_reset_value (ustmt);
- update_stmt (ustmt);
-   }
- else
-   gcc_unreachable ();
-   }
-   }
-}
-}
-
 /* Given loop represented by LOOP_VINFO, return true if computation of
LOOP_VINFO_NITERS (= LOOP_VINFO_NITERSM1 + 1) doesn't overflow, false
otherwise.  */
@@ -12088,126 +12048,6 @@ scale_profile_for_vect_loop (class loop *loop, edge 
exit_e, unsigned vf, bool fl
  get_likely_max_loop_iterations_int (loop));
 }
 
-/* For a vectorized stmt DEF_STMT_INFO adjust all vectorized PHI
-   latch edge values originally defined by it.  */
-
-static void
-maybe_set_vectorized_backedge_value (loop_vec_info loop_vinfo,
-stmt_vec_info def_stmt_info)
-{
-  tree def = gimple_get_lhs (vect_orig_stmt (def_stmt_info)->stmt);
-  if (!def || TREE_CODE (def) != SSA_NAME)
-return;
-  stmt_vec_info phi_info;
-  imm_use_iterator iter;
-  use_operand_p use_p;
-  FOR_EACH_IMM_USE_FAST (use_p, iter, def)
-{
-  gphi *phi = dyn_cast  (USE_STMT (use_p));
-  if (!phi)
-   continue;
-  if (!(gimple_bb (phi)->loop_father->header == gimple_bb (phi)
-   && (phi_info = loop_vinfo->lookup_stmt (phi))
-   && STMT_VINFO_RELEVANT_P (phi_info)))
-   continue;
-  loop_p loop = gimple_bb (phi)->loop_father;
-  edge e = loop_latch_edge (loop);
-  if (PHI_ARG_DEF_FROM_EDGE (phi, e) != def)
-   continue;
-
-  if (VECTORIZABLE_CYCLE_DEF (STMT_VINFO_DEF_TYPE (phi_info))
- && STMT_VINFO_REDUC_TYPE (phi_info) != FOLD_LEFT_REDUCTION
- && STMT_VINFO_REDUC_TYPE (phi_info) != EXTRACT_LAST_REDUCTION)
-   {
- vec &phi_defs = STMT_VINFO_VEC_STMTS (phi_info);
- vec &latch_defs = STMT_VINFO_VEC_STMTS (def_stmt_info);
- gcc_assert (phi_defs.length () == latch_defs.length ());
- for (unsigned i = 0; i < phi_defs.length (); ++i)
-   add_phi_arg (as_a  (phi_defs[i]),
-gimple_get_lhs (latch_defs[i]), e,
-gimple_phi_arg_location (phi, e->dest_idx));
-   }
-  else if (STMT_VINFO_DEF_TYPE (phi_info) == vect_first_order_recurrence)
-   {
- /* For first order recurrences we have to update both uses of
-the latch definition, the one in the PHI node and the one

[committed] cobol: New testcases for reference modification.

[Robert Dubner]

cobol: New testcases for reference modification.

gcc/testsuite

* cobol.dg/group2/Dynamic_reference_modification.cob: New
testcase.
* cobol.dg/group2/Length_overflow__1_.cob: Likewise.
* cobol.dg/group2/Length_overflow__2_.cob: Likewise.
* cobol.dg/group2/Length_overflow_with_offset__1_.cob:
Likewise.
* cobol.dg/group2/Length_overflow_with_offset__2_.cob:
Likewise.
* cobol.dg/group2/Length_overflow_with_offset__3_.cob:
Likewise.
* cobol.dg/group2/Offset_overflow.cob: Likewise.
* cobol.dg/group2/Offset_underflow.cob: Likewise.
*
cobol.dg/group2/Refmod__comparisons_inside_numeric-display.cob: Likewise.
* cobol.dg/group2/Refmod_sources_are_figurative_constants.cob:
Likewise.
* cobol.dg/group2/Static_reference_modification.cob: Likewise.
* cobol.dg/group2/Dynamic_reference_modification.out: New
known-good result.
* cobol.dg/group2/Length_overflow__1_.out: Likewise.
* cobol.dg/group2/Length_overflow__2_.out: Likewise.
* cobol.dg/group2/Length_overflow_with_offset__1_.out:
Likewise.
* cobol.dg/group2/Length_overflow_with_offset__2_.out:
Likewise.
* cobol.dg/group2/Length_overflow_with_offset__3_.out:
Likewise.
* cobol.dg/group2/Offset_overflow.out: Likewise.
* cobol.dg/group2/Offset_underflow.out: Likewise.
*
cobol.dg/group2/Refmod__comparisons_inside_numeric-display.out: Likewise.
* cobol.dg/group2/Refmod_sources_are_figurative_constants.out:
Likewise.
* cobol.dg/group2/Static_reference_modification.out: Likewise.

Re: [PATCH] libgomp: Update SVE tests

[Tejas Belagod]

On 4/10/25 5:56 PM, Richard Sandiford wrote:

Tejas Belagod  writes:

On 4/10/25 5:13 PM, Tejas Belagod wrote:

On 4/9/25 4:13 PM, Jakub Jelinek wrote:

On Wed, Apr 09, 2025 at 04:01:49PM +0530, Tejas Belagod wrote:

It also looks like there might be a missing "+" in simd_reduction:

     #pragma omp simd reduction (+:va, i)
     for (j = 0; j < 16; j++)
   va = svld1_s32 (svptrue_b32 (), a);

     res = svaddv_s32 (svptrue_b32 (), va);

     if (res != 8)
   __builtin_abort ();

since AFAICT the loop is not doing a reduction as things stand.
But perhaps that's deliberate, since it does match the != 8 test.


That's interesting. I thought the reduction definition in the
'declare reduction' does the reduction from all the individual
interations
according the the rules defined in the reduction irrespective of the
loop
structure.  Maybe 'va' doesn't become implicit private and causes a race
(which may be why I didn't see it in my testing) - I'll try to repro
this
and have a look.


No, reduction privatizes the variable, initializes the private
variable with
the initializer from UDR and reduces at the end only from all the private
variables to the original one.

For simd, each SIMD lane has one private copy and there are # SIMD lanes
reductions into the original, for e.g. worksharing constructs each thread
has a private copy and there are omp_get_num_threads () reductions, etc.

There is no special action at the end of each loop body, it is up to the
user to merge state from each iteration.  In sane code the loop body does
similar operation to what the reduction does.
So say if you have
float sum = 0;
#pragma omp parallel for reduction (+:sum)
for (int i = 0; i < 1024; ++i)
    sum += a[i];
then if OpenMP pragmas are ignored, all the array members
are summed up in that order, while if say there are 4
threads and each handles 256 iterations, then each thread will
start with sum = 0; and do sum += a[i]; for i omp_get_thread_num () * 256
to omp_get_thread_num () * 256 + 255 inclusive and finally in some random
order the 4 private floats will be summed together.
For floating point that can result in different behavior (different
rounding
etc.) but user said it is ok like that.



Thanks for the explanation.  I looked into why some of the tests may
have failed - my flawed understanding of the reduction clause was why I
didn't have the += in the loops - it might have passed for me as I
probably hit the exact omp_get_num_threads () number required for the
final += reductions to trigger from the declare clause.  As Richard
said, the += in the loops ought to fix the tests. I'm still analysing
inscan_reduction_incl () to fix it properly.


Sorry, forgot to ask - Richard, are you happy for me to work on a
separate patch to fix the test alongside your target +sve fix as a
couple more functions (eg simd_reduction () and inscan.. () ) also need
fixing?


Sure, that's fine with me.  Should I apply the patch, or would you
prefer to wait until your patch is ready?



Please apply - I don't think my fixes will conflict with your changes.

Thanks,
Tejas.

[pushed] Darwin, libgcobol: Enable for x86_64 Darwin.

[Iain Sandoe]

Tested on x86_64 Darwin, Linux, pushed to trunk, thanks
Iain

--- 8< ---

Now that we have libquadmath support, we can enable for x86_64, at
least.

libgcobol/ChangeLog:

* configure.tgt: Enable for x86_64 Darwin.

Signed-off-by: Iain Sandoe 
---
 libgcobol/configure.tgt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgcobol/configure.tgt b/libgcobol/configure.tgt
index c5e263a4eed..ebf044e98f1 100644
--- a/libgcobol/configure.tgt
+++ b/libgcobol/configure.tgt
@@ -34,7 +34,7 @@ case "${target}" in
LIBGCOBOL_SUPPORTED=yes
fi
;;
-x86_64-*-linux* | i?86-*-linux*)
+x86_64-*-linux* | i?86-*-linux* | x86_64-*-darwin*)
if test x$ac_cv_sizeof_void_p = x8; then
LIBGCOBOL_SUPPORTED=yes
fi
-- 
2.39.2 (Apple Git-143)

Re: [PATCH v3 00/19] FMV refactor and ACLE compliance.

[Alfie Richards]

Hello,

I have another revision of this coming as I discovered some issues at 
higher optimisation levels and have found a bunch of nits.


Kind regards,
Alfie

On 27/03/2025 15:45, Alfie Richards wrote:

Hi All,

This is an update on the patch series enabling ACLE compliant FMV
behaviour for targets supporting target_version and a refactor of FMV
in the front end.

This patch series leaves much of the logic that enables FMV for x86
in place, often gated behind TARGET_HAS_FMV_TARGET_ATTRIBUTE.
I would like to refactor more of the x86/PPC logic. Possibly even
making it match ACLE behaviour/semantics in places. but want to avoid
breaking changes and regressions, and as I could not find any x86/PPC
spec I thought best left alone for now.

The main changes between last patch series and this one are:

* Added pretty-print formatting support for string_slice.
   (I'm not sure I did this completely correctly though in
   the c-family front end?)
* Large refactor to the merging/conflicting logic in the
   C++ front end. This is because I found flaws in the previous version
   which could merge target_version decls that weren't distinct, but
   weren't mergaeble.
   * This involved a large refactor of the common_function_version
 hook to take string_slices instead of decls, and moving
 the target_version/target_clone distinctness/mergability
 logic into shared code.
   * This has the added benefit of enabling riscv target_version/
 target_clones automatically as it now uses the same shared code
 which wasn't possible before the hook refactor.
   * This did also require some hacks to the riscv target parsing code
 which would benefit from a more careful refactor.
* Added warning and skipping for unparsable target_clones values
   * This is part of the ACLE that I missed last time.
   * It only works properly for Aarch64 at the moment. Though I use
 the hook to check parsing and emit errors for riscv as otherwise
 I was breaking a lot of things.
   * Ideally this would be implemented by other targets (especially riscv
 with the shared target_clones semantics) to enable some portability.

I am also working on a patch to add target_version support to the C frontend
while making it ACLE compliant, and a patch to update the
redirect_to_specific_clone logic to work properly with ACLE semantics which
will both use the work in this patch.

Reg tested and bootstrapped on x86-linux-gnu and aarch64-linux-gnu.
FMV tests ran for PowerPC and RiscV.

Kind regards,
Alfie Richards

Alfie Richards (17):
   Add string_slice class.
   Remove unnecessary `record` argument from maybe_version_functions.
   Update is_function_default_version to work with target_version.
   Change function versions to be implicitly ordered.
   Change make_attribute to take string_slice.
   Add get_clone_versions and get_version functions.
   Add assembler_name to cgraph_function_version_info.
   Add dispatcher_resolver_function and is_target_clone to cgraph_node.
   Add clone_identifier function.
   Refactor FMV name mangling.
   Refactor riscv target parsing to take string_slice.
   Add regect_target_clone hook and filter target_clone versions.
   Change target_version semantics to follow ACLE specification.
   Refactor FMV frontend hooks and logic.
   Support mixing of target_clones and target_version.
   Add error cases and tests for Aarch64 FMV.
   Remove FMV beta warning.

Andrew Carlotti (2):
   Add PowerPC FMV symbol tests.
   Add x86 FMV symbol tests

  gcc/attribs.cc| 252 +--
  gcc/attribs.h |   6 +-
  gcc/c-family/c-attribs.cc |  29 +-
  gcc/c-family/c-format.cc  |   9 +
  gcc/c-family/c-format.h   |   1 +
  gcc/cgraph.cc |  28 +-
  gcc/cgraph.h  |  20 +-
  gcc/cgraphclones.cc   |  16 +-
  gcc/cgraphunit.cc |   9 +
  gcc/config/aarch64/aarch64.cc | 247 ++
  gcc/config/aarch64/aarch64.opt|   2 +-
  gcc/config/i386/i386-features.cc  | 141 
  gcc/config/i386/i386.cc   |   3 +
  gcc/config/riscv/riscv-protos.h   |   2 +
  gcc/config/riscv/riscv-target-attr.cc |  14 +-
  gcc/config/riscv/riscv.cc | 231 ++---
  gcc/config/rs6000/rs6000.cc   | 153 ++---
  gcc/cp/call.cc|  10 +
  gcc/cp/class.cc   |  19 +-
  gcc/cp/cp-gimplify.cc |  11 +-
  gcc/cp/cp-tree.h  |   4 +-
  gcc/cp/decl.cc|  79 -
  gcc/cp/decl2.cc   |   2 +-
  gcc/cp/typeck.cc  |  10 +
  gcc/doc/invoke.texi   |   5 +-
  gcc/doc/tm.texi   

Re: [PATCH] testsuite: Add support for GCOV_UNDER_TEST

[Christophe Lyon]

On Thu, 10 Apr 2025 at 15:29, Hans-Peter Nilsson  wrote:
>
> > From: Christophe Lyon 
> > Date: Thu, 10 Apr 2025 15:21:23 +0200
>
> Not sure why I'm CC:ed on this one, not being a maintainer
> of the testsuite or targets where gcov tests are exercised,

Because you fixed a problem in r13-4103-ge91d51457532da,
so I wanted to make sure my patch was OK for you.

> but FWIW: LGTM except for the two nits:
Thanks for catching them!

I'll update before committing if/when the patch is approved.

Christophe

>
> > ping?
> >
> > On Tue, 1 Apr 2025 at 22:37, Christophe Lyon  
> > wrote:
> > > diff --git a/gcc/testsuite/g++.dg/gcov/gcov.exp 
> > > b/gcc/testsuite/g++.dg/gcov/gcov.exp
> > > index 50f60c4a011..d85bf125d16 100644
> > > --- a/gcc/testsuite/g++.dg/gcov/gcov.exp
> > > +++ b/gcc/testsuite/g++.dg/gcov/gcov.exp
> > > @@ -21,12 +21,19 @@ load_lib g++-dg.exp
> > >  load_lib gcov.exp
> > >
> > >  global GXX_UNDER_TEST
> > > +global GCOV_UNDER_TEST
> > >
> > > -# Find gcov in the same directory as $GXX_UNDER_TEST.
> > > -if { ![is_remote host] && [string match "*/*" [lindex $GXX_UNDER_TEST 
> > > 0]] } {
> > > -set GCOV [file dirname [lindex $GXX_UNDER_TEST 
> > > 0]]/[gcc-transform-out-of-tree gcov]
> > > +# Find gcov in the same directory as $GXX_UNDER_TEST. under
> > > +# GCOV_UNDER_TEST is defined.
>
> Cutnpasto; s/. under/, unless/?
>
> > > diff --git a/gcc/testsuite/gnat.dg/gcov/gcov.exp 
> > > b/gcc/testsuite/gnat.dg/gcov/gcov.exp
> > > index 4fa887d5bad..d5977a85e8a 100644
> > > --- a/gcc/testsuite/gnat.dg/gcov/gcov.exp
> > > +++ b/gcc/testsuite/gnat.dg/gcov/gcov.exp
>
> > > +# GCOV_UNDER_TEST is defined..
>
> Extra ".".
>
> brgds, H-p

[Fortran, Patch, Team, 3/5] Update get_team, team_number and image_status to F2018 [PR88154, PR88960, PR97210, PR103001]

[Andre Vehreschild]

Hi all,

attached patch reworks GET_TEAM(), TEAM_NUMBER() and IMAGE_STATUS() to adhere
to the Fortran 2018 as much as possible and to play nicely with the previous
patch of the TEAM statements.

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

Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From ace6832bd6afaa766a43e33ff932714200f1fd09 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild 
Date: Mon, 7 Apr 2025 15:12:09 +0200
Subject: [PATCH 3/6] Fortran: Update get_team, team_number and image_status to
 F2018 [PR88154, PR88960, PR97210, PR103001]

Add functions get_team() and team_number() to comply with F2018
standard.

Update image_status() to comply with F2018 standard.

	PR fortran/88154
	PR fortran/88960
	PR fortran/97210
	PR fortran/103001

gcc/fortran/ChangeLog:

	* check.cc (team_type_check): Check a type for being team_type
	from the iso_fortran_env module.
	(gfc_check_image_status): Use team_type check.
	(gfc_check_get_team): Check for level argument.
	(gfc_check_team_number): Use team_type check.
	* expr.cc (gfc_check_assign): Add treatment for returning
	team_type in caf-single mode.
	* gfortran.texi: Add/Update documentation for get_team and
	team_number API functions.
	* intrinsic.cc (add_functions): Update get_team signature.
	* intrinsic.h (gfc_resolve_get_team): Add prototype.
	* intrinsic.texi: Add/Update documentation for get_team and
	team_number Fortran functions.
	* iresolve.cc (gfc_resolve_get_team): Resolve return type to be
	of type team_type.
	* iso-fortran-env.def: Update STAT_LOCK constants.  They have
	nothing to do with files.  Add level constants for get_team.
	* libgfortran.h: Add level and unlock_stat constants.
	* simplify.cc (gfc_simplify_get_team): Simply to correct return
	type team_type.
	* trans-decl.cc (gfc_build_builtin_function_decls): Update
	get_team and image_status API prototypes to correct signatures.
	* trans-intrinsic.cc (conv_intrinsic_image_status): Translate
	second parameter correctly.
	(conv_intrinsic_team_number): Translate optional single team
	argument correctly.
	(gfc_conv_intrinsic_function): Add translation of get_team.

libgfortran/ChangeLog:

	* caf/libcaf.h: Add constants for get_team's level argument and
	update stat values for failed images.
	(_gfortran_caf_team_number): Add prototype.
	(_gfortran_caf_get_team): Same.
	* caf/single.c (_gfortran_caf_team_number): Get the given team's
	team number.
	(_gfortran_caf_get_team): Get the current team or the team given
	by level when the argument is present.

gcc/testsuite/ChangeLog:

	* gfortran.dg/coarray/image_status_1.f08: Correct check for
	team_type.
	* gfortran.dg/pr102458.f90: Adapt to multiple errors.
	* gfortran.dg/coarray/get_team_1.f90: New test.
	* gfortran.dg/team_get_1.f90: New test.
	* gfortran.dg/team_number_1.f90: Correct Fortran syntax.
---
 gcc/fortran/check.cc  |  65 +-
 gcc/fortran/expr.cc   |   8 +-
 gcc/fortran/gfortran.texi |  50 
 gcc/fortran/intrinsic.cc  |   8 +-
 gcc/fortran/intrinsic.h   |   2 +-
 gcc/fortran/intrinsic.texi| 112 ++
 gcc/fortran/iresolve.cc   |  22 +++-
 gcc/fortran/iso-fortran-env.def   |  22 ++--
 gcc/fortran/libgfortran.h |  10 +-
 gcc/fortran/simplify.cc   |   6 +-
 gcc/fortran/trans-decl.cc |  14 +--
 gcc/fortran/trans-intrinsic.cc|  21 +---
 .../gfortran.dg/coarray/get_team_1.f90|  29 +
 .../gfortran.dg/coarray/image_status_1.f08|   2 +-
 gcc/testsuite/gfortran.dg/pr102458.f90|   2 +-
 gcc/testsuite/gfortran.dg/team_get_1.f90  |  27 +
 gcc/testsuite/gfortran.dg/team_number_1.f90   |   6 +-
 libgfortran/caf/libcaf.h  |  13 +-
 libgfortran/caf/single.c  |  26 
 19 files changed, 367 insertions(+), 78 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/coarray/get_team_1.f90
 create mode 100644 gcc/testsuite/gfortran.dg/team_get_1.f90

diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index 00342787a51..a1c3de3e80d 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -1809,6 +1809,23 @@ gfc_check_atomic_ref (gfc_expr *value, gfc_expr *atom, gfc_expr *stat)
   return gfc_check_atomic (atom, 1, value, 0, stat, 2);
 }

+bool
+team_type_check (gfc_expr *e, int n)
+{
+  if (e->ts.type != BT_DERIVED || !e->ts.u.derived
+  || e->ts.u.derived->from_intmod != INTMOD_ISO_FORTRAN_ENV
+  || e->ts.u.derived->intmod_sym_id != ISOFORTRAN_TEAM_TYPE)
+{
+  gfc_error ("%qs argument of %qs intrinsic at %L shall be of type "
+		 "% from the intrinsic module "
+		 "%",
+		 gfc_current_intrinsic_arg[n]->name, gfc_current_intrinsic,
+		 &e->where);
+  return false;
+}
+
+  return true;
+}

 bool
 gfc_check_image_status (gfc_expr *image, gfc_expr *team)
@@ -1

[PATCH] [PR119706] aarch64: Add test case.

[Jennifer Schmitz]

This patch adds a test case to the testsuite for PR119706.
The bug was already fixed by
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680573.html.

OK for mainline?

Signed-off-by: Jennifer Schmitz 

gcc/testsuite/
PR tree-optimization/119706
* g++.target/aarch64/sve/pr119706.C: New test.
---
 .../g++.target/aarch64/sve/pr119706.C | 178 ++
 1 file changed, 178 insertions(+)
 create mode 100644 gcc/testsuite/g++.target/aarch64/sve/pr119706.C

diff --git a/gcc/testsuite/g++.target/aarch64/sve/pr119706.C 
b/gcc/testsuite/g++.target/aarch64/sve/pr119706.C
new file mode 100644
index 000..443dc50e9d9
--- /dev/null
+++ b/gcc/testsuite/g++.target/aarch64/sve/pr119706.C
@@ -0,0 +1,178 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -mcpu=neoverse-v2 
--param=aarch64-autovec-preference=sve-only -w" } */
+
+namespace a {
+typedef long unsigned b;
+typedef int c;
+template  struct e { using f = d; };
+template  using h = typename e::f;
+template  class> struct i {
+  using f = aa;
+};
+template  class j> using k = i;
+template  class j>
+using l = typename k::f;
+} // namespace a
+inline void *operator new(a::b, void *ab) { return ab; }
+namespace a {
+template  class ac {
+public:
+  typedef b m;
+  template  void ae(ad *ab, n... w) {
+new (ab) ad(w...);
+  }
+};
+template  using x = ac;
+template  class af : public x {
+public:
+  typedef d o;
+  template  struct ag { typedef af ah; };
+};
+struct ai {};
+struct aj : ai {};
+struct ak : aj {};
+template  struct al;
+template  struct al {
+  typedef ak an;
+  typedef c ao;
+  typedef d ap;
+};
+template  typename aq ::an ar(aq) { return typename aq ::an(); }
+template  typename as ::ao at(as au, as av, ak) { return av - au; 
}
+template  typename aw ::ao ax(aw au, aw av) {
+  return at(au, av, ar(au));
+}
+template  struct ay { typedef c ao; };
+} // namespace a
+namespace az {
+template  class ba {
+  am bb;
+  typedef a::al bc;
+
+public:
+  typedef typename bc::an an;
+  typedef typename bc::ao ao;
+  typedef typename bc::ap ap;
+  ba(am bd) : bb(bd) {}
+  ap operator*() { return *bb; }
+  ba operator++() {
+++bb;
+return *this;
+  }
+  am base() { return bb; }
+};
+template 
+bool operator!=(ba bh, ba p) {
+  return bh.base() != p.base();
+}
+template 
+auto operator-(ba bh, ba p) {
+  return bh.base() - p.base();
+}
+} // namespace az
+namespace a {
+struct bi {
+  template  struct bj {
+using f = typename d::ag::ah;
+  };
+  template  using bk = b;
+  template  static constexpr bool bl = false;
+  template  static constexpr bool bm = bl<>;
+  template  static constexpr bool bn = bm;
+};
+template  using bp = typename bi::bj::f;
+template  struct bq : bi {
+  typedef typename bo::o o;
+  using br = l;
+  template  struct bt { using f = typename ay::ao; 
};
+  template  struct bv { using f = typename bu::m; };
+  using ao = typename bt::f;
+  using m = typename bv::f;
+  template  using bw = bp;
+  static br allocate(bo, m);
+  template 
+  static h> ae(bo ci, d ab, n... w) {
+ci.ae(ab, w...);
+  }
+};
+template  struct bx {
+  static bool by(d &bz) try { d(bz.begin(), bz.ca(), bz.cb()); } catch (...) {
+  }
+};
+} // namespace a
+namespace az {
+template  struct cc : a::bq {
+  typedef a::bq q;
+  template  struct ag { typedef typename q::bw ah; };
+};
+} // namespace az
+enum cd {};
+using ce = double;
+namespace a {
+template 
+cg cj(aw au, cf av, cg ck, ch cl) {
+  typedef az::cc cx;
+  for (; au != av; ++au, ++ck)
+cx::ae(cl, ck, *au);
+}
+template  struct cm {
+  typedef typename az::cc::ag::ah cn;
+  typedef typename az::cc::br br;
+  struct co {
+br db;
+br cp;
+  };
+  struct cq : cn, co {
+cq(cn) {}
+  } typedef cr;
+  cn cs();
+  cr cb() noexcept;
+  cm(cr ci) : ct(ci) {}
+  cq ct;
+  br cu(b cv) {
+typedef az::cc cw;
+return cv ? cw::allocate(ct, cv) : c();
+  }
+};
+template > class cy : cm {
+  typedef cm cz;
+
+public:
+  typedef typename cz::br br;
+  typedef az::ba da;
+  typedef b m;
+  typedef bo cr;
+  cz::cs;
+  template  cy(aw au, aw av, cr ci) : cz(ci) {
+dg(au, av, ar(au));
+  }
+  cz::cb;
+  da begin() { return this->ct.db; }
+  da ca() { return this->ct.cp; }
+  void r() { s(); }
+  void clear() { t(this->ct.db); }
+  template  void dg(cg au, cg av, ai) { y(au, av, ax(au, av)); }
+  template  void y(am au, cf av, m cv) {
+br z = this->cu(dc(cv, cs()));
+cj(au, av, z, cs());
+  }
+  bool s();
+  m dc(m cv, cr) { return cv; }
+  void t(br dd) {
+if (this->ct.cp - dd)
+  this->ct.cp = dd;
+  }
+};
+template  bool cy::s() { bx::by(*this); }
+namespace basic {
+class u {
+  using de = ce;
+  void v(cd, b);
+  cy df;
+};
+void u::v(cd, b) {
+  df.clear();
+  df.r();
+}
+} // namespace basic
+} // namespace a
\ No newline at end of file
-- 
2.34.1

smime.p7s
Description: S/MIME cryptographic signature

Re: .ACCESS_WITH_SIZE and pointer ranges

[Siddhesh Poyarekar]

On 2025-04-10 11:12, Martin Uecker wrote:

range-ops is setup to pull range information from builtin functions
already in gimple-range-op.cc::
gimple_range_op_handler::maybe_builtin_call ().  We'd just need to write
a handler for this new one.  You can pull information from 2 operands
under normal circumstances, but exceptions can be made.    I'd need a
description of what it looks like and how that translates to range info.


That's perfect!  It's probably redundant for cases where we end up with
both .ACCESS_WITH_SIZE and a __bos/__bdos call, but I don't remember if
that's the only place where .ACCESS_WITH_SIZE is generated today.  Qing,
could you please work with Andrew on this?


BTW, what I would find very interesting is inserting such information
at the points where arrays decay to pointer.


Indeed, that would be very useful.

Thanks,
Sid

Re: [PATCH v1 3/4] libstdc++: Implement std::extents [PR107761].

[Luc Grosheintz]

On 4/9/25 9:23 AM, Luc Grosheintz wrote:

This implements std::extents from  according to N4950 and
contains partial progress towards PR107761.

If an extent changes its type, there's a precondition in the standard,
that the value is representable in the target integer type. This commit
uses a static_cast for all of these conversions, without any additional
checks.

The precondition for 'extents::{static_,}extent' is that '__r < rank()'.
For extents this precondition is always violated and results in
calling __builtin_trap. For all other specializations it's checked via
__glibcxx_assert.

PR libstdc++/107761

libstdc++-v3/ChangeLog:

* include/std/mdspan (extents): New class.
* src/c++23/std.cc.in: Add 'using std::extents'.

Signed-off-by: Luc Grosheintz 
---
  libstdc++-v3/include/std/mdspan  | 400 +++
  libstdc++-v3/src/c++23/std.cc.in |   6 +-
  2 files changed, 405 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/std/mdspan b/libstdc++-v3/include/std/mdspan
index 4094a416d1e..5c6a1868d62 100644
--- a/libstdc++-v3/include/std/mdspan
+++ b/libstdc++-v3/include/std/mdspan
@@ -33,6 +33,10 @@
  #pragma GCC system_header
  #endif
  
+#include 

+#include 
+#include 
+
  #define __glibcxx_want_mdspan
  #include 
  
@@ -42,6 +46,402 @@ namespace std _GLIBCXX_VISIBILITY(default)

  {
  _GLIBCXX_BEGIN_NAMESPACE_VERSION
  
+  namespace __detail

+  {
+// Computed as: sum_i (i == __r) * E_i
+template
+  struct _StaticExtent;
+
+template
+  struct _StaticExtent<_Count, _Extent, _Extents...>
+  {
+   static constexpr size_t
+   _M_value(size_t __r) noexcept
+   {
+ return (_Count == __r) * _Extent
++ _StaticExtent<_Count + 1, _Extents...>::_M_value(__r);
+   }
+  };
+
+template
+  struct _StaticExtent<_Count>
+  {
+   static constexpr size_t
+   _M_value(size_t __r) noexcept
+   { return 0; }
+  };
+
+// Computed as: sum_i (i < __r) * (E_i == dynamic_extent)
+template
+  struct _DynamicIndex;
+
+template
+  struct _DynamicIndex<_Count, _Extent, _Extents...>
+  {
+   static constexpr size_t
+   _M_value(size_t __r) noexcept
+   {
+ return (_Count < __r) * (_Extent == dynamic_extent)
++ _DynamicIndex<_Count + 1, _Extents...>::_M_value(__r);
+   }
+  };
+
+template
+  struct _DynamicIndex<_Count>
+  {
+   static constexpr size_t
+   _M_value(size_t __r) noexcept
+   { return 0; }
+  };
+
+// Computed by: counting the number of dynamic extents (_Dr); and returning
+// the static index first time `__di == _Dr`.
+template
+  struct _DynamicIndexInv;
+
+template
+  struct _DynamicIndexInv<_Si, _Dr, _Extent, _Extents...>
+  {
+   static constexpr size_t
+   _M_value(size_t __di) noexcept
+   {
+ if (_Extent == dynamic_extent && __di == _Dr)
+   return _Si;
+ else
+   return _DynamicIndexInv<_Si+1, _Dr + (_Extent == dynamic_extent),
+   _Extents...>
+  ::_M_value(__di);
+   }
+  };
+
+template
+  struct _DynamicIndexInv<_Si, _Dr, _Extent>
+  {
+   static constexpr size_t
+   _M_value(size_t __di) noexcept
+   {
+ __glibcxx_assert(__di == _Dr);
+ return _Si;
+   }
+  };
+
+// Aim: __ext[i] for template parameter packs.
+template
+  struct _GetPackElement;
+
+template
+  struct _GetPackElement<_Count, _IndexType, _IndexTypes...>
+  {
+   template
+ static constexpr const auto&
+ get(const _IndexType& __current, const _IndexTypes&... __rest)
+ {
+   if constexpr (_Index == _Count)
+ return __current;
+   else
+ return _GetPackElement<_Count+1, _IndexTypes...>
+::template get<_Index>(__rest...);
+ }
+  };
+
+template
+  constexpr const auto&
+  __get_element(const _IndexTypes&... __exts)
+  {
+   return _GetPackElement<0, _IndexTypes...>
+  ::template get<_Di>(__exts...);
+  }
+
+template
+  struct _DynamicRank
+  {
+   static constexpr size_t _S_value = ((_Extents == dynamic_extent) + ...);
+  };
+
+template<>
+  struct _DynamicRank<>
+  {
+   static constexpr size_t _S_value = 0;
+  };
+
+template
+  struct _ExtentsStorage;
+
+template
+  struct _ExtentsStorage<_IndexType, index_sequence<_DynamicIndexes...>,
+index_sequence<_Indexes...>, _Extents...>
+  {
+   static constexpr size_t _S_rank = sizeof...(_Extents);
+
+   static constexpr size_t _S_rank_dynamic =
+ _DynamicRank<_Extents...>::_S_value;
+
+   static constexpr array _S_dynamic_index_inv{
+ _DynamicIndexInv<0, 0, _Extents...> ::_M_value(_DynamicIndexes)...};
+
+

[committed] libstdc++: Adjust value of __cpp_lib_constrained_equality for C++20

[Jonathan Wakely]

The P3379R0 bump to __cpp_lib_constrained_equality relates to changes
that only affect std::expected, so there's no reason to define the
updated value in C++20.

This change restores the previous value (202403) for C++20, and only
uses the new value (202411) for C++23 and later.

Also remove the TODO comments, because I correctly predicted that the
final value would be 202411.

libstdc++-v3/ChangeLog:

* include/bits/version.def (constrained_equality): Only define
as 202411 for C++23 and later, use 202403 for C++20.
* include/bits/version.h: Regenerate.
* testsuite/20_util/expected/equality_constrained.cc: Remove
TODO comment.
---

Tested x86_64-linux. Pushed to trunk.

N.B. strictly speaking neither of the papers that modified the
__cpp_lib_constrained_equality macro (P2944R3 and P3379R0) were approved
as a DR, so it's a C++26 feature. But we support the constraints back to
C++20 (or back to C++23 for std::expected). Defaulted comparisons work
better if these comparisons are properly constrained.

 libstdc++-v3/include/bits/version.def  | 7 ++-
 libstdc++-v3/include/bits/version.h| 7 ++-
 .../testsuite/20_util/expected/equality_constrained.cc | 2 +-
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/libstdc++-v3/include/bits/version.def 
b/libstdc++-v3/include/bits/version.def
index 8f609b469cc..2ec1b40bd38 100644
--- a/libstdc++-v3/include/bits/version.def
+++ b/libstdc++-v3/include/bits/version.def
@@ -1273,7 +1273,12 @@ ftms = {
 ftms = {
   name = constrained_equality;
   values = {
-v = 202411; // FIXME: 202403 for P2944R3, ??? for P3379R0
+v = 202411;
+cxxmin = 23;
+extra_cond = "__glibcxx_three_way_comparison";
+  };
+  values = {
+v = 202403;
 cxxmin = 20;
 extra_cond = "__glibcxx_three_way_comparison";
   };
diff --git a/libstdc++-v3/include/bits/version.h 
b/libstdc++-v3/include/bits/version.h
index f05c3fd13c0..04c1349c84b 100644
--- a/libstdc++-v3/include/bits/version.h
+++ b/libstdc++-v3/include/bits/version.h
@@ -1406,11 +1406,16 @@
 #undef __glibcxx_want_constexpr_vector
 
 #if !defined(__cpp_lib_constrained_equality)
-# if (__cplusplus >= 202002L) && (__glibcxx_three_way_comparison)
+# if (__cplusplus >= 202100L) && (__glibcxx_three_way_comparison)
 #  define __glibcxx_constrained_equality 202411L
 #  if defined(__glibcxx_want_all) || 
defined(__glibcxx_want_constrained_equality)
 #   define __cpp_lib_constrained_equality 202411L
 #  endif
+# elif (__cplusplus >= 202002L) && (__glibcxx_three_way_comparison)
+#  define __glibcxx_constrained_equality 202403L
+#  if defined(__glibcxx_want_all) || 
defined(__glibcxx_want_constrained_equality)
+#   define __cpp_lib_constrained_equality 202403L
+#  endif
 # endif
 #endif /* !defined(__cpp_lib_constrained_equality) && 
defined(__glibcxx_want_constrained_equality) */
 #undef __glibcxx_want_constrained_equality
diff --git a/libstdc++-v3/testsuite/20_util/expected/equality_constrained.cc 
b/libstdc++-v3/testsuite/20_util/expected/equality_constrained.cc
index 7f6cefae748..a079d98129f 100644
--- a/libstdc++-v3/testsuite/20_util/expected/equality_constrained.cc
+++ b/libstdc++-v3/testsuite/20_util/expected/equality_constrained.cc
@@ -4,7 +4,7 @@
 
 #ifndef __cpp_lib_constrained_equality
 # error "Feature-test macro for constrained_equality missing in "
-#elif __cpp_lib_constrained_equality < 202411L // TODO: use final value
+#elif __cpp_lib_constrained_equality < 202411L
 # error "Feature-test macro for constrained_equality has wrong value"
 #endif
 
-- 
2.49.0

[PATCH] libstdc++: Use constexpr-if for std::basic_string::_S_copy_chars

[Jonathan Wakely]

For C++11 and later we can remvoe four overloads of _S_copy_chars and
use constexpr-if in the generic _S_copy_chars. This simplifies overload
resolution for _S_copy_chars, and also means that we optimize for other
iterators such as std::vector::iterator.

We still need all the _S_copy_chars overloads to be part of the explicit
instantiation definition, so make them depend on the macro that is
defined by src/c++11/string-inst.cc for that purpose.

libstdc++-v3/ChangeLog:

* include/bits/basic_string.h (_S_copy_chars): Replace overloads
with constexpr-if and extend optimization to all contiguous
iterators.
* src/c++11/string-inst.cc: Extend comment.
---

Tested x86_64-linux.

 libstdc++-v3/include/bits/basic_string.h | 31 ++--
 libstdc++-v3/src/c++11/string-inst.cc|  3 ++-
 2 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/libstdc++-v3/include/bits/basic_string.h 
b/libstdc++-v3/include/bits/basic_string.h
index 886e7e6b19e..067c7915c76 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -468,6 +468,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
  traits_type::assign(__d, __n, __c);
   }
 
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wc++17-extensions"
   // _S_copy_chars is a separate template to permit specialization
   // to optimize for the common case of pointers as iterators.
   template
@@ -475,31 +477,44 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 static void
 _S_copy_chars(_CharT* __p, _Iterator __k1, _Iterator __k2)
 {
+#if __cplusplus >= 201103L
+ using _IterBase = decltype(std::__niter_base(__k1));
+ if constexpr (__or_,
+ is_same<_IterBase, const _CharT*>>::value)
+   _S_copy(__p, std::__niter_base(__k1), __k2 - __k1);
+#if __cpp_lib_concepts
+ else if constexpr (contiguous_iterator<_Iterator>
+  && is_same_v, _CharT>)
+   {
+ const auto __d = __k2 - __k1;
+ (void) (__k1 + __d); // See P3349R1
+ _S_copy(__p, std::to_address(__k1), static_cast(__d));
+   }
+#endif
+ else
+#endif
  for (; __k1 != __k2; ++__k1, (void)++__p)
traits_type::assign(*__p, *__k1); // These types are off.
}
+#pragma GCC diagnostic pop
 
-  _GLIBCXX20_CONSTEXPR
+#if __cplusplus < 201103L || defined _GLIBCXX_DEFINING_STRING_INSTANTIATIONS
   static void
-  _S_copy_chars(_CharT* __p, iterator __k1, iterator __k2) 
_GLIBCXX_NOEXCEPT
+  _S_copy_chars(_CharT* __p, iterator __k1, iterator __k2)
   { _S_copy_chars(__p, __k1.base(), __k2.base()); }
 
-  _GLIBCXX20_CONSTEXPR
   static void
   _S_copy_chars(_CharT* __p, const_iterator __k1, const_iterator __k2)
-  _GLIBCXX_NOEXCEPT
   { _S_copy_chars(__p, __k1.base(), __k2.base()); }
 
-  _GLIBCXX20_CONSTEXPR
   static void
-  _S_copy_chars(_CharT* __p, _CharT* __k1, _CharT* __k2) _GLIBCXX_NOEXCEPT
+  _S_copy_chars(_CharT* __p, _CharT* __k1, _CharT* __k2)
   { _S_copy(__p, __k1, __k2 - __k1); }
 
-  _GLIBCXX20_CONSTEXPR
   static void
   _S_copy_chars(_CharT* __p, const _CharT* __k1, const _CharT* __k2)
-  _GLIBCXX_NOEXCEPT
   { _S_copy(__p, __k1, __k2 - __k1); }
+#endif
 
   _GLIBCXX20_CONSTEXPR
   static int
diff --git a/libstdc++-v3/src/c++11/string-inst.cc 
b/libstdc++-v3/src/c++11/string-inst.cc
index c4864794d40..34df909b31a 100644
--- a/libstdc++-v3/src/c++11/string-inst.cc
+++ b/libstdc++-v3/src/c++11/string-inst.cc
@@ -40,7 +40,8 @@
 // replaced by constrained function templates, so that we instantiate the
 // pre-C++17 definitions.
 // This also causes the instantiation of the non-standard C++0x-era
-// insert(iterator, initializer_list) overload, see PR libstdc++/83328
+// insert(iterator, initializer_list) overload, see PR libstdc++/83328,
+// and overloads of _S_copy_chars for string iterators and pointers.
 #define _GLIBCXX_DEFINING_STRING_INSTANTIATIONS 1
 
 #include 
-- 
2.49.0

Re: [PATCH v4] libstdc++: Implement debug format for strings and characters formatters [PR109162]

[Jonathan Wakely]

On 10/04/25 11:24 +0200, Tomasz Kamiński wrote:

This patch implements part P2286R8 that specified debug (escaped)
format for the strings and characters sequences. This include both
handling of the '?' format specifier and set_debug_format member.

To indicate partial support we define __glibcxx_format_ranges macro
value 1, without defining __cpp_lib_format_ranges.

We provide two separate escaping routines depending on the literal
encoding for the corresponding character types. If the character
encoding is Unicode, we follow the specification for the standard
(__format::__write_escaped_unicode).
For other encodings, we escape only characters in range [0x00, 0x80),
interpreting them as ACII values: [0x00, 0x20), 0x7f and  '\t', '\r',


"ASCII"


'\n', '\\', '"', '\'' are escaped. We assume every character outside
this range is printable (__format::_write_escaped_ascii).
In particular we do not yet implement special handling of shift
sequences.

For Unicode escaping a new __escape_edges table is introduced,
that encodes information if character belongs to General_Category
that is escaped by the standard (Control or Other). This table
is generated from DerivedGeneralCategory.txt provided by Unicode.
Only boolean flag is preserved to reduce the number of entires.


"entries"


The additional rules for escaping are handled by __should_escape_unicode.

When width or precision is specified, we emit escaped string to the temporary
buffer and format the resulting string according to the format spec.
For characters use a fixed size stack buffer, for which a new _Fixedbuf_sink is
introduced. For strings, we use _Str_sink and to avoid allocations,
we compute the estimated size of (possibly truncated) input, and if it is
larger than width field we print directly.

PR libstdc++/109162

contrib/ChangeLog:

* unicode/README: Mentioned DerivedGeneralCategory.txt.
* unicode/gen_libstdcxx_unicode_data.py: Generation __escape_edges
table from DerivedGeneralCategory.txt. Update file name in comments.
* unicode/DerivedGeneralCategory.txt: Copy of file distrubuted by


"distributed"


Unicode Consortium.

ftp://ftp.unicode.org/Public/UNIDATA/extracted/DerivedGeneralCategory.txt.



I still don't think we want the URL in the ChangeLog.


libstdc++-v3/ChangeLog:

* include/bits/chrono_io.h (__detail::_Widen): Moved to std/format file.
* include/bits/unicode-data.h: Regnerate.
* include/bits/unicode.h (__unicode::_Utf_iterator::_M_units)
(__unicode::__should_escape_category): Define.


What happened to the changes to bits/version.def and bits/version.h ?

I thought you were going to change version.def to use no_stdname but
now it's not in the patch at all.


* include/std/format (_GLIBCXX_WIDEN_, _GLIBCXX_WIDEN): Copied from
include/bits/chrono_io.h.
(__format::_Widen): Moved from include/bits/chrono_io.h.
(__format::_Term_char, __format::_Escapes, __format::_Separators)
(__format::__should_escape_ascii, __format::__should_escape_unicode)
(__format::__write_escape_seq, __format::__write_escaped_char)
(__format::__write_escaped_acii, __format::__write_escaped_unicode)
(__format::__write_escaped): Define.
(__formatter_str::_S_format): Extracted truncation of character
sequences.
(__formatter_str::format): Handle _Pres_esc.
(__formatter_int::_M_do_parse) [__glibcxx_format_ranges]: Parse '?'.
(__formatter_int::_M_format_character_escaped): Define.
(formatter<_CharT, _CharT>::format, formatter::format):
Handle _Pres_esc.
(__formatter_str::set_debug_format, formatter<...>::set_debug_format)
Guard with __glibcxx_format_ranges.
(__format::_Fixedbuf_sink): Define.
* testsuite/std/format/debug.cc: New test.
* testsuite/std/format/debug_nonunicode.cc: New test.
* testsuite/std/format/parse_ctx.cc (escaped_strings_supported): Define
to true if __glibcxx_format_ranges is defined.
* testsuite/std/format/string.cc (escaped_strings_supported): Define to
 true if __glibcxx_format_ranges is defined.
---
This I believe address all review suggestions. I have also followed
Patrick's suggestions and added debug_nonunicode.cc test file.
Which helped to surface problem, where _GLIBCXX_WIDEN("\D") was
ill-formed for non-unicode encodings.

contrib/unicode/DerivedGeneralCategory.txt| 4323 +
contrib/unicode/README|3 +-
contrib/unicode/gen_libstdcxx_unicode_data.py |   47 +-
libstdc++-v3/include/bits/chrono_io.h |   16 +-
libstdc++-v3/include/bits/unicode-data.h  |  260 +-
libstdc++-v3/include/bits/unicode.h   |   17 +
libstdc++-v3/include/std/format   |  492 +-
.../23_containers/vector/bool/format.cc   |3 +-
libstdc++-v3/testsuite/std/format/debug.cc|  454 ++
.../testsuite/std/format/deb

RE: [committed] cobol: Proper comparison of alphanumeric to refmoded numeric-display [PR119682]

[Robert Dubner]

I just pushed another eleven testcases, one of which is inspired by the 
original PR.

> -Original Message-
> From: Richard Biener 
> Sent: Thursday, April 10, 2025 01:14
> To: Robert Dubner 
> Cc: Patches GCC 
> Subject: Re: [committed] cobol: Proper comparison of alphanumeric to
> refmoded numeric-display [PR119682]
>
>
>
> > Am 09.04.2025 um 23:19 schrieb Robert Dubner :
> >
> > This patch eliminates the error.
> >
> >cobol: Proper comparison of alphanumeric to refmoded numeric-display
> > [PR119682]
>
> Can you add the testcase as part of the fix?
>
> >gcc/cobol
> >
> >PR cobol/119682
> >* genapi.cc: (cobol_compare): Change the call to
> > __gg__compare().
> >
> >libgcobol
> >
> >PR cobol/119682
> >* common-defs.h: Define the REFER_T_REFMOD constant.
> >* intrinsic.cc: (__gg__max): Change the calls to
> > __gg__compare_2(),
> >(__gg__min): Likewise, (__gg__ord_min): Likewise,
> >(__gg__ord_max): Likewise.
> >* libgcobol.cc: (__gg__compare_2): Change definition of
> > calling
> >parameters, eliminate separate flag bit for ALL and
> > ADDRESS_OF,
> >change comparison of alphanumeric to numeric when the numeric
> >is a refmod.
> >* libgcobol.h: Change declaration of __gg__compare_2.
> >
> > diff --git a/gcc/cobol/genapi.cc b/gcc/cobol/genapi.cc
> > index c91237bd8d2c..fdf76aad7b14 100644
> > --- a/gcc/cobol/genapi.cc
> > +++ b/gcc/cobol/genapi.cc
> > @@ -2028,10 +2028,12 @@ cobol_compare(  tree return_int,
> > {
> > // None of our explicit comparisons up above worked, so we revert to
> > the
> > // general case:
> > -int leftflags  =   (left_side_ref.all  ? REFER_T_MOVE_ALL : 0)
> > -+  (left_side_ref.addr_of  ? REFER_T_ADDRESS_OF :
> 0);
> > -int rightflags =   (right_side_ref.all ? REFER_T_MOVE_ALL : 0)
> > -+  (right_side_ref.addr_of ? REFER_T_ADDRESS_OF :
> 0);
> > +int leftflags  =   (left_side_ref.all  ? REFER_T_MOVE_ALL
> :
> > 0)
> > ++  (left_side_ref.addr_of  ? REFER_T_ADDRESS_OF
> :
> > 0)
> > ++  (left_side_ref.refmod.from  ? REFER_T_REFMOD
> :
> > 0);
> > +int rightflags =   (right_side_ref.all ? REFER_T_MOVE_ALL
> :
> > 0)
> > ++  (right_side_ref.addr_of ? REFER_T_ADDRESS_OF
> :
> > 0)
> > ++  (right_side_ref.refmod.from ? REFER_T_REFMOD
> :
> > 0);
> > gg_assign(  return_int, gg_call_expr(
> > INT,
> > "__gg__compare",
> > @@ -2045,6 +2047,7 @@ cobol_compare(  tree return_int,
> > build_int_cst_type(INT, rightflags),
> > integer_zero_node,
> > NULL_TREE));
> > +compared = true;
> > }
> >
> > //  gg_printf("   result is %d\n", return_int, NULL_TREE);
> > diff --git a/libgcobol/common-defs.h b/libgcobol/common-defs.h
> > index f9d9c56a0d8d..6bf32ef79cf0 100644
> > --- a/libgcobol/common-defs.h
> > +++ b/libgcobol/common-defs.h
> > @@ -70,6 +70,7 @@
> > #define REFER_T_ALL_FLAGS_MASK 0x0FF  // We allow for seven subscripts
> > #define REFER_T_MOVE_ALL   0x100  // This is the move_all flag
> > #define REFER_T_ADDRESS_OF 0x200  // This is the address_of flag
> > +#define REFER_T_REFMOD 0x400  // Indicates to library the refer
> > was a refmod
> >
> > #define MIN_FIELD_BLOCK_SIZE (16)
> >
> > diff --git a/libgcobol/intrinsic.cc b/libgcobol/intrinsic.cc
> > index 4bce481b0c04..e0bd3339708e 100644
> > --- a/libgcobol/intrinsic.cc
> > +++ b/libgcobol/intrinsic.cc
> > @@ -1867,8 +1867,7 @@ __gg__max(cblc_field_t *dest,
> > unsigned char *best_location   ;
> > size_t best_length ;
> > intbest_attr   ;
> > -bool   best_move_all   ;
> > -bool   best_address_of ;
> > +intbest_flags  ;
> >
> > bool first_time = true;
> > assert(ncount);
> > @@ -1887,8 +1886,7 @@ __gg__max(cblc_field_t *dest,
> >   best_location   = __gg__treeplet_1f[i]->data +
> > __gg__treeplet_1o[i];
> >   best_length = __gg__treeplet_1s[i];
> >   best_attr   = __gg__treeplet_1f[i]->attr;
> > -  best_move_all   = !!(__gg__fourplet_flags[i] &
> > REFER_T_MOVE_ALL);
> > -  best_address_of = !!(__gg__fourplet_flags[i] &
> > REFER_T_ADDRESS_OF);
> > +  best_flags  = __gg__fourplet_flags[i];
> >   }
> > else
> >   {
> > @@ -1896,31 +1894,27 @@ __gg__max(cblc_field_t *dest,
> >   unsigned char *candidate_location   =
> > __gg__treeplet_1f[i]->data + __gg__treeplet_1o[i];
> >   size_t candidate_length = __gg__treeplet_1s[i];
> >   intcandidate_attr   =
> > __gg__treeplet_1f[i]->attr;
> > -  bool   candidate_move_all   =
> > !!(__gg__fourplet_flags[i] & REFER_T

Re: [PATCH] c++: alias_ctad_tweaks ICE w/ inherited CTAD [PR119687]

[Jason Merrill]

On 4/9/25 11:11 AM, Patrick Palka wrote:

Bootstrap and regtest running on x86_64-pc-linux-gnu, does this look
OK for trunk/14 if successful?


OK.


On a similar note, as a small optimization in deduction_guides_for I
think we can replace the lookup_add loop with a single call to
lookup_add, but I'll leave that for GCC 16.

-- >8 --

With inherited CTAD the set of guides may be a two-dimensional overload
set (i.e. OVERLOADs containing OVERLOADs) so alias_ctad_tweaks (which
also handles the inherited CTAD transformation) needs to use the 2D-aware
lkp_iterator instead of ovl_iterator.  Actually, we might as well use
the more idiomatic lkp_range here.

PR c++/119687

gcc/cp/ChangeLog:

* pt.cc (alias_ctad_tweaks): Use lkp_range / lkp_iterator
instead of ovl_iterator.

gcc/testsuite/ChangeLog:

* g++.dg/cpp23/class-deduction-inherited8.C: New test.
---
  gcc/cp/pt.cc  |  3 +--
  .../g++.dg/cpp23/class-deduction-inherited8.C | 21 +++
  2 files changed, 22 insertions(+), 2 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp23/class-deduction-inherited8.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index ffd23d9cd13b..c73db02e42e1 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -30922,9 +30922,8 @@ alias_ctad_tweaks (tree tmpl, tree uguides)
tree aguides = NULL_TREE;
tree atparms = INNERMOST_TEMPLATE_PARMS (fullatparms);
unsigned natparms = TREE_VEC_LENGTH (atparms);
-  for (ovl_iterator iter (uguides); iter; ++iter)
+  for (tree f : lkp_range (uguides))
  {
-  tree f = *iter;
tree in_decl = f;
location_t loc = DECL_SOURCE_LOCATION (f);
tree ret = TREE_TYPE (TREE_TYPE (f));
diff --git a/gcc/testsuite/g++.dg/cpp23/class-deduction-inherited8.C 
b/gcc/testsuite/g++.dg/cpp23/class-deduction-inherited8.C
new file mode 100644
index ..79fceadd9e1c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp23/class-deduction-inherited8.C
@@ -0,0 +1,21 @@
+// PR c++/119687
+// { dg-do compile { target c++20 } }
+
+template  class QFlagsStorage{};
+
+template  struct QFlagsStorageHelper : QFlagsStorage  {
+  using QFlagsStorage::QFlagsStorage;
+
+public:
+  QFlagsStorageHelper(Enum);
+};
+
+template  struct QFlags : public QFlagsStorageHelper {
+  using Base = QFlagsStorageHelper;
+  using Base::Base;
+  QFlags(Enum);
+};
+
+void f(int flag) {
+  QFlags{int{}};
+}

Re: [PATCH] testsuite: Add support for GCOV_UNDER_TEST

[Hans-Peter Nilsson]

> From: Christophe Lyon 
> Date: Thu, 10 Apr 2025 15:38:48 +0200

> On Thu, 10 Apr 2025 at 15:29, Hans-Peter Nilsson  wrote:
> >
> > > From: Christophe Lyon 
> > > Date: Thu, 10 Apr 2025 15:21:23 +0200
> >
> > Not sure why I'm CC:ed on this one, not being a maintainer
> > of the testsuite or targets where gcov tests are exercised,
> 
> Because you fixed a problem in r13-4103-ge91d51457532da,
> so I wanted to make sure my patch was OK for you.

I've forgot everything about that commit and the context. :}

So, I now had an extra glance from the transform-name
perspective: still ok.

brgds, H-P

[Fortran, Patch, Team, 4/5] Add team-support to this_image [PR87326]

[Andre Vehreschild]

Hi all,

attached patch reworks the implementation of THIS_IMAGE() to adhere as much as
possible to the Fortran 2018 standard.

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

Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From c6da27813d7a7622cae2663af7e25d21e7a34661 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild 
Date: Tue, 1 Apr 2025 12:17:43 +0200
Subject: [PATCH 4/6] Fortran: Add team-support to this_image [PR87326]

This_image() no longer has a distance formal argument, but a team one.
The source of the distance argument could not be identified, i.e.
whether it came from a TS or standard draft.  To implement only the
standard it is removed.  Besides being defined, it was not used anyway.

	PR fortran/87326

gcc/fortran/ChangeLog:

	* check.cc (gfc_check_this_image): Check the three different
	parameter lists possible for this_image and sort them correctly.
	* gfortran.texi: Update documentation on this_image's API.
	* intrinsic.cc (add_functions): Update this_image's signature.
	(check_specific): Add specific check for this_image.
	* intrinsic.h (gfc_check_this_image): Change to flexible
	argument list.
	* intrinsic.texi: Update documentation on this_image().
	* iresolve.cc (gfc_resolve_this_image): Resolve the different
	arguments.
	* simplify.cc (gfc_simplify_this_image): Simplify the simplify
	routine.
	* trans-decl.cc (gfc_build_builtin_function_decls): Update
	signature of this_image.
	* trans-expr.cc (gfc_caf_get_image_index): Use correct signature
	of this_image.
	* trans-intrinsic.cc (trans_this_image): Adapt to correct
	signature.

libgfortran/ChangeLog:

	* caf/libcaf.h (_gfortran_caf_this_image): Correct prototype.
	* caf/single.c (struct caf_single_team): Add new_index of image.
	(_gfortran_caf_this_image): Return the image index in the given team.
	(_gfortran_caf_form_team): Set new_index in team structure.

gcc/testsuite/ChangeLog:

	* gfortran.dg/coarray_10.f90: Update error messages.
	* gfortran.dg/coarray_lib_this_image_1.f90: Same.
	* gfortran.dg/coarray_lib_this_image_2.f90: Same.
	* gfortran.dg/coarray_this_image_1.f90: Add more tests and
	remove incorrect ones.
	* gfortran.dg/coarray_this_image_2.f90: Test more features.
	* gfortran.dg/coarray_this_image_3.f90: New test.
---
 gcc/fortran/check.cc  | 122 --
 gcc/fortran/gfortran.texi |  16 ++-
 gcc/fortran/intrinsic.cc  |  12 +-
 gcc/fortran/intrinsic.h   |   2 +-
 gcc/fortran/intrinsic.texi|  30 ++---
 gcc/fortran/iresolve.cc   |  23 +++-
 gcc/fortran/simplify.cc   |   7 +-
 gcc/fortran/trans-decl.cc |   6 +-
 gcc/fortran/trans-expr.cc |   6 +-
 gcc/fortran/trans-intrinsic.cc|  39 +++---
 gcc/testsuite/gfortran.dg/coarray_10.f90  |   2 +-
 .../gfortran.dg/coarray_lib_this_image_1.f90  |   2 +-
 .../gfortran.dg/coarray_lib_this_image_2.f90  |   2 +-
 .../gfortran.dg/coarray_this_image_1.f90  |  49 ++-
 .../gfortran.dg/coarray_this_image_2.f90  |  52 +++-
 .../gfortran.dg/coarray_this_image_3.f90  |  34 +
 libgfortran/caf/libcaf.h  |   2 +-
 libgfortran/caf/single.c  |  13 +-
 18 files changed, 290 insertions(+), 129 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/coarray_this_image_3.f90

diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index a1c3de3e80d..c27f653d3b0 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -6665,75 +6665,115 @@ gfc_check_team_number (gfc_expr *team)


 bool
-gfc_check_this_image (gfc_expr *coarray, gfc_expr *dim, gfc_expr *distance)
+gfc_check_this_image (gfc_actual_arglist *args)
 {
+  gfc_expr *coarray, *dim, *team, *cur;
+
+  coarray = dim = team = NULL;
+
   if (flag_coarray == GFC_FCOARRAY_NONE)
 {
   gfc_fatal_error ("Coarrays disabled at %C, use %<-fcoarray=%> to enable");
   return false;
 }

-  if (coarray == NULL && dim == NULL && distance == NULL)
+  /* Shortcut when no arguments are given.  */
+  if (!args->expr && !args->next->expr && !args->next->next->expr)
 return true;

-  if (dim != NULL && coarray == NULL)
-{
-  gfc_error ("DIM argument without COARRAY argument not allowed for "
-		 "THIS_IMAGE intrinsic at %L", &dim->where);
-  return false;
-}
+  cur = args->expr;

-  if (distance && (coarray || dim))
+  if (cur)
 {
-  gfc_error ("The DISTANCE argument may not be specified together with the "
-		 "COARRAY or DIM argument in intrinsic at %L",
-		 &distance->where);
-  return false;
+  gfc_push_suppress_errors ();
+  if (coarray_check (cur, 0))
+	coarray = cur;
+  else if (scalar_check (cur, 2) && team_type_check (cur, 2))
+	team = cur;
+  else
+	{
+	  gfc_pop_suppress_errors ();
+	  gfc_error ("First argument of % intrinsic at %L must be "
+		 "a coarray "
+		 "va

[PATCH] testsuite: arm: rename arm_v8_1_lob_ok into arm_v8_1_lob_hw

[Christophe Lyon]

All arm effective-targets using check_runtime use the "_hw" or
"_multilib" suffix, so rename arm_v8_1_lob_ok into arm_v8_1_lob_hw for
consistency.

gcc/testsuite/ChangeLog

* lib/target-supports.exp: Rename arm_v8_1_lob_ok into
arm_v8_1_lob_hw.
* gcc.target/arm/lob1.c: Likewise.
* gcc.target/arm/lob6.c: Likewise.
---
 gcc/testsuite/gcc.target/arm/lob1.c   | 2 +-
 gcc/testsuite/gcc.target/arm/lob6.c   | 2 +-
 gcc/testsuite/lib/target-supports.exp | 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/lob1.c 
b/gcc/testsuite/gcc.target/arm/lob1.c
index c8ce653a5c3..b97dafa3512 100644
--- a/gcc/testsuite/gcc.target/arm/lob1.c
+++ b/gcc/testsuite/gcc.target/arm/lob1.c
@@ -1,7 +1,7 @@
 /* Check that GCC generates Armv8.1-M low over head loop instructions
for some simple loops.  */
 /* { dg-do run } */
-/* { dg-require-effective-target arm_v8_1_lob_ok } */
+/* { dg-require-effective-target arm_v8_1_lob_hw } */
 /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } } */
 /* { dg-options "-march=armv8.1-m.main -mthumb -O3 --save-temps" } */
 #include 
diff --git a/gcc/testsuite/gcc.target/arm/lob6.c 
b/gcc/testsuite/gcc.target/arm/lob6.c
index 4fe116e2c2b..cef9d93ee4d 100644
--- a/gcc/testsuite/gcc.target/arm/lob6.c
+++ b/gcc/testsuite/gcc.target/arm/lob6.c
@@ -1,7 +1,7 @@
 /* Check that GCC generates Armv8.1-M low over head loop instructions
with some less trivial loops and the result is correct.  */
 /* { dg-do run } */
-/* { dg-require-effective-target arm_v8_1_lob_ok } */
+/* { dg-require-effective-target arm_v8_1_lob_hw } */
 /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } } */
 /* { dg-options "-march=armv8.1-m.main -mthumb -O3 --save-temps" } */
 #include 
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index bc4361d6092..d8e28db45de 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -13562,7 +13562,7 @@ proc check_effective_target_arm_v8_3a_bkey_directive { 
} {
 # Return 1 if the target supports executing the Armv8.1-M Mainline Low
 # Overhead Loop, 0 otherwise.  The test is valid for ARM.
 
-proc check_effective_target_arm_v8_1_lob_ok { } {
+proc check_effective_target_arm_v8_1_lob_hw { } {
 if { ![check_effective_target_arm_cortex_m] } {
return 0;
 } else {
@@ -13588,7 +13588,7 @@ proc check_effective_target_arm_v8_1_lob_ok { } {
 
 proc check_effective_target_arm_thumb2_no_arm_v8_1_lob { } {
 if { [check_effective_target_arm_thumb2]
-&& ![check_effective_target_arm_v8_1_lob_ok] } {
+&& ![check_effective_target_arm_v8_1_lob_hw] } {
return 1
 }
 return 0
@@ -13600,7 +13600,7 @@ proc check_effective_target_arm_thumb2_no_arm_v8_1_lob 
{ } {
 
 proc check_effective_target_arm_thumb2_ok_no_arm_v8_1_lob { } {
 if { [check_effective_target_arm_thumb2_ok]
-&& ![check_effective_target_arm_v8_1_lob_ok] } {
+&& ![check_effective_target_arm_v8_1_lob_hw] } {
return 1
 }
 return 0
-- 
2.34.1

[PATCH] c++/modules: More fixes for merging DECL_MAYBE_DELETED functions

[Nathaniel Shead]

Regression raised with my by private correspondance.
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?

-- >8 --

My change in r15-9216 broke the case where we imported an uninstantiated
defaulted function over the top of one we had already finished.  This
patch ensures that we don't error for mismatches when either function
has mismatching deferral from the other.

To assist in understanding these errors in the future as well, I've
customised the mismatch message for different cases.  I also rephrased
the message to talk about "imported declarations" rather than "global
module declarations", since as the FIXME noted we can also get
mismatches with some declarations attached to modules.  Ideally I'd like
to revisit the way this is structured entirely but that won't be
appropriate for GCC 15.

gcc/cp/ChangeLog:

* module.cc (trees_in::is_matching_decl): Handle all mismatching
DECL_MAYBE_DELETED.  Add custom errors for different kinds of
mismatches.

gcc/testsuite/ChangeLog:

* g++.dg/modules/lambda-8_b.C: Adjust error message.
* g++.dg/modules/leg-merge-4_c.C: Likewise.
* g++.dg/modules/noexcept-4_a.H: New test.
* g++.dg/modules/noexcept-4_b.C: New test.

Signed-off-by: Nathaniel Shead 
---
 gcc/cp/module.cc | 66 +++-
 gcc/testsuite/g++.dg/modules/lambda-8_b.C|  2 +-
 gcc/testsuite/g++.dg/modules/leg-merge-4_c.C |  6 +-
 gcc/testsuite/g++.dg/modules/noexcept-4_a.H  |  6 ++
 gcc/testsuite/g++.dg/modules/noexcept-4_b.C  | 17 +
 5 files changed, 77 insertions(+), 20 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/modules/noexcept-4_a.H
 create mode 100644 gcc/testsuite/g++.dg/modules/noexcept-4_b.C

diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 37fab5b5a43..ad3cd85b005 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -12090,6 +12090,8 @@ trees_in::is_matching_decl (tree existing, tree decl, 
bool is_typedef)
   gcc_checking_assert (TREE_CODE (e_inner) == TREE_CODE (d_inner));
 }
 
+  // FIXME: do more precise errors at point of mismatch
+  const char *mismatch_msg = nullptr;
   if (TREE_CODE (d_inner) == FUNCTION_DECL)
 {
   tree e_ret = fndecl_declared_return_type (existing);
@@ -12099,13 +12101,20 @@ trees_in::is_matching_decl (tree existing, tree decl, 
bool is_typedef)
  && LAMBDA_TYPE_P (DECL_CONTEXT (d_inner)))
/* This has a recursive type that will compare different.  */;
   else if (!same_type_p (d_ret, e_ret))
-   goto mismatch;
+   {
+ mismatch_msg = G_("conflicting type for imported declaration %#qD");
+ goto mismatch;
+   }
 
   tree e_type = TREE_TYPE (e_inner);
   tree d_type = TREE_TYPE (d_inner);
 
   if (DECL_EXTERN_C_P (d_inner) != DECL_EXTERN_C_P (e_inner))
-   goto mismatch;
+   {
+ mismatch_msg = G_("conflicting language linkage for imported "
+   "declaration %#qD");
+ goto mismatch;
+   }
 
   for (tree e_args = TYPE_ARG_TYPES (e_type),
 d_args = TYPE_ARG_TYPES (d_type);
@@ -12113,10 +12122,18 @@ trees_in::is_matching_decl (tree existing, tree decl, 
bool is_typedef)
   e_args = TREE_CHAIN (e_args), d_args = TREE_CHAIN (d_args))
{
  if (!(e_args && d_args))
-   goto mismatch;
+   {
+ mismatch_msg = G_("conflicting argument list for imported "
+   "declaration %#qD");
+ goto mismatch;
+   }
 
  if (!same_type_p (TREE_VALUE (d_args), TREE_VALUE (e_args)))
-   goto mismatch;
+   {
+ mismatch_msg = G_("conflicting argument types for imported "
+   "declaration %#qD");
+ goto mismatch;
+   }
}
 
   /* If EXISTING has an undeduced or uninstantiated exception
@@ -12125,7 +12142,8 @@ trees_in::is_matching_decl (tree existing, tree decl, 
bool is_typedef)
 instantiate it in the middle of loading.   */
   tree e_spec = TYPE_RAISES_EXCEPTIONS (e_type);
   tree d_spec = TYPE_RAISES_EXCEPTIONS (d_type);
-  if (DECL_MAYBE_DELETED (e_inner) || DEFERRED_NOEXCEPT_SPEC_P (e_spec))
+  if (DEFERRED_NOEXCEPT_SPEC_P (e_spec)
+ || DECL_MAYBE_DELETED (d_inner) != DECL_MAYBE_DELETED (e_inner))
{
  if (!DEFERRED_NOEXCEPT_SPEC_P (d_spec)
  || (UNEVALUATED_NOEXCEPT_SPEC_P (e_spec)
@@ -12149,7 +12167,11 @@ trees_in::is_matching_decl (tree existing, tree decl, 
bool is_typedef)
}
   else if (!DEFERRED_NOEXCEPT_SPEC_P (d_spec)
   && !comp_except_specs (d_spec, e_spec, ce_type))
-   goto mismatch;
+   {
+ mismatch_msg = G_("conflicting % specifier for "
+   "imported declaration %#qD");
+ goto mismatch;
+   }
 
   /* Similarly if EXISTING has an undeduced return type, but DECL's
 is already deduced

Re: .ACCESS_WITH_SIZE and pointer ranges

[Andrew MacLeod]

On 4/8/25 13:13, Siddhesh Poyarekar wrote:

On 2025-04-08 12:41, Qing Zhao wrote:

For the following small example:

[ counted_by_whole]$ cat t.c
#include 
#include 

struct annotated {
   size_t count;
   char other;
   char array[] __attribute__((counted_by (count)));
};

#define MAX(A, B) (A > B) ? (A) : (B)
#define ALLOC_SIZE_ANNOTATED(COUNT) \
   MAX(sizeof (struct annotated), \
   offsetof(struct annotated, array[0]) + (COUNT) * sizeof(char))

static struct annotated * __attribute__((__noinline__)) alloc_buf 
(int index)

{
   struct annotated *p;
   p = (struct annotated *) malloc (ALLOC_SIZE_ANNOTATED(index));
   p->count = index;
   return p;
}

int main()
{
   struct annotated *q = alloc_buf (10);
   __builtin_printf ("the bdos whole is %d\n", 
__builtin_dynamic_object_size(q, 1));

   return 0;
}

The gimple IR is:

   1 int main ()
   2 {
   3   int D.5072;
   4
   5   {
   6 struct annotated * q;
   7
   8 q = alloc_buf (10);
   9 _1 = __builtin_dynamic_object_size (q, 1);
  10 __builtin_printf ("the bdos whole is %d\n", _1);
  11 D.5072 = 0;
  12 return D.5072;
  13   }
  14   D.5072 = 0;
  15   return D.5072;
  16 }
  17
  18
  19 __attribute__((noinline))
  20 struct annotated * alloc_buf (int index)
  21 {
  22   struct annotated * D.5074;
  23   struct annotated * p;
  24   25   _1 = (long unsigned int) index;
  26   _2 = _1 + 9;
  27   _3 = MAX_EXPR <_2, 16>;
  28   p = malloc (_3);
  29   _4 = (long unsigned int) index;
  30   p->count = _4;
  31   D.5074 = p;
  32   return D.5074;
  33 }

When we generate the .ACCESS_WITH_SIZE for a pointer reference to 
“struct annotated”,
Looks like all the pointer references, at line 8, “q”,  at line 9, 
“q”, at line 28, “p”, need to be changed
to a call to .ACCESS_WITH_SIZE. this might increase the IR size 
unnecessarily.   Might have some
Impact on the inlining decision heuristics or other heuristic that 
depend on the code size.


Not sure whether this is a concern or not.



On the general question of whether additional .ACCESS_WITH_SIZE could 
hinder optimizations, one effect may be that it ends up acting as a 
barrier preventing code reordering around it, which may miss some 
opportunities.  However IMO that preserves correctness anyway.


On the other hand though, .ACCESS_WITH_SIZE should ideally provide 
range information that could aid optimization or even diagnostics.  
It's not something we do at the moment AFAIK though, except when 
.ACCESS_WITH_SIZE feeds directly into a __bos/__bdos call, in which 
case the __bos/__bdos call ends up providing that hint (I think).


Andrew, is this something pranger could explicitly identify?  That is, 
use .ACCESS_WITH_SIZE calls to identify the range of the pointer it is 
called with?



Its not clear to me exactly what is being asked, but I think the 
suggestion is that pointer references are being replaced with a builtin 
function called .ACCESS_WITH_SIZE ?    and I presume that builtin 
function has some parameters that give you relevant range information of 
some sort?


range-ops is setup to pull range information from builtin functions 
already in gimple-range-op.cc:: 
gimple_range_op_handler::maybe_builtin_call ().  We'd just need to write 
a handler for this new one.  You can pull information from 2 operands 
under normal circumstances, but exceptions can be made.    I'd need a 
description of what it looks like and how that translates to range info.


Andrew

Re: .ACCESS_WITH_SIZE and pointer ranges

[Siddhesh Poyarekar]

On 2025-04-10 10:50, Andrew MacLeod wrote:
Its not clear to me exactly what is being asked, but I think the 
suggestion is that pointer references are being replaced with a builtin 
function called .ACCESS_WITH_SIZE ?    and I presume that builtin 
function has some parameters that give you relevant range information of 
some sort?


Added, not replaced, but yes, that's essentially it.

range-ops is setup to pull range information from builtin functions 
already in gimple-range-op.cc:: 
gimple_range_op_handler::maybe_builtin_call ().  We'd just need to write 
a handler for this new one.  You can pull information from 2 operands 
under normal circumstances, but exceptions can be made.    I'd need a 
description of what it looks like and how that translates to range info.


That's perfect!  It's probably redundant for cases where we end up with 
both .ACCESS_WITH_SIZE and a __bos/__bdos call, but I don't remember if 
that's the only place where .ACCESS_WITH_SIZE is generated today.  Qing, 
could you please work with Andrew on this?


Thanks,
Sid

Re: [PATCH] c++/modules: More fixes for merging DECL_MAYBE_DELETED functions

[Jason Merrill]

On 4/10/25 8:46 AM, Nathaniel Shead wrote:

Regression raised with my by private correspondance.
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?

-- >8 --

My change in r15-9216 broke the case where we imported an uninstantiated
defaulted function over the top of one we had already finished.  This
patch ensures that we don't error for mismatches when either function
has mismatching deferral from the other.


These changes seem to mean that importing a deferred decl can overwrite 
properties of an existing non-deferred one.



To assist in understanding these errors in the future as well, I've
customised the mismatch message for different cases.  I also rephrased
the message to talk about "imported declarations" rather than "global
module declarations", since as the FIXME noted we can also get
mismatches with some declarations attached to modules.  Ideally I'd like
to revisit the way this is structured entirely but that won't be
appropriate for GCC 15.


Please split these changes into a separate commit; that patch is OK.


@@ -12125,7 +12142,8 @@ trees_in::is_matching_decl (tree existing, tree decl, 
bool is_typedef)
 instantiate it in the middle of loading.   */
tree e_spec = TYPE_RAISES_EXCEPTIONS (e_type);
tree d_spec = TYPE_RAISES_EXCEPTIONS (d_type);
-  if (DECL_MAYBE_DELETED (e_inner) || DEFERRED_NOEXCEPT_SPEC_P (e_spec))
+  if (DEFERRED_NOEXCEPT_SPEC_P (e_spec)
+ || DECL_MAYBE_DELETED (d_inner) != DECL_MAYBE_DELETED (e_inner))
{
  if (!DEFERRED_NOEXCEPT_SPEC_P (d_spec)


If loading a DECL_MAYBE_DELETED decl, I think it will have no eh spec, 
so DEFERRED_NOEXCEPT_SPEC_P will be false, so this will now propagate 
the lack of eh spec to the existing decl.



/* Similarly if EXISTING has undeduced constexpr, but DECL's
 is already deduced.  */
-  if (DECL_MAYBE_DELETED (e_inner) && !DECL_MAYBE_DELETED (d_inner)
- && DECL_DECLARED_CONSTEXPR_P (d_inner))
-   DECL_DECLARED_CONSTEXPR_P (e_inner) = true;
+  if (DECL_MAYBE_DELETED (e_inner) != DECL_MAYBE_DELETED (d_inner))
+   {
+ if (DECL_DECLARED_CONSTEXPR_P (d_inner))
+   DECL_DECLARED_CONSTEXPR_P (e_inner) = true;
+   }


And similarly if decl is MAYBE_DELETED, we will copy its constexpr. 
Though I guess only if it's declared constexpr, which is unlikely to 
cause trouble.  But still, rather than change these two conditions to != 
I'd rather add an else for the reverse mismatch that probably just 
accepts the difference.


Jason

[PATCH] libstdc++: Fix atomic CAS hang with C++11 [PR114865]

[Jonathan Wakely]

The std::atomic constructor clears padding bits so that compare_exchange
will not fail due to differences in padding bits. But we can only do
that for C++14 and later, because in C++11 a constexpr constructor must
have an empty body. However, the code in compare_exchange_strong assumes
that padding is always cleared, and so it fails in C++11 due to non-zero
padding.

Since we can't clear the padding in C++11 mode, we shouldn't assume it's
been cleared when in C++11 mode. This fixes the reported bug. However,
the fix fails to handle the case where the std::atomic is constructed in
C++11 code (and so doesn't zero padding) but the CAS happens in C++14
code (and so assumes padding has been zeroed). We might need to use the
same loop as atomic_ref::compare_exchange_strong to properly fix this
bug for that case.

Although the mixed C++11 / C++14 case isn't fixed, this is still an
incremental improvement. It fixes the pure-C++11 case and doesn't
preclude a more comprehensive fix later.

libstdc++-v3/ChangeLog:

PR libstdc++/114865
* include/bits/atomic_base.h (__maybe_has_padding): Return false
for C++11.
* include/std/atomic (atomic::atomic(T)): Add comment.
* testsuite/29_atomics/atomic/114865.cc: New test.
---

Tested x86_64-linux.

 libstdc++-v3/include/bits/atomic_base.h   |  4 +-
 libstdc++-v3/include/std/atomic   |  2 +
 .../testsuite/29_atomics/atomic/114865.cc | 49 +++
 3 files changed, 54 insertions(+), 1 deletion(-)
 create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/114865.cc

diff --git a/libstdc++-v3/include/bits/atomic_base.h 
b/libstdc++-v3/include/bits/atomic_base.h
index 92d1269493f..19fc7a77c1b 100644
--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -954,7 +954,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   constexpr bool
   __maybe_has_padding()
   {
-#if ! __has_builtin(__builtin_clear_padding)
+   // We cannot clear padding in the constructor for C++11,
+   // so return false here to disable all code for zeroing padding.
+#if __cplusplus < 201402L || ! __has_builtin(__builtin_clear_padding)
return false;
 #elif __has_builtin(__has_unique_object_representations)
return !__has_unique_object_representations(_Tp)
diff --git a/libstdc++-v3/include/std/atomic b/libstdc++-v3/include/std/atomic
index 9b1aca0fc09..949a9017862 100644
--- a/libstdc++-v3/include/std/atomic
+++ b/libstdc++-v3/include/std/atomic
@@ -243,6 +243,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   constexpr atomic(_Tp __i) noexcept : _M_i(__i)
   {
+   // A constexpr constructor must be empty in C++11,
+   // so we can only clear padding for C++14 and later.
 #if __cplusplus >= 201402L && __has_builtin(__builtin_clear_padding)
if _GLIBCXX17_CONSTEXPR (__atomic_impl::__maybe_has_padding<_Tp>())
  __builtin_clear_padding(std::__addressof(_M_i));
diff --git a/libstdc++-v3/testsuite/29_atomics/atomic/114865.cc 
b/libstdc++-v3/testsuite/29_atomics/atomic/114865.cc
new file mode 100644
index 000..577cd480915
--- /dev/null
+++ b/libstdc++-v3/testsuite/29_atomics/atomic/114865.cc
@@ -0,0 +1,49 @@
+// { dg-do run { target c++11_only } }
+// { dg-require-atomic-cmpxchg-word "" }
+// { dg-add-options libatomic }
+
+// Bug 114865
+// std::atomic::compare_exchange_strong seems to hang under GCC 13 for C++11
+
+#include 
+#include 
+
+struct type
+{
+  std::uint32_t u32;
+  std::uint16_t u16;
+};
+
+[[gnu::noipa,gnu::noinline,gnu::optimize("O0")]]
+type next(const type& old)
+{
+  auto t = old;
+  ++t.u16;
+  return t;
+}
+
+[[gnu::noipa,gnu::noinline,gnu::optimize("O0")]]
+void
+test_pr116440()
+{
+  constexpr auto mo = std::memory_order_relaxed;
+
+  type t;
+  t.u32 = t.u16 = 0;
+  std::atomic a(t);
+
+  auto old = a.load(mo);
+
+  while (true)
+  {
+auto t = next(old);
+
+if (a.compare_exchange_strong(old, t, mo, mo))
+  return;
+  }
+}
+
+int main()
+{
+  test_pr116440();
+}
-- 
2.49.0

Re: [PATCH] c++: Use G_ instead of _ around cp/errors.cc gcc-internal-format strings [PR119684]

[Jason Merrill]

On 4/9/25 3:16 PM, Jakub Jelinek wrote:

Hi!

These pp_printf/pp_verbatim format strings should be gcc-internal-format,
they use the pretty-print.cc format specifier handling rather than libc
*printf, but pp_printf/pp_verbatim are intentionally not handled through
exgettext because not everything done through them should be translated
(e.g. its use for dump files shouldn't be).
In addition, composing translatable messages from
"in requirements " and later on "with " might make it harder to be
translated.

I've verified these strings (at least those which don't use format
specifiers added post GCC 4.3 which gettext doesn't handle) are properly
marked as gcc-internal-format in gcc.pot.  The lack of that caused
ICEs on German translation of the "%s%s%sIn instantiation of %q#D:\n"
message because it contained too many %s.

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


OK.


2025-04-09  Jakub Jelinek  

PR translation/119684
* error.cc (cp_print_error_function): Use G_ instead of _ for
pp_printf arguments.
(function_category): Use G_ instead of _.
(print_instantiation_full_context): Use G_ instead of _ in pp_verbatim
arguments.
(print_location): Likewise.
(print_instantiation_partial_context): Likewise.
(maybe_print_constexpr_context): Likewise.
(print_constrained_decl_info): Use G_() around pp_verbatim argument.
(print_concept_check_info): Likewise.
(print_constraint_context_head): Likewise.
(print_requires_expression_info): Likewise.  Merge separate pp_verbatim
"in requirements " and "with " into one with conditional messages.

--- gcc/cp/error.cc.jj  2025-04-08 14:08:50.202296469 +0200
+++ gcc/cp/error.cc 2025-04-09 09:13:27.467826410 +0200
@@ -3788,18 +3788,18 @@ cp_print_error_function (diagnostic_text
{
  if (text_output.show_column_p () && s.column != 0)
pp_printf (pp,
-  _("inlined from %qD at %r%s:%d:%d%R"),
+  G_("inlined from %qD at %r%s:%d:%d%R"),
   fndecl,
   "locus", s.file, s.line, s.column);
  else
pp_printf (pp,
-  _("inlined from %qD at %r%s:%d%R"),
+  G_("inlined from %qD at %r%s:%d%R"),
   fndecl,
   "locus", s.file, s.line);
  
  		}

  else
-   pp_printf (pp, _("inlined from %qD"),
+   pp_printf (pp, G_("inlined from %qD"),
   fndecl);
}
}
@@ -3825,22 +3825,22 @@ function_category (tree fn)
&& DECL_FUNCTION_MEMBER_P (fn))
  {
if (DECL_STATIC_FUNCTION_P (fn))
-   return _("In static member function %qD");
+   return G_("In static member function %qD");
else if (DECL_COPY_CONSTRUCTOR_P (fn))
-   return _("In copy constructor %qD");
+   return G_("In copy constructor %qD");
else if (DECL_CONSTRUCTOR_P (fn))
-   return _("In constructor %qD");
+   return G_("In constructor %qD");
else if (DECL_DESTRUCTOR_P (fn))
-   return _("In destructor %qD");
+   return G_("In destructor %qD");
else if (LAMBDA_FUNCTION_P (fn))
-   return _("In lambda function");
+   return G_("In lambda function");
else if (DECL_XOBJ_MEMBER_FUNCTION_P (fn))
-   return _("In explicit object member function %qD");
+   return G_("In explicit object member function %qD");
else
-   return _("In member function %qD");
+   return G_("In member function %qD");
  }
else
-return _("In function %qD");
+return G_("In function %qD");
  }
  
  /* Disable warnings about missing quoting in GCC diagnostics for

@@ -3867,8 +3867,8 @@ print_instantiation_full_context (diagno
char *indent = text_output.build_indent_prefix (true);
pp_verbatim (text_output.get_printer (),
   p->list_p ()
-  ? _("%s%s%sIn substitution of %qS:\n")
-  : _("%s%s%sIn instantiation of %q#D:\n"),
+  ? G_("%s%s%sIn substitution of %qS:\n")
+  : G_("%s%s%sIn instantiation of %q#D:\n"),
   indent,
   show_file ? LOCATION_FILE (location) : "",
   show_file ? ": " : "",
@@ -3888,10 +3888,10 @@ print_location (diagnostic_text_output_f
expanded_location xloc = expand_location (loc);
pretty_printer *const pp = text_output.get_printer ();
if (text_output.show_column_p ())
-pp_verbatim (pp, _("%r%s:%d:%d:%R   "),
+pp_verbatim (pp, G_("%r%s:%d:%d:%R   "),
 "locus", xloc.file, xloc.line, xloc.column);
else
-pp_verbatim (pp, _("%r%s

Re: .ACCESS_WITH_SIZE and pointer ranges

[Martin Uecker]

Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar:
> On 2025-04-10 10:50, Andrew MacLeod wrote:
> > Its not clear to me exactly what is being asked, but I think the 
> > suggestion is that pointer references are being replaced with a builtin 
> > function called .ACCESS_WITH_SIZE ?    and I presume that builtin 
> > function has some parameters that give you relevant range information of 
> > some sort?
> 
> Added, not replaced, but yes, that's essentially it.
> 
> > range-ops is setup to pull range information from builtin functions 
> > already in gimple-range-op.cc:: 
> > gimple_range_op_handler::maybe_builtin_call ().  We'd just need to write 
> > a handler for this new one.  You can pull information from 2 operands 
> > under normal circumstances, but exceptions can be made.    I'd need a 
> > description of what it looks like and how that translates to range info.
> 
> That's perfect!  It's probably redundant for cases where we end up with 
> both .ACCESS_WITH_SIZE and a __bos/__bdos call, but I don't remember if 
> that's the only place where .ACCESS_WITH_SIZE is generated today.  Qing, 
> could you please work with Andrew on this?

BTW, what I would find very interesting is inserting such information
at the points where arrays decay to pointer.

Martin

Re: [PATCH GCC 15] c++: ICE with nested default targ lambdas [PR119574]

[Jason Merrill]

On 4/8/25 10:29 AM, Patrick Palka wrote:

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


OK.


-- >8 --

Here we substitute into the inner lambda twice, first during default
argument substitution for the outer template parameters, then during
that for the inner template parameters.

For the second testcase (which is easier to follow/debug), the first
substitution into the inner lambda is with the template arguments
{0, NULL_TREE}, which we defer because it's an incremental substitution.
For the second and final substitution we have the template arguments
{1, NULL_TREE}, which we try combining via add_extra_args and ICE on
the checking assert because TREE_STATIC isn't set on the deferred
arguments but the template arguments are considered dependent.


Incidentally, in a separate change let's add a macro with a more 
informative name that we can use instead of TREE_STATIC. 
EXTRA_ARGS_TF_PARTIAL?


Though perhaps we also want to rename tf_partial to something like 
tf_preserve_level?



The template arguments aren't dependent however -- they're just
incomplete because when we deferred them we were in the middle
deduction, and we consider a NULL_TREE template argument as dependent.


I wonder what would break if that changed?

I also wonder about trying to distinguish between things that actually 
involve a template parameter and things that are instantiation-dependent 
for other reasons...



If we remove this checking assert, we go on to correctly merge the
template arguments into {{0, NULL_TREE}, {1, NULL_TREE}}.  So this
patch just removes this imprecise assert.

PR c++/119574

gcc/cp/ChangeLog:

* pt.cc (add_extra_args): Remove checking assert.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/lambda-targ13.C: New test.
* g++.dg/cpp2a/lambda-targ13a.C: New test.
* g++.dg/cpp2a/lambda-targ13b.C: New test.
---
  gcc/cp/pt.cc| 1 -
  gcc/testsuite/g++.dg/cpp2a/lambda-targ13.C  | 7 +++
  gcc/testsuite/g++.dg/cpp2a/lambda-targ13a.C | 8 
  gcc/testsuite/g++.dg/cpp2a/lambda-targ13b.C | 8 
  4 files changed, 23 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/lambda-targ13.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/lambda-targ13a.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/lambda-targ13b.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 95b89f1281ba..ffd23d9cd13b 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -13740,7 +13740,6 @@ add_extra_args (tree extra, tree args, tsubst_flags_t 
complain, tree in_decl)
gcc_assert (!TREE_PURPOSE (extra));
extra = TREE_VALUE (extra);
  }
-  gcc_checking_assert (TREE_STATIC (extra) == uses_template_parms (extra));
if (TREE_STATIC (extra))
  /* This is a partial substitution into e.g. a requires-expr or lambda-expr
 inside a default template argument; we expect 'extra' to be a full set
diff --git a/gcc/testsuite/g++.dg/cpp2a/lambda-targ13.C 
b/gcc/testsuite/g++.dg/cpp2a/lambda-targ13.C
new file mode 100644
index ..8fd0a311e056
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/lambda-targ13.C
@@ -0,0 +1,7 @@
+// PR c++/119574
+// { dg-do compile { target c++20 } }
+
+template  () {})>
+void f(F op = {}) { op(); }
+
+int main() { f(); }
diff --git a/gcc/testsuite/g++.dg/cpp2a/lambda-targ13a.C 
b/gcc/testsuite/g++.dg/cpp2a/lambda-targ13a.C
new file mode 100644
index ..8aaefd93356c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/lambda-targ13a.C
@@ -0,0 +1,8 @@
+// PR c++/119574
+// A version of lambda-targ13.C with extra template parameters.
+// { dg-do compile { target c++20 } }
+
+template  () {})>
+void f(F op = {}) { op(); }
+
+int main() { f(); }
diff --git a/gcc/testsuite/g++.dg/cpp2a/lambda-targ13b.C 
b/gcc/testsuite/g++.dg/cpp2a/lambda-targ13b.C
new file mode 100644
index ..952c44761357
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/lambda-targ13b.C
@@ -0,0 +1,8 @@
+// PR c++/119574
+// A version of lambda-targ13.C where the inner lambda returns non-void.
+// { dg-do compile { target c++20 } }
+
+template  () { return G(); 
})>
+int f(F op = {}) { return op(); }
+
+int main() { f(); }

[PATCH] libgcobol, v2: Handle long double as an alternate IEEE754 128b

[Jakub Jelinek]

On Wed, Apr 09, 2025 at 02:22:16PM +0200, Rainer Orth wrote:
> > Here is what I'm testing as an incremental fix, so far OK on x86_64-darwin
> > and powerpcle64 (GLIBC 2.34) .. others in progress.  Does it help the
> > Solaris cases?
> 
> I'll give it a try.  Here's what I have (I believe it's more readable in
> some cases), but as I said something's not right yet (probably something
> very stupid).

Yes, most importantly

>  #if !defined (HAVE_STRFROMF128)
> -# if !USE_QUADMATH
> +static int
> +strfromf128 (char *s, size_t n, const char *f, long double v)

this long double should have been GCOB_FP128.

Anyway, I think there should be consistency in what we use, so like
libgcobol-fp.h specifies, IEEE quad long double should have highest
priority, then _Float128 with *f128 APIs, then libquadmath.
And when we decide to use say long double, we shouldn't mix that with
strfromf128/strtof128.

Additionally, given that the *l vs. *f128 vs. *q API decision is done
solely in libgcobol and not in the compiler (which is different from
the Fortran case where compiled code emits say sinq or sinf128 calls),
I think libgcobol.spec should only have -lquadmath in any form only in
the case when using libquadmath for everything.  In the Fortran case
it is for backwards compatibility purposes, if something has been
compiled with older gfortran which used say sinq and link is done by
gfortran which has been configured against new glibc with *f128, linking
would fail otherwise.

So, here is an updated patch based on your patch, so far briefly
tested on x86_64 with recent glibc (i.e. with the *f128 APIs).

2025-04-10  Jakub Jelinek  
Rainer Orth  

PR cobol/119244
* acinclude.m4 (LIBGCOBOL_CHECK_FLOAT128): Ensure
libgcob_cv_have_float128 is not yes on targets with IEEE quad
long double.  Don't check for --as-needed nor set LIBQUADSPEC
on targets which USE_IEC_60559.
* libgcobol-fp.h (FP128_FMT, strtofp128, strfromfp128): Define.
* intrinsic.cc (strtof128): Don't redefine.
(WEIRD_TRANSCENDENT_RETURN_VALUE): Use GCOB_FP128_LITERAL macro.
(__gg__numval_f): Use strtofp128 instead of strtof128.
* libgcobol.cc (strtof128): Don't redefine.
(format_for_display_internal): Use strfromfp128 instead of
strfromf128 or quadmath_snprintf and use FP128_FMT in the format
string.
(get_float128, __gg__compare_2, __gg__move, __gg__move_literala):
Use strtofp128 instead of strtof128.
* configure: Regenerate.

--- libgcobol/acinclude.m4.jj   2025-04-10 17:14:36.535278015 +0200
+++ libgcobol/acinclude.m4  2025-04-10 17:33:56.012347476 +0200
@@ -44,6 +44,10 @@ AC_DEFUN([LIBGCOBOL_CHECK_FLOAT128], [
   AC_CACHE_CHECK([whether we have a usable _Float128 type],
  libgcob_cv_have_float128, [
GCC_TRY_COMPILE_OR_LINK([
+#if __LDBL_MANT_DIG__ == 113 && __LDBL_MIN_EXP__ == -16381
+#error "long double is IEEE quad, no need for libquadmath"
+#endif
+
 _Float128 foo (_Float128 x)
 {
  _Complex _Float128 z1, z2;
@@ -90,32 +94,22 @@ AC_DEFUN([LIBGCOBOL_CHECK_FLOAT128], [
 fi
 AC_DEFINE(HAVE_FLOAT128, 1, [Define if target has usable _Float128 and 
__float128 types.])
 
-dnl Check whether -Wl,--as-needed resp. -Wl,-zignore is supported
-dnl 
-dnl Turn warnings into error to avoid testsuite breakage.  So enable
-dnl AC_LANG_WERROR, but there's currently (autoconf 2.64) no way to turn
-dnl it off again.  As a workaround, save and restore werror flag like
-dnl AC_PATH_XTRA.
-dnl Cf. http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01889.html
-
ac_xsave_[]_AC_LANG_ABBREV[]_werror_flag=$ac_[]_AC_LANG_ABBREV[]_werror_flag
-AC_CACHE_CHECK([whether --as-needed/-z ignore works],
-  [libgcob_cv_have_as_needed],
-  [
-  # Test for native Solaris options first.
-  # No whitespace after -z to pass it through -Wl.
-  libgcob_cv_as_needed_option="-zignore"
-  libgcob_cv_no_as_needed_option="-zrecord"
-  save_LDFLAGS="$LDFLAGS"
-  LDFLAGS="$LDFLAGS -Wl,$libgcob_cv_as_needed_option -lm 
-Wl,$libgcob_cv_no_as_needed_option"
-  libgcob_cv_have_as_needed=no
-  AC_LANG_WERROR
-  AC_LINK_IFELSE([AC_LANG_PROGRAM([])],
-[libgcob_cv_have_as_needed=yes],
-[libgcob_cv_have_as_needed=no])
-  LDFLAGS="$save_LDFLAGS"
-  if test "x$libgcob_cv_have_as_needed" = xno; then
-   libgcob_cv_as_needed_option="--as-needed"
-   libgcob_cv_no_as_needed_option="--no-as-needed"
+if test "x$USE_IEC_60559" != xyes; then
+  dnl Check whether -Wl,--as-needed resp. -Wl,-zignore is supported
+  dnl 
+  dnl Turn warnings into error to avoid testsuite breakage.  So enable
+  dnl AC_LANG_WERROR, but there's currently (autoconf 2.64) no way to turn
+  dnl it off again.  As a workaround, save and restore werror flag like
+  dnl AC_PATH_XTRA.
+  dnl Cf. http://gcc.gnu.org/ml/gcc-p

[PATCH v2] libstdc++: Implement C++26 features (P2546R5)

[Jonathan Wakely]

It would be good to provide a macOS definition of is_debugger_present as
per https://developer.apple.com/library/archive/qa/qa1361/_index.html
but that isn't included in this change.

libstdc++-v3/ChangeLog:

* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Check for facilities needed by .
* include/Makefile.am: Add new header.
* include/Makefile.in: Regenerate.
* include/bits/version.def (debugging): Add.
* include/bits/version.h: Regenerate.
* src/c++26/Makefile.am: Add new file.
* src/c++26/Makefile.in: Regenerate.
* include/std/debugging: New file.
* src/c++26/debugging.cc: New file.
* testsuite/19_diagnostics/debugging/breakpoint.cc: New test.
* testsuite/19_diagnostics/debugging/breakpoint_if_debugging.cc:
New test.
* testsuite/19_diagnostics/debugging/is_debugger_present.cc: New
test.
---

I sent v1 of this patch in June last year:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653293.html
My comments about testing with GDB still apply.

Compared to v1, this adds a void __gnu_cxx::attach_debugger(bool)
function that could be called by debuggers to announce that they are
attaching and detaching. It also adds a systemtap probe point to
std::breakpoint().

Tested x86_64-linux.

N.B. this only adds new symbols to the libstdc++exp.a archive, not to
libstdc++.so so it's not a risky change at this stage.

 libstdc++-v3/config.h.in  |   9 +
 libstdc++-v3/configure|  22 +++
 libstdc++-v3/configure.ac |   9 +
 libstdc++-v3/include/Makefile.am  |   1 +
 libstdc++-v3/include/Makefile.in  |   1 +
 libstdc++-v3/include/bits/version.def |   8 +
 libstdc++-v3/include/bits/version.h   |  10 ++
 libstdc++-v3/include/std/debugging|  77 
 libstdc++-v3/src/c++26/Makefile.am|   4 +-
 libstdc++-v3/src/c++26/Makefile.in|   7 +-
 libstdc++-v3/src/c++26/debugging.cc   | 165 ++
 .../19_diagnostics/debugging/breakpoint.cc|  13 ++
 .../debugging/breakpoint_if_debugging.cc  |  13 ++
 .../debugging/is_debugger_present.cc  |  14 ++
 14 files changed, 350 insertions(+), 3 deletions(-)
 create mode 100644 libstdc++-v3/include/std/debugging
 create mode 100644 libstdc++-v3/src/c++26/debugging.cc
 create mode 100644 
libstdc++-v3/testsuite/19_diagnostics/debugging/breakpoint.cc
 create mode 100644 
libstdc++-v3/testsuite/19_diagnostics/debugging/breakpoint_if_debugging.cc
 create mode 100644 
libstdc++-v3/testsuite/19_diagnostics/debugging/is_debugger_present.cc

diff --git a/libstdc++-v3/config.h.in b/libstdc++-v3/config.h.in
index 77bbaf1beaa..3f1331ff36f 100644
--- a/libstdc++-v3/config.h.in
+++ b/libstdc++-v3/config.h.in
@@ -70,6 +70,9 @@
 /* Define to 1 if you have the `cosl' function. */
 #undef HAVE_COSL
 
+/* Define to 1 if you have the  header file. */
+#undef HAVE_DEBUGAPI_H
+
 /* Define to 1 if you have the declaration of `strnlen', and to 0 if you
don't. */
 #undef HAVE_DECL_STRNLEN
@@ -439,6 +442,9 @@
 /* Define to 1 if you have the  header file. */
 #undef HAVE_SYS_PARAM_H
 
+/* Define to 1 if you have the  header file. */
+#undef HAVE_SYS_PTRACE_H
+
 /* Define to 1 if you have the  header file. */
 #undef HAVE_SYS_RESOURCE_H
 
@@ -850,6 +856,9 @@
 /* Define if nl_langinfo_l should be used for std::text_encoding. */
 #undef _GLIBCXX_USE_NL_LANGINFO_L
 
+/* Define if /proc/self/status should be used for . */
+#undef _GLIBCXX_USE_PROC_SELF_STATUS
+
 /* Define if pthreads_num_processors_np is available in . */
 #undef _GLIBCXX_USE_PTHREADS_NUM_PROCESSORS_NP
 
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 819a1d82876..8143df91c38 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -54700,6 +54700,28 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
 
 
 
+# For std::is_debugger_present
+case "$target_os" in
+  linux*)
+
+$as_echo "#define _GLIBCXX_USE_PROC_SELF_STATUS 1" >>confdefs.h
+
+;;
+esac
+for ac_header in sys/ptrace.h debugapi.h
+do :
+  as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
+ac_fn_c_check_header_mongrel "$LINENO" "$ac_header" "$as_ac_Header" 
"$ac_includes_default"
+if eval test \"x\$"$as_ac_Header"\" = x"yes"; then :
+  cat >>confdefs.h <<_ACEOF
+#define `$as_echo "HAVE_$ac_header" | $as_tr_cpp` 1
+_ACEOF
+
+fi
+
+done
+
+
 # Define documentation rules conditionally.
 
 # See if makeinfo has been installed and is modern enough
diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac
index a6c01b29e94..83adb46454e 100644
--- a/libstdc++-v3/configure.ac
+++ b/libstdc++-v3/configure.ac
@@ -587,6 +587,15 @@ GLIBCXX_CHECK_FILEBUF_NATIVE_HANDLES
 # For std::text_encoding
 GLIBCXX_CHECK_TEXT_ENCODING
 
+# For std::is_debugger_present
+case "$target_os" in
+  linux*)
+AC_DEFINE([_GLIBCXX_USE_PROC_SELF_STATUS],1,
+   

[committed] RISC-V: Include local riscv_vector.h in testsuite

[Kito Cheng]

That could prevent us including stdint.h from glibc, and that will cause
problem when the corresponding multilib isn't built.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/abi-callee-saved-1-fixed-1.c: Include local
riscv_vector.h.
* gcc.target/riscv/rvv/base/abi-callee-saved-1-fixed-2.c: Ditto.
* gcc.target/riscv/rvv/base/abi-callee-saved-1-save-restore.c: Ditto.
* gcc.target/riscv/rvv/base/abi-callee-saved-1-zcmp.c: Ditto.
* gcc.target/riscv/rvv/base/abi-callee-saved-1.c: Ditto.
* gcc.target/riscv/rvv/base/abi-callee-saved-2-save-restore.c: Ditto.
* gcc.target/riscv/rvv/base/abi-callee-saved-2-zcmp.c: Ditto.
* gcc.target/riscv/rvv/base/abi-callee-saved-2.c: Ditto.
* gcc.target/riscv/rvv/base/bug-10-2.c: Ditto.
* gcc.target/riscv/rvv/base/bug-10.c: Ditto.
* gcc.target/riscv/rvv/base/bug-7.c: Ditto.
* gcc.target/riscv/rvv/base/bug-8.c: Ditto.
* gcc.target/riscv/rvv/base/bug-9.c: Ditto.
* gcc.target/riscv/rvv/base/pr110943.c: Ditto.
* gcc.target/riscv/rvv/base/pr112431-21.c: Ditto.
* gcc.target/riscv/rvv/base/pr114639-1.c: Ditto.
* gcc.target/riscv/rvv/base/pr115068.c: Ditto.
* gcc.target/riscv/rvv/base/pr117286.c: Ditto.
* gcc.target/riscv/rvv/base/pr117544.c: Ditto.
* gcc.target/riscv/rvv/base/pr117955.c: Ditto.
* gcc.target/riscv/rvv/base/pr118872.c: Ditto.
* gcc.target/riscv/rvv/base/vlmul_ext-1.c: Ditto.
* gcc.target/riscv/rvv/base/vssubu-1.c: Ditto.
* gcc.target/riscv/rvv/base/vssubu-2.c: Ditto.
* gcc.target/riscv/rvv/base/vwaddsub-1.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/pr111234.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/pr115214.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vsetvl-24.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vsetvl_bug-3.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vsetvl_bug-4.c: Ditto.
* gcc.target/riscv/rvv/xtheadvector/pr116591.c: Ditto.
* gcc.target/riscv/rvv/xtheadvector/pr116592.c: Ditto.
* gcc.target/riscv/rvv/xtheadvector/pr118357.c: Ditto.
* gcc.target/riscv/rvv/xtheadvector/vsext.c: Ditto.
* gcc.target/riscv/rvv/xtheadvector/vzext.c: Ditto.
---
 .../gcc.target/riscv/rvv/base/abi-callee-saved-1-fixed-1.c  | 2 +-
 .../gcc.target/riscv/rvv/base/abi-callee-saved-1-fixed-2.c  | 2 +-
 .../gcc.target/riscv/rvv/base/abi-callee-saved-1-save-restore.c | 2 +-
 .../gcc.target/riscv/rvv/base/abi-callee-saved-1-zcmp.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/base/abi-callee-saved-1.c| 2 +-
 .../gcc.target/riscv/rvv/base/abi-callee-saved-2-save-restore.c | 2 +-
 .../gcc.target/riscv/rvv/base/abi-callee-saved-2-zcmp.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/base/abi-callee-saved-2.c| 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/base/bug-10-2.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/base/bug-10.c| 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/base/bug-7.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/base/bug-8.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/base/bug-9.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/base/pr110943.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-21.c   | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/base/pr114639-1.c| 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/base/pr115068.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/base/pr117286.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/base/pr117544.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/base/pr117955.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/base/pr118872.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/base/vlmul_ext-1.c   | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/base/vssubu-1.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/base/vssubu-2.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/base/vwaddsub-1.c| 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/pr111234.c| 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/pr115214.c| 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vsetvl-24.c   | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vsetvl_bug-3.c| 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vsetvl_bug-4.c| 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/pr116591.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/pr116592.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/pr118357.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/vsext.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/vzext.c | 2 +-
 35 files changed, 35 insertions(+), 35 deletions(-)

diff --git 
a/gcc/testsuite/gcc.target/riscv/rvv/base/abi-callee-saved-1-fixed-1.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/ab

[committed] RISC-V: Fix the behavior for multilib-generator with --cmodel=large on rv32

[Kito Cheng]

Large code model is only supported on RV64, so we don't need to
generate the multilibs for RV32 with --cmodel=large. And the compact
code model is something we don't supported on upstream (which is
accidentally added in the past), so we need to remove it.

gcc/ChangeLog:

* config/riscv/multilib-generator: Remove the compact code model
and check large code model for RV32.
---
 gcc/config/riscv/multilib-generator | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/riscv/multilib-generator 
b/gcc/config/riscv/multilib-generator
index 48280168b5b..6ad1cf0e553 100755
--- a/gcc/config/riscv/multilib-generator
+++ b/gcc/config/riscv/multilib-generator
@@ -159,8 +159,8 @@ for cmodel in cmodels:
  "e.g. rv32imafd-ilp32--" % cfg)
   sys.exit(1)
 
-# Compact code model only support rv64.
-if cmodel == "compact" and arch.startswith("rv32"):
+# Large code model only support rv64.
+if cmodel == "large" and arch.startswith("rv32"):
   continue
 
 arch = arch_canonicalize (arch, args.misa_spec)
-- 
2.34.1

[PATCH] Avoid using POINTER_DIFF_EXPR for overlap checks [PR119399]

[Richard Sandiford]

In r10-4803-g8489e1f45b50600c I'd used POINTER_DIFF_EXPR to subtract
the two pointers involved in an overlap test.  I'm not sure whether
I'd specifically chosen that over MINUS_EXPR or not; if so, the only
reason I can think of is that it is probably faster on targets with
PSImode pointers.  Regardless, as the PR points out, subtracting
unrelated pointers using POINTER_DIFF_EXPR is undefined behaviour.

Tested on aarch64-linux-gnu & x86_64-linux-gnu.  OK for trunk, and
for backports after a grace period?

Richard


gcc/
PR tree-optimization/119399
* tree-data-ref.cc (create_waw_or_war_checks): Use a MINUS_EXPR
on two converted pointers, rather than converting a POINTER_DIFF_EXPR
on the pointers.

gcc/testsuite/
PR tree-optimization/119399
* gcc.dg/vect/pr119399.c: New test.
---
 gcc/testsuite/gcc.dg/vect/pr119399.c | 10 ++
 gcc/tree-data-ref.cc |  7 ---
 2 files changed, 14 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/vect/pr119399.c

diff --git a/gcc/testsuite/gcc.dg/vect/pr119399.c 
b/gcc/testsuite/gcc.dg/vect/pr119399.c
new file mode 100644
index 000..8d868f44b67
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr119399.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-fdump-tree-vect-raw" } */
+
+void foo(int *p, int *q, int n)
+{
+  for (int i = 0; i < n; i++)
+p[i] = q[i] + 1;
+}
+
+/* { dg-final { scan-tree-dump-not {

Re: [PATCH v1 1/4] libstdc++: Setup internal FTM for mdspan.

[Tomasz Kaminski]

On Wed, Apr 9, 2025 at 9:30 AM Luc Grosheintz 
wrote:

> Uses the FTM infrastructure to create an internal feature testing macro
> for partial availability of mdspan; which is then used to hide the
> contents of the header mdspan when compiling against a standard prior to
> C++23.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/version.def: Add internal feature testing macro
> __glibcxx_mdspan.
> * include/bits/version.h: Regenerate.
>
> Signed-off-by: Luc Grosheintz 
> ---
>  libstdc++-v3/include/bits/version.def |  9 +
>  libstdc++-v3/include/bits/version.h   | 10 ++
>  2 files changed, 19 insertions(+)
>
> diff --git a/libstdc++-v3/include/bits/version.def
> b/libstdc++-v3/include/bits/version.def
> index 8f609b469cc..89f066010ae 100644
> --- a/libstdc++-v3/include/bits/version.def
> +++ b/libstdc++-v3/include/bits/version.def
> @@ -998,6 +998,15 @@ ftms = {
>};
>  };
>
> +ftms = {
> +  name = mdspan;
> +  no_stdname = true; // FIXME: remove
> +  values = {
> +v = 1; // FIXME: 202207
> +cxxmin = 23;
> +  };
> +};
> +
>  ftms = {
>name = ssize;
>values = {
> diff --git a/libstdc++-v3/include/bits/version.h
> b/libstdc++-v3/include/bits/version.h
> index f05c3fd13c0..b97053a891e 100644
> --- a/libstdc++-v3/include/bits/version.h
> +++ b/libstdc++-v3/include/bits/version.h
> @@ -1115,6 +1115,16 @@
>  #endif /* !defined(__cpp_lib_span) && defined(__glibcxx_want_span) */
>  #undef __glibcxx_want_span
>
> +#if !defined(__cpp_lib_mdspan)
> +# if (__cplusplus >= 202100L)
> +#  define __glibcxx_mdspan 1L
> +#  if defined(__glibcxx_want_all) || defined(__glibcxx_want_mdspan)
> +#   define __cpp_lib_mdspan 1L
>
With the `no_stdname` option this line should not be present. Support for
no_stdname was merged recently,
so could you try to regenerate the file. I have recently merged
__glibcxx_format_ranges that have similar behavior.

In that case, you should use __glibcxx_mdspan as the guard for macros.

> +#  endif
> +# endif
> +#endif /* !defined(__cpp_lib_mdspan) && defined(__glibcxx_want_mdspan) */
> +#undef __glibcxx_want_mdspan
> +
>  #if !defined(__cpp_lib_ssize)
>  # if (__cplusplus >= 202002L)
>  #  define __glibcxx_ssize 201902L
> --
> 2.49.0
>
>

[PATCH] middle-end/119706 - allow POLY_INT_CST as is_gimple_mem_ref_addr

[Richard Biener]

We currently only INTEGER_CST, but not POLY_INT_CST, which leads
to the situation that when the POLY_INT_CST is only indrectly
present via a SSA def the IL is valid but when propagated it's not.
That's unsustainable.

Bootstrap and regtest running on x86_64-unknown-linux-gnu, will
push after that succeeded.

PR middle-end/119706
* gimple-expr.cc (is_gimple_mem_ref_addr): Also allow
POLY_INT_CST.
---
 gcc/gimple-expr.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/gimple-expr.cc b/gcc/gimple-expr.cc
index a670e4648d3..c0367f490d6 100644
--- a/gcc/gimple-expr.cc
+++ b/gcc/gimple-expr.cc
@@ -884,7 +884,7 @@ bool
 is_gimple_mem_ref_addr (tree t)
 {
   return (is_gimple_reg (t)
- || TREE_CODE (t) == INTEGER_CST
+ || poly_int_tree_p (t)
  || (TREE_CODE (t) == ADDR_EXPR
  && (CONSTANT_CLASS_P (TREE_OPERAND (t, 0))
  || decl_address_invariant_p (TREE_OPERAND (t, 0);
-- 
2.43.0

Re: Questions on replacing a structure pointer reference to a call to .ACCESS_WITH_SIZE in C FE

[Martin Uecker]

Am Donnerstag, dem 10.04.2025 um 06:56 -0400 schrieb Siddhesh Poyarekar:
> On 2025-04-10 01:41, Martin Uecker wrote:
> > I have some questions about this:  The access would add new reads
> > to the size field.  For counted_by, so far, those are somehow
> > coupled to the access to the member.  From this you would assume
> 
> For the currently implemented subset, updates to the storage of the 
> annotated FAM and updates to its counted_by size need to be coupled to 
> prevent reordering because their relationship is otherwise implicit.
> 
> This proposed feature would need the counted_by size and the containing 
> struct of the FAM to be coupled to make that relationship explicit, but 
> it's not necessarily to prevent reordering because this case needs to 
> only be considered when the update of the storage for the struct (or its 
> containing FAM) is not visible.  That is, the pointer either comes in as 
> a parameter or a non-allocator call returning that pointer.

So the assumption here is that you never pass around a pointer
to an uninitialized (or otherwise not validely initialized)
structure. 

> 
> Now it is entirely possible that further inlining gets the allocator in 
> and it would be possible to thread through the .ACCESS_WITH_SIZE to 
> reach the allocator, but I would argue that the counted_by + size of 
> struct should be the canonical result.

I am thinking about use cases where the user does its own memory
management, e.g. there is larger arena the structure is
allocated in or there is a capacity field because the structure
was overallocated.

> 
> > that inserting the new accesses to the size field are ok (e.g.
> > one can assume the struct is accessible, there are no new race
> > conditions under some assumptions, it is initialized).  If you
> > now want to read the size at different points, all this is even
> > less clear to me.
> 
> I'm not sure about race conditions, the coupling was to prevent 
> reordering.  Would you be able to elaborate on the race condition question?

If you materialize a read to the size field it could race
with a write to this field in another thread.  I am not sure
whether there are use cases where this can happen, but it is
something to worry about.

> 
> > I may miss something, but I think one would have to first
> > define a clear criterion when it is ok to access the size
> > field.
> 
> This is a contentious issue I had not thought of; if the pointer ends up 
> being NULL at runtime, a dereference due to the size expression for the 
> containing struct will end up validating it for subsequent passes, which 
> may makes things even worse.  The size expression will also need a NULL 
> check to work around this.

Yes. But there could be other issues. The memory could be
protected.

> > So to me it seems we can not simply insert it at specific
> > point in the C FE where a pointer to the struct is
> > used, but only when there is some specific trigger.
> > 
> > An example I could imagine is when you memcpy
> > the struct.   (but it is also not entirely clear why this
> > should not be allowed to go beyond the counted_by size
> > if the underlying storage is larger).
> 
> IMO, I don't think underallocation/overallocation (and expecting the 
> additional allocation to be usable) and counted_by for FAM should be 
> allowed to coexist.  That's just a source for confusion.

It certainly makes it more complex.  But people like to use
their own memory management (or have to) and not being able to use
counted_by then would be a limitation.

> 
> > Maybe you could add it when a pointer to an annotated
> > struct is passed as parameter, but also there it is not
> > clear to me that we might want to materialize new
> > accesses to the struct at this point.
> > 
> > An alternative approach could be to just do it when
> > such a pointer is explicitely passed to the BDOS builtin.
> 
> I suppose bounds sanitizer won't be affected by this but wouldn't this 
> then exclude the object-size sanitizer?  I don't know if its 
> instrumentation runs early enough.

I am not sure.

Martin

Re: [PATCH] libgomp: Update SVE tests

[Tejas Belagod]

On 4/10/25 5:13 PM, Tejas Belagod wrote:

On 4/9/25 4:13 PM, Jakub Jelinek wrote:

On Wed, Apr 09, 2025 at 04:01:49PM +0530, Tejas Belagod wrote:

It also looks like there might be a missing "+" in simd_reduction:

    #pragma omp simd reduction (+:va, i)
    for (j = 0; j < 16; j++)
  va = svld1_s32 (svptrue_b32 (), a);

    res = svaddv_s32 (svptrue_b32 (), va);

    if (res != 8)
  __builtin_abort ();

since AFAICT the loop is not doing a reduction as things stand.
But perhaps that's deliberate, since it does match the != 8 test.


That's interesting. I thought the reduction definition in the
'declare reduction' does the reduction from all the individual 
interations
according the the rules defined in the reduction irrespective of the 
loop

structure.  Maybe 'va' doesn't become implicit private and causes a race
(which may be why I didn't see it in my testing) - I'll try to repro 
this

and have a look.


No, reduction privatizes the variable, initializes the private 
variable with

the initializer from UDR and reduces at the end only from all the private
variables to the original one.

For simd, each SIMD lane has one private copy and there are # SIMD lanes
reductions into the original, for e.g. worksharing constructs each thread
has a private copy and there are omp_get_num_threads () reductions, etc.

There is no special action at the end of each loop body, it is up to the
user to merge state from each iteration.  In sane code the loop body does
similar operation to what the reduction does.
So say if you have
float sum = 0;
#pragma omp parallel for reduction (+:sum)
for (int i = 0; i < 1024; ++i)
   sum += a[i];
then if OpenMP pragmas are ignored, all the array members
are summed up in that order, while if say there are 4
threads and each handles 256 iterations, then each thread will
start with sum = 0; and do sum += a[i]; for i omp_get_thread_num () * 256
to omp_get_thread_num () * 256 + 255 inclusive and finally in some random
order the 4 private floats will be summed together.
For floating point that can result in different behavior (different 
rounding

etc.) but user said it is ok like that.



Thanks for the explanation.  I looked into why some of the tests may 
have failed - my flawed understanding of the reduction clause was why I 
didn't have the += in the loops - it might have passed for me as I 
probably hit the exact omp_get_num_threads () number required for the 
final += reductions to trigger from the declare clause.  As Richard 
said, the += in the loops ought to fix the tests. I'm still analysing 
inscan_reduction_incl () to fix it properly.


Sorry, forgot to ask - Richard, are you happy for me to work on a 
separate patch to fix the test alongside your target +sve fix as a 
couple more functions (eg simd_reduction () and inscan.. () ) also need 
fixing?


Thanks,
Tejas.

[PATCH v5 2/2] i386: Enable -mnop-mcount for -fpic with PLTs

[Ard Biesheuvel]

From: Ard Biesheuvel 

-mnop-mcount can be trivially enabled for -fPIC codegen as long as PLTs
are being used, given that the instruction encodings are identical, only
the target may resolve differently depending on how the linker decides
to incorporate the object file.

So relax the option check, and add a test to ensure that 5-byte NOPs are
emitted when -mnop-mcount is being used.

Signed-off-by: Ard Biesheuvel 

gcc/ChangeLog:

PR target/119386
* config/i386/i386-options.cc: Permit -mnop-mcount when using
  -fpic with PLTs.

gcc/testsuite/ChangeLog:

PR target/119386
* gcc.target/i386/pr119386-3.c: New test.
---
 gcc/config/i386/i386-options.cc|  4 ++--
 gcc/testsuite/gcc.target/i386/pr119386-3.c | 10 ++
 2 files changed, 12 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr119386-3.c

diff --git a/gcc/config/i386/i386-options.cc b/gcc/config/i386/i386-options.cc
index a9fac011f3d..964449fa8cd 100644
--- a/gcc/config/i386/i386-options.cc
+++ b/gcc/config/i386/i386-options.cc
@@ -2828,8 +2828,8 @@ ix86_option_override_internal (bool main_args_p,
   if (flag_nop_mcount)
 error ("%<-mnop-mcount%> is not compatible with this target");
 #endif
-  if (flag_nop_mcount && flag_pic)
-error ("%<-mnop-mcount%> is not implemented for %<-fPIC%>");
+  if (flag_nop_mcount && flag_pic && !flag_plt)
+error ("%<-mnop-mcount%> is not implemented for %<-fno-plt%>");
 
   /* Accept -msseregparm only if at least SSE support is enabled.  */
   if (TARGET_SSEREGPARM_P (opts->x_target_flags)
diff --git a/gcc/testsuite/gcc.target/i386/pr119386-3.c 
b/gcc/testsuite/gcc.target/i386/pr119386-3.c
new file mode 100644
index 000..287410b951a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr119386-3.c
@@ -0,0 +1,10 @@
+/* PR target/119386 */
+/* { dg-do compile { target *-*-linux* } } */
+/* { dg-options "-O2 -fpic -pg -mnop-mcount" } */
+/* { dg-final { scan-assembler ".byte\[ \t\]+0x0f, 0x1f, 0x44, 0x00, 0x00" } } 
*/
+
+int
+main ()
+{
+  return 0;
+}
-- 
2.49.0.504.g3bcea36a83-goog

[PATCH v5 1/2] i386: Prefer PLT indirection for __fentry__ calls under -fPIC

[Ard Biesheuvel]

From: Ard Biesheuvel 

Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
__fentry__") updated the logic that emits mcount() / __fentry__() calls
into function prologues when profiling is enabled, to avoid GOT-based
indirect calls when a direct call would suffice.

There are two problems with that change:
- it relies on -mdirect-extern-access rather than -fno-plt to decide
  whether or not a direct [PLT based] call is appropriate;
- for the PLT case, it falls through to x86_print_call_or_nop(), which
  does not emit the @PLT suffix, resulting in the wrong relocation to be
  used (R_X86_64_PC32 instead of R_X86_64_PLT32)

Fix this by testing flag_plt instead of ix86_direct_extern_access, and
updating x86_print_call_or_nop() to take flag_pic and flag_plt into
account. This also ensures that -mnop-mcount works as expected when
emitting the PLT based profiling calls.

While at it, fix the 32-bit logic as well, and issue a PLT call unless
PLTs are explicitly disabled.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386

Signed-off-by: Ard Biesheuvel 

gcc/ChangeLog:

PR target/119386
* config/i386/i386.cc (x86_print_call_or_nop): Add @PLT suffix
where appropriate.
(x86_function_profiler): Fall through to x86_print_call_or_nop()
for PIC codegen when flag_plt is set.

gcc/testsuite/ChangeLog:

PR target/119386
* gcc.target/i386/pr119386-1.c: New test.
* gcc.target/i386/pr119386-2.c: New test.
---
 gcc/config/i386/i386.cc| 12 ++--
 gcc/testsuite/gcc.target/i386/pr119386-1.c | 10 ++
 gcc/testsuite/gcc.target/i386/pr119386-2.c | 12 
 3 files changed, 32 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr119386-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr119386-2.c

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index 4f8380c4a58..20059b775b9 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -23158,6 +23158,12 @@ x86_print_call_or_nop (FILE *file, const char *target)
   if (flag_nop_mcount || !strcmp (target, "nop"))
 /* 5 byte nop: nopl 0(%[re]ax,%[re]ax,1) */
 fprintf (file, "1:" ASM_BYTE "0x0f, 0x1f, 0x44, 0x00, 0x00\n");
+  else if (!TARGET_PECOFF && flag_pic)
+{
+  gcc_assert (flag_plt);
+
+  fprintf (file, "1:\tcall\t%s@PLT\n", target);
+}
   else
 fprintf (file, "1:\tcall\t%s\n", target);
 }
@@ -23321,7 +23327,7 @@ x86_function_profiler (FILE *file, int labelno 
ATTRIBUTE_UNUSED)
  break;
case CM_SMALL_PIC:
case CM_MEDIUM_PIC:
- if (!ix86_direct_extern_access)
+ if (!flag_plt)
{
  if (ASSEMBLER_DIALECT == ASM_INTEL)
fprintf (file, "1:\tcall\t[QWORD PTR %s@GOTPCREL[rip]]\n",
@@ -23352,7 +23358,9 @@ x86_function_profiler (FILE *file, int labelno 
ATTRIBUTE_UNUSED)
 "\tleal\t%sP%d@GOTOFF(%%ebx), %%" PROFILE_COUNT_REGISTER "\n",
 LPREFIX, labelno);
 #endif
-  if (ASSEMBLER_DIALECT == ASM_INTEL)
+  if (flag_plt)
+   x86_print_call_or_nop (file, mcount_name);
+  else if (ASSEMBLER_DIALECT == ASM_INTEL)
fprintf (file, "1:\tcall\t[DWORD PTR %s@GOT[ebx]]\n", mcount_name);
   else
fprintf (file, "1:\tcall\t*%s@GOT(%%ebx)\n", mcount_name);
diff --git a/gcc/testsuite/gcc.target/i386/pr119386-1.c 
b/gcc/testsuite/gcc.target/i386/pr119386-1.c
new file mode 100644
index 000..9a0dc64b5b9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr119386-1.c
@@ -0,0 +1,10 @@
+/* PR target/119386 */
+/* { dg-do compile { target *-*-linux* } } */
+/* { dg-options "-O2 -fpic -pg" } */
+/* { dg-final { scan-assembler "call\[ \t\]+mcount@PLT" } } */
+
+int
+main ()
+{
+  return 0;
+}
diff --git a/gcc/testsuite/gcc.target/i386/pr119386-2.c 
b/gcc/testsuite/gcc.target/i386/pr119386-2.c
new file mode 100644
index 000..3ea978ecfdf
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr119386-2.c
@@ -0,0 +1,12 @@
+/* PR target/119386 */
+/* { dg-do compile { target *-*-linux* } } */
+/* { dg-options "-O2 -fpic -fno-plt -pg" } */
+/* { dg-final { scan-assembler "call\[ \t\]+\\*mcount@GOTPCREL\\(" { target { 
! ia32 } } } } */
+/* { dg-final { scan-assembler "call\[ \t\]+\\*mcount@GOT\\(" { target ia32 } 
} } */
+
+
+int
+main ()
+{
+  return 0;
+}
-- 
2.49.0.504.g3bcea36a83-goog

Re: [PATCH 2/2] libgcobol: Allow libgcobol to use libquadmath [PR119244].

[Jakub Jelinek]

On Sun, Apr 06, 2025 at 09:02:07AM +0100, Iain Sandoe wrote:
> Many of the changes are mechanical:
>  1. 'GCOB_FP128' in place of _Float128.
>  2. Using FP128_FUNC to represent the spelling of intrinsics.
>  3. Using GCOB_FP128_LITERAL() to choose the suffix for literals.
> 
> This allows for:
>   __float128 and 'q' as the suffix when libquadmath is configured.
>_Float128 / 'f128' when IEC-60559 is available in libc
>  long double / 'l' when long double is ieee753 128b.
> 
> Add libquadmath to libgcobol.spec and its dependencies  where the
> platform needs it.
> 
>   PR cobol/119244
> 
> libgcobol/ChangeLog:
> 
>   * Makefile.am: Add support for libquadmath.
>   * Makefile.in: Regenerate.
>   * acinclude.m4: Add support for libquadmath.
>   * config.h.in: Regenerate.
>   * configure: Regenerate.
>   * configure.ac: Configure libquadmath support.
>   * gmath.cc: Use GCOB_FP128 to represent the configured
>   128b floating point type.  Use FP128_FUNC to represent
>   the naming of intrinsics in the configure 128b floating
>   point type. Render literals with GCOB_FP128_LITERAL.
>   * intrinsic.cc: Likewise.
>   * libgcobol.cc: Likewise.
>   * libgcobol.h: Likewise.
>   * libgcobol-fp.h: New file.
>   * gfileio.cc: Include libgcobol-fp.h.
>   * libgcobol.spec.in: Add libquadmath configure output.
> 
> Signed-off-by: Iain Sandoe 

Ok.

Jakub

Re: OpenACC: Support GCC/C++-special 'default(_GCC_firstprivate)' clause [PR119692]

[Tobias Burnus]

Hi Thomas,

Thomas Schwinge wrote:


To allow me to progress with other work items, is the attached
"OpenACC: Support GCC/C++-special 'default(_GCC_firstprivate)' clause 
[PR119692]"
OK to push to trunk branch, with a few test cases added?


I assume this patch has been withdrawn.
(Collateral from your follow-up comment in the PR).

* * *

I have to admit that I do not understand the idea of this patch, possibly
except for using it with some testcases.

Your patch email also does not really describe this - nor does the PR.

However, IMHO, the real solution is -- a language hook.

Namely, by using the existing 'omp_predetermined_mapping' langhook,
modified as needed.

It seems as if you concur, given what you point to this langhook
in the PR.  (After sending this patch/hack.)

->https://gcc.gnu.org/PR119692

* * *


(I might also suggest OpenACC 'default(firstprivate)' for standardization
by the OpenACC Technical Committee.)


Speaking more from the OpenMP side than OpenACC side, but presumably applying
to either: I find the default most useful - or default(none). The default
settings are rather sensible while 'default(none)' avoids some gotchas.

As a user, the most confusing bit is that scalars are firstprivatized
(omp target, acc parallel), even if there are semantic and technical reasons
that it often makes sense

Hence, I am not sure how useful a 'default(firstprivate)' is. But I guess for
some corner case, it is.

In OpenMP, the defaultmap also permits to specify the preferred mapping per
category (scalar, pointer, aggregate, allocatable - and 'all'), which IMHO
is useful to avoid some confusions (how are scalars handled?) and permits
finetuning.

BTW: At least in OpenMP, some default features are not representable by
mapping flags - like pointer mapping, which are privatized but the pointer
target (pointee) is updated if already mapped.

Tobias

Re: [PATCH v4] libstdc++: Implement debug format for strings and characters formatters [PR109162]

[Tomasz Kaminski]

On Thu, Apr 10, 2025 at 6:39 PM Jonathan Wakely  wrote:

> On 10/04/25 11:24 +0200, Tomasz Kamiński wrote:
> >This patch implements part P2286R8 that specified debug (escaped)
> >format for the strings and characters sequences. This include both
> >handling of the '?' format specifier and set_debug_format member.
> >
> >To indicate partial support we define __glibcxx_format_ranges macro
> >value 1, without defining __cpp_lib_format_ranges.
> >
> >We provide two separate escaping routines depending on the literal
> >encoding for the corresponding character types. If the character
> >encoding is Unicode, we follow the specification for the standard
> >(__format::__write_escaped_unicode).
> >For other encodings, we escape only characters in range [0x00, 0x80),
> >interpreting them as ACII values: [0x00, 0x20), 0x7f and  '\t', '\r',
>
> "ASCII"
>
> >'\n', '\\', '"', '\'' are escaped. We assume every character outside
> >this range is printable (__format::_write_escaped_ascii).
> >In particular we do not yet implement special handling of shift
> >sequences.
> >
> >For Unicode escaping a new __escape_edges table is introduced,
> >that encodes information if character belongs to General_Category
> >that is escaped by the standard (Control or Other). This table
> >is generated from DerivedGeneralCategory.txt provided by Unicode.
> >Only boolean flag is preserved to reduce the number of entires.
>
> "entries"
>
> >The additional rules for escaping are handled by __should_escape_unicode.
> >
> >When width or precision is specified, we emit escaped string to the
> temporary
> >buffer and format the resulting string according to the format spec.
> >For characters use a fixed size stack buffer, for which a new
> _Fixedbuf_sink is
> >introduced. For strings, we use _Str_sink and to avoid allocations,
> >we compute the estimated size of (possibly truncated) input, and if it is
> >larger than width field we print directly.
> >
> >   PR libstdc++/109162
> >
> >contrib/ChangeLog:
> >
> >   * unicode/README: Mentioned DerivedGeneralCategory.txt.
> >   * unicode/gen_libstdcxx_unicode_data.py: Generation __escape_edges
> >   table from DerivedGeneralCategory.txt. Update file name in
> comments.
> >   * unicode/DerivedGeneralCategory.txt: Copy of file distrubuted by
>
> "distributed"
>
> >   Unicode Consortium.
> >
> ftp://ftp.unicode.org/Public/UNIDATA/extracted/DerivedGeneralCategory.txt.
>
>
> I still don't think we want the URL in the ChangeLog.
>
> >libstdc++-v3/ChangeLog:
> >
> >   * include/bits/chrono_io.h (__detail::_Widen): Moved to std/format
> file.
> >   * include/bits/unicode-data.h: Regnerate.
> >   * include/bits/unicode.h (__unicode::_Utf_iterator::_M_units)
> >   (__unicode::__should_escape_category): Define.
>
> What happened to the changes to bits/version.def and bits/version.h ?
>
> I thought you were going to change version.def to use no_stdname but
> now it's not in the patch at all.
>
The are already in master, as I merged them with formatter for
vector::reference:
https://gcc.gnu.org/cgit/gcc/commit/?id=84d668b0ca67c5d3fe6430f101d61e60aa796a81

>
> >   * include/std/format (_GLIBCXX_WIDEN_, _GLIBCXX_WIDEN): Copied from
> >   include/bits/chrono_io.h.
> >   (__format::_Widen): Moved from include/bits/chrono_io.h.
> >   (__format::_Term_char, __format::_Escapes, __format::_Separators)
> >   (__format::__should_escape_ascii,
> __format::__should_escape_unicode)
> >   (__format::__write_escape_seq, __format::__write_escaped_char)
> >   (__format::__write_escaped_acii, __format::__write_escaped_unicode)
> >   (__format::__write_escaped): Define.
> >   (__formatter_str::_S_format): Extracted truncation of character
> >   sequences.
> >   (__formatter_str::format): Handle _Pres_esc.
> >   (__formatter_int::_M_do_parse) [__glibcxx_format_ranges]: Parse
> '?'.
> >   (__formatter_int::_M_format_character_escaped): Define.
> >   (formatter<_CharT, _CharT>::format, formatter wchar_t>::format):
> >   Handle _Pres_esc.
> >   (__formatter_str::set_debug_format,
> formatter<...>::set_debug_format)
> >   Guard with __glibcxx_format_ranges.
> >   (__format::_Fixedbuf_sink): Define.
> >   * testsuite/std/format/debug.cc: New test.
> >   * testsuite/std/format/debug_nonunicode.cc: New test.
> >   * testsuite/std/format/parse_ctx.cc (escaped_strings_supported):
> Define
> >   to true if __glibcxx_format_ranges is defined.
> >   * testsuite/std/format/string.cc (escaped_strings_supported):
> Define to
> >true if __glibcxx_format_ranges is defined.
> >---
> > This I believe address all review suggestions. I have also followed
> > Patrick's suggestions and added debug_nonunicode.cc test file.
> > Which helped to surface problem, where _GLIBCXX_WIDEN("\D") was
> > ill-formed for non-unicode encodings.
> >
> > contrib/unicode/DerivedGeneralCategory.txt| 4323 +
> > con

[Fortran, Patch, Teams, 1/5] Unify handling of STAT= and ERRMSG= optional arguments [PR87939]

[Andre Vehreschild]

Hi all,

this patch unifies handling of STAT= and ERRMSG= for some users of these
optional arguments. The first introduction of the arguments seems to stem from
SYNC, which choose the rule name sync_stat in the Fortran grammar. Therefore I
named the structure and participating routines the same. The patch allows for
easy parsing, resolving and translating these arguments. There is also an
implementation on how to make use of this for functions like MOVE_ALLOC(). The
following patches make use sync_stat in the teams statements.

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

Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From b329c2d35cbc4a5ecf0445811f1236ef3c9e9611 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild 
Date: Fri, 14 Mar 2025 14:20:18 +0100
Subject: [PATCH 1/6] Fortran: Unify handling of STAT= and ERRMSG= optional
 arguments [PR87939]

In preparing F2018 Teams handling improvements, unify handling of STAT=
and ERRMSG= optional arguments.  Handling of stat and errmsg in most
teams statements is corrected in the next patch.

Implement stat and errmsg for move_alloc () to comply with F2018.

	PR fortran/87939

gcc/fortran/ChangeLog:

	* check.cc (gfc_check_move_alloc): Add stat and errmsg to
	move_alloc.
	* dump-parse-tree.cc (show_sync_stat): New helper function.
	(show_code_node): Use show_sync_stat to print stat and errmsg.
	* gfortran.h (struct sync_stat): New struct to unify stat and
	errmsg handling.
	* intrinsic.cc (add_subroutines): Correct signature of
	move_alloc.
	* intrinsic.h (gfc_check_move_alloc): Correct signature of
	check_move_alloc.
	* match.cc (match_named_arg): Match an optional argument to a
	statement.
	(match_stat_errmsg): Match a stat= or errmsg= named argument.
	(gfc_match_critical): Use match_stat_errmsg to match the named
	arguments.
	(gfc_match_sync_team): Same.
	* resolve.cc (resolve_team_argument): Resolve an expr to have
	type TEAM_TYPE from iso_fortran_env.
	(resolve_scalar_variable_as_arg): Resolve an argument as a
	scalar type.
	(resolve_sync_stat): Resolve stat and errmsg expressions.
	(resolve_sync_team): Resolve a sync team statement using
	sync_stat helper.
	(resolve_end_team): Same.
	(resolve_critical): Same.
	* trans-decl.cc (gfc_build_builtin_function_decls): Correct
	sync_team signature.
	* trans-intrinsic.cc (conv_intrinsic_move_alloc): Store stat
	an errmsg optional arguments in helper struct and use helper
	to translate.
	* trans-stmt.cc (trans_exit): Implement DRY pattern for
	generating an _exit().
	(gfc_trans_sync_stat): Translate stat and errmsg contents.
	(gfc_trans_end_team): Use helper to translate stat and errmsg.
	(gfc_trans_sync_team): Same.
	(gfc_trans_critical): Same.
	* trans-stmt.h (gfc_trans_sync_stat): New function.
	* trans.cc (gfc_deallocate_with_status): Parameterize check at
	runtime to allow unallocated (co-)array when freeing a
	structure.
	(gfc_deallocate_scalar_with_status): Same and also add errmsg.
	* trans.h (gfc_deallocate_with_status): Signature changes.
	(gfc_deallocate_scalar_with_status): Same.

libgfortran/ChangeLog:

	* caf/single.c (_gfortran_caf_lock): Correct stat value, if
	lock is already locked by current image.
	(_gfortran_caf_unlock): Correct stat value, if lock is not
	locked.

gcc/testsuite/ChangeLog:

	* gfortran.dg/coarray_critical_2.f90: New test.
	* gfortran.dg/coarray_critical_3.f90: New test.
	* gfortran.dg/team_sync_1.f90: New test.
	* gfortran.dg/move_alloc_11.f90: New test.
---
 gcc/fortran/check.cc  |  12 +-
 gcc/fortran/dump-parse-tree.cc|  23 ++-
 gcc/fortran/gfortran.h|   9 +
 gcc/fortran/intrinsic.cc  |  10 +-
 gcc/fortran/intrinsic.h   |   3 +-
 gcc/fortran/match.cc  | 121 ++--
 gcc/fortran/resolve.cc|  52 -
 gcc/fortran/trans-decl.cc |   8 +-
 gcc/fortran/trans-intrinsic.cc|  61 --
 gcc/fortran/trans-stmt.cc | 186 --
 gcc/fortran/trans-stmt.h  |   1 +
 gcc/fortran/trans.cc  |  46 +++--
 gcc/fortran/trans.h   |  11 +-
 .../gfortran.dg/coarray_critical_2.f90|  30 +++
 .../gfortran.dg/coarray_critical_3.f90|  32 +++
 gcc/testsuite/gfortran.dg/move_alloc_11.f90   |  23 +++
 gcc/testsuite/gfortran.dg/team_sync_1.f90 |  24 +++
 libgfortran/caf/single.c  |   8 +-
 18 files changed, 532 insertions(+), 128 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/coarray_critical_2.f90
 create mode 100644 gcc/testsuite/gfortran.dg/coarray_critical_3.f90
 create mode 100644 gcc/testsuite/gfortran.dg/move_alloc_11.f90
 create mode 100644 gcc/testsuite/gfortran.dg/team_sync_1.f90

diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index 9c66c25e059..00342787a51 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.

[PATCH] rtl-optimization/119689 - compare-debug failure with LRA

[Richard Biener]

The previous change to fix LRA rematerialization broke compare-debug
for i586 bootstrap.  Fixed by using prev_nonnote_nondebug_insn
instead of prev_nonnote_insn.

Bootstrapped on i586-linux where the miscompare is gone with this
patch.  Bootstrap and regtest running on x86_64-unknown-linux-gnu.

OK if the latter succeeds?

Thanks,
Richard.

PR rtl-optimization/119689
PR rtl-optimization/115568
* lra-remat.cc (create_cands): Use prev_nonnote_nondebug_insn
to check whether insn2 is directly before insn.

* g++.target/i386/pr119689.C: New testcase.
---
 gcc/lra-remat.cc |  2 +-
 gcc/testsuite/g++.target/i386/pr119689.C | 44 
 2 files changed, 45 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.target/i386/pr119689.C

diff --git a/gcc/lra-remat.cc b/gcc/lra-remat.cc
index 2f3afffcf5b..5f823193aa7 100644
--- a/gcc/lra-remat.cc
+++ b/gcc/lra-remat.cc
@@ -460,7 +460,7 @@ create_cands (void)
&& dst_regno >= FIRST_PSEUDO_REGISTER
&& reg_renumber[dst_regno] < 0
&& BLOCK_FOR_INSN (insn2) == BLOCK_FOR_INSN (insn)
-   && insn2 == prev_nonnote_insn (insn))
+   && insn2 == prev_nonnote_nondebug_insn (insn))
  {
create_cand (insn2, regno_potential_cand[src_regno].nop,
 dst_regno, insn);
diff --git a/gcc/testsuite/g++.target/i386/pr119689.C 
b/gcc/testsuite/g++.target/i386/pr119689.C
new file mode 100644
index 000..cdc6d2dade5
--- /dev/null
+++ b/gcc/testsuite/g++.target/i386/pr119689.C
@@ -0,0 +1,44 @@
+// { dg-do compile }
+// { dg-options "-O2 -fcompare-debug" }
+// { dg-additional-options "-march=i586 -mtune=generic" { target ia32 } }
+// { dg-additional-options "-fPIC" { target { fpic } } }
+
+enum gimple_code { GIMPLE_ASSIGN, GIMPLE_RETURN };
+bool is_gimple_call();
+int m_sig, m_exp, sreal_new_exp;
+struct sreal {
+  sreal(long long sig) {
+long long __trans_tmp_6 = sig >= 0 ? sig : -(unsigned long long)sig;
+sig = __trans_tmp_6 <<= sreal_new_exp -= m_exp = __trans_tmp_6;
+m_sig = sig;
+  }
+  void operator/(sreal);
+};
+struct ipa_predicate {
+  ipa_predicate(bool = true);
+  void operator&=(ipa_predicate);
+  void operator&(ipa_predicate);
+};
+void add_condition();
+gimple_code eliminated_by_inlining_prob_code;
+static int eliminated_by_inlining_prob() {
+  switch (eliminated_by_inlining_prob_code) {
+  case GIMPLE_RETURN:
+return 2;
+  case GIMPLE_ASSIGN:
+return 1;
+  }
+  return 0;
+}
+void fp_expression_p() {
+  ipa_predicate bb_predicate;
+  for (;;) {
+int prob = eliminated_by_inlining_prob();
+ipa_predicate sra_predicate;
+sra_predicate &= add_condition;
+if (is_gimple_call())
+  sreal(prob) / 2;
+if (prob != 2)
+  bb_predicate & sra_predicate;
+  }
+}
-- 
2.43.0

Re: [PATCH GCC 15] c++: ICE with nested default targ lambdas [PR119574]

[Jason Merrill]

On 4/10/25 12:34 PM, Jason Merrill wrote:

On 4/8/25 10:29 AM, Patrick Palka wrote:

The template arguments aren't dependent however -- they're just
incomplete because when we deferred them we were in the middle
deduction, and we consider a NULL_TREE template argument as dependent.


I wonder what would break if that changed?


Interestingly, the answer seems to be nothing: returning false instead 
of true for null in dependent_template_arg_p fixes the testcases in this 
patch and causes no regressions.


So for 16, let's try doing that and bring back the assert?

Jason

Re: Questions on replacing a structure pointer reference to a call to .ACCESS_WITH_SIZE in C FE

[Qing Zhao]

Hi, Martin,

Thanks a lot for all your comments and questions, really helpful.

> On Apr 10, 2025, at 01:41, Martin Uecker  wrote:
> 
> Am Mittwoch, dem 09.04.2025 um 18:31 + schrieb Qing Zhao:
>> Hi, Joseph and Martin,
>> 
>> When I implemented the patch to attach the counted_by information to an 
>> array reference (FAM reference) in C FE, 
>> The work was done inside the routine “build_component_ref” in 
>> gcc/c/c-typeck.cc .  and this is very reasonable and
>> quite clean. 
>> 
>> Now, If we try to replace a structure pointer reference with counted_by 
>> attached to the FAM field, where in the C FE
>> I should look at?
>> 
>> For the following small example, I am trying to replace the pointer 
>> reference at line 28, “obj”, and line 34, “q” to a call to
>> .ACCESS_WITH_SIZE. However, “p” at line 21 and “q” at line 33 should not be 
>> replaced. 
>> 
>> Do you have any suggestions?
>> 
>> Thanks a lot for your help here.
> 
> Hi Qing,
> 
> sorry, I wasn't able to follow the thread.   If I understand correctly,
> you want to extend the reach of BDOS by using the information from
> counted_by, but not only for the size of the FAM but also for the
> size of the struct itself, for scenarious where BDOS can not find
> the original allocation.  Is this correct?

Exactly!

> 
> I have some questions about this:  The access would add new reads
> to the size field.  For counted_by, so far, those are somehow
> coupled to the access to the member.  From this you would assume
> that inserting the new accesses to the size field are ok (e.g.
> one can assume the struct is accessible, there are no new race
> conditions under some assumptions, it is initialized).  If you
> now want to read the size at different points, all this is even
> less clear to me.

struct annotated {
  size_t count;
  char array[] __attribute__((counted_by (count)));
} *p;

Currently, when we see:

p->array

We assume that the pointer p is accessible and initialized. Therefore,
Inserting the new access to the size field is ok, i.e.,

p->count 

Is valid and safe to be inserted for p->array. 

However, when we only see the pointer p, it’s not always safe to insert
p->count
Since the pointer p might not be accessible nor initialized at that point. 

Only when we are sure which use of pointer p is accessible and initialized, we 
can replace the use of pointer p with size computations and a call to 
.ACCESS_WITH_SIZE.

So, at this moment, I really feel that this might NOT be a task in FE since FE 
doesn’t
have enough information to figure out whether a use of pointer p is accessible
and initialized. 

Middle-end with data-flow might be more proper to do this?
> 
> I may miss something, but I think one would have to first
> define a clear criterion when it is ok to access the size
> field.   
> 
> So to me it seems we can not simply insert it at specific
> point in the C FE where a pointer to the struct is
> used, but only when there is some specific trigger.

Yes. 
> 
> An example I could imagine is when you memcpy
> the struct.   (but it is also not entirely clear why this
> should not be allowed to go beyond the counted_by size
> if the underlying storage is larger).  
> 
> Maybe you could add it when a pointer to an annotated
> struct is passed as parameter, but also there it is not
> clear to me that we might want to materialize new
> accesses to the struct at this point.

This is true too,  and this is even true for the current implementation for 
p->array,
as I checked with a small example as below:

[opc@qinzhao-aarch64-ol8 counted_by_whole]$ cat t2.c
#include 
#include 

struct annotated {
  size_t count;
  char array[];  
};

static size_t __attribute__((__noinline__,__noipa__)) size_of (struct annotated 
* obj)
{
  return __builtin_dynamic_object_size (obj->array, 1);
}

int main()
{
  __builtin_printf ("the bdos whole is %ld\n", size_of (0));
  return 0;
}

In the above example, the parameter to the function “size_of” has pointer type 
to “struct annotated”,
However, I passed a NULL to “size_of”, is this legal C? Looks like -Wall did 
not issue any warning 
for it.


[opc@qinzhao-aarch64-ol8 counted_by_whole]$ sh t
/home/opc/Install/latest-d/bin/gcc -O2 -Wall t2.c
the bdos whole is -1
0

Then when I added the counted_by attribute for FAM array as:

[opc@qinzhao-aarch64-ol8 counted_by_whole]$ cat t2.c
#include 
#include 

struct annotated {
  size_t count;
  char array[] __attribute__ ((counted_by(count)));  
};

static size_t __attribute__((__noinline__,__noipa__)) size_of (struct annotated 
* obj)
{
  return __builtin_dynamic_object_size (obj->array, 1);
}

int main()
{
  __builtin_printf ("the bdos whole is %ld\n", size_of (0));
  return 0;
}
[opc@qinzhao-aarch64-ol8 counted_by_whole]$ sh t
/home/opc/Install/latest-d/bin/gcc -O2 -Wall t2.c
t: line 13: 2944007 Segmentation fault  (core dumped) ./a.out
139

This is because we insert the load from the &p->count for the size.

Qing

> 
> An alternative appro

[PATCH] realloc-1.c: accept long long in warning for llp64

[Jonathan Yong]

Attached patch OK for master branch?
Will push soon if there are no objections.
From 075f2ab502ca7291887c1fa75b5351fb0cbad013 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Wed, 9 Apr 2025 14:21:22 +
Subject: [PATCH] realloc-1.c: accept long long in warning for llp64
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

llp64 targets like mingw-w64 will print:
warning: ignoring return value of ‘void* __builtin_realloc(void*, long long unsigned int)’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
Change the regex pattern to accept it.

Signed-off-by: Jonathan Yong <10wa...@gmail.com>

gcc/testsuite/ChangeLog:

	* c-c++-common/analyzer/realloc-1.c: Make diagnostic accept
	long long for __builtin_realloc warning.
---
 gcc/testsuite/c-c++-common/analyzer/realloc-1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/c-c++-common/analyzer/realloc-1.c b/gcc/testsuite/c-c++-common/analyzer/realloc-1.c
index 04925cfe5ad..0bb846c6249 100644
--- a/gcc/testsuite/c-c++-common/analyzer/realloc-1.c
+++ b/gcc/testsuite/c-c++-common/analyzer/realloc-1.c
@@ -92,5 +92,5 @@ void test_9 (void *p)
 void test_10 (char *s, int n)
 {
   __builtin_realloc(s, n); /* { dg-warning "ignoring return value of '__builtin_realloc' declared with attribute 'warn_unused_result'" "" { target c } } */
-  /* { dg-warning "ignoring return value of 'void\\* __builtin_realloc\\(void\\*, (long )?unsigned int\\)' declared with attribute 'warn_unused_result'" "" { target c++ } .-1 } */
+  /* { dg-warning "ignoring return value of 'void\\* __builtin_realloc\\(void\\*, (long )*unsigned int\\)' declared with attribute 'warn_unused_result'" "" { target c++ } .-1 } */
 } /* { dg-warning "leak" } */
-- 
2.49.0

Re: [PATCH] riscv: Fix r15-9270 fallout on RISC-V

[Robin Dapp]

Tested with compilation of x86_64-linux -> riscv64-linux cross,
ok for trunk?


Yes.

--
Regards
Robin

Re: Questions on replacing a structure pointer reference to a call to .ACCESS_WITH_SIZE in C FE

[Martin Uecker]

Am Donnerstag, dem 10.04.2025 um 17:05 + schrieb Qing Zhao:
> Hi, Martin,
> 
> Thanks a lot for all your comments and questions, really helpful.
> 
> 

...
> > 
> > An example I could imagine is when you memcpy
> > the struct.   (but it is also not entirely clear why this
> > should not be allowed to go beyond the counted_by size
> > if the underlying storage is larger).  
> > 
> > Maybe you could add it when a pointer to an annotated
> > struct is passed as parameter, but also there it is not
> > clear to me that we might want to materialize new
> > accesses to the struct at this point.
> 
> This is true too,  and this is even true for the current implementation for 
> p->array,
> as I checked with a small example as below:
> 
> [opc@qinzhao-aarch64-ol8 counted_by_whole]$ cat t2.c
> #include 
> #include 
> 
> struct annotated {
>   size_t count;
>   char array[];  
> };
> 
> static size_t __attribute__((__noinline__,__noipa__)) size_of (struct 
> annotated * obj)
> {
>   return __builtin_dynamic_object_size (obj->array, 1);
> }
> 
> int main()
> {
>   __builtin_printf ("the bdos whole is %ld\n", size_of (0));
>   return 0;
> }
> 
> In the above example, the parameter to the function “size_of” has pointer 
> type to “struct annotated”,
> However, I passed a NULL to “size_of”, is this legal C? Looks like -Wall did 
> not issue any warning 
> for it.

It is legal to pass a NULL pointer.  Here, the issue is
that the builtin does not evaluate its argument, so it
is perhaps surprising that you can get a segfault.  If
the access it outside of the builtin, then this is not
a problem

static size_t __attribute__((__noinline__,__noipa__)) size_of (struct annotated 
* obj)
{
  char *p = obj->array;
  return __builtin_dynamic_object_size (p, 1);
}

because you get the segault anyway when the first line
is executed.

Maybe we need to document that the BDOS builtin requires
 obj->array  to be accessible even though it is not
evaluated.

But I wonder whether there are other cases where
the object-size path can walk into dead code and create
accesses in this way. Not sure, but I found this bug though:
https://godbolt.org/z/ejP918nW7

Martin

> 
> 
> [opc@qinzhao-aarch64-ol8 counted_by_whole]$ sh t
> /home/opc/Install/latest-d/bin/gcc -O2 -Wall t2.c
> the bdos whole is -1
> 0
> 
> Then when I added the counted_by attribute for FAM array as:
> 
> [opc@qinzhao-aarch64-ol8 counted_by_whole]$ cat t2.c
> #include 
> #include 
> 
> struct annotated {
>   size_t count;
>   char array[] __attribute__ ((counted_by(count)));  
> };
> 
> static size_t __attribute__((__noinline__,__noipa__)) size_of (struct 
> annotated * obj)
> {
>   return __builtin_dynamic_object_size (obj->array, 1);
> }
> 
> int main()
> {
>   __builtin_printf ("the bdos whole is %ld\n", size_of (0));
>   return 0;
> }
> [opc@qinzhao-aarch64-ol8 counted_by_whole]$ sh t
> /home/opc/Install/latest-d/bin/gcc -O2 -Wall t2.c
> t: line 13: 2944007 Segmentation fault  (core dumped) ./a.out
> 139
> 
> This is because we insert the load from the &p->count for the size.
> 
> Qing
> 
> > 
> > An alternative approach could be to just do it when
> > such a pointer is explicitely passed to the BDOS builtin. 
> > 
> > Martin
> > 
> > 
> > > 
> > > Qing
> > > 
> > >  1 #include 
> > >  2 #include 
> > >  3
> > >  4 struct annotated {
> > >  5   size_t count;
> > >  6   char array[] __attribute__((counted_by (count)));
> > >  7 };
> > >  8 
> > >  9 /* compute the minimum # of bytes needed to hold a structure 
> > > “annotated”,
> > > 10whose # of elements of “array” is COUNT.  */
> > > 11 #define MAX(A, B) (A > B) ? (A) : (B)
> > > 12 #define ALLOC_SIZE_ANNOTATED(COUNT) \
> > > 13   MAX(sizeof (struct annotated), \
> > > 14   offsetof(struct annotated, array[0]) + (COUNT) * sizeof(char))
> > > 15 
> > > 16 /* allocate the memory for the structure with FAM,
> > > 17update “count” with the # of elements “index”.  */
> > > 18 static struct annotated * __attribute__((__noinline__)) alloc_buf (int 
> > > index)
> > > 19 {
> > > 20   struct annotated *p;
> > > 21   p = (struct annotated *) malloc (ALLOC_SIZE_ANNOTATED(index));
> > > 22   p->count = index;
> > > 23   return p;
> > > 24 }
> > > 25 
> > > 26 static size_t __attribute__((__noinline__)) size_of (struct annotated 
> > > * obj)
> > > 27 {
> > > 28   return __builtin_dynamic_object_size (obj, 1);
> > > 29 }
> > > 30  
> > > 31 int main()
> > > 32 {
> > > 33   struct annotated *q = alloc_buf (10);
> > > 34   __builtin_printf ("the bdos whole is %d\n", size_of (q));
> > > 35   return 0;
> > > 36 }
> 
> 

Re: [PATCH] testsuite: arm: rename arm_v8_1_lob_ok into arm_v8_1_lob_hw

[Richard Earnshaw (lists)]

On 10/04/2025 14:55, Christophe Lyon wrote:
> All arm effective-targets using check_runtime use the "_hw" or
> "_multilib" suffix, so rename arm_v8_1_lob_ok into arm_v8_1_lob_hw for
> consistency.
> 
> gcc/testsuite/ChangeLog
> 
>   * lib/target-supports.exp: Rename arm_v8_1_lob_ok into
>   arm_v8_1_lob_hw.
>   * gcc.target/arm/lob1.c: Likewise.
>   * gcc.target/arm/lob6.c: Likewise.

Since you're changing that, would you mind making the name arm_v8_1m_lob_hw?  
Although LOB is specific to
Armv8.1-m, it's not very obvious if you're not familiar with the many 
architecture extensions.

OK with that change.

R.

> ---
>  gcc/testsuite/gcc.target/arm/lob1.c   | 2 +-
>  gcc/testsuite/gcc.target/arm/lob6.c   | 2 +-
>  gcc/testsuite/lib/target-supports.exp | 6 +++---
>  3 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/gcc/testsuite/gcc.target/arm/lob1.c 
> b/gcc/testsuite/gcc.target/arm/lob1.c
> index c8ce653a5c3..b97dafa3512 100644
> --- a/gcc/testsuite/gcc.target/arm/lob1.c
> +++ b/gcc/testsuite/gcc.target/arm/lob1.c
> @@ -1,7 +1,7 @@
>  /* Check that GCC generates Armv8.1-M low over head loop instructions
> for some simple loops.  */
>  /* { dg-do run } */
> -/* { dg-require-effective-target arm_v8_1_lob_ok } */
> +/* { dg-require-effective-target arm_v8_1_lob_hw } */
>  /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
> "-mcpu=*" } } */
>  /* { dg-options "-march=armv8.1-m.main -mthumb -O3 --save-temps" } */
>  #include 
> diff --git a/gcc/testsuite/gcc.target/arm/lob6.c 
> b/gcc/testsuite/gcc.target/arm/lob6.c
> index 4fe116e2c2b..cef9d93ee4d 100644
> --- a/gcc/testsuite/gcc.target/arm/lob6.c
> +++ b/gcc/testsuite/gcc.target/arm/lob6.c
> @@ -1,7 +1,7 @@
>  /* Check that GCC generates Armv8.1-M low over head loop instructions
> with some less trivial loops and the result is correct.  */
>  /* { dg-do run } */
> -/* { dg-require-effective-target arm_v8_1_lob_ok } */
> +/* { dg-require-effective-target arm_v8_1_lob_hw } */
>  /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
> "-mcpu=*" } } */
>  /* { dg-options "-march=armv8.1-m.main -mthumb -O3 --save-temps" } */
>  #include 
> diff --git a/gcc/testsuite/lib/target-supports.exp 
> b/gcc/testsuite/lib/target-supports.exp
> index bc4361d6092..d8e28db45de 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -13562,7 +13562,7 @@ proc check_effective_target_arm_v8_3a_bkey_directive 
> { } {
>  # Return 1 if the target supports executing the Armv8.1-M Mainline Low
>  # Overhead Loop, 0 otherwise.  The test is valid for ARM.
>  
> -proc check_effective_target_arm_v8_1_lob_ok { } {
> +proc check_effective_target_arm_v8_1_lob_hw { } {
>  if { ![check_effective_target_arm_cortex_m] } {
>   return 0;
>  } else {
> @@ -13588,7 +13588,7 @@ proc check_effective_target_arm_v8_1_lob_ok { } {
>  
>  proc check_effective_target_arm_thumb2_no_arm_v8_1_lob { } {
>  if { [check_effective_target_arm_thumb2]
> -  && ![check_effective_target_arm_v8_1_lob_ok] } {
> +  && ![check_effective_target_arm_v8_1_lob_hw] } {
>   return 1
>  }
>  return 0
> @@ -13600,7 +13600,7 @@ proc 
> check_effective_target_arm_thumb2_no_arm_v8_1_lob { } {
>  
>  proc check_effective_target_arm_thumb2_ok_no_arm_v8_1_lob { } {
>  if { [check_effective_target_arm_thumb2_ok]
> -  && ![check_effective_target_arm_v8_1_lob_ok] } {
> +  && ![check_effective_target_arm_v8_1_lob_hw] } {
>   return 1
>  }
>  return 0

Re: [PATCH] [PR119706] aarch64: Add test case.

[Richard Biener]

> Am 10.04.2025 um 17:27 schrieb Jennifer Schmitz :
> 
> This patch adds a test case to the testsuite for PR119706.
> The bug was already fixed by
> https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680573.html.
> 
> OK for mainline?

Ok

Richard 


> Signed-off-by: Jennifer Schmitz 
> 
> gcc/testsuite/
>PR tree-optimization/119706
>* g++.target/aarch64/sve/pr119706.C: New test.
> ---
> .../g++.target/aarch64/sve/pr119706.C | 178 ++
> 1 file changed, 178 insertions(+)
> create mode 100644 gcc/testsuite/g++.target/aarch64/sve/pr119706.C
> 
> diff --git a/gcc/testsuite/g++.target/aarch64/sve/pr119706.C 
> b/gcc/testsuite/g++.target/aarch64/sve/pr119706.C
> new file mode 100644
> index 000..443dc50e9d9
> --- /dev/null
> +++ b/gcc/testsuite/g++.target/aarch64/sve/pr119706.C
> @@ -0,0 +1,178 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O3 -mcpu=neoverse-v2 
> --param=aarch64-autovec-preference=sve-only -w" } */
> +
> +namespace a {
> +typedef long unsigned b;
> +typedef int c;
> +template  struct e { using f = d; };
> +template  using h = typename e::f;
> +template  class> struct i {
> +  using f = aa;
> +};
> +template  class j> using k = i;
> +template  class j>
> +using l = typename k::f;
> +} // namespace a
> +inline void *operator new(a::b, void *ab) { return ab; }
> +namespace a {
> +template  class ac {
> +public:
> +  typedef b m;
> +  template  void ae(ad *ab, n... w) {
> +new (ab) ad(w...);
> +  }
> +};
> +template  using x = ac;
> +template  class af : public x {
> +public:
> +  typedef d o;
> +  template  struct ag { typedef af ah; };
> +};
> +struct ai {};
> +struct aj : ai {};
> +struct ak : aj {};
> +template  struct al;
> +template  struct al {
> +  typedef ak an;
> +  typedef c ao;
> +  typedef d ap;
> +};
> +template  typename aq ::an ar(aq) { return typename aq ::an(); }
> +template  typename as ::ao at(as au, as av, ak) { return av - 
> au; }
> +template  typename aw ::ao ax(aw au, aw av) {
> +  return at(au, av, ar(au));
> +}
> +template  struct ay { typedef c ao; };
> +} // namespace a
> +namespace az {
> +template  class ba {
> +  am bb;
> +  typedef a::al bc;
> +
> +public:
> +  typedef typename bc::an an;
> +  typedef typename bc::ao ao;
> +  typedef typename bc::ap ap;
> +  ba(am bd) : bb(bd) {}
> +  ap operator*() { return *bb; }
> +  ba operator++() {
> +++bb;
> +return *this;
> +  }
> +  am base() { return bb; }
> +};
> +template 
> +bool operator!=(ba bh, ba p) {
> +  return bh.base() != p.base();
> +}
> +template 
> +auto operator-(ba bh, ba p) {
> +  return bh.base() - p.base();
> +}
> +} // namespace az
> +namespace a {
> +struct bi {
> +  template  struct bj {
> +using f = typename d::ag::ah;
> +  };
> +  template  using bk = b;
> +  template  static constexpr bool bl = false;
> +  template  static constexpr bool bm = bl<>;
> +  template  static constexpr bool bn = bm n...>;
> +};
> +template  using bp = typename bi::bj::f;
> +template  struct bq : bi {
> +  typedef typename bo::o o;
> +  using br = l;
> +  template  struct bt { using f = typename 
> ay::ao; };
> +  template  struct bv { using f = typename bu::m; };
> +  using ao = typename bt::f;
> +  using m = typename bv::f;
> +  template  using bw = bp;
> +  static br allocate(bo, m);
> +  template 
> +  static h> ae(bo ci, d ab, n... w) {
> +ci.ae(ab, w...);
> +  }
> +};
> +template  struct bx {
> +  static bool by(d &bz) try { d(bz.begin(), bz.ca(), bz.cb()); } catch (...) 
> {
> +  }
> +};
> +} // namespace a
> +namespace az {
> +template  struct cc : a::bq {
> +  typedef a::bq q;
> +  template  struct ag { typedef typename q::bw ah; };
> +};
> +} // namespace az
> +enum cd {};
> +using ce = double;
> +namespace a {
> +template 
> +cg cj(aw au, cf av, cg ck, ch cl) {
> +  typedef az::cc cx;
> +  for (; au != av; ++au, ++ck)
> +cx::ae(cl, ck, *au);
> +}
> +template  struct cm {
> +  typedef typename az::cc::ag::ah cn;
> +  typedef typename az::cc::br br;
> +  struct co {
> +br db;
> +br cp;
> +  };
> +  struct cq : cn, co {
> +cq(cn) {}
> +  } typedef cr;
> +  cn cs();
> +  cr cb() noexcept;
> +  cm(cr ci) : ct(ci) {}
> +  cq ct;
> +  br cu(b cv) {
> +typedef az::cc cw;
> +return cv ? cw::allocate(ct, cv) : c();
> +  }
> +};
> +template > class cy : cm {
> +  typedef cm cz;
> +
> +public:
> +  typedef typename cz::br br;
> +  typedef az::ba da;
> +  typedef b m;
> +  typedef bo cr;
> +  cz::cs;
> +  template  cy(aw au, aw av, cr ci) : cz(ci) {
> +dg(au, av, ar(au));
> +  }
> +  cz::cb;
> +  da begin() { return this->ct.db; }
> +  da ca() { return this->ct.cp; }
> +  void r() { s(); }
> +  void clear() { t(this->ct.db); }
> +  template  void dg(cg au, cg av, ai) { y(au, av, ax(au, av)); }
> +  template  void y(am au, cf av, m cv) {
> +br z = this->cu(dc(cv, cs()));
> +cj(au, av, z, cs());
> +  }
> +  bool s();
> +  m dc(m cv, cr) { return cv; }
> +  void t(br dd) {
> +if (this->ct.cp - dd)
> +  this->ct.cp =

Re: [PATCH v1 3/4] libstdc++: Implement std::extents [PR107761].

[Tomasz Kaminski]

On Wed, Apr 9, 2025 at 9:28 AM Luc Grosheintz 
wrote:

> This implements std::extents from  according to N4950 and
> contains partial progress towards PR107761.
>
> If an extent changes its type, there's a precondition in the standard,
> that the value is representable in the target integer type. This commit
> uses a static_cast for all of these conversions, without any additional
> checks.
>
> The precondition for 'extents::{static_,}extent' is that '__r < rank()'.
> For extents this precondition is always violated and results in
> calling __builtin_trap. For all other specializations it's checked via
> __glibcxx_assert.
>
> PR libstdc++/107761
>
> libstdc++-v3/ChangeLog:
>
> * include/std/mdspan (extents): New class.
> * src/c++23/std.cc.in: Add 'using std::extents'.
>
> Signed-off-by: Luc Grosheintz 
> ---
>
Thanks for working on this. One general comment, as this is c++23 feature,
we can benefit for the extensions to consteval functions, and replace the
usual metaprogramming
recursion with consteval functions, like following:
__static_extent(size_t count, initializer_list extends)
{
   // use normal for to compute the product
}
We will elminiate instantiotns of the class template in this way.

 libstdc++-v3/include/std/mdspan  | 400 +++
>  libstdc++-v3/src/c++23/std.cc.in |   6 +-
>  2 files changed, 405 insertions(+), 1 deletion(-)
>
> diff --git a/libstdc++-v3/include/std/mdspan
> b/libstdc++-v3/include/std/mdspan
> index 4094a416d1e..5c6a1868d62 100644
> --- a/libstdc++-v3/include/std/mdspan
> +++ b/libstdc++-v3/include/std/mdspan
> @@ -33,6 +33,10 @@
>  #pragma GCC system_header
>  #endif
>
> +#include 
> +#include 
> +#include 
> +
>  #define __glibcxx_want_mdspan
>  #include 
>
> @@ -42,6 +46,402 @@ namespace std _GLIBCXX_VISIBILITY(default)
>  {
>  _GLIBCXX_BEGIN_NAMESPACE_VERSION
>
> +  namespace __detail
>
I would use a dedicated internal namespace for mdspan, like __mdspan.

> +  {
> +// Computed as: sum_i (i == __r) * E_i
> +template
> +  struct _StaticExtent;
> +
> +template
> +  struct _StaticExtent<_Count, _Extent, _Extents...>
> +  {
> +   static constexpr size_t
> +   _M_value(size_t __r) noexcept
> +   {
> + return (_Count == __r) * _Extent
> ++ _StaticExtent<_Count + 1, _Extents...>::_M_value(__r);
> +   }
> +  };
> +
> +template
> +  struct _StaticExtent<_Count>
> +  {
> +   static constexpr size_t
> +   _M_value(size_t __r) noexcept
> +   { return 0; }
> +  };
>
As mentioned, I would experiment with implementing this as a consteval
function, that accepts _Count and
extends as parameters. We could also declare them as static methods inside
the extends class itself,
and create a stack array of extends inside them:
static consteval
_static_extent(size_t i)
{
  size_t __exts[]{ __Extents };
  return __exts[i];
}
Or I suggest below, we can pass extends as std::array NTTP and have access
to it direclty.

> +
> +// Computed as: sum_i (i < __r) * (E_i == dynamic_extent)
> +template
> +  struct _DynamicIndex;
> +
> +template
> +  struct _DynamicIndex<_Count, _Extent, _Extents...>
> +  {
> +   static constexpr size_t
> +   _M_value(size_t __r) noexcept
> +   {
> + return (_Count < __r) * (_Extent == dynamic_extent)
> ++ _DynamicIndex<_Count + 1, _Extents...>::_M_value(__r);
> +   }
> +  };
> +
> +template
> +  struct _DynamicIndex<_Count>
> +  {
> +   static constexpr size_t
> +   _M_value(size_t __r) noexcept
> +   { return 0; }
> +  };
> +
> +// Computed by: counting the number of dynamic extents (_Dr); and
> returning
> +// the static index first time `__di == _Dr`.
> +template
> +  struct _DynamicIndexInv;
> +
> +template
> +  struct _DynamicIndexInv<_Si, _Dr, _Extent, _Extents...>
> +  {
> +   static constexpr size_t
> +   _M_value(size_t __di) noexcept
> +   {
> + if (_Extent == dynamic_extent && __di == _Dr)
> +   return _Si;
> + else
> +   return _DynamicIndexInv<_Si+1, _Dr + (_Extent ==
> dynamic_extent),
> +   _Extents...>
> +  ::_M_value(__di);
> +   }
> +  };
> +
> +template
> +  struct _DynamicIndexInv<_Si, _Dr, _Extent>
> +  {
> +   static constexpr size_t
> +   _M_value(size_t __di) noexcept
> +   {
> + __glibcxx_assert(__di == _Dr);
> + return _Si;
> +   }
> +  };
> +
> +// Aim: __ext[i] for template parameter packs.
> +template
> +  struct _GetPackElement;
> +
> +template
> +  struct _GetPackElement<_Count, _IndexType, _IndexTypes...>
> +  {
> +   template
> + static constexpr const auto&
> + get(const _IndexType& __current, const _IndexTypes&... __rest)
> + {
> +   if constexpr (_Index == _Count)
> +

Re: [PATCH v2] testcase: Add testcase for shrink wrapping of vector::push_back [PR118502]

[Andrew Pinski]

On Sun, Mar 9, 2025 at 1:35 PM Andrew Pinski  wrote:
>
> LLVM folks noticed that GCC was shrink wrapping the call to 
> vector::push_back.
> So I thought it was a good idea to commit a testcase to make sure GCC does 
> not regress
> in this area unknowning.
>
> Note the shrink wrapping started with r15-1619-g3b9b8d6cfdf593.
> Note this enables the testcase for x86_64 (!ia32), powerpc, aarch64 and riscv 
> which I tested
> via godbolt to see the shrink wrapping occurs. Also tested the testcase for 
> both
> x86_64-linux-gnu and aarch64-linux-gnu to make sure I got the target selects 
> correct.

Ping?

>
> Changes since v1:
> * v2: Fix some comments typos that was mentioned in the bug report.
>
> PR rtl-optimization/118502
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/opt/shrink-wrapping-vector-1.C: New test.
>
> Signed-off-by: Andrew Pinski 
> ---
>  .../g++.dg/opt/shrink-wrapping-vector-1.C   | 17 +
>  1 file changed, 17 insertions(+)
>  create mode 100644 gcc/testsuite/g++.dg/opt/shrink-wrapping-vector-1.C
>
> diff --git a/gcc/testsuite/g++.dg/opt/shrink-wrapping-vector-1.C 
> b/gcc/testsuite/g++.dg/opt/shrink-wrapping-vector-1.C
> new file mode 100644
> index 000..8b1ad53fa80
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/opt/shrink-wrapping-vector-1.C
> @@ -0,0 +1,17 @@
> +// { dg-do compile { target { { { i?86-*-* x86_64-*-* } && { ! ia32 } } || { 
> powerpc*-*-* aarch64*-*-* riscv*-*-* }  } } }
> +// { dg-options "-O2  -fdump-rtl-pro_and_epilogue"  }
> +// { dg-skip-if "requires hosted libstdc++ for vector" { ! hostedlib } }
> +
> +// PR rtl-optimization/118502
> +
> +// The shrink-wrapping should happen around the slow path of 
> vector::push_back,
> +// The fast path is just checking if there is enough space and doing a few 
> stores.
> +// We want to verify that shrink wrapping always happens.
> +
> +#include 
> +
> +void push_back(std::vector& xs, unsigned char x) {
> +xs.push_back(x);
> +}
> +
> +/* { dg-final { scan-rtl-dump "Performing shrink-wrapping" 
> "pro_and_epilogue" } } */
> --
> 2.43.0
>

Re: [PATCH v2] aarch64, Darwin: Initial implementation of Apple cores [PR113257].

[Iain Sandoe]

> On 7 Apr 2025, at 13:24, Kyrylo Tkachov  wrote:
> 
> 
> 
>> On 7 Apr 2025, at 10:21, Tamar Christina  wrote:
>> 
>>> -Original Message-
>>> From: Kyrylo Tkachov 
>>> Sent: Monday, March 31, 2025 1:43 PM
>>> To: i...@sandoe.co.uk
>>> Cc: Tamar Christina ; GCC Patches >> patc...@gcc.gnu.org>; Alice Carlotti ; Richard 
>>> Sandiford
>>> ; s...@gentoo.org
>>> Subject: Re: [PATCH v2] aarch64, Darwin: Initial implementation of Apple 
>>> cores
>>> [PR113257].
>>> 
>>> Hi Iain,
>>> 
 On 22 Mar 2025, at 15:31, Iain Sandoe  wrote:
 
 0. Sorry this has taken some time to close off; partly because of waiting
 for input, but mostly that I've been stretched with other work.
 1. As per the commit message, the apparent non-conformance with 8.5/6
 because FEAT_SPECRES returns 0, is a result of the query operating
 at user priv.  The cores are confirmed to support this for priv.
 code.
 2. I added entries for the apple-m1,2,3 cores in invoke.texi.
 3. Following Andrew's suggestion and with some measurements by Tamar
 and me, figured out the LITTLE.big chip ids (at least for a sub-
 set).
 
 This has been in use for a while on aarch64-darwin branches and I've
 checked manually that it gives the right .arch lines on cfarm185.
 
 OK for trunk? (if so, when?)
 thanks
 Iain
 
 --- 8< ---
 
 After discussion with the open source support team at Apple, we have
 established that the cores conform to the 8.5 and 8.6 requirements.
 One of the mandatory features (FEAT_SPECRES) is not exposed (or
 available) in user-space code but is supported for privileged code.
 
 The values for chip IDs and the LITTLE.big variants have been taken
 from lists in the XNU and LLVM sources.
 
 PR target/113257
 
 gcc/ChangeLog:
 
 * config/aarch64/aarch64-cores.def (AARCH64_CORE): Add Apple-a12,
 Apple-M1, Apple-M2, Apple-M3 with expanded names to allow for the
 LITTLE.big versions.
 * config/aarch64/aarch64-tune.md: Regenerate.
 * doc/invoke.texi: Add apple-m1,2 and 3 cores to the ones listed
 for arch and tune selections.
 
 Signed-off-by: Iain Sandoe 
 ---
 gcc/config/aarch64/aarch64-cores.def | 16 
 gcc/config/aarch64/aarch64-tune.md   |  2 +-
 gcc/doc/invoke.texi  |  5 +++--
 3 files changed, 20 insertions(+), 3 deletions(-)
 
 diff --git a/gcc/config/aarch64/aarch64-cores.def
>>> b/gcc/config/aarch64/aarch64-cores.def
 index 0e22d72976e..7f204fd0ac9 100644
 --- a/gcc/config/aarch64/aarch64-cores.def
 +++ b/gcc/config/aarch64/aarch64-cores.def
 @@ -173,6 +173,22 @@ AARCH64_CORE("cortex-a76.cortex-a55",
>>> cortexa76cortexa55, cortexa53, V8_2A,  (F
 AARCH64_CORE("cortex-r82", cortexr82, cortexa53, V8R, (), cortexa53, 0x41,
>>> 0xd15, -1)
 AARCH64_CORE("cortex-r82ae", cortexr82ae, cortexa53, V8R, (), cortexa53,
>>> 0x41, 0xd14, -1)
 
 +/* Apple (A12 and M) cores.
 +   Known part numbers as listed in other public sources.
 +   Placeholders for schedulers, generic_armv8_a for costs.
 +   A12 seems mostly 8.3, M1 is 8.5 without BTI, M2 and M3 are 8.6
 +   From measurements made so far the odd-number core IDs are performance.
>>> */
 +AARCH64_CORE("apple-a12", applea12, cortexa53, V8_3A,  (),
>>> generic_armv8_a, 0x61, 0x12, -1)
 +AARCH64_CORE("apple-m1", applem1_0, cortexa57, V8_5A,  (),
>>> generic_armv8_a, 0x61, AARCH64_BIG_LITTLE (0x21, 0x20), -1)
 +AARCH64_CORE("apple-m1", applem1_1, cortexa57, V8_5A,  (),
>>> generic_armv8_a, 0x61, AARCH64_BIG_LITTLE (0x23, 0x22), -1)
 +AARCH64_CORE("apple-m1", applem1_2, cortexa57, V8_5A,  (),
>>> generic_armv8_a, 0x61, AARCH64_BIG_LITTLE (0x25, 0x24), -1)
 +AARCH64_CORE("apple-m1", applem1_3, cortexa57, V8_5A,  (),
>>> generic_armv8_a, 0x61, AARCH64_BIG_LITTLE (0x29, 0x28), -1)
 +AARCH64_CORE("apple-m2", applem2_0, cortexa57, V8_6A,  (),
>>> generic_armv8_a, 0x61, AARCH64_BIG_LITTLE (0x31, 0x30), -1)
 +AARCH64_CORE("apple-m2", applem2_1, cortexa57, V8_6A,  (),
>>> generic_armv8_a, 0x61, AARCH64_BIG_LITTLE (0x33, 0x32), -1)
 +AARCH64_CORE("apple-m2", applem2_2, cortexa57, V8_6A,  (),
>>> generic_armv8_a, 0x61, AARCH64_BIG_LITTLE (0x35, 0x34), -1)
 +AARCH64_CORE("apple-m2", applem2_3, cortexa57, V8_6A,  (),
>>> generic_armv8_a, 0x61, AARCH64_BIG_LITTLE (0x39, 0x38), -1)
 +AARCH64_CORE("apple-m3", applem3_0, cortexa57, V8_6A,  (),
>>> generic_armv8_a, 0x61, AARCH64_BIG_LITTLE (0x49, 0x48), -1)
>>> 
>>> I don’t think we have precedent of different MIDR part numbers resolving to 
>>> the
>>> same -mcpu string, but I think it should all work as expected.
>> 
>> Indeed, I think for the current usage it should work fine.
>> 
>>> As long as you and Tamar are happy with the feature set here no objections 
>>> from
>>> me.
>> 
>> FWIW no objections from me.  This should unblock folks 😊
>> 
>> Thanks,

Re: [Stage1][Middle-end][object-size][PATCH v1] Evaluate the object size by the size of the pointee type

[Qing Zhao]

> On Apr 7, 2025, at 22:15, Siddhesh Poyarekar  wrote:
> 
> On 2025-04-07 14:53, Qing Zhao wrote:
>>> Is there a reason to do this at the very end like this and not in the 
>>> GIMPLE_ASSIGN case in the switch block?  Something like this:
>>> 
>>> tree rhs = gimple_assign_rhs1 (stmt);
>>> tree counted_by_ref = NULL_TREE;
>>> if (gimple_assign_rhs_code (stmt) == POINTER_PLUS_EXPR
>>> || (gimple_assign_rhs_code (stmt) == ADDR_EXPR
>>> && TREE_CODE (TREE_OPERAND (rhs, 0)) == MEM_REF))
>>>   reexamine = plus_stmt_object_size (osi, var, stmt);
>>> else if (gimple_assign_rhs_code (stmt) == COND_EXPR)
>>>   reexamine = cond_expr_object_size (osi, var, stmt);
>>> else if (gimple_assign_single_p (stmt)
>>>  || gimple_assign_unary_nop_p (stmt))
>>>   {
>>> if (TREE_CODE (rhs) == SSA_NAME
>>> && POINTER_TYPE_P (TREE_TYPE (rhs)))
>>>   reexamine = merge_object_sizes (osi, var, rhs);
>>> else
>>>   expr_object_size (osi, var, rhs);
>>>   }
>>> +else if ((counted_by_ref = fam_struct_with_counted_by (rhs)))
>>> +  record_fam_object_size (osi, var, counted_by_ref);
>>> else
>>>   unknown_object_size (osi, var);
>>> 
>>> where you can then fold in all your gating conditions, including getting 
>>> the counted_by ref into the fam_struct_with_counted_by and then limit the 
>>> record_fam_object_size to just evaluating the type size + counted_by size.
>>> 
>>> This may even help avoid the insertion order hack you have to do, i.e. the 
>>> gsi_insert_seq_before vs gsi_insert_seq_after.
>> This is a good suggestion. I will try this to see any issue there.
>> My initial thought is to give the counted_by information the lowest priority
>>  if there are other information (for example, malloc) available.
>> Do you see any issue here?
> 
> No, that is the right idea, but I don't know if you'll actually need to 
> choose.  AFAICT, you'll either be able to trace the pointer to an allocation, 
> in which case the fallback is unnecessary.  Otherwise you'll trace it to one 
> of the following:
> 
> 1. An assignment from an expression that returns the pointer
> 2. A NOP with a var_decl, which is handled in the GIMPLE_NOP case; you'd need 
> to add a similar hook there.
> 
> I can't think of any other cases off the top of my head, how about you?
> 
>>> Also, it seems like simply making build_counted_by_ref available may be 
>>> unnecessary and maybe you could explore associating the counted_by 
>>> component_ref with the parent type somehow.  Alternatively, how about 
>>> building an .ACCESS_WITH_SIZE for types with FAM that have a counted_by?  
>>> That would allow the current access_with_size_object_size() to work out of 
>>> the box.
>> I am not sure about this though.
>> Our initial design is to change every component_ref  (which is a reference 
>> to the FAM)
>> in the data flow of the routine that has a counted_by attribute to a  call 
>> to .ACCESS_WITH_SIZE.
>> Then put this call to .ACCESS_WITH_SIZE into the data flow of the routine.
>> Now, if we try to associate counted_by information to the parent type, how 
>> can we add such information
>> To the data flow of the routine if there is no explicit reference to the 
>> array itself?
> 
> I'm not entirely sure, but maybe whenever there is an access on a ptr to the 
> parent struct, add a call to .ACCESS_WITH_SIZE there, with a built expression 
> for its size?  e.g for:
> 
> struct S
> {
>  size_t c;
>  char a[] __counted_by (c);
> }
> 
> void foo (Struct S *s)
> {
>  ...
>  sz = __builtin_dynamic_object_size (s, 0);
>  ...
> }
> 
> we could generate:
> 
> void foo (struct S *s)
> {
>  ...
>  sz_exp = c + sizeof (struct S);
>  s_1 = .ACCESS_WITH_SIZE (&s..., &c, ...);
>  ...
>  sz = __builtin_dynamic_object_size (*s_1, 0);
> }
> 

Yes, I prefer this approach. 

For the definition of .ACCESS_WITH_SIZE:

   ACCESS_WITH_SIZE (REF_TO_OBJ, REF_TO_SIZE, CLASS_OF_SIZE,
 TYPE_OF_SIZE, ACCESS_MODE)
   which returns the REF_TO_OBJ same as the 1st argument;

   1st argument REF_TO_OBJ: The reference to the object;
   2nd argument REF_TO_SIZE: The reference to the size of the object,
   3rd argument CLASS_OF_SIZE: The size referenced by the REF_TO_SIZE represents
 0: the number of bytes.
 1: the number of the elements of the object type;
   4th argument TYPE_OF_SIZE: A constant 0 with its TYPE being the same as the 
TYPE
of the object referenced by REF_TO_SIZE
   5th argument ACCESS_MODE:
-1: Unknown access semantics
 0: none
 1: read_only
 2: write_only
 3: read_write
   6th argument: A constant 0 with the pointer TYPE to the original flexible
 array type.

Currently, we only generate .ACCESS_WITH_SIZE for p->array if it’s a FAM with 
counted_by, the 3rd argument
of this call is 1 (the number of the elements of the object type

[PING][PATCH] doc: Clarify REG_EH_REGION note usage

[Konstantinos Eleftheriou]

Hi,
Just a ping for
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677635.html.

Thanks,
Konstantinos

[COMMITTED 10/32] gccrs: feature: Add min_specialization feature

[arthur . cohen]

From: Arthur Cohen 

gcc/rust/ChangeLog:

* checks/errors/rust-feature.cc (Feature::create): Handle 
`#![feature(min_specialization)]`.
* checks/errors/rust-feature.h: Likewise.
---
 gcc/rust/checks/errors/rust-feature.cc | 4 
 gcc/rust/checks/errors/rust-feature.h  | 1 +
 2 files changed, 5 insertions(+)

diff --git a/gcc/rust/checks/errors/rust-feature.cc 
b/gcc/rust/checks/errors/rust-feature.cc
index 25af46cbed8..441a1b288fd 100644
--- a/gcc/rust/checks/errors/rust-feature.cc
+++ b/gcc/rust/checks/errors/rust-feature.cc
@@ -55,6 +55,9 @@ Feature::create (Feature::Name f)
  "1.11.0", 37854);
 case Feature::Name::PRELUDE_IMPORT:
   return Feature (f, Feature::State::ACTIVE, "prelude_import", "1.0.0");
+case Feature::Name::MIN_SPECIALIZATION:
+  return Feature (f, Feature::State::ACTIVE, "min_specialization",
+ "1.0.0" /* FIXME: What version here? */, 31844);
 case Feature::Name::AUTO_TRAITS:
   return Feature (f, Feature::State::ACTIVE, "optin_builtin_traits",
  "1.0.0", 13231);
@@ -80,6 +83,7 @@ const std::map 
Feature::name_hash_map = {
   {"raw_ref_op", Feature::Name::RAW_REF_OP},
   {"exclusive_range_pattern", Feature::Name::EXCLUSIVE_RANGE_PATTERN},
   {"prelude_import", Feature::Name::PRELUDE_IMPORT},
+  {"min_specialization", Feature::Name::MIN_SPECIALIZATION},
 }; // namespace Rust
 
 tl::optional
diff --git a/gcc/rust/checks/errors/rust-feature.h 
b/gcc/rust/checks/errors/rust-feature.h
index 9edae6d62c3..e7cb0afc689 100644
--- a/gcc/rust/checks/errors/rust-feature.h
+++ b/gcc/rust/checks/errors/rust-feature.h
@@ -51,6 +51,7 @@ public:
 RAW_REF_OP,
 EXCLUSIVE_RANGE_PATTERN,
 PRELUDE_IMPORT,
+MIN_SPECIALIZATION,
   };
 
   const std::string &as_string () { return m_name_str; }
-- 
2.49.0

Re: [PATCH v4 1/2] i386: Prefer PLT indirection for __fentry__ calls under -fPIC

[Ard Biesheuvel]

On Wed, 9 Apr 2025 at 16:46, H.J. Lu  wrote:
>
> On Wed, Apr 9, 2025 at 1:53 AM Ard Biesheuvel  wrote:
> >
> > From: Ard Biesheuvel 
> >
> > Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
> > __fentry__") updated the logic that emits mcount() / __fentry__() calls
> > into function prologues when profiling is enabled, to avoid GOT-based
> > indirect calls when a direct call would suffice.
> >
> > There are two problems with that change:
> > - it relies on -mdirect-extern-access rather than -fno-plt to decide
> >   whether or not a direct [PLT based] call is appropriate;
> > - for the PLT case, it falls through to x86_print_call_or_nop(), which
> >   does not emit the @PLT suffix, resulting in the wrong relocation to be
> >   used (R_X86_64_PC32 instead of R_X86_64_PLT32)
> >
> > Fix this by testing flag_plt instead of ix86_direct_extern_access, and
> > updating x86_print_call_or_nop() to take flag_pic and flag_plt into
> > account. This also ensures that -mnop-mcount works as expected when
> > emitting the PLT based profiling calls.
> >
> > Note that only 64-bit codegen is affected by this change or by the
> > commit referenced above; -m32 will yield 'call *mcount@GOT()' as before.
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
> >
> > Signed-off-by: Ard Biesheuvel 
> >
> > gcc/ChangeLog:
> >
> > PR target/119386
> > * config/i386/i386.cc (x86_print_call_or_nop): Add @PLT suffix
> > where appropriate.
> > (x86_function_profiler): Fall through to x86_print_call_or_nop()
> > for PIC codegen when flag_plt is set.
> >
> > gcc/testsuite/ChangeLog:
> >
> > PR target/119386
> > * gcc.target/i386/pr119386-1.c: New test.
> > * gcc.target/i386/pr119386-2.c: New test.
> > ---
> >  gcc/config/i386/i386.cc|  8 +++-
> >  gcc/testsuite/gcc.target/i386/pr119386-1.c | 11 +++
> >  gcc/testsuite/gcc.target/i386/pr119386-2.c | 12 
> >  3 files changed, 30 insertions(+), 1 deletion(-)
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr119386-1.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr119386-2.c
> >
> > diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> > index be5e27fc391..0b238c3dddc 100644
> > --- a/gcc/config/i386/i386.cc
> > +++ b/gcc/config/i386/i386.cc
> > @@ -23154,6 +23154,12 @@ x86_print_call_or_nop (FILE *file, const char 
> > *target)
> >if (flag_nop_mcount || !strcmp (target, "nop"))
> >  /* 5 byte nop: nopl 0(%[re]ax,%[re]ax,1) */
> >  fprintf (file, "1:" ASM_BYTE "0x0f, 0x1f, 0x44, 0x00, 0x00\n");
> > +  else if (!TARGET_PECOFF && flag_pic)
> > +{
> > +  gcc_assert (flag_plt);
> > +
> > +  fprintf (file, "1:\tcall\t%s@PLT\n", target);
> > +}
> >else
> >  fprintf (file, "1:\tcall\t%s\n", target);
> >  }
> > @@ -23317,7 +23323,7 @@ x86_function_profiler (FILE *file, int labelno 
> > ATTRIBUTE_UNUSED)
> >   break;
> > case CM_SMALL_PIC:
> > case CM_MEDIUM_PIC:
> > - if (!ix86_direct_extern_access)
> > + if (!flag_plt)
> > {
> >   if (ASSEMBLER_DIALECT == ASM_INTEL)
> > fprintf (file, "1:\tcall\t[QWORD PTR 
> > %s@GOTPCREL[rip]]\n",
> > diff --git a/gcc/testsuite/gcc.target/i386/pr119386-1.c 
> > b/gcc/testsuite/gcc.target/i386/pr119386-1.c
> > new file mode 100644
> > index 000..174d00f1e27
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/i386/pr119386-1.c
> > @@ -0,0 +1,11 @@
> > +/* PR target/119386 */
> > +/* { dg-do compile { target *-*-linux* } } */
> > +/* { dg-options "-O2 -fpic -pg" } */
> > +/* { dg-final { scan-assembler "call\[ \t\]mcount@PLT" { target { ! ia32 } 
> > } } } */
> > +/* { dg-final { scan-assembler "call\[ \t\]\\*mcount@GOT\\(" { target ia32 
> > } } } */
>
> This is wrong for ia32, which should also generate "call mcount@PLT".
>

But it hasn't done that for a long time - it is hard to figure out
from the Git history how long but at least 20 years IIUC

So do you think this change should fix IA-32 as well? Note that the
issue is about emitting 'call mcount' on 64-bit where 'call
mcount@PLT' is needed, not about changing the indirect GOT based call
to a PLT call.

Re: [PATCH 5/7] ipa-cp: Use the collected pass-through types to propagate constants (PR118097)

[Jan Hubicka]

> This patch revisits the fix for PR 118097 and instead of deducing the
> necessary operation type it just uses the value collected and streamed
> by an earlier patch.
> 
> It is bigger than the ones for propagating value ranges and known bits
> because we track constants both in parameters themselves and also in
> memory they point to or within aggregates, we clone functions for them
> and we do fancy things for some types of recursive calls.
> 
> In the case of constants in aggregates or passed by reference, the
> situation should not change because the code creating jump functions
> for them does not allow type-casts, unlike for the plain ones.
> However, this patch changes how we handle them for the sake of
> consistency and also so that we can try and eliminate this limitation
> in the next stage 1.
> 
> Bootstrapped and tested and LTO bootstrapped on x86_64-linux. OK for
> master?
> 
> Thanks,
> 
> Martin
> 
> 
> gcc/ChangeLog:
> 
> 2025-03-20  Martin Jambor  
> 
>   PR ipa/118097
>   * ipa-cp.cc (ipa_get_jf_arith_result): Require res_operand for
>   anything except NOP_EXPR or ADDR_EXPR, document it and remove the code
>   trying to deduce it.
>   (ipa_value_from_jfunc): Use the stored and streamed type of arithmetic
>   pass-through functions.
>   (ipa_agg_value_from_jfunc): Use the stored and streamed type of
>   arithmetic pass-through functions, convert to the type used to store
>   the value if necessary.
>   (get_val_across_arith_op): New parameter op_type, pass it to
>   ipa_get_jf_arith_result.
>   (propagate_vals_across_arith_jfunc): New parameter op_type, pass it to
>   get_val_across_arith_op.
>   (propagate_vals_across_pass_through): Use the stored and streamed type
>   of arithmetic pass-through functions.
>   (propagate_aggregate_lattice): Likewise.
>   (push_agg_values_for_index_from_edge): Use the stored and streamed
>   type of arithmetic pass-through functions, convert to the type used to
>   store the value if necessary.
OK,
thanks!
Honza
> ---
>  gcc/ipa-cp.cc | 94 ---
>  1 file changed, 52 insertions(+), 42 deletions(-)
> 
> diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
> index e39a9e144ad..7aa17d083d3 100644
> --- a/gcc/ipa-cp.cc
> +++ b/gcc/ipa-cp.cc
> @@ -1478,10 +1478,12 @@ ipacp_value_safe_for_type (tree param_type, tree 
> value)
>  return NULL_TREE;
>  }
>  
> -/* Return the result of a (possibly arithmetic) operation on the constant 
> value
> -   INPUT.  OPERAND is 2nd operand for binary operation.  RES_TYPE is the type
> -   in which any operation is to be performed.  Return NULL_TREE if that 
> cannot
> -   be determined or be considered an interprocedural invariant.  */
> +/* Return the result of a (possibly arithmetic) operation determined by 
> OPCODE
> +   on the constant value INPUT.  OPERAND is 2nd operand for binary operation
> +   and is required for binary operations.  RES_TYPE, required when opcode is
> +   not NOP_EXPR, is the type in which any operation is to be performed.  
> Return
> +   NULL_TREE if that cannot be determined or be considered an interprocedural
> +   invariant.  */
>  
>  static tree
>  ipa_get_jf_arith_result (enum tree_code opcode, tree input, tree operand,
> @@ -1502,16 +1504,6 @@ ipa_get_jf_arith_result (enum tree_code opcode, tree 
> input, tree operand,
>   return NULL_TREE;
>  }
>  
> -  if (!res_type)
> -{
> -  if (TREE_CODE_CLASS (opcode) == tcc_comparison)
> - res_type = boolean_type_node;
> -  else if (expr_type_first_operand_type_p (opcode))
> - res_type = TREE_TYPE (input);
> -  else
> - return NULL_TREE;
> -}
> -
>if (TREE_CODE_CLASS (opcode) == tcc_unary)
>  res = fold_unary (opcode, res_type, input);
>else
> @@ -1595,7 +1587,10 @@ ipa_value_from_jfunc (class ipa_node_params *info, 
> struct ipa_jump_func *jfunc,
>   return NULL_TREE;
> enum tree_code opcode = ipa_get_jf_pass_through_operation (jfunc);
> tree op2 = ipa_get_jf_pass_through_operand (jfunc);
> -   tree cstval = ipa_get_jf_arith_result (opcode, input, op2, NULL_TREE);
> +   tree op_type
> + = (opcode == NOP_EXPR) ? NULL_TREE
> + : ipa_get_jf_pass_through_op_type (jfunc);
> +   tree cstval = ipa_get_jf_arith_result (opcode, input, op2, op_type);
> return ipacp_value_safe_for_type (parm_type, cstval);
>   }
>else
> @@ -1905,10 +1900,11 @@ ipa_agg_value_from_jfunc (ipa_node_params *info, 
> cgraph_node *node,
>   return NULL_TREE;
>  }
>  
> -  return ipa_get_jf_arith_result (item->value.pass_through.operation,
> -   value,
> -   item->value.pass_through.operand,
> -   item->type);
> +  tree cstval = ipa_get_jf_arith_result (item->value.pass_through.operation,
> +  value,
> +  

Re: [PATCH v5 5/5] libgomp: Add AArch64 SVE target tests to libgomp.

[Mark Wielaard]

Hi Tejas,

On Tue, Apr 08, 2025 at 12:02:12PM +0530, Tejas Belagod wrote:
> On 4/7/25 3:33 PM, Jakub Jelinek wrote:
> >On Mon, Apr 07, 2025 at 03:28:29PM +0530, Tejas Belagod wrote:
> >>Add AArch64 SVE target exectute tests to test various workshare constructs 
> >>and
> >>clauses with SVE types.
> >>
> >>libgomp/ChangeLog:
> >>
> >>* testsuite/libgomp.c-target/aarch64/aarch64.exp: Test driver.
> >>* testsuite/libgomp.c-target/aarch64/firstprivate.c: New test.
> >>* testsuite/libgomp.c-target/aarch64/lastprivate.c: Likewise.
> >>* testsuite/libgomp.c-target/aarch64/private.c: Likewise.
> >>* testsuite/libgomp.c-target/aarch64/shared.c: Likewise.
> >>* testsuite/libgomp.c-target/aarch64/simd-aligned.c: Likewise.
> >>* testsuite/libgomp.c-target/aarch64/simd-nontemporal.c: Likewise.
> >>* testsuite/libgomp.c-target/aarch64/threadprivate.c: Likewise.
> >>* testsuite/libgomp.c-target/aarch64/udr-sve.c: Likewise.
> >
> >Ok.
> >
> 
> Thanks for the reviews. All patches now applied on trunk.

Unfortunately this seems to have broken the riscv bootstrap:
https://builder.sourceware.org/buildbot/#/builders/337/builds/105

../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: enumeration 
value ‘TCTX_OMP_MAP’ not handled in switch [-Werror=switch]
 4730 |   switch (context)
  |  ^
../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: enumeration 
value ‘TCTX_OMP_MAP_IMP_REF’ not handled in switch [-Werror=switch]
../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: enumeration 
value ‘TCTX_OMP_PRIVATE’ not handled in switch [-Werror=switch]
../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: enumeration 
value ‘TCTX_OMP_FIRSTPRIVATE’ not handled in switch [-Werror=switch]
../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: enumeration 
value ‘TCTX_OMP_DEVICE_ADDR’ not handled in switch [-Werror=switch]
cc1plus: all warnings being treated as errors

Could you have a look?

Thanks,

Mark

[PATCH v1 4/4] libstdc++: Add tests for std::extents.

[Luc Grosheintz]

A prior commit added std::extents, this commits adds the tests. The bulk
is focussed on testing the constructors. These are split into three
groups:

1. the ctor from other extents and the copy ctor,
2. the ctor from a pack of integer-like objects,
3. the ctor from shapes, i.e. span and array.

For each group check that the ctor:
* produces an object with the expected values for extent,
* is implicit if and only if required,
* is constexpr,
* doesn't change the rank of the extent.

libstdc++-v3/ChangeLog:

* testsuite/23_containers/mdspan/extents/assign_copy.cc: New test.
* testsuite/23_containers/mdspan/extents/assign_copy_01_neg.cc: New 
test.
* testsuite/23_containers/mdspan/extents/class_traits.cc: New test.
* testsuite/23_containers/mdspan/extents/ctor_copy.cc: New test.
* testsuite/23_containers/mdspan/extents/ctor_copy_01_neg.cc: New test.
* testsuite/23_containers/mdspan/extents/ctor_copy_02_neg.cc: New test.
* testsuite/23_containers/mdspan/extents/ctor_copy_constexpr.cc: New 
test.
* testsuite/23_containers/mdspan/extents/ctor_copy_implicit_00.cc: New 
test.
* testsuite/23_containers/mdspan/extents/ctor_copy_implicit_01.cc: New 
test.
* testsuite/23_containers/mdspan/extents/ctor_copy_implicit_02_neg.cc: 
New test.
* testsuite/23_containers/mdspan/extents/ctor_copy_implicit_03_neg.cc: 
New test.
* testsuite/23_containers/mdspan/extents/ctor_copy_implicit_04_neg.cc: 
New test.
* testsuite/23_containers/mdspan/extents/ctor_ints_00.cc: New test.
* testsuite/23_containers/mdspan/extents/ctor_ints_01.cc: New test.
* testsuite/23_containers/mdspan/extents/ctor_ints_02_neg.cc: New test.
* testsuite/23_containers/mdspan/extents/ctor_ints_03_neg.cc: New test.
* testsuite/23_containers/mdspan/extents/ctor_ints_constexpr.cc: New 
test.
* testsuite/23_containers/mdspan/extents/ctor_ints_implicit_00_neg.cc: 
New test.
* testsuite/23_containers/mdspan/extents/ctor_ints_implicit_01_neg.cc: 
New test.
* testsuite/23_containers/mdspan/extents/ctor_shape_00.cc: New test.
* testsuite/23_containers/mdspan/extents/ctor_shape_01.cc: New test.
* testsuite/23_containers/mdspan/extents/ctor_shape_02_neg.cc: New test.
* testsuite/23_containers/mdspan/extents/ctor_shape_03_neg.cc: New test.
* testsuite/23_containers/mdspan/extents/ctor_shape_constexpr.cc: New 
test.
* testsuite/23_containers/mdspan/extents/ctor_shape_implicit_00.cc: New 
test.
* testsuite/23_containers/mdspan/extents/ctor_shape_implicit_01.cc: New 
test.
* testsuite/23_containers/mdspan/extents/ctor_shape_implicit_02_neg.cc: 
New test.
* testsuite/23_containers/mdspan/extents/ctor_shape_implicit_03_neg.cc: 
New test.
* testsuite/23_containers/mdspan/extents/ctor_shape_implicit_04.cc: New 
test.
* testsuite/23_containers/mdspan/extents/custom_integer.cc: New test.
* testsuite/23_containers/mdspan/extents/deduction_guide_00.cc: New 
test.
* testsuite/23_containers/mdspan/extents/deduction_guide_01_neg.cc: New 
test.
* testsuite/23_containers/mdspan/extents/dextents.cc: New test.
* testsuite/23_containers/mdspan/extents/extent.cc: New test.
* testsuite/23_containers/mdspan/extents/index_type.cc: New test.
* testsuite/23_containers/mdspan/extents/ops_eq.cc: New test.
* testsuite/23_containers/mdspan/extents/rank.cc: New test.
* testsuite/23_containers/mdspan/extents/rank_dynamic.cc: New test.
* testsuite/23_containers/mdspan/extents/rank_return_type.cc: New test.
* testsuite/23_containers/mdspan/extents/rank_type.cc: New test.
* testsuite/23_containers/mdspan/extents/size_type.cc: New test.
* testsuite/23_containers/mdspan/extents/sizeof.cc: New test.
* testsuite/23_containers/mdspan/extents/static_extent.cc: New test.

Signed-off-by: Luc Grosheintz 
---
 .../mdspan/extents/assign_copy.cc | 26 ++
 .../mdspan/extents/assign_copy_01_neg.cc  | 15 
 .../mdspan/extents/class_traits.cc| 20 +
 .../23_containers/mdspan/extents/ctor_copy.cc | 34 
 .../mdspan/extents/ctor_copy_01_neg.cc| 10 +++
 .../mdspan/extents/ctor_copy_02_neg.cc| 10 +++
 .../mdspan/extents/ctor_copy_constexpr.cc | 20 +
 .../mdspan/extents/ctor_copy_implicit_00.cc   | 28 ++
 .../mdspan/extents/ctor_copy_implicit_01.cc   | 22 +
 .../extents/ctor_copy_implicit_02_neg.cc  | 10 +++
 .../extents/ctor_copy_implicit_03_neg.cc  |  9 ++
 .../extents/ctor_copy_implicit_04_neg.cc  |  9 ++
 .../mdspan/extents/ctor_ints_00.cc| 30 +++
 .../mdspan/extents/ctor_ints_01.cc| 24 ++
 .../mdspan/extents/ctor_ints_02_neg.cc|  9 ++
 .../mdspan/extents/ctor_ints_03_neg.cc|  9 ++
 .../mdspan/extents/ctor_ints_constexpr.cc | 12 +++
 .../extents/c

[PATCH] expr: Use constant_lower_bound classifying constructor els [PR116595].

[Robin Dapp]

Hi,

in categorize_ctor_elements_1 we do
 VECTOR_CST_NELTS (value).to_constant ()
but VALUE's type can be a VLA vector (since r15-5780-g17b520a10cdaab).

This patch uses constant_lower_bound instead.

Bootstrapped and regtested on x86, aarch64, and power 10.
Regtested on rv64gcv_zvl512b.

Regards
Robin

PR middle-end/116595

gcc/ChangeLog:

* expr.cc (categorize_ctor_elements_1): Use
constant_lower_bound.

gcc/testsuite/ChangeLog:

* g++.target/riscv/rvv/autovec/pr116595.C: New test.
---
gcc/expr.cc   |  6 +++---
gcc/testsuite/g++.target/riscv/rvv/autovec/pr116595.C | 10 ++
2 files changed, 13 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/g++.target/riscv/rvv/autovec/pr116595.C

diff --git a/gcc/expr.cc b/gcc/expr.cc
index 2147eedad7b..3815c565e2d 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -7193,9 +7193,9 @@ categorize_ctor_elements_1 (const_tree ctor, 
HOST_WIDE_INT *p_nz_elts,

case VECTOR_CST:
  {
-   /* We can only construct constant-length vectors using
-  CONSTRUCTOR.  */
-   unsigned int nunits = VECTOR_CST_NELTS (value).to_constant ();
+   unsigned int nunits
+ = constant_lower_bound
+ (TYPE_VECTOR_SUBPARTS (TREE_TYPE (value)));
for (unsigned int i = 0; i < nunits; ++i)
  {
tree v = VECTOR_CST_ELT (value, i);
diff --git a/gcc/testsuite/g++.target/riscv/rvv/autovec/pr116595.C 
b/gcc/testsuite/g++.target/riscv/rvv/autovec/pr116595.C
new file mode 100644
index 000..6d509d2cf74
--- /dev/null
+++ b/gcc/testsuite/g++.target/riscv/rvv/autovec/pr116595.C
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv" } */
+
+#include 
+
+void
+vsseg (float *a, vfloat32mf2_t b, vfloat32mf2_t c, unsigned long vl)
+{
+  vfloat32mf2x2_t foo = vfloat32mf2x2_t ();
+}
--
2.49.0

Re: [PATCH v4] libstdc++: Implement debug format for strings and characters formatters [PR109162]

[Jonathan Wakely]

On Thu, 10 Apr 2025 at 18:53, Tomasz Kaminski  wrote:
>
>
>
> On Thu, Apr 10, 2025 at 6:39 PM Jonathan Wakely  wrote:
>> What happened to the changes to bits/version.def and bits/version.h ?
>>
>> I thought you were going to change version.def to use no_stdname but
>> now it's not in the patch at all.
>
> The are already in master, as I merged them with formatter for 
> vector::reference:
> https://gcc.gnu.org/cgit/gcc/commit/?id=84d668b0ca67c5d3fe6430f101d61e60aa796a81


Ah yes, of course!

OK for trunk with the last few typos fixed then, thanks.

[PING][PATCH v3] reassoc: Optimize CMP/XOR expressions [PR116860]

[Konstantinos Eleftheriou]

Hi,
Just a ping for
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677788.html .

Thanks,
Konstantinos

[PATCH] Add std::deque shrink_to_fit test

[François Dumont]

Hi

    No problem detected now that we really test std::deque 
shrink_to_fit implementation.


    libstdc++: Add std::deque<>::shrink_to_fit test

    The existing test is currently testing std::vector. Make it test 
std::deque.


    libstdc++-v3/ChangeLog:

    * testsuite/23_containers/deque/capacity/shrink_to_fit.cc: 
Adapt test

    to check std::deque shrink_to_fit method.

Tested under Linux x64.

Ok to commit ?

François
diff --git 
a/libstdc++-v3/testsuite/23_containers/deque/capacity/shrink_to_fit.cc 
b/libstdc++-v3/testsuite/23_containers/deque/capacity/shrink_to_fit.cc
index 7cb67079214..57e66de70f4 100644
--- a/libstdc++-v3/testsuite/23_containers/deque/capacity/shrink_to_fit.cc
+++ b/libstdc++-v3/testsuite/23_containers/deque/capacity/shrink_to_fit.cc
@@ -1,4 +1,5 @@
 // { dg-do run { target c++11 } }
+// { dg-add-options no_pch }
 
 // 2010-01-08  Paolo Carlini  
 
@@ -19,18 +20,32 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-#include 
+#define _GLIBCXX_DEQUE_BUF_SIZE sizeof(int) * 3
+
+#include 
 #include 
+#include 
 
 // libstdc++/42573
 void test01()
 {
-  std::vector d(100);
+  __gnu_test::counter::reset();
+
+  std::deque d;
   d.push_back(1);
   d.push_back(1);
-  // VERIFY( d.size() < d.capacity() );
+  d.push_back(1);
+  d.pop_front();
+  VERIFY( d.size() == 2 );
+  // 1 node array allocation + 2 node allocation = 3.
+  VERIFY( __gnu_test::counter::count() == 3 );
+  VERIFY( __gnu_test::counter::get()._M_increments == 3 );
+
   d.shrink_to_fit();
-  // VERIFY( d.size() == d.capacity() );
+  VERIFY( d.size() == 2 );
+  // 1 node array allocation + 1 node allocation = 2.
+  VERIFY( __gnu_test::counter::count() == __cpp_exceptions ? 2 : 3 );
+  VERIFY( __gnu_test::counter::get()._M_increments == 3 + (__cpp_exceptions ? 
2 : 0) );
 }
 
 int main()

[COMMITTED 24/32] gccrs: Fix unresolved label error message

[arthur . cohen]

From: Pierre-Emmanuel Patry 

gcc/rust/ChangeLog:

* resolve/rust-ast-resolve-expr.cc (ResolveExpr::visit):
Change error message to match rustc.

gcc/testsuite/ChangeLog:

* rust/compile/undeclared_label.rs: Change test
expected string.

Signed-off-by: Pierre-Emmanuel Patry 
---
 gcc/rust/resolve/rust-ast-resolve-expr.cc  | 8 
 gcc/testsuite/rust/compile/undeclared_label.rs | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/rust/resolve/rust-ast-resolve-expr.cc 
b/gcc/rust/resolve/rust-ast-resolve-expr.cc
index dc7f76d652d..4bfd1b3ca4f 100644
--- a/gcc/rust/resolve/rust-ast-resolve-expr.cc
+++ b/gcc/rust/resolve/rust-ast-resolve-expr.cc
@@ -486,8 +486,8 @@ ResolveExpr::visit (AST::BreakExpr &expr)
&resolved_node))
{
  rust_error_at (label.get_locus (), ErrorCode::E0426,
-"use of undeclared label %qs in %",
-label.get_lifetime_name ().c_str ());
+"use of undeclared label %qs",
+label.as_string ().c_str ());
  return;
}
   resolver->insert_resolved_label (label.get_node_id (), resolved_node);
@@ -609,8 +609,8 @@ ResolveExpr::visit (AST::ContinueExpr &expr)
&resolved_node))
{
  rust_error_at (expr.get_label ().get_locus (), ErrorCode::E0426,
-"use of undeclared label %qs in %",
-label.get_lifetime_name ().c_str ());
+"use of undeclared label %qs",
+label.as_string ().c_str ());
  return;
}
   resolver->insert_resolved_label (label.get_node_id (), resolved_node);
diff --git a/gcc/testsuite/rust/compile/undeclared_label.rs 
b/gcc/testsuite/rust/compile/undeclared_label.rs
index 6efa2d98dbf..9aa0553f657 100644
--- a/gcc/testsuite/rust/compile/undeclared_label.rs
+++ b/gcc/testsuite/rust/compile/undeclared_label.rs
@@ -2,12 +2,12 @@
 #![allow(unused)]
 fn resolve_label_continue() -> () {
 loop {
-continue 'a; // { dg-error "use of undeclared label .a. in .continue." 
}
+continue 'a; // { dg-error "use of undeclared label .'a." }
 }
 }
 fn resolve_label_break() -> () {
 loop {
-break 'crabby; // { dg-error "use of undeclared label .crabby. in 
.break." }
+break 'crabby; // { dg-error "use of undeclared label .'crabby." }
 }
 }
 fn main() {
-- 
2.49.0

Re: [PATCH] libgomp: Update SVE tests

[Tejas Belagod]

On 4/9/25 4:13 PM, Jakub Jelinek wrote:

On Wed, Apr 09, 2025 at 04:01:49PM +0530, Tejas Belagod wrote:

It also looks like there might be a missing "+" in simd_reduction:

#pragma omp simd reduction (+:va, i)
for (j = 0; j < 16; j++)
  va = svld1_s32 (svptrue_b32 (), a);

res = svaddv_s32 (svptrue_b32 (), va);

if (res != 8)
  __builtin_abort ();

since AFAICT the loop is not doing a reduction as things stand.
But perhaps that's deliberate, since it does match the != 8 test.


That's interesting. I thought the reduction definition in the
'declare reduction' does the reduction from all the individual interations
according the the rules defined in the reduction irrespective of the loop
structure.  Maybe 'va' doesn't become implicit private and causes a race
(which may be why I didn't see it in my testing) - I'll try to repro this
and have a look.


No, reduction privatizes the variable, initializes the private variable with
the initializer from UDR and reduces at the end only from all the private
variables to the original one.

For simd, each SIMD lane has one private copy and there are # SIMD lanes
reductions into the original, for e.g. worksharing constructs each thread
has a private copy and there are omp_get_num_threads () reductions, etc.

There is no special action at the end of each loop body, it is up to the
user to merge state from each iteration.  In sane code the loop body does
similar operation to what the reduction does.
So say if you have
float sum = 0;
#pragma omp parallel for reduction (+:sum)
for (int i = 0; i < 1024; ++i)
   sum += a[i];
then if OpenMP pragmas are ignored, all the array members
are summed up in that order, while if say there are 4
threads and each handles 256 iterations, then each thread will
start with sum = 0; and do sum += a[i]; for i omp_get_thread_num () * 256
to omp_get_thread_num () * 256 + 255 inclusive and finally in some random
order the 4 private floats will be summed together.
For floating point that can result in different behavior (different rounding
etc.) but user said it is ok like that.



Thanks for the explanation.  I looked into why some of the tests may 
have failed - my flawed understanding of the reduction clause was why I 
didn't have the += in the loops - it might have passed for me as I 
probably hit the exact omp_get_num_threads () number required for the 
final += reductions to trigger from the declare clause.  As Richard 
said, the += in the loops ought to fix the tests. I'm still analysing 
inscan_reduction_incl () to fix it properly.


Thanks,
Tejas.

Re: [PATCH] libgcobol, v2: Handle long double as an alternate IEEE754 128b

[Iain Sandoe]

> On 10 Apr 2025, at 17:36, Jakub Jelinek  wrote:
> 
> On Wed, Apr 09, 2025 at 02:22:16PM +0200, Rainer Orth wrote:
>>> Here is what I'm testing as an incremental fix, so far OK on x86_64-darwin
>>> and powerpcle64 (GLIBC 2.34) .. others in progress.  Does it help the
>>> Solaris cases?
>> 
>> I'll give it a try.  Here's what I have (I believe it's more readable in
>> some cases), but as I said something's not right yet (probably something
>> very stupid).
> 
> Yes, most importantly
> 
>> #if !defined (HAVE_STRFROMF128)
>> -# if !USE_QUADMATH
>> +static int
>> +strfromf128 (char *s, size_t n, const char *f, long double v)
> 
> this long double should have been GCOB_FP128.
> 
> Anyway, I think there should be consistency in what we use, so like
> libgcobol-fp.h specifies, IEEE quad long double should have highest
> priority, then _Float128 with *f128 APIs, then libquadmath.
> And when we decide to use say long double, we shouldn't mix that with
> strfromf128/strtof128.
> 
> Additionally, given that the *l vs. *f128 vs. *q API decision is done
> solely in libgcobol and not in the compiler (which is different from
> the Fortran case where compiled code emits say sinq or sinf128 calls),
> I think libgcobol.spec should only have -lquadmath in any form only in
> the case when using libquadmath for everything.  In the Fortran case
> it is for backwards compatibility purposes, if something has been
> compiled with older gfortran which used say sinq and link is done by
> gfortran which has been configured against new glibc with *f128, linking
> would fail otherwise.
> 
> So, here is an updated patch based on your patch, so far briefly
> tested on x86_64 with recent glibc (i.e. with the *f128 APIs).

makes sense to me - and builds and tests on x86_64-darwin (which needs
libquadmath) without issue.
Iain

> 
> 2025-04-10  Jakub Jelinek  
>   Rainer Orth  
> 
>   PR cobol/119244
>   * acinclude.m4 (LIBGCOBOL_CHECK_FLOAT128): Ensure
>   libgcob_cv_have_float128 is not yes on targets with IEEE quad
>   long double.  Don't check for --as-needed nor set LIBQUADSPEC
>   on targets which USE_IEC_60559.
>   * libgcobol-fp.h (FP128_FMT, strtofp128, strfromfp128): Define.
>   * intrinsic.cc (strtof128): Don't redefine.
>   (WEIRD_TRANSCENDENT_RETURN_VALUE): Use GCOB_FP128_LITERAL macro.
>   (__gg__numval_f): Use strtofp128 instead of strtof128.
>   * libgcobol.cc (strtof128): Don't redefine.
>   (format_for_display_internal): Use strfromfp128 instead of
>   strfromf128 or quadmath_snprintf and use FP128_FMT in the format
>   string.
>   (get_float128, __gg__compare_2, __gg__move, __gg__move_literala):
>   Use strtofp128 instead of strtof128.
>   * configure: Regenerate.
> 
> --- libgcobol/acinclude.m4.jj 2025-04-10 17:14:36.535278015 +0200
> +++ libgcobol/acinclude.m42025-04-10 17:33:56.012347476 +0200
> @@ -44,6 +44,10 @@ AC_DEFUN([LIBGCOBOL_CHECK_FLOAT128], [
>   AC_CACHE_CHECK([whether we have a usable _Float128 type],
>  libgcob_cv_have_float128, [
>GCC_TRY_COMPILE_OR_LINK([
> +#if __LDBL_MANT_DIG__ == 113 && __LDBL_MIN_EXP__ == -16381
> +#error "long double is IEEE quad, no need for libquadmath"
> +#endif
> +
> _Float128 foo (_Float128 x)
> {
>  _Complex _Float128 z1, z2;
> @@ -90,32 +94,22 @@ AC_DEFUN([LIBGCOBOL_CHECK_FLOAT128], [
> fi
> AC_DEFINE(HAVE_FLOAT128, 1, [Define if target has usable _Float128 and 
> __float128 types.])
> 
> -dnl Check whether -Wl,--as-needed resp. -Wl,-zignore is supported
> -dnl 
> -dnl Turn warnings into error to avoid testsuite breakage.  So enable
> -dnl AC_LANG_WERROR, but there's currently (autoconf 2.64) no way to turn
> -dnl it off again.  As a workaround, save and restore werror flag like
> -dnl AC_PATH_XTRA.
> -dnl Cf. http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01889.html
> -
> ac_xsave_[]_AC_LANG_ABBREV[]_werror_flag=$ac_[]_AC_LANG_ABBREV[]_werror_flag
> -AC_CACHE_CHECK([whether --as-needed/-z ignore works],
> -  [libgcob_cv_have_as_needed],
> -  [
> -  # Test for native Solaris options first.
> -  # No whitespace after -z to pass it through -Wl.
> -  libgcob_cv_as_needed_option="-zignore"
> -  libgcob_cv_no_as_needed_option="-zrecord"
> -  save_LDFLAGS="$LDFLAGS"
> -  LDFLAGS="$LDFLAGS -Wl,$libgcob_cv_as_needed_option -lm 
> -Wl,$libgcob_cv_no_as_needed_option"
> -  libgcob_cv_have_as_needed=no
> -  AC_LANG_WERROR
> -  AC_LINK_IFELSE([AC_LANG_PROGRAM([])],
> -  [libgcob_cv_have_as_needed=yes],
> -  [libgcob_cv_have_as_needed=no])
> -  LDFLAGS="$save_LDFLAGS"
> -  if test "x$libgcob_cv_have_as_needed" = xno; then
> - libgcob_cv_as_needed_option="--as-needed"
> - libgcob_cv_no_as_needed_option="--no-as-needed"
> +if test "x$USE_IEC_60559" != xyes; then
> +  dnl Check whether -Wl,--as-needed resp. -Wl,-zignore is supported
> +  d

Re: Questions on replacing a structure pointer reference to a call to .ACCESS_WITH_SIZE in C FE

[Qing Zhao]

> On Apr 10, 2025, at 13:43, Martin Uecker  wrote:
> 
> Am Donnerstag, dem 10.04.2025 um 17:05 + schrieb Qing Zhao:
>> Hi, Martin,
>> 
>> Thanks a lot for all your comments and questions, really helpful.
>> 
>> 
> 
> ...
>>> 
>>> An example I could imagine is when you memcpy
>>> the struct.   (but it is also not entirely clear why this
>>> should not be allowed to go beyond the counted_by size
>>> if the underlying storage is larger).  
>>> 
>>> Maybe you could add it when a pointer to an annotated
>>> struct is passed as parameter, but also there it is not
>>> clear to me that we might want to materialize new
>>> accesses to the struct at this point.
>> 
>> This is true too,  and this is even true for the current implementation for 
>> p->array,
>> as I checked with a small example as below:
>> 
>> [opc@qinzhao-aarch64-ol8 counted_by_whole]$ cat t2.c
>> #include 
>> #include 
>> 
>> struct annotated {
>>  size_t count;
>>  char array[];  
>> };
>> 
>> static size_t __attribute__((__noinline__,__noipa__)) size_of (struct 
>> annotated * obj)
>> {
>>  return __builtin_dynamic_object_size (obj->array, 1);
>> }
>> 
>> int main()
>> {
>>  __builtin_printf ("the bdos whole is %ld\n", size_of (0));
>>  return 0;
>> }
>> 
>> In the above example, the parameter to the function “size_of” has pointer 
>> type to “struct annotated”,
>> However, I passed a NULL to “size_of”, is this legal C? Looks like -Wall did 
>> not issue any warning 
>> for it.
> 
> It is legal to pass a NULL pointer.  Here, the issue is
> that the builtin does not evaluate its argument, so it
> is perhaps surprising that you can get a segfault.  If
> the access it outside of the builtin, then this is not
> a problem
> 
> static size_t __attribute__((__noinline__,__noipa__)) size_of (struct 
> annotated * obj)
> {
>  char *p = obj->array;
>  return __builtin_dynamic_object_size (p, 1);
> }

The above acts the same as

static size_t __attribute__((__noinline__,__noipa__)) size_of (struct annotated 
* obj)
{
 return __builtin_dynamic_object_size (obj->array, 1);
}

Only after I changed it as:

static size_t __attribute__((__noinline__,__noipa__)) size_of (struct annotated 
* obj)
{
  char *p = obj->array;
  p[1] = 0;
  return __builtin_dynamic_object_size (p, 1);
}

I got a segmentation fault before evaluating _bdos. 
> 
> because you get the segault anyway when the first line
> is executed.

Yes. That’s right.
> 
> Maybe we need to document that the BDOS builtin requires
> obj->array  to be accessible even though it is not
> evaluated.

Yes, this needs to be at least documented. 
> 
> But I wonder whether there are other cases where
> the object-size path can walk into dead code and create
> accesses in this way. Not sure, but I found this bug though:
> https://godbolt.org/z/ejP918nW7

Thanks, will file bugs and fix them first.

thanks.

Qing
> 
> Martin
> 
>> 
>> 
>> [opc@qinzhao-aarch64-ol8 counted_by_whole]$ sh t
>> /home/opc/Install/latest-d/bin/gcc -O2 -Wall t2.c
>> the bdos whole is -1
>> 0
>> 
>> Then when I added the counted_by attribute for FAM array as:
>> 
>> [opc@qinzhao-aarch64-ol8 counted_by_whole]$ cat t2.c
>> #include 
>> #include 
>> 
>> struct annotated {
>>  size_t count;
>>  char array[] __attribute__ ((counted_by(count)));  
>> };
>> 
>> static size_t __attribute__((__noinline__,__noipa__)) size_of (struct 
>> annotated * obj)
>> {
>>  return __builtin_dynamic_object_size (obj->array, 1);
>> }
>> 
>> int main()
>> {
>>  __builtin_printf ("the bdos whole is %ld\n", size_of (0));
>>  return 0;
>> }
>> [opc@qinzhao-aarch64-ol8 counted_by_whole]$ sh t
>> /home/opc/Install/latest-d/bin/gcc -O2 -Wall t2.c
>> t: line 13: 2944007 Segmentation fault  (core dumped) ./a.out
>> 139
>> 
>> This is because we insert the load from the &p->count for the size.
>> 
>> Qing
>> 
>>> 
>>> An alternative approach could be to just do it when
>>> such a pointer is explicitely passed to the BDOS builtin. 
>>> 
>>> Martin
>>> 
>>> 
 
 Qing
 
 1 #include 
 2 #include 
 3
 4 struct annotated {
 5   size_t count;
 6   char array[] __attribute__((counted_by (count)));
 7 };
 8 
 9 /* compute the minimum # of bytes needed to hold a structure “annotated”,
 10whose # of elements of “array” is COUNT.  */
 11 #define MAX(A, B) (A > B) ? (A) : (B)
 12 #define ALLOC_SIZE_ANNOTATED(COUNT) \
 13   MAX(sizeof (struct annotated), \
 14   offsetof(struct annotated, array[0]) + (COUNT) * sizeof(char))
 15 
 16 /* allocate the memory for the structure with FAM,
 17update “count” with the # of elements “index”.  */
 18 static struct annotated * __attribute__((__noinline__)) alloc_buf (int 
 index)
 19 {
 20   struct annotated *p;
 21   p = (struct annotated *) malloc (ALLOC_SIZE_ANNOTATED(index));
 22   p->count = index;
 23   return p;
 24 }
 25 
 26 static size_t __attribute__((__noinline__)) size_of (struct annotated * 

[PATCH] bitintlower: Fix up handling of nested casts in m_upward_2limbs cases [PR119707]

[Jakub Jelinek]

Hi!

The following testcase is miscompiled I believe starting with
PR112941 r14-6742.  That commit fixed the bitint-55.c testcase.
The m_first initialization for such conversion initializes 2 SSA_NAMEs,
one is PHI result on the loop (m_data[save_data_cnt]) and the other
(m_data[save_data_cnt+1]) is the argument of that PHI from the latch
edge initialized somewhere in the loop.  Both of these are used to
propagate sign extension (i.e. either 0 or all ones limb) from the
iteration with the sign bit of a narrower type to following iterations.
The bitint-55.c testcase was ICEing with invalid SSA forms as it was 
using unconditionally the PHI argument SSA_NAME even in places which
weren't dominated by that.  And the code which was touched is about
handling constant idx, so if e.g. there are nested casts and the
outer one does conditional code based on index comparison with
a particular constant index.
In the following testcase there are 2 nested casts, one from signed
_BitInt(129) to unsigned _BitInt(255) and the outer from unsigned
_BitInt(255) to unsigned _BitInt(256).  The m_upward_2limbs case which
is used for handling mergeable arithmetics (like +-|&^ and casts etc.)
one loop iteration handles 2 limbs, the first half the even ones, the
second half the odd ones.
And for these 2 conversions, the special one for the inner conversion
on x86_64 is with index 2 where the sign bit of _BitInt(129) is present,
while for the outer one index 3 where we need to mask off the most
significant bit.
The r15-6742 change started using m_data[save_data_cnt] for all constant
indexes if it is still inside of the loop (and it is sign extension).
But that doesn't work correctly for the case where the inner conversion
produces the sign extension limb in the loop for an even index and
the outer conversion needs to special case the immediately next conversion,
because in that case using the PHI result will see still 0 there rather
than the updated value from the handling of previous limb.
So the following patch special cases this and uses the other SSA_NAME.

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

Commented IL, trying to lower
  _1 = (unsigned _BitInt(255)) y_4(D);
  _2 = (unsigned _BitInt(256)) _1;
  _3 = _2 + x_5(D);
   = _3;
we were emitting
   [local count: 1073741824]:
  # _8 = PHI <0(2), _9(12)> // This is the limb index
  # _10 = PHI <0(2), _11(12)>   // Sign extension limb from inner cast (0 or 
~0UL)
  # _22 = PHI <0(2), _23(12)>   // Overflow bit from addition of previous limb
  if (_8 <= 2)
goto ; [80.00%]
  else
goto ; [20.00%]

   [local count: 1073741824]:
  if (_8 == 2)
goto ; [20.00%]
  else
goto ; [80.00%]
  
   [local count: 1073741824]:
  _12 = VIEW_CONVERT_EXPR(y)[_8]; // Full limbs in y
  goto ; [100.00%]
  
   [local count: 214748360]:
  _13 = MEM  [(_BitInt(129) *)&y + 16B]; // y[2] which
  _14 = () _13;   // needs to be
  _15 = (unsigned long) _14;// sign extended
  _16 = (signed long) _15;  // to full
  _17 = _16 >> 63;  // limb
  _18 = (unsigned long) _17;
  
   [local count: 1073741824]:
  # _19 = PHI <_12(5), _10(3), _15(6)>  // Limb to add for result of casts
  # _20 = PHI <0(5), _10(3), _18(6)>// Sign extension limb from previous 
limb
  _11 = _20;// PHI _10 argument above
  _21 = VIEW_CONVERT_EXPR(x)[_8];
  _24 = .UADDC (_19, _21, _22);
  _25 = IMAGPART_EXPR <_24>;
  _26 = REALPART_EXPR <_24>;
  VIEW_CONVERT_EXPR()[_8] = _26;
  _27 = _8 + 1;
  if (_27 == 3) // For the outer cast limb 3 is special
goto ; [20.00%]
  else
goto ; [80.00%]

   [local count: 1073741824]:
  if (_27 < 2)
goto ; [80.00%]
  else
goto ; [20.00%]

   [local count: 1073741824]:
  _28 = VIEW_CONVERT_EXPR(y)[_27];// These are used in 
full

   [local count: 1073741824]:
  # _29 = PHI <_28(9), _11(8)>
  goto ; [100.00%]

   [local count: 214748360]:
// And HERE is the actual bug.  Using _10 for idx 3 will mean it is always
// zero there and doesn't contain the _18 value propagated to it.
// It should be
// _30 = () _11;
// Now if the outer conversion had special iteration say 5, we could
// have used _10 fine here, by that time it already propagates through
// the PHI.
  _30 = () _10;
  _31 = (unsigned long) _30;

   [local count: 1073741824]:
  # _32 = PHI <_29(10), _31(11)>
  _33 = VIEW_CONVERT_EXPR(x)[_27];
  _34 = .UADDC (_32, _33, _25);
  _23 = IMAGPART_EXPR <_34>;
  _35 = REALPART_EXPR <_34>;
  VIEW_CONVERT_EXPR()[_27] = _35;
  _9 = _8 + 2;
  if (_9 != 4)
goto ; [0.05%]
  else
goto ; [99.95%]

2025-04-10  Jakub Jelinek  

PR tree-optimization/119707
* gimple-lower-bitint.cc (bitint_large_huge::handle_cast): Only use
m_data[save_data_cnt] instead of m_data[save_data_cnt + 1] if
idx is odd and equal to low + 1.  Remember tree_to_uhwi (idx) in
a tempora

[COMMITTED htdocs] gcc-3.2/changes: fix 'several' typo

[Sam James]

---
Pushed.

 htdocs/gcc-3.2/changes.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/gcc-3.2/changes.html b/htdocs/gcc-3.2/changes.html
index 7b9ea63f..4ab9fdce 100644
--- a/htdocs/gcc-3.2/changes.html
+++ b/htdocs/gcc-3.2/changes.html
@@ -59,7 +59,7 @@
 
 C++
   
-GCC 3.2 fixed serveral differences between the C++ ABI implemented
+GCC 3.2 fixed several differences between the C++ ABI implemented
 in GCC and the multi-vendor standard, but more have been found
 since the release.  3.2.1 adds a new warning, -Wabi,
 to warn about code which is affected by these bugs.

base-commit: 691f8fc1f47538e774af557547a56df0b64948d8
-- 
2.49.0

[committed] d: Fix infinite loop in isAliasThisTuple

[Iain Buclaw]

Hi,

This reverts a change in the upstream D implementation of the compiler,
as the refactoring introduced a regression.

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

Regards,
Iain.

---
gcc/d/ChangeLog:

* dmd/MERGE: Merge upstream dmd 51816cd01d.

Reviewed-on: https://github.com/dlang/dmd/pull/21155
---
 gcc/d/dmd/MERGE   |  2 +-
 gcc/d/dmd/expressionsem.d | 30 +++
 gcc/testsuite/gdc.test/compilable/test21153.d |  8 +
 3 files changed, 26 insertions(+), 14 deletions(-)
 create mode 100644 gcc/testsuite/gdc.test/compilable/test21153.d

diff --git a/gcc/d/dmd/MERGE b/gcc/d/dmd/MERGE
index bd297b612c4..a05a50eefb8 100644
--- a/gcc/d/dmd/MERGE
+++ b/gcc/d/dmd/MERGE
@@ -1,4 +1,4 @@
-ed17b3e95dc3fc3264a4c91843da824f5541f3e1
+51816cd01deee5cc1d7d2c6e1e24788ec655b73e
 
 The first line of this file holds the git revision number of the last
 merge done from the dlang/dmd repository.
diff --git a/gcc/d/dmd/expressionsem.d b/gcc/d/dmd/expressionsem.d
index b0278cbaca1..19111e31baa 100644
--- a/gcc/d/dmd/expressionsem.d
+++ b/gcc/d/dmd/expressionsem.d
@@ -641,21 +641,25 @@ TupleDeclaration isAliasThisTuple(Expression e)
 Type t = e.type.toBasetype();
 while (true)
 {
-Dsymbol s = t.toDsymbol(null);
-if (!s)
-return null;
-auto ad = s.isAggregateDeclaration();
-if (!ad)
-return null;
-s = ad.aliasthis ? ad.aliasthis.sym : null;
-if (s && s.isVarDeclaration())
+if (Dsymbol s = t.toDsymbol(null))
 {
-TupleDeclaration td = 
s.isVarDeclaration().toAlias().isTupleDeclaration();
-if (td && td.isexp)
-return td;
+if (auto ad = s.isAggregateDeclaration())
+{
+s = ad.aliasthis ? ad.aliasthis.sym : null;
+if (s && s.isVarDeclaration())
+{
+TupleDeclaration td = 
s.isVarDeclaration().toAlias().isTupleDeclaration();
+if (td && td.isexp)
+return td;
+}
+if (Type att = t.aliasthisOf())
+{
+t = att;
+continue;
+}
+}
 }
-if (Type att = t.aliasthisOf())
-t = att;
+return null;
 }
 }
 
diff --git a/gcc/testsuite/gdc.test/compilable/test21153.d 
b/gcc/testsuite/gdc.test/compilable/test21153.d
new file mode 100644
index 000..cd92a31240b
--- /dev/null
+++ b/gcc/testsuite/gdc.test/compilable/test21153.d
@@ -0,0 +1,8 @@
+// https://github.com/dlang/dmd/issues/21153
+alias AliasSeq(TList...) = TList;
+class DataClass;
+void reduce(DataClass[] r)
+{
+alias Args = AliasSeq!(DataClass);
+Args result = r[0];
+}
-- 
2.43.0

[PATCH] sanitizer: Store no_sanitize attribute value in uint32 instead of unsigned

[Keith Packard]

A target using 16-bit ints won't have enough bits to hold the whole
flag_sanitize set. Be explicit about using uint32 for the attribute data.

Signed-off-by: Keith Packard 
---
 gcc/c-family/c-attribs.cc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
index 5a0e3d328ba..2a4ae10838a 100644
--- a/gcc/c-family/c-attribs.cc
+++ b/gcc/c-family/c-attribs.cc
@@ -1420,12 +1420,12 @@ add_no_sanitize_value (tree node, unsigned int flags)
   if (flags == old_value)
return;
 
-  TREE_VALUE (attr) = build_int_cst (unsigned_type_node, flags);
+  TREE_VALUE (attr) = build_int_cst (uint32_type_node, flags);
 }
   else
 DECL_ATTRIBUTES (node)
   = tree_cons (get_identifier ("no_sanitize"),
-  build_int_cst (unsigned_type_node, flags),
+  build_int_cst (uint32_type_node, flags),
   DECL_ATTRIBUTES (node));
 }
 
-- 
2.49.0

Re: [PATCH] Improve [-W..] display for -Wformat

[Sam James]

Vishnu Mohandas  writes:

> Hello,

Hi,

> The patch below proposes a possible improvement for the issue mentioned in 
> bug 65445. Although I'm not certain that it
> address all the concerns, it does seem to make it better.>

Unfortunately, I see a few issues here. There needs to be a ChangeLog
entry for the patch, but also the patch itself is both not submitted in
the right format (looks copy/pasted from a pager?) but also appears
incomplete as it just removes lines and nothing else.

See https://gcc.gnu.org/contribute.html#patches.

Please try to resend the patch with git send-email (see
https://git-send-email.io/ for help) or if you must if that fails, try
attach it as a patch as the output of git format-patch.

[COMMITTED] Doc: Discourage the use of -ffloat-store [PR14708]

[Sandra Loosemore]

gcc/ChangeLog
PR middle-end/14708
* doc/invoke.texi (Optimize Options): List -fexcess-precision
before -ffloat-store, moving some background discussion to the
former from the latter.  Recommend using -fexcess-precision=standard
instead of -ffloat-store.
---
 gcc/doc/invoke.texi | 42 +++---
 1 file changed, 23 insertions(+), 19 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index a040d65af0e..05f6ca66fce 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -15318,32 +15318,24 @@ arithmetic.  These options trade off between speed and
 correctness.  All must be specifically enabled.
 
 @table @gcctabopt
-@opindex ffloat-store
-@item -ffloat-store
-Do not store floating-point variables in registers, and inhibit other
-options that might change whether a floating-point value is taken from a
-register or memory.
-
-@cindex floating-point precision
-This option prevents undesirable excess precision on machines such as
-the 68000 where the floating registers (of the 68881) keep more
-precision than a @code{double} is supposed to have.  Similarly for the
-x86 architecture.  For most programs, the excess precision does only
-good, but a few programs rely on the precise definition of IEEE floating
-point.  Use @option{-ffloat-store} for such programs, after modifying
-them to store all pertinent intermediate computations into variables.
-
 @opindex fexcess-precision
 @item -fexcess-precision=@var{style}
-This option allows further control over excess precision on machines
+This option allows control over excess precision on machines
 where floating-point operations occur in a format with more precision or
-range than the IEEE standard and interchange floating-point types.  By
-default, @option{-fexcess-precision=fast} is in effect; this means that
+range than the IEEE standard and interchange floating-point types.
+An example of such a target is x87 floating point on x86 processors,
+which uses an 80-bit representation internally instead of the 64-bit
+IEEE format.  For most programs, the excess precision is harmless,
+but some programs may rely on the
+requirements of the C or C++ language standards for handling IEEE values.
+
+By default, @option{-fexcess-precision=fast} is in effect; this means that
 operations may be carried out in a wider precision than the types specified
 in the source if that would result in faster code, and it is unpredictable
 when rounding to the types specified in the source code takes place.
 When compiling C or C++, if @option{-fexcess-precision=standard} is specified
-then excess precision follows the rules specified in ISO C99 or C++; in 
particular,
+then excess precision follows the rules specified in ISO C99 or C++;
+in particular,
 both casts and assignments cause values to be rounded to their
 semantic types (whereas @option{-ffloat-store} only affects
 assignments).  This option is enabled by default for C or C++ if a strict
@@ -15361,6 +15353,18 @@ or @option{-mfpmath=sse+387} is specified; in the 
former case, IEEE
 semantics apply without excess precision, and in the latter, rounding
 is unpredictable.
 
+@opindex ffloat-store
+@item -ffloat-store
+Do not store floating-point variables in registers, and inhibit other
+options that might change whether a floating-point value is taken from a
+register or memory.  This option has generally been subsumed by
+@option{-fexcess-precision=standard}, which is more general.  If you do use
+@option{-ffloat-store}, you may need to modify your program to explicitly
+store intermediate computations in temporary variables since
+@option{-ffloat-store} handles rounding to IEEE format
+only on assignments and not casts as @option{-fexcess-precision=standard}
+does.
+
 @opindex ffast-math
 @item -ffast-math
 Sets the options @option{-fno-math-errno}, 
@option{-funsafe-math-optimizations},
-- 
2.34.1

Re: [PATCH] realloc-1.c: accept long long in warning for llp64

[Jonathan Yong]

On 4/9/25 2:27 PM, Jonathan Yong wrote:

Attached patch OK for master branch?
Will push soon if there are no objections.


Pushed to master branch.

Re: [PATCH] bf-ms-attrib.c: Fix expected struct size

[Jonathan Yong]

On 4/9/25 2:35 PM, Jonathan Yong wrote:
Attached patch OK for master branch? Gcc produced struct sizes match 
those of MSVC when __ms_struct__ is used, both producing a layout size 
of 12.


Will push soon if there are no objections.


Pushed to master branch.

[PATCH v2] riscv: Fix incorrect gnu property alignment on rv32

[Jesse Huang]

Codegen is incorrectly emitting a ".p2align 3" that coerces the
alignment of the .note.gnu.property section from 4 to 8 on rv32.

2025-04-11  Jesse Huang  

gcc/ChangeLog

* config/riscv/riscv.cc (riscv_file_end): Fix .p2align value.

gcc/testsuite/ChangeLog

* gcc.target/riscv/gnu-property-align-rv32.c: New file.
* gcc.target/riscv/gnu-property-align-rv64.c: New file.
---
 gcc/config/riscv/riscv.cc| 2 +-
 gcc/testsuite/gcc.target/riscv/gnu-property-align-rv32.c | 7 +++
 gcc/testsuite/gcc.target/riscv/gnu-property-align-rv64.c | 7 +++
 3 files changed, 15 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/gnu-property-align-rv32.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/gnu-property-align-rv64.c

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 38f3ae7cd84..d3656a7a430 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -10382,7 +10382,7 @@ riscv_file_end ()
   fprintf (asm_out_file, "1:\n");
 
   /* pr_type.  */
-  fprintf (asm_out_file, "\t.p2align\t3\n");
+  fprintf (asm_out_file, "\t.p2align\t%u\n", p2align);
   fprintf (asm_out_file, "2:\n");
   fprintf (asm_out_file, "\t.long\t0xc000\n");
   /* pr_datasz.  */
diff --git a/gcc/testsuite/gcc.target/riscv/gnu-property-align-rv32.c 
b/gcc/testsuite/gcc.target/riscv/gnu-property-align-rv32.c
new file mode 100644
index 000..4f48cff33da
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/gnu-property-align-rv32.c
@@ -0,0 +1,7 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv32g_zicfiss -fcf-protection=return -mabi=ilp32d " } 
*/
+
+void foo() {}
+
+/* { dg-final { scan-assembler-times ".p2align\t2" 3 } } */
+/* { dg-final { scan-assembler-not ".p2align\t3" } } */
diff --git a/gcc/testsuite/gcc.target/riscv/gnu-property-align-rv64.c 
b/gcc/testsuite/gcc.target/riscv/gnu-property-align-rv64.c
new file mode 100644
index 000..1bfd1271826
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/gnu-property-align-rv64.c
@@ -0,0 +1,7 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64g_zicfiss -fcf-protection=return -mabi=lp64d " } */
+
+void foo() {}
+
+/* { dg-final { scan-assembler-times ".p2align\t3" 3 } } */
+/* { dg-final { scan-assembler-not ".p2align\t2" } } */
-- 
2.39.3

[COMMITTED 04/32] gccrs: Fix ICE when resolving lifetimes without name

[arthur . cohen]

From: Philip Herron 

We dont need to assert here the lifetime code already supports this case.

Fixes Rust-GCC#3657

gcc/rust/ChangeLog:

* typecheck/rust-hir-type-check-base.cc: remove assertion

gcc/testsuite/ChangeLog:

* rust/compile/issue-3657.rs: New test.

Signed-off-by: Philip Herron 
---
 gcc/rust/typecheck/rust-hir-type-check-base.cc | 2 --
 gcc/testsuite/rust/compile/issue-3657.rs   | 8 
 2 files changed, 8 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/rust/compile/issue-3657.rs

diff --git a/gcc/rust/typecheck/rust-hir-type-check-base.cc 
b/gcc/rust/typecheck/rust-hir-type-check-base.cc
index 34a726cc665..d3d68821734 100644
--- a/gcc/rust/typecheck/rust-hir-type-check-base.cc
+++ b/gcc/rust/typecheck/rust-hir-type-check-base.cc
@@ -397,8 +397,6 @@ TypeCheckBase::resolve_generic_params (
auto lifetime_param
  = static_cast (*generic_param);
auto lifetime = lifetime_param.get_lifetime ();
-   rust_assert (lifetime.get_lifetime_type ()
-== AST::Lifetime::LifetimeType::NAMED);
context->get_lifetime_resolver ().insert_mapping (
  context->intern_lifetime (lifetime));
  }
diff --git a/gcc/testsuite/rust/compile/issue-3657.rs 
b/gcc/testsuite/rust/compile/issue-3657.rs
new file mode 100644
index 000..978f3ce336f
--- /dev/null
+++ b/gcc/testsuite/rust/compile/issue-3657.rs
@@ -0,0 +1,8 @@
+struct Foo<'_>(&'_ u8);
+
+impl Foo<'a> {
+// { dg-error "unresolved lifetime" "" { target *-*-* } .-1 }
+fn x() {}
+}
+
+fn x() {}
-- 
2.49.0

[COMMITTED] Doc: Add missing documentation for -ftree-cselim [PR87909]

[Sandra Loosemore]

gcc/ChangeLog
PR tree-optimization/87909
* common.opt.urls: Regenerate.
* doc/invoke.texi (Option Summary): Add -ftree-cselim.
(Optimize Options): Likewise.
---
 gcc/common.opt.urls |  3 +++
 gcc/doc/invoke.texi | 10 --
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/gcc/common.opt.urls b/gcc/common.opt.urls
index 860ebd01ace..a4b14f5241f 100644
--- a/gcc/common.opt.urls
+++ b/gcc/common.opt.urls
@@ -1459,6 +1459,9 @@ 
UrlSuffix(gcc/Optimize-Options.html#index-ftree-coalesce-vars)
 ftree-copy-prop
 UrlSuffix(gcc/Optimize-Options.html#index-ftree-copy-prop)
 
+ftree-cselim
+UrlSuffix(gcc/Optimize-Options.html#index-ftree-cselim)
+
 ftree-switch-conversion
 UrlSuffix(gcc/Optimize-Options.html#index-ftree-switch-conversion)
 
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 05f6ca66fce..ffde9df85fd 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -642,8 +642,8 @@ Objective-C and Objective-C++ Dialects}.
 -fsplit-wide-types  -fsplit-wide-types-early  -fssa-backprop  -fssa-phiopt
 -fstdarg-opt  -fstore-merging  -fstrict-aliasing -fipa-strict-aliasing
 -fthread-jumps  -ftracer  -ftree-bit-ccp
--ftree-builtin-call-dce  -ftree-ccp  -ftree-ch
--ftree-coalesce-vars  -ftree-copy-prop  -ftree-dce  -ftree-dominator-opts
+-ftree-builtin-call-dce  -ftree-ccp  -ftree-ch  -ftree-coalesce-vars
+-ftree-copy-prop  -ftree-cselim  -ftree-dce  -ftree-dominator-opts
 -ftree-dse  -ftree-forwprop  -ftree-fre  -fcode-hoisting
 -ftree-loop-if-convert  -ftree-loop-im
 -ftree-phiprop  -ftree-loop-distribution  -ftree-loop-distribute-patterns
@@ -14072,6 +14072,12 @@ in this pass can
 be limited using @option{max-tail-merge-comparisons} parameter and
 @option{max-tail-merge-iterations} parameter.
 
+@opindex ftree-cselim
+@item -ftree-cselim
+Perform conditional store elimination on trees.  This flag is enabled by
+default at @option{-O1} and higher on targets that have conditional
+move instructions.
+
 @opindex ftree-dce
 @item -ftree-dce
 Perform dead code elimination (DCE) on trees.  This flag is enabled by
-- 
2.34.1

Re: [PATCH] Add std::deque shrink_to_fit test

[Tomasz Kaminski]

On Thu, Apr 10, 2025 at 10:47 PM Jonathan Wakely  wrote:

> On 10/04/25 22:36 +0200, François Dumont wrote:
> >After running the test with -fno-exceptions option we rather need this
> >patch.
> >
> >Ok to commit ?
> >
> >François
> >
> >
> >On 10/04/2025 21:08, François Dumont wrote:
> >>Hi
> >>
> >>No problem detected now that we really test std::deque
> >>shrink_to_fit implementation.
> >>
> >>libstdc++: Add std::deque<>::shrink_to_fit test
> >>
> >>The existing test is currently testing std::vector. Make it test
> >>std::deque.
> >>
> >>libstdc++-v3/ChangeLog:
> >>
> >>*
> >>testsuite/23_containers/deque/capacity/shrink_to_fit.cc: Adapt test
> >>to check std::deque shrink_to_fit method.
> >>
> >>Tested under Linux x64.
> >>
> >>Ok to commit ?
> >>
> >>François
>
> >diff --git
> a/libstdc++-v3/testsuite/23_containers/deque/capacity/shrink_to_fit.cc
> b/libstdc++-v3/testsuite/23_containers/deque/capacity/shrink_to_fit.cc
> >index 7cb67079214..9c8b3a926e8 100644
> >--- a/libstdc++-v3/testsuite/23_containers/deque/capacity/shrink_to_fit.cc
> >+++ b/libstdc++-v3/testsuite/23_containers/deque/capacity/shrink_to_fit.cc
> >@@ -1,4 +1,5 @@
> > // { dg-do run { target c++11 } }
> >+// { dg-add-options no_pch }
>
> Tests using replacement_memory_operators.h need:
>
> // { dg-require-effective-target std_allocator_new }
> // { dg-xfail-run-if "AIX operator new" { powerpc-ibm-aix* } }
>
> See e.g. 23_containers/unordered_set/96088.cc
>
> >
> > // 2010-01-08  Paolo Carlini  
> >
> >@@ -19,18 +20,39 @@
> > // with this library; see the file COPYING3.  If not see
> > // .
> >
> >-#include 
> >+#define _GLIBCXX_DEQUE_BUF_SIZE sizeof(int) * 3
>
> Couldn't the test just create more elements, instead of modifying the
> internals? We should test it using the default parameters, no?
>
In from_range test I have used a class that contains some padding,
to be able to fill the deque buffer, while still test with few elements,

struct EightInBuf

{
  EightInBuf(int x) : elems{x}
  { }

 private:
   int elems[512 / (sizeof(int) * 8)];

  friend constexpr bool operator==(EightInBuf const& lhs, int rhs)
  { return lhs.elems[0] == rhs; }
 };





> >+#include 
> > #include 
> >+#include 
> >
> > // libstdc++/42573
> > void test01()
> > {
> >-  std::vector d(100);
> >+  __gnu_test::counter::reset();
> >+
> >+  std::deque d;
> >   d.push_back(1);
> >   d.push_back(1);
> >-  // VERIFY( d.size() < d.capacity() );
> >+  d.push_back(1);
> >+  d.pop_front();
> >+  VERIFY( d.size() == 2 );
> >+  // 1 node array allocation + 2 node allocation = 3.
> >+  VERIFY( __gnu_test::counter::count() == 3 );
> >+  VERIFY( __gnu_test::counter::get()._M_increments == 3 );
> >+
> >   d.shrink_to_fit();
> >-  // VERIFY( d.size() == d.capacity() );
> >+  VERIFY( d.size() == 2 );
> >+#if __cpp_exceptions
> >+  // 1 node array allocation + 1 node allocation = 2.
> >+  const int expected_count = 2;
> >+  const int expected_increments = 2;
> >+#else
>
> It would be useful to add a comment here saying that shrink_to_fit()
> is a no-op for -fno-exceptions because we choose not to reallocate.
>
> >+  const int expected_count = 3;
> >+  const int expected_increments = 0;
> >+#endif
> >+  VERIFY( __gnu_test::counter::count() == expected_count );
> >+  VERIFY( __gnu_test::counter::get()._M_increments == 3 +
> expected_increments );
> > }
> >
> > int main()
> >diff --git a/libstdc++-v3/testsuite/util/replacement_memory_operators.h
> b/libstdc++-v3/testsuite/util/replacement_memory_operators.h
> >index 2516cd24ae1..69afa77754d 100644
> >--- a/libstdc++-v3/testsuite/util/replacement_memory_operators.h
> >+++ b/libstdc++-v3/testsuite/util/replacement_memory_operators.h
> >@@ -36,8 +36,12 @@ namespace __gnu_test
> >
> > ~counter() THROW (counter_error)
> > {
> >+#if __cpp_exceptions
> >   if (_M_throw && _M_count != 0)
> >   throw counter_error();
> >+#else
> >+  VERIFY( !_M_throw || _M_count == 0 );
> >+#endif
> > }
> >
> > static void
> >@@ -133,8 +137,12 @@ void* operator new(std::size_t size)
> THROW(std::bad_alloc)
> > {
> >   std::printf("operator new is called \n");
> >   void* p = std::malloc(size);
> >+#if __cpp_exceptions
> >   if (!p)
> > throw std::bad_alloc();
> >+#else
> >+  VERIFY( p );
> >+#endif
> >   __gnu_test::counter::increment();
> >   return p;
> > }
>
>

Re: [PATCH] libstdc++: Add P1206R7 from_range members to std::string [PR111055]

[Tomasz Kaminski]

On Fri, Apr 11, 2025 at 1:32 AM Jonathan Wakely  wrote:

> This is the last piece of P1206R7, adding new members to
> std::basic_string.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/111055
> * include/bits/basic_string.h (_S_copy_range): New function.
> (basic_string(from_range_t, R%%, const Alloc&)): New
> constructor.
> (append_range, assign_range, insert_range, replace_with_range):
> New functions.
> * include/bits/cow_string.h: Likewise.
> * testsuite/21_strings/basic_string/cons/from_range.cc: New
> test.
> *
> testsuite/21_strings/basic_string/modifiers/append/append_range.cc:
> New test.
> *
> testsuite/21_strings/basic_string/modifiers/assign/assign_range.cc:
> New test.
> *
> testsuite/21_strings/basic_string/modifiers/insert/insert_range.cc:
> New test.
> *
> testsuite/21_strings/basic_string/modifiers/replace/replace_with_range.cc:
> New test.
>
> Co-authored-by: Tomasz Kamiński 
> ---
>
> Thanks to Tomasz for the tests and fixes to this.
>
LGTM for reasons that may be obvious.

>
> Tested x86_64-linux.
>
>  libstdc++-v3/include/bits/basic_string.h  | 182 ++
>  libstdc++-v3/include/bits/cow_string.h| 115 +++
>  .../basic_string/cons/from_range.cc   | 124 
>  .../modifiers/append/append_range.cc  | 125 
>  .../modifiers/assign/assign_range.cc  | 116 +++
>  .../modifiers/insert/insert_range.cc  | 130 +
>  .../modifiers/replace/replace_with_range.cc   | 133 +
>  7 files changed, 925 insertions(+)
>  create mode 100644
> libstdc++-v3/testsuite/21_strings/basic_string/cons/from_range.cc
>  create mode 100644
> libstdc++-v3/testsuite/21_strings/basic_string/modifiers/append/append_range.cc
>  create mode 100644
> libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/assign_range.cc
>  create mode 100644
> libstdc++-v3/testsuite/21_strings/basic_string/modifiers/insert/insert_range.cc
>  create mode 100644
> libstdc++-v3/testsuite/21_strings/basic_string/modifiers/replace/replace_with_range.cc
>
> diff --git a/libstdc++-v3/include/bits/basic_string.h
> b/libstdc++-v3/include/bits/basic_string.h
> index 067c7915c76..1ca8f5fb749 100644
> --- a/libstdc++-v3/include/bits/basic_string.h
> +++ b/libstdc++-v3/include/bits/basic_string.h
> @@ -51,6 +51,11 @@
>  # include 
>  #endif
>
> +#if __glibcxx_ranges_to_container // C++ >= 23
> +# include   // ranges::copy
> +# include   // ranges::subrange
> +#endif
> +
>  #if __cplusplus > 202302L
>  # include 
>  #endif
> @@ -516,6 +521,21 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
>{ _S_copy(__p, __k1, __k2 - __k1); }
>  #endif
>
> +#if __glibcxx_ranges_to_container // C++ >= 23
> +  // pre: __n == ranges::distance(__rg). __p+[0,__n) is a valid range.
> +  template
> +   static constexpr void
> +   _S_copy_range(pointer __p, _Rg&& __rg, size_type __n)
> +   {
> + if constexpr (ranges::contiguous_range<_Rg>
> + && is_same_v, _CharT>)
> +   _S_copy(__p, ranges::data(std::forward<_Rg>(__rg)), __n);
> + else
> +   for (auto&& __e : __rg)
> + traits_type::assign(*__p++,
> std::forward(__e));
> +   }
> +#endif
> +
>_GLIBCXX20_CONSTEXPR
>static int
>_S_compare(size_type __n1, size_type __n2) _GLIBCXX_NOEXCEPT
> @@ -732,6 +752,33 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
> __str._M_set_length(0);
>}
>
> +#if __glibcxx_ranges_to_container // C++ >= 23
> +  /**
> +   * @brief Construct a string from a range.
> +   * @since C++23
> +   */
> +  template<__detail::__container_compatible_range<_CharT> _Rg>
> +   constexpr
> +   basic_string(from_range_t, _Rg&& __rg, const _Alloc& __a =
> _Alloc())
> +   : basic_string(__a)
> +   {
> + if constexpr (ranges::forward_range<_Rg> ||
> ranges::sized_range<_Rg>)
> +   {
> + const auto __n =
> static_cast(ranges::distance(__rg));
> + reserve(__n);
> + _S_copy_range(_M_data(), std::forward<_Rg>(__rg), __n);
> + _M_set_length(__n);
> +   }
> + else
> +   {
> + auto __first = ranges::begin(__rg);
> + const auto __last = ranges::end(__rg);
> + for (; __first != __last; ++__first)
> +   push_back(*__first);
> +   }
> +   }
> +#endif
> +
>/**
> *  @brief  Construct string from an initializer %list.
> *  @param  __l  std::initializer_list of characters.
> @@ -1541,6 +1588,58 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
>append(size_type __n, _CharT __c)
>{ return _M_replace_aux(this->size(), size_type(0), __n, __c); }
>
> +#if __glibcxx_ranges_to_container // C++ >= 23
> +  /**
> +   * @brief Append a range to the string.
> + 

Re: [PATCH] aarch64: Fix CFA offsets in non-initial stack probes [PR119610]

[Richard Biener]

On Thu, Apr 10, 2025 at 10:10 PM Richard Sandiford
 wrote:
>
> PR119610 is about incorrect CFI output for a stack probe when that
> probe is not the initial allocation.  The main aarch64 stack probe
> function, aarch64_allocate_and_probe_stack_space, implicitly assumed
> that the incoming stack pointer pointed to the top of the frame,
> and thus held the CFA.
>
> aarch64_save_callee_saves and aarch64_restore_callee_saves use a
> parameter called bytes_below_sp to track how far the stack pointer
> is above the base of the static frame.  This patch does the same
> thing for aarch64_allocate_and_probe_stack_space.
>
> Also, I noticed that the SVE path was attaching the first CFA note
> to the wrong instruction: it was attaching the note to the calculation
> of the stack size, rather than to the r11<-sp copy.
>
> Bootstrapped & regression-tested on aarch64-linux-gnu.  I'll push on
> Monday if there are no comments before then.  I'd appreciate a second
> pair of eyes though, since this is a sensitive area.

Do you happen to know if the backports to older branches you provided for
the change that triggered this issue (in particular to GCC 7) are also affected?
The testcase from the PR does not fail in the reported way for me, but I guess
that very much depends on "details".

Thanks,
Richard.

> Richard
>
> gcc/
> PR target/119160
> * config/aarch64/aarch64.cc (aarch64_allocate_and_probe_stack_space):
> Add a bytes_below_sp parameter and use it to calculate the CFA
> offsets.  Attach the first SVE CFA note to the move into the
> associated temporary register.
> (aarch64_allocate_and_probe_stack_space): Update calls accordingly.
> Start out with bytes_per_sp set to the frame size and decrement
> it after each allocation.
>
> gcc/testsuite/
> PR target/119160
> * g++.dg/torture/pr119610.C: New test.
> * g++.target/aarch64/sve/pr119610-sve.C: Likewise.
> ---
>  gcc/config/aarch64/aarch64.cc | 66 +++
>  gcc/testsuite/g++.dg/torture/pr119610.C   | 18 +
>  .../g++.target/aarch64/sve/pr119610-sve.C | 20 ++
>  3 files changed, 78 insertions(+), 26 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/torture/pr119610.C
>  create mode 100644 gcc/testsuite/g++.target/aarch64/sve/pr119610-sve.C
>
> diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
> index 4e801146c60..1e415c1e78f 100644
> --- a/gcc/config/aarch64/aarch64.cc
> +++ b/gcc/config/aarch64/aarch64.cc
> @@ -9417,13 +9417,16 @@ aarch64_emit_stack_tie (rtx reg)
>  }
>
>  /* Allocate POLY_SIZE bytes of stack space using TEMP1 and TEMP2 as scratch
> -   registers.  If POLY_SIZE is not large enough to require a probe this 
> function
> -   will only adjust the stack.  When allocating the stack space
> -   FRAME_RELATED_P is then used to indicate if the allocation is frame 
> related.
> -   FINAL_ADJUSTMENT_P indicates whether we are allocating the area below
> -   the saved registers.  If we are then we ensure that any allocation
> -   larger than the ABI defined buffer needs a probe so that the
> -   invariant of having a 1KB buffer is maintained.
> +   registers, given that the stack pointer is currently BYTES_BELOW_SP bytes
> +   above the bottom of the static frame.
> +
> +   If POLY_SIZE is not large enough to require a probe this function will 
> only
> +   adjust the stack.  When allocating the stack space FRAME_RELATED_P is then
> +   used to indicate if the allocation is frame related.  FINAL_ADJUSTMENT_P
> +   indicates whether we are allocating the area below the saved registers.
> +   If we are then we ensure that any allocation larger than the ABI defined
> +   buffer needs a probe so that the invariant of having a 1KB buffer is
> +   maintained.
>
> We emit barriers after each stack adjustment to prevent optimizations from
> breaking the invariant that we never drop the stack more than a page.  
> This
> @@ -9440,6 +9443,7 @@ aarch64_emit_stack_tie (rtx reg)
>  static void
>  aarch64_allocate_and_probe_stack_space (rtx temp1, rtx temp2,
> poly_int64 poly_size,
> +   poly_int64 bytes_below_sp,
> aarch64_isa_mode force_isa_mode,
> bool frame_related_p,
> bool final_adjustment_p)
> @@ -9503,8 +9507,8 @@ aarch64_allocate_and_probe_stack_space (rtx temp1, rtx 
> temp2,
>   poly_size, temp1, temp2, force_isa_mode,
>   false, true);
>
> -  rtx_insn *insn = get_last_insn ();
> -
> +  auto initial_cfa_offset = frame.frame_size - bytes_below_sp;
> +  auto final_cfa_offset = initial_cfa_offset + poly_size;
>if (frame_related_p)
> {
>   /* This is done to provide unwinding information for the stack
> @@ -9514,28 +9518,31 @@ 

[PATCH] Improve [-W..] display for -Wformat

[Vishnu Mohandas]

Hello,
The patch below proposes a possible improvement for the issue mentioned in
bug 65445. Although I'm not certain that it address all the concerns, it
does seem to make it better.

Bootstrapped on x86_64 Linux.

Thanks,
Vishnu

   1   │ diff --git a/gcc/opt-functions.awk b/gcc/opt-functions.awk
   2   │ index 9001a049ed9..96ba21347ef 100644
   3   │ --- a/gcc/opt-functions.awk
   4   │ +++ b/gcc/opt-functions.awk
   5   │ @@ -26,18 +26,6 @@ BEGIN {
   6   │ alnum = lower "" upper "" digit
   7   │  }
   8   │
   9   │ -#Define an array of options and their corresponding enabling
options
  10   │ -BEGIN {
  11   │ -   opts_enable_table["Wformat"] = "Wformat-contains-nul
Wformat-truncation"
  12   │ -}
  13   │ -#Return a INT for a warning option
  14   │ -function get_enabling_options(opt)
  15   │ -{
  16   │ -   if (opt in opts_enable_table)
  17   │ -   return opts_enable_table[opt]
  18   │ -   else
  19   │ -   return ""
  20   │ -
  21   │  # Return nonzero if FLAGS contains a flag matching REGEX.
  22   │  function flag_set_p(regex, flags)
  23   │  {

[PATCH] dwarf2out: Decrease dw_loc_descr_node and dw_attr_struct struct sizes [PR119711]

[Jakub Jelinek]

Hi!

As noted by Richi on a large testcase, there are unnecessary paddings
in some heavily used dwarf2out.{h,cc} structures on 64-bit hosts.

struct dw_val_node {
enum dw_val_class  val_class;/* 0 4 */

/* XXX 4 bytes hole, try to pack */

struct addr_table_entry *  val_entry;/* 8 8 */
union dw_val_struct_union  v;/*1616 */

/* size: 32, cachelines: 1, members: 3 */
/* sum members: 28, holes: 1, sum holes: 4 */
/* last cacheline: 32 bytes */
};
struct dw_loc_descr_node {
dw_loc_descr_ref   dw_loc_next;  /* 0 8 */
enum dwarf_location_atom   dw_loc_opc:8; /* 8: 0  4 */
unsigned int   dtprel:1; /* 8: 8  4 */
unsigned int   frame_offset_rel:1;   /* 8: 9  4 */

/* XXX 22 bits hole, try to pack */

intdw_loc_addr;  /*12 4 */
struct dw_val_node dw_loc_oprnd1;/*1632 */
struct dw_val_node dw_loc_oprnd2;/*4832 */

/* size: 80, cachelines: 2, members: 7 */
/* sum members: 76 */
/* sum bitfield members: 10 bits, bit holes: 1, sum bit holes: 22 bits 
*/
/* last cacheline: 16 bytes */
};
struct dw_attr_struct {
enum dwarf_attribute   dw_attr;  /* 0 4 */

/* XXX 4 bytes hole, try to pack */

struct dw_val_node dw_attr_val;  /* 832 */

/* size: 40, cachelines: 1, members: 2 */
/* sum members: 36, holes: 1, sum holes: 4 */
/* last cacheline: 40 bytes */
};

The following patch is an (not very clean admittedly) attempt to decrease
size of dw_loc_descr_node from 80 bytes to 72 and (more importantly)
dw_attr_struct from 40 bytes to 32 by moving the dw_attr member from
dw_attr_struct into dw_attr_val's padding and similarly move
dw_loc_opc/dtprel/frame_offset_rel members into dw_loc_oprnd1 padding
and dw_loc_addr into dw_loc_oprnd2 padding.
All we need to ensure is that nothing tries to copy whole dw_val_node
structs unless it is copied as part of whole dw_loc_descr_node or
dw_attr_struct copy.

To verify that wasn't the case, I've temporarily added a deleted copy ctor
to dw_val_node and then looked at all the errors/warnings caused by that,
and those were just from memcpy/memmove or structure assignments of whole
dw_loc_descr_node/dw_attr_struct.

Bootstrapped/regtested on x86_64-linux and i686-linux.
Ok for stage1?

2025-04-10  Jakub Jelinek  

PR debug/119711
* dwarf2out.h (struct dw_val_node): Add u member.
(struct dw_loc_descr_node): Remove dw_loc_opc, dtprel,
frame_offset_rel and dw_loc_addr members.
(dw_loc_opc, dw_loc_dtprel, dw_loc_frame_offset_rel, dw_loc_addr):
Define.
(struct dw_attr_struct): Remove dw_attr member.
(dw_attr): Define.
* dwarf2out.cc (loc_descr_equal_p_1): Use dw_loc_dtprel instead of
dtprel.
(output_loc_operands, new_addr_loc_descr, loc_checksum,
loc_checksum_ordered): Likewise.
(resolve_args_picking_1): Use dw_loc_frame_offset_rel instead of
frame_offset_rel.
(loc_list_from_tree_1): Likewise.
(resolve_addr_in_expr): Use dw_loc_dtprel instead of dtprel.
(copy_deref_exprloc): Copy val_class, val_entry and v members
instead of whole dw_loc_oprnd1 and dw_loc_oprnd2.
(optimize_string_length): Copy val_class, val_entry and v members
instead of whole dw_attr_val.
(hash_loc_operands): Use dw_loc_dtprel instead of dtprel.
(compare_loc_operands, compare_locs): Likewise.

--- gcc/dwarf2out.h.jj  2025-04-08 14:08:51.82269 +0200
+++ gcc/dwarf2out.h 2025-04-10 19:07:32.535018798 +0200
@@ -276,6 +276,25 @@ typedef struct GTY(()) dw_loc_list_struc
 
 struct GTY(()) dw_val_node {
   enum dw_val_class val_class;
+  /* On 64-bit host, there are 4 bytes of padding between val_class
+ and val_entry.  Reuse the padding for other content of
+ dw_loc_descr_node and dw_attr_struct.  */
+  union dw_val_node_parent
+{
+  struct dw_val_loc_descr_node
+   {
+ ENUM_BITFIELD (dwarf_location_atom) dw_loc_opc_v : 8;
+ /* Used to distinguish DW_OP_addr with a direct symbol relocation
+from DW_OP_addr with a dtp-relative symbol relocation.  */
+ unsigned int dw_loc_dtprel_v : 1;
+ /* For DW_OP_pick, DW_OP_dup and DW_OP_over operations: true iff.
+it targets a DWARF prodecure argument.  In this case, it needs to 
be
+relocated according to the current frame offset.  */
+ unsigned int dw_loc_frame_offset_rel_v : 1;
+   } u1;
+  int u2;
+  enum dwarf_attribute u3;
+} GTY((skip)) u;
   struct addr_table_entry * GTY(()) val_entry;
   union dw_val_struct_union
 

[COMMITTED 21/32] gccrs: Remove unused error constructor and getter

[arthur . cohen]

From: Pierre-Emmanuel Patry 

These constructor for eroneous state are not in use anymore since we
replaced this error state with an optional in the parent nodes.

gcc/rust/ChangeLog:

* ast/rust-expr.h: Remove error getter and constructor.

Signed-off-by: Pierre-Emmanuel Patry 
---
 gcc/rust/ast/rust-expr.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/gcc/rust/ast/rust-expr.h b/gcc/rust/ast/rust-expr.h
index 3ce78c643c7..e6cfa2709f9 100644
--- a/gcc/rust/ast/rust-expr.h
+++ b/gcc/rust/ast/rust-expr.h
@@ -31,11 +31,6 @@ public:
   {}
 
   // Returns whether the LoopLabel is in an error state.
-  bool is_error () const { return label.is_error (); }
-
-  // Creates an error state LoopLabel.
-  static LoopLabel error () { return LoopLabel (Lifetime::error ()); }
-
   location_t get_locus () const { return locus; }
 
   Lifetime &get_lifetime () { return label; }
-- 
2.49.0

Re: [PATCH 2/2] libgcobol: Allow libgcobol to use libquadmath [PR119244].

[Rainer Orth]

Jakub Jelinek  writes:

> On Sun, Apr 06, 2025 at 09:02:07AM +0100, Iain Sandoe wrote:
>>  
>> +
>> +#if !defined (HAVE_STRTOF128)
>> +# if USE_QUADMATH
>> +#  define strtof128 strtoflt128
>> +# else
>> +#  error "no available string to float 128"
>> +# endif
>> +#endif
>
> If there is no strtof128 and not using libquadmath, there is always
> the possibility to use strtold if long double is IEEE quad.
> But that can be fixed incrementally.
>
> As for strfromf128, there is always the possibility to use snprintf
> with %.36LE format specifier if long double is IEEE quad.

That's what's needed on Solaris/SPARC which has _Float128, 128-bit long
double, but no __float128 (yet, patch WIP).

There's one remaing issue in that case:

/vol/gcc/src/hg/master/cobol/libgcobol/intrinsic.cc:999:5: error: unsupported 
non-standard suffix on floating constant

This needs

diff --git a/libgcobol/intrinsic.cc b/libgcobol/intrinsic.cc
--- a/libgcobol/intrinsic.cc
+++ b/libgcobol/intrinsic.cc
@@ -67,7 +67,7 @@
 
 #define JD_OF_1601_01_02 2305812.5
 
-#define WEIRD_TRANSCENDENT_RETURN_VALUE (0.0Q)
+#define WEIRD_TRANSCENDENT_RETURN_VALUE GCOB_FP128_LITERAL (0.0)
 #define NO_RDIGITS (0)
 
 struct cobol_tm

I guess it would be better to move that strtof128 and strfromf128
handling to libgcobol-fp.h to avoid duplication.

Rainer

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