I've totally missed the P3491R3 paper (define_static_{string,object,array})
comes with its own feature test macro - __cpp_lib_define_static 202506
which should appear in <version> and <meta>.
The paper contains 3 parts, std::is_string_literal,
std::meta::reflect_constant_{string,array} and
std::define_static_{string,object,array}.
The first part is implementable without reflection, the third part in theory
would be also implementable without reflection but usually will be (and in
libstdc++ is) implemented using reflection, and the middle part is really
part of reflection. So dunno how useful this FTM actually is, maybe just
for cases where some implementation does implement reflection and doesn't
implement this paper for a while.
Anyway, the FTM is in C++26 draft, so this patch adds it, with the same
condition as __cpp_lib_reflection.
2026-02-03 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/123921
* include/bits/version.def (define_static): New with the
same values as reflection.
* include/bits/version.h: Regenerate.
* include/std/meta: Define also __glibcxx_want_define_static before
including bits/version.h.
* g++.dg/reflect/feat2.C: Add also test for __cpp_lib_define_static.
* g++.dg/reflect/feat3.C: New test.
This patch extends omp_target_is_accessible to check the actual device status
for the memory region, on amdgcn and nvptx devices (rather than just checking
if shared memory is enabled).
In both cases, we check the status of each 4k region within the given memory
range (assuming 4k pages should be safe for all the currently supported hosts)
and returns true if all of the pages report accessible.
The testcases have been modified to check that allocations marked accessible
actually are accessible (inaccessibility can't be checked without invoking
memory faults), and to understand that some parts of an array can be accessible
but other parts not (I have observed this intermittently for the stack memory
on amdgcn using the Fortran testcase, which can have the allocation span pages).
There's also new testcases for the various other memory modes, and for managed
memory.
include/ChangeLog:
* cuda/cuda.h (CUpointer_attribute): New enum.
(cuPointerGetAttribute): New prototype.
libgomp/ChangeLog:
PR libgomp/121813
PR libgomp/113213
* libgomp-plugin.h (GOMP_OFFLOAD_is_accessible_ptr): New prototype.
* libgomp.h
(struct gomp_device_descr): Add GOMP_OFFLOAD_is_accessible_ptr.
* libgomp.texi: Update omp_target_is_accessible docs.
* plugin/cuda-lib.def (cuPointerGetAttribute): New entry.
* plugin/plugin-gcn.c (struct hsa_runtime_fn_info): Add
hsa_amd_svm_attributes_get_fn and hsa_amd_pointer_info_fn.
(init_hsa_runtime_functions): Add hsa_amd_svm_attributes_get and
hsa_amd_pointer_info.
(enum accessible): New enum type.
(host_memory_is_accessible): New function.
(device_memory_is_accessible): New function.
(GOMP_OFFLOAD_is_accessible_ptr): New function.
* plugin/plugin-nvptx.c (GOMP_OFFLOAD_is_accessible_ptr): Likewise.
* target.c (omp_target_is_accessible): Call is_accessible_ptr_func.
(gomp_load_plugin_for_device): Add is_accessible_ptr.
* testsuite/libgomp.c-c++-common/target-is-accessible-1.c: Rework
to match more details of the GPU implementation.
* testsuite/libgomp.fortran/target-is-accessible-1.f90: Likewise.
* testsuite/libgomp.c-c++-common/target-is-accessible-2.c: New test.
* testsuite/libgomp.c-c++-common/target-is-accessible-3.c: New test.
* testsuite/libgomp.c-c++-common/target-is-accessible-4.c: New test.
* testsuite/libgomp.c-c++-common/target-is-accessible-5.c: New test.
afunix.h was first included in MinGW 10.0.0. For earlier versions, fall
back to internal definition.
gcc/ChangeLog:
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac (gcc_cv_header_afunix_h): New test.
(HAVE_AFUNIX_H): New AC_DEFINE.
* diagnostics/sarif-sink.cc: Conditionally include afunix.h
if it's available, else fall back to internal definition.
Richard Biener [Tue, 3 Feb 2026 08:26:01 +0000 (09:26 +0100)]
ipa/123416 - fix IPA modref summary merging after inlining
There's a typo in the condition skipping load collapsing when
there's no callee modref summary. We do have to collapse loads
for the destination iff the callee performs any loads which includes
when the callee is ECF_PURE. The LTO summary part already gets
this correct.
PR ipa/123416
* ipa-modref.cc (ipa_merge_modref_summary_after_inlining):
Fix typo in condtion for load merging when no callee summary.
Jakub Jelinek [Tue, 3 Feb 2026 08:19:19 +0000 (09:19 +0100)]
c++: Fix UB in eval_data_member_spec [PR123920]
We can overflow buffer in eval_data_member_spec on some initializers.
The code has 2 loops, one to figure out the needed length
of the buffer and diagnose errors
unsigned HOST_WIDE_INT l = 0;
bool ntmbs = false;
FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (f), k, field, value)
if (!tree_fits_shwi_p (value))
goto fail;
else if (field == NULL_TREE)
{
if (integer_zerop (value))
{
ntmbs = true;
break;
}
++l;
}
else if (TREE_CODE (field) == RANGE_EXPR)
{
tree lo = TREE_OPERAND (field, 0);
tree hi = TREE_OPERAND (field, 1);
if (!tree_fits_uhwi_p (lo) || !tree_fits_uhwi_p (hi))
goto fail;
if (integer_zerop (value))
{
l = tree_to_uhwi (lo);
ntmbs = true;
break;
}
l = tree_to_uhwi (hi) + 1;
}
else if (tree_fits_uhwi_p (field))
{
l = tree_to_uhwi (field);
if (integer_zerop (value))
{
ntmbs = true;
break;
}
++l;
}
else
goto fail;
if (!ntmbs || l > INT_MAX - 1)
goto fail;
which assumes that if there are designators, they need to be ascending,
so no { [10] = 1, [2] = 3, [6] = 4, [4] = 5 } like in C11 and stops on the
first '\0' seen (but remember in l the index of that. Here we need the
3 integer_zerop calls because the exact setting of l depends on if it is
an elt without index, or with RANGE_EXPR index, or with normal INTEGER_CST
index. And then there is a second loop where it just stores the values
into the allocated buffer and does rely on the checking the first loop
did. Now, for CONSTRUCTORs without indexes or with RANGE_EXPR only it
also correctly stops at '\0', but I forgot to check that in the last
case where index is INTEGER_CST:
char *namep;
unsigned len = l;
if (l < 64)
namep = XALLOCAVEC (char, l + 1);
else
namep = XNEWVEC (char, l + 1);
memset (namep, 0, l + 1);
l = 0;
FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (f), k, field, value)
if (field == NULL_TREE)
{
if (integer_zerop (value))
break;
namep[l] = tree_to_shwi (value);
++l;
}
else if (TREE_CODE (field) == RANGE_EXPR)
{
tree lo = TREE_OPERAND (field, 0);
tree hi = TREE_OPERAND (field, 1);
if (integer_zerop (value))
break;
unsigned HOST_WIDE_INT m = tree_to_uhwi (hi);
for (l = tree_to_uhwi (lo); l <= m; ++l)
namep[l] = tree_to_shwi (value);
}
else
{
l = tree_to_uhwi (field);
namep[l++] = tree_to_shwi (value);
}
namep[len] = '\0';
So, I could add if (integer_zerop (value) break; into the else
block, but then, in this loop there is no reason not to check integer_zerop
(value) first because it is handled in all 3 cases the same.
2026-02-03 Jakub Jelinek <jakub@redhat.com>
PR c++/123920
* reflect.cc (eval_data_member_spec): Break out of the loop
if value is integer_zerop even in the field
&& TREE_CODE (field) != RANGE_EXPR case and use a single
test for integer_zerop (value) in the whole loop.
Jakub Jelinek [Tue, 3 Feb 2026 08:18:34 +0000 (09:18 +0100)]
c++: Don't call cpp_translate_string on NULL string [PR123918]
My P2246R1 patch caused diagnostics reported by running ubsan
instrumented compiler on cpp26/static_assert1.C - if len is 0,
we don't bother to allocate msg, so it stays NULL, and when I've added
cpp_translate_string call, that can invoke memcpy (something, NULL, 0);
in that case.
While that is no longer UB in C2Y since N3322, libsanitizer doesn't
know that yet and reports it anyway.
While we could just do
if (len)
{
...
}
else
msg = "";
there is really no point in trying to translate "" and allocate memory
for that, so the following patch instead by passes that translation for
len == 0.
2026-02-03 Jakub Jelinek <jakub@redhat.com>
PR c++/123918
* semantics.cc (cexpr_str::extract): Bypass cpp_translate_string
for len == 0.
Eric Botcazou [Tue, 3 Feb 2026 07:45:23 +0000 (08:45 +0100)]
Ada: Fix couple of small accessibility glitches
The first glitch is that the ACATS test c3a0025 does not pass in Ada 2005
because an accessibility check preempts a null access check. The second
glitch is that there should be no differences in Ada 2012 and later for
the test, in other words there is a missing accessibility check failure.
The second glitch comes from a thinko in the new implementation of the
In_Return_Value predicate, which has incorrectly dropped the handling of
assignments to return objects.
The first glitch is fixed by swapping the order of null access checks and
accessibility checks for conversions, which requires adding a small guard
to Apply_Discriminant_Check.
gcc/ada/
* checks.adb (Apply_Discriminant_Check): Bail out for a source type
that is a class-wide type whose root type has no discriminants.
* exp_ch4.adb (Expand_N_Type_Conversion): If the target type is an
access type, emit null access checks before accessibility checks.
* sem_util.adb (In_Return_Value): Deal again with assignments to
return objects.
Xi Ruoyao [Thu, 29 Jan 2026 09:08:02 +0000 (17:08 +0800)]
LoongArch: rework copysign and xorsign implementation
The copysign and xorsign implementation had two significant bugs:
1. The GCC Internal documentation explicitly says the IOR, XOR, and AND
optabs are only for fixed-point modes, i.e. they cannot be used for
floating-point modes.
2. The handling of "%V" uses a very nasty way to pun floating-point
const value to integer representation, invoking undefined behavior on
32-bit hosts by shifting left a "long" by 32 bits. In fact
lowpart_subreg handles punning of const values correctly despite the
name contains "reg."
Fix the bugs by using lowpart_subreg to pun the modes in the expanders.
gcc/
* config/loongarch/predicates.md (const_vector_neg_fp_operand):
New define_predicate.
(reg_or_vector_neg_fp_operand): New define_predicate.
* config/loongarch/lasx.md (copysign<mode>3): Remove.
(xorsign<mode>3): Remove.
* config/loongarch/lsx.md (copysign<mode>3): Remove.
(@xorsign<mode>3): Remove.
* config/loongarch/simd.md (copysign<mode>3): New define_expand.
(@xorsign<mode>3): New define_expand.
(and<mode>3): Only allow IVEC instead of ALLVEC.
(ior<mode>3): Likewise.
(xor<mode>3): Likewise.
* config/loongarch/loongarch.cc (loongarch_print_operand): No
longer allow floating-point vector constants for %V.
(loongarch_const_vector_bitimm_set_p): Always return false for
floating-point vector constants.
(loongarch_build_signbit_mask): Factor out force_reg.
(loongarch_emit_swrsqrtsf): Use integer vector mode instead of
floating-point vector mode when masking zero inputs.
David Malcolm [Mon, 2 Feb 2026 23:14:11 +0000 (18:14 -0500)]
diagnostics: respect dumpdir when outputting SARIF and HTML file [PR110522]
PR diagnostics/110522 notes that when generating the output path for
diagnostics in SARIF or HTML form, the compiler ignores the path for the
compiler output, leading to race conditions and overwritten SARIF output
when compiling the same source file multiple times in a build.
my intent was for the sarif sink to write to "build-dir/foo.c.sarif",
but in GCC 13 - GCC 15 it writes to "foo.c.sarif" instead.
The driver adds the option "-dumpdir build-dir" when invoking cc1, and
opts.cc's finish_options has the logic to prepend the dump_dir_name to
the dump_base_name, which in theory ought to have affected the name for
SARIF output. The root cause is that finish_options is called *after*
processing the options for creating the diagnostic sinks, and so the
sarif_sink is created when dump_base_name is "foo.c", and thus
writes to "foo.c.sarif", rather than "build-dir/foo.c.sarif".
This patch introduces a new helper function for accessing the base name
for diagnostic sinks and refactors the prepending logic
in finish_options so that it is also used when creating diagnostic
sinks, so that in the above example the SARIF is written to
"build-dir/foo.c.sarif".
The patch took the number of .sarif files generated by the analyzer
integration tests from 5094 to 11309. The most extreme example I could
find within them was where we previously got a single .sarif file:
qemu-7.2.0/build/fpu_softfloat.c.c.sarif
and *with* the patch we get 66 .sarif files:
qemu-7.2.0/build/libqemu-aarch64-linux-user.fa.p/fpu_softfloat.c.c.sarif
qemu-7.2.0/build/libqemu-aarch64-softmmu.fa.p/fpu_softfloat.c.c.sarif
[...snip lots of different architectures...]
qemu-7.2.0/build/libqemu-xtensaeb-linux-user.fa.p/fpu_softfloat.c.c.sarif
qemu-7.2.0/build/libqemu-xtensaeb-softmmu.fa.p/fpu_softfloat.c.c.sarif
which presumably were previously all being written to the same place
during the build. Indeed, the old file is invalid JSON, and appears to
have been truncated.
gcc/ChangeLog:
PR diagnostics/110522
* gcc.cc (driver_handle_option): Use
get_diagnostic_file_output_basename for
OPT_fdiagnostics_format_.
* opts-diagnostic.cc (get_base_filename): Likewise.
(get_diagnostic_file_output_basename): New.
* opts-diagnostic.h (get_diagnostic_file_output_basename): New
decl.
* opts.cc (maybe_prepend_dump_dir_name): New, based on code in
finish_options.
(finish_options): Move code for determining prepended
dump_base_name to maybe_prepend_dump_dir_name and call it.
(common_handle_option): Use get_diagnostic_file_output_basename
for OPT_fdiagnostics_format_.
* opts.h (maybe_prepend_dump_dir_name): New decl.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Eric Botcazou [Mon, 2 Feb 2026 18:40:33 +0000 (19:40 +0100)]
Ada: Fix profile conformance glitch with limited_with and incomplete type
That's an old issue, but the fix is quite straightforward.
gcc/ada/
PR ada/89159
* sem_ch6.adb (Conforming_Types.Is_Matching_Limited_View): Return
true when the type is an incomplete view of the non-limited view.
gcc/testsuite/
* gnat.dg/limited_with8.adb: New test.
* gnat.dg/limited_with8_pkg1.ads: New helper.
* gnat.dg/limited_with8_pkg2.ads: Likewise.
* gnat.dg/limited_with8_pkg2.adb: Likewise.
Andrew Pinski [Sun, 1 Feb 2026 23:41:52 +0000 (15:41 -0800)]
ifcvt: Fix store flag of XImode on aarch64 while ifcvt [PR123294]
In the testcase ifcvt is trying to do a emit_store_flag into a XImode.
That will cause an ICE because XImode does not have any arithmetic optabs
associated with it. This is because it is greater than MAX_FIXED_MODE_SIZE
(along other things).
noce_emit_store_flag already has code to reject non-scalar modes, so
this adds a new check for modes that are greater than MAX_FIXED_MODE_SIZE.
Bootstrapped and tested on aarch64-linux-gnu.
PR rtl-optimization/123294
gcc/ChangeLog:
* ifcvt.cc (noce_emit_store_flag): Reject modes
greater than MAX_FIXED_MODE_SIZE.
gcc/testsuite/ChangeLog:
* gcc.dg/pr123294-1.c: New test.
* gcc.target/aarch64/pr123294-1.c: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Marek Polacek [Sun, 1 Feb 2026 23:06:20 +0000 (18:06 -0500)]
c++/reflection: fix ICE with object_of [PR123695]
In eval_object_of we are calling cxx_eval_constant_expression on
references to get the referent. We should check that the type is
non-null before checking TYPE_REF_P, because for invalid arguments
it can be null, as shown in the test.
PR c++/123695
gcc/cp/ChangeLog:
* reflect.cc (eval_object_of): Check type before TYPE_REF_P.
gcc/testsuite/ChangeLog:
* g++.dg/reflect/object_of3.C: New test.
Co-authored-by: Boris Staletic <boris.staletic@protonmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Marek Polacek [Sun, 1 Feb 2026 20:20:55 +0000 (15:20 -0500)]
c++/reflection: wrong error with const meta::info parm [PR123614]
Here we issue a bogus "not a constant expression" error ultimately
because get_info returns NULL_TREE for the const parameter in Name.
The cxx_eval_constant_expression in get_info produces a NOP_EXPR:
(info) reflect_expr <int>
which is not REFLECT_EXPR_P. This isn't caught by the
REFLECTION_TYPE_P && REFLECT_EXPR_P check in _eval_constant_expression
because OP is a NOP_EXPR. The NOP_EXPR comes from adjust_temp_type.
I suppose I could just add STRIP_NOPS to get_info. Or I could follow
c++/65695 / r6-41-gfb899e32c16088 and adjust cp_fold_convert to fold
away the conversion.
PR c++/123614
gcc/cp/ChangeLog:
* cvt.cc (cp_fold_convert): Avoid wrapping a REFLECT_EXPR in NOP_EXPR.
Tamar Christina [Mon, 2 Feb 2026 11:03:53 +0000 (11:03 +0000)]
middle-end: use destination type when folding addent [PR123897]
Previously the types of the 3 operands would always be the same when you get to
convert_mult_to_fma_1. However now they can differ untill we fold them to be the
same. Using the type of the final expression is thus incorrect and any
intermediate operations need to happen in the type of the expression being
folded.
gcc/ChangeLog:
PR tree-optimization/123897
* tree-ssa-math-opts.cc (convert_mult_to_fma_1): Use type of variable
being folded.
gcc/testsuite/ChangeLog:
PR tree-optimization/123897
* gcc.target/aarch64/sve/pr123897.c: New test.
Tamar Christina [Mon, 2 Feb 2026 10:59:11 +0000 (10:59 +0000)]
AArch64: remove setting scalar dup analysis flag back to false [PR121290]
The final loop in the PR s313 is fixed by removing he else branch that shouldn't
be there now that we look at a ratio of dups instead of a yes/no.
By setting m_loop_fully_scalar_dup the final costing doesn't think there's any
dup at all in the inner loop costing.
This returns the codegen to what it was for GCC 15. However as the PR mentions
with the broken costing -O3 did improve. The reason for this was that it was
preventing unrolling at -O3.
Which is silly due to the limited throughput of the instructions in this loop.
the left fold reduction is a single cycle reduction since the unrolling needs
the accumulation to happen in the same scalar.
However aarch64_force_single_cycle doesn't detected this and so the costing of
the loop is wrong. Even fixing that though the cost model does still think it's
beneficial because the throughput restrictions for the reductions aren't modeled
but to get it to reject the unrolling the cost have to be increased
unrealistically.
The better approach I think would be for us to model pipeline restrictions more
such that we have the ability to say that the above is a linear reduction chain.
However since that's not a regression and needs quite a bit of work, punted to
GCC 17.
As the following testcase shows, I've missed a check that element type
of lhs type of ovf1/ovf2 (.ADD_OVERFLOW/.SUB_OVERFLOW) matches type (there
are some casts accepted on the way for the case of values in [0-1] range),
so the following testcase got also matched as .SUBC and we get an ICE on
type mismatch in there. The other .{ADD,SUB}_OVERFLOW cases already check
even the result type, both
if (gimple_call_internal_p (ovf, code == PLUS_EXPR
? IFN_ADD_OVERFLOW
: IFN_SUB_OVERFLOW))
...
ovf_lhs = gimple_call_lhs (ovf);
tree ovf_lhs_type = TREE_TYPE (TREE_TYPE (ovf_lhs));
ovf_arg1 = gimple_call_arg (ovf, 0);
ovf_arg2 = gimple_call_arg (ovf, 1);
/* In that case we need to punt if the types don't
mismatch. */
if (!types_compatible_p (type, ovf_lhs_type)
|| !types_compatible_p (type, TREE_TYPE (ovf_arg1))
|| !types_compatible_p (type,
TREE_TYPE (ovf_arg2)))
ovf_lhs = NULL_TREE;
and
gimple *ovf3
= SSA_NAME_DEF_STMT (TREE_OPERAND (gimple_assign_rhs1 (im3), 0));
if (gimple_call_internal_p (ovf3, ifn))
{
lhs = gimple_call_lhs (ovf3);
arg1 = gimple_call_arg (ovf3, 0);
arg2 = gimple_call_arg (ovf3, 1);
if (types_compatible_p (type, TREE_TYPE (TREE_TYPE (lhs)))
&& types_compatible_p (type, TREE_TYPE (arg1))
&& types_compatible_p (type, TREE_TYPE (arg2)))
2026-02-02 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/121104
* tree-ssa-math-opts.cc (match_uaddc_usubc): Punt if
lhs of ovf1 or ovf2 doesn't have element type compatible with type.
Signed-off-by: Jose E. Marchesi <jemarch@gnu.org>
gcc/algol68/ChangeLog
* a68-low-bits.cc (a68_bits_test): Do not get a parameter with the
result moid.
* a68.h: Adapt prototype of a68_bits_test accordingly.
* a68-low-prelude.cc (a68_lower_test3): Adjust call accordingly.
Note how the "inproc" export flag is not set. This causes the
resulting applied identifier in calls to fclose to be lowered to a
VAR_DECL rather than a FUNCTION_DECL, resulting in an indirect call.
This patch makes the parser to mark identity declarations of proc
modes whose actual parameters are formal holes as "inproc".
Signed-off-by: Jose E. Marchesi <jemarch@gnu.org>
gcc/algol68/ChangeLog
* a68.h: Prototype for a68_make_proc_formal_hole_decl.
* a68-parser-extract.cc (extract_identities): Mark identity
declarations of proc modes whose actual parameter is a formal hole
as "inproc".
* a68-low.cc (a68_make_proc_formal_hole_decl): New function.
* a68-low-units.cc (a68_lower_formal_hole): Call
a68_make_proc_formal_hole_decl whenever necessary.
Eric Botcazou [Sun, 1 Feb 2026 19:31:41 +0000 (20:31 +0100)]
Ada: Fix prefixed-view notation rejected for discriminated private type
The problem comes from an oversight in Analyze_Selected_Component.
gcc/ada/
PR ada/123902
* sem_ch4.adb (Analyze_Selected_Component): Also test
Core_Extensions_Allowed for discriminated private types.
Rework and augment commentary throughout the procedure.
gcc/testsuite/
* gnat.dg/prefix4.adb: New test.
* gnat.dg/prefix4_pkg.ads: New helper.
Richard Biener [Fri, 30 Jan 2026 07:19:06 +0000 (08:19 +0100)]
tree-optimization/123755 - more (len-)masked call fixes
The testcase shows that we end up with (len-)masking a call even
when not semantically necessary. The following aligns the condition
to apply len-masking with the condition to apply loop-masking, adjusting
downstream conditions to look at the chosen ifn instead of replicating
a possibly complex decision.
Alexandre Oliva [Sun, 1 Feb 2026 07:36:00 +0000 (04:36 -0300)]
testsuite: skip pr118817 over unmet hostedlib needs
The test for -shared support doesn't fail on riscv64-elf, unlike other
barebones targets including riscv32-elf (testing with -fpic -shared
overflows HI20 relocs) that don't enable a hosted libstdc++.
This test thus got skipped on those other platforms, but we still
gave it a shot on riscv64-elf, and then it failed because libstdc++
doesn't have all the headers enabled that the test requires.
Alexandre Oliva [Sun, 1 Feb 2026 07:35:56 +0000 (04:35 -0300)]
testsuite: riscv: pr110812_*.c needs medany on rv32
When linking the pr110812 units with lto after compiling them with a
riscv(32?) compiler that defaults to the medlow code model, the
compiler uses HI20 relocations that overflow with our linker scripts.
I suppose the test expects PC-relative relocations for symbol
resolution, as in the medany code model, so select that explicitly.
for gcc/testsuite/ChangeLog
* gcc.target/riscv/lto/pr110812_0.c: Set cmodel explicitly.
* gcc.target/riscv/lto/pr110812_1.c: Likewise.
Alexandre Oliva [Sun, 1 Feb 2026 07:35:41 +0000 (04:35 -0300)]
testsuite: riscv: pr118170 goes 64-bit without choosing a 64-bit abi
The test selects a 64-bit cpu explicitly, which enables a 64-bit arch,
but the test doesn't set the abi, so it fails on riscv32-elf. Set a
64-bit abi explicitly.
for gcc/testsuite/ChangeLog
* gcc.target/riscv/pr118170.c: Set the abi explicitly.
Alexandre Oliva [Sun, 1 Feb 2026 07:35:33 +0000 (04:35 -0300)]
testsuite: riscv: set expected code model for pr113206-2.c
With a compiler that defaults to cmodel medany, pr113206-2.c ends up
generating an extra vsetvli insn.
Set the code model explicitly to medlow to meet the expectation.
This is unfortunately not enough to get the test to a pass on trunk.
It is on gcc-15 and the change is an improvement, but trunk still gets
an unexpected vsetvli even with the change.
for gcc/testsuite/ChangeLog
* gcc.target/riscv/rvv/autovec/pr113206-2.c: Set the expected
code model explicitly.
Alexandre Oliva [Sun, 1 Feb 2026 07:35:30 +0000 (04:35 -0300)]
testsuite: riscv: set expected code model
When testing a compiler configured to default to the medany code
model, riscv autovec binop vadd and vsub -nofm tests fail because
their codegen expectations don't match the generated code.
Set the code model to the medlow model that the tests expect.
for gcc/testsuite/ChangeLog
* gcc.target/riscv/rvv/autovec/binop/vadd-rv32gcv-nofm.c: Set the
expected code model explicitly.
* gcc.target/riscv/rvv/autovec/binop/vadd-rv64gcv-nofm.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vsub-rv32gcv-nofm.c: Likewise.
* gcc.target/riscv/rvv/autovec/binop/vsub-rv64gcv-nofm.c: Likewise.
Alexandre Oliva [Sun, 1 Feb 2026 07:35:23 +0000 (04:35 -0300)]
testsuite: riscv: disable scheduling for rvv/autovec/bug-3.c
Combine was prevented for some time from combining two ashifts when
the substituted insn couldn't be removed, and r15-7801 changed the
expectations to match.
Combine was later allowed to combine such insns, and the scheduler
reorders the insns so that the expected function body doesn't match.
I've added options to disable scheduling, and I've restored the
combine expectation.
for gcc/testsuite/ChangeLog
* gcc.target/riscv/rvv/autovec/bug-3.c: Disable scheduling,
and restore expectation of slli combine.
When running a riscv(32|64)-elf-targeting compiler on a
x86_64-linux-gnu with valgrind-3.18.1, it prints a multi-line warning
about an unhandled syscall, but the test works if we ignore those
lines to avoid an excess errors failure.
I've thus arranged for relevant pieces of the valgrind warning to be
pruned.
Alexandre Oliva [Sun, 1 Feb 2026 07:35:09 +0000 (04:35 -0300)]
testsuite: riscv: adjust/xfail dynamic-lmul tests
While investigating riscv*-elf testsuite failures in gcc-15, I found
mainline still had failures for a number of the dynamic-lmul tests I
investigated, though not always the same as gcc-15 due to other
changes. Here are some adjustments to the tests, whether updates or
xfails, to fix or silence the failures for gcc-16, respectively.
* dynamic-lmul4-3.c: r16-843 had bumped the "Maximum lmul = 2" count,
which was reasonable then, but subsequent changes in e.g. r16-2515
restored the original count, so revert that expectation.
* dynamic-lmul4-7.c: SLP improvements seem to have caused us to find
more live V_REGs during analysis, so we choose 1 instead of 2 for
lmul. Because of additional live V_REGs, AFAICT introduced by SLP, we
lower the RVV mode choice twice rather than the expected once. Since
the SLP improvements AFAICT make the code worse, at least for leading
to a lower lmul choice, I'm marking these two deviations as expected
failures.
* dynamic-lmul4-5.c: Like 4-7, this one regressed in the lmul choice
due to extra live V_REGs, and thus got extra messages about preferring
a lower lmul. As for the start/end patterns, I can't tell what they
were meant to test, but the live V_REGs have changed so significantly,
and are so likely to keep changing, that I figured we're better off
dropping those failing expectations. This is the only test that had
them.
* dynamic-lmul4-6.c: For some reason I haven't tried to figure out,
but I guess it also has to do with SLP improvements, the "Maximum lmul
= [24]" messages are no longer printed after "Update local program
points for bb 6" for this test, so I'm XFAILing them, because that
feels like a regression even though we end up with the expected lmul.
* dynamic-lmul4-8.c: Same as 4-6.
* dynamic-lmul8-10.c: I haven't tried to figure out why the initial
maximum lmul estimate has fallen from 8 to 4, despite the V_REG's
count being (proportionally) the same and fitting, but we still choose
8 for lmul, so I'm dropping the requirement for an 'lmul = 8' match
under the tentative conclusion that the expectation is unnecessary.
* dynamic-lmul8-12.c: Same as 8-10 and 4-6.
* pr113112-3.c: We get a much higher lmul (m8) than expected (m2), for
the same e32 element size, but the generated code is far too much
larger and hairier. While the lmul bump is probably a welcome
improvement, the expected choice of return instruction isn't found,
and I can't tell why the test prefers one over the other, so I'm
XFAILing all of them.
* pr113112-4.c: We get a lower lmul than expected, but that
expectation was different before r15-639, and we get what we used to
expect before that change. Since we could do better at some point,
I'm XFAILing it.
for gcc/testsuite/ChangeLog
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-3.c: Revert
Maximum lmul = 2 count.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-7.c: XFAIL
unmet lmul selection expectations.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-5.c: Likewise,
and drop start/end patterns.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-6.c: XFAIL
missing Maximum lmul messages.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-8.c: Likewise.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-12.c: Drop
Maximum lmul = 8 message. Likewise.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-10.c: Likewise.
* gcc.dg/vect/costmodel/riscv/rvv/pr113112-3.c: XFAIL unexpected
selections of lmul, and of return insn.
* gcc.dg/vect/costmodel/riscv/rvv/pr113112-4.c: XFAIL unexpected
selection of lmul.
c++: Fix error recovery after export keyword [PR121832]
When we enter cp_parser_explicit_template_declaration with the following
tokens being 'template <>', we never parse a parameter list and so with
-fconcepts we crash dereferencing a null pointer. This can currently
only happen after a non-modules 'export' declaration, as all other paths
check early for this case.
PR c++/121832
gcc/cp/ChangeLog:
* parser.cc (cp_parser_explicit_template_declaration): Check for
null.
Jose E. Marchesi [Sat, 31 Jan 2026 17:34:11 +0000 (18:34 +0100)]
a68: add TEST operator for bits to expanded prelude
This patch adds support for a TEST operator for L bits. Documentation
and tests are included.
Signed-off-by: Jose E. Marchesi <jemarch@gnu.org>
gcc/algol68/ChangeLog
* a68.h: Prototypes for a68_bits_test and a68_lower_test3.
* a68-low-bits.cc (a68_bits_test): New function.
* a68-low-prelude.cc (a68_lower_test3): Likewise.
* a68-parser-prelude.cc (gnu_prelude): Declare TEST operators and
their priority.
* ga68.texi (Extended bits operators): New section.
Jose E. Marchesi [Fri, 30 Jan 2026 10:41:05 +0000 (11:41 +0100)]
a68: add SET and CLEAR operators for L bits
This commit adds two more operators to the extended standard prelude
that work on L bits values.
Tests and documention included.
Signed-off-by: Jose E. Marchesi <jemarch@gnu.org>
gcc/algol68/ChangeLog
* ga68.texi (POSIX files): Document SET and CLEAR operators.
* a68.h: Prototypes for a68_bits_set, a68_bits_clear,
a68_lower_set3 and a68_lower_clear3.
* a68-low-bits.cc (a68_bits_set): New function.
(a68_bits_clear): Likewise.
* a68-low-prelude.cc (a68_lower_set3): Likewise.
(a68_lower_clear3): Likewise.
* a68-parser-prelude.cc (gnu_prelude): Declare operators SET and
CLEAR and their priorities.
gcc/testsuite/ChangeLog
* algol68/execute/bits-clear-1.a68: New test.
* algol68/execute/bits-set-1.a68: Likewise.
Keith Packard [Sat, 31 Jan 2026 14:00:26 +0000 (07:00 -0700)]
[PATCH] picolibc: Use %:find-file for both test and access to picolibc.ld
If the gcc driver and linker don't agree on what the search path for
linker scripts is, then the driver may discover a file that
the linker won't end up using. This results in linking failures
when applications don't specific an explicit linker script.
Fix this by duplicating the call to %:find-file for both
test and in the parameter passed to the linker.
gcc/
* config/picolibc-spec.h (LIBC_LINK_SPEC): Use find-file for test
and access to picolibc.ld.
- When called to fold away a reference, it considers the use to not be
an lvalue and so 'maybe_constant_value' folds all the way through the
nested INDIRECT_REF to a prvalue. Fixed by folding the op0 of the
INDIRECT_REF rather than the ref itself and avoiding a double
cp_fold_non_odr_use_1.
- When used to fold away the initializing expression for an INIT_EXPR,
it doesn't mark any new TARGET_EXPRs as eliding. Fixed by reapplying
'set_target_expr_eliding' for the initializer of an INIT_EXPR if it
got modified during ff_only_non_odr walk.
PR c++/123557
PR c++/123738
gcc/cp/ChangeLog:
* cp-gimplify.cc (cp_fold_maybe_rvalue): Call
cp_fold_non_odr_use_1 before recursing cp_fold.
(cp_fold): Pass op0 to cp_fold_non_odr_use_1 when folding a
reference. Reapply set_target_expr_eliding on the initializing
expression of an INIT_EXPR.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-ice22.C: New test.
* g++.dg/cpp2a/constexpr-ref2.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
The first testcase comes directly from
https://eel.is/c++draft/meta.reflection#names-1.8.2
and shows that we don't handle for -freflection the function
argument name difference handling isn't performed for local externs,
which doesn't go the duplicate_decls route but directly remembers
the alias.
The following patch handles outlines the DECL_ARGUMENTS handling
from duplicate_decls and uses it in push_local_extern_decl_alias
(with some minor differences and for now not propagating attributes
back for the push_local_extern_decl_alias case unless -freflection).
ALso, I found that the addition of a new alias created completely broken
DECL_ARGUMENTS (copied at most the first PARM_DECL, never more than that).
That is because copy_decl clears DECL_CHAIN, so the loop always stopped
after the first iteration.
2026-01-31 Jakub Jelinek <jakub@redhat.com>
PR c++/123825
* cp-tree.h (merge_decl_arguments): Declare.
* decl.cc (duplicate_decls): Outline DECL_ARGUMENTS handling
into ...
(merge_decl_arguments): ... new function.
* name-lookup.cc (push_local_extern_decl_alias): Call
merge_decl_arguments. Don't copy just the first PARM_DECL when
creating a new alias FUNCTION_DECL.
* g++.dg/reflect/has_identifier3.C: New test.
* g++.dg/reflect/identifier_of3.C: New test.
* g++.dg/cpp26/attr-indeterminate5.C: New test.
The late-combine pass enabled some of the vdup.32 instructions
expected in crypto-vsha1*_u32 tests to use d registers, so accept them
as well.
While at that, drop the excess + after ] in d register matches in
vmov.32 instructions.
for gcc/testsuite/ChangeLog
* gcc.target/arm/crypto-vsha1cq_u32.c: Accept d regs in
vdup.32. Drop extraneous + after ] in vmov.32 pattern.
* gcc.target/arm/crypto-vsha1h_u32.c: Likewise.
* gcc.target/arm/crypto-vsha1mq_u32.c: Likewise.
* gcc.target/arm/crypto-vsha1pq_u32.c: Likewise.
Alexandre Oliva [Sat, 31 Jan 2026 04:52:05 +0000 (01:52 -0300)]
testsuite: arm: add -mcpu=unset before -march
Reset the cpu selection to the default on tests that set -march
explicitly instead of using dg-add-options. The latter would reset
the cpu selection to avoid interference from TOOL_OPTIONS.
Also add +fp to -march in tests that don't override float-abi and fpu,
so that -mfloat-abi=hard -mfpu=auto in TOOL_OPTIONS won't cause a
failure.
Since the addition of DCE after complex lowering, reassoc1 has no
longer been impeded by COMPLEX_EXPRs, so it changes (a - (b + c)),
where (b + c) is the imaginary part of an intermediate complex value,
to ((a - b) - c), and this prevents the vectorizer from recognizing
the expected COMPLEX_ADD_ROT270 pattern in fms_elemconjsnd.
Stop expecting that pattern to be found on that test.
David Malcolm [Sat, 31 Jan 2026 04:27:40 +0000 (23:27 -0500)]
analyzer: fix ICE on rethrow without throw [PR123880]
gcc/analyzer/ChangeLog:
PR analyzer/123880
* engine.cc (throw_custom_edge::update_model): Gracefully handle
not knowing the current exception in a rethrow.
(exploded_node::on_throw): Likewise.
gcc/testsuite/ChangeLog:
PR analyzer/123880
* g++.dg/analyzer/exception-rethrow-3.C: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Jason Merrill [Wed, 28 Jan 2026 06:17:13 +0000 (14:17 +0800)]
c++: defer DECL_ONE_ONLY vs consteval-only [PR122785]
The failure in the given PR occurs because when setting up an
imported vague-linkage variable, we currently call 'maybe_commonize_var'
which for -freflection checks 'consteval_only_p'. Unfortunately this
latter function needs to call 'complete_type_p' which can perform
recursive loading of the (possibly yet-to-be-streamed) class type,
breaking modules assumptions.
If we just remove the consteval_only_p early exit from maybe_commonize_var,
we end up crashing at EOF while trying to mangle its comdat group, so we
need to undo maybe_commonize_var along with setting DECL_EXTERN.
Pietro Monteiro [Sat, 31 Jan 2026 01:22:49 +0000 (20:22 -0500)]
libitm: testsuite: don't include libstdc++ paths in test names [PR69018]
Libitm C++ tests pass -B/full/path/to/build/libstc++/src/.libs on the
options argument to dg-runtest and the libstdc++ include paths as
the default-extra-options. This causes 2 problems:
1) If a test uses `dg-options' then the libstdc++ include paths are
not passed to the compiler.
2) The `-B/full/path/to/build/libstc++/src/.libs' gets added to the
test name. This makes comparing build done in different directories
harder because the hardcoded full path.
Stop passing options and default-extra-options to dg-runtest and move
dealing with the path-releated flags to libitm_target_compile in
libitm.exp, where they are added to additional_flags.
Also change the FSF address to the website in the license text.
libitm/ChangeLog:
PR libitm/69018
* testsuite/lib/libitm.exp (libitm_target_compile): Add
lang_include_flags and `-B${blddir}/${lang_library_paths}' to
additional_flags.
* testsuite/libitm.c++/c++.exp: Set lang_library_paths and lang_include_flags.
Signed-off-by: Pietro Monteiro <pietro@sociotechnical.xyz>
Jerry DeLisle [Fri, 30 Jan 2026 21:25:23 +0000 (13:25 -0800)]
Fortran: Fix PR123868
When copying derived types with allocatable array components where the
array element type also has allocatable components, the condition at
line 11071 was incorrectly triggering a call to gfc_duplicate_allocatable.
However, for allocatable arrays with nested allocatables (where
cmp_has_alloc_comps && c->as is true), the add_when_allocated code
already includes a gfc_duplicate_allocatable call (generated by the
recursive structure_alloc_comps call at lines 10290-10293).
This caused the outer array to be allocated twice: first by the explicit
gfc_duplicate_allocatable call at line 11099, and then again by the
gfc_duplicate_allocatable embedded in add_when_allocated. The first
allocation was leaked when the second allocation overwrote the data
pointer.
PR121628 added "add_when_allocated != NULL_TREE ||" to the condition,
which was redundant for scalars (already handled by !c->as) and wrong
for arrays (caused double allocation). Simply removing this clause
restores the correct pre-PR121628 behavior.
PR fortran/123868
gcc/fortran/ChangeLog:
* trans-array.cc (structure_alloc_comps): For COPY_ALLOC_COMP,
remove the add_when_allocated != NULL_TREE clause that PR121628
added. This clause was redundant for scalars and caused double
allocation for arrays with nested allocatable components.
gcc/testsuite/ChangeLog:
* gfortran.dg/array_memcpy_2.f90: Update expected memcpy count
from 4 to 3, as the double allocation bug is now fixed.
* gfortran.dg/pr123868.f90: New test.
Signed-off-by: Christopher Albert <albert@alumni.tugraz.at>
Patrick Palka [Fri, 30 Jan 2026 20:25:43 +0000 (15:25 -0500)]
c++: non-empty constexpr constructor bodies in C++11 [PR123845]
This patch makes us support C++14 non-empty constexpr constructor bodies
in C++11, as an extension. This will make it trivial to safely fix the
C++11 library regression PR114865 that requires us to do
__builtin_clear_padding after initializing _M_i in std::atomic's
single-parameter constructor, and that's not really possible with the
C++11 constexpr restrictions.
Since we lower member initializers to constructor body statements
internally, and so constructor bodies are already effectively non-empty
internally even in C++11, supporting non-empty bodies in user code is
mostly a matter of relaxing the parse-time error.
But constexpr-ex3.C revealed that by accepting the non-empty body of A's
constructor, build_data_member_initialization goes on to mistake the
'i = _i' assignment as a member initializer, and we incorrectly accept
the constructor in C++11 mode (even though omitting mem-inits is only
valid since C++20). Turns out this is caused by that function
recognizing MODIFY_EXPR only in C++11 mode, logic that was last changed
by r5-5013 (presumably to limit impact of the patch at the time) but I
reckon could just be removed outright. This should be safe because the
result of build_data_member_initialization is only used by
cx_check_missing_mem_inits for validation; evaluation is in terms of
the entire lowered constructor body.
PR c++/123845
PR libstdc++/114865
gcc/cp/ChangeLog:
* constexpr.cc (build_data_member_initialization): Remove
C++11-specific recognition of MODIFY_EXPR.
(check_constexpr_ctor_body): Relax error diagnostic to a
pedwarn and don't clear DECL_DECLARED_CONSTEXPR_P upon
error. Return true if complaining.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-ex3.C: Adjust C++11 non-empty
constexpr constructor dg-error to a dg-warning. Expect
a follow-up missing member initializer diagnostic in C++11 mode.
* g++.dg/cpp2a/constexpr-try1.C: Expect a follow-up
compound-statement in constexpr function diagnostic in C++11
mode.
* g++.dg/cpp2a/constexpr-try2.C: Likewise. Adjust C++11
non-empty constexpr constructor dg-error to a dg-warning.
* g++.dg/cpp2a/constexpr-try3.C: Adjust C++11 non-empty
constexpr constructor dg-error to a dg-warning.
* g++.dg/cpp0x/constexpr-ctor23.C: New test.
The following properly checks expr_no_side_effects_p on two patterns
that turns a conditionally evaluated operand into unconditonal.
PR middle-end/123887
* match.pd ((zero_one ==/!= 0) ? .. z <op> y .. -> zero_one * z ..):
Check evaluating z unconditionally has no side-effects, like
trapping.
Richard Biener [Fri, 30 Jan 2026 13:55:58 +0000 (14:55 +0100)]
debug/123886 - remove GTY((skip)) from external_die_map entry
The following avoids GCing IDENTIFIER_POINTERs referenced from
external_die_map after we clear ggc_protect_identifiers. I never
expected those to be GCed.
Patrick Palka [Fri, 30 Jan 2026 18:16:20 +0000 (13:16 -0500)]
libstdc++/regex: add [[gnu::always_inline]] to _Executor::_M_node
The compiler understandably doesn't know that _M_node only ever has a
single call site, _M_dfs, (and is not directly called from other library
headers or user code) and so decides not to inline it. So use the
always_inline attribute to force the inlining. This seems sufficient to
make all _M_dfs subroutines get inlined away, and speeds up the executor
by 30% on some microbenchmarks.
Gary Dismukes [Fri, 30 Jan 2026 16:55:16 +0000 (17:55 +0100)]
Ada: Fix regression in visibility for nested use_type_clauses
An earlier fix for wrong handling of visibility when a use_type_clause
with "all" occurs within a nested scope when there's a use_type_clause
in an enclosing scope without "all" was incorrect and led to primitives
being visible in a later nested scope that has a use_type_clause with
"all" for the same type. We now properly restore Current_Use_Clause
to refer to the outer use_type_clause when ending the scope of nested
use_type_clauses.
gcc/ada/
* sem_ch8.adb (End_Use_Type): Remove test of Prev_Use_Clause as
as a condition for resetting In_Use and Current_Use_Clause, and
change setting of that flag and field based on Prev_Use_Clause
rather than setting them to Empty. Revise preceding comment.
Patrick Palka [Fri, 30 Jan 2026 17:29:17 +0000 (12:29 -0500)]
libstdc++/regex: Defer _M_current restoration to backtracking nodes [PR86164]
The incrementing of the current input string position (_M_current) is
done by _M_handle_match, which also makes sure to restore it afterwards,
via a restore_current frame. But restoring _M_current is naturally only
necessary when backtracking is involved, not after every single match.
So this patch moves the responsibility of saving/restoring _M_current
from _M_handle_match to the branching nodes _M_handle_alternative and
_M_handle_repeat. This is done by storing _M_current within the
fallback_next, fallback_rep_once_more and posix_alternative frames.
In turn we can get rid of the now unused restore_current frame kind.
This reduces the maximum size of the _M_frames stack by 15% for
regex_match(string(200000, 'a'), "(a|b|c)*")
PR libstdc++/86164
libstdc++-v3/ChangeLog:
* include/bits/regex_executor.tcc (__detail::_ExecutorFrameOpcode):
Remove _S_fopcode_restore_current.
(__detail::_Executor::_M_handle_repeat): Pass _M_current when
pushing a fallback_next or fallback_rep_once_more frame.
(__detail::_Executor::_M_handle_match): Don't push a
restore_current frame.
(__detail::_Executor::_M_handle_backref): Likewise and simplify
accordingly.
(__detail::_Executor::_M_handle_alternative): Pass _M_current when
pushing a fallback_next or posix_alternative frame.
(__detail::_Executor::_M_dfs) <case _S_fopcode_fallback_next>:
Restore _M_current.
<case _S_fopcode_fallback_rep_once_more>: Likewise.
<case _S_fopcode_posix_alternative>: Likewise.
<case _S_fopcode_restore_current>: Remove.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Patrick Palka [Fri, 30 Jan 2026 17:23:40 +0000 (12:23 -0500)]
libstdc++/regex: Make DFS executor non-recursive [PR86164]
This patch replaces the recursive implementation of the DFS executor
with an iterative one using an explicit heap-based stack. System
stack usage of the executor is now constant with respect to input size
rather than linear, avoding stack overflow errors when processing
long inputs.
PR libstdc++/86164
libstdc++-v3/ChangeLog:
* include/bits/regex.h (__detail::_Executor): Use inline
namespace _V2.
* include/bits/regex_executor.h (__detail::_ExecutorFrame):
Declare.
(__detail::_Executor): Use inline namespace _V2.
(__detail::_Executor::_M_node): Declare.
(__detail::_Executor::_M_frames): New data member.
* include/bits/regex_executor.tcc (__detail::_ExecutorFrameOpcode):
New.
(__detail::_ExecutorFrameBase): New.
(__detail::_ExecutorFrame): New.
(__detail::_Executor): Use inline namespace _V2.
(__detail::_Executor::_M_rep_once_more): Replace recursive
_M_dfs calls with an _S_opcode_next frame push, and any work
after such calls with an appropriate frame push.
(__detail::_M_handle_repeat): Likewise.
(__detail::_M_handle_subexpr_begin): Likewise.
(__detail::_M_handle_subexpr_end): Likewise.
(__detail::_M_handle_line_begin_assertion): Likewise.
(__detail::_M_handle_line_end_assertion): Likewise.
(__detail::_M_handle_word_boundary): Likewise.
(__detail::_M_handle_subexpr_lookahead): Likewise.
(__detail::_M_handle_match): Likewise.
(__detail::_M_handle_backref): Likewise.
(__detail::_M_handle_accept): Likewise.
(__detail::_M_handle_alternative): Likewise.
(__detail::_M_node): Factored out from _M_dfs.
(__detail::_M_dfs): Push an initial frame to _M_frames that
visits the starting node and pass this stack each subroutine.
Pop the latest _ExecutorFrame from _M_frames and handle
appropriately according to its _ExecutorFrameOpcode. Loop until
_M_frames is empty.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Marek Polacek [Wed, 28 Jan 2026 22:05:46 +0000 (17:05 -0500)]
c++/reflection: check TYPE_BEING_DEFINED in define_aggregate
As discussed in
<https://gcc.gnu.org/pipermail/gcc-patches/2026-January/705756.html>,
we should check TYPE_BEING_DEFINED along with COMPLETE_TYPE_P in
eval_define_aggregate. It seems that with this check added, we don't
need this code anymore:
if (c == type)
{
auto_diagnostic_group d;
error_at (loc, "%<define_aggregate%> evaluated from "
"%<consteval%> block enclosed by %qT being "
"defined", type);
//...
}
so I'm removing that in this patch.
gcc/cp/ChangeLog:
* reflect.cc (eval_define_aggregate): Also give an error when
TYPE_BEING_DEFINED is true for the first argument. Remove code
that did the same.
Marek Polacek [Wed, 28 Jan 2026 21:33:34 +0000 (16:33 -0500)]
c++/reflection: tweak eval_can_substitute
As discussed in
<https://gcc.gnu.org/pipermail/gcc-patches/2026-January/705756.html>,
we should check for undeduced_auto_decl after performing
resolve_nondeduced_context_or_error. Also add a test to exercise
the new check.
gcc/cp/ChangeLog:
* reflect.cc (eval_can_substitute): Check undeduced_auto_decl after
resolve_nondeduced_context_or_error.
gcc/testsuite/ChangeLog:
* g++.dg/reflect/substitute3.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com> Reviewed-by: Jakub Jelinek <jakub@redhat.com>
Eric Botcazou [Fri, 30 Jan 2026 10:58:58 +0000 (11:58 +0100)]
Ada: Fix spurious visibility error from limited_with clause in hierarchy
The problem is that the compiler installs the limited view of a package that
is already installed by the virtue of being an ancestor of the main unit.
gcc/ada/
PR ada/123867
* sem_ch10.adb (Analyze_Compilation_Unit): Output info message
when -gnatdi is specified.
(Install_Parents): Likewise. Set the Is_Visible_Lib_Unit flag
on the unit.
(Install_Private_With_Clauses): Do not output info message here.
(Remove_Parents): Output info message when -gnatdi is specified
and clear the Is_Visible_Lib_Unit flag on the unit.
gcc/testsuite/
* gnat.dg/specs/limited_with3.ads: New test.
* gnat.dg/specs/limited_with3-child.ads: New helper.
* gnat.dg/specs/limited_with3-child-grandchild.ads: Likewise.
* gnat.dg/specs/limited_with3-child-grandchild-grandgrandchild.ads:
Likewise.
The following fixes a link failure due to missing skeleton
ancestors.
PR debug/110885
* dwarf2out.cc (generate_skeleton_bottom_up): Generate the
skeleton ancestor tree when moving a new child to the parent
even for template instantiations.
Jakub Jelinek [Fri, 30 Jan 2026 10:43:49 +0000 (11:43 +0100)]
libatomic: Don't install libatomic_asneeded.{so,a} if corresponding libatomic.{so,a} wasn't installed
Filip complained on IRC that libatomic_asneeded.a is installed as
stale symlink in --disable-static build.
The following patch makes sure to install the libatomic_asneeded.{so,a}
script and/or symlink only if the corresponding libatomic.{so,a} has been
installed.
2026-01-30 Jakub Jelinek <jakub@redhat.com>
* Makefile.am (all-local, install-asneeded): Only create
libatomic_asneeded.so script if libatomic.so exist, only
create libatomic_asneeded.a symlink if libatomic.a exist.
* Makefile.in: Regenerate.
Jakub Jelinek [Fri, 30 Jan 2026 10:42:41 +0000 (11:42 +0100)]
match.pd: Fix up __imag__ .MUL_OVERFLOW simplification [PR123864]
The integer_minus_onep case is really meant for multiplication by
-1, not by (unsigned char)0xff or (unsigned short)0xffff or 0xffffffffU etc.
We've already tested that the first operand is signed (otherwise the
earlier case is used) and also that int_fits_type_p (@1, TREE_TYPE (@0)),
but if @0 is signed and @1 is unsigned all ones with smaller precision
than that, it fits into @0's type, integer_minus_onep will be true
and it still should be handled through the ranges, not as @0 == min.
2026-01-30 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/123864
* match.pd (__builtin_mul_overflow_p (x, cst, (stype) 0) ->
x > stype_max / cst || x < stype_min / cst): Only check
integer_minus_onep for signed types.
* gcc.c-torture/execute/pr123864.c: New test.
* gcc.dg/torture/pr123864.c: New test.
Jakub Jelinek [Fri, 30 Jan 2026 10:40:17 +0000 (11:40 +0100)]
fold-const: Fix implicit cast to nullptr_t typedef [PR123790]
The following testcase is incorrectly rejected, because since r15-6744
it adds build_nop to preserve the exact typedef type and
cxx_eval_constant_expression can't fold NOP_EXPR from integer_zerop of one
NULLPTR_TYPE to another NULLPTR_TYPE, while cxx_eval_constant_expression
relies on fold to do such folding.
I see 3 options to fix that, one is deal with this in the r15-6744 spot
and special case NULLPTR_TYPE there and build_zero_cst instead of build_nop
(with similar condition like in the patch below), another possibility is
special case this in cxx_eval_constant_expression, and
another one (done in this patch) is to handle this in fold-const.cc -
fold_convert_loc and also in fold_convert_const.
2026-01-30 Jakub Jelinek <jakub@redhat.com>
PR c++/123790
* fold-const.cc (fold_convert_const): Handle conversion of
integer_zerop to NULLPTR_TYPE.
(fold_convert_loc): Likewise.
Jørgen Kvalsvik [Wed, 28 Jan 2026 19:33:21 +0000 (20:33 +0100)]
Permit const counters in flush_on_edges [PR123855]
Relax the (accidental) requirement and permit that function-local
counters don't have SSA names. We really only look up the def
statement to check if it is a phi node, in which case we need to
resolve the counter from there. This obviously doesn't apply when it
is a constant.
PR gcov-profile/123855
gcc/ChangeLog:
* path-coverage.cc (flush_on_edges): Only look up SSA name def
stmt when counter is non-const.
Jørgen Kvalsvik [Mon, 3 Nov 2025 23:05:04 +0000 (00:05 +0100)]
gcov-dump: Print PATHS tag
Print the record associated with the PATHS tag. While it just prints
the number of prime paths for the function, this is more useful than
the UNKNOWN it would otherwise print.
Jørgen Kvalsvik [Mon, 3 Nov 2025 22:48:25 +0000 (23:48 +0100)]
gcc: -f*-coverage implies -ftest-coverage
The --coverage flag is a useful alias for -fprofile-arcs
-ftest-coverage where the latter makes gcc output the .gcno file.
While it makes sense to use -fprofile-arcs without a .gcno file (pgo,
maybe more), it never really makes sense to request -fpath-coverage or
-fcondition-coverage without also wanting the .gcno to interpret the
results.
gcc/ChangeLog:
* common.opt: ftest-coverage enabled by fpath-coverage or
fcondition-coverage
That patch adds discriminators to edge->goto_locus which will map to
the right source location, but breaks the equality comparison used in
the hash set.
Jakub Jelinek [Fri, 30 Jan 2026 09:56:10 +0000 (10:56 +0100)]
libcpp: Fix up comment handling in -fdirectives-only preprocessing [PR123273]
Back in 2020 Nathan rewrote the -E -fdirectives-only preprocessing.
In PR103130 a year and half later I've fixed the handling of comments
so that /* \*/ is considered as full comment even when * is escaped,
to match the normal preprocessing.
The following testcases shows further bugs in the comment handling.
One is that /* *\/ should not be considered as full comment (i.e.
when the / after * is escaped). And another one is that the code
was treating any number of backslashes as escape, which is wrong,
only a single backslash is an escape, two backslashes preprocess as
one backslash, three as one backslash and one escape, etc.
So, while /* *\
/ is a full comment, /* *\\
/ or /* *\\\\\\\\\\\\\
/ is not.
2026-01-30 Jakub Jelinek <jakub@redhat.com>
PR preprocessor/123273
* lex.cc (cpp_directive_only_process): Only go to done_comment
for '/' if star is true and esc is false. When seeing '\\' with
esc set to true, clear esc as well as star instead of keeping esc
set.
* c-c++-common/cpp/dir-only-10.c: New test.
* c-c++-common/cpp/dir-only-11.c: New test.
the problem being that nonstreaming_only expects an instance of
aarch64_feature_flags which (statically) describes the required
extensions for the intrinsics. Instead, we were passing TARGET_SIMD,
which computes a boolean telling us dynamically whether the simd feature
is currently available.
This patch fixes the issue by simply doing
s/TARGET_SIMD/AARCH64_FL_SIMD/ in that file. We also add a simple test
which checks that we now diagnose the missing extension instead of
ICEing when compiling with +nosimd.
As an additional conservative hardening step (to prevent a similar issue
from re-occurring), this patch adjusts the aarch64_pragma_builtins table
to make it constexpr. This makes the bug a compile-time error.
The next patch in the series adjusts the ctor of bbitmap to make it
explicit (and deals with the fallout), this patch however is
deliberately a minimal fix which is suitable for backporting.
gcc/ChangeLog:
PR target/123206
* config/aarch64/aarch64-builtins.cc (struct aarch64_pragma_builtins_data):
Declare array as CONSTEXPR.
* config/aarch64/aarch64-simd-pragma-builtins.def: Update
incorrect uses of TARGET_SIMD to use AARCH64_FL_SIMD instead.
gcc/testsuite/ChangeLog:
PR target/123206
* gcc.target/aarch64/pr123206.c: New test.
Iain Buclaw [Fri, 30 Jan 2026 08:06:39 +0000 (09:06 +0100)]
d: Refactor for changes to dmd front-end inteface
There are a number of interface changes being made to the dmd front-end
interface. This makes any necessary refactorings ahead of the merge to
reduce the size of the diff.
gcc/d/ChangeLog:
* decl.cc (DeclVisitor::visit (EnumDeclaration *)): Treat sinit member
field as a generic pointer.
(enum_initializer_decl): Likewise.
* expr.cc (ExprVisitor::visit (ArrayLiteralExp *)): Compute static
array length separately from creating type.
* modules.cc (struct module_info): Add ctor_decl, dtor_decl,
sharedctor_decl, shareddtor_decl, standalonector_decl, and
unittest_decl.
(layout_moduleinfo_fields): Add mi argument. Use it to check whether
module helpers have been generated.
(layout_moduleinfo): Likewise.
(build_module_tree): Cache generated module helpers in module_info.
* typeinfo.cc (cpp_type_info_ptrs): New variable.
(get_cpp_typeinfo_decl): Cache generated C++ type_info references in
cpp_type_info_ptrs.
* types.cc (TypeVisitor::visit (TypeEnum *)): Separate getting
front-end member value from building its CST tree.
Iain Buclaw [Fri, 30 Jan 2026 07:14:34 +0000 (08:14 +0100)]
d: Fix ICE in dwarf2out_abstract_function, at dwarf2out.cc:23771 [PR123263]
Emit artificial functions as being part of the module context, so that
they are unaffected by dwarf early_finish pass removing the parent type
that they were generated for.
PR d/123263
gcc/d/ChangeLog:
* d-codegen.cc (d_decl_context): Set DECL_CONTEXT of compiler
generated functions to that of parent module.
Richard Biener [Thu, 29 Jan 2026 14:43:01 +0000 (15:43 +0100)]
tree-optimization/109410 - ICE with noreturn and -g
This fixes the -g variant of the original testcase.
PR tree-optimization/109410
* tree-ssa-reassoc.cc (build_and_add_sum): Use
gsi_start_nondebug_after_labels_bb to look for a possible
returns-twice call.
Andrew Pinski [Wed, 28 Jan 2026 20:32:12 +0000 (12:32 -0800)]
ifcvt: Improve noce_can_force_operand in ifcvt [PR122170]
Currently if the rtl is either an arithmetic or an unary
rtl, noce_can_force_operand checks to see if there is an
optab for that rtl code. This works for more things except
on some targets they have a ss_minus instruction but don't
implement the optab for it. In the case of arm you can
generate a ss_minus with a builtin and then when it comes
to trying to do ifcvt, force_operand fails over.
In this case the optab, sssub was only supported for
fixed-point modes before and it was working as code_to_optab
would return there was not optabs. But after r15-1030-gabe6d39365476e,
the optab will be return. What the backend is doing is correct and will
most likely happen with other rtl codes/optabs later on.
To fix this instead of just returning true if the optab exists, we need
to check if the optab entry for the mode exists.
PR rtl-optimization/122170
gcc/ChangeLog:
* ifcvt.cc (noce_can_force_operand): Don't only check if
there is an optab for the code check the entry for the
mode is non-null. Handle non integral div by checking
optab like force_operand does.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Lulu Cheng [Tue, 27 Jan 2026 02:31:36 +0000 (10:31 +0800)]
LoongArch: Fix bug123766.
The pointer parameter type for the original store class builtin
functions is CVPOINTER (const volatile void *).
Taking the following test as an example:
```
v4i64 v = {0, 0, 0, 0};
void try_store() {
long r[4];
__lasx_xvst(v, r, 0);
}
```
At this point, the type of r is CVPOINTER, which means data in memory
can only be read through r. Therefore, if the array r is not
initialized, an uninitialized warning will be issued.
This patch changes the pointer type of store-class builtin functions
from CVPOINTER to VPOINTER (volatile void *).
PR target/123766
gcc/ChangeLog:
* config/loongarch/loongarch-builtins.cc
(loongarch_build_vpointer_type): New function. Return a type
for 'volatile void *'.
(LARCH_ATYPE_VPOINTER): New macro.
* config/loongarch/loongarch-ftypes.def: Change the pointer
type of the store class function from CVPOINTER to VPOINTER.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/vector/lasx/pr123766.c: New test.
* gcc.target/loongarch/vector/lsx/pr123766.c: New test.
Lulu Cheng [Mon, 26 Jan 2026 03:38:59 +0000 (11:38 +0800)]
LoongArch: Fix bug123807.
In the function loongarch_expand_vector_init_same, if same is MEM and
the mode of same does not match imode, it will cause an ICE
in force_reg (imode, same).
PR target/123807
gcc/ChangeLog:
* config/loongarch/loongarch.cc
(loongarch_expand_vector_init_same): When same is MEM and
GET_MODE(same) != imode, first load the data from memory
and then process it further.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/vector/lsx/pr123807.c: New test.
mengqinggang [Fri, 23 Jan 2026 07:00:58 +0000 (15:00 +0800)]
LoongArch: Fix movsf in lp64s abi
When adding LoongArch32 ilp32s abi support, add TARGET_HARD_FLOAT condition for
movsf to prevent matching in target without FPU.
But movsf also needs to be used in lp64s abi, it can expand to some
non float instructions.
Delete TARGET_HARD_FLOAT condition.
Andrew Pinski [Thu, 29 Jan 2026 00:50:52 +0000 (16:50 -0800)]
optabs: Fix expansion of abs and neg for Float16 [PR123869]
The problem here is we try to use the widening type before
doing the bitwise expansion of neg/and for floating point types.
This moves the code around to try the bitwise expansion first.
Note this mostly matters for NaNs where you widening (promotion)
would cause a NaN to be slightly different when doing the rounding
back.
Bootstrapped and tested on x86_64-linux-gnu.
PR middle-end/123869
gcc/ChangeLog:
* optabs.cc (expand_unop): Move the NEG optab
handling before the widening code.
Move the ABS bitwise expansion from expand_abs_nojump
to before the widening code.
(expand_abs_nojump): Remove the bitwise expansion trial
since expand_unop is called right above.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
projects / thirdparty / gcc.git / log
