[COMMITTED] MAINTAINERS: Add myself to write after approval

[Kishan Parmar]

2025-05-22  Kishan Parmar  

* MAINTAINERS: Add myself to write after approval.
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8993d176c22..ac7e4de112e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -717,6 +717,7 @@ Maxim Ostapenko chefmax 

 Jeevitha Palanisamy jeevitha
 Patrick Palka   ppalka  
 Seongbae Park   spark   
+Kishan Parmar   kishan  
 Srinath Parvathanenisripar01
 Devang Pateldpatel  
 Andris Pavenis  andris  
-- 
2.43.5

Re: [PATCH] c++: Take downgraded errors into account in seen_error [PR118388]

[Jason Merrill]

On 5/9/25 11:37 AM, Simon Martin wrote:

Several gcc_assert through the C++ front-end involve seen_error (), that
does not take into account errors that were turned into warnings due to
-fpermissive or -Wtemplate-body.

Running the full C++ testsuite when forcing the use of -fpermissive
leads to ICEs for 6 tests (see list in ticket); one could consider those
as reject-valid cases.

This patch keeps track of whether we tried to emit an error (whether it
was eventually output as such or not) and uses this in seen_error.


Why isn't the current erroneous_templates code sufficient?  At a glance, 
it seems like the problem might be get_current_template returning the 
lambda, which never gets passed to maybe_diagnose_erroneous_template.


The merge_exception_specifiers change is OK.


Successfully tested on x86_64-pc-linux-gnu.

PR c++/118388

gcc/cp/ChangeLog:

* error.cc (seen_error_raw): New counter to keep track of errors
including those downgraded to warnings.
(cp_seen_error): Take downgraded errors into account.
* typeck2.cc (merge_exception_specifiers): Use seen_error
instead of errorcount.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/lambda/lambda-ice5-fpermissive.C: New test.
* g++.dg/cpp0x/noexcept128-fpermissive.C: New test.

---
  gcc/cp/error.cc   | 54 +--
  gcc/cp/typeck2.cc |  2 +-
  .../cpp0x/lambda/lambda-ice5-fpermissive.C| 14 +
  .../g++.dg/cpp0x/noexcept128-fpermissive.C| 21 
  4 files changed, 63 insertions(+), 28 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice5-fpermissive.C
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept128-fpermissive.C

diff --git a/gcc/cp/error.cc b/gcc/cp/error.cc
index 75bf7dcef62..78ecafb0e02 100644
--- a/gcc/cp/error.cc
+++ b/gcc/cp/error.cc
@@ -215,6 +215,11 @@ get_current_template ()
  
  erroneous_templates_t *erroneous_templates;
  
+/* SEEN_ERROR_RAW will be true if we tried to emit an error message, regardless

+   of whether it was actually output or downgraded to a warning.  */
+
+bool seen_error_raw = false;
+
  /* Callback function diagnostic_context::m_adjust_diagnostic_info.
  
 Errors issued when parsing a template are automatically treated like

@@ -227,40 +232,35 @@ cp_adjust_diagnostic_info (diagnostic_context *context,
   diagnostic_info *diagnostic)
  {
if (diagnostic->kind == DK_ERROR)
-if (tree tmpl = get_current_template ())
-  {
-   diagnostic->option_id = OPT_Wtemplate_body;
-
-   if (context->m_permissive)
- diagnostic->kind = DK_WARNING;
-
-   bool existed;
-   location_t &error_loc
- = hash_map_safe_get_or_insert (erroneous_templates,
-  tmpl, &existed);
-   if (!existed)
- /* Remember that this template had a parse-time error so
-that we'll ensure a hard error has been issued upon
-its instantiation.  */
- error_loc = diagnostic->richloc->get_loc ();
-  }
+{
+  seen_error_raw = true;
+  if (tree tmpl = get_current_template ())
+   {
+ diagnostic->option_id = OPT_Wtemplate_body;
+
+ if (context->m_permissive)
+   diagnostic->kind = DK_WARNING;
+
+ bool existed;
+ location_t &error_loc
+   = hash_map_safe_get_or_insert (erroneous_templates,
+tmpl, &existed);
+ if (!existed)
+   /* Remember that this template had a parse-time error so
+  that we'll ensure a hard error has been issued upon
+  its instantiation.  */
+   error_loc = diagnostic->richloc->get_loc ();
+   }
+}
  }
  
  /* A generalization of seen_error which also returns true if we've

-   permissively downgraded an error to a warning inside a template.  */
+   permissively downgraded an error to a warning.  */
  
  bool

  cp_seen_error ()
  {
-  if ((seen_error) ())
-return true;
-
-  if (erroneous_templates)
-if (tree tmpl = get_current_template ())
-  if (erroneous_templates->get (tmpl))
-   return true;
-
-  return false;
+  return (seen_error) () || seen_error_raw;
  }
  
  /* CONTEXT->printer is a basic pretty printer that was constructed

diff --git a/gcc/cp/typeck2.cc b/gcc/cp/typeck2.cc
index 45edd180173..a2d230461c4 100644
--- a/gcc/cp/typeck2.cc
+++ b/gcc/cp/typeck2.cc
@@ -2726,7 +2726,7 @@ merge_exception_specifiers (tree list, tree add)
  return add;
noex = TREE_PURPOSE (list);
gcc_checking_assert (!TREE_PURPOSE (add)
-  || errorcount || !flag_exceptions
+  || seen_error () || !flag_exceptions
   || cp_tree_equal (noex, TREE_PURPOSE (add)));
  
/* Combine the dynamic-exception-specifiers, if any.  */

diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice5-fp

Re: [PATCH 2/2] VR-VALUES: Rewrite test_for_singularity using range_op_handler

[Andrew MacLeod]

On 9/29/23 16:17, Jeff Law wrote:



On 9/5/23 01:12, Andrew Pinski wrote:

On Mon, Sep 4, 2023 at 11:06 PM Jeff Law via Gcc-patches
 wrote:




On 9/1/23 11:30, Andrew Pinski via Gcc-patches wrote:

So it turns out there was a simplier way of starting to
improve VRP to start to fix PR 110131, PR 108360, and PR 108397.
That was rewrite test_for_singularity to use range_op_handler
and Value_Range.

This patch implements that and

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

gcc/ChangeLog:

   * vr-values.cc (test_for_singularity): Add edge argument
   and rewrite using range_op_handler.
   (simplify_compare_using_range_pairs): Use Value_Range
   instead of value_range and update test_for_singularity call.

gcc/testsuite/ChangeLog:

   * gcc.dg/tree-ssa/vrp124.c: New test.
   * gcc.dg/tree-ssa/vrp125.c: New test.
---



diff --git a/gcc/vr-values.cc b/gcc/vr-values.cc
index 52ab4fe6109..2474e57ee90 100644
--- a/gcc/vr-values.cc
+++ b/gcc/vr-values.cc
@@ -904,69 +904,33 @@ 
simplify_using_ranges::simplify_bit_ops_using_ranges

   }

   /* We are comparing trees OP1 and OP2 using COND_CODE. OP1 has
-   a known value range VR.
+   a known value range OP1_RANGE.

  If there is one and only one value which will satisfy the
-   conditional, then return that value.  Else return NULL.
-
-   If signed overflow must be undefined for the value to satisfy
-   the conditional, then set *STRICT_OVERFLOW_P to true. */
+   conditional on the EDGE, then return that value.
+   Else return NULL.  */

   static tree
   test_for_singularity (enum tree_code cond_code, tree op1,
-   tree op2, const value_range *vr)
+   tree op2, const int_range_max &op1_range, bool 
edge)

   {
-  tree min = NULL;
-  tree max = NULL;
-
-  /* Extract minimum/maximum values which satisfy the conditional 
as it was

- written.  */
-  if (cond_code == LE_EXPR || cond_code == LT_EXPR)
+  /* This is already a singularity.  */
+  if (cond_code == NE_EXPR || cond_code == EQ_EXPR)
+    return NULL;

I don't think this is necessarily the right thing to do for NE.

Consider if op1 has the range [0,1] and op2 has the value 1. If the
code is NE, then we should be able to return a singularity of 0 since
that's the only value for x where x ne 1 is true given the range for x.


The "false" edge singularity is already known when NE is supplied. I
don't think changing it to the "true" edge singularity will be helpful
all of the time; preferring the value of 0 is a different story.
But that is a different patch and for a different location rather than
inside VRP; it should be in either isel or expand (more likely isel).
I forgot something critically important here.  Specifically, this code 
is supposed to be subsumed by Ranger.


The whole point of this routine is to rewrite to EQ/NE comparisons so 
that we can expose equivalences on the true/false arm of the 
conditional (and NE is just as important as EQ).  It's not really 
about preferring any particular value like 0.


The problem with this routine is it loses information after the code 
has been transformed.  Let's say we had a test x < 4.  If we assume 
that VRP is able to prove X doesn't have any of the values [MIN..3], 
then we can change the test to x == 4 and propagate 4 for any uses of 
X in the true arm.


But on the false ARM we end up with x != 4 which is a wider range than 
[5..MAX].  So if we were to instantiate a new Ranger after the 
transformation we'd lose information on the false arm.  More 
importantly, I think the transformation was bad for either SCEV or 
loop iteration analysis.


When Andrew, Aldy and I kicked this problem around the consensus was 
that Ranger should find and propagate the equivalence, including 
making it visible to jump threading.  That should make the rewriting 
totally unnecessary.


So the net is we really ought to be doing here is looking for cases 
where this code actually helps code generation and if it does we need 
to understand how/why as this code is supposed to go away.


Given you're already poking around in here, you might have such cases 
handy :-)  If you do, I'm sure Andrew, Aldy and I would love to see them.



Since the PR scrolled by, i don't think I ever noticed this thread.. or 
at least where it lead.


This is not an "equivalence" that ranger would propagate because its a 
relation with a constant.


the issue here seems to be:

if (x < 4)   when x has a range something like [0,0][10, 40][30, +INF]

on the true edge, we will propagate the RANGE [0,0] for x and any pass 
which queries the range of x will get [0,0],  just as if if was if (x == 0)

likewise, on the false edge we'll propagate x = [10,40][30, +INF]

so although we don't propagate an *equivalence* as such,  any pass which 
queries the range of X will get the [0,0] range one expects.


As for the transformation...  Perhaps what we are really interested in 
checking here is whether all further uses o

[PATCH] c++/modules: Fix stream-in of member using-decls [PR120414]

[Nathaniel Shead]

Tested on x86_64-pc-linux-gnu (so far just modules.exp), OK for trunk if
full bootstrap+regtest succeeds?

-- >8 --

When streaming in a reference to a data member, we have an oversight
where we did not consider USING_DECLs, despite otherwise handling them
here the same as fields.  This patch corrects that mistake.

PR c++/120414

gcc/cp/ChangeLog:

* module.cc (trees_in::tree_node): Allow reading a USING_DECL
when streaming tt_data_member.

gcc/testsuite/ChangeLog:

* g++.dg/modules/using-31_a.C: New test.
* g++.dg/modules/using-31_b.C: New test.

Signed-off-by: Nathaniel Shead 
---
 gcc/cp/module.cc  |  3 ++-
 gcc/testsuite/g++.dg/modules/using-31_a.C | 18 ++
 gcc/testsuite/g++.dg/modules/using-31_b.C |  5 +
 3 files changed, 25 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/modules/using-31_a.C
 create mode 100644 gcc/testsuite/g++.dg/modules/using-31_b.C

diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 13f8770b7bd..17c040d26b0 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -10512,7 +10512,8 @@ trees_in::tree_node (bool is_use)
  res = lookup_field_ident (ctx, u ());
 
if (!res
-   || TREE_CODE (res) != FIELD_DECL
+   || (TREE_CODE (res) != FIELD_DECL
+   && TREE_CODE (res) != USING_DECL)
|| DECL_CONTEXT (res) != ctx)
  res = NULL_TREE;
  }
diff --git a/gcc/testsuite/g++.dg/modules/using-31_a.C 
b/gcc/testsuite/g++.dg/modules/using-31_a.C
new file mode 100644
index 000..75bd87285e1
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/using-31_a.C
@@ -0,0 +1,18 @@
+// PR c++/120414
+// { dg-additional-options "-fmodules" }
+// { dg-module-cmi m }
+
+export module m;
+
+template 
+struct Base {
+  static constexpr int base_static_mbr_n = n;
+};
+
+template 
+struct Derived : Base {
+  using Base::base_static_mbr_n;
+  static constexpr int go(int x = base_static_mbr_n) { return x; }
+};
+
+template struct Derived<1>;
diff --git a/gcc/testsuite/g++.dg/modules/using-31_b.C 
b/gcc/testsuite/g++.dg/modules/using-31_b.C
new file mode 100644
index 000..e913a77aaf9
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/using-31_b.C
@@ -0,0 +1,5 @@
+// PR c++/120414
+// { dg-additional-options "-fmodules" }
+
+module m;
+static_assert(Derived<1>::go() == 1);
-- 
2.47.0

Re: [PATCH] Verify 'GIMPLE_RETURN' vs. 'RESULT_DECL' if 'aggregate_value_p' [PR119835]

[Richard Biener]

> Am 23.05.2025 um 16:49 schrieb Thomas Schwinge :
> 
> This fell out of me looking into PR119835.  This doesn't resolve the 
> underlying
> issue, but instead of failing GIMPLE semantics verification just by chance in
> the 'GIMPLE pass: nrv' context, it makes the issue observable generally.
> (... thereby regressing a small number of offloading test cases where host vs.
> offload compilers disagree on 'aggregate_value_p' for functions that return
> aggregate types.)
> 
> This cross-references just the three places in the code that I ran into;
> likely there are more?
> 
> No regressions for powerpc64le-unknown-linux-gnu, x86_64-pc-linux-gnu 
> bootstrap
> and 'make check' (without offloading configured).

I think this is a step in the wrong direction in absence of quoting the wrong 
thing that happens downstream when we violate this (an assert does not 
qualify).  ESP. When at the same time we allow the actual thing returned to be 
a register (aka SSA name)

Richard 

