d: Add convenient overload for build_libcall

Most generated calls to build_libcall don't require any special
conversions from the generic type returned by the library. Add an
overload that calls the library function without doing any nop casts.

gcc/d/ChangeLog:

* d-tree.h (build_libcall): New declaration.
* runtime.cc (build_libcall_1): New function.
(build_libcall): New overload.
* d-codegen.cc (build_assert_call): Call build_libcall without Type
argument.
(build_array_bounds_call): Likewise.
(build_bounds_index_condition): Likewise.
(build_bounds_slice_condition): Likewise.
(build_closure): Likewise.
* expr.cc (ExprVisitor::visit): Likewise.
* toir.cc (IRVisitor::visit): Likewise.

d: Fix ICE in output_constant, at varasm.cc:5662 [PR124026]

PR d/124026

gcc/d/ChangeLog:

* expr.cc (ExprVisitor::visit (FuncExp *)): Always convert function
literal to a delegate if the expression expects one.

d: Fix error when passing assert(0) as argument [PR123995]

Library routines that either throw or halt execution already have the
call flag ECF_NORETURN.  Make their internal type `noreturn' as well, so
that they can be "passed" to functions accepting noreturn arguments.

PR d/123995

gcc/d/ChangeLog:

* d-codegen.cc (build_assert_call): Cast libcall result to `noreturn'.
(build_array_bounds_call):  Likewise.
(build_bounds_index_condition): Likewise.
(build_bounds_slice_condition): Likewise.
* expr.cc (ExprVisitor::visit (ThrowExp *)): Likewise.
* toir.cc (IRVisitor::visit (ThrowStatement *)): Likewise.
* runtime.cc (enum d_libcall_type): Add LCT_NORETURN.
(get_libcall_type): Handle LCT_NORETURN.
* runtime.def (ASSERTP): Change return type to `noreturn'.
(ASSERT_MSG): Likewise.
(UNITTESTP): Likewise.
(UNITTEST_MSG): Likewise.
(ARRAYBOUNDSP): Likewise.
(ARRAYBOUNDS_SLICEP): Likewise.
(ARRAYBOUNDS_INDEXP): Likewise.
(THROW): Likewise.

gcc/testsuite/ChangeLog:

* gdc.dg/pr123995.d: New test.

Fortran: fix check for class array valued constructors and functions [PR123961]

PR fortran/123961

gcc/fortran/ChangeLog:

* check.cc (array_check): Extend check to class array functions.
* class.cc (gfc_add_class_array_ref): Fix NULL pointer dereference.

gcc/testsuite/ChangeLog:

* gfortran.dg/class_array_24.f90: New test.

testsuite: Fix ice-pr116228.C test for 32-bit targets

This test fails on 32-bit targets:
  ..../gcc/gcc/testsuite/g++.dg/analyzer/ice-pr116228.C:3:7: error: 'operator new' takes type 'size_t' ('unsigned int') as first parameter [-fpermissive]

Fix by using proper __SIZE_TYPE__ type.

Ensured that the test still passes with this patch.  Also, reverted the
fix for r16-7383-gf3f7e7514a794f, and ensured that the test still can
expose the ICE on x86_64-pc-linux-gnu:

  $ make check-gcc-c++ RUNTESTFLAGS="--target_board=unix/ analyzer.exp=ice-pr116228.C"
  FAIL: g++.dg/analyzer/ice-pr116228.C  -std=c++20 (internal compiler error: in get_or_create_null_ptr, at analyzer/region-model-manager.cc:257)
  # of unexpected failures        6

  $ make check-gcc-c++ RUNTESTFLAGS="--target_board=unix/-m32 analyzer.exp=ice-pr116228.C"
  FAIL: g++.dg/analyzer/ice-pr116228.C  -std=c++20 (internal compiler error: in get_or_create_null_ptr, at analyzer/region-model-manager.cc:257)
  # of unexpected failures        6

gcc/testsuite/ChangeLog:

* g++.dg/analyzer/ice-pr116228.C: Use __SIZE_TYPE__ for "new"
operator declaration.

Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>

Fortran: [PDT] Fix faults in fiats runtime [PR123545,PR123673,PR122949]

2026-02-08  Paul Thomas  <pault@gcc.gnu.org>

gcc/fortran
PR fortran/123545
PR fortran/123673
* decl.cc (gfc_get_pdt_instance): If a pdt_type component is
allocatable or has allocatable components, mark it alloc_comp.
(gfc_match_decl_type_spec): Sometimes in compiling contained
functions, the symtree for the constructor points to the type
instead of the constructor symbol. This corrects itself later
in compilation so return MATCH_YES.
* trans-decl.cc (gfc_generate_function_code): Unconditionally
nullify allocatable components as well as applying the default
initializer.
* trans-expr.cc (gfc_trans_alloc_subarray_assign): Restrict the
freeing of the destination data to non-allocatable expressions
and, instead, add the se finalblock to the encompassing final_
block.

gcc/testsuite
PR fortran/123545
* gfortran.dg/pdt_82.f03: New test.

PR fortran/123673
* gfortran.dg/pdt_83.f03: New test.

PR fortran/122949
* gfortran.dg/pr122949.f90: New test.

c++/modules: Fix ICE with multiple module declarations and -M [PR123738]

When only doing preprocessing, we do not call declare_module, and so we
do not check that a module has been declared multiple times.  This means
we end up with multiple "primary modules" being passed to the dependency
producing logic, which asserts.  Fixed by checking if we've already seen
a module declaration and complaining.

PR c++/123738

gcc/cp/ChangeLog:

* module.cc (preprocess_module): Complain for any non-imported
module declaration in a module purview.

gcc/testsuite/ChangeLog:

* g++.dg/modules/dep-5.C: New test.

Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>

gcc.target/i386/pr63542-2.c: Fix llp64 casts

Fix compile warnings with mingw-w64.

Signed-off-by: Jonathan Yong <10walls@gmail.com>
gcc/testsuite/ChangeLog:

* gcc.target/i386/pr63542-2.c: Change long unsigned casts
to __UINTPTR_TYPE__.

gcc.dg/analyzer/null-deref-pr105755.c: fix llp64

Fix compile warnings with mingw-w64.

Signed-off-by: Jonathan Yong <10walls@gmail.com>
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/null-deref-pr105755.c:
(ptrdiff_t): Change from long int to __PTRDIFF_TYPE__.
(EMACS_INT): Change from long int to __UINTPTR_TYPE__.
(intmax_t): change from long int to __INTMAX_TYPE__.

gcc.dg/pr97750.c: fix llp64 warnings

Signed-off-by: Jonathan Yong <10walls@gmail.com>
gcc/testsuite/ChangeLog:
* gcc.dg/pr97750.c: make llp64 warnings consistent with lp64

c++/reflection: splice parsing fixes [PR123823]

This patch fixes the problem that when cp_parser_splice_specifier sees
:]<, it always thinks it's a template-id.  Consequently, this should compile
but does not:

  int i;
  constexpr auto r = ^^i;
  bool b = [:r:] < 42;

because we think that a template argument list follows the splice.

Fixed by implementing [temp.names]/3 better: only attempt to parse
a template argument list if we saw template or typename.  As an
extension, also parse a template argument list if the splice yielded
a TEMPLATE_DECL -- in that case, chances are that the user simply
forgot to specify 'template'.  In that case we'll suggest adding
'template' in cp_parser_splice_expression.

We should accept the following given [temp.names]/3:

  S<[:r:] < 43> s;

and we should also accept:

  [:r:] < 42 > 0;

I also realized that my code to detect unparenthesized splice
expressions as template arguments is wrong.  [expr.prim.splice] says that

  constexpr auto i = e<[:^^h:]>;

is ill-formed, but "S<[:r:] >= 1>" is fine as per [temp.names]/6.  I moved
the checking to cp_parser_template_argument while making sure that we
only complain when the splice-expression is the whole template-argument.

This patch also fixes 123640.

PR c++/123823
PR c++/123640

gcc/cp/ChangeLog:

* parser.cc (cp_parser_splice_specifier): New typename_p parameter.
Use cp_parser_nth_token_starts_template_argument_list_p instead of
checking CPP_LESS.  Check for typename/template/TEMPLATE_DECL before
parsing a template-id.
(cp_parser_splice_type_specifier): Adjust the call to
cp_parser_splice_specifier.
(cp_parser_splice_expression): Don't detect unparenthesized splice
expressions here.  Adjust the call to cp_parser_splice_specifier.
(cp_parser_splice_scope_specifier): Adjust the call to
cp_parser_splice_specifier.
(cp_parser_skip_entire_splice_expr): New, broken out of...
(cp_parser_splice_spec_is_nns_p): ...this.
(cp_parser_template_id): Call pop_deferring_access_checks.
(cp_parser_template_argument): Detect unparenthesized splice
expressions here.

gcc/testsuite/ChangeLog:

* g++.dg/reflect/crash6.C: Adjust expected diagnostic.
* g++.dg/reflect/expr3.C: Likewise.  Test more cases.
* g++.dg/reflect/splice4.C: Adjust expected diagnostic.
* g++.dg/reflect/error12.C: New test.
* g++.dg/reflect/parse1.C: New test.
* g++.dg/reflect/parse2.C: New test.
* g++.dg/reflect/parse3.C: New test.
* g++.dg/reflect/parse4.C: New test.
* g++.dg/reflect/parse5.C: New test.
* g++.dg/reflect/parse6.C: New test.

Reviewed-by: Jason Merrill <jason@redhat.com>

Daily bump.

c++/reflection: add fixed test [PR123616]

This was fixed by r16-7330-g507ea25cf2e18b.

PR c++/123616

gcc/testsuite/ChangeLog:

* g++.dg/reflect/type_of3.C: New test.

Fix typo in last patch.

I committed a version where I had neutred the effective-target check.  That was
unintentional.

gcc/testsuite
* gcc.dg/pr90838.c: Commit correct version of patch.

Fix testsuite scan failure on loongarch64

Robin's patch to fix nonzero bits for the result of a popcount triggered a
minor testsuite scan failure for loongarch.  Essentially it was expecting to
see an ANDI for a zero-extend, but after the change we get a slli with a count
0, which is used for sign extension on loongarch.

Both are likely equally performant.  So this just adjusts the test to accept
both forms.  Now one could argue that the result of the popcount is already
sign extended and you'd be right -- that's a separate missed optimization issue
and unrelated to this testsuite regression.

Anyway, pushing this to the trunk.

gcc/testsuite/
* gcc.dg/pr90838.c: Adjust expected output for loongarch.

forwprop: Fix up calc_perm_vec_perm_simplify_seqs [PR123672]

Since r15-5563-g1c4d39ada we have an optimization to try to blend 2
sequences of 2xVEC_PERM_EXPR + 2x binop + 1x VEC_PERM where the first two
VEC_PERMs are permuting a single input and the last one permutes result from
those 2 binops into 2 VEC_PERM_EXPRs from 2 inputs, 2 binops and 2 final
VEC_PERMs.
On the following testcase, the intended change (i.e. after patch) is
(including DCE after it which the optimizations relies on):
   a_7 = *x_6(D);
   b_9 = *y_8(D);
-  c_10 = VEC_PERM_EXPR <a_7, a_7, { 0, 2, 0, 2 }>;
-  d_11 = VEC_PERM_EXPR <a_7, a_7, { 1, 3, 1, 3 }>;
-  e_12 = VEC_PERM_EXPR <b_9, b_9, { 0, 2, 0, 2 }>;
-  f_13 = VEC_PERM_EXPR <b_9, b_9, { 1, 3, 1, 3 }>;
+  c_10 = VEC_PERM_EXPR <a_7, b_9, { 0, 2, 4, 6 }>;
+  d_11 = VEC_PERM_EXPR <a_7, b_9, { 1, 3, 5, 7 }>;
   _1 = c_10 + d_11;
   _2 = c_10 - d_11;
   g_14 = VEC_PERM_EXPR <_1, _2, { 0, 4, 1, 5 }>;
-  _3 = e_12 + f_13;
-  _4 = e_12 - f_13;
-  h_15 = VEC_PERM_EXPR <_3, _4, { 0, 4, 1, 5 }>;
+  h_15 = VEC_PERM_EXPR <_1, _2, { 2, 6, 3, 7 }>;
   *x_6(D) = g_14;
   *y_8(D) = h_15;
This works by first identifying the two sequences, attempting to use vect
elem redundancies to only use at most half of the vector elements
(in this testcase a nop because 0, 4, 1, 5 perms already use only half of
the vector elts), remembering details of such sequences and later comparing
them if there are at least two (up to 8 I think) and trying to merge them.
The optimization is meant to improve SPEC x264.
Anyway, in r15-6387-geee289131 the optimization was changed to fix some
regressions but regressed this testcase, instead of the desirable
{ 0, 2, 4, 6 } and { 1, 3, 5, 7 } first 2 VEC_PERMs 15 branch and trunk
uses { 0, 2, 4, 4 } and { 1, 3, 5, 5 } and on this testcase that means
computing incorrect result.
On this testcase, it identified the two sequences (one ending with g_14
and one with h_15 with no changes (see above).  The first one (it has
some code to attempt to swap them if needed, but here the first one remains
g_14) keeps using the final VEC_PERM_EXPR as is (or with whatever
simplification recognise_vec_perm_simplify_seq performed on just that to
reduce to at most half of nelts) and the second one is modified so that
it uses the other elts of the two vectors.
So, we have { 0, 4, 1, 5 } (i.e. twice first lanes and twice second lanes)
from the first sequence and look up unused lanes (third and fourth) to
transform the other { 0, 4, 1, 5 } to, and find that is { 2, 6, 3, 7 }.
So far good.  But the next operation is to compute the new selectors
for the first 2 VEC_PERM_EXPRs, which are changed from single input to
two input ones.  For that, the code correctly uses the VECTOR_CST elts
unmodified for the lanes used by the first sequence (in this
testcase first/second lanes), so { 0, 2, X, X } and { 1, 3, X, X }
and then need to find out what to use for the needs of the second sequence.
Here is what it does currently:
  for (i = 0; i < nelts; i++)
    {
      bool use_seq1 = lane_assignment[i] != 2;
      unsigned int l1, l2;

      if (use_seq1)
        {
          /* Just reuse the selector indices.  */
          tree s1 = gimple_assign_rhs3 (seq1->v_1_stmt);
          tree s2 = gimple_assign_rhs3 (seq1->v_2_stmt);
          l1 = TREE_INT_CST_LOW (VECTOR_CST_ELT (s1, i));
          l2 = TREE_INT_CST_LOW (VECTOR_CST_ELT (s2, i));
        }
      else
        {
          /* We moved the lanes for seq2, so we need to adjust for that.  */
          tree s1 = gimple_assign_rhs3 (seq2->v_1_stmt);
          tree s2 = gimple_assign_rhs3 (seq2->v_2_stmt);

          unsigned int j = 0;
          for (; j < i; j++)
            {
              unsigned int sel_new;
              sel_new = seq2_stmt_sel_perm[j].to_constant ();
              sel_new %= nelts;
              if (sel_new == i)
                break;
            }

          /* This should not happen.  Test anyway to guarantee correctness.  */
          if (j == i)
            return false;

          l1 = TREE_INT_CST_LOW (VECTOR_CST_ELT (s1, j));
          l2 = TREE_INT_CST_LOW (VECTOR_CST_ELT (s2, j));
        }

      seq1_v_1_stmt_sel_perm.quick_push (l1 + (use_seq1 ? 0 : nelts));
      seq1_v_2_stmt_sel_perm.quick_push (l2 + (use_seq1 ? 0 : nelts));
    }
seq2_stmt_sel_perm is the newly computed { 2, 6, 3, 7 } selector and
seq1->v_{1,2}_stmt are def stmts of {c_10,d_11} and seq2->v_{1,2}_stmt
are def stmts of {e_12,f_13}.  For i 0 and 1 it is use_seq1 and
correct, then for i 2 the loop checks first seq2_stmt_sel_perm[0],
it is 2 % 4, equal to i, so picks up VECTOR_CST_ELTS (s{1,2}, 2),
which happens to be correct in this case, for i 3 the loop loops until
seq2_stmt_sel_perm[2] which is 3 % 4, stops and picks the wrong
VECTOR_CST_ELTS (s{1,2}, 2) which has the same value as
VECTOR_CST_ELTS (s{1,2}, 0), when the correct value would be in this
case either 1 or 3 (due to the duplication).
What the loop should do for !use_seq1 is to take the lane transformations
into account, we've changed { 0, 4, 1, 5 } to { 2, 6, 3, 7 }, so instead
of using lanes 0, 0, 1, 1 we now use lanes 2, 2, 3, 3 (x / 4 is about
which input it is picked from, here + or -).  So, for 2 which got remapped
from 0 we want to use 0 and for 3 which got remapped from 1 we want to use
1.
The function uses an auto_vec lane_assignment with values 0 (unused lane,
so far or altogether), 1 (used by first sequence) and 2 (used by second
sequence).  When we store in there 2, we know exactly which lane we are
remapping to which lane, so instead of computing it again the following
patch stores there 2 + l_orig, such that value >= 2 means second lane
and lane_assignment[i] - 2 in that case is the lane that got remapped to i.
And then the last loop doesn't need to recompute anything and can just use
the remembered transformation.
The rest of the changes (hunks 1-5 and 7) are just random small fixes I've
noticed while trying to understand the code.  The real fix is
- lane_assignment[lane] = 2;
+ lane_assignment[lane] = 2 + l_orig;
and
- bool use_seq1 = lane_assignment[i] != 2;
+ bool use_seq1 = lane_assignment[i] < 2;
and the rest of the last hunk.  Also, the last loop was kind of assuming
VEC_PERM_EXPR canonicalization happened and for single input perm the
selector elts are never >= nelts, I've added %= nelts just to be sure.

2026-02-07  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/123672
* tree-ssa-forwprop.cc (recognise_vec_perm_simplify_seq): Use std::swap
instead of fetching gimple_assign_rhs{1,2} again.  Change type of lanes
vector from auto_vec<unsigned int> to auto_vec<bool> and store true
instead of 1 into it.  Fix comment typo and formatting fix.
(can_blend_vec_perm_simplify_seqs_p): Put end of comment on the same
line as the last sentence in it.
(calc_perm_vec_perm_simplify_seqs): Change lane_assignment type from
auto_vec<int> to auto_vec<unsigned> and store 2 + l_orig into it
instead of true.  Fix comment typo and formatting fix.  Set use_seq1
to line_assignment[i] < 2 instead of line_assignment[i] != 2.  Replace
bogus computation of index for !use_seq with using
line_assignment[i] - 2.  Set l1 to l1 % nelts and similarly for l2.

* gcc.dg/pr123672.c: New test.

analyzer: fix ICE on operator new with discarded result [PR116228]

gcc/analyzer/ChangeLog:
PR analyzer/116228
* kf-lang-cp.cc (kf_operator_new::impl_call_post): Don't try to
add a constraint if the return value is discarded.

gcc/testsuite/ChangeLog:
PR analyzer/116228
* g++.dg/analyzer/ice-pr116228.C: New test.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

Fix comment typos in permutation spelling

Noticed two weird ways to spell permutation in some comments.

2026-02-07  Jakub Jelinek  <jakub@redhat.com>

* optabs.cc (expand_vec_perm_const): Comment spelling fix,
permuation -> permutation.
* config/arm/arm.cc (arm_evpc_neon_vtbl): Likewise.
* config/loongarch/loongarch.cc (loongarch_try_expand_lsx_vshuf_const):
Comment spelling fix, permuatation -> permutation.
(loongarch_is_elem_duplicate): Likewise.  Comment spelling fix,
permuation -> permutation.

c++: Handle SPLICE_SCOPE in cp_walk_subtrees [PR123659]

SPLICE_SCOPE is a TYPE_P, but didn't have its SPLICE_SCOPE_EXPR
walked by cp_walk_tree, so the following testcase has been rejected
because it didn't find a pack in it.

SPLICE_EXPR is fine, as it is tcc_expression and walk_tree by default
walks all the tcc_exception operands for unknown trees.

2026-02-07  Jakub Jelinek  <jakub@redhat.com>

PR c++/123659
* tree.cc (cp_walk_subtrees): Handle SPLICE_SCOPE.

* g++.dg/reflect/splice9.C: New test.

c++: Fix error recovery of invalid splice during tsubst_splice_expr [PR123752]

splice can return error_mark_node, e.g. if the evaluation of the
constant expression throws without being caught, and the error_mark_node
later on causes ICEs in various asserts.

The following patch fixes it by returning early if error_mark_node is
returned.

2026-02-07  Jakub Jelinek  <jakub@redhat.com>

PR c++/123752
* pt.cc (tsubst_splice_expr): Return error_mark_node if
splice returned it.

* g++.dg/reflect/splice8.C: New test.

Revert part of r16-869-ge3d3d6d7d2c8ab

The following reverts part of the changes done by r16-869-ge3d3d6d7d2c8ab
which AFAICS was never posted on the mailing list.  The hunk reverted
adds extra costs for vector construction of AVX or AVX512 vectors
because Honza thought we're only adding 1 conversion for all constructs,
but in fact we're costing each individual unique scalar source used.

Noticed when investigating PR120234, but this does not affect it
since there it's all SSE sized operations.

Still this is a regression, though reading r16-869-ge3d3d6d7d2c8ab
commit message indicating "correct numbers regress benchmarks" might
make this somewhat dangerous.  Still r16-531-g37e61c793c1b22 already
made the constructor costs much more expensive for integers, so
this might compensate.

* config/i386/i386.cc (ix86_vector_costs::add_stmt_cost):
Remove double and triple accounting of GPR -> XMM moves
in construction of AVX and AVX512 vectors.

cse: Take single register constraints into account

This fixes

t.c:17:3: error: 'asm' operand has impossible constraints or there are not enough registers
   17 |   __asm__ ("" : "=f" (a), "={fr2}" (e) : "{fr1}" (d));
      |   ^~~~~~~

on powerpc64le-unknown-linux-gnu for the attached test.  Prior cse1 we have

(insn 2 4 3 2 (set (reg/v:TF 120 [ c ])
        (reg:TF 33 1 [ c ])) "t.c":14:26 614 {*movtf_64bit_dm}
     (nil))
...
(insn 10 9 6 2 (parallel [
            (set (reg:DF 121)
                (asm_operands:DF ("") ("=f") 0 [
                        (reg:TF 124)
                    ]
                     [
                        (asm_input:TF ("{fr1}") t.c:17)
                    ]
                     [] t.c:17))
            (set (reg:DF 123 [ e ])
                (asm_operands:DF ("") ("={fr2}") 1 [
                        (reg:TF 124)
                    ]
                     [
                        (asm_input:TF ("{fr1}") t.c:17)
                    ]
                     [] t.c:17))
            (clobber (reg:SI 98 ca))
        ]) "t.c":17:3 -1
     (nil))
...
(insn 12 11 13 2 (set (reg:TF 33 1)
            (reg/v:TF 120 [ c ])) "t.c":18:12 614 {*movtf_64bit_dm}
     (nil))

During cse1, in insn 12 pseudo 120 is substituted with hard register 33
rendering the resulting insn trivial which is why the insn gets removed
afterwards.  Since hard register 33 has a use after insn 12, the
register is live before and after insn 10.  This leaves us with the
non-trivial problem, during LRA, to also assign hard register 33 to
pseudo 124 which is coming from the constraint of insn 10.  Since hard
registers are not tracked, except for liveness, this cannot be solved by
reloads which is why we end up with an error.  Therefore, treat single
register constraints as clobbers of the respective hard registers.

For the sake of symmetry this should also be done for constraints
associated a single register class.  However, since we are in stage 4,
there is no open PR, and I haven't done any extensive testing for single
register classes, I'm skipping this for the moment.  Once we are back in
stage 1, something along the lines could be added:

        else
          {
            enum reg_class cl
              = reg_class_for_constraint (lookup_constraint (p));
            if (cl == NO_REGS)
              continue;
            machine_mode mode = recog_data.operand_mode[nop];
            int regno = ira_class_singleton[cl][mode];
            if (regno >= 0)
              invalidate_reg (gen_rtx_REG (mode, regno));
          }

gcc/ChangeLog:

* cse.cc (invalidate_from_sets_and_clobbers): Consider any hard
register referred to by any single register constraint
potentially being clobbered.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/asm-hard-reg-2.c: New test.

PR tree-optimization/123958: FMA vs pow(x,2.0) [vs errno]

This is my proposed solution to PR123958 (and PR124002) which is a
regression exposed by my recent change to avoid expanding pow(x,2.0)
to x*x with -fmath-errno (the default) when we can't guarantee that
errno shouldn't be updated.  The problem is that the logic to convert
pow(x,2.0) was also duplicated (but unused) in tree-ssa-math-opts
where it's intended to perform this conversion in order to expose
fused-multiply-add instructions when supported by the target.  The
issue is that this "vestigial" code has bit-rotten over the years,
and incorrectly updates vdefs when changing vops, tiggering an ICE.

My pragmatic solution to this is to simply delete the problematic
code; the decision of whether pow(x,2.0) should be expanded is left
to the earlier pow_expand pass (which is what it's designed for), and
the later FMA pass can make use of any resulting FP multiplications.
Not only does this avoid the PHI related ICE, but also fixes the
original PR (on updating errno) on targets with FMA, e.g. aarch64
and recent x86_64 architectures (such as -march=znver3).

2026-02-07  Roger Sayle  <roger@nextmovesoftware.com>

gcc/ChangeLog
PR middle-end/123826
PR tree-optimization/123958
PR c++/124002
* tree-ssa-math-opts.cc (math_opts_dom_walker::after_dom_children):
Delete code that (mis)handled conversion of pow(x,2.0) to x*x.

gcc/testsuite/ChangeLog
PR middle-end/123826
PR tree-optimization/123958
PR c++/124002
* g++.target/i386/pr124002.C: New test case.
* gcc.target/i386/pr123958.c: Likewise.
* gcc.dg/errno-4.c: Likewise.

PR rtl-optimization/123833: Use of insn attributes in insn_costs corrupts recog_data.

Thanks again to Jeff Law and Andrew Pinski.  Here's a revised patch that
addresses the true underlying cause of PR 128333.  recog.cc's cancel_changes
was not correctly updating the recog_data cache, which leads to strange
(incorrect) behavior in fwprop and ifcvt.

2026-02-07  Roger Sayle  <roger@nextmovesoftware.com>
    Andrew Pinski  <andrew.pinski@oss.qualcomm.com>
    Jeff Law  <jeffrey.law@oss.qualcomm.com>

gcc/ChangeLog
PR rtl-optimization/123833
* recog.cc (cancel_changes): Update the recog_data cache if it
holds the instruction being changed.

gcc/testsuite
PR rtl-optimization/123833
* gcc.target/mips/pr123833.c: New test case.

Daily bump.

a68: fix lowering of unicode characters in denotations

Signed-off-by: Jose E. Marchesi <jemarch@gnu.org>
gcc/algol68/ChangeLog

* a68-low-units.cc (a68_lower_denotation): Fix call to
a68_u8_mbtouc.

aarch64: Fix FEAT_PCDPHINT for C++

This patch rewrites the _Generic in arm_acle.h into a resolve_overloaded_builtin.
The reason for this was the lack of support in C++ for _Generic.

gcc/ChangeLog:

* config/aarch64/aarch64-builtins.cc
(enum aarch64_builtins): Add ptr and generic variants.
(aarch64_init_pcdphint_builtins): Likewise.
(aarch64_general_expand_builtin): Add ptr variant.
(aarch64_resolve_overloaded_builtin_stshh): Function to handle
overloaded atomic_store_with_stshh.
(aarch64_resolve_overloaded_builtin_general): Add call to stshh function.
* config/aarch64/aarch64-c.cc
(aarch64_resolve_overloaded_builtin): Allow fndecl to return.
* config/aarch64/arm_acle.h
(__atomic_store_with_stshh): Remove __Generic.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/atomic_store_with_stshh.c: Testcase change.
* g++.target/aarch64/atomic_store_with_stshh.C: New test.

ipa-cp: Fix assert triggering with -fno-toplevel-reorder (PR 106260)

with -fno-toplevel-reorder (and -fwhole-program), there apparently can
be local functions without any callers.  This is something that IPA-CP
does not like because its propagation verifier checks that local
functions do not end up with TOP in their lattices.  Therefore there
is an assert checking that all call-less unreachable functions have
been removed, which tigers in PR 106260 with these two options.

This patch detects the situation and marks the lattices as variable,
thus avoiding both the assert trigger and the verification failure.

gcc/ChangeLog:

2022-07-13  Martin Jambor  <mjambor@suse.cz>

PR ipa/106260
* ipa-cp.cc (initialize_node_lattices): Replace assert that there are
callers with handling that situation when -fno-toplevel_reorder.

gcc/testsuite/ChangeLog:

2022-07-13  Martin Jambor  <mjambor@suse.cz>

PR ipa/106260
* g++.dg/ipa/pr106260.C: New test.

a68: more work on formal holes

This commit implements several improvements:

1. The optimization for avoiding indirect calls while using
   declarations like:

    proc(string)int puts = nest C "_libga68_posixputs";

   has been completed.

2. Algol 68 procedures getting strings as arguments can now
   wrap corresponding C functions.  Note this does not include
   procedures yielding strings as for now.

3. Wrappers are now built for all formal holes having proc mode.  This
   allows for a more robust implementation.

Signed-off-by: Jose E. Marchesi <jemarch@gnu.org>
gcc/algol68/ChangeLog

* Make-lang.in (ALGOL68_OBJS): Add algol68/a68-low-holes.o.
* a68.h: Update prototypes.
* a68-types.h (struct TAG_T): New field nest_proc.
(NEST_PROC): Define.
* a68-parser.cc (a68_new_tag): Initialize NEST_PROC.
* a68-parser-extract.cc (extract_identities): Use NEST_PROC
instead of IN_PROC for taxes for defining-identifiers in identity
declarations of proc modes with formal holes as actual parameters.
* a68-moids-misc.cc (a68_is_c_mode): Modified to allow strings as
direct parameters.
* a68-low.cc (a68_make_proc_formal_hole_decl): Remove.
* a68-low-units.cc (a68_lower_identifier): Improve commentary.
(a68_lower_formal_hole): Factorize.
* a68-low-holes.cc: New file.
* a68-low-decls.cc (a68_lower_identity_declaration): Optimize
identity declarations of proc mode with formal holes as actual
parameters.
* a68-exports.cc (a68_add_identifier_to_moif): Honor NEST_PROC.
* ga68.texi (Communicating with C): Strings can now be passed as
parameters in formal holes.

gcc/testsuite/ChangeLog

* algol68/compile/error-nest-4.a68: Strings can now be passed as
arguments in formal holes.

build: Properly set gas_flag/gnu_ld_flag

This patch

commit cc12934b555625b130e242eb6199c60b353ab509
Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Date:   Tue Feb 3 20:41:40 2026 +0100

    build: Only use gas_flag/gnu_ld_flag internally [PR123841]

caused testsuite regressions on Linux/x86_64 in one configuration: if
configured without --with-gnu-as/--with-gnu-ld, taking as and ld from
PATH, the stage 1 gcc/auto-host.h differs:

@@ -538 +544 @@
-#define HAVE_AS_IX86_GOT32X 1
+#define HAVE_AS_IX86_GOT32X 0
@@ -586 +592 @@
-#define HAVE_AS_IX86_TLSLDM 1
+#define HAVE_AS_IX86_TLSLDM 0
@@ -599 +605 @@
-#define HAVE_AS_IX86_TLS_GET_ADDR_GOT 1
+#define HAVE_AS_IX86_TLS_GET_ADDR_GOT 0
@@ -1795 +1801 @@
-#define HAVE_LD_DEMANGLE 1
+/* #undef HAVE_LD_DEMANGLE */

gas_flag and gnu_ld_flag weren't set correctly in this case:

Without --with-gnu-ld, AC_ARG_WITH(gnu-ld) sets gnu_ld_flag to no.  The
later check to determine gnu_ld_flag from $gcc_cv_ld --version isn't
even run because it is guarded by test -z "$gnu_ld_flag".

To avoid this, two things need to happen:

* The ld --version check needs to be done in the ACTION_IF_NOT case of
  AC_ARG_WITH(gnu-ld), not afterwards.

* For this to work, gcc_cv_ld needs to be set at this point.

Therefore this patch does the first.  In order for the second to work,
AC_ARG_WITH(gnu-ld) is moved later when gcc_cv_ld has already been set.

The same applies to gas_flag, too.

Tested on x86_64-pc-linux-gnu and sparc64-unknown-linux-gnu like so:

* Establish a baseline before my gas_flag/gnu_ld_flag patches:

  commit f75fe68437e3cd62548370f9653aae7fee8c621c
  Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
  Date:   Tue Jan 27 19:11:11 2026 +0100

      build: Only use --fatal-warnings if assembler supports it

  configure with --disable-bootstrap --enable-languages=c++ in various
  combinations:

  * without anything more, taking as/ld from PATH

  * the same with --with-gnu-as --with-gnu-ld added

  * specifying --with-as=/usr/bin/as --with-ld=/usr/bin/ld instead

  * the same with --with-gnu-as --with-gnu-ld added

  then run make configure-gcc and compare gcc/auto-host.h files.

* At current trunk, there are two differences:

** The ones described above.

** HAVE_AFUNIX_H that was added to configure.ac since.

* With the current patch, all differences to the baseline vanish again,
  with the exception of the latter.

2026-02-04  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

gcc:
* configure.ac (gnu_ld_flag): Move $gcc_cv_ld --version check into
AC_ARG_WITH(gnu-ld).
(gcc_cv_ld): Set before gnu_ld_flag.
(gas_flag): Move $gcc_cv_ld --version check into AC_ARG_WITH(gnu-ld).
(gcc_cv_as): Set before gas_flag.
* configure: Regenerate.

Allow TYPE_CANONICAL (TYPE_MAIN_VARIANT (t)) not to be its own TYPE_MAIN_VARIANT [PR101312]

I had to revert my r16-7102 patch
https://gcc.gnu.org/pipermail/gcc-patches/2026-January/706424.html
(first patch in
https://gcc.gnu.org/pipermail/gcc-patches/2025-December/704097.html )
in r16-7328 because it regressed the testcase added in r16-7331 for PR123882.
typedef int T;
void foo (unsigned long, T[]);
void foo (unsigned long x, T[restrict x]);
The ICE was on the array_as_string hack which used qualifiers on
ARRAY_TYPE for printing and then FE called get_aka_type and errored
that restrict is not allowed on ARRAY_TYPEs.
Anyway, guess that would be fixable with further hacks, but when looking
into that, I've noticed my approach was completely broken, my assumption
that TYPE_CANONICAL (volatile int) is int is not true, TYPE_CANONICAL
(volatile int) is itself.  For volatile int[2], C/C++ pushes the cv quals
to the element type, so it is ARRAY_TYPE of volatile int, and this
modified ARRAY_TYPE is made a type variant of int[2], but its TYPE_CANONICAL
is again volatile int[2].
Furthermore, a lot of places including build_type_attribute_variant call
build_type_attribute_qual_variant like:
  return build_type_attribute_qual_variant (ttype, attribute,
                                            TYPE_QUALS (ttype));
so pass the quals of the type to it.  If build_type_attribute_qual_variant
for ARRAY_TYPEs behaves differently between C/C++ (in that case it
pushes quals to the element type) and other languages, then this will
do unexpected changes, namely because the ARRAY_TYPE usually (except for
array_as_string hack) don't contain cv quals,
build_type_attribute_variant (volatile int[2], may_alias,
                              TYPE_QUALS (volatile int[2]))
would create int [2] with may_alias attribute for C/C++.

Now, the ICE on the testcases was in 2 spots, in get_alias_check
gcc_checking_assert and in verify_type -fchecking stuff, the assumption
was that
TYPE_MAIN_VARIANT (TYPE_CANONICAL (TYPE_MAIN_VARIANT (type)))
== TYPE_CANONICAL (TYPE_MAIN_VARIANT (type))
for any type where TYPE_CANONICAL is non-NULL.  The reason why
this works e.g. for the C/C++ volatile int[2] is that the ARRAY_TYPE
is variant type of int[2], so the first TYPE_MAIN_VARIANT gets us
int[2] and its TYPE_CANONICAL is int[2] which is the main variant.
Now, if TYPE_CANONICAL (volatile int) needs to be itself (but sure with
typedef volatile int V; TYPE_CANONICAL (V) is volatile int) and I Richi
tried to change that and it broke everything, my change was wrong and
we really need
TYPE_CANONICAL (volatile int[2] __attribute__((may_alias))) to be
volatile int[2] and we create the attribute variants as distinct types,
using build_distinct_type_copy, so
TYPE_MAIN_VARIANT (volatile int[2] __attribute__((may_alias)))
is itself, then the alias/tree assumption that the
TYPE_MAIN_VARIANT (TYPE_CANONICAL (TYPE_MAIN_VARIANT (type)))
== TYPE_CANONICAL (TYPE_MAIN_VARIANT (type))
can't hold.  We need one further hop, so just guarantee that
TYPE_CANONICAL (TYPE_MAIN_VARIANT (TYPE_CANONICAL (TYPE_MAIN_VARIANT (type))))
== TYPE_MAIN_VARIANT (TYPE_CANONICAL (TYPE_MAIN_VARIANT (type))).

The following patch changes get_alias_set and tree.cc to verify that
instead.  For get_alias_set the checking checks more than before,
in particular that for both steps TYPE_CANONICAL is its own TYPE_CANONICAL
rather than just that !TYPE_STRUCTURAL_EQUALITY_P (i.e. TYPE_CANONICAL
is non-NULL).  verify_type already checks that though.

I've tried even
typedef volatile int A[1] __attribute__((may_alias));
typedef A __attribute__((btf_type_tag ("foo"))) B;
B c;
i.e. cascading more than one type attribute on the ARRAY_TYPE and it
still works, TYPE_CANONICAL (A) will be volatile int A[1] without
attribute and TYPE_CANONICAL (B) the same.

2026-02-06  Jakub Jelinek  <jakub@redhat.com>

PR c/101312
* alias.cc (get_alias_set): Allow TYPE_CANONICAL (mv) to be
not its own TYPE_MAIN_VARIANT, as long as its TYPE_MAIN_VARIANT
has TYPE_CANONICAL equal to itself.
* tree.cc (verify_type): Likewise.

* gcc.dg/pr101312-1.c: New test.
* gcc.dg/pr101312-2.c: New test.

cobol: Process -dumpspecs, -dumpversion, -dumpmachine. [PR119332]

Process the -dumpspecs, -dumpversion, and -dumpmachine options without
complaining about a lack of input files.

gcc/cobol/ChangeLog:

PR cobol/119332
* gcobolspec.cc (lang_specific_driver): Add -dumpspecs,
-dumpversion, -dumpmachine to the no_files_error=false cases.

match.pd: (A | (convert?)(A != 0)) EQ|NE 0 -> A EQ|NE 0 [PR114969]

The NE variant is a gimple pattern that comes from the following C++
code:

bool result = (std::max(
                  (unsigned long long) 0, (unsigned long long) var_0))
               | ( var_0 ?  1 : 0);

PR tree-optimization/114969

gcc/ChangeLog:

* match.pd (`(A | (convert?)(A != 0)) EQ|NE 0`): New pattern.

gcc/testsuite/ChangeLog:

* g++.dg/pr114969.C: New test.

amdgcn: Clean up the mov insn definitions

This patch should not change anything functional; it just deletes some cruft
and converts the constraints to the new format.  This is to make it easier
to edit later.

 * The long-commented-out insns are now deleted.
 * The vestigial support for unaligned register pairs has been removed (it
 was disabled and removed elsewhere long ago).

gcc/ChangeLog:

* config/gcn/gcn-valu.md (*mov<mode>_exec_match): Delete.
(*mov<mode>_exec_match): Likewise.
(*mov<mode>): Delete unaligned register support, and convert to new
constraint syntax.
(mov<mode>_exec): Likewise.
(@mov<mode>_sgprbase): Likewise.
* config/gcn/gcn.md (*movbi): Likewise.

analyzer: use value_range and range_op in eval_condition [PR98447]

PR analyzer/98447 covers a false positive from -fanalyzer.
The root cause is that the analyzer's constraint-handling code
doesn't "know" that if X := Y % 64, then X < 64.

This patch adds some minimal usage of value_range and range_op to
-fanalyzer.  It adds a new svalue::maybe_get_value_range vfunc, which
attempts to get a value_range for an svalue (but bails out for awkward
cases), and if value_ranges are available, uses them in eval_condition
to determine if the result is known based on range_op.

Doing so fixes the above false positive, improves a couple of other
tests in the DejaGnu testsuite, and eliminates 31 false +ves in the
analyzer integration testsuite (out of ~2200), along with a slight
speedup to the latter (albeit testing with a debug build of gcc).

A deeper integration with ranger could probably be made, but that is
clearly stage 1 material.

gcc/analyzer/ChangeLog:
PR analyzer/98447
* common.h: Include "value-range.h".
* region-model.cc: Include "value-relation.h" and "range-op.h".
(region_model::eval_condition): Try using range_op to see if we
can get a known boolean from the value_ranges of the operands.
* svalue.cc: Include "value-relation.h" and "range-op.h".
(type_can_have_value_range_p): New.
(svalue::maybe_get_value_range): New.
(constant_svalue::maybe_get_value_range): New.
(unknown_svalue::maybe_get_value_range): New.
(unaryop_svalue::maybe_get_value_range): New.
(binop_svalue::maybe_get_value_range): New.
* svalue.h (svalue::maybe_get_value_range): New vfunc decl.
(constant_svalue::maybe_get_value_range): New decl.
(unknown_svalue::maybe_get_value_range): New decl.
(unaryop_svalue::maybe_get_value_range): New decl.
(binop_svalue::maybe_get_value_range): New decl.

gcc/testsuite/ChangeLog:
PR analyzer/98447
* c-c++-common/analyzer/conditionals-pr98447-1.c: New test.
* c-c++-common/analyzer/conditionals-pr98447-2.c: New test.
* c-c++-common/analyzer/null-deref-pr108400-SoftEtherVPN-WebUi.c:
Updated for false positive being fixed for C.
* gcc.dg/analyzer/data-model-1.c: Update expected output to
reflect improved output.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

analyzer: fix ICE on repeated_svalue with no type [PR117491]

gcc/analyzer/ChangeLog:
PR analyzer/117491
* region-model-manager.cc
(region_model_manager::maybe_fold_repeated_svalue): Don't ICE when
inner_svalue has null type.

gcc/testsuite/ChangeLog:
PR analyzer/117491
* gcc.dg/analyzer/torture/ice-pr117491.c: New test.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

libstdc++: Update guards on __heterogeneous_hash_key and __heterogeneous_tree_key

The r16-7359-gae04c1afd1526a changed __heterogeneous_key to be
defined if __glibcxx_associative_heterogeneous_erasure, but missed
guards on derived __heterogeneous_hash_key and __heterogeneous_tree_key
concept.

libstdc++-v3/ChangeLog:

* include/bits/hashtable.h (std::__heterogeneous_hash_key)
[__glibcxx_associative_heterogeneous_erasure]: Changed guard.
* include/bits/stl_tree.h (std::__heterogeneous_tree_key)
[__glibcxx_associative_heterogeneous_erasure]: Likewise.
* include/bits/stl_function.h: Add comment with C++ version
for __glibcxx_associative_heterogeneous_erasure guard.

testsuite: forward extra arguments from $GCC_UNDER_TEST to gcc-ar

gcc/testsuite/ChangeLog:

* lib/lto.exp (lto-build-archive): Forward extra command line
arguments from $GCC_UNDER_TEST to gcc-ar.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>

rtl-optimization/119982 - XFAIL part of gcc.target/i386/pr109362.c

This XFAILs the gcc.target/i386/pr109362.c testcase where we now
need an additional register for the address part of a sequence
of two atomic loads because TER no longer applies after we now
hoist the address computation out of a loop.  In the PR I noted
how RTL propagation could handle this.  In the end this restores
the state we had in GCC 12 and earlier where in GCC 13 the code
generation improved by accident.

This resolves a P1 testsuite regression.

PR rtl-optimization/119982
* gcc.target/i386/pr109362.c: XFAIL.

tree-optimization/114274 - avoid stray BLOCK refrence from CSWTCH vars

The following removes the location from CSWTCH variables which are
DECL_IGNORED_P and have no DECL_CONTEXT.  The location is currently
taken from the gswitch statement and thus includes a BLOCK reference
which can eventually be elided and GCd, causing later ICEs when
ICF decides to merge the variable with some other.

PR tree-optimization/114274
* tree-switch-conversion.cc (switch_conversion::build_one_array):
Use UNKNOWN_LOCATION for the CSWTCH decl.

libstdc++: fix C++17 regression in concept __heterogeneous_key (2nd)

The commit 3f7905550483408a2c4c5096a1adc8d7e863eb12 defined a
concept __heterogeneous_key using a name not defined in C++17.
This is fixed by guarding the definition behind a name defined
in C++23 the earliest Standard that uses the definition.

https://gcc.gnu.org/pipermail/gcc-patches/2026-February/707814.html

libstdc++-v3/ChangeLog
* include/bits/stl_function.h (concept __heterogeneous_key):
Guard with __glibcxx_associative_heterogeneous_erasure

tree: Fix up build_function_type for (...) fntypes [PR123977]

The following testcase ICEs in -std=c++26 mode since my r16-4338 C++26
va_start changes.
The problem is that if we have anything non-canonical in a function
type with (...) in C++26 (or C23/C2Y) mode, in this case the R typedef
on return type rather than void, then we try to build TYPE_CANONICAL
for that, but weren't passing in the no_named_args_stdarg_p, so
a type with TYPE_NO_NAMED_ARGS_STDARG_P flag set got TYPE_CANONICAL
with TYPE_NO_NAMED_ARGS_STDARG_P flag cleared and comptypes then
didn't like that as those aren't really compatible types
(...) vs. the C89-ish () which even C++ uses for some type-generic
etc. builtins.

2026-02-05  Jakub Jelinek  <jakub@redhat.com>

PR c++/123977
* tree.cc (build_function_type): Pass no_named_args_stdarg_p
as last argument to recursive call.

* g++.dg/cpp26/stdarg10.C: New test.

libstdc++: Prevent std::stacktrace from using atomics on arm-eabi [PR120567]

The conftest.cc in GLIBCXX_ENABLE_BACKTRACE checks if calls to
__atomic_load and __atomic_store result in libatomic calls. For arm-eabi
those expand to normal loads with a call to __sync_synchronize to ensure
correct ordering. That means the generated assembly does not match the
grep pattern "__atomic_" and so configure incorrectly assumes we can use
atomics in libbacktrace.

The fix is to grep for "__atomic_|__sync_" instead of just "__atomic_".

As explained in the bug comments, the similar grep for "__atomic_" in
the GLIBCXX_ENABLE_ATOMIC_BUILTINS macro doesn't need the same change.
That conftest.cc program does emit a call to a libatomic function that
matches the grep pattern "__atomic_" so the test gives the right answer
for arm-eabi.

libstdc++-v3/ChangeLog:

PR libstdc++/120567
* acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Include "__sync_" in
grep command to check for extern calls to libatomic.
* configure: Regenerate.

Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>

testsuite: Fix pr61053.c testsuite failure on mingw

This test expects an error for x32 where long has smaller alignment than
long long and double, but the same is also true for *-*-mingw* targets.
Add that triplet to the target selectors for the dg-error directives.

gcc/testsuite/ChangeLog:

* gcc.dg/pr61053.c: Add *-*-mingw* to the dg-error directives
that currently only match x32.

libstdc++: Allow new-abi-baseline target to overwrite existing file

There doesn't seem to be much benefit to writing the symbols to
baseline_symbols.txt.new when an existing file is already present. It
just adds a manual step for maintainers to move the .txt.new file to
replace the .txt one. Overwriting the file directly allows you to use
git diff to see what changed immediately, and you can easly use git
commands to revert to the original file too.

libstdc++-v3/ChangeLog:

* testsuite/Makefile.am (new-abi-baseline): Overwrite existing
file instead of creating baseline_symbols.txt.new.
* testsuite/Makefile.in: Regenerate.

libstdc++: fix C++17 regression in concept __heterogeneous_key

The commit 3f7905550483408a2c4c5096a1adc8d7e863eb12 defined a
concept using a name not defined in C++17. This is fixed by
using an older name.

https://gcc.gnu.org/pipermail/gcc-patches/2026-February/707814.html

libstdc++-v3/ChangeLog
* include/bits/stl_function.h (__heterogeneous_key): Use
C++17-defined remove_cvref<>::type instead.

math-opts: Only build FMA when use is in addends. [PR123940]

When looking for an FMA opportunity we can find a multiplication use in an
else operand:

  vect_pretmp_50.23_121 = MEM <vector(2) charD.2> [(charD.2 *)&dD.2916 + 14B];
  vect__28.25_123 = vect_pretmp_50.23_121 * { 2, 2 };
  vect_patt_99.26_124 = .COND_ADD ({ -1, -1 }, vect_pretmp_50.23_121, { 14, 15 }, vect__28.25_123);

and build it:
  vect_pretmp_50.23_121 = MEM <vector(2) charD.2> [(charD.2 *)&dD.2916 + 14B];
  vect_patt_99.26_124 = .FMA (vect_pretmp_50.23_121, { 2, 2 }, vect_pretmp_50.23_121);

This patch checks if the use is in one of the addends.

PR tree-optimization/123940

gcc/ChangeLog:

* tree-ssa-math-opts.cc (convert_mult_to_fma): Check
multiplication result is an addend.

gcc/testsuite/ChangeLog:

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

Signed-off-by: Robin Dapp <rdapp@oss.qualcomm.com>

libgcc: replace CONST_CAST2 macro

libgcc/ChangeLog:

* config/i386/gthr-win32.h: Replace CONST_CAST2 with expanded
expression where used.
* config/pa/gthr-dce.h: Likewise.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>

middle-end: replace CONST_CAST with const_cast<> [PR123892]

gcc/ChangeLog:

PR middle-end/123892
* attribs.cc: Replace CONST_CAST with const_cast<>.
* builtins.cc: Likewise.
* collect2.cc: Likewise.
* config/bpf/core-builtins.cc: Likewise.
* config/gcn/mkoffload.cc: Likewise.
* config/nvptx/mkoffload.cc: Likewise.
* config/nvptx/nvptx.cc: Likewise.
* ctfc.cc: Likewise.
* dumpfile.cc: Likewise.
* gcc.cc: Likewise.
* gcov.cc: Likewise.
* gengtype-parse.cc: Likewise.
* gengtype-state.cc: Likewise.
* gengtype.cc: Likewise.
* genoutput.cc: Likewise.
* ggc-page.cc: Likewise.
* godump.cc: Likewise.
* lto-section-in.cc: Likewise.
* lto-wrapper.cc: Likewise.
* omp-offload.cc: Likewise.
* passes.cc: Likewise.
* plugin.cc: Likewise.
* prefix.cc: Likewise.
* pretty-print.cc: Likewise.
* selftest.cc: Likewise.
* statistics.cc: Likewise.
* stringpool.cc: Likewise.
* tree.h: Likewise.
* tree-profile.cc: Likewise.
* vec.h: Likewise.
* system.h (CONST_CAST2): Remove.
(CONST_CAST): Likewise.
* tsystem.h (CONST_CAST2): Remove.
(CONST_CAST): Likewise.

gcc/c-family/ChangeLog:

PR middle-end/123892
* c-common.cc: Replace CONST_CAST with const_cast<>.
* c-lex.cc: Likewise.

gcc/c/ChangeLog:

PR middle-end/123892
* c-decl.cc: Replace CONST_CAST with const_cast<>.
* c-parser.cc: Likewise.

gcc/cp/ChangeLog:

PR middle-end/123892
* call.cc: Replace CONST_CAST with const_cast<>.
* parser.cc: Likewise.

gcc/d/ChangeLog:

PR middle-end/123892
* d-builtins.cc: Replace CONST_CAST with const_cast<>.
* d-incpath.cc: Likewise.
* d-lang.cc: Likewise.
* d-spec.cc: Likewise.
* decl.cc: Likewise.

gcc/fortran/ChangeLog:

PR middle-end/123892
* gfortran.h: Replace CONST_CAST with const_cast<>.
* module.cc: Likewise.
* openmp.cc: Likewise.
* options.cc: Likewise.
* parse.cc: Likewise.
* scanner.cc: Likewise.
* st.cc: Likewise.
* trans-intrinsic.cc: Likewise.

gcc/lto/ChangeLog:

PR middle-end/123892
* lto-common.cc: Replace CONST_CAST with const_cast<>.
* lto.cc: Likewise.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>

gcc/tree.h: replace CONST_CAST2 with const_cast<> [PR123892]

gcc/ChangeLog:

PR middle-end/123892
* tree.h: Replace CONST_CAST2 with const_cast<>.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>

middle-end: replace CONST_CAST_TREE with const_cast<tree> [PR123892]

gcc/ChangeLog:

PR middle-end/123892
* attribs.cc: Replace CONST_CAST_TREE with const_cast<tree>.
* config/aarch64/aarch64.cc: Likewise.
* config/arm/arm.cc: Likewise.
* config/darwin.cc: Likewise.
* fold-const.cc: Likewise.
* gimple-expr.cc: Likewise.
* print-rtl.cc: Likewise.
* tree-object-size.cc: Likewise.
* tree.cc: Likewise.
* varasm.cc: Likewise.
* tree.h: Likewise.

gcc/c-family/ChangeLog:

PR middle-end/123892
* c-gimplify.cc: Replace CONST_CAST_TREE with const_cast<tree>.

gcc/cp/ChangeLog:

PR middle-end/123892
* call.cc: Replace CONST_CAST_TREE with const_cast<tree>.
* constraint.cc: Likewise.
* cp-lang.cc: Likewise.
* cp-tree.h: Likewise.
* cp-objcp-common.cc: Likewise.
* decl.cc: Likewise.
* init.cc: Likewise.
* pt.cc: Likewise.
* reflect.cc: Likewise.
* tree.cc: Likewise.
* typeck.cc: Likewise.
* typeck2.cc: Likewise.

gcc/lto/ChangeLog:

PR middle-end/123892
* lto-common.cc: Replace CONST_CAST_TREE with const_cast<tree>.

gcc/rust/ChangeLog:

PR middle-end/123892
* backend/rust-tree.cc: Replace CONST_CAST_TREE with const_cast<tree>.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>

middle-end: replace CONST_CAST_GIMPLE with const_cast<gimple *> [PR123892]

gcc/ChangeLog:

PR middle-end/123892
* gimple.h: Replace CONST_CAST_GIMPLE with const_cast<gimple *>.
* system.h (CONST_CAST_GIMPLE): Remove.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>

middle-end: replace CONST_CAST_BB with const_cast<basic_block> [PR123892]

gcc/ChangeLog:

PR middle-end/123892
* system.h: Remove.
* tracer.cc: Replace CONST_CAST_BB with
const_cast<basic_block>.
* tree-cfg.cc: Likewise.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>

middle-end: replace CONST_CAST_RTX with const_cast<rtx> [PR123892]

gcc/ChangeLog:

PR middle-end/123892
* alias.cc: Replace CONST_CAST_RTX with const_cast<rtx>.
* config/i386/x86-tune-sched-bd.cc: Likewise.
* config/rs6000/rs6000.cc: Likewise.
* recog.cc: Likewise.
* sel-sched-ir.cc: Likewise.
* var-tracking.cc: Likewise.
* varasm.cc: Likewise.
* system.h (CONST_CAST_RTX): Remove.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>

middle-end: replace CONST_CAST_RTX_INSN with const_cast<struct rtx_insn *> [PR123892]

gcc/ChangeLog:

PR middle-end/123892
* config/aarch64/aarch64.cc: Replace CONST_CAST_RTX_INSN with
const_cast<struct rtx_insn *>.
* rtlanal.cc: Likewise.
* sched-deps.cc: Likewise.
* system.h (CONST_CAST_RTX_INSN): Remove.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>

Daily bump.

value-range: update comments

One of the difficulties I ran into when familiarizing myself with
value-range.{h,cc} is that the comments and classes refer to
representations of "ranges", but the implementation has grown beyond
mere ranges of values (such as with bitmasks and NaN-tracking).

Arguably "range" could refer to the mathematical definition: the set
of possible outputs of a function, but I find it much clearer to think
of these classes as efficient representations of subsets of possible
values of a type.

This patch updates various leading comments in a way that clarifies
the intent of these classes (for me, at least).

gcc/ChangeLog:
* value-range.cc (irange_bitmask::irange_bitmask): Fix typo in
comment.
* value-range.h (class vrange): Update leading comment to refer
to "subsets" rather than "ranges".  Allude to the available
subclasses.  Warn that the classes can be over-approximations and
thus can introduce imprecision.
(class irange_bitmask): Updating leading comment to refer to
knowledge about a "value", rather than a "range".  Reword
description of MASK and VALUE to clarify implementation, and
add an example.
(class irange): Update leading comment to refer to a
"subset of possible values" rather than a "range", and
that subclasses have responsibility for storage.
(class nan_state): Rewrite leading comment.
(class frange final): Update leading comment to refer to
subsets of possible values, rather than ranges, and to
consistently use "Nan" when capitalizing.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

c++/reflection: make p3394-1.C dg-run

This test now links now so we should make it a dg-run.  The output
checking isn't very pretty.

gcc/testsuite/ChangeLog:

* g++.dg/reflect/p3394-1.C: Make dg-run.  Add dg-output.

Reviewed-by: Jakub Jelinek <jakub@redhat.com>

Update gcc es.po

* es.po: Update.

cobol: Use _perform_line_pairs instead of injecting encoded label names.

The gcobol front end has been communicating with GDB-COBOL by encoding
information into labels that are injected into the assembly language
with ASM_EXPR nodes.  That behavior is, at best, questionable.

These changes replace the "proccall" and "procret" types of those labels
in favor of a static _perform_line_pairs table that contains the same
information and is accessible by GDB-COBOL by virtue of its known name.

That table allows GDB-COBOL to "NEXT over COBOL PERFORM" statements in a
way that is familiar to users who have used "NEXT over function call".

Eventually that information should find its way into the .debug_info
section, but at the present time I don't know how to do that on either
the compiler or debugger sides.

Most of these changes involve eliminating gg_insert_into_assembler calls
and replacing them with the perform_is_armed/perform_line_pairs logic.

Some COBOL variable initialization changes crept in here, as well.

gcc/cobol/ChangeLog:

* genapi.cc (DEFAULT_LINE_NUMBER): Remove unused #define.
(parser_statement_begin): Implement perform_is_armed logic.
(initialize_variable_internal): Handle both real and int types in
SHOW_PARSE tracing.
(section_label): Comment a renumbered insert_nop() for gdb-cobol
logic.
(paragraph_label): Likewise.
(leave_procedure): Eliminate call to gg_insert_into_assembler().
(parser_enter_section): Renumber insert_nop().
(parser_perform): Eliminate call to gg_insert_into_assembler().
(parser_perform_times): Likewise.
(internal_perform_through): Likewise.
(internal_perform_through_times): Likewise.
(parser_leave_file): Create the static _perform_line_pairs table.
(parser_sleep): Renumber insert_nop().
(parser_division): Remove calls to initialize_the_data().
(parser_perform_start): New call to insert_nop().
(parser_perform_conditional): Likewise.
(perform_outofline_before_until): Expanded comment.
(perform_outofline_after_until): Eliminate call to
gg_insert_into_assembler().
(perform_outofline_testafter_varying): Likewise.
(perform_outofline_before_varying): Likewise.
(perform_inline_testbefore_varying):  New call to insert_nop().
(create_and_call): Change a comment.
* gengen.cc (gg_create_goto_pair): Change characteristics of a
label.
* parse.y: Change how data are initialized.
* parse_ante.h (field_type_update): Likewise.
* symbols.cc (cbl_field_t::set_signable): Likewise.
(cbl_field_t::encode): Likewise.
* symbols.h (struct cbl_field_t): Likewise.
* util.cc (symbol_field_type_update): Likewise.
(cbl_field_t::encode_numeric): Likewise.

libgcobol/ChangeLog:

* valconv.cc (__gg__string_to_numeric_edited): Explanatory comment.

libstdc++: make __collatenames array const in regex.tcc

libstdc++-v3/ChangeLog:

* include/bits/regex.tcc (regex_traits::lookup_collatename):
Make __collatenames array const.

Signed-off-by: Caolán McNamara <caolanm@gmail.com>

libstdc++: Fix ambiguity caused by new std::source_location constructor

The new constructor added for Contracts support was not explicit, so
caused ambiguities when arbitrary pointers were used in contexts which
could convert to std::source_location.

We don't actually need a constructor, the contract_violation::location()
function can just set the data member directly.

libstdc++-v3/ChangeLog:

* include/std/contracts (contract_violation::location): Use
source_location default constructor and then set _M_impl.
* include/std/source_location (source_location(const void*)):
Remove constructor.
* testsuite/18_support/contracts/includes.cc: Move to...
* testsuite/18_support/contracts/srcloc.cc: ...here. Test for
ambiguity caused by new constructor.

Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>

contrib/download_prerequisites: Switch gcc.gnu.org link to https

contrib/ChangeLog:

* download_prerequisites: Switch gcc.gnu.org link to https

aarch64: Adjust PR117048 scan assembly test

This test needed adjustment for the changes from PR123584.
Pushing to trunk.

Signed-off-by: Kyrylo Tkachov <ktkachov@nvidia.com>
gcc/testsuite/

PR target/117048
PR target/123584
* gcc.target/aarch64/simd/pr117048.c: Scan for # in assembly immediate.

libiberty: add helper to swap doubly-linked list wrappers

This patch introduces a new helper to swap the contents of two
doubly-linked list wrappers. The new *_swap_lists operation exchanges
the first, last, and size fields, allowing two lists to be swapped
efficiently without iterating over their elements.

This helper is intended for cases where the ownership of a list must be
exchanged but swapping wrapper pointers is not possible. For simple
references to lists, when wrappers are dynamically allocated, swapping
the wrapper pointers themselves is sufficient and remains the preferred
approach.

This change adds the necessary declaration and definition macros to
doubly-linked-list.h and integrates them into the set of mutative
list operations.

The testsuite is updated accordingly to cover the new functionality.

include/ChangeLog:

* doubly-linked-list.h
(LINKED_LIST_SWAP_LISTS): Add new helper.
(LINKED_LIST_DECL_SWAP_LISTS): Likewise.
(LINKED_LIST_DEFN_SWAP_LISTS): Likewise.
(LWRAPPERTYPE##_swap_lists): Likewise.

libiberty/ChangeLog:

* testsuite/test-doubly-linked-list.c: Update.

libphobos: Merge upstream phobos f7249cf45

Phobos changes:

- `std.uni' has been upgraded from Unicode 16.0.0 to 17.0.0.

