- Import dmd v2.112.0.
- Bitfields feature is now enabled by default.
- The compiler now accepts `-std=d2024' and `-std=d202y'.
- An error is now issued for dangling `else' statements.
- `finally' statements are no longer rewritten to a sequence if
no `Exception' was thrown.
- Some forms of `printf' calls are now treated as `@safe'.
- Implicit integer conversions in `int op= float` assignments
has been deprecated.
D runtime changes:
- Import druntime v2.112.0.
- Added `filterCaughtThrowable' in `core.thread.ThreadBase'.
Phobos changes:
- Import phobos v2.112.0.
gcc/d/ChangeLog:
* dmd/VERSION: Bump version to v2.112.0.
* dmd/MERGE: Merge upstream dmd 24a41073c2.
* d-attribs.cc (build_attributes): Update for new front-end interface.
* d-builtins.cc (build_frontend_type): Likewise.
(matches_builtin_type): Likewise.
(d_init_versions): Predefine D_Profile when compiling with profile
enabled.
* d-codegen.cc (get_array_length): Update for new front-end interface.
(lower_struct_comparison): Likewise.
(build_array_from_val): Likewise.
(get_function_type): Likewise.
(get_frameinfo): Likewise.
* d-compiler.cc (Compiler::paintAsType): Likewise.
* d-convert.cc (convert_expr): Likewise.
(convert_for_rvalue): Likewise.
(convert_for_assignment): Likewise.
(d_array_convert): Likewise.
* d-diagnostic.cc (verrorReport): Rename to ...
(vreportDiagnostic): ... this.
(verrorReportSupplemental): Rename to ...
(vsupplementalDiagnostic): ... this.
* d-lang.cc (d_handle_option): Handle -std=d2024 and -std=d202y.
(d_parse_file): Update for new front-end interface.
* d-target.cc (Target::fieldalign): Likewise.
(Target::isVectorTypeSupported): Likewise.
(Target::isVectorOpSupported): Likewise.
* decl.cc (get_symbol_decl): Likewise.
(DeclVisitor::visit): Likewise.
(DeclVisitor::visit (FuncDeclaration *)): Do NRVO on `__result' decl.
* expr.cc (needs_postblit): Remove.
(needs_dtor): Remove.
(lvalue_p): Remove.
(ExprVisitor::visit): Update for new front-end interface.
(ExprVisitor::visit (AssignExp *)): Update for front-end lowering
expression using templates.
* imports.cc (ImportVisitor::visit): Update for new front-end
interface.
* intrinsics.def (INTRINSIC_VA_ARG): Update signature.
(INTRINSIC_C_VA_ARG): Update signature.
(INTRINSIC_VASTART): Update signature.
* lang.opt: Add -std=d2024 and -std=d202y.
* toir.cc (IRVisitor::visit): Update for new front-end interface.
* typeinfo.cc (TypeInfoVisitor::visit): Likewise.
(TypeInfoVisitor::visit (TypeInfoStructDeclaration *)): Ensure
semantic is ran on all TypeInfo members.
(base_vtable_offset): Update for new front-end interface.
* types.cc (TypeVisitor::visit): Likewise.
Marek Polacek [Mon, 2 Feb 2026 16:05:16 +0000 (11:05 -0500)]
libstdc++, c++/reflection: mark {,de}allocate constexpr
[allocator.members] says that allocator::{,de}allocate should be
constexpr but currently we don't mark them as such. I had to
work around that in the Reflection code, but it would be better to
clean this up. (I see no allocation_result so I'm not changing that.)
Kirill Chilikin [Sun, 25 Jan 2026 07:43:08 +0000 (14:43 +0700)]
fortran: Fix creation of reference to C_FUNLOC argument [PR117303]
The reference returned by C_FUNLOC is assigned to a variable. Without that,
no reference from the calling subprogram to the argument of C_FUNLOC
was created in the call graph, resulting in an undefined-reference error
with link-time optimization. Please see PR 117303 for more details.
PR fortran/117303
gcc/fortran/ChangeLog:
* trans-intrinsic.cc (conv_isocbinding_function):
Assign the reference returned by C_FUNLOC to a variable.
gcc/testsuite/ChangeLog:
* gfortran.dg/c_funloc_tests_7.f90:
Updated test due to changed code generation.
* gfortran.dg/c_funloc_tests_9.f90: New test.
Rainer Orth [Tue, 3 Feb 2026 19:41:40 +0000 (20:41 +0100)]
build: Only use gas_flag/gnu_ld_flag internally [PR123841]
gcc/acinclude.m4, gcc/config.gcc, and gcc/configure.ac have two
different variables that are checked to determine if GNU as and/or GNU
ld are used. config.gcc describes them like this:
gas_flag Either yes or no depending on whether GNU as was
requested.
gnu_ld_flag Either yes or no depending on whether GNU ld was
requested.
gas Set to yes or no depending on whether the target
system normally uses GNU as.
gnu_ld Set to yes or no depending on whether the target
system normally uses GNU ld.
I find this duplication highly confusing: what's the point of what a
target normally uses when it can just be determined at configure time if
the assembler/linker used is gas/gnu_ld?
There are two uses for those variables:
* gas/gnu_ld determine the setting of HAVE_GNU_AS/HAVE_GNU_LD. In this
case only, the normally part may be good enough, so this patch doesn't
touch it.
* However, there are several other places where this isn't good enough:
when the assembler/linker is invoked at configure time, it's crucial
that the right options and input syntax are use for the tool in
question.
Therefore this patch determines gas_flag/gnu_ld_flag at configure time
if they are not yet set otherwise. All tests that need to know which
tool is used now check gas_flag/gnu_ld_flag only.
Tested on {i386,amd64}-pc-solaris2.11, {i686,x86_64}-pc-linux-gnu,
{i386,x86_64}-apple-darwin, and sparc64-unknown-linux-gnu.
Paul Thomas [Tue, 3 Feb 2026 18:00:54 +0000 (18:00 +0000)]
Fortran: Fix module proc with array valued dummy procedure [PR123952]
2026-01-14 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/123952
* symbol.cc (gfc_copy_dummy_sym): Ensure that external, array
valued destination symbols have the correct interface so that
conflicts do not arise when adding attributes.
gcc/testsuite
PR fortran/123952
* gfortran.dg/pr123952.f90: New test.
Roger Sayle [Tue, 3 Feb 2026 17:43:59 +0000 (17:43 +0000)]
PR middle-end/118608: Fix lack of sign extension on MIPS64 with -Os
Here is a refreshed version of my patch from February 2025, for resolving
PR middle-end/118608, a wrong code on valid regression where the middle-end
is failing to keep values suitably sign-extended (MIPS64 is a rare
targetm.mode_rep_extended target, as well as being BYTES_BIG_ENDIAN).
This fix requires three independent tweaks, one in each source file.
The first tweak is that the logic in my triggering patch for determining
whether store_field updates the most significant bit needs to be updated
to handle BYTES_BIG_ENDIAN. Of the two insertions in the bugzilla test
case, we were generating the sign extension after the wrong one.
The second tweak was that this explicit sign-extension was then being
eliminated during combine by simplify-rtx that believed the explicit
TRUNCATE wasn't required. This patch updates truncated_to_mode to
understand that on mode_rep_extended targets, TRUNCATE is used instead
of SUBREG because it isn't a no-op. Finally, the third tweak is
that the MIPS backend requires a small change to recognize (and split)
*extenddi_truncatesi when TARGET_64BIT and !ISA_HAS_EXTS.
On mips64-elf with -mabi=64 the following are now generated for prepareNeedle:
-O2
sll $5,$5,16
jr $31
or $2,$5,$4
-Os
dsll $5,$5,16
or $2,$4,$5
dsll $2,$2,32
jr $31
dsra $2,$2,32
-O2 -march=octeon2
move $2,$0
ins $2,$5,16,16
jr $31
ins $2,$4,0,16
-Os -march=octeon2
move $2,$0
dins $2,$4,0,16
dins $2,$5,16,16
jr $31
sll $2,$2,0
Many thanks to Mateusz Marciniec and Jeff Law for additional testing.
gcc/ChangeLog
PR middle-end/118608
* expr.cc (store_field_updates_msb_p): New helper function that
now also handles BYTES_BIG_ENDIAN targets.
(expand_assignment): Use the above function when deciding to emit
a required sign/zero extension.
* rtlanal.cc (truncated_to_mode): Call targetm.mode_rep_extended
to check whether an explicit TRUNCATE is required (i.e. performs
an extension) on this target.
* config/mips/mips.md (*extenddi_truncate<mode>): Handle all
SUBDI modes, not just SHORT modes.
gcc/testsuite/ChangeLog
PR middle-end/118608
* gcc.target/mips/pr118608-1.c: New test case.
* gcc.target/mips/pr118608-2.c: Likewise.
* gcc.target/mips/pr118608-3.c: Likewise.
* gcc.target/mips/pr118608-4.c: Likewise.
Roger Sayle [Tue, 3 Feb 2026 17:06:25 +0000 (17:06 +0000)]
PR middle-end/123826: __builtin_pow vs. errno.
This is my proposed solution to PR middle-end/123826. Initially
I thought this would be a "one line change", adding a test for
flag_errno_math to gimple_expand_builtin_pow. Unfortunately
this revealed a second later problem, where pow (with constant
arguments) was still getting evaluated at compile-time, even when
the result is known to overflow.
It's ancient history, but shortly after I added support for pow
as a builtin, I contributed code to evaluate it at compile-time
when the exponent is an integer constant. Since then we now use
MPFR to evaluate libm math functions at compile-time. However
the vestigial call to evaluate pow via real_powi still exists,
and gets invoked after do_mpfr_arg2/mpfr_pow correctly determines
that we shouldn't evaluate pow at compile-time. This patch reorganizes
fold_const_pow paying attention to signaling NaNs (PR 61441)
and flag_errno_math. Most importantly normal cases like pow(2.0,3.0)
and pow(3.0,0.5) still get evaluated at compile-time.
2026-02-03 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR middle-end/123826
* tree-ssa-math-opts.cc (gimple_expand_builtin_pow): Add test
for flag_errno_math.
* fold-const-call.cc (fold_const_pow): Reorganize, eliminating
call to real_powi, and letting do_mpfr_arg2 do all the heavy
lifting.
gcc/testsuite/ChangeLog
PR middle-end/123826
* gcc.dg/errno-2.c: New test case.
* gcc.dg/errno-3.c: Likewise.
Christophe Lyon [Tue, 3 Feb 2026 13:07:10 +0000 (13:07 +0000)]
testsuite: arm: Make arm_neon_ok_nocache consistent with other effective-targets
A recent patch updated arm_neon_ok_nocache with an improved list of
flags to try, but was not consistent with
arm_v8_3a_complex_neon_ok,_nocache arm_v8_2a_fp16_neon_ok_nocache,
arm_v8_3a_fp16_complex_neon_ok_nocache.
This patch inserts "-mcpu=unset -march=armv7-a+simd -mfpu=auto" before
we try to force -mfloat-abi=softfp and -mfloat-abi=hard.
Tested on aarch64-linux-gnu, arm-linux-gnueabihf and several flavors
of arm-none-eabi with non-default configurations.
Jeff Law [Tue, 3 Feb 2026 14:24:53 +0000 (07:24 -0700)]
[RISC-V][PR rtl-optimization/123322] Split general conditional moves into simpler sequences
This has gone round and round a few times... But I think we're finally at a
resolution of the regression. There's more work to do for gcc-17 though.
---
At its core this regression is caused by more accurately costing branches
during if-conversion. The more accurate cost causes the multi-set path during
the first ifcvt pass to (profitably) convert the sequence. However, it would
have been more profitable to have waited for things to be cleaned up and by the
2nd ifcvt pass we'd be able to convert using the condzero path which is *more*
profitable than the multi-set code (which is what happens in gcc-15).
One possible solution would be to disable the multi-set ifcvt code during its
first pass. That was evaluated and ultimately rejected because of clear
undesirable impacts. It may still be a good thing to do, but certainly not at
this stage of gcc-16.
Another path that was considered was recognizing the sign extension in the
if-convertable block and avoiding the multi-set path in that case on the
assumption it'd be cleaned up later and the condzero path would be used. That
felt way too target specific and optimistic about removal of the sign
extension.
Daniel looked at if-converting these cases during phiopt; that generally looks
like a good thing to do, but had notable undesirable fallout on RISC-V and I
was significantly worried it would re-introduce sequences on x86 and aarch64
that we just fixed. ie, solving one regression and creating another. So that
feels like a gcc-17 evaluation.
After much head-banging it occurred to me that we could tackle this in the
target with a tiny bit of help from combine. These conditional ops are 4
instruction sequences. The operation, a pair of czeros and an add/ior to
select between the output of the two czeros. Combine is pretty conservative in
when it chooses to try 4 insn sequences.
So step #1 was to loosen the restrictions on combine a little bit. If it sees
an IF_THEN_ELSE, then it considers that "good" which in turn allows us to try 4
insn combinations a bit more often.
That exposes the potential for 4 insn combinations and since the IOR/XOR case
is a 4->2 sequence fixing those regressions is just a good define_split. In
fact, we can use that splitter for any case where the neutral operand is zero
(IOR, XOR, PLUS, MINUS, etc). We need a second pattern to handle reversed
operands since we're using code iterators and match_dup for the matching
operand rather than something like a matching constraint.
THat still leaves conditional shifts regressing due to the same problem. For
shifts/rotates, the count is in QImode, so we need a different pattern to
handle those cases, but it has the same basic structure and behavior.
AND was *still* regressing though. That would require a 4->3 split which isn't
supported by combine. Given the issues with the other paths attempted, I
ultimately decided on a define_insn_and_split (boo!). This shouldn't be
happening a ton like mvconst_internal, so not great, but workable. This also
required recognizing the pattern and giving it a suitable cost (COSTS_N_INSNS
(3)).
That fixes the regressions. We're still not generating ideal code for rv64
when the operands are 32bit quantities and the architecture provides an
instruction variant that sign extends from 32 to 64 bits (add, subtract, shifts
and rotates). But the code we generate for gcc-16 is better than we were
generating for gcc-15, it's just not optimal. So there's a TODO for gcc-17 as
well.
This was bootstrapped and regression tested on x86, alpha, riscv, armv7, hppa,
maybe others, but those definitely for sure. It was also tested on the various
crosses without regressions. Waiting on pre-commit testing to render a verdict
before going forward.
PR rtl-optimization/123322
gcc/
* combine.cc (try_combine): Consider an IF_THEN_ELSE "good" when
evaluating if 4 insn combinations should be tried.
* config/riscv/iterators.md (zero_is_neutral_op): New iterator.
(zero_is_neutral_op_c): Likewise.
(any_shift_rotate): Likewise.
* config/riscv/riscv.cc (riscv_rtx_costs): Recognize the conditional
AND RTL and cost is appropriately.
* config/riscv/zicond.md: Add patterns to rewrite general conditional
move sequences into simpler forms.
gcc/testsuite
* gcc.target/riscv/pr123322.c: New test.
Marek Polacek [Mon, 2 Feb 2026 23:09:08 +0000 (18:09 -0500)]
c++/reflection: refactor compare_reflections
In <https://gcc.gnu.org/pipermail/gcc-patches/2026-January/705756.html>
Jason suggested using cp_tree_equal for all exprs in compare_reflections.
This patch does so. We just have to handle comparing annotations and
types specially, then we can use cp_tree_equal for the rest. It just
had to be taught not to crash on unequal NAMESPACE_DECLs.
gcc/cp/ChangeLog:
* reflect.cc (compare_reflections): Handle comparing annotations
and types specially, use cp_tree_equal for the rest.
* tree.cc (cp_tree_equal) <case NAMESPACE_DECL>: New.
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.
projects / thirdparty / gcc.git / log