>PR middle-end/119835
>gcc/
>* tree-cfg.cc (verify_gimple_return): Verify 'GIMPLE_RETURN' vs.
>'RESULT_DECL' if 'aggregate_value_p'.
>* gimplify.cc (gimplify_return_expr): Cross-reference it.
>* tree-nrv.cc (pass_nrv::execute): Likewise.
> ---
> gcc/gimplify.cc |  1 +
> gcc/tree-cfg.cc | 23 +++
> gcc/tree-nrv.cc |  1 +
> 3 files changed, 25 insertions(+)
> 
> diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
> index 4f385b1b779..ac296ab70bf 100644
> --- a/gcc/gimplify.cc
> +++ b/gcc/gimplify.cc
> @@ -1903,6 +1903,7 @@ gimplify_return_expr (tree stmt, gimple_seq *pre_p)
> }
> 
>   /* If aggregate_value_p is true, then we can return the bare RESULT_DECL.
> + This is checked in 'tree-cfg.cc:verify_gimple_return'.
>  Recall that aggregate_value_p is FALSE for any aggregate type that is
>  returned in registers.  If we're returning values in registers, then
>  we don't want to extend the lifetime of the RESULT_DECL, particularly
> diff --git a/gcc/tree-cfg.cc b/gcc/tree-cfg.cc
> index 6a95b82ff40..2fc99d54934 100644
> --- a/gcc/tree-cfg.cc
> +++ b/gcc/tree-cfg.cc
> @@ -4892,6 +4892,29 @@ verify_gimple_return (greturn *stmt)
>   return true;
> }
> 
> +  /* Verify 'gimplify.cc:gimplify_return_expr' property:
> + "If aggregate_value_p is true, then we can return the bare RESULT_DECL."
> +  */
> +  tree decl_result = DECL_RESULT (current_function_decl);
> +  if (aggregate_value_p (decl_result, current_function_decl))
> +{
> +  tree op_check;
> +  if (TREE_CODE (op) == SSA_NAME)
> +op_check = SSA_NAME_VAR (op);
> +  else
> +op_check = op;
> +  if (op_check != decl_result)
> +{
> +  error ("operand in return statement differs from %qs",
> + get_tree_code_name (TREE_CODE (decl_result)));
> +  if (op != op_check)
> +debug_generic_stmt (op);
> +  debug_generic_stmt (op_check);
> +  debug_generic_stmt (decl_result);
> +  return true;
> +}
> +}
> +
>   if ((TREE_CODE (op) == RESULT_DECL
>&& DECL_BY_REFERENCE (op))
>   || (TREE_CODE (op) == SSA_NAME
> diff --git a/gcc/tree-nrv.cc b/gcc/tree-nrv.cc
> index 180ce39de4c..6ac77567600 100644
> --- a/gcc/tree-nrv.cc
> +++ b/gcc/tree-nrv.cc
> @@ -174,6 +174,7 @@ pass_nrv::execute (function *fun)
>  /* In a function with an aggregate return value, the
> gimplifier has changed all non-empty RETURN_EXPRs to
> return the RESULT_DECL.  */
> +  /* See also 'tree-cfg.cc:verify_gimple_return'.  */
>  ret_val = gimple_return_retval (return_stmt);
>  if (ret_val)
>gcc_assert (ret_val == result);
> --
> 2.34.1
> 

Re: [PATCH] testsuite: Fix typo in parse_ctx.cc

[Stefan Schulze Frielinghaus]

On Wed, May 21, 2025 at 07:34:27PM +0200, Stefan Schulze Frielinghaus wrote:
> libstdc++-v3/ChangeLog:
> 
>   * testsuite/std/format/parse_ctx.cc: Fix typo for bfloat16 guard.
> ---
>  Ok for mainline?

Just realized that I can use my super powers ;-) and pushed as obvious
in commit 08b4f6198de9c13a8d31580dde052006d2081e52.

> 
>  libstdc++-v3/testsuite/std/format/parse_ctx.cc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libstdc++-v3/testsuite/std/format/parse_ctx.cc 
> b/libstdc++-v3/testsuite/std/format/parse_ctx.cc
> index adafc58c183..6294dcf43f5 100644
> --- a/libstdc++-v3/testsuite/std/format/parse_ctx.cc
> +++ b/libstdc++-v3/testsuite/std/format/parse_ctx.cc
> @@ -539,7 +539,7 @@ test_dynamic_type_check()
>(void) std::format("{:str}", X{}, "H2G2");
>(void) std::format("{:float}", X{}, 10.0);
>  
> -#ifdef __STDCPP_FLOAT16_T__
> +#ifdef __STDCPP_BFLOAT16_T__
>if constexpr (std::formattable)
>  (void) std::format("{:other}", X{}, 10.0bf16);
>  #endif
> -- 
> 2.49.0
> 

[PATCH] Verify 'GIMPLE_RETURN' vs. 'RESULT_DECL' if 'aggregate_value_p' [PR119835]

[Thomas Schwinge]

This fell out of me looking into PR119835.  This doesn't resolve the underlying
issue, but instead of failing GIMPLE semantics verification just by chance in
the 'GIMPLE pass: nrv' context, it makes the issue observable generally.
(... thereby regressing a small number of offloading test cases where host vs.
offload compilers disagree on 'aggregate_value_p' for functions that return
aggregate types.)

This cross-references just the three places in the code that I ran into;
likely there are more?

No regressions for powerpc64le-unknown-linux-gnu, x86_64-pc-linux-gnu bootstrap
and 'make check' (without offloading configured).

PR middle-end/119835
gcc/
* tree-cfg.cc (verify_gimple_return): Verify 'GIMPLE_RETURN' vs.
'RESULT_DECL' if 'aggregate_value_p'.
* gimplify.cc (gimplify_return_expr): Cross-reference it.
* tree-nrv.cc (pass_nrv::execute): Likewise.
---
 gcc/gimplify.cc |  1 +
 gcc/tree-cfg.cc | 23 +++
 gcc/tree-nrv.cc |  1 +
 3 files changed, 25 insertions(+)

diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index 4f385b1b779..ac296ab70bf 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -1903,6 +1903,7 @@ gimplify_return_expr (tree stmt, gimple_seq *pre_p)
 }
 
   /* If aggregate_value_p is true, then we can return the bare RESULT_DECL.
+ This is checked in 'tree-cfg.cc:verify_gimple_return'.
  Recall that aggregate_value_p is FALSE for any aggregate type that is
  returned in registers.  If we're returning values in registers, then
  we don't want to extend the lifetime of the RESULT_DECL, particularly
diff --git a/gcc/tree-cfg.cc b/gcc/tree-cfg.cc
index 6a95b82ff40..2fc99d54934 100644
--- a/gcc/tree-cfg.cc
+++ b/gcc/tree-cfg.cc
@@ -4892,6 +4892,29 @@ verify_gimple_return (greturn *stmt)
   return true;
 }
 
+  /* Verify 'gimplify.cc:gimplify_return_expr' property:
+ "If aggregate_value_p is true, then we can return the bare RESULT_DECL."
+  */
+  tree decl_result = DECL_RESULT (current_function_decl);
+  if (aggregate_value_p (decl_result, current_function_decl))
+{
+  tree op_check;
+  if (TREE_CODE (op) == SSA_NAME)
+   op_check = SSA_NAME_VAR (op);
+  else
+   op_check = op;
+  if (op_check != decl_result)
+   {
+ error ("operand in return statement differs from %qs",
+get_tree_code_name (TREE_CODE (decl_result)));
+ if (op != op_check)
+   debug_generic_stmt (op);
+ debug_generic_stmt (op_check);
+ debug_generic_stmt (decl_result);
+ return true;
+   }
+}
+
   if ((TREE_CODE (op) == RESULT_DECL
&& DECL_BY_REFERENCE (op))
   || (TREE_CODE (op) == SSA_NAME
diff --git a/gcc/tree-nrv.cc b/gcc/tree-nrv.cc
index 180ce39de4c..6ac77567600 100644
--- a/gcc/tree-nrv.cc
+++ b/gcc/tree-nrv.cc
@@ -174,6 +174,7 @@ pass_nrv::execute (function *fun)
  /* In a function with an aggregate return value, the
 gimplifier has changed all non-empty RETURN_EXPRs to
 return the RESULT_DECL.  */
+ /* See also 'tree-cfg.cc:verify_gimple_return'.  */
  ret_val = gimple_return_retval (return_stmt);
  if (ret_val)
gcc_assert (ret_val == result);
-- 
2.34.1

Re: [PATCH v3 0/9] Implement layouts from mdspan.

[Luc Grosheintz]

On 5/22/25 15:21, Tomasz Kaminski wrote:

Thanks for working on the patches, they look solid, comments.

Could you prepare a separate patch to fix initialization
default-initialization of extents,
that you have noticed, standard requires them to be value-initialized, and
add corresponding test?


Yes, I was thinking of something that statically allocates
sizeof(Extents) bytes, sets all the bits to 1 and then uses placement
new to "run" the default ctor. That way we can be confident that
the zeros we're observing aren't accidental.

We do a renaming within this patch series that affects the value
initialization patch. Should I submit a v4 that applies cleanly
to master *after* applying the value initialization patch? (And
cause conflict if applied to the current state of master.)



Similarly, we have test for default constructor of stride_mapping, I would
add them for other layouts,
and check:
   * all extents being static -> depends on mapping
   * first extent being dynamic, and rest static -> all strides are zero
   * middle extent being dynamic


Yes, definitely.



For the stride and product computation, we should perform them in
Extent::size_type, not index_type.
The latter may be signed, and we may hit UB in multiplying non-zero
extents, before reaching the zero.


This seems unfortunate, because if I understood correctly, the idea
behind allowing signed `index_type`, was that signed integer operations
are faster (exactly because they don't need to behave "well" on overflow).

I've made the changes to use unsigned integers. However, I'd like to add
this to my pile of performance questions to be investigated.

I believe that since constexpr code must be UB free, we should be able
to create tests, that can detect overflow in the naive formulas.



For is_exhaustive question, I will write to LWG reflector to ask authors,
and see what their opinion is.
Will keep you posted.


Thank you! Somehow I'm failing to figure out a reasonable algorithm
to check it in a conformant way, so this is definitely welcome.
(Brute-force is not reasonable.)



In a lot of tests we are doing, where I believe we could skip template
parameters, and deduce it for argument.
   verify_nothrow_convertible>(
+   std::extents{});
Could you look into doing it?


I could only find them in cases like:

  template
  const void
  verify_nothrow_convertible(OExtents oexts);

i.e. the first is explicitly given and the second is deduced. This
happens when checking properties of mappings of the same layout with
different extent_types. I didn't add anything to reduce the amount
of code when Extents == OExtents, because it felt non-uniform (I
don't like remembering special cases) and a little error prone. Let
me know if you see it differently and would like me to add a default
template argument to handle the case Extents == OExtents.



Regards,
Tomasz

On Thu, May 22, 2025 at 2:21 PM Tomasz Kaminski  wrote:




On Wed, May 21, 2025 at 4:21 PM Luc Grosheintz 
wrote:


It's missing the "registration" of the three new classes in
std.cc.in.


Please remember to add it in next revisions.



On 5/21/25 11:40, Luc Grosheintz wrote:

Follows up on:
https://gcc.gnu.org/pipermail/libstdc++/2025-May/061535.html

To improve naming conventions, this series includes three new commits:
* Two commits to rename  _ExtentsStorage::_M_dynamic_extents, and
  extents::_M_dynamic_extents.
* One commit to cleanup whitespace errors in extents.

The changes to the existing commits are:
* Fix division by zero bug.
* Rename subextents -> extents.
* Default arguments for __{static,dynamic}_extents.
* Default argument for __static_quotient.
* Four times: use range-based for.
* Eliminate __has_static_zero
* Short-circuit in __static_quotient.
* Optimize __exts_prod for rank == rank_dynamic.

This review suggestion was intentionally skipped:
* Inline helper of __exts_prod, because with the additional
optimization for rank == rank_dynamic, having two separate
functions makes the highlevel structure a little bit more
obvious. Additionally, there's numerous changes planned that
might make one of the two functions much more verbose.

Luc Grosheintz (9):
libstdc++: Rename _ExtentsStorage::_M_dynamic_extents.
libstdc++: Rename extents::_M_dynamic_extents.
libstdc++: Cleanup formatting in mdspan.
libstdc++: Implement layout_left from mdspan.
libstdc++: Add tests for layout_left.
libstdc++: Implement layout_right from mdspan.
libstdc++: Add tests for layout_right.
libstdc++: Implement layout_stride from mdspan.
libstdc++: Add tests for layout_stride.

   libstdc++-v3/include/std/mdspan   | 692 +-
   .../mdspan/layouts/class_mandate_neg.cc   |  42 ++
   .../23_containers/mdspan/layouts/ctors.cc | 401 ++
   .../23_containers/mdspan/layouts/mapping.cc   | 569 ++
   .../23_containers/mdspan/layouts/stride.cc| 494 ++

[PATCH v2] ext-dce: Don't refine live width with SUBREG mode if !TRULY_NOOP_TRUNCATION_MODES_P [PR 120050]

[Xi Ruoyao]

If we see a promoted subreg and TRULY_NOOP_TRUNCATION says the
truncation is not a noop, then all bits of the inner reg are live.  We
cannot reduce the live mask to that of the mode of the subreg.

gcc/ChangeLog:

PR rtl-optimization/120050
* ext-dce.cc (ext_dce_process_uses): Break early if a SUBREG in
rhs is promoted and the truncation from the inner mode to the
outer mode is not a noop when handling SETs.
---

Bootstrapped on mips64el-linux-gnuabi64.  Ok for trunk?

 gcc/ext-dce.cc | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/gcc/ext-dce.cc b/gcc/ext-dce.cc
index a0343950141..3b21e68b90c 100644
--- a/gcc/ext-dce.cc
+++ b/gcc/ext-dce.cc
@@ -35,6 +35,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "print-rtl.h"
 #include "dbgcnt.h"
 #include "diagnostic-core.h"
+#include "target.h"
 
 /* These should probably move into a C++ class.  */
 static vec livein;
@@ -764,13 +765,20 @@ ext_dce_process_uses (rtx_insn *insn, rtx obj,
 We don't want to mark those bits live unnecessarily
 as that inhibits extension elimination in important
 cases such as those in Coremark.  So we need that
-outer code.  */
+outer code.
+
+But if !TRULY_NOOP_TRUNCATION_MODES_P, those bits
+may be actually alive with any promoted subreg
+regardless of the outer code.  See PR 120050.  */
  if (!REG_P (SUBREG_REG (y))
  || (SUBREG_PROMOTED_VAR_P (y)
  && ((GET_CODE (SET_SRC (x)) == SIGN_EXTEND
   && SUBREG_PROMOTED_SIGNED_P (y))
  || (GET_CODE (SET_SRC (x)) == ZERO_EXTEND
- && SUBREG_PROMOTED_UNSIGNED_P (y)
+ && SUBREG_PROMOTED_UNSIGNED_P (y))
+ || !TRULY_NOOP_TRUNCATION_MODES_P (
+   GET_MODE (y),
+   GET_MODE (SUBREG_REG (y))
break;
 
  bit = subreg_lsb (y).to_constant ();
-- 
2.49.0

Re: [PATCH] c++/modules: Fix merge of TLS import functions [PR120363]

[Jason Merrill]

On 5/22/25 8:22 AM, Nathaniel Shead wrote:

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

(Also is renaming the old test OK/appropriate? Or should I keep it
before and just name the new tests as tls1/2, with a comment referring
to pr113292?)

-- >8 --

The PR notes that we missed setting DECL_CONTEXT on the TLS init
function; we missed this initially because this function is not created
in header units, only named modules.

I also noticed that 'DECL_CONTEXT (fn) = DECL_CONTEXT (var)' was
incorrect: for class members, this ends up having the modules merging
machinery treat the decl as a member function, which breaks when
attempting to dedup against an existing completed class type.  Instead
we can just use the global_namespace as the context, because the name of
the function is already mangled appropriately so that we'll match the
correct duplicates.

PR c++/120363

gcc/cp/ChangeLog:

* decl2.cc (get_tls_init_fn): Set context as global_namespace.
(get_tls_wrapper_fn): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/modules/pr113292_a.H: Move to...
* g++.dg/modules/tls-1_a.H: ...here.
* g++.dg/modules/pr113292_b.C: Move to...
* g++.dg/modules/tls-1_b.C: ...here.
* g++.dg/modules/pr113292_c.C: Move to...
* g++.dg/modules/tls-1_c.C: ...here.
* g++.dg/modules/tls-2_a.C: New test.
* g++.dg/modules/tls-2_b.C: New test.
* g++.dg/modules/tls-2_c.C: New test.
* g++.dg/modules/tls-3.h: New test.
* g++.dg/modules/tls-3_a.H: New test.
* g++.dg/modules/tls-3_b.C: New test.

Signed-off-by: Nathaniel Shead 
---
  gcc/cp/decl2.cc   |  3 +-
  .../modules/{pr113292_a.H => tls-1_a.H}   |  0
  .../modules/{pr113292_b.C => tls-1_b.C}   |  2 +-
  .../modules/{pr113292_c.C => tls-1_c.C}   |  2 +-
  gcc/testsuite/g++.dg/modules/tls-2_a.C| 12 ++
  gcc/testsuite/g++.dg/modules/tls-2_b.C|  5 +++
  gcc/testsuite/g++.dg/modules/tls-2_c.C| 11 +
  gcc/testsuite/g++.dg/modules/tls-3.h  | 42 +++
  gcc/testsuite/g++.dg/modules/tls-3_a.H|  4 ++
  gcc/testsuite/g++.dg/modules/tls-3_b.C|  4 ++
  10 files changed, 82 insertions(+), 3 deletions(-)
  rename gcc/testsuite/g++.dg/modules/{pr113292_a.H => tls-1_a.H} (100%)
  rename gcc/testsuite/g++.dg/modules/{pr113292_b.C => tls-1_b.C} (93%)
  rename gcc/testsuite/g++.dg/modules/{pr113292_c.C => tls-1_c.C} (93%)
  create mode 100644 gcc/testsuite/g++.dg/modules/tls-2_a.C
  create mode 100644 gcc/testsuite/g++.dg/modules/tls-2_b.C
  create mode 100644 gcc/testsuite/g++.dg/modules/tls-2_c.C
  create mode 100644 gcc/testsuite/g++.dg/modules/tls-3.h
  create mode 100644 gcc/testsuite/g++.dg/modules/tls-3_a.H
  create mode 100644 gcc/testsuite/g++.dg/modules/tls-3_b.C

diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
index a08d173c0df..be82ccd8bc1 100644
--- a/gcc/cp/decl2.cc
+++ b/gcc/cp/decl2.cc
@@ -4028,6 +4028,7 @@ get_tls_init_fn (tree var)
SET_DECL_LANGUAGE (fn, lang_c);
TREE_PUBLIC (fn) = TREE_PUBLIC (var);
DECL_ARTIFICIAL (fn) = true;
+  DECL_CONTEXT (fn) = global_namespace;


Generally we do FROB_CONTEXT (global_namespace) so we never actually see 
global_namespace in DECL_CONTEXT.  I'm not sure that's necessary in this 
particular case, but best to be consistent.


The test renaming is fine.


DECL_COMDAT (fn) = DECL_COMDAT (var);
DECL_EXTERNAL (fn) = DECL_EXTERNAL (var);
if (DECL_ONE_ONLY (var))
@@ -4087,7 +4088,7 @@ get_tls_wrapper_fn (tree var)
TREE_PUBLIC (fn) = TREE_PUBLIC (var);
DECL_ARTIFICIAL (fn) = true;
DECL_IGNORED_P (fn) = 1;
-  DECL_CONTEXT (fn) = DECL_CONTEXT (var);
+  DECL_CONTEXT (fn) = global_namespace;
/* The wrapper is inline and emitted everywhere var is used.  */
DECL_DECLARED_INLINE_P (fn) = true;
if (TREE_PUBLIC (var))
diff --git a/gcc/testsuite/g++.dg/modules/pr113292_a.H 
b/gcc/testsuite/g++.dg/modules/tls-1_a.H
similarity index 100%
rename from gcc/testsuite/g++.dg/modules/pr113292_a.H
rename to gcc/testsuite/g++.dg/modules/tls-1_a.H
diff --git a/gcc/testsuite/g++.dg/modules/pr113292_b.C 
b/gcc/testsuite/g++.dg/modules/tls-1_b.C
similarity index 93%
rename from gcc/testsuite/g++.dg/modules/pr113292_b.C
rename to gcc/testsuite/g++.dg/modules/tls-1_b.C
index fc582a5a0cf..941bff2710a 100644
--- a/gcc/testsuite/g++.dg/modules/pr113292_b.C
+++ b/gcc/testsuite/g++.dg/modules/tls-1_b.C
@@ -1,7 +1,7 @@
  // PR c++/113292
  // { dg-additional-options "-fmodules-ts" }
  
-import "pr113292_a.H";

+import "tls-1_a.H";
  
  // provide a definition of 'instance' so things link

  thread_local test test::instance;
diff --git a/gcc/testsuite/g++.dg/modules/pr113292_c.C 
b/gcc/testsuite/g++.dg/modules/tls-1_c.C
similarity index 93%
rename from gcc/testsuite/g++.dg/modules/pr113292_c.C
rename to gcc/testsuite/g++.dg/modules/tls-1_c

[PATCH v2] c++/modules: Fix merge of TLS init functions [PR120363]

[Nathaniel Shead]

On Fri, May 23, 2025 at 10:23:51AM -0400, Jason Merrill wrote:
> On 5/22/25 8:22 AM, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
> > 
> > (Also is renaming the old test OK/appropriate? Or should I keep it
> > before and just name the new tests as tls1/2, with a comment referring
> > to pr113292?)
> > 
> > -- >8 --
> > 
> > The PR notes that we missed setting DECL_CONTEXT on the TLS init
> > function; we missed this initially because this function is not created
> > in header units, only named modules.
> > 
> > I also noticed that 'DECL_CONTEXT (fn) = DECL_CONTEXT (var)' was
> > incorrect: for class members, this ends up having the modules merging
> > machinery treat the decl as a member function, which breaks when
> > attempting to dedup against an existing completed class type.  Instead
> > we can just use the global_namespace as the context, because the name of
> > the function is already mangled appropriately so that we'll match the
> > correct duplicates.
> > 
> > PR c++/120363
> > 
> > gcc/cp/ChangeLog:
> > 
> > * decl2.cc (get_tls_init_fn): Set context as global_namespace.
> > (get_tls_wrapper_fn): Likewise.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/modules/pr113292_a.H: Move to...
> > * g++.dg/modules/tls-1_a.H: ...here.
> > * g++.dg/modules/pr113292_b.C: Move to...
> > * g++.dg/modules/tls-1_b.C: ...here.
> > * g++.dg/modules/pr113292_c.C: Move to...
> > * g++.dg/modules/tls-1_c.C: ...here.
> > * g++.dg/modules/tls-2_a.C: New test.
> > * g++.dg/modules/tls-2_b.C: New test.
> > * g++.dg/modules/tls-2_c.C: New test.
> > * g++.dg/modules/tls-3.h: New test.
> > * g++.dg/modules/tls-3_a.H: New test.
> > * g++.dg/modules/tls-3_b.C: New test.
> > 
> > Signed-off-by: Nathaniel Shead 
> > ---
> >   gcc/cp/decl2.cc   |  3 +-
> >   .../modules/{pr113292_a.H => tls-1_a.H}   |  0
> >   .../modules/{pr113292_b.C => tls-1_b.C}   |  2 +-
> >   .../modules/{pr113292_c.C => tls-1_c.C}   |  2 +-
> >   gcc/testsuite/g++.dg/modules/tls-2_a.C| 12 ++
> >   gcc/testsuite/g++.dg/modules/tls-2_b.C|  5 +++
> >   gcc/testsuite/g++.dg/modules/tls-2_c.C| 11 +
> >   gcc/testsuite/g++.dg/modules/tls-3.h  | 42 +++
> >   gcc/testsuite/g++.dg/modules/tls-3_a.H|  4 ++
> >   gcc/testsuite/g++.dg/modules/tls-3_b.C|  4 ++
> >   10 files changed, 82 insertions(+), 3 deletions(-)
> >   rename gcc/testsuite/g++.dg/modules/{pr113292_a.H => tls-1_a.H} (100%)
> >   rename gcc/testsuite/g++.dg/modules/{pr113292_b.C => tls-1_b.C} (93%)
> >   rename gcc/testsuite/g++.dg/modules/{pr113292_c.C => tls-1_c.C} (93%)
> >   create mode 100644 gcc/testsuite/g++.dg/modules/tls-2_a.C
> >   create mode 100644 gcc/testsuite/g++.dg/modules/tls-2_b.C
> >   create mode 100644 gcc/testsuite/g++.dg/modules/tls-2_c.C
> >   create mode 100644 gcc/testsuite/g++.dg/modules/tls-3.h
> >   create mode 100644 gcc/testsuite/g++.dg/modules/tls-3_a.H
> >   create mode 100644 gcc/testsuite/g++.dg/modules/tls-3_b.C
> > 
> > diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
> > index a08d173c0df..be82ccd8bc1 100644
> > --- a/gcc/cp/decl2.cc
> > +++ b/gcc/cp/decl2.cc
> > @@ -4028,6 +4028,7 @@ get_tls_init_fn (tree var)
> > SET_DECL_LANGUAGE (fn, lang_c);
> > TREE_PUBLIC (fn) = TREE_PUBLIC (var);
> > DECL_ARTIFICIAL (fn) = true;
> > +  DECL_CONTEXT (fn) = global_namespace;
> 
> Generally we do FROB_CONTEXT (global_namespace) so we never actually see
> global_namespace in DECL_CONTEXT.  I'm not sure that's necessary in this
> particular case, but best to be consistent.

I see, thanks.  Updated below, and fixed thinko in commit title; testing
modules.exp passed successfully on x86_64-pc-linux-gnu.

OK for trunk/15 if full bootstrap+regtest succeeds?

-- >8 --

Subject: [PATCH] c++/modules: Fix merge of TLS init functions [PR120363]

The PR notes that we missed setting DECL_CONTEXT on the TLS init
function; we missed this initially because this function is not created
in header units, only named modules.

I also noticed that 'DECL_CONTEXT (fn) = DECL_CONTEXT (var)' was
incorrect: for class members, this ends up having the modules merging
machinery treat the decl as a member function, which breaks when
attempting to dedup against an existing completed class type.  Instead
we can just use the global_namespace as the context, because the name of
the function is already mangled appropriately so that we'll match the
correct duplicates.

PR c++/120363

gcc/cp/ChangeLog:

* decl2.cc (get_tls_init_fn): Set context as global_namespace.
(get_tls_wrapper_fn): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/modules/pr113292_a.H: Move to...
* g++.dg/modules/tls-1_a.H: ...here.
* g++.dg/modules/pr113292_b.C: Move to...
* g++.dg/modules/tls-1_b.C: ...here.
* g++.dg/modules/pr113292

Re: [PATCH v3 0/9] Implement layouts from mdspan.

[Tomasz Kaminski]

On Fri, May 23, 2025 at 4:22 PM Luc Grosheintz 
wrote:

>
>
> On 5/22/25 15:21, Tomasz Kaminski wrote:
> > Thanks for working on the patches, they look solid, comments.
> >
> > Could you prepare a separate patch to fix initialization
> > default-initialization of extents,
> > that you have noticed, standard requires them to be value-initialized,
> and
> > add corresponding test?
>
> Yes, I was thinking of something that statically allocates
> sizeof(Extents) bytes, sets all the bits to 1 and then uses placement
> new to "run" the default ctor. That way we can be confident that
> the zeros we're observing aren't accidental.
>
Running the constructor at compile time will be sufficient, to detect if
zero were
set explicitly, so do not need to go extra.

>
> We do a renaming within this patch series that affects the value
> initialization patch. Should I submit a v4 that applies cleanly
> to master *after* applying the value initialization patch? (And
> cause conflict if applied to the current state of master.)
>
Yes, I think we will land the initialization patch before the rest of
series..

>
> >
> > Similarly, we have test for default constructor of stride_mapping, I
> would
> > add them for other layouts,
> > and check:
> >* all extents being static -> depends on mapping
> >* first extent being dynamic, and rest static -> all strides are zero
> >* middle extent being dynamic
>
> Yes, definitely.
>
> >
> > For the stride and product computation, we should perform them in
> > Extent::size_type, not index_type.
> > The latter may be signed, and we may hit UB in multiplying non-zero
> > extents, before reaching the zero.
>
> This seems unfortunate, because if I understood correctly, the idea
> behind allowing signed `index_type`, was that signed integer operations
> are faster (exactly because they don't need to behave "well" on overflow).
>

> I've made the changes to use unsigned integers. However, I'd like to add
> this to my pile of performance questions to be investigated.
>
Just to clarify, we only need to perform stride/required_span_size
computation
using the size_type. For the operator() we should keep using an index_type,
as:
 * we check that required_span_size() fits in index_type
 * if any extent is zero the operator() cannot be invoked.

This will we will still use signed (potentially faster) arithmetic when
retrieving elements,
and unsigned will be limited to use of stride, and other funciton that
perform layout conversions.
And I am less concerned with them.

>
> I believe that since constexpr code must be UB free, we should be able
> to create tests, that can detect overflow in the naive formulas.
>
> >
> > For is_exhaustive question, I will write to LWG reflector to ask authors,
> > and see what their opinion is.
> > Will keep you posted.
>
> Thank you! Somehow I'm failing to figure out a reasonable algorithm
> to check it in a conformant way, so this is definitely welcome.
> (Brute-force is not reasonable.)
>
I should soon have LWG issue number. Then you will add comment in
implementation:
 // _GLIBCXX_RESOLVE_LIB_DEFECTS
 // XXX. Issue title
And also mention in commit message that you are implemented it as modified
by the issue.

>
> >
> > In a lot of tests we are doing, where I believe we could skip template
> > parameters, and deduce it for argument.
> >verify_nothrow_convertible>(
> > +   std::extents{});
> > Could you look into doing it?
>
> I could only find them in cases like:
>
>template
>const void
>verify_nothrow_convertible(OExtents oexts);
>
> i.e. the first is explicitly given and the second is deduced. This
> happens when checking properties of mappings of the same layout with
> different extent_types. I didn't add anything to reduce the amount
> of code when Extents == OExtents, because it felt non-uniform (I
> don't like remembering special cases) and a little error prone. Let
> me know if you see it differently and would like me to add a default
> template argument to handle the case Extents == OExtents.
>
In that case, I believe this is OK.

>
> >
> > Regards,
> > Tomasz
> >
> > On Thu, May 22, 2025 at 2:21 PM Tomasz Kaminski 
> wrote:
> >
> >>
> >>
> >> On Wed, May 21, 2025 at 4:21 PM Luc Grosheintz <
> luc.groshei...@gmail.com>
> >> wrote:
> >>
> >>> It's missing the "registration" of the three new classes in
> >>> std.cc.in.
> >>>
> >> Please remember to add it in next revisions.
> >>
> >>>
> >>> On 5/21/25 11:40, Luc Grosheintz wrote:
>  Follows up on:
>  https://gcc.gnu.org/pipermail/libstdc++/2025-May/061535.html
> 
>  To improve naming conventions, this series includes three new commits:
>  * Two commits to rename  _ExtentsStorage::_M_dynamic_extents, and
>    extents::_M_dynamic_extents.
>  * One commit to cleanup whitespace errors in extents.
> 
>  The changes to the existing commits are:
>  * Fix division by zero bug.
>  * Rename subextents -> extents.
>  * De

Re: [PATCH v2] libstdc++: Implement C++26 std::indirect [PR119152]

[Tomasz Kaminski]

On Fri, May 23, 2025 at 1:52 PM Jonathan Wakely  wrote:

> On 23/05/25 10:03 +0100, Jonathan Wakely wrote:
> >On 22/05/25 14:50 +0200, Tomasz Kamiński wrote:
> >>From: Jonathan Wakely 
> >>
> >>This papers implements C++26 std::indirect as specified
> >>in P3019 with amendment to move assignment from LWG 4251.
> >>
> >>  PR libstdc++/119152
> >>
> >>libstdc++-v3/ChangeLog:
> >>
> >>  * include/Makefile.am: Add new header.
> >>  * include/Makefile.in: Regenerate.
> >>  * include/bits/indirect.h: New file.
> >>  * include/bits/version.def (indirect): Define.
> >>  * include/bits/version.h: Regenerate.
> >>  * include/std/memory: Include new header.
> >>  * testsuite/std/memory/indirect/copy.cc
> >>  * testsuite/std/memory/indirect/copy_alloc.cc
> >>  * testsuite/std/memory/indirect/ctor.cc
> >>  * testsuite/std/memory/indirect/incomplete.cc
> >>  * testsuite/std/memory/indirect/invalid_neg.cc
> >>  * testsuite/std/memory/indirect/move.cc
> >>  * testsuite/std/memory/indirect/move_alloc.cc
> >>  * testsuite/std/memory/indirect/relops.cc
> >>
> >>Co-authored-by: Tomasz Kamiński 
> >>Signed-off-by: Tomasz Kamiński 
> >>---
> >>Changes in v2:
> >>- Fixed typos in commit messages as pointed by Jakub
> >>- Removed stray comment in indirect.h header as pointed out by Daniel
> >>
> >>libstdc++-v3/include/Makefile.am  |   1 +
> >>libstdc++-v3/include/Makefile.in  |   1 +
> >>libstdc++-v3/include/bits/indirect.h  | 459 ++
> >>libstdc++-v3/include/bits/version.def |   9 +
> >>libstdc++-v3/include/bits/version.h   |  10 +
> >>libstdc++-v3/include/std/memory   |   5 +
> >>.../testsuite/std/memory/indirect/copy.cc | 121 +
> >>.../std/memory/indirect/copy_alloc.cc | 228 +
> >>.../testsuite/std/memory/indirect/ctor.cc | 203 
> >>.../std/memory/indirect/incomplete.cc |  38 ++
> >>.../std/memory/indirect/invalid_neg.cc|  28 ++
> >>.../testsuite/std/memory/indirect/move.cc | 144 ++
> >>.../std/memory/indirect/move_alloc.cc | 296 +++
> >>.../testsuite/std/memory/indirect/relops.cc   |  82 
> >>14 files changed, 1625 insertions(+)
> >>create mode 100644 libstdc++-v3/include/bits/indirect.h
> >>create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/copy.cc
> >>create mode 100644
> libstdc++-v3/testsuite/std/memory/indirect/copy_alloc.cc
> >>create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/ctor.cc
> >>create mode 100644
> libstdc++-v3/testsuite/std/memory/indirect/incomplete.cc
> >>create mode 100644
> libstdc++-v3/testsuite/std/memory/indirect/invalid_neg.cc
> >>create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/move.cc
> >>create mode 100644
> libstdc++-v3/testsuite/std/memory/indirect/move_alloc.cc
> >>create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/relops.cc
> >>
> >>diff --git a/libstdc++-v3/include/Makefile.am
> b/libstdc++-v3/include/Makefile.am
> >>index 3e5b6c4142e..b67d470c27e 100644
> >>--- a/libstdc++-v3/include/Makefile.am
> >>+++ b/libstdc++-v3/include/Makefile.am
> >>@@ -210,6 +210,7 @@ bits_headers = \
> >>  ${bits_srcdir}/gslice_array.h \
> >>  ${bits_srcdir}/hashtable.h \
> >>  ${bits_srcdir}/hashtable_policy.h \
> >>+ ${bits_srcdir}/indirect.h \
> >>  ${bits_srcdir}/indirect_array.h \
> >>  ${bits_srcdir}/ios_base.h \
> >>  ${bits_srcdir}/istream.tcc \
> >>diff --git a/libstdc++-v3/include/Makefile.in
> b/libstdc++-v3/include/Makefile.in
> >>index 3531162b5f7..6f7f2be68fd 100644
> >>--- a/libstdc++-v3/include/Makefile.in
> >>+++ b/libstdc++-v3/include/Makefile.in
> >>@@ -563,6 +563,7 @@ bits_freestanding = \
> >>@GLIBCXX_HOSTED_TRUE@ ${bits_srcdir}/gslice_array.h \
> >>@GLIBCXX_HOSTED_TRUE@ ${bits_srcdir}/hashtable.h \
> >>@GLIBCXX_HOSTED_TRUE@ ${bits_srcdir}/hashtable_policy.h \
> >>+@GLIBCXX_HOSTED_TRUE@${bits_srcdir}/indirect.h \
> >>@GLIBCXX_HOSTED_TRUE@ ${bits_srcdir}/indirect_array.h \
> >>@GLIBCXX_HOSTED_TRUE@ ${bits_srcdir}/ios_base.h \
> >>@GLIBCXX_HOSTED_TRUE@ ${bits_srcdir}/istream.tcc \
> >>diff --git a/libstdc++-v3/include/bits/indirect.h
> b/libstdc++-v3/include/bits/indirect.h
> >>new file mode 100644
> >>index 000..3fd9807a8fd
> >>--- /dev/null
> >>+++ b/libstdc++-v3/include/bits/indirect.h
> >>@@ -0,0 +1,459 @@
> >>+// Vocabulary Types for Composite Class Design -*- C++ -*-
> >>+
> >>+// Copyright The GNU Toolchain Authors.
> >>+//
> >>+// This file is part of the GNU ISO C++ Library.  This library is free
> >>+// software; you can redistribute it and/or modify it under the
> >>+// terms of the GNU General Public License as published by the
> >>+// Free Software Foundation; either version 3, or (at your option)
> >>+// any later version.
> >>+
> >>+// This library is distributed in the hope that it will be useful,
> >>+// but WITHOUT ANY WARRANTY; without even the implied warranty of
> >>+// MERC

Re: [PATCH v2] libstdc++: Implement C++26 std::indirect [PR119152]

[Jonathan Wakely]

On Fri, 23 May 2025 at 16:31, Tomasz Kaminski  wrote:
>
>
>
> On Fri, May 23, 2025 at 1:52 PM Jonathan Wakely  wrote:
>>
>> On 23/05/25 10:03 +0100, Jonathan Wakely wrote:
>> >On 22/05/25 14:50 +0200, Tomasz Kamiński wrote:
>> >>From: Jonathan Wakely 
>> >>
>> >>This papers implements C++26 std::indirect as specified
>> >>in P3019 with amendment to move assignment from LWG 4251.
>> >>
>> >>  PR libstdc++/119152
>> >>
>> >>libstdc++-v3/ChangeLog:
>> >>
>> >>  * include/Makefile.am: Add new header.
>> >>  * include/Makefile.in: Regenerate.
>> >>  * include/bits/indirect.h: New file.
>> >>  * include/bits/version.def (indirect): Define.
>> >>  * include/bits/version.h: Regenerate.
>> >>  * include/std/memory: Include new header.
>> >>  * testsuite/std/memory/indirect/copy.cc
>> >>  * testsuite/std/memory/indirect/copy_alloc.cc
>> >>  * testsuite/std/memory/indirect/ctor.cc
>> >>  * testsuite/std/memory/indirect/incomplete.cc
>> >>  * testsuite/std/memory/indirect/invalid_neg.cc
>> >>  * testsuite/std/memory/indirect/move.cc
>> >>  * testsuite/std/memory/indirect/move_alloc.cc
>> >>  * testsuite/std/memory/indirect/relops.cc
>> >>
>> >>Co-authored-by: Tomasz Kamiński 
>> >>Signed-off-by: Tomasz Kamiński 
>> >>---
>> >>Changes in v2:
>> >>- Fixed typos in commit messages as pointed by Jakub
>> >>- Removed stray comment in indirect.h header as pointed out by Daniel
>> >>
>> >>libstdc++-v3/include/Makefile.am  |   1 +
>> >>libstdc++-v3/include/Makefile.in  |   1 +
>> >>libstdc++-v3/include/bits/indirect.h  | 459 ++
>> >>libstdc++-v3/include/bits/version.def |   9 +
>> >>libstdc++-v3/include/bits/version.h   |  10 +
>> >>libstdc++-v3/include/std/memory   |   5 +
>> >>.../testsuite/std/memory/indirect/copy.cc | 121 +
>> >>.../std/memory/indirect/copy_alloc.cc | 228 +
>> >>.../testsuite/std/memory/indirect/ctor.cc | 203 
>> >>.../std/memory/indirect/incomplete.cc |  38 ++
>> >>.../std/memory/indirect/invalid_neg.cc|  28 ++
>> >>.../testsuite/std/memory/indirect/move.cc | 144 ++
>> >>.../std/memory/indirect/move_alloc.cc | 296 +++
>> >>.../testsuite/std/memory/indirect/relops.cc   |  82 
>> >>14 files changed, 1625 insertions(+)
>> >>create mode 100644 libstdc++-v3/include/bits/indirect.h
>> >>create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/copy.cc
>> >>create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/copy_alloc.cc
>> >>create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/ctor.cc
>> >>create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/incomplete.cc
>> >>create mode 100644 
>> >>libstdc++-v3/testsuite/std/memory/indirect/invalid_neg.cc
>> >>create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/move.cc
>> >>create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/move_alloc.cc
>> >>create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/relops.cc
>> >>
>> >>diff --git a/libstdc++-v3/include/Makefile.am 
>> >>b/libstdc++-v3/include/Makefile.am
>> >>index 3e5b6c4142e..b67d470c27e 100644
>> >>--- a/libstdc++-v3/include/Makefile.am
>> >>+++ b/libstdc++-v3/include/Makefile.am
>> >>@@ -210,6 +210,7 @@ bits_headers = \
>> >>  ${bits_srcdir}/gslice_array.h \
>> >>  ${bits_srcdir}/hashtable.h \
>> >>  ${bits_srcdir}/hashtable_policy.h \
>> >>+ ${bits_srcdir}/indirect.h \
>> >>  ${bits_srcdir}/indirect_array.h \
>> >>  ${bits_srcdir}/ios_base.h \
>> >>  ${bits_srcdir}/istream.tcc \
>> >>diff --git a/libstdc++-v3/include/Makefile.in 
>> >>b/libstdc++-v3/include/Makefile.in
>> >>index 3531162b5f7..6f7f2be68fd 100644
>> >>--- a/libstdc++-v3/include/Makefile.in
>> >>+++ b/libstdc++-v3/include/Makefile.in
>> >>@@ -563,6 +563,7 @@ bits_freestanding = \
>> >>@GLIBCXX_HOSTED_TRUE@ ${bits_srcdir}/gslice_array.h \
>> >>@GLIBCXX_HOSTED_TRUE@ ${bits_srcdir}/hashtable.h \
>> >>@GLIBCXX_HOSTED_TRUE@ ${bits_srcdir}/hashtable_policy.h \
>> >>+@GLIBCXX_HOSTED_TRUE@${bits_srcdir}/indirect.h \
>> >>@GLIBCXX_HOSTED_TRUE@ ${bits_srcdir}/indirect_array.h \
>> >>@GLIBCXX_HOSTED_TRUE@ ${bits_srcdir}/ios_base.h \
>> >>@GLIBCXX_HOSTED_TRUE@ ${bits_srcdir}/istream.tcc \
>> >>diff --git a/libstdc++-v3/include/bits/indirect.h 
>> >>b/libstdc++-v3/include/bits/indirect.h
>> >>new file mode 100644
>> >>index 000..3fd9807a8fd
>> >>--- /dev/null
>> >>+++ b/libstdc++-v3/include/bits/indirect.h
>> >>@@ -0,0 +1,459 @@
>> >>+// Vocabulary Types for Composite Class Design -*- C++ -*-
>> >>+
>> >>+// Copyright The GNU Toolchain Authors.
>> >>+//
>> >>+// This file is part of the GNU ISO C++ Library.  This library is free
>> >>+// software; you can redistribute it and/or modify it under the
>> >>+// terms of the GNU General Public License as published by the
>> >>+// Free Software Foundation; either version 3, or (at your option)
>> >>+// any later

[PATCH] Fix makeinfo error from recently-added nodes missing in menu

[Hans-Peter Nilsson]

The 6.7 version is what's in Debian 11.  I'll commit this as
obvious in a few hours.

-- >8 --
Commit r16-833-gfbb7f1cb5d3c8b appears to have broken builds with
makeinfo from texinfo 6.7 (Debian: 6.7.0.dfsg.2-6) - but not 6.8
(6.8-6+b1).  With 6.7, I see (linebreaks manually added):

if [ xinfo = xinfo ]; then \
makeinfo --split-size=500 --split-size=500 --no-split -I . -I 
/src/gcc/doc \
-I /src/gcc/doc/include -o doc/gcc.info /src/gcc/doc/gcc.texi; \
fi
/src/gcc/doc/implement-c.texi:303: warning: node next `Floating point 
implementation' in
 menu `Arrays and pointers implementation' and in sectioning `Constant 
expressions implementation' differ
/src/gcc/doc/implement-c.texi:413: warning: node `Arrays and pointers 
implementation' is
 next for `Constant expressions implementation' in sectioning but not in menu
/src/gcc/doc/implement-c.texi:413: warning: node `Floating point 
implementation' is
 prev for `Constant expressions implementation' in sectioning but not in menu
/src/gcc/doc/implement-c.texi:413: warning: node `C Implementation' is
 up for `Constant expressions implementation' in sectioning but not in menu
/src/gcc/doc/implement-c.texi:5: node `C Implementation' lacks
 menu item for `Constant expressions implementation' despite being its Up target
/src/gcc/doc/implement-c.texi:432: warning: node prev `Arrays and pointers 
implementation' in
 menu `Floating point implementation' and in sectioning `Constant expressions 
implementation' differ
/src/gcc/doc/implement-c.texi:590: warning: node next `Qualifiers 
implementation' in
 menu `Declarators implementation' and in sectioning `Types implementation' 
differ
/src/gcc/doc/implement-c.texi:642: warning: node `Declarators implementation' is
 next for `Types implementation' in sectioning but not in menu
/src/gcc/doc/implement-c.texi:642: warning: node `Qualifiers implementation' is
 prev for `Types implementation' in sectioning but not in menu
/src/gcc/doc/implement-c.texi:642: warning: node `C Implementation' is
 up for `Types implementation' in sectioning but not in menu
/src/gcc/doc/implement-c.texi:5: node `C Implementation' lacks
 menu item for `Types implementation' despite being its Up target
/src/gcc/doc/implement-c.texi:668: warning: node prev `Declarators 
implementation' in
 menu `Qualifiers implementation' and in sectioning `Types implementation' 
differ
make[2]: *** [Makefile:3790: doc/gcc.info] Error 1

* doc/implement-c.texi (menu): Add recently added nodes "Constant
expressions implementation" and "Types implementation".
---
 gcc/doc/implement-c.texi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gcc/doc/implement-c.texi b/gcc/doc/implement-c.texi
index bdfb6342f0df..8f0c2ff4bf3c 100644
--- a/gcc/doc/implement-c.texi
+++ b/gcc/doc/implement-c.texi
@@ -30,10 +30,12 @@ a freestanding environment); refer to their documentation 
for details.
 * Characters implementation::
 * Integers implementation::
 * Floating point implementation::
+* Constant expressions implementation::
 * Arrays and pointers implementation::
 * Hints implementation::
 * Structures unions enumerations and bit-fields implementation::
 * Qualifiers implementation::
+* Types implementation::
 * Declarators implementation::
 * Statements implementation::
 * Preprocessing directives implementation::
-- 
2.30.2

Re: [PATCH 2/4] c++/modules: Implement streaming of uncontexted TYPE_DECLs [PR98735]

[Jason Merrill]

On 5/21/25 10:15 PM, Nathaniel Shead wrote:

Another approach would be to fix 'write_class_def' to handle these
declarations better, but that ended up being more work and felt fragile.
It also meant streaming a lot more information that we don't need.

Long term I had been playing around with reworking ubsan.cc entirely to
have a fixed set of types it would use we that we could merge with, but
given that there seems to be at least one other place we are creating
ad-hoc types (the struct for constexpr new allocations), and I couldn't
see an easy way of reworking that, I thought we should support this.

Finally, I'm not 100% certain about the hard-coding MK_unique for fields
of contextless types, but given that we've given up merging the owning
TYPE_DECL with anything anyway I think it should be OK.

-- >8 --

Currently, most declarations must have a DECL_CONTEXT for modules
streaming to behave correctly, so that they can have an appropriate
merge key generated and be correctly deduplicated on import.

There are a few exceptions, however, for internally generated
declarations that will never be merged and don't necessarily have an
appropriate parent to key off for the context.  One case that's come up
a few times is TYPE_DECLs, especially temporary RECORD_TYPEs used as
intermediaries within expressions.

Previously I've tried to give all such types a DECL_CONTEXT, but in some
cases that has ended up being infeasible, such as with the types
generated by UBSan (which are shared with the C frontend and don't know
their context, especially when created at global scope).  Additionally,
these types often don't have many of the parts that a normal struct
declaration created via parsing user code would have, which confuses
module streaming.

Given that these types are typically intended to be one-off and unique
anyway, this patch instead adds support for by-value streaming of
uncontexted TYPE_DECLs.  The patch only support streaming the bare
minimum amount of fields needed for the cases I've come across so far;
in general the preference should still be to ensure that DECL_CONTEXT is
set where possible.


We should be able to distinguish such types by CLASS_TYPE_P, which is 
false for them.


Jason

[PATCH] fortran: add constant input support for trig functions with half-revolutions

[Yuao Ma]

Hi Tobias,

The patch has been updated. Could you please take a look when you have a
chance?

> Can you add the PR number to the commit log ("PR fortran/113152")?

Done.

> Can you also update the documentation – as you already did for ATAND?

I think that's quite a lot of wording... Hoping to tackle that in another
patch, if that's okay.

> As now the builtins are available, how about updating mathbuiltins.def
> already?

Done.

> As the comment states, it seems to make sense to put the new symbols at
> the end. GCC generates for "module m" a module file (.mod) which is a
> compress lisp-like file. That one also stores the intrinsic procedure's
> ID – and it makes sense to be upward compatible by appending the new
> ones at the end.

Done.

> Testcases: I think it makes sense to check – either in this patch or in
> the follow up – that -std=f2018 gives a diagnostic that the intrinsic is
> unsupported while -std=f2023 supports it.

Done. When testing invalid input, I'm only testing the first half of the
sentence. The original test case used `.*`, which defaults to a greedy match
and caused issues. I attempted to use `.*?` for a non-greedy match, but it
didn't resolve the problem.

> But this change should be should also mentioned in the ChangeLog to
> avoid going through the change letter by letter to understand whether
> there was a significant change or it was just reformatted.

Done.

Yuao



0001-fortran-add-constant-input-support-for-trig-function.patch
Description: 0001-fortran-add-constant-input-support-for-trig-function.patch

[committed] libstdc++: Fix 17_intro/names.cc failure on Solaris 11.3

[Jonathan Wakely]

There are some names in Solaris libc headers which cause:

FAIL: 17_intro/names.cc  -std=gnu++98 (test for excess errors)
FAIL: 17_intro/names.cc  -std=gnu++11 (test for excess errors)

libstdc++-v3/ChangeLog:

* testsuite/17_intro/names.cc [__sun__] (a, i, n): Undefine.
---

Tested x86_64-linux and sparc-solaris11.3.

Pushed to trunk.

 libstdc++-v3/testsuite/17_intro/names.cc | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/testsuite/17_intro/names.cc 
b/libstdc++-v3/testsuite/17_intro/names.cc
index f67818db425f..0e67c795564d 100644
--- a/libstdc++-v3/testsuite/17_intro/names.cc
+++ b/libstdc++-v3/testsuite/17_intro/names.cc
@@ -323,6 +323,7 @@
 
 #ifdef __sun__
 //  defines these as members of fex_numeric_t
+#undef i
 #undef l
 #undef f
 #undef d
@@ -332,8 +333,11 @@
 #undef ptr
 //  uses this as parameter
 #undef r
-//  uses this as member of drand48_data
+//  uses these as members of drand48_data
+#undef a
 #undef x
+//  defines this as a parameter of timingsafe_memcmp
+#undef n
 #endif
 
 #ifdef __VXWORKS__
-- 
2.49.0

[PATCH] libstdc++: Support std::abs for 128-bit integers and floats [PR96710]

[Jonathan Wakely]

Currently we only provide std::abs(__int128) and std::abs(__float128)
for non-strict modes, i.e. -std=gnu++NN but not -std=c++NN.

This defines those overloads for strict modes too, as a small step
towards resolving PR 96710 (which will eventually mean that __int128
satisfies the std::integral concept).

libstdc++-v3/ChangeLog:

PR libstdc++/96710
* include/bits/std_abs.h [__SIZEOF_INT128__] (abs(__int128)):
Define.
[_GLIBCXX_USE_FLOAT128] (abs(__float128)): Enable definition for
strict modes.
* testsuite/26_numerics/headers/cmath/82644.cc: Use strict_std
instead of defining __STRICT_ANSI__.
* testsuite/26_numerics/headers/cstdlib/abs128.cc: New test.
---

Even before we make std::is_integral_v<__int128> true, I don't see why
we can't overload std::abs for it. Likewise for __float128.

Tested x86_64-linux and sparc-solaris11.3  (-m32 and -m64 for both).

 libstdc++-v3/include/bits/std_abs.h  |  9 -
 .../testsuite/26_numerics/headers/cmath/82644.cc |  3 ++-
 .../26_numerics/headers/cstdlib/abs128.cc| 16 
 3 files changed, 26 insertions(+), 2 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/26_numerics/headers/cstdlib/abs128.cc

diff --git a/libstdc++-v3/include/bits/std_abs.h 
b/libstdc++-v3/include/bits/std_abs.h
index 35ec4d374b6e..3d805e6d6f04 100644
--- a/libstdc++-v3/include/bits/std_abs.h
+++ b/libstdc++-v3/include/bits/std_abs.h
@@ -103,6 +103,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   abs(__GLIBCXX_TYPE_INT_N_3 __x) { return __x >= 0 ? __x : -__x; }
 #endif
 
+#if defined __STRICT_ANSI__ && defined __SIZEOF_INT128__
+  // In strict modes __GLIBCXX_TYPE_INT_N_0 is not defined for __int128,
+  // but we want to always define std::abs(__int128).
+  __extension__ inline _GLIBCXX_CONSTEXPR __int128
+  abs(__int128 __x) { return __x >= 0 ? __x : -__x; }
+#endif
+
 #if defined(__STDCPP_FLOAT16_T__) && defined(_GLIBCXX_FLOAT_IS_IEEE_BINARY32)
   constexpr _Float16
   abs(_Float16 __x)
@@ -137,7 +144,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { return __gnu_cxx::__bfloat16_t(__builtin_fabsf(__x)); }
 #endif
 
-#if !defined(__STRICT_ANSI__) && defined(_GLIBCXX_USE_FLOAT128)
+#if defined(_GLIBCXX_USE_FLOAT128)
   __extension__ inline _GLIBCXX_CONSTEXPR
   __float128
   abs(__float128 __x)
diff --git a/libstdc++-v3/testsuite/26_numerics/headers/cmath/82644.cc 
b/libstdc++-v3/testsuite/26_numerics/headers/cmath/82644.cc
index 3274f0564c4d..40abb2ced668 100644
--- a/libstdc++-v3/testsuite/26_numerics/headers/cmath/82644.cc
+++ b/libstdc++-v3/testsuite/26_numerics/headers/cmath/82644.cc
@@ -15,8 +15,9 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-options "-D__STDCPP_WANT_MATH_SPEC_FUNCS__ -D__STRICT_ANSI__" }
+// { dg-options "-D__STDCPP_WANT_MATH_SPEC_FUNCS__" }
 // { dg-do compile { target c++11 } }
+// // { dg-add-options strict_std }
 
 #define conf_hyperg 1
 #define conf_hypergf 2
diff --git a/libstdc++-v3/testsuite/26_numerics/headers/cstdlib/abs128.cc 
b/libstdc++-v3/testsuite/26_numerics/headers/cstdlib/abs128.cc
new file mode 100644
index ..cfb056219b29
--- /dev/null
+++ b/libstdc++-v3/testsuite/26_numerics/headers/cstdlib/abs128.cc
@@ -0,0 +1,16 @@
+// { dg-do compile }
+// { dg-add-options strict_std }
+
+#include 
+
+template T same_type(T, T) { return T(); }
+
+#ifdef __SIZEOF_INT128__
+__int128 i = 0;
+__int128 j = same_type(std::abs(i), i);
+#endif
+
+#ifdef __SIZEOF_FLOAT128__
+__float128 f = 0.0;
+__float128 g = same_type(std::abs(f), f);
+#endif
-- 
2.49.0

[PATCH] libstdc++: Add smart ptr owner_equals and owner_hash structs and members for P1901R2

[Paul Keir]

This patch implements C++26 "Enabling the Use of weak_ptr as Keys in Unordered 
Associative Containers", as specified in P1901R2.

I don't have write access.

Signed-off-by: Paul Keir 

Tested on x86_64-linux.

libstdc++-v3/ChangeLog:

* include/bits/shared_ptr.h: Added owner_equal and owner_hash members 
to shared_ptr and weak_ptr
* include/bits/shared_ptr_base.h: Added owner_equal and owner_hash 
structs
* testsuite/20_util/owner_equal/cmp.cc: New test.
* testsuite/20_util/owner_equal/noexcept.cc: New test.
* testsuite/20_util/owner_hash/cmp.cc: New test.
* testsuite/20_util/owner_hash/noexcept.cc: New test.
* testsuite/20_util/shared_ptr/observers/owner_equal.cc: New test.
* testsuite/20_util/shared_ptr/observers/owner_hash.cc: New test.
* testsuite/20_util/weak_ptr/observers/owner_equal.cc: New test.
* testsuite/20_util/weak_ptr/observers/owner_hash.cc: New test.

---

 libstdc++-v3/include/bits/shared_ptr.h |  57 ++
 libstdc++-v3/include/bits/shared_ptr_base.h|  40 +++
 libstdc++-v3/testsuite/20_util/owner_equal/cmp.cc  | 122 +
 .../testsuite/20_util/owner_equal/noexcept.cc  |  39 +++
 libstdc++-v3/testsuite/20_util/owner_hash/cmp.cc   | 104 ++
 .../testsuite/20_util/owner_hash/noexcept.cc   |  31 ++
 .../20_util/shared_ptr/observers/owner_equal.cc|  93 
 .../20_util/shared_ptr/observers/owner_hash.cc |  90 +++
 .../20_util/weak_ptr/observers/owner_equal.cc  |  71 
 .../20_util/weak_ptr/observers/owner_hash.cc   |  69 
 10 files changed, 716 insertions(+)

diff --git a/libstdc++-v3/include/bits/shared_ptr.h 
b/libstdc++-v3/include/bits/shared_ptr.h
index a196a0f1212..9f25f6ccc23 100644
--- a/libstdc++-v3/include/bits/shared_ptr.h
+++ b/libstdc++-v3/include/bits/shared_ptr.h
@@ -909,6 +909,63 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 : public _Sp_owner_less, shared_ptr<_Tp>>
 { };

+#if __cplusplus > 202302L
+
+  /**
+   * @brief Provides ownership-based hashing.
+   * @headerfile memory
+   * @since C++26
+   */
+  struct owner_hash
+  {
+template
+size_t operator()(const shared_ptr<_Tp>& __s) const noexcept
+{ return __s.owner_hash(); }
+
+template
+size_t operator()(const weak_ptr<_Tp>& __s) const noexcept
+{ return __s.owner_hash(); }
+
+using is_transparent = void;
+  };
+
+  /**
+   * @brief Provides ownership-based mixed equality comparisons of
+   *shared and weak pointers.
+   * @headerfile memory
+   * @since C++26
+   */
+  struct owner_equal
+  {
+template
+bool
+operator()(const shared_ptr<_Tp1>& __lhs,
+   const shared_ptr<_Tp2>& __rhs) const noexcept
+{ return __lhs.owner_equal(__rhs); }
+
+template
+bool
+operator()(const shared_ptr<_Tp1>& __lhs,
+   const   weak_ptr<_Tp2>& __rhs) const noexcept
+{ return __lhs.owner_equal(__rhs); }
+
+template
+bool
+operator()(const   weak_ptr<_Tp1>& __lhs,
+   const shared_ptr<_Tp2>& __rhs) const noexcept
+{ return __lhs.owner_equal(__rhs); }
+
+template
+bool
+operator()(const weak_ptr<_Tp1>& __lhs,
+   const weak_ptr<_Tp2>& __rhs)   const noexcept
+{ return __lhs.owner_equal(__rhs); }
+
+using is_transparent = void;
+  };
+
+#endif
+
   /**
* @brief Base class allowing use of the member function `shared_from_this`.
* @headerfile memory
diff --git a/libstdc++-v3/include/bits/shared_ptr_base.h 
b/libstdc++-v3/include/bits/shared_ptr_base.h
index b4be1b49e4d..6db8095f583 100644
--- a/libstdc++-v3/include/bits/shared_ptr_base.h
+++ b/libstdc++-v3/include/bits/shared_ptr_base.h
@@ -1122,6 +1122,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _M_less(const __weak_count<_Lp>& __rhs) const noexcept
   { return std::less<_Sp_counted_base<_Lp>*>()(this->_M_pi, __rhs._M_pi); }

+#if __cplusplus > 202302L
+  size_t
+  _M_owner_hash() const noexcept
+  { return std::hash<_Sp_counted_base<_Lp>*>()(this->_M_pi); }
+#endif
+
   // Friend function injected into enclosing namespace and found by ADL
   friend inline bool
   operator==(const __shared_count& __a, const __shared_count& __b) noexcept
@@ -1225,6 +1231,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _M_less(const __shared_count<_Lp>& __rhs) const noexcept
   { return std::less<_Sp_counted_base<_Lp>*>()(this->_M_pi, __rhs._M_pi); }

+#if __cplusplus > 202302L
+  size_t
+  _M_owner_hash() const noexcept
+  { return std::hash<_Sp_counted_base<_Lp>*>()(this->_M_pi); }
+#endif
+
   // Friend function injected into enclosing namespace and found by ADL
   friend inline bool
   operator==(const __weak_count& __a, const __weak_count& __b) noexcept
@@ -1715,6 +1727,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{ return _M_refcount._M_less(__rhs._M_refcount); }
   /// @}

+

Re: [PATCH] c++/modules: Fix stream-in of member using-decls [PR120414]

[Jason Merrill]

On 5/23/25 10:59 AM, Nathaniel Shead wrote:

Tested on x86_64-pc-linux-gnu (so far just modules.exp), OK for trunk if
full bootstrap+regtest succeeds?


OK.


-- >8 --

When streaming in a reference to a data member, we have an oversight
where we did not consider USING_DECLs, despite otherwise handling them
here the same as fields.  This patch corrects that mistake.

PR c++/120414

gcc/cp/ChangeLog:

* module.cc (trees_in::tree_node): Allow reading a USING_DECL
when streaming tt_data_member.

gcc/testsuite/ChangeLog:

* g++.dg/modules/using-31_a.C: New test.
* g++.dg/modules/using-31_b.C: New test.

Signed-off-by: Nathaniel Shead 
---
  gcc/cp/module.cc  |  3 ++-
  gcc/testsuite/g++.dg/modules/using-31_a.C | 18 ++
  gcc/testsuite/g++.dg/modules/using-31_b.C |  5 +
  3 files changed, 25 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/modules/using-31_a.C
  create mode 100644 gcc/testsuite/g++.dg/modules/using-31_b.C

diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 13f8770b7bd..17c040d26b0 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -10512,7 +10512,8 @@ trees_in::tree_node (bool is_use)
  res = lookup_field_ident (ctx, u ());
  
  	if (!res

-   || TREE_CODE (res) != FIELD_DECL
+   || (TREE_CODE (res) != FIELD_DECL
+   && TREE_CODE (res) != USING_DECL)
|| DECL_CONTEXT (res) != ctx)
  res = NULL_TREE;
  }
diff --git a/gcc/testsuite/g++.dg/modules/using-31_a.C 
b/gcc/testsuite/g++.dg/modules/using-31_a.C
new file mode 100644
index 000..75bd87285e1
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/using-31_a.C
@@ -0,0 +1,18 @@
+// PR c++/120414
+// { dg-additional-options "-fmodules" }
+// { dg-module-cmi m }
+
+export module m;
+
+template 
+struct Base {
+  static constexpr int base_static_mbr_n = n;
+};
+
+template 
+struct Derived : Base {
+  using Base::base_static_mbr_n;
+  static constexpr int go(int x = base_static_mbr_n) { return x; }
+};
+
+template struct Derived<1>;
diff --git a/gcc/testsuite/g++.dg/modules/using-31_b.C 
b/gcc/testsuite/g++.dg/modules/using-31_b.C
new file mode 100644
index 000..e913a77aaf9
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/using-31_b.C
@@ -0,0 +1,5 @@
+// PR c++/120414
+// { dg-additional-options "-fmodules" }
+
+module m;
+static_assert(Derived<1>::go() == 1);

Re: [PATCH v2] c++/modules: Fix merge of TLS init functions [PR120363]

[Jason Merrill]

On 5/23/25 10:35 AM, Nathaniel Shead wrote:

On Fri, May 23, 2025 at 10:23:51AM -0400, Jason Merrill wrote:

On 5/22/25 8:22 AM, Nathaniel Shead wrote:

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

(Also is renaming the old test OK/appropriate? Or should I keep it
before and just name the new tests as tls1/2, with a comment referring
to pr113292?)

-- >8 --

The PR notes that we missed setting DECL_CONTEXT on the TLS init
function; we missed this initially because this function is not created
in header units, only named modules.

I also noticed that 'DECL_CONTEXT (fn) = DECL_CONTEXT (var)' was
incorrect: for class members, this ends up having the modules merging
machinery treat the decl as a member function, which breaks when
attempting to dedup against an existing completed class type.  Instead
we can just use the global_namespace as the context, because the name of
the function is already mangled appropriately so that we'll match the
correct duplicates.

PR c++/120363

gcc/cp/ChangeLog:

* decl2.cc (get_tls_init_fn): Set context as global_namespace.
(get_tls_wrapper_fn): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/modules/pr113292_a.H: Move to...
* g++.dg/modules/tls-1_a.H: ...here.
* g++.dg/modules/pr113292_b.C: Move to...
* g++.dg/modules/tls-1_b.C: ...here.
* g++.dg/modules/pr113292_c.C: Move to...
* g++.dg/modules/tls-1_c.C: ...here.
* g++.dg/modules/tls-2_a.C: New test.
* g++.dg/modules/tls-2_b.C: New test.
* g++.dg/modules/tls-2_c.C: New test.
* g++.dg/modules/tls-3.h: New test.
* g++.dg/modules/tls-3_a.H: New test.
* g++.dg/modules/tls-3_b.C: New test.

Signed-off-by: Nathaniel Shead 
---
   gcc/cp/decl2.cc   |  3 +-
   .../modules/{pr113292_a.H => tls-1_a.H}   |  0
   .../modules/{pr113292_b.C => tls-1_b.C}   |  2 +-
   .../modules/{pr113292_c.C => tls-1_c.C}   |  2 +-
   gcc/testsuite/g++.dg/modules/tls-2_a.C| 12 ++
   gcc/testsuite/g++.dg/modules/tls-2_b.C|  5 +++
   gcc/testsuite/g++.dg/modules/tls-2_c.C| 11 +
   gcc/testsuite/g++.dg/modules/tls-3.h  | 42 +++
   gcc/testsuite/g++.dg/modules/tls-3_a.H|  4 ++
   gcc/testsuite/g++.dg/modules/tls-3_b.C|  4 ++
   10 files changed, 82 insertions(+), 3 deletions(-)
   rename gcc/testsuite/g++.dg/modules/{pr113292_a.H => tls-1_a.H} (100%)
   rename gcc/testsuite/g++.dg/modules/{pr113292_b.C => tls-1_b.C} (93%)
   rename gcc/testsuite/g++.dg/modules/{pr113292_c.C => tls-1_c.C} (93%)
   create mode 100644 gcc/testsuite/g++.dg/modules/tls-2_a.C
   create mode 100644 gcc/testsuite/g++.dg/modules/tls-2_b.C
   create mode 100644 gcc/testsuite/g++.dg/modules/tls-2_c.C
   create mode 100644 gcc/testsuite/g++.dg/modules/tls-3.h
   create mode 100644 gcc/testsuite/g++.dg/modules/tls-3_a.H
   create mode 100644 gcc/testsuite/g++.dg/modules/tls-3_b.C

diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
index a08d173c0df..be82ccd8bc1 100644
--- a/gcc/cp/decl2.cc
+++ b/gcc/cp/decl2.cc
@@ -4028,6 +4028,7 @@ get_tls_init_fn (tree var)
 SET_DECL_LANGUAGE (fn, lang_c);
 TREE_PUBLIC (fn) = TREE_PUBLIC (var);
 DECL_ARTIFICIAL (fn) = true;
+  DECL_CONTEXT (fn) = global_namespace;


Generally we do FROB_CONTEXT (global_namespace) so we never actually see
global_namespace in DECL_CONTEXT.  I'm not sure that's necessary in this
particular case, but best to be consistent.


I see, thanks.  Updated below, and fixed thinko in commit title; testing
modules.exp passed successfully on x86_64-pc-linux-gnu.

OK for trunk/15 if full bootstrap+regtest succeeds?


OK.


-- >8 --

Subject: [PATCH] c++/modules: Fix merge of TLS init functions [PR120363]

The PR notes that we missed setting DECL_CONTEXT on the TLS init
function; we missed this initially because this function is not created
in header units, only named modules.

I also noticed that 'DECL_CONTEXT (fn) = DECL_CONTEXT (var)' was
incorrect: for class members, this ends up having the modules merging
machinery treat the decl as a member function, which breaks when
attempting to dedup against an existing completed class type.  Instead
we can just use the global_namespace as the context, because the name of
the function is already mangled appropriately so that we'll match the
correct duplicates.

PR c++/120363

gcc/cp/ChangeLog:

* decl2.cc (get_tls_init_fn): Set context as global_namespace.
(get_tls_wrapper_fn): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/modules/pr113292_a.H: Move to...
* g++.dg/modules/tls-1_a.H: ...here.
* g++.dg/modules/pr113292_b.C: Move to...
* g++.dg/modules/tls-1_b.C: ...here.
* g++.dg/modules/pr113292_c.C: Move to...
* g++.dg/modules/tls-1_c.C: ...here.
* g++.dg/modules/tls-2_a.C: New test.
* g++.dg/modules/tls-2_b.C: New test.
* g+

[PATCH] libstdc++: Replace some uses of std::__addressof with std::addressof

[Jonathan Wakely]

Since r16-154-gc91eb5a5c13f14 std::addressof is no less efficient than
std::__addressof, so change some uses of the latter to the former.

We can't change them all, because some uses need to compile as C++98
which only has std::__addressof.

libstdc++-v3/ChangeLog:

* include/bits/stl_construct.h: Replace std::__addressof with
std::addressof.
* include/bits/stl_uninitialized.h: Likewise.
---

I'm undecided whether it's better to use the standard std::addressof for
simplicity, or to stick with std::__addressof in files where there's a
mix of C++98 code and >= C++11 code.

Obviously in files that don't need to compile as C++98 (such as
) we could just use std::addressof.

Tested x86_64-linux.

 libstdc++-v3/include/bits/stl_construct.h |  2 +-
 libstdc++-v3/include/bits/stl_uninitialized.h | 28 +--
 2 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/libstdc++-v3/include/bits/stl_construct.h 
b/libstdc++-v3/include/bits/stl_construct.h
index 23b8fb754710..a53274e33c0c 100644
--- a/libstdc++-v3/include/bits/stl_construct.h
+++ b/libstdc++-v3/include/bits/stl_construct.h
@@ -82,7 +82,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   if constexpr (__cplusplus > 201703L && is_array_v<_Tp>)
{
  for (auto& __x : *__location)
-   std::destroy_at(std::__addressof(__x));
+   std::destroy_at(std::addressof(__x));
}
   else
__location->~_Tp();
diff --git a/libstdc++-v3/include/bits/stl_uninitialized.h 
b/libstdc++-v3/include/bits/stl_uninitialized.h
index b1428db48b00..bde787c2beaa 100644
--- a/libstdc++-v3/include/bits/stl_uninitialized.h
+++ b/libstdc++-v3/include/bits/stl_uninitialized.h
@@ -839,7 +839,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 {
  _UninitDestroyGuard<_ForwardIterator> __guard(__first);
  for (; __first != __last; ++__first)
-   std::_Construct(std::__addressof(*__first));
+   std::_Construct(std::addressof(*__first));
  __guard.release();
}
 };
@@ -856,7 +856,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return;
 
  typename iterator_traits<_ForwardIterator>::value_type* __val
-   = std::__addressof(*__first);
+   = std::addressof(*__first);
  std::_Construct(__val);
  if (++__first != __last)
std::fill(__first, __last, *__val);
@@ -873,7 +873,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 {
  _UninitDestroyGuard<_ForwardIterator> __guard(__first);
  for (; __n > 0; --__n, (void) ++__first)
-   std::_Construct(std::__addressof(*__first));
+   std::_Construct(std::addressof(*__first));
  __guard.release();
  return __first;
}
@@ -890,7 +890,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  if (__n > 0)
{
  typename iterator_traits<_ForwardIterator>::value_type* __val
-   = std::__addressof(*__first);
+   = std::addressof(*__first);
  std::_Construct(__val);
  ++__first;
  __first = std::fill_n(__first, __n - 1, *__val);
@@ -955,7 +955,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__alloc);
   typedef __gnu_cxx::__alloc_traits<_Allocator> __traits;
   for (; __first != __last; ++__first)
-   __traits::construct(__alloc, std::__addressof(*__first));
+   __traits::construct(__alloc, std::addressof(*__first));
   __guard.release();
 }
 
@@ -980,7 +980,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__alloc);
   typedef __gnu_cxx::__alloc_traits<_Allocator> __traits;
   for (; __n > 0; --__n, (void) ++__first)
-   __traits::construct(__alloc, std::__addressof(*__first));
+   __traits::construct(__alloc, std::addressof(*__first));
   __guard.release();
   return __first;
 }
@@ -1007,7 +1007,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
  _UninitDestroyGuard<_ForwardIterator> __guard(__first);
  for (; __first != __last; ++__first)
-   std::_Construct_novalue(std::__addressof(*__first));
+   std::_Construct_novalue(std::addressof(*__first));
  __guard.release();
}
 };
@@ -1033,7 +1033,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
  _UninitDestroyGuard<_ForwardIterator> __guard(__first);
  for (; __n > 0; --__n, (void) ++__first)
-   std::_Construct_novalue(std::__addressof(*__first));
+   std::_Construct_novalue(std::addressof(*__first));
  __guard.release();
  return __first;
}
@@ -1089,7 +1089,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 {
   _UninitDestroyGuard<_ForwardIterator> __guard(__result);
   for (; __n > 0; --__n, (void) ++__first, ++__result)
-   std::_Construct(std::__addressof(*__result), *__first);
+   std::_Construct(std::addressof(*__result), *__first);
 

[committed] libstdc++: Add always_inline to std::is_constant_evaluated()

[Jonathan Wakely]

We already have the attribute on std::__is_constant_evaluated() but for
some reason not on std::is_constant_evaluated().

libstdc++-v3/ChangeLog:

* include/std/type_traits (is_constant_evaluated): Add
always_inline attribute.
---

Tested x86_64-linux.

Pushed to trunk.

 libstdc++-v3/include/std/type_traits | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index 0601869266c9..6bf355d97cc9 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -4019,7 +4019,8 @@ template
 #ifdef __cpp_lib_is_constant_evaluated // C++ >= 20 && HAVE_IS_CONST_EVAL
   /// Returns true only when called during constant evaluation.
   /// @since C++20
-  constexpr inline bool
+  [[__gnu__::__always_inline__]]
+  constexpr bool
   is_constant_evaluated() noexcept
   {
 #if __cpp_if_consteval >= 202106L
-- 
2.49.0

Re: [PATCH] Fix makeinfo error from recently-added nodes missing in menu

[Richard Biener]

> Am 23.05.2025 um 17:35 schrieb Hans-Peter Nilsson :
> 
> The 6.7 version is what's in Debian 11.  I'll commit this as
> obvious in a few hours.

Thanks- I’ve also seen this on SLES and ppenSUSE Leap.

Richard 

> -- >8 --
> Commit r16-833-gfbb7f1cb5d3c8b appears to have broken builds with
> makeinfo from texinfo 6.7 (Debian: 6.7.0.dfsg.2-6) - but not 6.8
> (6.8-6+b1).  With 6.7, I see (linebreaks manually added):
> 
> if [ xinfo = xinfo ]; then \
>makeinfo --split-size=500 --split-size=500 --no-split -I . -I 
> /src/gcc/doc \
>-I /src/gcc/doc/include -o doc/gcc.info /src/gcc/doc/gcc.texi; \
> fi
> /src/gcc/doc/implement-c.texi:303: warning: node next `Floating point 
> implementation' in
> menu `Arrays and pointers implementation' and in sectioning `Constant 
> expressions implementation' differ
> /src/gcc/doc/implement-c.texi:413: warning: node `Arrays and pointers 
> implementation' is
> next for `Constant expressions implementation' in sectioning but not in menu
> /src/gcc/doc/implement-c.texi:413: warning: node `Floating point 
> implementation' is
> prev for `Constant expressions implementation' in sectioning but not in menu
> /src/gcc/doc/implement-c.texi:413: warning: node `C Implementation' is
> up for `Constant expressions implementation' in sectioning but not in menu
> /src/gcc/doc/implement-c.texi:5: node `C Implementation' lacks
> menu item for `Constant expressions implementation' despite being its Up 
> target
> /src/gcc/doc/implement-c.texi:432: warning: node prev `Arrays and pointers 
> implementation' in
> menu `Floating point implementation' and in sectioning `Constant expressions 
> implementation' differ
> /src/gcc/doc/implement-c.texi:590: warning: node next `Qualifiers 
> implementation' in
> menu `Declarators implementation' and in sectioning `Types implementation' 
> differ
> /src/gcc/doc/implement-c.texi:642: warning: node `Declarators implementation' 
> is
> next for `Types implementation' in sectioning but not in menu
> /src/gcc/doc/implement-c.texi:642: warning: node `Qualifiers implementation' 
> is
> prev for `Types implementation' in sectioning but not in menu
> /src/gcc/doc/implement-c.texi:642: warning: node `C Implementation' is
> up for `Types implementation' in sectioning but not in menu
> /src/gcc/doc/implement-c.texi:5: node `C Implementation' lacks
> menu item for `Types implementation' despite being its Up target
> /src/gcc/doc/implement-c.texi:668: warning: node prev `Declarators 
> implementation' in
> menu `Qualifiers implementation' and in sectioning `Types implementation' 
> differ
> make[2]: *** [Makefile:3790: doc/gcc.info] Error 1
> 
>* doc/implement-c.texi (menu): Add recently added nodes "Constant
>expressions implementation" and "Types implementation".
> ---
> gcc/doc/implement-c.texi | 2 ++
> 1 file changed, 2 insertions(+)
> 
> diff --git a/gcc/doc/implement-c.texi b/gcc/doc/implement-c.texi
> index bdfb6342f0df..8f0c2ff4bf3c 100644
> --- a/gcc/doc/implement-c.texi
> +++ b/gcc/doc/implement-c.texi
> @@ -30,10 +30,12 @@ a freestanding environment); refer to their documentation 
> for details.
> * Characters implementation::
> * Integers implementation::
> * Floating point implementation::
> +* Constant expressions implementation::
> * Arrays and pointers implementation::
> * Hints implementation::
> * Structures unions enumerations and bit-fields implementation::
> * Qualifiers implementation::
> +* Types implementation::
> * Declarators implementation::
> * Statements implementation::
> * Preprocessing directives implementation::
> --
> 2.30.2
> 

simple frm save/restore strategy (was Re: [PATCH 3/6] RISC-V: frm/mode-switch: remove dubious frm edge insertion before call_insn)

[Vineet Gupta]

On 5/22/25 05:12, Robin Dapp wrote:
>>> AFAICT the main difference to standard mode switching is that we (ab)use it 
>>> to set the rounding mode to the value it had initially, either at function 
>>> entry or after a call.  That's different to regular mode switching which 
>>> assumes "static" rounding modes for different instructions.
>>>
>>> Standard could e.g. be:
>>> - insn1 demands frm1
>>> - call1 demands frm4
>>> - call2 demands frm5
>>>
>>> Whereas we have:
>>> - insn1 demands frm1
>>> - call1 demands "frm at the start of the function"
>>> - call2 demands "frm after call1 that could have called fesetround"
>> Weird, call2 can demand the frm as it existed after call1?!?  I'm going 
>> to try not to cry and return to my bubble :-)
> Maybe demand was not really accurate.  It's rather that we want call2 to
> operate with the global rounding mode that call1 might have changed.
> So the demand is not a specific rounding mode but rather the global one.
>
> And as we might have changed the rounding mode without having restored it 
> since 
> we need to jump through those hoops.  Not defending, just describing the 
> status 
> quo, I don't like it either ;) and yeah it's contrary to what we usually 
> assume 
> of liveness etc.
>
> I'd much rather see only a local backup of the rounding mode in the 
> mode-changing intrinsics.  Like
>
> backup FRM
> set specific FRM
> insn with specific FRM
> restore FRM
>
> so we'd always be sure the rounding mode is back to "normal"/"unknown" after 
> an 
> intrinsic and wouldn't need to do anything for calls and exits.

I have a prototype which implements the simple/dumb strategy. Indeed calls are
no longer special.

This does change codegen semantics somewhat (although there's no clear
documented ABI so we have some wiggle room)

1. OK: Inline asm based FRM writes are now considered same as calls. They are
the only way to facilitate global FRM change at all and now this happens
unconditionally whereas in the the old regime things it could behave differently
"under certain conditions" (a restore could overwrite a later global update with
prior one )  see PR/120404 [1]. Gory details in the PR, but it seems this was
not really designed to be, just a fallout of the implementation detail
(eager/early backup before any inline asm got inspected).

 [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120404

2. OK'ish: A bunch of testcases see more reads/writes as PRE of redundant
read/writes is punted to later passes which obviously needs more work.

3. NOK: We loose the ability to instrument local RM writes - especially in the
testsuite.
  e.g.
     a.  instrinsic setting a static RM
 b. get_frm() to ensure that happened (inline asm to read out frm)

The tightly coupled restore kicks in before get_frm could be emitted which fails
to observe #a. This is a deal breaker for the testsuite as much of frm tests
report as fail even if the actual codegen is sane.


> Another argument would also be that we technically aren't allowed to change 
> the 
> rounding mode without -frounding-math (as seen in a PR a while ago) because 
> passes might not do the right thing.  Therefore, increasing the region of 
> non-default rounding mode, could lead to incorrect optimizations.
>
> Anyway, I think Vineet's patches improve on what we have right now.  I'd 
> still 
> like to understand if this "abuse" of mode switching gets globally better 
> results than a very simple approach like above.  If the other (non 
> mode-switching) LCMs cannot really optimize FRM reads and writes the simple
> approach could indeed be worse.

At this point I think we need to reconsider how to proceed. The simple approach
seems promising but we need to solve #3 above first.
OTOH we could just get the low hanging fruit by accepting the incremental
updates to existing state machine (my v1 series)
This solves the optim issue PR/119164, correctness issue PR/120203.

The pending things would be optim issue PR/120245 and correctness issue 
PR/120404

Thx,
-Vineet

[PATCH] doc: Correct the return type of float comparison

[Trevor Gross]

Documentation for `__cmpsf2` and similar functions currently indicate a
return type of `int`. This is not correct however; the `libgcc`
functions return `CMPtype`, the size of which is determined by the
`libgcc_cmp_return` mode.

Update documentation to use `CMPtype` and indicate that this is
target-dependent, also mentioning the usual modes.

Reported-by: beetrees 
Fixes: 
https://github.com/rust-lang/compiler-builtins/issues/919#issuecomment-2905347318
Signed-off-by: Trevor Gross 
---
 gcc/doc/libgcc.texi | 53 +
 1 file changed, 29 insertions(+), 24 deletions(-)

diff --git a/gcc/doc/libgcc.texi b/gcc/doc/libgcc.texi
index 3587ffb1f..530de42fa 100644
--- a/gcc/doc/libgcc.texi
+++ b/gcc/doc/libgcc.texi
@@ -454,9 +454,9 @@ otherwise from signed bit-precise integer.
 
 There are two sets of basic comparison functions.
 
-@deftypefn {Runtime Function} int __cmpsf2 (float @var{a}, float @var{b})
-@deftypefnx {Runtime Function} int __cmpdf2 (double @var{a}, double @var{b})
-@deftypefnx {Runtime Function} int __cmptf2 (long double @var{a}, long double 
@var{b})
+@deftypefn {Runtime Function} CMPtype __cmpsf2 (float @var{a}, float @var{b})
+@deftypefnx {Runtime Function} CMPtype __cmpdf2 (double @var{a}, double 
@var{b})
+@deftypefnx {Runtime Function} CMPtype __cmptf2 (long double @var{a}, long 
double @var{b})
 These functions calculate @math{a <=> b}.  That is, if @var{a} is less
 than @var{b}, they return @minus{}1; if @var{a} is greater than @var{b}, they
 return 1; and if @var{a} and @var{b} are equal they return 0.  If
@@ -465,9 +465,9 @@ if NaN is a possibility, use one of the higher-level 
comparison
 functions.
 @end deftypefn
 
-@deftypefn {Runtime Function} int __unordsf2 (float @var{a}, float @var{b})
-@deftypefnx {Runtime Function} int __unorddf2 (double @var{a}, double @var{b})
-@deftypefnx {Runtime Function} int __unordtf2 (long double @var{a}, long 
double @var{b})
+@deftypefn {Runtime Function} CMPtype __unordsf2 (float @var{a}, float @var{b})
+@deftypefnx {Runtime Function} CMPtype __unorddf2 (double @var{a}, double 
@var{b})
+@deftypefnx {Runtime Function} CMPtype __unordtf2 (long double @var{a}, long 
double @var{b})
 These functions return a nonzero value if either argument is NaN, otherwise 0.
 @end deftypefn
 
@@ -489,49 +489,54 @@ NaN@.  Thus, the meaning of the return value is different 
for each set.
 Do not rely on this implementation; only the semantics documented
 below are guaranteed.
 
-@deftypefn {Runtime Function} int __eqsf2 (float @var{a}, float @var{b})
-@deftypefnx {Runtime Function} int __eqdf2 (double @var{a}, double @var{b})
-@deftypefnx {Runtime Function} int __eqtf2 (long double @var{a}, long double 
@var{b})
+@deftypefn {Runtime Function} CMPtype __eqsf2 (float @var{a}, float @var{b})
+@deftypefnx {Runtime Function} CMPtype __eqdf2 (double @var{a}, double @var{b})
+@deftypefnx {Runtime Function} CMPtype __eqtf2 (long double @var{a}, long 
double @var{b})
 These functions return zero if neither argument is NaN, and @var{a} and
 @var{b} are equal.
 @end deftypefn
 
-@deftypefn {Runtime Function} int __nesf2 (float @var{a}, float @var{b})
-@deftypefnx {Runtime Function} int __nedf2 (double @var{a}, double @var{b})
-@deftypefnx {Runtime Function} int __netf2 (long double @var{a}, long double 
@var{b})
+@deftypefn {Runtime Function} CMPtype __nesf2 (float @var{a}, float @var{b})
+@deftypefnx {Runtime Function} CMPtype __nedf2 (double @var{a}, double @var{b})
+@deftypefnx {Runtime Function} CMPtype __netf2 (long double @var{a}, long 
double @var{b})
 These functions return a nonzero value if either argument is NaN, or
 if @var{a} and @var{b} are unequal.
 @end deftypefn
 
-@deftypefn {Runtime Function} int __gesf2 (float @var{a}, float @var{b})
-@deftypefnx {Runtime Function} int __gedf2 (double @var{a}, double @var{b})
-@deftypefnx {Runtime Function} int __getf2 (long double @var{a}, long double 
@var{b})
+@deftypefn {Runtime Function} CMPtype __gesf2 (float @var{a}, float @var{b})
+@deftypefnx {Runtime Function} CMPtype __gedf2 (double @var{a}, double @var{b})
+@deftypefnx {Runtime Function} CMPtype __getf2 (long double @var{a}, long 
double @var{b})
 These functions return a value greater than or equal to zero if
 neither argument is NaN, and @var{a} is greater than or equal to
 @var{b}.
 @end deftypefn
 
-@deftypefn {Runtime Function} int __ltsf2 (float @var{a}, float @var{b})
-@deftypefnx {Runtime Function} int __ltdf2 (double @var{a}, double @var{b})
-@deftypefnx {Runtime Function} int __lttf2 (long double @var{a}, long double 
@var{b})
+@deftypefn {Runtime Function} CMPtype __ltsf2 (float @var{a}, float @var{b})
+@deftypefnx {Runtime Function} CMPtype __ltdf2 (double @var{a}, double @var{b})
+@deftypefnx {Runtime Function} CMPtype __lttf2 (long double @var{a}, long 
double @var{b})
 These functions return a value less than zero if neither argument is
 NaN, and @var{a} is strictly less than @var{b}.
 @end deftypefn
 
-@deftyp

Re: [PATCH] libstdc++: Add smart ptr owner_equals and owner_hash structs and members for P1901R2

[Jonathan Wakely]

On Fri, 23 May 2025 at 18:56, Paul Keir  wrote:
>
> This patch implements C++26 "Enabling the Use of weak_ptr as Keys in 
> Unordered Associative Containers", as specified in P1901R2.

Splendid, thanks. I'll review this more carefully next week.

Some quick comments:

This should define the __cpp_lib_smart_pointer_owner_equality feature
test macro.

To do that you need to add a new entry in include/bits/version.def
(see the comments at the top and the existing entries which should be
fairly clear - I am in the middle of documenting this process).
Then in the $objdir/x86_64-pc-linux-gnu/libstdc++-v3/include directory
run 'make update-version' which should regenerate the bits/version.h
file to include your new macro.
Then in  define __glibcxx_want_smart_pointer_owner_equality
before including .

> diff --git a/libstdc++-v3/testsuite/20_util/owner_equal/cmp.cc 
> b/libstdc++-v3/testsuite/20_util/owner_equal/cmp.cc
> new file mode 100644
> index 000..c958d9c62ea
> --- /dev/null
> +++ b/libstdc++-v3/testsuite/20_util/owner_equal/cmp.cc
> @@ -0,0 +1,122 @@
> +// { dg-do run { target c++26 } }
> +// { dg-require-effective-target hosted }
> +
> +// Copyright (C) 2008-2025 Free Software Foundation, Inc.

I see that all the new tests have copyright dates varying from 2008 to
2017, but they're all new files (I don't think they copy anythign from
existing tests, right?). So they should not have copyright dates
claiming to be written in the past. They also shouldn't have copyright
notices claiming to be owned by the FSF if you're contributing them
under the DCO terms, because you retain your own copyright.

My preference for new tests is not to bother with the copyright notice
or license text at all. Nothing in those tests looks very novel or
inventive, it's just repetitive, fairly mechanical testing of the API.
I am sceptical whether such things are even copyrightable. So I don't
both with the 20 lines of comments in each file, e.g. see
testsuite/20_util/weak_ptr/atomic_weak_ptr.cc from 2022.


> +// This file is part of the GNU ISO C++ Library.  This library is free
> +// software; you can redistribute it and/or modify it under the
> +// terms of the GNU General Public License as published by the
> +// Free Software Foundation; either version 3, or (at your option)
> +// any later version.
> +
> +// This library is distributed in the hope that it will be useful,
> +// but WITHOUT ANY WARRANTY; without even the implied warranty of
> +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +// GNU General Public License for more details.
> +
> +// You should have received a copy of the GNU General Public License along
> +// with this library; see the file COPYING3.  If not see
> +// .
> +
> +// 20.3.2.6 Struct owner_equal [util.smartptr.owner.equal]

Please put the C++ standard version, or in this case working draft
number, in these comments, e.g.
// N5008 20.3.2.6 Struct owner_equal [util.smartptr.owner.equal]

We didn't used to do that (as you'll see in the old tests) and it
becomes pretty pointless to just have a subclause number in some
unspecified document (unlike the C standard, the C++ subclause numbers
change dramatically between standards).

I have been trying to add "C++11" or "C++03" those comments in old
tests when I touch the file for some other reason.

Re: [PATCH v4 1/2] aarch64: Match unpredicated shift patterns for ADR, SRA and ADDHNB instructions

[Dhruv Chawla]

On 22/05/25 15:56, Richard Sandiford wrote:

External email: Use caution opening links or attachments


 writes:

From: Dhruv Chawla 

This patch modifies the shift expander to immediately lower constant
shifts without unspec. It also modifies the ADR, SRA and ADDHNB patterns
to match the lowered forms of the shifts, as the predicate register is
not required for these instructions.

Bootstrapped and regtested on aarch64-linux-gnu.

Signed-off-by: Dhruv Chawla 
Co-authored-by: Richard Sandiford 

gcc/ChangeLog:

   * gcc/config/aarch64/aarch64-sve.md (@aarch64_adr_shift):
   Match lowered form of ashift.
   (*aarch64_adr_shift): Likewise.
   (*aarch64_adr_shift_sxtw): Likewise.
   (*aarch64_adr_shift_uxtw): Likewise.
   (3): Check amount instead of operands[2] in
   aarch64_sve_shift_operand.
   (v3): Generate unpredicated shifts for constant
   operands.
   (@aarch64_pred_): Convert to a define_expand.
   (*aarch64_pred_): Create define_insn_and_split pattern
   from @aarch64_pred_.
   (*post_ra_v_ashl3): Rename to ...
   (aarch64_vashl3_const): ... this and remove reload requirement.
   (*post_ra_v_3): Rename to ...
   (aarch64_v3_const): ... this and remove reload
   requirement.
   * gcc/config/aarch64/aarch64-sve2.md
   (@aarch64_sve_add_): Match lowered form of
   SHIFTRT.
   (*aarch64_sve2_sra): Likewise.
   (*bitmask_shift_plus): Match lowered form of lshiftrt.
---
  gcc/config/aarch64/aarch64-sve.md  | 119 +++--
  gcc/config/aarch64/aarch64-sve2.md |  46 ---
  2 files changed, 75 insertions(+), 90 deletions(-)


OK, thanks.

It doesn't look like you're listed in MAINTAINERS as having write access.
If that's right, and if you'd like access, please follow the instructions
in https://gcc.gnu.org/gitwrite.html (I'll sponsor).


Committed as 7e0149fdb01b595949a3a6add478b3eed9acf478 and
c637186943b78b6e07e3310e878da922ecdd99f4. Thanks for the reviews!


Richard



diff --git a/gcc/config/aarch64/aarch64-sve.md 
b/gcc/config/aarch64/aarch64-sve.md
index bf7569f932b..e1ec778b10d 100644
--- a/gcc/config/aarch64/aarch64-sve.md
+++ b/gcc/config/aarch64/aarch64-sve.md
@@ -4234,80 +4234,57 @@
  (define_expand "@aarch64_adr_shift"
[(set (match_operand:SVE_FULL_SDI 0 "register_operand")
   (plus:SVE_FULL_SDI
-   (unspec:SVE_FULL_SDI
- [(match_dup 4)
-  (ashift:SVE_FULL_SDI
-(match_operand:SVE_FULL_SDI 2 "register_operand")
-(match_operand:SVE_FULL_SDI 3 "const_1_to_3_operand"))]
- UNSPEC_PRED_X)
+   (ashift:SVE_FULL_SDI
+ (match_operand:SVE_FULL_SDI 2 "register_operand")
+ (match_operand:SVE_FULL_SDI 3 "const_1_to_3_operand"))
 (match_operand:SVE_FULL_SDI 1 "register_operand")))]
"TARGET_SVE && TARGET_NON_STREAMING"
-  {
-operands[4] = CONSTM1_RTX (mode);
-  }
  )

-(define_insn_and_rewrite "*aarch64_adr_shift"
+(define_insn "*aarch64_adr_shift"
[(set (match_operand:SVE_24I 0 "register_operand" "=w")
   (plus:SVE_24I
-   (unspec:SVE_24I
- [(match_operand 4)
-  (ashift:SVE_24I
-(match_operand:SVE_24I 2 "register_operand" "w")
-(match_operand:SVE_24I 3 "const_1_to_3_operand"))]
- UNSPEC_PRED_X)
+   (ashift:SVE_24I
+ (match_operand:SVE_24I 2 "register_operand" "w")
+ (match_operand:SVE_24I 3 "const_1_to_3_operand"))
 (match_operand:SVE_24I 1 "register_operand" "w")))]
"TARGET_SVE && TARGET_NON_STREAMING"
"adr\t%0., [%1., %2., lsl %3]"
-  "&& !CONSTANT_P (operands[4])"
-  {
-operands[4] = CONSTM1_RTX (mode);
-  }
  )

  ;; Same, but with the index being sign-extended from the low 32 bits.
  (define_insn_and_rewrite "*aarch64_adr_shift_sxtw"
[(set (match_operand:VNx2DI 0 "register_operand" "=w")
   (plus:VNx2DI
-   (unspec:VNx2DI
- [(match_operand 4)
-  (ashift:VNx2DI
-(unspec:VNx2DI
-  [(match_operand 5)
-   (sign_extend:VNx2DI
- (truncate:VNx2SI
-   (match_operand:VNx2DI 2 "register_operand" "w")))]
-  UNSPEC_PRED_X)
-(match_operand:VNx2DI 3 "const_1_to_3_operand"))]
- UNSPEC_PRED_X)
+   (ashift:VNx2DI
+ (unspec:VNx2DI
+   [(match_operand 4)
+(sign_extend:VNx2DI
+  (truncate:VNx2SI
+(match_operand:VNx2DI 2 "register_operand" "w")))]
+  UNSPEC_PRED_X)
+ (match_operand:VNx2DI 3 "const_1_to_3_operand"))
 (match_operand:VNx2DI 1 "register_operand" "w")))]
"TARGET_SVE && TARGET_NON_STREAMING"
"adr\t%0.d, [%1.d, %2.d, sxtw %3]"
-  "&& (!CONSTANT_P (operands[4]) || !CONSTANT_P (operands[5]))"
+  "&& !CONSTANT_P (operands[4])"
{
-operands[5] = operands[4] = CONSTM1_RTX (VNx2BImode);
+operands[4] = CONSTM1_RTX (VNx2BImode);
}
  )

  ;; Same, but with the index being zero-extended

Re: [PATCH] rtl-ssa: Reject non-address uses of autoinc regs [PR120347]

[Richard Biener]

On Thu, May 22, 2025 at 12:19 PM Richard Sandiford
 wrote:
>
> As the rtl.texi documentation of RTX_AUTOINC expressions says:
>
>   If a register used as the operand of these expressions is used in
>   another address in an insn, the original value of the register is
>   used.  Uses of the register outside of an address are not permitted
>   within the same insn as a use in an embedded side effect expression
>   because such insns behave differently on different machines and hence
>   must be treated as ambiguous and disallowed.
>
> late-combine was failing to follow this rule.  One option would have
> been to enforce it during the substitution phase, like combine does.
> This could either be a dedicated condition in the substitution code
> or, more generally, an extra condition in can_merge_accesses.
> (The latter would include extending is_pre_post_modify to uses.)
>
> However, since the restriction applies to patterns rather than to
> actions on patterns, the more robust fix seemed to be test and reject
> this case in (a subroutine of) rtl_ssa::recog.  We already do something
> similar for hard-coded register clobbers.
>
> Using vec_rtx_properties isn't the lightest-weight operation
> out there.  I did wonder about relying on the is_pre_post_modify
> flag of the definitions in the new_defs array, but that would
> require callers that create new autoincs to set the flag before
> calling recog.  Normally these flags are instead updated
> automatically based on the final pattern.
>
> Besides, recog itself has had to traverse the whole pattern,
> and it is even less light-weight than vec_rtx_properties.
> At least the pattern should be in cache.
>
> Tested on arm-linux-gnueabihf, aarch64-linux-gnu and
> x86_64-linux-gnu.  OK for trunk and backports?

LGTM, note the 14 branch is currently frozen.

> Richard
>
>
> gcc/
> PR rtl-optimization/120347
> * rtl-ssa/changes.cc (recog_level2): Check whether an
> RTX_AUTOINCed register also appears outside of an address.
>
> gcc/testsuite/
> PR rtl-optimization/120347
> * gcc.dg/torture/pr120347.c: New test.
> ---
>  gcc/rtl-ssa/changes.cc  | 18 ++
>  gcc/testsuite/gcc.dg/torture/pr120347.c | 13 +
>  2 files changed, 31 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.dg/torture/pr120347.c
>
> diff --git a/gcc/rtl-ssa/changes.cc b/gcc/rtl-ssa/changes.cc
> index eb579ad3ad7..f7aa6a66cdf 100644
> --- a/gcc/rtl-ssa/changes.cc
> +++ b/gcc/rtl-ssa/changes.cc
> @@ -1106,6 +1106,24 @@ recog_level2 (insn_change &change, 
> add_regno_clobber_fn add_regno_clobber)
> }
> }
>
> +  // Per rtl.texi, registers that are modified using RTX_AUTOINC operations
> +  // cannot also appear outside an address.
> +  vec_rtx_properties properties;
> +  properties.add_pattern (pat);
> +  for (rtx_obj_reference def : properties.refs ())
> +if (def.is_pre_post_modify ())
> +  for (rtx_obj_reference use : properties.refs ())
> +   if (def.regno == use.regno && !use.in_address ())
> + {
> +   if (dump_file && (dump_flags & TDF_DETAILS))
> + {
> +   fprintf (dump_file, "register %d is both auto-modified"
> +" and used outside an address:\n", def.regno);
> +   print_rtl_single (dump_file, pat);
> + }
> +   return false;
> + }
> +
>// check_asm_operands checks the constraints after RA, so we don't
>// need to do it again.
>if (reload_completed && !asm_p)
> diff --git a/gcc/testsuite/gcc.dg/torture/pr120347.c 
> b/gcc/testsuite/gcc.dg/torture/pr120347.c
> new file mode 100644
> index 000..a2d187bbc5c
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/torture/pr120347.c
> @@ -0,0 +1,13 @@
> +/* { dg-do assemble } */
> +/* { dg-additional-options "-march=armv7-a -mthumb" { target { 
> arm_arch_v7a_ok && arm_thumb2_ok } } } */
> +
> +void *end;
> +void **start;
> +void main(void)
> +{
> +  for (; end; start++) {
> +if (*start)
> +  return;
> +*start = start;
> +  }
> +}
> --
> 2.43.0
>

Re: [PATCH v1 0/3] RISC-V: Combine vec_duplicate + vor.vv to vor.vx on GR2VR cost

[Robin Dapp]

This patch would like to introduce the combine of vec_dup + vor.vv into
vor.vx on the cost value of GR2VR.  The late-combine will take place if
the cost of GR2VR is zero, or reject the combine if non-zero like 1, 15
in test.  There will be two cases for the combine:


OK, thanks.

--
Regards
Robin

Re: [PATCH v2] libstdc++: Implement C++26 std::indirect [PR119152]

[Jonathan Wakely]

On 22/05/25 14:50 +0200, Tomasz Kamiński wrote:

From: Jonathan Wakely 

This papers implements C++26 std::indirect as specified
in P3019 with amendment to move assignment from LWG 4251.

PR libstdc++/119152

libstdc++-v3/ChangeLog:

* include/Makefile.am: Add new header.
* include/Makefile.in: Regenerate.
* include/bits/indirect.h: New file.
* include/bits/version.def (indirect): Define.
* include/bits/version.h: Regenerate.
* include/std/memory: Include new header.
* testsuite/std/memory/indirect/copy.cc
* testsuite/std/memory/indirect/copy_alloc.cc
* testsuite/std/memory/indirect/ctor.cc
* testsuite/std/memory/indirect/incomplete.cc
* testsuite/std/memory/indirect/invalid_neg.cc
* testsuite/std/memory/indirect/move.cc
* testsuite/std/memory/indirect/move_alloc.cc
* testsuite/std/memory/indirect/relops.cc

Co-authored-by: Tomasz Kamiński 
Signed-off-by: Tomasz Kamiński 
---
Changes in v2:
- Fixed typos in commit messages as pointed by Jakub
- Removed stray comment in indirect.h header as pointed out by Daniel

libstdc++-v3/include/Makefile.am  |   1 +
libstdc++-v3/include/Makefile.in  |   1 +
libstdc++-v3/include/bits/indirect.h  | 459 ++
libstdc++-v3/include/bits/version.def |   9 +
libstdc++-v3/include/bits/version.h   |  10 +
libstdc++-v3/include/std/memory   |   5 +
.../testsuite/std/memory/indirect/copy.cc | 121 +
.../std/memory/indirect/copy_alloc.cc | 228 +
.../testsuite/std/memory/indirect/ctor.cc | 203 
.../std/memory/indirect/incomplete.cc |  38 ++
.../std/memory/indirect/invalid_neg.cc|  28 ++
.../testsuite/std/memory/indirect/move.cc | 144 ++
.../std/memory/indirect/move_alloc.cc | 296 +++
.../testsuite/std/memory/indirect/relops.cc   |  82 
14 files changed, 1625 insertions(+)
create mode 100644 libstdc++-v3/include/bits/indirect.h
create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/copy.cc
create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/copy_alloc.cc
create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/ctor.cc
create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/incomplete.cc
create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/invalid_neg.cc
create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/move.cc
create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/move_alloc.cc
create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/relops.cc

diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 3e5b6c4142e..b67d470c27e 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -210,6 +210,7 @@ bits_headers = \
${bits_srcdir}/gslice_array.h \
${bits_srcdir}/hashtable.h \
${bits_srcdir}/hashtable_policy.h \
+   ${bits_srcdir}/indirect.h \
${bits_srcdir}/indirect_array.h \
${bits_srcdir}/ios_base.h \
${bits_srcdir}/istream.tcc \
diff --git a/libstdc++-v3/include/Makefile.in b/libstdc++-v3/include/Makefile.in
index 3531162b5f7..6f7f2be68fd 100644
--- a/libstdc++-v3/include/Makefile.in
+++ b/libstdc++-v3/include/Makefile.in
@@ -563,6 +563,7 @@ bits_freestanding = \
@GLIBCXX_HOSTED_TRUE@   ${bits_srcdir}/gslice_array.h \
@GLIBCXX_HOSTED_TRUE@   ${bits_srcdir}/hashtable.h \
@GLIBCXX_HOSTED_TRUE@   ${bits_srcdir}/hashtable_policy.h \
+@GLIBCXX_HOSTED_TRUE@  ${bits_srcdir}/indirect.h \
@GLIBCXX_HOSTED_TRUE@   ${bits_srcdir}/indirect_array.h \
@GLIBCXX_HOSTED_TRUE@   ${bits_srcdir}/ios_base.h \
@GLIBCXX_HOSTED_TRUE@   ${bits_srcdir}/istream.tcc \
diff --git a/libstdc++-v3/include/bits/indirect.h 
b/libstdc++-v3/include/bits/indirect.h
new file mode 100644
index 000..3fd9807a8fd
--- /dev/null
+++ b/libstdc++-v3/include/bits/indirect.h
@@ -0,0 +1,459 @@
+// Vocabulary Types for Composite Class Design -*- C++ -*-
+
+// Copyright The GNU Toolchain Authors.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exception along with this program;
+// see the files

[Patch] OpenMP/C++: Avoid ICE for BIND_EXPR with empty BIND_EXPR_BLOCK [PR120413]

[Tobias Burnus]

This fixes a GCC 12-to-16 Regression related to an
unexpected empty BIND_EXPR_BLOCK, where nonetheless
aBIND_EXPR exists - just by not walking the hence non-existing variables 
binding to that block.
Any comments before I commit this to mainline? I also intent to backport 
it relatively soonish to GCC 15, but also GCC 14 (14.4 or still 14.3 ?) 
seems to be useful target.


* * *

The issue reminds me a bit of r15-4104-ga8caeaacf499d5 where
in a some fancy way a TREE_USED is created but all what was
left was a DECL_EXPR in the BIND_EXPR_BODY and no statement
list. [Otherwise, a completely different code path.]

Here, the situation is a bit similar: GCC generates also a
BIND_EXPR - but the BIND_EXPR_BLOCK is empty, which the prexisting
code also did not handle. - Contrary to the not-quite used
variable in the previous issue, the constructor might actually
do something observable (but doesn't in this case).
Tobias
OpenMP/C++: Avoid ICE for BIND_EXPR with empty BIND_EXPR_BLOCK [PR120413]

	PR c++/120413

gcc/cp/ChangeLog:

	* semantics.cc (finish_omp_target_clauses_r): Handle
	BIND_EXPR with empty BIND_EXPR_BLOCK.

gcc/testsuite/ChangeLog:

	* g++.dg/gomp/target-4.C: New test.

 gcc/cp/semantics.cc  |  7 ---
 gcc/testsuite/g++.dg/gomp/target-4.C | 22 ++
 2 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 43a0eabfa12..8651009a43f 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -10566,9 +10566,10 @@ finish_omp_target_clauses_r (tree *tp, int *walk_subtrees, void *ptr)
   if (TREE_CODE (t) == BIND_EXPR)
 {
   tree block = BIND_EXPR_BLOCK (t);
-  for (tree var = BLOCK_VARS (block); var; var = DECL_CHAIN (var))
-	if (!data->local_decls.contains (var))
-	  data->local_decls.add (var);
+  if (block)
+	for (tree var = BLOCK_VARS (block); var; var = DECL_CHAIN (var))
+	  if (!data->local_decls.contains (var))
+	data->local_decls.add (var);
   return NULL_TREE;
 }
 
diff --git a/gcc/testsuite/g++.dg/gomp/target-4.C b/gcc/testsuite/g++.dg/gomp/target-4.C
new file mode 100644
index 000..80fc9dfe936
--- /dev/null
+++ b/gcc/testsuite/g++.dg/gomp/target-4.C
@@ -0,0 +1,22 @@
+// { dg-do compile { target c++11 } }
+// PR c++/120413
+
+struct S
+{
+  S() {}
+  ~S() {}
+};
+
+struct array
+{
+  S _arr[1];
+};
+
+int main()
+{
+#pragma omp target
+  {
+array arr{};
+  }
+  return 0;
+}

Re: [Patch] OpenMP/C++: Avoid ICE for BIND_EXPR with empty BIND_EXPR_BLOCK [PR120413]

[Jakub Jelinek]

On Fri, May 23, 2025 at 11:10:46AM +0200, Tobias Burnus wrote:
> OpenMP/C++: Avoid ICE for BIND_EXPR with empty BIND_EXPR_BLOCK [PR120413]
> 
>   PR c++/120413
> 
> gcc/cp/ChangeLog:
> 
>   * semantics.cc (finish_omp_target_clauses_r): Handle
>   BIND_EXPR with empty BIND_EXPR_BLOCK.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/gomp/target-4.C: New test.
> 
>  gcc/cp/semantics.cc  |  7 ---
>  gcc/testsuite/g++.dg/gomp/target-4.C | 22 ++
>  2 files changed, 26 insertions(+), 3 deletions(-)
> 
> diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
> index 43a0eabfa12..8651009a43f 100644
> --- a/gcc/cp/semantics.cc
> +++ b/gcc/cp/semantics.cc
> @@ -10566,9 +10566,10 @@ finish_omp_target_clauses_r (tree *tp, int 
> *walk_subtrees, void *ptr)
>if (TREE_CODE (t) == BIND_EXPR)
>  {
>tree block = BIND_EXPR_BLOCK (t);
> -  for (tree var = BLOCK_VARS (block); var; var = DECL_CHAIN (var))
> - if (!data->local_decls.contains (var))
> -   data->local_decls.add (var);
> +  if (block)
> + for (tree var = BLOCK_VARS (block); var; var = DECL_CHAIN (var))
> +   if (!data->local_decls.contains (var))
> + data->local_decls.add (var);
>return NULL_TREE;
>  }

There is also BIND_EXPR_VARS, dunno if that should be walked instead or
in addition.
Anyway, from formatting POV, it would be nicer to do
  if (TREE_CODE (t) == BIND_EXPR)
{
  if (tree block = BIND_EXPR_BLOCK (t))
for (tree var = BLOCK_VARS (block); var; var = DECL_CHAIN (var))
  if (!data->local_decls.contains (var))
data->local_decls.add (var);
  return NULL_TREE;
}

Jakub

[committed] libgomp.c-c++-common/metadirective-1.c: Expect 'error:' for nvptx compile [PR118694]

[Tobias Burnus]

Committed as r16-838-gb3d07ec7ac2ccd. When adding the testcase
originally in r15-6963-gfdeceba59bee60 seemingly the compile-time
FAIL when nvptx offload compilation is enabled was missed.

That's now fixed by using an effective target, avoiding the FAIL.

That there is an issue with such code was known, cf. PR118694.
However, it looks as if there is no good way to fix this as long
as it depends on knowledge available only at runtime as 'target'
is executed differently when there is a 'teams' available from
when it isn't.

Tobias

PS: I intent to cherry-pick this to GCC 15 shortly.

Re: [PATCH] match: Undo maybe_push_res_to_seq in some cases [PR120331]

[Richard Biener]

On Thu, May 22, 2025 at 3:11 AM Jeff Law  wrote:
>
>
>
> On 5/18/25 10:38 AM, Andrew Pinski wrote:
> > While working on improving forwprop and removal of
> > forward_propagate_into_gimple_cond/forward_propagate_into_comparison,
> > I came cross a case where we end up with SSA_NAME in the resulting
> > gimple_match_op and one statement in the sequence.  This was the result
> > of simplification of:
> > ```
> > _3 = MIN_EXPR  > 16
> > if (_3 > 16) ...
> > ```
> >
> > Which simplifies down to:
> > (maxlen_2(D) > 16) & (264 > 16)
> > into
> > (maxlen_2(D) > 16) & 1
> >
> > Which `maxlen_2(D) > 16` gets pushed onto the sequence
> > and then the & 1 is removed via the match pattern:
> > ```
> > /* x & ~0 -> x  */
> > (simplify
> >   (bit_and @0 integer_all_onesp)
> >(non_lvalue @0))
> > ```
> >
> > So what this patch does is to undo the push extracting the new op
> > from the pushed statement and remove the sequence as it is not used
> > any more.
> >
> > Bootstrapped and tested on x86_64-linux-gnu.
> >
> > gcc/ChangeLog:
> >
> >   PR tree-optimization/120331
> >   * gimple-match-exports.cc (maybe_undo_push): New function.
> >   (gimple_simplify): Call maybe_undo_push if resimplify was successfull.
> OK, but this isn't my strongest area.  So give Richi until Monday AM to
> chime in if he's got concerns.

It's a bit ugly and IMO it should be in-line at the single user and have an
explaining comment why we still might see such cases.  I'll note that
this does not help when match recursively applies simplifications or when
'seq' is passed as NULL.  So addressing this in the genmatch generated
code directly would be superior (but IIRC what the bug said this isn't
possible?)

Richard.

> Thanks,
> jeff
>

Re: [committed] c: Document C23 implementation-defined behavior

[Rainer Orth]

Hi Joseph,

> Add references to C23 subclauses to the documentation of
> implementation-defined behavior, and new entries for
> implementation-defined behavior new in C23; change some references in
> the text to e.g. "C99 and C11" to encompass C23 as well.
>
> Tested with "make info html pdf".
>
>   * doc/implement-c.texi: Document C23 implementation-defined
>   behavior.
>   (Constant expressions implementation, Types implementation): New
>   nodes.

this patch broke bootstrap on Ubuntu 20.04 (which bundles makeinfo 6.7)
and elsewhere with a local installation of makeinfo 6.6:

gcc/doc/implement-c.texi:5: node `C Implementation' lacks menu item for 
`Constant expressions implementation' despite being its Up target
gcc/doc/implement-c.texi:5: node `C Implementation' lacks menu item for `Types 
implementation' despite being its Up target

Fixed as follows.  Ok for trunk?

Rainer

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


2025-05-23  Rainer Orth  

gcc:
* doc/implement-c.texi (C Implementation): Add missing menu items.

diff --git a/gcc/doc/implement-c.texi b/gcc/doc/implement-c.texi
--- a/gcc/doc/implement-c.texi
+++ b/gcc/doc/implement-c.texi
@@ -30,10 +30,12 @@ a freestanding environment); refer to th
 * Characters implementation::
 * Integers implementation::
 * Floating point implementation::
+* Constant expressions implementation::
 * Arrays and pointers implementation::
 * Hints implementation::
 * Structures unions enumerations and bit-fields implementation::
 * Qualifiers implementation::
+* Types implementation::
 * Declarators implementation::
 * Statements implementation::
 * Preprocessing directives implementation::

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

[Xi Ruoyao]

On Fri, 2025-03-07 at 14:14 +0800, Lulu Cheng wrote:
> By default, vectorization is not enabled on LoongArch,
> resulting in the failure of these two test cases.

Hmm, but wouldn't every test in the vect/ directory automatically get -
mlsx (from DEFAULT_VECTCFLAGS in lib/target-supports.exp)?

> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.dg/vect/pr112325.c: Add the vector compilation
>   option '-mlsx' for LoongArch.
>   * gcc.dg/vect/pr117888-1.c: Likewise.
> 
> ---
>  gcc/testsuite/gcc.dg/vect/pr112325.c   | 1 +
>  gcc/testsuite/gcc.dg/vect/pr117888-1.c | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/gcc/testsuite/gcc.dg/vect/pr112325.c
> b/gcc/testsuite/gcc.dg/vect/pr112325.c
> index 143903beab2..8689fbfe092 100644
> --- a/gcc/testsuite/gcc.dg/vect/pr112325.c
> +++ b/gcc/testsuite/gcc.dg/vect/pr112325.c
> @@ -4,6 +4,7 @@
>  /* { dg-require-effective-target vect_shift } */
>  /* { dg-additional-options "-mavx2" { target x86_64-*-* i?86-*-* } }
> */
>  /* { dg-additional-options "--param max-completely-peeled-insns=200"
> { target powerpc64*-*-* } } */
> +/* { dg-additional-options "-mlsx" { target loongarch64-*-* } } */
>  
>  typedef unsigned short ggml_fp16_t;
>  static float table_f32_f16[1 << 16];
> diff --git a/gcc/testsuite/gcc.dg/vect/pr117888-1.c
> b/gcc/testsuite/gcc.dg/vect/pr117888-1.c
> index 4796a7c83c1..0b31fcdc423 100644
> --- a/gcc/testsuite/gcc.dg/vect/pr117888-1.c
> +++ b/gcc/testsuite/gcc.dg/vect/pr117888-1.c
> @@ -4,6 +4,7 @@
>  /* { dg-require-effective-target vect_shift } */
>  /* { dg-additional-options "-mavx2" { target x86_64-*-* i?86-*-* } }
> */
>  /* { dg-additional-options "--param max-completely-peeled-insns=200"
> { target powerpc64*-*-* } } */
> +/* { dg-additional-options "-mlsx" { target loongarch64-*-* } } */
>  
>  typedef unsigned short ggml_fp16_t;
>  static float table_f32_f16[1 << 16];

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

[wwwdocs] Add notes about C++20 iterator concepts and std::vector

[Jonathan Wakely]

---

Pushed to wwwdocs.

 htdocs/gcc-14/porting_to.html | 10 ++
 htdocs/gcc-15/porting_to.html | 61 +++
 2 files changed, 71 insertions(+)

diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
index 2d8eaf3a..e8c2869b 100644
--- a/htdocs/gcc-14/porting_to.html
+++ b/htdocs/gcc-14/porting_to.html
@@ -561,6 +561,16 @@ needs to be performed in a new user-defined macro.
   arithmetic support of these types instead of
   __FLT16_MAX__(or other similar Macros).
 
+C++20 iterator support in 
std::vector
+
+In GCC 14.3 std::vector has been extended so that
+the vector(InputIterator, InputIterator) constructor recognizes
+iterators that satisfy the C++20 iterator concepts, such as
+std::random_access_iterator.
+See Porting to GCC 15 for some caveats
+regarding compatibility with C++17-style iterators, and how to fix them.
+
+
 
 
 
diff --git a/htdocs/gcc-15/porting_to.html b/htdocs/gcc-15/porting_to.html
index db540a9f..74de44f2 100644
--- a/htdocs/gcc-15/porting_to.html
+++ b/htdocs/gcc-15/porting_to.html
@@ -173,6 +173,67 @@ Most uses of  can be adjusted 
to use
 can use  and/or .
 
 
+C++20 iterator support in 
std::vector
+
+In GCC 15.1 (and GCC 14.3) std::vector has been extended so that
+the vector(InputIterator, InputIterator) constructor recognizes
+iterators that satisfy the C++20 iterator concepts, such as
+std::random_access_iterator. This can give significant performance
+improvements for some types of iterator which satisfy the new C++20 concepts
+but which were only considered to be a Cpp17InputIterator under the
+rules of C++17 (and earlier standards). However, it can also cause problems
+for iterator adaptors or iterator facades implemented as templates that wrap
+another iterator class.
+
+
+If an adaptor template declares all the possible operators supported for any
+iterator category (e.g. operator--, operator+,
+operator[], etc.) but does not constrain those operators to only
+be present when the wrapped iterator supports them, then the C++20 standard
+library will incorrectly deduce that the adaptor satisfies the new C++20
+iterator concepts. This means the library might attempt to use
+operator-- on a non-bidirectional iterator,
+or operator[] on a non-random access iterator, resulting in
+compilation errors.
+
+
+Code which encounters these errors should be fixed by constraining the iterator
+adaptors using concepts (or std::enable_if) so that the operator
+functions don't appear to be usable unless they will actually compile.
+For example, the following additions could be used to prevent
+IteratorAdaptor from looking like it supports
+operator--, operator[], and operator-
+when Iter doesn't support those:
+
+template
+class IteratorAdaptor
+{
+  Iter m_iter; // The underlying iterator that is being adapted.
+
+public:
+  // ...
+
+  IteratorAdaptor& operator--()
+#ifdef __cpp_lib_ranges
+  requires std::bidirectional_iterator
+#endif
+  { --m_iter; return *this; }
+
+  reference operator[](difference_type n) const
+#ifdef __cpp_lib_ranges
+  requires std::random_access_iterator
+#endif
+  { return m_iter[n]; }
+
+  friend difference_type operator-(const IteratorAdaptor& lhs, const 
IteratorAdaptor& rhs)
+#ifdef __cpp_lib_ranges
+  requires std::sized_sentinel_for
+#endif
+  { return lhs.m_iter - rhs.m_iter; }
+};
+
+
+
 
 
 
-- 
2.49.0

[PATCH] Add anchor to new link to GCC 15 notes

[Jonathan Wakely]

---

Jakub poined out I'd forgotten the #cxx20-iterators on the new link.
And I've just realised it's a fragment not an anchor, so the commit
message is wrong, oops.

Pushed to wwwdocs.

 htdocs/gcc-14/porting_to.html | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
index e8c2869b..004da7a5 100644
--- a/htdocs/gcc-14/porting_to.html
+++ b/htdocs/gcc-14/porting_to.html
@@ -567,8 +567,9 @@ In GCC 14.3 std::vector has been extended so 
that
 the vector(InputIterator, InputIterator) constructor recognizes
 iterators that satisfy the C++20 iterator concepts, such as
 std::random_access_iterator.
-See Porting to GCC 15 for some caveats
-regarding compatibility with C++17-style iterators, and how to fix them.
+See Porting to GCC 15
+for some caveats regarding compatibility with C++17-style iterators,
+and how to fix them.
 
 
 
-- 
2.49.0

[PATCH] Conditionalize libgdiagnostic processing on presence

[Richard Biener]

The following makes update_web_docs_git work on branches without
libgdiagnostic.

I'm re-running update_web_docs_git with this, OK if it succeeds now?

Thanks,
Richard.

maintainer_scripts/
* update_web_docs_git: Conditionalize libgdiagnostic processing
on presence.
---
 maintainer-scripts/update_web_docs_git | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/maintainer-scripts/update_web_docs_git 
b/maintainer-scripts/update_web_docs_git
index 424808847b6..c779e761e85 100755
--- a/maintainer-scripts/update_web_docs_git
+++ b/maintainer-scripts/update_web_docs_git
@@ -242,11 +242,13 @@ popd
 cp -a gcc/gcc/jit/docs/_build/html jit
 mkdir -p $DOCSDIR/jit
 
-pushd gcc/gcc/doc/libgdiagnostics
-make html SPHINXBUILD=$SPHINX_VENV/bin/sphinx-build || true
-popd
-cp -a gcc/gcc/doc/libgdiagnostics/_build/html libgdiagnostics
-mkdir -p $DOCSDIR/libgdiagnostics
+if test -d gcc/gcc/doc/libgdiagnostics; then
+  pushd gcc/gcc/doc/libgdiagnostics
+  make html SPHINXBUILD=$SPHINX_VENV/bin/sphinx-build || true
+  popd
+  cp -a gcc/gcc/doc/libgdiagnostics/_build/html libgdiagnostics
+  mkdir -p $DOCSDIR/libgdiagnostics
+fi
 
 # Work around makeinfo generated file names and references with
 # "_002d" instead of "-".
-- 
2.43.0

Re: [PATCH] Conditionalize libgdiagnostic processing on presence

[Richard Biener]

On Fri, 23 May 2025, Richard Biener wrote:

> The following makes update_web_docs_git work on branches without
> libgdiagnostic.
> 
> I'm re-running update_web_docs_git with this, OK if it succeeds now?

One more bit, the find command also fails.

OK?
Richard.

>From 97b55be8f9bb5d822371e463dff3bbe64e1fe6f9 Mon Sep 17 00:00:00 2001
From: Richard Biener 
Date: Fri, 23 May 2025 13:32:47 +0200
Subject: [PATCH] Conditionalize libgdiagnostic processing on presence
To: gcc-patches@gcc.gnu.org

The following makes update_web_docs_git work on branches without
libgdiagnostic.

maintainer_scripts/
* update_web_docs_git: Conditionalize libgdiagnostic processing
on presence.
---
 maintainer-scripts/update_web_docs_git | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/maintainer-scripts/update_web_docs_git 
b/maintainer-scripts/update_web_docs_git
index 424808847b6..00334ddac7d 100755
--- a/maintainer-scripts/update_web_docs_git
+++ b/maintainer-scripts/update_web_docs_git
@@ -242,11 +242,15 @@ popd
 cp -a gcc/gcc/jit/docs/_build/html jit
 mkdir -p $DOCSDIR/jit
 
-pushd gcc/gcc/doc/libgdiagnostics
-make html SPHINXBUILD=$SPHINX_VENV/bin/sphinx-build || true
-popd
-cp -a gcc/gcc/doc/libgdiagnostics/_build/html libgdiagnostics
-mkdir -p $DOCSDIR/libgdiagnostics
+LIBGDIAGNOSTICS=
+if test -d gcc/gcc/doc/libgdiagnostics; then
+  pushd gcc/gcc/doc/libgdiagnostics
+  make html SPHINXBUILD=$SPHINX_VENV/bin/sphinx-build || true
+  popd
+  cp -a gcc/gcc/doc/libgdiagnostics/_build/html libgdiagnostics
+  mkdir -p $DOCSDIR/libgdiagnostics
+  LIBGDIAGNOSTICS=libgdiagnostics
+fi
 
 # Work around makeinfo generated file names and references with
 # "_002d" instead of "-".
@@ -298,7 +302,7 @@ done
 # below them, and with some non-HTML files (.png images from us,
 # plus .css and .js supplied by sphinx, and source files, renamed
 # from .rst to .txt).
-find jit libgdiagnostics \
+find jit $LIBGDIAGNOSTICS \
 -name "*.html" -o -name "*.png" \
 -o -name "*.css" -o -name "*.js" \
 -o -name "*.txt" |
-- 
2.43.0

Re: [PATCH v6] libstdc++: Implement C++26 function_ref [PR119126]

[Jonathan Wakely]

On 21/05/25 11:07 +0200, Tomasz Kamiński wrote:

This patch implements C++26 function_ref as specified in P0792R14,
with correction for constraints for constructor accepting nontype_t
parameter from LWG 4256.

As function_ref may store a pointer to the const object, __Ptrs::_M_obj is
changed to const void*, so again we do not cast away const from const
objects. To help with necessary casts, a __polyfunc::__cast_to helper is
added, that accepts reference to or target type direclty.

The _Invoker now defines additional call methods used by function_ref:
_S_ptrs() for invoking target passed by reference, and __S_nttp, _S_bind_ptr,
_S_bind_ref for handling constructors accepting nontype_t. The existing
_S_call_storage is changed to thin wrapper, that initialies _Ptrs, and forwards
to _S_call_ptrs.

This reduced the most uses of _Storage::_M_ptr and _Storage::_M_ref,
so this functions was removed, and _Manager uses were adjusted.

Finally we make function_ref available in freestanding mode, as
move_only_function and copyable_function are currently only available in hosted,
so we define _Manager and _Mo_base only if either __glibcxx_move_only_function
or __glibcxx_copyable_function is defined.

PR libstdc++/119126

libstdc++-v3/ChangeLog:

* doc/doxygen/stdheader.cc: Added funcref_impl.h file.
* include/Makefile.am: Added funcref_impl.h file.
* include/Makefile.in: Added funcref_impl.h file.
* include/bits/funcref_impl.h: New file.
* include/bits/funcwrap.h: (_Ptrs::_M_obj): Const-qualify.
(_Storage::_M_ptr, _Storage::_M_ref): Remove.
(__polyfunc::__cast_to) Define.
(_Base_invoker::_S_ptrs, _Base_invoker::_S_nttp)
(_Base_invoker::_S_bind_ptrs, _Base_invoker::_S_bind_ref)
(_Base_invoker::_S_call_ptrs): Define.
(_Base_invoker::_S_call_storage): Foward to _S_call_ptrs.
(_Manager::_S_local, _Manager::_S_ptr): Adjust for _M_obj being
const qualified.
(__polyfunc::_Manager, __polyfunc::_Mo_base): Guard with
__glibcxx_move_only_function || __glibcxx_copyable_function.
(__polyfunc::__skip_first_arg, __polyfunc::__deduce_funcref)
(std::function_ref) [__glibcxx_function_ref]: Define.
* include/bits/utility.h (std::nontype_t, std::nontype)
(__is_nontype_v) [__glibcxx_function_ref]: Define.
* include/bits/version.def: Define function_ref.
* include/bits/version.h: Regenerate.
* include/std/functional: Define __cpp_lib_function_ref.
* src/c++23/std.cc.in (std::nontype_t, std::nontype)
(std::function_ref) [__cpp_lib_function_ref]: Export.
* testsuite/20_util/function_ref/assign.cc: New test.
* testsuite/20_util/function_ref/call.cc: New test.
* testsuite/20_util/function_ref/cons.cc: New test.
* testsuite/20_util/function_ref/cons_neg.cc: New test.
* testsuite/20_util/function_ref/conv.cc: New test.
* testsuite/20_util/function_ref/deduction.cc: New test.
* testsuite/20_util/function_ref/mutation.cc: New test.
---
The patches v5 (posted as v2) and v6 contains only non-functional changes.
v5: Fixed typos and adjust formatting in documentation comments.
v6: Add test for behavior of function_ref if target is mutated.
   I.e. that is have reference sematnics.

OK for trunk?


OK thanks.


libstdc++-v3/doc/doxygen/stdheader.cc |   1 +
libstdc++-v3/include/Makefile.am  |   1 +
libstdc++-v3/include/Makefile.in  |   1 +
libstdc++-v3/include/bits/funcref_impl.h  | 198 +
libstdc++-v3/include/bits/funcwrap.h  | 188 +
libstdc++-v3/include/bits/utility.h   |  17 ++
libstdc++-v3/include/bits/version.def |   8 +
libstdc++-v3/include/bits/version.h   |  10 +
libstdc++-v3/include/std/functional   |   3 +-
libstdc++-v3/src/c++23/std.cc.in  |   7 +
.../testsuite/20_util/function_ref/assign.cc  | 108 
.../testsuite/20_util/function_ref/call.cc| 186 +
.../testsuite/20_util/function_ref/cons.cc| 218 +++
.../20_util/function_ref/cons_neg.cc  |  30 ++
.../testsuite/20_util/function_ref/conv.cc| 259 ++
.../20_util/function_ref/deduction.cc | 103 +++
.../20_util/function_ref/mutation.cc  |  85 ++
17 files changed, 1376 insertions(+), 47 deletions(-)
create mode 100644 libstdc++-v3/include/bits/funcref_impl.h
create mode 100644 libstdc++-v3/testsuite/20_util/function_ref/assign.cc
create mode 100644 libstdc++-v3/testsuite/20_util/function_ref/call.cc
create mode 100644 libstdc++-v3/testsuite/20_util/function_ref/cons.cc
create mode 100644 libstdc++-v3/testsuite/20_util/function_ref/cons_neg.cc
create mode 100644 libstdc++-v3/testsuite/20_util/function_ref/conv.cc
create mode 100644 libstdc++-v3/testsuite/20_util/function_ref/deduction.cc
create mode 100644 libstdc++-v3/testsuite/20_util/function_ref/

GCC 14.3.1 Status Report (2025-05-23)

[Richard Biener]

Status
==

The GCC 14 branch is open again for regression and documentation fixes.


Quality Data


Priority  #   Change from last report
---   ---
P10-   1
P2  603-  15 
P3  133+  23 
P4  216+   4
P5   23
---   ---
Total P1-P3 736+   7
Total   975+  11


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2025-May/246053.html

Re: [PATCH v2 1/1] Add warnings of potentially-uninitialized padding bits

[Christopher Bazley]

Hi Jakub,

On 21/05/2025 14:46, Christopher Bazley wrote:

Hi Jakub,

Thanks for your review.

On 21/05/2025 13:51, Jakub Jelinek wrote:

On Wed, May 21, 2025 at 01:42:01PM +0100, Christopher Bazley wrote:

On 21/05/2025 12:26, Christopher Bazley wrote:

Hi Joseph,

Thanks for reviewing my patch.

On 20/05/2025 18:02, Joseph Myers wrote:

On Tue, 20 May 2025, Christopher Bazley wrote:


+    if (!cleared)
+  {
+    if (complete_p.padded_non_union
+    && warn_zero_init_padding_bits >= 
ZERO_INIT_PADDING_BITS_ALL)

+  {
+    warning (OPT_Wzero_init_padding_bits_,
+ "Padding bits might not be initialized to zero; "
+ "consider using 
%<-fzero-init-padding-bits=all%>");

+  }
+    else if (complete_p.padded_union
+ && warn_zero_init_padding_bits
+    >= ZERO_INIT_PADDING_BITS_UNIONS)
+  {
+    warning (OPT_Wzero_init_padding_bits_,
+ "Padding bits might not be initialized to zero; "
+ "consider using %<-fzero-init-padding-bits=unions%> "
+ "or %<-fzero-init-padding-bits=all%>");

Diagnostics should start with a lowercase letter.

I'll change it to "padding might not be initialized to zero..." OK?

("padding" seems to be more common than "padding bits" in existing
messages.)

Is there anything I need to do for initialization?
Sorry, I meant "internationalisation" (i.e. to support translation), 
not

"initialization"!

For translations I think it is fine as is.
Please avoid {}s around single statements (e.g. the warning call above).


Originally, it was more than one statement to produce information on 
how to initialise padding bits. That information was language (and 
dialect) specific, which wasn't acceptable in the Gimplifier. I'll 
remove the redundant braces.


Fixed in patch v4. OK?


And, I think the warnings should include text like
"if code relies on it being zero, consider"
because telling people to use those options mindlessly is undesirable.


Nobody is going to see these warnings unless they explicitly enable 
them, in which case I hope they would have read the documentation first.


The current text is:

+               warning (OPT_Wzero_init_padding_bits_,
+                        "padding might not be initialized to zero; "
+                        "consider using 
%<-fzero-init-padding-bits=unions%> "

+                        "or %<-fzero-init-padding-bits=all%>");

I can add "if code relies on it being zero," although I don't think 
"consider" is a very strong prescription and I highly doubt whether 
the people reading these warnings will know whether the code they are 
compiling relies on padding being zeroed or not. My presumption was 
that programmers who know their own code intimately won't enable the 
warnings in the first place.


Changed in patch v4. OK?

Thanks,

--
Christopher Bazley
Staff Software Engineer, GNU Tools Team.
Arm Ltd, 110 Fulbourn Road, Cambridge, CB1 9NJ, UK.
http://www.arm.com/

Re: [PATCH] Conditionalize libgdiagnostic processing on presence

[Jakub Jelinek]

On Fri, May 23, 2025 at 01:34:35PM +0200, Richard Biener wrote:
> The following makes update_web_docs_git work on branches without
> libgdiagnostic.
> 
> I'm re-running update_web_docs_git with this, OK if it succeeds now?
> 
> Thanks,
> Richard.
> 
> maintainer_scripts/
>   * update_web_docs_git: Conditionalize libgdiagnostic processing
>   on presence.

LGTM.

> --- a/maintainer-scripts/update_web_docs_git
> +++ b/maintainer-scripts/update_web_docs_git
> @@ -242,11 +242,13 @@ popd
>  cp -a gcc/gcc/jit/docs/_build/html jit
>  mkdir -p $DOCSDIR/jit
>  
> -pushd gcc/gcc/doc/libgdiagnostics
> -make html SPHINXBUILD=$SPHINX_VENV/bin/sphinx-build || true
> -popd
> -cp -a gcc/gcc/doc/libgdiagnostics/_build/html libgdiagnostics
> -mkdir -p $DOCSDIR/libgdiagnostics
> +if test -d gcc/gcc/doc/libgdiagnostics; then
> +  pushd gcc/gcc/doc/libgdiagnostics
> +  make html SPHINXBUILD=$SPHINX_VENV/bin/sphinx-build || true
> +  popd
> +  cp -a gcc/gcc/doc/libgdiagnostics/_build/html libgdiagnostics
> +  mkdir -p $DOCSDIR/libgdiagnostics
> +fi
>  
>  # Work around makeinfo generated file names and references with
>  # "_002d" instead of "-".
> -- 
> 2.43.0

Jakub

Re: [PATCH v2] libstdc++: Implement C++26 std::indirect [PR119152]

[Jonathan Wakely]

On 23/05/25 10:03 +0100, Jonathan Wakely wrote:

On 22/05/25 14:50 +0200, Tomasz Kamiński wrote:

From: Jonathan Wakely 

This papers implements C++26 std::indirect as specified
in P3019 with amendment to move assignment from LWG 4251.

PR libstdc++/119152

libstdc++-v3/ChangeLog:

* include/Makefile.am: Add new header.
* include/Makefile.in: Regenerate.
* include/bits/indirect.h: New file.
* include/bits/version.def (indirect): Define.
* include/bits/version.h: Regenerate.
* include/std/memory: Include new header.
* testsuite/std/memory/indirect/copy.cc
* testsuite/std/memory/indirect/copy_alloc.cc
* testsuite/std/memory/indirect/ctor.cc
* testsuite/std/memory/indirect/incomplete.cc
* testsuite/std/memory/indirect/invalid_neg.cc
* testsuite/std/memory/indirect/move.cc
* testsuite/std/memory/indirect/move_alloc.cc
* testsuite/std/memory/indirect/relops.cc

Co-authored-by: Tomasz Kamiński 
Signed-off-by: Tomasz Kamiński 
---
Changes in v2:
- Fixed typos in commit messages as pointed by Jakub
- Removed stray comment in indirect.h header as pointed out by Daniel

libstdc++-v3/include/Makefile.am  |   1 +
libstdc++-v3/include/Makefile.in  |   1 +
libstdc++-v3/include/bits/indirect.h  | 459 ++
libstdc++-v3/include/bits/version.def |   9 +
libstdc++-v3/include/bits/version.h   |  10 +
libstdc++-v3/include/std/memory   |   5 +
.../testsuite/std/memory/indirect/copy.cc | 121 +
.../std/memory/indirect/copy_alloc.cc | 228 +
.../testsuite/std/memory/indirect/ctor.cc | 203 
.../std/memory/indirect/incomplete.cc |  38 ++
.../std/memory/indirect/invalid_neg.cc|  28 ++
.../testsuite/std/memory/indirect/move.cc | 144 ++
.../std/memory/indirect/move_alloc.cc | 296 +++
.../testsuite/std/memory/indirect/relops.cc   |  82 
14 files changed, 1625 insertions(+)
create mode 100644 libstdc++-v3/include/bits/indirect.h
create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/copy.cc
create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/copy_alloc.cc
create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/ctor.cc
create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/incomplete.cc
create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/invalid_neg.cc
create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/move.cc
create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/move_alloc.cc
create mode 100644 libstdc++-v3/testsuite/std/memory/indirect/relops.cc

diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 3e5b6c4142e..b67d470c27e 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -210,6 +210,7 @@ bits_headers = \
${bits_srcdir}/gslice_array.h \
${bits_srcdir}/hashtable.h \
${bits_srcdir}/hashtable_policy.h \
+   ${bits_srcdir}/indirect.h \
${bits_srcdir}/indirect_array.h \
${bits_srcdir}/ios_base.h \
${bits_srcdir}/istream.tcc \
diff --git a/libstdc++-v3/include/Makefile.in b/libstdc++-v3/include/Makefile.in
index 3531162b5f7..6f7f2be68fd 100644
--- a/libstdc++-v3/include/Makefile.in
+++ b/libstdc++-v3/include/Makefile.in
@@ -563,6 +563,7 @@ bits_freestanding = \
@GLIBCXX_HOSTED_TRUE@   ${bits_srcdir}/gslice_array.h \
@GLIBCXX_HOSTED_TRUE@   ${bits_srcdir}/hashtable.h \
@GLIBCXX_HOSTED_TRUE@   ${bits_srcdir}/hashtable_policy.h \
+@GLIBCXX_HOSTED_TRUE@  ${bits_srcdir}/indirect.h \
@GLIBCXX_HOSTED_TRUE@   ${bits_srcdir}/indirect_array.h \
@GLIBCXX_HOSTED_TRUE@   ${bits_srcdir}/ios_base.h \
@GLIBCXX_HOSTED_TRUE@   ${bits_srcdir}/istream.tcc \
diff --git a/libstdc++-v3/include/bits/indirect.h 
b/libstdc++-v3/include/bits/indirect.h
new file mode 100644
index 000..3fd9807a8fd
--- /dev/null
+++ b/libstdc++-v3/include/bits/indirect.h
@@ -0,0 +1,459 @@
+// Vocabulary Types for Composite Class Design -*- C++ -*-
+
+// Copyright The GNU Toolchain Authors.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exc

Re: [PATCH] Conditionalize libgdiagnostic processing on presence

[Jakub Jelinek]

On Fri, May 23, 2025 at 01:40:20PM +0200, Richard Biener wrote:
> On Fri, 23 May 2025, Richard Biener wrote:
> 
> > The following makes update_web_docs_git work on branches without
> > libgdiagnostic.
> > 
> > I'm re-running update_web_docs_git with this, OK if it succeeds now?
> 
> One more bit, the find command also fails.
> 
> OK?
> Richard.
> 
> >From 97b55be8f9bb5d822371e463dff3bbe64e1fe6f9 Mon Sep 17 00:00:00 2001
> From: Richard Biener 
> Date: Fri, 23 May 2025 13:32:47 +0200
> Subject: [PATCH] Conditionalize libgdiagnostic processing on presence
> To: gcc-patches@gcc.gnu.org
> 
> The following makes update_web_docs_git work on branches without
> libgdiagnostic.
> 
> maintainer_scripts/
>   * update_web_docs_git: Conditionalize libgdiagnostic processing
>   on presence.

Ok.

Jakub

[PATCH 2/2] c-family: switch away from -ffp-contract=fast

[Alexander Monakov]

Unrestricted FMA contraction, combined with optimizations that create
copies of expressions, is causing hard-to-debug issues such as PR106902.
Since we implement conformant contraction now, switch C and C++ from
-ffp-contract=fast to either =off (under -std=c[++]NN like before, also
for C++ now), or =on (under -std=gnu[++]NN).  Keep -ffp-contract=fast
when -funsafe-math-optimizations (or -ffast-math, -Ofast) is active.

In other words,

- -ffast-math: no change, unrestricted contraction like before;
- standards compliant mode for C: no change, no contraction;
- ditto, for C++: align with C (no contraction);
- otherwise, switch C and C++ from -ffp-contract=fast to =on.

gcc/c-family/ChangeLog:

* c-opts.cc (c_common_post_options): Adjust handling of
flag_fp_contract_mode.

gcc/ChangeLog:

* doc/invoke.texi (-ffp-contract): Describe new defaults.
(-funsafe-math-optimizations): Add -ffp-contract=fast.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr81904.c: Add -ffp-contract=fast to flags.
* gcc.target/i386/pr116979.c: Ditto.
* gcc.target/i386/intrinsics_opt-1.c: Ditto.
* gcc.target/i386/part-vect-fmaddsubhf-1.c: Ditto.
* gcc.target/i386/avx512f-vect-fmaddsubXXXps.c: Ditto.
* gcc.target/i386/avx512f-vect-fmaddsubXXXpd.c: Ditto.
---
 gcc/c-family/c-opts.cc| 11 ++-
 gcc/doc/invoke.texi   | 10 ++
 .../gcc.target/i386/avx512f-vect-fmaddsubXXXpd.c  |  2 +-
 .../gcc.target/i386/avx512f-vect-fmaddsubXXXps.c  |  2 +-
 gcc/testsuite/gcc.target/i386/intrinsics_opt-1.c  |  2 +-
 .../gcc.target/i386/part-vect-fmaddsubhf-1.c  |  2 +-
 gcc/testsuite/gcc.target/i386/pr116979.c  |  2 +-
 gcc/testsuite/gcc.target/i386/pr81904.c   |  2 +-
 8 files changed, 14 insertions(+), 19 deletions(-)

diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc
index f1c276f07c..1c921ff717 100644
--- a/gcc/c-family/c-opts.cc
+++ b/gcc/c-family/c-opts.cc
@@ -877,15 +877,8 @@ c_common_post_options (const char **pfilename)
 flag_excess_precision = (flag_iso ? EXCESS_PRECISION_STANDARD
 : EXCESS_PRECISION_FAST);
 
-  /* ISO C restricts floating-point expression contraction to within
- source-language expressions (-ffp-contract=on, currently an alias
- for -ffp-contract=off).  */
-  if (flag_iso
-  && !c_dialect_cxx ()
-  && (OPTION_SET_P (flag_fp_contract_mode)
- == (enum fp_contract_mode) 0)
-  && flag_unsafe_math_optimizations == 0)
-flag_fp_contract_mode = FP_CONTRACT_OFF;
+  if (!flag_unsafe_math_optimizations && !OPTION_SET_P (flag_fp_contract_mode))
+flag_fp_contract_mode = flag_iso ? FP_CONTRACT_OFF : FP_CONTRACT_ON;
 
   /* C language modes before C99 enable -fpermissive by default, but
  only if -pedantic-errors is not specified.  Also treat
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 699ee1cc0b..9cf6343539 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -13004,16 +13004,17 @@ Disabled by default.
 @opindex ffp-contract
 @item -ffp-contract=@var{style}
 @option{-ffp-contract=off} disables floating-point expression contraction.
+This is the default for C and C++ in a standards compliant mode
+(@option{-std=c11}, @option{-std=c++11} or similar).
 @option{-ffp-contract=fast} enables floating-point expression contraction
 such as forming of fused multiply-add operations if the target has
 native support for them.
+This is the default for languages other than C and C++.
 @option{-ffp-contract=on} enables floating-point expression contraction
 if allowed by the language standard.  This is implemented for C and C++,
 where it enables contraction within one expression, but not across
 different statements.
-
-The default is @option{-ffp-contract=off} for C in a standards compliant mode
-(@option{-std=c11} or similar), @option{-ffp-contract=fast} otherwise.
+This is the default when compiling GNU dialects of C or C++.
 
 @opindex fomit-frame-pointer
 @item -fomit-frame-pointer
@@ -15501,7 +15502,8 @@ or ISO rules/specifications for math functions. It may, 
however,
 yield faster code for programs that do not require the guarantees
 of these specifications.
 Enables @option{-fno-signed-zeros}, @option{-fno-trapping-math},
-@option{-fassociative-math} and @option{-freciprocal-math}.
+@option{-fassociative-math}, @option{-freciprocal-math} and
+@option{-ffp-contract=fast}.
 
 The default is @option{-fno-unsafe-math-optimizations}.
 
diff --git a/gcc/testsuite/gcc.target/i386/avx512f-vect-fmaddsubXXXpd.c 
b/gcc/testsuite/gcc.target/i386/avx512f-vect-fmaddsubXXXpd.c
index 734f9e0144..2510d96937 100644
--- a/gcc/testsuite/gcc.target/i386/avx512f-vect-fmaddsubXXXpd.c
+++ b/gcc/testsuite/gcc.target/i386/avx512f-vect-fmaddsubXXXpd.c
@@ -1,6 +1,6 @@
 /* { dg-do run } */
 /* { dg-require-effective-target avx512f } */
-/* { dg-options "-O3 -mfma -save-t

[PATCH 1/2] allow contraction to synthetic single-element vector FMA

[Alexander Monakov]

In PR 105965 we accepted a request to form FMA instructions when the
source code is using a narrow generic vector that contains just one
element, corresponding to V1SF or V1DF mode, while the backend does not
expand fma patterns for such modes.

For this to work under -ffp-contract=on, we either need to modify
backends, or emulate such degenerate-vector FMA via scalar FMA in
tree-vect-generic.  Do the latter.

gcc/c-family/ChangeLog:

* c-gimplify.cc (fma_supported_p): Allow forming single-element
vector FMA when scalar FMA is available.
(c_gimplify_expr): Allow vector types.

gcc/ChangeLog:

* tree-vect-generic.cc (expand_vec1_fma): New helper.  Use it...
(expand_vector_operations_1): ... here to handle IFN_FMA.
---
 gcc/c-family/c-gimplify.cc | 10 ++--
 gcc/tree-vect-generic.cc   | 48 --
 2 files changed, 54 insertions(+), 4 deletions(-)

diff --git a/gcc/c-family/c-gimplify.cc b/gcc/c-family/c-gimplify.cc
index c6fb764656..1942d5019e 100644
--- a/gcc/c-family/c-gimplify.cc
+++ b/gcc/c-family/c-gimplify.cc
@@ -875,7 +875,13 @@ c_build_bind_expr (location_t loc, tree block, tree body)
 static bool
 fma_supported_p (enum internal_fn fn, tree type)
 {
-  return direct_internal_fn_supported_p (fn, type, OPTIMIZE_FOR_BOTH);
+  return (direct_internal_fn_supported_p (fn, type, OPTIMIZE_FOR_BOTH)
+ /* Accept single-element vector FMA (see PR 105965) when the
+backend handles the scalar but not the vector mode.  */
+ || (VECTOR_TYPE_P (type)
+ && known_eq (TYPE_VECTOR_SUBPARTS (type),  1U)
+ && direct_internal_fn_supported_p (fn, TREE_TYPE (type),
+OPTIMIZE_FOR_BOTH)));
 }
 
 /* Gimplification of expression trees.  */
@@ -939,7 +945,7 @@ c_gimplify_expr (tree *expr_p, gimple_seq *pre_p 
ATTRIBUTE_UNUSED,
/* For -ffp-contract=on we need to attempt FMA contraction only
   during initial gimplification.  Late contraction across statement
   boundaries would violate language semantics.  */
-   if (SCALAR_FLOAT_TYPE_P (type)
+   if ((SCALAR_FLOAT_TYPE_P (type) || VECTOR_FLOAT_TYPE_P (type))
&& flag_fp_contract_mode == FP_CONTRACT_ON
&& cfun && !(cfun->curr_properties & PROP_gimple_any)
&& fma_supported_p (IFN_FMA, type))
diff --git a/gcc/tree-vect-generic.cc b/gcc/tree-vect-generic.cc
index 3c68361870..954b84edce 100644
--- a/gcc/tree-vect-generic.cc
+++ b/gcc/tree-vect-generic.cc
@@ -1983,6 +1983,36 @@ expand_vector_conversion (gimple_stmt_iterator *gsi)
   gsi_replace (gsi, g, false);
 }
 
+/* Expand IFN_FMA, assuming vector contains just one scalar.
+   c_gimplify_expr can introduce it when performing FMA contraction.  */
+
+static void
+expand_vec1_fma (gimple_stmt_iterator *gsi)
+{
+  gcall *call = as_a  (gsi_stmt (*gsi));
+  tree type = TREE_TYPE (gimple_call_arg (call, 0));
+  if (!VECTOR_TYPE_P (type))
+return;
+  gcc_assert (known_eq (TYPE_VECTOR_SUBPARTS (type), 1U));
+
+  for (int i = 0; i < 3; i++)
+{
+  tree arg = gimple_call_arg (call, i);
+  arg = gimplify_build1 (gsi, VIEW_CONVERT_EXPR, TREE_TYPE (type), arg);
+  gimple_call_set_arg (call, i, arg);
+}
+  tree lhs = gimple_call_lhs (call);
+  if (lhs)
+{
+  tree new_lhs = make_ssa_name (TREE_TYPE (type));
+  gimple_call_set_lhs (call, new_lhs);
+  tree ctor = build_constructor_single (type, 0, new_lhs);
+  gimple *g = gimple_build_assign (lhs, CONSTRUCTOR, ctor);
+  gsi_insert_after (gsi, g, GSI_NEW_STMT);
+}
+  update_stmt (call);
+}
+
 /* Process one statement.  If we identify a vector operation, expand it.  */
 
 static void
@@ -1998,8 +2028,22 @@ expand_vector_operations_1 (gimple_stmt_iterator *gsi)
   gassign *stmt = dyn_cast  (gsi_stmt (*gsi));
   if (!stmt)
 {
-  if (gimple_call_internal_p (gsi_stmt (*gsi), IFN_VEC_CONVERT))
-   expand_vector_conversion (gsi);
+  gcall *call = dyn_cast  (gsi_stmt (*gsi));
+  if (!call || !gimple_call_internal_p (call))
+   return;
+  switch (gimple_call_internal_fn (call))
+   {
+   case IFN_VEC_CONVERT:
+ return expand_vector_conversion (gsi);
+   case IFN_FMA:
+   case IFN_FMS:
+   case IFN_FNMA:
+   case IFN_FNMS:
+ if (!direct_internal_fn_supported_p (call, OPTIMIZE_FOR_BOTH))
+   return expand_vec1_fma (gsi);
+   default:
+ break;
+   }
   return;
 }
 
-- 
2.49.0

[pushed] c++: drop push_tinst_level in mangling

[Jason Merrill]

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

-- 8< --

I wondered why we needed to push/pop_tinst_level in mangle_decl_string.  And
apparently we don't need to anymore.

gcc/cp/ChangeLog:

* mangle.cc (mangle_decl_string): Don't push_tinst_level.
---
 gcc/cp/mangle.cc | 22 +++---
 1 file changed, 3 insertions(+), 19 deletions(-)

diff --git a/gcc/cp/mangle.cc b/gcc/cp/mangle.cc
index 3d5e96b2c94..13d5dedebd2 100644
--- a/gcc/cp/mangle.cc
+++ b/gcc/cp/mangle.cc
@@ -4452,23 +4452,12 @@ static tree
 mangle_decl_string (const tree decl)
 {
   tree result;
-  tree saved_fn = NULL_TREE;
-  bool template_p = false;
+  tree saved_fn = current_function_decl;
 
   /* We shouldn't be trying to mangle an uninstantiated template.  */
   gcc_assert (!type_dependent_expression_p (decl));
 
-  if (DECL_LANG_SPECIFIC (decl) && DECL_USE_TEMPLATE (decl))
-{
-  struct tinst_level *tl = current_instantiation ();
-  if ((!tl || tl->maybe_get_node () != decl)
- && push_tinst_level (decl))
-   {
- template_p = true;
- saved_fn = current_function_decl;
- current_function_decl = NULL_TREE;
-   }
-}
+  current_function_decl = NULL_TREE;
   iloc_sentinel ils (DECL_SOURCE_LOCATION (decl));
 
   start_mangling (decl);
@@ -4483,12 +4472,7 @@ mangle_decl_string (const tree decl)
 fprintf (stderr, "mangle_decl_string = '%s'\n\n",
 IDENTIFIER_POINTER (result));
 
-  if (template_p)
-{
-  pop_tinst_level ();
-  current_function_decl = saved_fn;
-}
-
+  current_function_decl = saved_fn;
   return result;
 }
 

base-commit: 32396d87b7d92aa2a89f3b2c09f4f1fe373f3ef0
-- 
2.49.0

Re: [PATCH v6 1/3][Middle-end] Provide more contexts for -Warray-bounds, -Wstringop-*warning messages due to code movements from compiler transformation (Part 1) [PR109071,PR85788,PR88771,PR106762,PR1

[Qing Zhao]

Hi, Richard,

Thanks a lot for your comments and questions.
Please see my answers embedded below:

> On May 19, 2025, at 06:44, Richard Biener  wrote:
> 
> On Fri, May 16, 2025 at 3:34 PM Qing Zhao  wrote:
>> 
>> Control this with a new option -fdiagnostics-details.
>> 
>> $ cat t.c
>> extern void warn(void);
>> static inline void assign(int val, int *regs, int *index)
>> {
>>  if (*index >= 4)
>>warn();
>>  *regs = val;
>> }
>> struct nums {int vals[4];};
>> 
>> void sparx5_set (int *ptr, struct nums *sg, int index)
>> {
>>  int *val = &sg->vals[index];
>> 
>>  assign(0,ptr, &index);
>>  assign(*val, ptr, &index);
>> }
>> 
>> $ gcc -Wall -O2  -c -o t.o t.c
>> t.c: In function ‘sparx5_set’:
>> t.c:12:23: warning: array subscript 4 is above array bounds of ‘int[4]’ 
>> [-Warray-bounds=]
>>   12 |   int *val = &sg->vals[index];
>>  |   ^~~
>> t.c:8:18: note: while referencing ‘vals’
>>8 | struct nums {int vals[4];};
>>  |  ^~~~
>> 
>> In the above, Although the warning is correct in theory, the warning message
>> itself is confusing to the end-user since there is information that cannot
>> be connected to the source code directly.
>> 
>> It will be a nice improvement to add more information in the warning message
>> to report where such index value come from.
>> 
>> In order to achieve this, we add a new data structure "move_history" to 
>> record
>> 1. the "condition" that triggers the code movement;
>> 2. whether the code movement is on the true path of the "condition";
>> 3. the "compiler transformation" that triggers the code movement.
>> 
>> Whenever there is a code movement along control flow graph due to some
>> specific transformations, such as jump threading, path isolation, tree
>> sinking, etc., a move_history structure is created and attached to the
>> moved gimple statement.
>> 
>> During array out-of-bound checking or -Wstringop-* warning checking, the
>> "move_history" that was attached to the gimple statement is used to form
>> a sequence of diagnostic events that are added to the corresponding rich
>> location to be used to report the warning message.
>> 
>> This behavior is controled by the new option -fdiagnostics-details
>> which is off by default.
>> 
>> With this change, by adding -fdiagnostics-details,
>> the warning message for the above testing case is now:
>> 
>> $ gcc -Wall -O2 -fdiagnostics-details -c -o t.o t.c
>> t.c: In function ‘sparx5_set’:
>> t.c:12:23: warning: array subscript 4 is above array bounds of ‘int[4]’ 
>> [-Warray-bounds=]
>>   12 |   int *val = &sg->vals[index];
>>  |   ^~~
>>  ‘sparx5_set’: events 1-2
>>4 |   if (*index >= 4)
>>  |  ^
>>  |  |
>>  |  (1) when the condition is evaluated to true
>> ..
>>   12 |   int *val = &sg->vals[index];
>>  |   ~~~
>>  |   |
>>  |   (2) out of array bounds here
>> t.c:8:18: note: while referencing ‘vals’
>>8 | struct nums {int vals[4];};
>>  |  ^~~~
>> 
>> The change was divided into 3 parts:
>> 
>> Part 1: Add new data structure move_history, record move_history during
>>transformation;
>> Part 2: In warning analysis, Use the new move_history to form a rich
>>location with a sequence of events, to report more context info
>>of the warnings.
>> Part 3: Add debugging mechanism for move_history.
> 
> Thanks for working on this.  I'm pasting my review notes on [1/3] below.
> 
> 
> ove histories are allocated from a global obstack - it seems they are
> never released, just the association between stmt and history is
> eventually broken by remove_move_history?

They are supposed to be released by the following routine:

+void
+move_history_finalize (void)
+{
+  if (move_history_map)
+{
+  delete move_history_map;
+  move_history_map = NULL;
+}
+  obstack_free (&move_history_obstack, NULL);
+  return;
+}

Is the above “obstack_free” the proper utility routine that are used to free 
the whole 
memory allocated for the“move_history_obstack”? 

If not, please advise on how to free the obstacle variables.

>  Do you have any statistics
> on the memory usage?
No. 
>  Might be an interesting bit to dump with
> -fmem-report (the size of the obstack).  Likewise the statistics
> on the hash-map are interesting.

Are you suggesting to add the memory usage statistics for both 
“move_history_obstack” and
“move_history_map” to -fmem_report? 
If so, I will study a little bit on how to do this. And then add this part.


> static bool
> +is_move_history_existed (location_t cond_location, bool is_true_path,
> +enum move_reason
> 
> that's a bit of an odd name - 'move_history_exists_p'?  

Okay, will update the name as you suggested.

> What are
> we supposed to do on a duplicate?  This is a linear search - how
> many do we accumulate in practice?  Does it make sense to

Re: [PATCH RFA (diagnostic)] c++: modules and #pragma diagnostic

[Jason Merrill]

On 4/14/25 9:57 AM, Jason Merrill wrote:

On 1/9/25 10:00 PM, Jason Merrill wrote:

Tested x86_64-pc-linux-gnu.  Is the diagnostic.h change OK for trunk?


Ping?


Ping.


-- 8< --

To respect the #pragma diagnostic lines in libstdc++ headers when 
compiling

with module std, we need to represent them in the module.

I think it's reasonable to make module_state a friend of
diagnostic_option_classifier to allow direct access to the data.  This 
is a

different approach from how Jakub made PCH streaming members of
diagnostic_option_classifier, but it seems to me that modules handling
belongs in module.cc.

gcc/ChangeLog:

* diagnostic.h: Add friends.

gcc/cp/ChangeLog:

* module.cc (module_state::write_diagnostic_classification): New.
(module_state::write_begin): Call it.
(module_state::read_diagnostic_classification): New.
(module_state::read_initial): Call it.

gcc/testsuite/ChangeLog:

* g++.dg/modules/warn-spec-3_a.C: New test.
* g++.dg/modules/warn-spec-3_b.C: New test.
---
  gcc/diagnostic.h |  4 +
  gcc/cp/module.cc | 86 +++-
  gcc/testsuite/g++.dg/modules/warn-spec-3_a.C | 20 +
  gcc/testsuite/g++.dg/modules/warn-spec-3_b.C |  8 ++
  4 files changed, 117 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/modules/warn-spec-3_a.C
  create mode 100644 gcc/testsuite/g++.dg/modules/warn-spec-3_b.C

diff --git a/gcc/diagnostic.h b/gcc/diagnostic.h
index 202760b2f85..91bde3ff06c 100644
--- a/gcc/diagnostic.h
+++ b/gcc/diagnostic.h
@@ -299,6 +299,8 @@ private:
    /* For pragma push/pop.  */
    vec m_push_list;
+
+  friend class module_state;
  };
  /* A bundle of options relating to printing the user's source code
@@ -807,6 +809,8 @@ private:
    /* The stack of sets of overridden diagnostic option severities.  */
    diagnostic_option_classifier m_option_classifier;
+  friend class module_state;
+
    /* True if we should print any CWE identifiers associated with
   diagnostics.  */
    bool m_show_cwe;
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 78fb21dc22f..49c9c092163 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -3876,6 +3876,9 @@ class GTY((chain_next ("%h.parent"), for_user)) 
module_state {

    void write_macro_maps (elf_out *to, range_t &, unsigned *crc_ptr);
    bool read_macro_maps (line_map_uint_t);
+  void write_diagnostic_classification (elf_out *, diagnostic_context 
*, unsigned *);

+  bool read_diagnostic_classification (diagnostic_context *);
+
   private:
    void write_define (bytes_out &, const cpp_macro *);
    cpp_macro *read_define (bytes_in &, cpp_reader *) const;
@@ -17637,6 +17640,78 @@ module_state::write_ordinary_maps (elf_out 
*to, range_t &info,

    dump.outdent ();
  }
+/* Write out any #pragma GCC diagnostic info to the .dgc section.  */
+
+void
+module_state::write_diagnostic_classification (elf_out *to,
+   diagnostic_context *dc,
+   unsigned *crc_p)
+{
+  auto &changes = dc->m_option_classifier.m_classification_history;
+
+  dump () && dump ("Writing diagnostic change locations");
+  dump.indent ();
+
+  bytes_out sec (to);
+  if (sec.streaming_p ())
+    sec.begin ();
+
+  unsigned len = changes.length ();
+  dump () && dump ("Diagnostic changes: %u", len);
+  if (sec.streaming_p ())
+    sec.u (len);
+
+  for (const auto &c: changes)
+    {
+  write_location (sec, c.location);
+  if (sec.streaming_p ())
+    {
+  sec.u (c.option);
+  sec.u (c.kind);
+    }
+    }
+
+  if (sec.streaming_p ())
+    sec.end (to, to->name (MOD_SNAME_PFX ".dgc"), crc_p);
+  dump.outdent ();
+}
+
+/* Read any #pragma GCC diagnostic info from the .dgc section.  */
+
+bool
+module_state::read_diagnostic_classification (diagnostic_context *dc)
+{
+  bytes_in sec;
+
+  if (!sec.begin (loc, from (), MOD_SNAME_PFX ".dgc"))
+    return false;
+
+  dump () && dump ("Reading diagnostic change locations");
+  dump.indent ();
+
+  unsigned len = sec.u ();
+  dump () && dump ("Diagnostic changes: %u", len);
+
+  auto &changes = dc->m_option_classifier.m_classification_history;
+  unsigned offset = changes.length ();
+  changes.reserve (len);
+  for (unsigned i = 0; i < len; ++i)
+    {
+  location_t loc = read_location (sec);
+  int opt = sec.u ();
+  diagnostic_t kind = (diagnostic_t) sec.u ();
+  if (kind == DK_POP)
+    opt += offset;
+  changes.quick_push ({ loc, opt, kind });
+    }
+
+  dump.outdent ();
+  if (!sec.end (from ()))
+    return false;
+
+  return true;
+}
+
  void
  module_state::write_macro_maps (elf_out *to, range_t &info, unsigned 
*crc_p)

  {
@@ -19231,6 +19306,8 @@ module_state::write_begin (elf_out *to, 
cpp_reader *reader,

    if (is_header ())
  macros = prepare_macros (reader);
+  write_diagnostic_classification (nullptr, global_dc, nullptr);
+
    config.num_imports = mod_hwm;
    config.num_partitions = modules->length () - mod_hwm;
 

Re: [PATCH] fortran: add constant input support for trig functions with half-revolutions

[Steve Kargl]

Apologies for late a late reply.  A quick skim of the code
suggests that you can eliminate some of the range_check()
calls in the simplifications.  For example, you have

+gfc_expr *
+gfc_simplify_acospi (gfc_expr *x)
+{
+  gfc_expr *result;
+
+  if (x->expr_type != EXPR_CONSTANT)
+return NULL;
+
+  if (mpfr_cmp_si (x->value.real, 1) > 0 || mpfr_cmp_si (x->value.real, -1) < 
0)
+{
+  gfc_error ("Argument of ACOSPI at %L must be between -1 and 1",
+&x->where);
+  return &gfc_bad_expr;
+}

This error check should be sufficient, so that ...

+  result = gfc_get_constant_expr (x->ts.type, x->ts.kind, &x->where);
+
+#if MPFR_VERSION >= MPFR_VERSION_NUM(4, 2, 0)
+  mpfr_acospi (result->value.real, x->value.real, GFC_RND_MODE);
+#else
+  mpfr_t pi, tmp;
+  mpfr_inits2 (2 * mpfr_get_prec (x->value.real), pi, tmp, NULL);
+  mpfr_const_pi (pi, GFC_RND_MODE);
+  mpfr_acos (tmp, x->value.real, GFC_RND_MODE);
+  mpfr_div (result->value.real, tmp, pi, GFC_RND_MODE);
+  mpfr_clears (pi, tmp, NULL);
+#endif
+
+  return range_check (result, "ACOSPI");

this range_check() is unneeded.

As a side note, the error message is slightly misleading 
(although it will not be issued).  Technically, x = -1 or 1
are allowed values, and neither is **between** -1 and 1.
A better error message might be 

   gfc_error ("Argument of ACOSPI at %L must be within the "
   closed interval [-1,1]");
or
   gfc_error ("Argument X of ACOSPI at %L must satisfy -1 <= X <= 1");


-- 
steve

[PATCH] c++/modules: Support re-streaming TU_LOCAL_ENTITYs [PR120412]

[Nathaniel Shead]

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

-- >8 --

When emitting a primary module interface, we must re-stream any TU-local
entities that we saw in a partition.  This patch adds the missing
members from core_vals.

As a drive-by fix, in some cases we might have a typedef referring to a
TU-local entity; we need to handle that case as well.

PR c++/120412

gcc/cp/ChangeLog:

* module.cc (trees_out::core_vals): Write TU_LOCAL_ENTITY bits.
(trees_in::core_vals): Read it.
(trees_in::tree_node): Handle TU_LOCAL_ENTITY typedefs.

gcc/testsuite/ChangeLog:

* g++.dg/modules/internal-14_a.C: New test.
* g++.dg/modules/internal-14_b.C: New test.
* g++.dg/modules/internal-14_c.C: New test.

Signed-off-by: Nathaniel Shead 
---
 gcc/cp/module.cc | 15 ++-
 gcc/testsuite/g++.dg/modules/internal-14_a.C | 17 +
 gcc/testsuite/g++.dg/modules/internal-14_b.C |  6 ++
 gcc/testsuite/g++.dg/modules/internal-14_c.C |  9 +
 4 files changed, 46 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/modules/internal-14_a.C
 create mode 100644 gcc/testsuite/g++.dg/modules/internal-14_b.C
 create mode 100644 gcc/testsuite/g++.dg/modules/internal-14_c.C

diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 17c040d26b0..16322fddde7 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -6774,6 +6774,13 @@ trees_out::core_vals (tree t)
   if (streaming_p ())
WU (((lang_tree_node *)t)->trait_expression.kind);
   break;
+
+case TU_LOCAL_ENTITY:
+  WT (((lang_tree_node *)t)->tu_local_entity.name);
+  if (state)
+   state->write_location
+ (*this, ((lang_tree_node *)t)->tu_local_entity.loc);
+  break;
 }
 
   if (CODE_CONTAINS_STRUCT (code, TS_TYPED))
@@ -7317,6 +7324,11 @@ trees_in::core_vals (tree t)
   RT (((lang_tree_node *)t)->trait_expression.type2);
   RUC (cp_trait_kind, ((lang_tree_node *)t)->trait_expression.kind);
   break;
+
+case TU_LOCAL_ENTITY:
+  RT (((lang_tree_node *)t)->tu_local_entity.name);
+  ((lang_tree_node *)t)->tu_local_entity.loc
+   = state->read_location (*this);
 }
 
   if (CODE_CONTAINS_STRUCT (code, TS_TYPED))
@@ -10125,7 +10137,8 @@ trees_in::tree_node (bool is_use)
&& dump ("Read %stypedef %C:%N",
 DECL_IMPLICIT_TYPEDEF_P (res) ? "implicit " : "",
 TREE_CODE (res), res);
- res = TREE_TYPE (res);
+ if (TREE_CODE (res) != TU_LOCAL_ENTITY)
+   res = TREE_TYPE (res);
}
   break;
 
diff --git a/gcc/testsuite/g++.dg/modules/internal-14_a.C 
b/gcc/testsuite/g++.dg/modules/internal-14_a.C
new file mode 100644
index 000..07eb9658951
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/internal-14_a.C
@@ -0,0 +1,17 @@
+// PR c++/120412
+// { dg-additional-options "-fmodules -std=c++20 -Wtemplate-names-tu-local" }
+// { dg-module-cmi m:part }
+
+export module m:part;
+
+export template 
+auto fun1(F) {
+  return true;
+}
+
+using Dodgy = decltype([]{});
+
+export template 
+auto fun2(T&&) {  // { dg-warning "TU-local" }
+  return fun1(Dodgy{});
+}
diff --git a/gcc/testsuite/g++.dg/modules/internal-14_b.C 
b/gcc/testsuite/g++.dg/modules/internal-14_b.C
new file mode 100644
index 000..ad3b09d0722
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/internal-14_b.C
@@ -0,0 +1,6 @@
+// PR c++/120412
+// { dg-additional-options "-fmodules -std=c++20 -Wtemplate-names-tu-local" }
+// { dg-module-cmi m }
+
+export module m;
+export import :part;
diff --git a/gcc/testsuite/g++.dg/modules/internal-14_c.C 
b/gcc/testsuite/g++.dg/modules/internal-14_c.C
new file mode 100644
index 000..4f8e785ce87
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/internal-14_c.C
@@ -0,0 +1,9 @@
+// PR c++/120412
+// { dg-additional-options "-fmodules -std=c++20" }
+
+import m;
+
+int main() {
+  // { dg-error "instantiation exposes TU-local entity '(fun1|Dodgy)'" "" { 
target *-*-* } 0 }
+  fun2(123);  // { dg-message "required from here" }
+}
-- 
2.47.0

[PATCH] Improve copy prop for aggregates and combine with zeroing case

[Andrew Pinski]

This improves copy prop for aggregates by working over statements that don't 
modify the access
just like how it is done for copying zeros.
To speed up things, we should only have one loop back on the vuse instead of 
doing it twice for
each load/store assignments.

PR tree-optimization/14295

gcc/ChangeLog:

* tree-ssa-forwprop.cc (optimize_memcpy_to_memset): Split rewriting 
part out into ...
(optimize_memcpy_to_memset_1): This function.
(optimize_agr_copyprop):  Walk back until we get a
statement that may clobber the read. Call optimize_memcpy_to_memset_1.
Check that the src variable is not clobbered between the 2 statements.
(pass_forwprop::execute): Call optimize_agr_copyprop only instead of
optimize_memcpy_to_memset too.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/copy-prop-arg-1.c: New test.
* gcc.dg/tree-ssa/copy-prop-arg-2.c: New test.
* gcc.dg/tree-ssa/copy-prop-arg-3.c: New test.

Signed-off-by: Andrew Pinski 
---
 .../gcc.dg/tree-ssa/copy-prop-arg-1.c |  37 +
 .../gcc.dg/tree-ssa/copy-prop-arg-2.c |  35 
 .../gcc.dg/tree-ssa/copy-prop-arg-3.c |  41 +
 gcc/tree-ssa-forwprop.cc  | 149 --
 4 files changed, 212 insertions(+), 50 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/copy-prop-arg-1.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/copy-prop-arg-2.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/copy-prop-arg-3.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/copy-prop-arg-1.c 
b/gcc/testsuite/gcc.dg/tree-ssa/copy-prop-arg-1.c
new file mode 100644
index 000..876556fc464
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/copy-prop-arg-1.c
@@ -0,0 +1,37 @@
+/* { dg-do compile } */ 
+/* { dg-options "-O1 -fno-tree-sra -fdump-tree-optimized 
-fdump-tree-forwprop1-details" } */
+
+/* PR tree-optimization/14295 */
+
+/* Check for copyprop on structs.  */
+
+struct s
+{
+  char d;
+  int a, b;
+  double m;
+  int t[1024];
+};
+
+void g();
+struct s foo (struct s r)
+{
+  struct s temp_struct1;
+  struct s temp_struct2;
+  struct s temp_struct3;
+  temp_struct1 = r;
+  temp_struct2 = temp_struct1;
+  temp_struct3 = temp_struct2;
+  /* The call here should not make
+ a difference in removing all of the copies,
+ this is true as we end up with r = r; */
+  g();
+  r = temp_struct3;
+  return r;
+}
+
+/* There should be no references to any of "temp_struct*"
+   temporaries.  */
+/* { dg-final { scan-tree-dump-times "temp_struct" 0 "optimized" } } */
+/* Also check that forwprop pass did the copy prop. */
+/* { dg-final { scan-tree-dump-times "after previous" 3 "forwprop1" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/copy-prop-arg-2.c 
b/gcc/testsuite/gcc.dg/tree-ssa/copy-prop-arg-2.c
new file mode 100644
index 000..b1a76b48953
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/copy-prop-arg-2.c
@@ -0,0 +1,35 @@
+/* { dg-do compile } */ 
+/* { dg-options "-O1 -fno-tree-sra -fdump-tree-optimized 
-fdump-tree-forwprop1-details" } */
+
+/* PR tree-optimization/14295 */
+
+/* Check for copyprop on structs.  */
+
+struct s
+{
+  char d;
+  int a, b;
+  double m;
+  int t[1024];
+};
+
+void g();
+struct s foo (struct s r)
+{
+  struct s temp_struct1;
+  struct s temp_struct2;
+  struct s temp_struct3;
+  temp_struct1 = r;
+  temp_struct2 = temp_struct1;
+  temp_struct3 = temp_struct2;
+  /* The call here should not make
+ a difference in removing all of the copies. */
+  g();
+  return temp_struct3;
+}
+
+/* There should be no references to any of "temp_struct*"
+   temporaries.  */
+/* { dg-final { scan-tree-dump-times "temp_struct" 0 "optimized" } } */
+/* Also check that forwprop pass did the copy prop. */
+/* { dg-final { scan-tree-dump-times "after previous" 3 "forwprop1" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/copy-prop-arg-3.c 
b/gcc/testsuite/gcc.dg/tree-ssa/copy-prop-arg-3.c
new file mode 100644
index 000..96efafbe20c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/copy-prop-arg-3.c
@@ -0,0 +1,41 @@
+/* { dg-do compile } */ 
+/* { dg-options "-O2 -fno-tree-sra -fdump-tree-optimized 
-fdump-tree-forwprop1-details" } */
+
+/* PR tree-optimization/14295 */
+
+/* Check for copyprop on structs.  */
+
+struct s
+{
+  int t[1024];
+};
+
+[[gnu::noinline]]
+void g(float *a)
+{
+  *a = 1.0;
+}
+
+struct s r;
+struct s foo (float *a)
+{
+  struct s temp_struct1;
+  struct s temp_struct2;
+  struct s temp_struct3;
+  temp_struct1 = r;
+  temp_struct2 = temp_struct1;
+  temp_struct3 = temp_struct2;
+  /* The call here should not make
+ a difference in removing all of the copies,
+ this is true as we end up with r = r; g should be known only to change
+ float types so can be ignored with TBAA. */
+  g(a);
+  r = temp_struct3;
+  return r;
+}
+
+/* There should be no references to any of "temp_struct*"
+   temporaries.  */
+/* { dg-final { scan-tree-dump-times "temp_struct" 

Re: [PATCH] match: Undo maybe_push_res_to_seq in some cases [PR120331]

[Andrew Pinski]

On Fri, May 23, 2025 at 2:39 AM Richard Biener
 wrote:
>
> On Thu, May 22, 2025 at 3:11 AM Jeff Law  wrote:
> >
> >
> >
> > On 5/18/25 10:38 AM, Andrew Pinski wrote:
> > > While working on improving forwprop and removal of
> > > forward_propagate_into_gimple_cond/forward_propagate_into_comparison,
> > > I came cross a case where we end up with SSA_NAME in the resulting
> > > gimple_match_op and one statement in the sequence.  This was the result
> > > of simplification of:
> > > ```
> > > _3 = MIN_EXPR  > 16
> > > if (_3 > 16) ...
> > > ```
> > >
> > > Which simplifies down to:
> > > (maxlen_2(D) > 16) & (264 > 16)
> > > into
> > > (maxlen_2(D) > 16) & 1
> > >
> > > Which `maxlen_2(D) > 16` gets pushed onto the sequence
> > > and then the & 1 is removed via the match pattern:
> > > ```
> > > /* x & ~0 -> x  */
> > > (simplify
> > >   (bit_and @0 integer_all_onesp)
> > >(non_lvalue @0))
> > > ```
> > >
> > > So what this patch does is to undo the push extracting the new op
> > > from the pushed statement and remove the sequence as it is not used
> > > any more.
> > >
> > > Bootstrapped and tested on x86_64-linux-gnu.
> > >
> > > gcc/ChangeLog:
> > >
> > >   PR tree-optimization/120331
> > >   * gimple-match-exports.cc (maybe_undo_push): New function.
> > >   (gimple_simplify): Call maybe_undo_push if resimplify was 
> > > successfull.
> > OK, but this isn't my strongest area.  So give Richi until Monday AM to
> > chime in if he's got concerns.
>
> It's a bit ugly and IMO it should be in-line at the single user and have an
> explaining comment why we still might see such cases.  I'll note that
> this does not help when match recursively applies simplifications or when
> 'seq' is passed as NULL.  So addressing this in the genmatch generated
> code directly would be superior (but IIRC what the bug said this isn't
> possible?)

I am going to try again to see if there is a way to get genmatch
generated code to
do it. I hope to get to it next week.

Thanks,
Andrew

>
> Richard.
>
> > Thanks,
> > jeff
> >