libphobos/ChangeLog:

* src/MERGE: Merge upstream phobos f7249cf45.

testsuite: Add testcase for PR123986

This patch add a missing testcase cvise-reduced
testcase for PR123986.

PR tree-optimization/123986

gcc/testsuite/ChangeLog:

* gfortran.dg/vect/pr123986.f90: New test.

Signed-off-by: Josef Melcr <josef.melcr@suse.com>

c,c++: Fix incorrect warning with asm defined symbols

Static symbols defined in assembly cause wrong "used but never defined"
warning.

static void asm_fn();
asm("%cc0:" :: ":"(&asm_fn));

This happens in C,C++ frontends before cgraph is created where the
relevant flags are located.

We can suppress these warnings with OPT_Wunused.
C,C++ frontends and cgraphunit suppressed OPT_Wunused and
OPT_Wunused_function interchangeably, so we unify suppression to
only OPT_Wunused.

PR testsuite/123559

gcc/c/ChangeLog:

* c-decl.cc (c_write_global_declarations_1): Check and suppress
OPT_Wunused.
* c-typeck.cc (build_asm_expr): Suppress OPT_Wunused.

gcc/ChangeLog:

* cgraphunit.cc (check_global_declaration): Suppress OPT_Wunused.

gcc/cp/ChangeLog:

* decl.cc (wrapup_namespace_globals): Check and suppress OPT_Wunused.
* semantics.cc (finish_asm_stmt): Suppress OPT_Wunused.

gcc/testsuite/ChangeLog:

* c-c++-common/toplevel-extended-asm-1.c: New test.

testsuite: Add testcase for PR [PR123882]

I've reverted the PR101312 changes in order to fix this PR.
Here I'm just adding new testcase.

2026-02-05  Jakub Jelinek  <jakub@redhat.com>

PR c/123882
* gcc.dg/pr123882.c: New test.

c++/reflection: fix type_of for member fns [PR123934]

Here the assert was wrongly failing with

  'void (struct F::)(int)' is not the same as 'void(int)'

but as per [dcl.fct]/1 the type of fType should not include the class F.

PR c++/123934

gcc/cp/ChangeLog:

* reflect.cc (type_of): For FUNCTION_DECLs, use static_fn_type.

gcc/testsuite/ChangeLog:

* g++.dg/reflect/type_of2.C: Uncomment an assert.

Reviewed-by: Jason Merrill <jason@redhat.com>

c++: cv-qualified pack index propagation [PR122169]

Since type pack indexes can be cv-qualified, we need to propagate their
qualifiers when substituting them.

PR c++/122169

gcc/cp/ChangeLog:

* pt.cc (tsubst_pack_index): Propagate cv-qualifiers of
PACK_INDEX_TYPE.

gcc/testsuite/ChangeLog:

* g++.dg/cpp26/pack-indexing19.C: New test.

Reviewed-by: Marek Polacek <polacek@redhat.com>
Reviewed-by: Jason Merrill <jason@redhat.com>

Revert c, c++: Use c*_build_qualified_type instead of build_qualified_type from within build_type_attribute

As seen in PR123882, this broke more than it fixed, a lot of
build_type_attribute_qual_variant including build_type_attribute_variant
just pass in TYPE_QUALS (type) as the last argument and for C/C++
when the code pushes the quals to the element type, it will effectively
make those unqualified.  The PR123882 ICE is then on the array_as_string
terrible hack if the FE calls get_aka_type on that, it wants to create
qualified attribute variant of that and errors on the restrict qual.

So, to fix both PR c/123882 and other unknown regressions caused by
PR c/101312 I'm reverting it now.

This reverts commit 3d2a91a3767982dde5a37abf45c12c08d4fdbf41.

testsuite: lto: transform gcc-ar to include prefix

When the the gcc binary is named arm-none-eabi-gcc, the gcc-ar binary
will be named arm-none-eabi-gcc-ar.  The current approach works fine as
long as the binary does not contain any prefix, but if it does, the
gcc-ar binary will not be found.

gcc/testsuite/ChangeLog

* lib/lto.exp (lto-build-archive): Transform gcc-ar binary name.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>

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

Allows the GDCFLAGS for each bootstrap stage of building gdc to be
overriden, as is the case with CXXFLAGS for other front-ends.

PR d/116975

ChangeLog:

* Makefile.in: Regenerate.
* Makefile.tpl (STAGE[+id+]_GDCFLAGS): New.
(STAGE2_GDCFLAGS): Add -fno-checking.
(STAGE3_GDCFLAGS): Add -fchecking=1.
(BASE_FLAGS_TO_PASS): Pass STAGE[+id+]_GDCFLAGS down.
(configure-stage[+id+]-[+prefix+][+module+]): Set GDCFLAGS for all gcc
module stages.
(all-stage[+id+]-[+prefix+][+module+]): Likewise.

tree-optimization/123986 - upon SLP analysis rollback, release data

The following makes sure to release any SLP kind specific data when
rolling back earlier successful analysis.  This avoids crashing
when re-analyzing such node via another graph entry.

PR tree-optimization/123986
* tree-vect-slp.cc (vect_slp_analyze_operations): When
rolling back analyzed nodes, release node specific data
and reset SLP_TREE_TYPE.

tree-optimization/123983 - only update IV on the requested edge

The following reverts back to only updating the IV after the
vectorized loop on the requested edge which avoids disrupting
live value vectorization.

PR tree-optimization/123983
* tree-vect-loop-manip.cc (vect_update_ivs_after_vectorizer):
Only update the PHI argument on the requested edge.

* gcc.dg/vect/vect-pr123983.c: New testcase.

compare-elim: arm: enable compare-elimination on Arm [PR123604]

The Arm port has never had the compare elimination pass enabled by
adding a definition of TARGET_FLAGS_REGNUM.  But just adding this is
insufficient because the target uses COND_EXEC and compare-elim is not
yet set up to handle this.

This seems to be quite simple, since we just need to recognize
COND_EXEC in insns when scanning for uses of the condition code
register.

This is a partial mitigation for the code quality regression
reported in PR target/123604.

gcc/ChangeLog:

PR target/123604
* compare-elim.cc (find_flags_uses_in_insn): Handle COND_EXEC.
* config/arm/arm.cc (TARGET_FLAGS_REGNUM): Define.

ranger: Fix up WIDEN_MULT_EXPR handling in the ranger [PR123978]

In r13-6617 WIDEN_MULT_EXPR support has been added to the ranger, though
I guess until we started to use ranger during expansion in r16-1398
it wasn't really used much because vrp2 happens before widen_mul.
WIDEN_MULT_EXPR is documented to be
/* Widening multiplication.
   The two arguments are of type t1 and t2, both integral types that
   have the same precision, but possibly different signedness.
   The result is of integral type t3, such that t3 is at least twice
   the size of t1/t2. WIDEN_MULT_EXPR is equivalent to first widening
   (promoting) the arguments from type t1 to type t3, and from t2 to
   type t3 and then multiplying them.  */
and IMHO ranger should follow that description, so not relying on
the precisions to be exactly 2x but >= 2x.  More importantly, I don't
see convert_mult_to_widen actually ever testing TYPE_UNSIGNED on the
result, why would it when the actual RTL optabs don't care about that,
in RTL the signs are relevant just whether it is smul_widen, umul_widen
or usmul_widen.  Though on GIMPLE whether the result is signed or unsigned
is important, for value rangers it is essential (in addition to whether the
result type is wrapping or undefined overflow).  Unfortunately the ranger
doesn't tell wi_fold about the signs of the operands and wide_int can be
both signed and unsigned, all it knows is the precision of the operands,
so r13-6617 handled it by introducing two variants (alternate codes for
WIDEN_MULT_EXPR).  One was assuming first operand is signed, the other
the first operand is unsigned and both were assuming that the second operand
has the same sign as the result and that result has exactly 2x precision
of the arguments.  That is clearly wrong, on the following testcase
we have u w* u -> s stmt and ranger incorrectly concluded that the result
has [0, 0] range because the operands were [0, 0xffffffff] and
[0, -1] (both had actually [0, 0xffffffff] range, but as it used sign
extension rather than zero extension for the latter given the signed result,
it got it wrong).  And when we see [0, 0] range for memset length argument,
we just optimize it away completely at expansion time, which is wrong for
the testcase where it can be arbitrary long long int [0, 0xffffffff]
* long long int [0, 0xffffffff], so because of signed overflow I believe
the right range is long long int [0, 0x7fffffffffffffff], as going above
that would be UB and both operands are non-negative.

The following patch fixes it by not having 2 magic ops for WIDEN_MULT_EXPR,
but 3, one roughly corresponding to smul_widen, one to umul_widen and
one to usmul_widen (though confusingly with sumul order of operands).
The first one handles s w* s -> {u,s}, the second one u w* u -> {u,s}
and the last one s w* u -> {u,s} with u w* s -> {u,s} handled by swapping
the operands as before.  Also, in all cases it uses TYPE_PRECISION (type)
as the precision to extend to, because that is the precision in which
the actual multiplication is performed, the operation as described is
(type) op1 * (type) op2.

Note, r13-6617 also added OP_WIDEN_PLUS_{SIGNED,UNSIGNED} and handlers
for that, but it doesn't seem to be wired up in any way, so I think it
is dead code:
|git grep OP_WIDEN_PLUS_ .
|ChangeLog-2023: (OP_WIDEN_PLUS_SIGNED): New.
|ChangeLog-2023: (OP_WIDEN_PLUS_UNSIGNED): New.
|range-op.cc:  set (OP_WIDEN_PLUS_SIGNED, op_widen_plus_signed);
|range-op.cc:  set (OP_WIDEN_PLUS_UNSIGNED, op_widen_plus_unsigned);
|range-op.h:#define OP_WIDEN_PLUS_SIGNED ((unsigned) MAX_TREE_CODES + 2)
|range-op.h:#define OP_WIDEN_PLUS_UNSIGNED       ((unsigned) MAX_TREE_CODES + 3)
My understanding is that it is misnamed attempt to implement WIDEN_SUM_EXPR
handling but one that wasn't hooked up in maybe_non_standard.
I wonder if we shouldn't keep it as is for GCC 16, rename to OP_WIDEN_SUM_*
in stage1, hook it up in maybe_non_standard (in this case 2 ops are
sufficient, the description is
/* Widening summation.
   The first argument is of type t1.
   The second argument is of type t2, such that t2 is at least twice
   the size of t1. The type of the entire expression is also t2.
   WIDEN_SUM_EXPR is equivalent to first widening (promoting)
   the first argument from type t1 to type t2, and then summing it
   with the second argument.  */
and so we know second argument has the same type as the result, so all
we need to encode is the sign of the first argument.
And the ops should be both renamed and fixed, instead of
   wi::overflow_type ov_lb, ov_ub;
   signop s = TYPE_SIGN (type);

   wide_int lh_wlb
     = wide_int::from (lh_lb, wi::get_precision (lh_lb) * 2, SIGNED);
   wide_int lh_wub
     = wide_int::from (lh_ub, wi::get_precision (lh_ub) * 2, SIGNED);
   wide_int rh_wlb = wide_int::from (rh_lb, wi::get_precision (rh_lb) * 2, s);
   wide_int rh_wub = wide_int::from (rh_ub, wi::get_precision (rh_ub) * 2, s);

   wide_int new_lb = wi::add (lh_wlb, rh_wlb, s, &ov_lb);
   wide_int new_ub = wi::add (lh_wub, rh_wub, s, &ov_ub);

   r = int_range<2> (type, new_lb, new_ub);
I'd go for
   wide_int lh_wlb = wide_int::from (lh_lb, TYPE_PRECISION (type), SIGNED);
   wide_int lh_wub = wide_int::from (lh_ub, TYPE_PRECISION (type), SIGNED);
   return op_plus.wi_fold (r, type, lh_wlb, lh_wub, rh_lb, rh_ub);
(and similarly for the unsigned case with s/SIGNED/UNSIGNED/g).
Reasons: the precision again needs to be widen to type's precision, there
is no point to widen the second operand as it is already supposed to have
the right precision and operator_plus actually ends with
  value_range_with_overflow (r, type, new_lb, new_ub, ov_lb, ov_ub);
to handle the overflows etc., r = int_range<2> (type, new_lb, new_ub);
won't do it.

2026-02-04  Jakub Jelinek  <jakub@redhat.com>

PR middle-end/123978
* range-op.h (OP_WIDEN_MULT_SIGNED_UNSIGNED): Define.
(OP_WIDEN_PLUS_SIGNED, OP_WIDEN_PLUS_UNSIGNED,
RANGE_OP_TABLE_SIZE): Renumber.
* gimple-range-op.cc (imple_range_op_handler::maybe_non_standard):
Use 3 different classes instead of 2 for WIDEN_MULT_EXPR, one
for both operands signed, one for both operands unsigned and
one for operands with different signedness.  In the last case
canonicalize to first operand signed second unsigned.
* range-op.cc (operator_widen_mult_signed::wi_fold): Use
TYPE_PRECISION (type) rather than wi::get_precision (whatever) * 2,
use SIGNED for all wide_int::from calls.
(operator_widen_mult_unsigned::wi_fold): Similarly but use UNSIGNED
for all wide_int::from calls.
(class operator_widen_mult_signed_unsigned): New type.
(operator_widen_mult_signed_unsigned::wi_fold): Define.

* gcc.c-torture/execute/pr123978.c: New test.

libstdc++: Fix std::shared_ptr pretty printer for GDB 11

This pretty printer was updated for GCC 16 to match a change to
std::atomic<shared_ptr<T>>.  But the gdb.Type.is_scalar property was
added in GDB 12.1, so we get an error for older GDB versions.

This adds a workaround for older GDB versions. The gdb.Type.tag property
is None for scalar types, and should always be defined for the
std::atomic class template. Another option would be to use the
is_specialization_of function defined in printers.py, but just checking
for the tag is simpler.

libstdc++-v3/ChangeLog:

* python/libstdcxx/v6/printers.py (SharedPointerPrinter): Only
use gdb.Type.is_scalar if supported.
* testsuite/libstdc++-prettyprinters/compat.cc: Test printer for
old implementation of std::atomic<std::shared_ptr<T>>.

Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>

libstdc++: Fix some -Wpedantic warnings in regex tests

These tests can be run as C++11, so should use a string literal with the
static assertions.

libstdc++-v3/ChangeLog:

* testsuite/28_regex/algorithms/regex_match/multiline.cc: Add
string to static_assert.
* testsuite/28_regex/sub_match/lwg3204.cc: Likewise.

Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>

Fix speculative devirtualization ICE

this patch fixes cgraph verifier ICE about missing indirect call in the
speculative call sequence.  This is triggered when tree-inline manages to
devirtualize call during folding it does and the call has multiple specualtive
targets.  cgraph_update_edges_for_call_stmt_node calls
cgraph_edge::resolve_speculation which resolves one edge, but it should make
the whole sequence direct which is done by cgraph_edge::make_direct.

The code was also handling the case that call changed but it is not direct.
This should be impossible (and would require similar updating) so I added unreachable.

Bootstrapped/regtested x86_64-linux and also tested with autofdo and spec2017.

gcc/ChangeLog:

PR ipa/123226
* cgraph.cc (cgraph_update_edges_for_call_stmt_node): Fix handling
of multi-target speculations resolved at clone materialization time

libgomp, docs: Update TR14 omp_target_is_accessible status

This is now done, so update the table in the docs.

libgomp/ChangeLog:

* libgomp.texi: Mark TR14 omp_target_is_accessible status as "Y".

libgomp, docs: Fix misplaced pinned memory description

The NVPTX note about ompx_gnu_pinned_mem_alloc was accidentally placed in
the AMD GCN section.  This patch moves the paragraph to the NVPTX section.

However, the text was not actually wrong in the context of AMD GCN, so I've
adapted the wording, rather than removing it.

libgomp/ChangeLog:

* libgomp.texi: Separate the ompx_gnu_pinned_mem_alloc notes for
NVPTX and AMD GCN, and move them to right sections.

libphobos: Regenerate libdruntime/Makefile.am

Adds newly added modules, missed in the last upstream merge.

libphobos/ChangeLog:

* libdruntime/Makefile.am (DRUNTIME_DSOURCES): Add
core/internal/vararg/gnu.d.
(DRUNTIME_DSOURCES_LINUX): Add core/sys/linux/hdlc/ioctl.d,
core/sys/linux/net/if_.d.
(DRUNTIME_DSOURCES_SOLARIS): Add core/sys/solaris/sys/procfs.d,
core/sys/solaris/sys/regset.d, core/sys/solaris/thread.d.
* libdruntime/Makefile.in: Regenerate.

a68: fix function type in a68_lower_revelation_ludes

Turns out that:

   build_function_type_list (void_type_node, void_type_node, NULL_TREE)

doesn't do what I thought it does.  It resulted in a function type
getting two `void' arguments, and this was triggering a warning in LTO
mode.

Signed-off-by: Jose E. Marchesi <jemarch@gnu.org>
gcc/algol68/ChangeLog

* a68-low-clauses.cc (a68_lower_revelation_ludes): Fix function
type for fdecl.

aarch64: Add support for Hisilicon's hip12 core (-mcpu=hip12)

This patch adds initial support for Hisilicon's hip12 core
(Kunpeng 950 processor).
For more information, see:
https://www.huawei.com/en/news/2025/9/hc-xu-keynote-speech

Bootstrapped and tested on aarch64-linux-gnu, no regression.

Signed-off-by: xiezhiheng <xiezhiheng@huawei.com>
Co-authored-by: liyunfei <liyunfei33@huawei.com>
gcc/ChangeLog:

* config/aarch64/aarch64-cores.def (AARCH64_CORE): Add hip12 core
* config/aarch64/aarch64-cost-tables.h: Add hip12_extra_costs
* config/aarch64/aarch64-tune.md: Regenerate
* config/aarch64/aarch64.cc: Include hip12 tuning model
* doc/invoke.texi: Document -mcpu=hip12
* config/aarch64/tuning_models/hip12.h: New file.

RISC-V: Fix xtheadvector ratio attribute. [PR123870]

As reported in PR123870 we miscompile an RVV-optimized jpeg-quantsmooth
with xtheadvector.  The core issue is that we forget to emit a vsetvl
before a -fschedule-insn induced spill restore.  Spills are usually
handled by full-register loads and stores but xtheadvector doesn't have
those.  Instead, the regular loads and stores are used which differ from
full-register loads/store in the fact that they don't encode the LMUL
in the instruction directly and thus require a proper SEW and LMUL in
the vtype rather than just the ratio.

This patch makes vlds have an SEW/LMUL demand instead of a "ratio only"
demand for theadvector.

I didn't manage to come up with a simple test case, though.
PR123969 has a test but it won't fail without slight changes to the
16 codebase.  I'm still adding it for documentation and backport
reasons.

Regtested on rv64gcv_zvl512b.

PR target/123870
PR target/123969

gcc/ChangeLog:

* config/riscv/vector.md: Add vlds to "no ratio" for
theadvector.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/xtheadvector/pr123969.c: New test.

Signed-off-by: Robin Dapp <rdapp@oss.qualcomm.com>

RISC-V: Allow vector modes for xtheadvector. [PR123971]

In riscv_vector_mode_supported_any_target_p we disallow any vector mode
when TARGET_XTHEADVECTOR.
Things go wrong when we check if a permutation for a mode is supported
by just looking at the optab (e.g. in forwprop).  Then later we try to
expand that permutation but cannot find a related int vector mode because
we don't allow any vector mode.

Strictly speaking, this is fallout from the simplify_vector_constructor
changes but it's still a target issue as the common code has done the
proper check and we don't live up to the promise of being able to extend
a certain mode.

This patch just allows all modes in
riscv_vector_mode_supported_any_target_p, even for theadvector.

PR target/123971

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_vector_mode_supported_any_target_p):
Remove TARGET_XTHEADVECTOR.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/xtheadvector/pr123971.c: New test.

Signed-off-by: Robin Dapp <rdapp@oss.qualcomm.com>

forwprop: Handle nop-conversion for maybe_ident. [PR123925]

The same handling for nop conversions we did in the !maybe_ident case is
also necessary in for maybe_ident.  This patch performs the necessary
preprocessing before the if and unifies the nop-conversion handling.

PR tree-optimization/123925

gcc/ChangeLog:

* tree-ssa-forwprop.cc (simplify_vector_constructor):
Add nop-conversion handling for maybe_ident.

gcc/testsuite/ChangeLog:

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

Signed-off-by: Robin Dapp <rdapp@oss.qualcomm.com>

RISC-V: Disable small memsets for xtheadvector [PR123910].

This patch disables memsets with size less than a vector for
xtheadvector.  As xtheadvector does not support fractional
LMUL we need to ensure to not emit those vectors that might
use it.

PR target/123910

gcc/ChangeLog:

* config/riscv/riscv-string.cc (riscv_expand_block_move):
Remove !xtheadvector guard.
(use_vector_stringop_p): Guard small LMULs.
(check_vectorise_memory_operation): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/pr123910.c: New test.
* gcc.target/riscv/rvv/xtheadvector/pr114194-rv32.c: xfail.

Signed-off-by: Robin Dapp <rdapp@oss.qualcomm.com>

contrib/check-params-in-docs.py: Make compatible with params.texi

Update the check-params-in-docs.py script so that it works with params
newly being documented in params.texi instead of in invoke.texi.

Committing as obvious.

contrib/ChangeLog:

* check-params-in-docs.py: Extend architecture-specific options
filtering.  Remove the mechanism for seeking to the param
section.

Signed-off-by: Filip Kastl <fkastl@suse.cz>

a68: make SET, CLEAR and TEST bits operators zero-based

After some discussion at the working group we have decided that the
bits operators SET, CLEAR and TEST, which are a GNU extension, shall
get bit numbers which are zero-based rather than one-based.

Signed-off-by: Jose E. Marchesi <jemarch@gnu.org>
gcc/algol68/ChangeLog

* a68-low-bits.cc (a68_bits_set): Make bit number zero-based rathe
than one-based.
(a68_bits_clear): Likewise.
(a68_bits_test): Likewise.
* ga68.texi (Extended bits operators): Adapt documentation
accordingly.

gcc/testsuite/ChangeLog

* algol68/execute/bits-clear-1.a68: Adapt test to new CLEAR
semantics.
* algol68/execute/bits-set-1.a68: Likewise for SET.
* algol68/execute/bits-test-1.a68: Likewise for TEST.

a68: fix bit-shift standard operators [PR algol68/123959]

In Standard Algol 68:

- ABS (b) < bits_width results in the expected result.
- ABS (b) = bits_width results in all bits set to zero.
- ABS (b) > bits_width is undefined.

In GNU algol 68:

- ABS (b) < bits_width results in the expected result.
- ABS (b) >= bits_width results in all bits set to zero.

Our behavior is:

1. Conformant and backwards compatible.

2. Matches well with the similar extension of skip of integral, bits,
   real, etc values to always yield zeroes.

3. Intuitive.

This patch fixes the lowering of the standard operators SHR and SHL
accordingly, including an update for the manual and a few tests.

Signed-off-by: Jose E. Marchesi <jemarch@gnu.org>
gcc/algol68/ChangeLog

PR algol68/123959
* a68.h: Expand prototype of a68_bits_shift to get a node argument
for location purposes.
* a68-low-bits.cc (a68_bits_shift): Implement RR compatible
semantics.
* a68-low-prelude.cc (a68_lower_shl3): Fix call to a68_bit_shift.
(a68_lower_shr3): Likewise.
* ga68.texi (Bits operators): Fix documentation of SHR and SHL.

gcc/testsuite/ChangeLog

PR algol68/123959
* algol68/execute/bits-shift-1.a68: New test.
* algol68/execute/bits-shift-2.a68: Likewise.
* algol68/execute/bits-shift-3.a68: Likewise.

Add -ffuse-ops-with-volatile-access: Adjust 'gcc.target/nvptx/alloca-5.c' [PR122343]

With commit r16-5947-ga6c50ec2c6ebcbda2b032eee0552a6a486355e12
"Add -ffuse-ops-with-volatile-access", GCC/nvptx avoids use of intermediate
registers in applicable cases (nice!).  This causes one test suite regression:

    PASS: gcc.target/nvptx/alloca-5.c (test for excess errors)
    XFAIL: gcc.target/nvptx/alloca-5.c execution test
    [-PASS:-]{+FAIL:+} gcc.target/nvptx/alloca-5.c check-function-bodies f
    PASS: gcc.target/nvptx/alloca-5.c check-function-bodies g

Adjust the FAILing 'check-function-bodies' as per the improved code generation.

PR target/122343
gcc/testsuite/
* gcc.target/nvptx/alloca-5.c: Adjust.

tree-optimization/121726 - TBAA bug with SRA of address-taken decls

The following fixes re-materialization of aggregates before calls
that take the address of a scalarized decl.  The issue here is that
we do not know the appropriate effective type to use for the stores.
So we use ref-all accesses for the re-materialization to properly
support TBAA info modref might have recorded.  The same holds
true for the re-load after the call.

PR tree-optimization/121726
* tree-sra.cc (build_ref_for_offset): Add force_ref_all
parameter and use ptr_type_node as alias pointer type in
that case.
(build_ref_for_model): Add force_ref_all parameter and
pass it through, forcing build_ref_for_offset.
(generate_subtree_copies): Likewise.
(sra_modify_call_arg): Force ref-all accesses.

* gcc.target/i386/pr121726.c: New testcase.

middle-end: use inner variable when determining deferred FMA order [PR123898]

If we defer an FMA creation the code tries to determine the order of the
operands before deferring.  To do this it compares the operands against the
result expression (which should contain the multiplication expression).

However the multiply might be wrapped in a conversion.  This change has us strip
one level of conversion (the most that convert_mult_to_fma) supports handling
and only then do the comparison.

We cannot strip ops[0] and ops[1] and store them stripped since after the
deferrence, if we create an FMA we need to know the original types and
convert_mult_to_fma handles the conversions during FMA creation anyway.

There's probably a similar helper to strip_nop_view_converts but I couldn't
find one, since many of the stripping helpers are recursive or don't support
stripping VIEW_CONVERTS.

gcc/ChangeLog:

PR tree-optimization/123898
* tree-ssa-math-opts.cc (strip_nop_view_converts): New.
(convert_mult_to_fma): Use it.

gcc/testsuite/ChangeLog:

PR tree-optimization/123898
* gcc.target/aarch64/sve/pr123898.c: New test.

testsuite: aarch64: state pr122103_1.c requirements [PR123936]

The execution testcase needed SVE support but didn't state that as a
requirement.  Add it.

for  gcc/testsuite/ChangeLog

PR testsuite/123936
PR tree-optimization/122103
* gcc.target/aarch64/sve/pr122103_1.c: Add sve hw requirement.

testsuite: aarch64: state pr123775.c requirements

The execution testcase requires sve2 and 128-bit sve hardware, but it
doesn't state those requiremnets.  I'm think the latter is implied by
the former, but I'm not entirely sure, so I'm requiring both
explicitly.

for  gcc/testsuite/ChangeLog

PR middle-end/123775
* gcc.target/aarch64/sve2/pr123775.c: Add sve128 and sve2 hw
requirements.

testsuite: require hostedlib for pr123729.C

This testcase uses features not available when libstdc++ doesn't have
the hostedlib bits enabled.

for  gcc/testsuite/ChangeLog

PR tree-optimization/123729
* g++.dg/torture/pr123729.C: Require hostedlib.

simplify-rtx: fix riscv redundant-bitmap-2.C

The insn simplification expected by the test, to get a bset
instruction, has been prevented since r15-9239, because we get rotates
for bit clear and shifts for bit flip, and we don't know how to
simplify those.

Teach the rtl simplifier, at the spots where it had been extended to
handle these logical simplifications, to also handle these less
obvious negations.

for  gcc/ChangeLog

* simplify-rtx.cc (negated_ops_p): New.
(simplify_context::simplify_binary_operation_1): Use it.