Jakub Jelinek [Fri, 23 Jan 2026 09:37:46 +0000 (10:37 +0100)]
builtins: Only fold abs/absu if it is sane [PR123703]
To my surprise the C FE marks as builtin even a declaration which has incorrect
return type. Normally gimple_builtin_call_types_compatible_p etc. will
just punt in cases where the return type is wrong, but builtins.cc doesn't
use that. For e.g. the mathfn builtins like sqrt and many others, it will
punt on weird return types, but for fold_builtin_abs it doesn't and happily
tests TYPE_UNSIGNED on it and fold_convert the integral operand to it etc.,
which ICEs if the return type is aggregate.
The following patch fixes it by punting if type is not integral.
2026-01-23 Jakub Jelinek <jakub@redhat.com>
PR middle-end/123703
* builtins.cc (fold_builtin_abs): Return NULL_TREE if type is not
integral.
Jakub Jelinek [Fri, 23 Jan 2026 07:37:36 +0000 (08:37 +0100)]
openmp: Fix up OpenMP loop parsing in templates [PR123597]
The following testcase is miscompiled, because since r14-3490
because in this case the sum variable is moved out of the loop's
body into an outer BIND_EXPR and becomes shared, so from what
has been previously private can result in data races.
In the C++ FE, BIND_EXPRs are mostly created for 2 reasons.
One is when something calls c_build_bind_expr and that function
creates a BIND_EXPR because there are decls to attach to it,
this happens for !processing_template_decl e.g. from do_poplevel
or poplevel (the latter for sk_cleanup which I think don't appear
if processing_template_decl). And the other case are BIND_EXPRs
created by begin_compound_stmt if processing_template_decl, those
don't stand for the need to collect decls inside of it, but to
say the source had {} at this point, take it into account when
instantiating the template.
Now, on the testcase when parsing the body of the inner collapsed
loop we call cp_parser_statement -> cp_parser_compound_statement
-> begin_compound_statement because the body is surrounded by {}s
and that returns a BIND_EXPR with the processing_template_decl
meaning, the source had {} here.
But the r14-3490 code then calls substitute_in_tree in a loop, trying
to replace placeholders it created with the parsed bodies. And while
doing that, considers all BIND_EXPRs with !BIND_EXPR_VARS redundant
and just throws them away.
They are redundant when !processing_template_decl, but when
processing_template_decl they I think always have !BIND_EXPR_VARS,
the vars inside of such bodies aren't pushed into any BIND_EXPR yet,
they just have a DECL_EXPR somewhere, and the pushing of the instantiated
copies of those will be done only during instantiation.
The following patch fixes it by not treating BIND_EXPRs with !BIND_EXPR_VARS
as redundant if processing_template_decl, it is fine to merge two
BIND_EXPRs with nothing in between them.
2026-01-23 Jakub Jelinek <jakub@redhat.com>
PR c++/123597
* parser.cc (substitute_in_tree_walker, substitute_in_tree): Don't
consider BIND_EXPRs with !BIND_EXPR_VARS redundant if
processing_template_decl.
Richard Biener [Thu, 22 Jan 2026 13:06:50 +0000 (14:06 +0100)]
Avoid selecting masked epilogs for in-order reduction vectorization
When masking an in-order reduction we are applying the mask with a
COND_EXPR followed by an in-order accumulation of all elements,
including the masked ones. That makes loop masking not profitable.
Ideally we'd apply this logic to all loops, even when masking is
selected via --param vect-partial-vector-usage=2 but the current
way we iterate over modes (and opt-out of cost compares) does not
allow do iterate over masked vs. non-masked, so that does not work.
I plan to fix that for GCC 17, for now this fixes a regression
for tagets opting in to avx512_masked_epilogues.
* config/i386/i386.cc (ix86_vector_costs::finish_cost):
Avoid selecting masked epilogs for in-order reductions.
* gcc.dg/vect/costmodel/x86_64/costmodel-vect-epil-1.c: New
testcase.
Hongyu Wang [Fri, 9 Jan 2026 08:34:55 +0000 (16:34 +0800)]
[APX] i386: Fix illegal broadcast instruction generated by intrinsic
For _mm256_broadcastsi128_si256 call with -mapxf enabled it may produce
illegal vbroadcasti128 with egpr under high register pressure. Restrict
the pattern to use "jm" and gpr16 for avx2 alternative.
gcc/ChangeLog:
* config/i386/sse.md (avx2_vbroadcasti128_<mode>): Constraint
alternative 0 with jm and add gpr16 attr to avoid egpr usage.
testsuite: Fix issues with simulator testing in guality, simulate-thread tests
The guality and simulate-thread tests expect a native gdb to
run. That's native as in "<simulator-command-name> gdb
<prog-to-test>", not as in "<cross-name-gdb> <prog-to-test>"
(or even a cross gdb connecting to a native gdb-stub). Such
a beast does not currently exist.
Before r16-6780-g620c85fb709d27, there was an early exit for
"remote targets" such as simulator targets in gdb-test. No
test attempting to run a "native" gdb was applied to a
simulator target.
There's a wart in dejagnu sim_exec (up to and including
1.6.3 and unreleased sources as of 2026-01-20) that, instead
of returning [list -1 "error message"], it (also) calls
perror and thus a log for a test-run gets spurious lines
saying "ERROR: Remote execution for simulators not
implemented." That effectively breaks the useful quality for
such logs, that lines matching "^ERROR:" are only caused by
testsuite framework errors, like syntax errors in dg-clauses
in the test-cases.
Further, trying like gdb-test does, to execute remote_expect
for a remote_spawn:ed (sim_spawn:ed) "<simulator-command>
gdb <prog-to-test>", will for unknown reasons, hang each
test-case until it times out, despite the simulator, as
expected, immediately exiting with
e.g. '<simulator-command-name>: can't open "gdb": No such
file or directory'.
Better exit early for simulators for these parts of the
testsuite, like before r16-6780-g620c85fb709d27, but with
the early exit moved nearby those for other early exits for
specific targets, instead of e.g. inside gdb-test.
* g++.dg/guality/guality.exp, gcc.dg/guality/guality.exp,
gcc.dg/simulate-thread/simulate-thread.exp,
g++.dg/simulate-thread/simulate-thread.exp,
gfortran.dg/guality/guality.exp: Exit early for simulators.
Richard Earnshaw [Thu, 22 Jan 2026 14:16:28 +0000 (14:16 +0000)]
arm: fix unrecognized HFmode min/max insns on neon [PR123742]
When expansion support for smin/smax was enabled (presumably for MVE)
the corresponding Neon instructions were not updated to recognize the
generated RTL. This patch makes the necessary changes to recognize
these variants.
Marek Polacek [Wed, 21 Jan 2026 19:04:34 +0000 (14:04 -0500)]
c++: fix user_provided_p
A user-provided function is a user-declared function that is
not explicitly defaulted or deleted on its first declaration
([dcl.fct.def.default]). So,
void bar (int, long) = delete;
in namespace scope should not be user-provided. But user_provided_p
was mistakenly returning true for this case, so eval_is_user_provided
had to work around that.
This patch corrects user_provided_p. It makes use of the fact that
a function deleted after its first declaration is ill-formed
rather than user-provided:
void f();
void f() = delete; // error, not first declaration
gcc/cp/ChangeLog:
* class.cc (user_provided_p): Return false for a deleted
namespace-scope function.
* reflect.cc (eval_is_user_provided): Don't check
DECL_NAMESPACE_SCOPE_P or DECL_DELETED_FN.
Richard Biener [Thu, 22 Jan 2026 12:12:43 +0000 (13:12 +0100)]
tree-optimization/123741 - fix segfault with BB vect and masked stores
When vectorizing the body of an if-converted loop with BB vectorization
we can end up vectorizing masked stores. But the code tracking whether
a loop used masked stores failed to check we're doing loop
vectorization.
Frank Scheiner [Wed, 7 Jan 2026 20:55:30 +0000 (21:55 +0100)]
libstdc++-v3: Update baseline symbols for ia64-linux
The Linux/ia64 libstdc++ baselines haven't been updated in years. This
patch fixes that, makes the "libstdc++-abi/abi_check" test succeed with
master revision 8e23a9982fa4b885a27608825cbe326d61f20498.
This still excludes the GCC 16 symbols. Also the TLS symbols for
__once_call and __once_callable are excluded as per convention, because
those are not present for all configurations.
Notice that `make new-abi-baseline` will include them, so they need to
be removed from the regenerated "baseline_symbols.txt" prior to any
future update.
Robin Dapp [Wed, 21 Jan 2026 07:20:48 +0000 (08:20 +0100)]
forwprop: More nop-conversion handling [PR123731].
Since relaxing the constraints for permutes in r16-6671 for simplifying
vector constructors there is an additional case to be handled as it
interacts with r16-5561 (that allows nop conversions).
In
vector(8) short unsigned int _4;
short int _5;
vector(4) unsigned int _17;
Robin Dapp [Fri, 2 Jan 2026 15:57:21 +0000 (16:57 +0100)]
RISC-V: Fix intrinsic FoF load at -O0 [PR122869].
In the PR we try to compile a loop at -O0 with fault-only-first loads.
We use the VL adjusted by the FoF loads to count the number of
processed elements. Currently, this is implemented as "folding" the FoF
load into a FoF load and a riscv_read_vl directly after.
We cannot guarantee the value of VL between two calls, though. It is
possible that we need a vector store in between which would clobber VL.
This patch makes the VL -> pseudo semantics of the FoF insn explicit and
adjusts the intrinsics expander accordingly.
There is a problem with this approach, though: Technically, the VL
adjustment of the FoF loads is modelled as a store and the VL variable
is made TREE_ADDRESSABLE. At the gimple level we managed to elide the
store very early but at RTL level we don't. Also, we don't manage to
re-use the same register for VL at -O2 and -O3 while it still works for
-O1.
What might help with the second issue above is to add value tracking
to the vsetvl pass. I suppose the first issue would require a larger
intervention.
PR target/122869
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc (fold_fault_load):
Remove
* config/riscv/riscv-vector-builtins.cc (function_expander::use_contiguous_load_insn):
Use new helper.
(function_expander::prepare_contiguous_load_insn): New helper.
(function_expander::use_fof_load_insn): New function to emit FoF
loads.
* config/riscv/riscv-vector-builtins.h: Declare new functions.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr122656-1.c: Remove dg-error.
* gcc.target/riscv/rvv/vsetvl/ffload-3.c: XFAIL for -O2 and -O3.
* gcc.target/riscv/rvv/base/pr122869.c: New test.
Robin Dapp [Fri, 16 Jan 2026 11:54:47 +0000 (12:54 +0100)]
RISC-V: Correct builtin registration order [PR123279].
When compiling ncnn with LTO we encountered an ICE in the final link
step. The reason for this is inconsistent builtin registration
order, and, as a consequence, inconsistent functions codes being
streamed.
The underlying reason is that ncnn compiles files with different -march
options, one of them being -march=..._xtheadvector. XTheadVector does
not support fractional LMULs and several insns while also adding new
insns. As we register builtins sequentially, not registering some
builtins in one TU but registering them in another will naturally lead
to different orders and incompatible function codes.
I'm not really sure how such an executable is going to work eventually
but we should not ICE at least.
At first I tried to re-use the existing function_instance hash but that
would quickly lead to collisions due to the high number of total
builtins. Linear probing for the next bucket would have caused the same
problems we wanted to avoid in the first place.
The problem with XTheadVector in particular is that it both takes away
builtins (the ones with fractional LMUL) as well as adds its own.
Therefore just partitioning the function-code space into extensions is
not sufficient. It would be sufficient if an extension only added
builtins but the order will still be different if we just skip builtins
with fractional LMUL.
There are at least two options now:
- Create placeholders for all skipped builtins.
- Enable the unsupported builtins for XTheadVector and bail at expand
time.
In order to create placeholders we first need to get to the place where
to create them. As we have some guards for XTheadVector before that,
verifying that types are available etc., the necessary changes would
have touched several layers.
Therefore I went with the second option above, combining it with
partitioning the function space into extensions for a bit of future
proofing. Not creating placeholders is also in line with "polluting"
the march flags, i.e. enable everything reasonably possible.
To that end, the patch removes the TARGET_XTEADVECTOR-related checks
in riscv-vector-switch.def and introduces a new builtin requirement
VECTOR_EXT_NO_XTHEAD that contains the "V"-only but not XTHeadVector
builtins.
The function code now looks like this:
Bit 0: RISCV_BUILTIN_VECTOR (class bit)
Bits 1-8: Partition (rvv_builtin_partition enum)
Bits 9+: Index within partition.
I tried to come up with a test case for quite a while but didn't manage.
Reducing the ncnn LTO build failure also proved very difficult so in
order to move forwarding I'm posting the patch without a dedicated test
case.
Richard Biener [Thu, 22 Jan 2026 10:11:18 +0000 (11:11 +0100)]
tree-optimization/123756 - remove now bogus assert in reduction vect
With r16-5372-gfacb92812a4ec5 I have generalized reduction operator
support to allow (masked) internal functions in more cases. The
following removes an now bogus assert given IFN_FMAX is now allowed
given IFN_COND_FMAX is available.
Andrew Pinski [Thu, 22 Jan 2026 07:53:32 +0000 (23:53 -0800)]
testsuite: don't test for shirnk wrapping for arm thumb1 on pr46555.c [PR123751]
Thumb1 does not support shrink wrapping so the check for shrink
wrapping in pr46555.c needs to be disabled for that. It does work
with both thumb2 and arm modes.
Pushed after testing for arm with `-mthumb -march=armv8-m.base`,
`-marm -mcpu=cotext-a72` and `-mthumb -mcpu=cotext-a72` to make
sure the correct tests are happening and still pass.
PR testsuite/123751
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr46555.c: Disable for arm thumb1.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
David Malcolm [Thu, 22 Jan 2026 01:28:39 +0000 (20:28 -0500)]
sarif-replay: improve path output when source is unavailable [PR122622]
For cases where sarif-replay can't find the source, text output with
-fdiagnostics-path-format=inline-events and HTML output both lead to
the event locations and messages in replayed execution paths not being
printed at all.
Fixed thusly.
gcc/ChangeLog:
PR diagnostics/122622
* diagnostics/paths-output.cc: Include "diagnostics/file-cache.h".
(event_range::print_as_text): Generalize the fallback logic for
special locations to also cover the case where source-printing
will fail, and show the location for that case.
(event_range::print_as_html): Likewise.
(event_range::can_print_source_p): New.
gcc/testsuite/ChangeLog:
PR diagnostics/122622
* sarif-replay.dg/2.1.0-valid/missing-source-pr122622-check-html.py:
New test script.
* sarif-replay.dg/2.1.0-valid/missing-source-pr122622.sarif: New
test.
* sarif-replay.dg/2.1.0-valid/spec-example-4.sarif: Update
expected output to reflect showing event locations and text.
* sarif-replay.dg/2.1.0-valid/tutorial-example.sarif: Likewise.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
liuhongt [Mon, 19 Jan 2026 08:02:21 +0000 (00:02 -0800)]
Add u-arch tune prefer_bcst_from_integer.
/* X86_TUNE_PREFER_BCST_FROM_INTEGER: Enable broadcast from integer for
128/256/512-bit vector, if disabled, the move will be done by
broadcast/load from constant pool
broadcast from integer:
mov $0xa,%eax
vmovd %eax,%xmm0
vpbroadcastd %xmm0,%xmm0
broadcast/load from constant pool:
vpbroadcastd CST.0(%rip), %xmm0 */
The tune is on by default.
gcc/ChangeLog:
PR target/123631
* config/i386/i386-expand.cc (ix86_vector_duplicate_value):
Don't force CONST_INT to reg !TARGET_PREFER_BCST_FROM_INTEGER,
force it to mem instead.
* config/i386/i386.h (TARGET_PREFER_BCST_FROM_INTEGER): New macro.
* config/i386/x86-tune.def
(X86_TUNE_PREFER_BCST_FROM_INTEGER): New tune.
David Malcolm [Wed, 21 Jan 2026 18:43:03 +0000 (13:43 -0500)]
analyzer: ensure that concrete binding keys don't overlap
Add assertions on the internal state of the analyzer, made
possible by r16-4334-g310a70ef6db45d, to verify that concrete binding
keys don't overlap.
Doing so uncovers an issue in the state merging where overzealous merging
of partially-overlapping maps could lead to a malformed merged state.
Fix this by rejecting such state mergers.
gcc/analyzer/ChangeLog:
* store.cc (binding_cluster::validate): Reimplement as...
(binding_map::validate): ...this new function, using
m_concrete and m_symbolic sizes rather than iterating through
map and counting. Verify that concrete keys do not overlap.
(binding_cluster::can_merge_p): Reject cases that would lead to
overlapping concrete clusters.
* store.h (binding_cluster::validate): New decl.
(binding_map::get_concrete_bindings): New accessor.
gcc/testsuite/ChangeLog:
* c-c++-common/analyzer/flex-without-call-summaries.c: Skip on
C++98 and tweak xfails to reflect slight differences in where
we hit exploration limits.
* c-c++-common/analyzer/raw-data-cst-pr117262-1.c: Add params to
force full exploration of the loop.
* gcc.dg/analyzer/pr93355-localealias.c (read_alias_file): Drop
xfail.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Wed, 21 Jan 2026 18:42:48 +0000 (13:42 -0500)]
analyzer: different decls don't alias
While debugging an issue where a binding_map could erroneously have
overlapping concrete bindings, I noticed a couple of cases in
haproxy-2.7 arising due to decls with !tracked_p leading to eval_alias
being called by store::set_value, and erroneously returning TS_UNKNOWN,
leading to writes to those decls affecting other decls.
Fixed thusly.
gcc/analyzer/ChangeLog:
* store.cc (store::eval_alias): Different decls don't alias.
gcc/testsuite/ChangeLog:
* c-c++-common/analyzer/aliasing-4.c: New test.
* c-c++-common/analyzer/aliasing-5.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Gaius Mulley [Wed, 21 Jan 2026 18:33:30 +0000 (18:33 +0000)]
[PR modula2/123739] The help option descriptions are not capitalized
All option descriptions are now capitalized and some of the help
messages have been improved. A Warning tag (after the language label)
has been added to all warning options.
gcc/m2/ChangeLog:
PR modula2/123739
* lang.opt: All option descriptions are now capitalized.
(Wcase-enum): Warning tag added.
(Wpedantic-param-names): Ditto.
(Wpedantic-cast): Ditto.
(Wverbose-unbounded): Ditto.
(Wstyle): Ditto.
(Wuninit-variable-checking): Ditto.
(Wuninit-variable-checking=): Ditto.
Marek Polacek [Tue, 20 Jan 2026 18:53:12 +0000 (13:53 -0500)]
c++: introduce maybe_get_first_fn
In reflect.cc, we have maybe_get_reflection_fndecl to maybe
extract the BASELINK / OVL_FIRST from an expression. We could
introduce a more general function that the rest of the compiler
can use as well, based on maybe_get_fns. I currently do not see
any spots that could use this new function, though.
Marek Polacek [Fri, 16 Jan 2026 19:13:16 +0000 (14:13 -0500)]
c++: tighten up is_std_substitution
During Reflection review it came up that is_std_substitution
handles NAMESPACE_DECLs accidentally: it wants either a class or a
class template, but is looking at the type of any decl. With this
patch, we return false for any _DECL except TYPE_DECL and
DECL_CLASS_TEMPLATE_P, but let's verify that we now don't return false
for something that used to yield true.
gcc/cp/ChangeLog:
* mangle.cc (is_std_substitution): Return false for any _DECL except
TYPE_DECL and DECL_CLASS_TEMPLATE_P. Verify that we don't return false
for something that used to yield true. Use NULL_TREE instead of NULL.
s390: Don't emulate vec_cmpgtuv1tiv1ti for VXE3 [PR122781]
Starting with VXE3, 128-bit integer compares are natively supported.
For older machines those compares are emulated via
*vec_cmpeq<mode><mode>_nocc_emu and *vec_cmpgt<mode><mode>_nocc_emu and
*vec_cmpgtu<mode><mode>_nocc_emu. The latter was missing !TARGET_VXE3
in the condition which resulted in emulating unsigned greater-than
compares instead of making use of the new instructions enabled by
r15-7051.
PR target/122781
gcc/ChangeLog:
* config/s390/vector.md: Don't emulate vec_cmpgtu for 128-bit
integers for VXE3.
Jakub Jelinek [Wed, 21 Jan 2026 13:32:26 +0000 (14:32 +0100)]
c++: Fix ICE in build_base_path -> resolves_to_fixed_type_p -> fixed_type_or_null [PR123692]
The move of the resolves_to_fixed_type_p call earlier in build_base_path
for constexpr virtual inheritance caused the following ICE.
What changed is that in an unevaluated context expr can be a CALL_EXPR with
class type and when it is not a ctor,
resolves_to_fixed_type_p -> fixed_type_or_null
ICEs on it:
if (CLASS_TYPE_P (TREE_TYPE (instance)))
{
/* We missed a build_cplus_new somewhere, likely due to tf_decltype
mishandling. */
gcc_checking_assert (false);
Now, the reason why that worked fine when resolves_to_fixed_type_p was
later in the function is that there was
/* This must happen before the call to save_expr. */
expr = cp_build_addr_expr (expr, complain);
in between the new and old calls to resolves_to_fixed_type_p, and for the
uneval case like that
cp_build_addr_expr -> unary_complex_lvalue -> build_cplus_new
wraps the CALL_EXPR into a TARGET_EXPR already, so the later call
was happy.
Now, none of fixed_type_p, virtual_access or nonnull values are ever
used in the build_base_path uneval path.
if (code == PLUS_EXPR
&& !want_pointer
&& !has_empty
&& !uneval
&& !virtual_access)
return build_simple_base_path (expr, binfo);
doesn't look at it,
if (!want_pointer)
{
rvalue = !lvalue_p (expr);
/* This must happen before the call to save_expr. */
expr = cp_build_addr_expr (expr, complain);
}
else
expr = mark_rvalue_use (expr);
neither, nothing soon after it either and very soon we
if (uneval)
{
expr = build_nop (ptr_target_type, expr);
goto indout;
}
and indout: doesn't use it either.
So, if only uneval expressions have problems with moving the
resolves_to_fixed_type_p call earlier, the following patch fixes
it by just not calling that function at all in the uneval case
because we will not care about the result anyway.
2026-01-21 Jakub Jelinek <jakub@redhat.com>
PR c++/123692
* class.cc (build_base_path): Don't call resolves_to_fixed_type_p if
uneval.
Jakub Jelinek [Wed, 21 Jan 2026 13:30:03 +0000 (14:30 +0100)]
c++: Fix ICE with constant evaluation of a = {CLOBBER} with ptrmemfn [PR123677]
The following testcase ICEs when we evaluate a = {CLOBBER} stmt.
The code assumes that if type is an aggregate type and *valp is
non-NULL, then it must be a CONSTRUCTOR.
That is usually the case, but there is one exception, *valp can
be a PTRMEM_CST if TYPE_PTRMEMFUNC_P (type) and in that
case CONSTRUCTOR_ELTS (*valp) obviously ICEs or misbehaves.
Now, while I could do something like
if (*valp && (!TYPE_PTRMEMFUNC_P (type) || TREE_CODE (*valp) != PTRMEM_CST))
just making sure TREE_CODE (*valp) == CONSTRUCTOR seems much easier
and more readable.
2026-01-21 Jakub Jelinek <jakub@redhat.com>
PR c++/123677
* constexpr.cc (cxx_eval_store_expression): Only clear
CONSTRUCTOR_ELTS (*valp) if *valp is CONSTRUCTOR.
Eric Botcazou [Wed, 21 Jan 2026 10:47:42 +0000 (11:47 +0100)]
Ada: Fix visibility issue on generic parent from nested generic package
The problem is that we temporarily push onto the scope stack and install
the declarations of a package that is already on the scope stack and whose
declarations are already visible so, when the temporary condition is over,
the declarations are uninstalled, thus making them definitively invisible.
It comes from the use of the idiom Scope_Within_Or_Same (Current_Scope, S)
to detect whether S is open in the current scope, but that's not robust in
the presence of transient scopes or during instantiation of generic units.
gcc/ada/
* sem_ch13.adb (Analyze_Aspects_At_Freeze_Point): Replace call to
Scope_Within_Or_Same (Current_Scope, S) with In_Open_Scopes (S) to
test whether S is open in the current scope.
* sem_util.adb (From_Nested_Package): Likewise.
If the default CPU under testing merely supports Thumb2, but doesn't
default to it, thumb2-pop-loreg.c fails because the expected pop
instruction won't be found. Enable -mthumb explicitly.
Alexandre Oliva [Wed, 21 Jan 2026 03:30:14 +0000 (00:30 -0300)]
testsuite: arm: bf16_vstn_1 vst3q_bf16 improved by late-combine
The late-combine pass removes some unnecessary register copying in
bf16_vstn_1.c, copying that was expected by vst3q_bf16. Adjust the
expectations so that they match the better code we get now.
for gcc/testsuite/ChangeLog
* gcc.target/arm/simd/bf16_vstn_1.c: Adjust expectations for
code improved by late-combine.
Alexandre Oliva [Wed, 21 Jan 2026 03:30:10 +0000 (00:30 -0300)]
testsuite: enable use of cxa_atexit on tree-ssa cxa_atexit tests
The expected cxa_atexit calls and optimizations won't take place on
targets that don't have -fuse-cxa-atexit enabled by default. Enabling
it explicitly is enough to meet the expectations of the cxa_atexit
tests.
Alexandre Oliva [Wed, 21 Jan 2026 03:30:01 +0000 (00:30 -0300)]
testsuite: silence nolto-rel warning in pr62026_0.C
On some targets, pr62026_0.C issues a warning about implicitly passing
-flinker-output=nolto-rel, which flags the test as a failure. Pass
the flag explicitly to avoid the warning.
Alexandre Oliva [Wed, 21 Jan 2026 03:29:58 +0000 (00:29 -0300)]
testsuite: enable use of cxa_atexit on abi tag18a test
The _ZZZ1fB7__test1vEN1T1gEvE1x symbol is only output with the ABI tag
when cxa_atexit is available for use. On targets that default to
-fno-use-cxa-atexit, the test fails gratuitously. Add an explicit
-fuse-cxa-atexit, along with a requirement for cxa_atexit support.
for gcc/testsuite/ChangeLog
* g++.dg/abi/abi-tag18a.C: Require and enable cxa_atexit.
Alexandre Oliva [Wed, 21 Jan 2026 03:29:54 +0000 (00:29 -0300)]
testsuite: add hostedlib requirements to multiple C++ tests
Various C++ tests added in the gcc-15 cycle require features that are
only available when libstdc++-v3 is built in hosted mode, so they fail
when this is not the case. Skip them if ! hostedlib.
Alexandre Oliva [Wed, 21 Jan 2026 03:29:48 +0000 (00:29 -0300)]
testsuite: _Static_assert is not present in C90
fp8-helpers-neon.c uses _Static_assert, but the compiler warns that
this feature is not present in C90. Annotate it as an __extension__
to silence the warning, preserving the intent of the test.
for gcc/testsuite/ChangeLog
* gcc.target/aarch64/acle/fp8-helpers-neon.c: Silence
warnings about _Static_assert.
Alexandre Oliva [Wed, 21 Jan 2026 03:29:44 +0000 (00:29 -0300)]
testsuite: require c99_runtime for ldexp optimizations
ldexpf and ldexpl are only optimized as expected when the target libc
is known to have C99 support, so don't expect those optimizations when
HAVE_C99_RUNTIME is not set by builtins-config.h.
for gcc/testsuite/ChangeLog
* gcc.dg/tree-ssa/ldexp.c: Require HAVE_C99_RUNTIME to test
ldexpf and ldexpl.
Alexandre Oliva [Wed, 21 Jan 2026 03:29:36 +0000 (00:29 -0300)]
testsuite: drop explicit run from dfp execution tests
dfp support isn't built into libgcc when fenv.h doesn't define the
expected FE_* macros, but some dfp tests go "dg-do run", overriding
the default "compile" when dfprt is not available.
Drop the overrider.
for gcc/testsuite/ChangeLog
* gcc.dg/dfp/c23-decimal64x-1.c: Drop the explicit dg-do run.
* gcc.dg/dfp/c23-decimal64x-3.c: Likewise.
Jeff Law [Tue, 20 Jan 2026 22:03:28 +0000 (15:03 -0700)]
[PR rtl-optimization/123380] Avoid creating bogus SUBREG in combine
In this issue we try to call gen_rtx_SUBREG with arguments that will trigger an
assertion failure. In particular we're trying to create a paradoxical subreg
of an HFmode object where the paradoxical is in DImode. That's obviously a
change in size. validate_subreg returns false for that case, thus triggering
the assertion.
Like other cases in combine.cc and elsewhere we can check validate_subreg
before we call gen_rtx_SUBREG and if validate_subreg returns false, we can
return a safe value. So that's all this patch does.
Bootstrapped and regression tested on x86_64, also regression tested on
riscv{32,64}-elf. Pushing to the trunk.
PR rtl-optimization/123380
gcc/
* combine.cc (gen_lowpart_for_combine): Don't try to create a
paradoxical SUBREG if it's going to be rejected by validate_subreg.
gcc/testsuite/
* gcc.target/riscv/pr123380.c: New test.
Jeff Law [Tue, 20 Jan 2026 20:57:10 +0000 (13:57 -0700)]
[RISC-V][PR target/123626] Fix VXRM state after calls
This is a partial fix for a long standing issue that Richard S. raised about a
year ago.
Specifically he indicated that he believed our handling of VXRM mode switching
was wrong and could lead to incorrect code, particularly WRT handling of calls.
Without rehashing everything related to VXRM, its sufficient to say that it has
no known value at function entry or upon returning from a call.
If we look at the main scan loop in mode-switching we have:
The way to think about this is if INSN requests a mode and it is not the same
as the last mode, then we've got a new point where we need to logically insert
a mode switch and we clear TRANSP.
A CALL_INSN in the RISC-V backend produces NO_MODE (it doesn't need VXRM
state). So we never get into the then clause of that inner if statement and
TRANSP stays on.
The fix is quite simple. We need one more state in the VXRM mode switching
that indicates we don't know VXRM's state after a call. While I could have
hacked up the various hooks to special case CALLs, it was just as easy to
adjust the attribute's generic handling so that any CALL_P is given the
VXRM_MODE_CLOBBER state.
Out of an abundance of caution if we'll filter out any actual code generation
setting it to CLOBBER state.
This is enough to make the testcase pass for rv64. It's still failing rv32,
but likely for completely different reasons. It obviously doesn't cause any
regressions on riscv{32,64}-elf and bootstraps will fire up later today on the
Pioneer and BPI.
PR target/123626
gcc/
* config/riscv/vector.md (vxrm_mode): Handle CALL_INSNs, which set
the attribute to the new VXRM_MODE_CLOBBER state.
* config/riscv/riscv.cc (riscv_emit_mode_set): Don't emit code when
VXRM's state changes to VXRM_MODE_CLOBBER.
gcc/testsuite
* gcc.target/riscv/rvv/base/pr123626.c: New test.
Patrick Palka [Tue, 20 Jan 2026 20:25:07 +0000 (15:25 -0500)]
c++: non-dep reversed <=> returning int [PR123601]
The code path for non-dependent operator expressions rewritten from a
<=> returning a non-class type (added in r16-3727-gf2fddc4b84a843) is
also reached for a reversed such <=> expression with the form
0 @ (y <=> x) where the @ is <=>, so we need to relax the relevant
assert accordingly.
PR c++/123601
gcc/cp/ChangeLog:
* tree.cc (build_min_non_dep_op_overload): Relax
COMPARISON_CLASS_P assert to accept SPACESHIP_EXPR too.
Andrew MacLeod [Mon, 19 Jan 2026 18:44:25 +0000 (13:44 -0500)]
Do not trap on a stmt with no basic block.
WHen calculating ranges for statements not in the IL, avoid looking for
range on entry values.
PR tree-optimization/123314
gcc/
* gimple-range.cc (gimple_ranger::range_on_entry): Do not check
ranger cache for an SSA_NAME with no BB.
(gimple_ranger::prefill_stmt_dependencies): Stop filling
dependencies when an out-of IL name is encountered.
PR sarif-replay/123056 notes that when using sarif-replay to generate
HTML from a .sarif file containing an embedded "sarif:/" link we get
bogus output containing SGR codes.
The links in question come from GCC's sarif output for cross-referencing
event IDs within an execution path.
These links are JSON pointers. I experimented with propertly supporting
the JSON Pointer spec (RFC 6901) within GCC, and I have a partially
working implementation which parses JSON pointers here, and, where
appropriate, reconstructs the pertinent event ID.
However, that feels too invasive to be pushing in stage 4. Hence for
GCC 16, this patch simply skips the link part of "sarif:/" links in
sarif-replay, avoiding corrupt output, deferring the more ambitious
round-tripping fix to GCC 17.
gcc/ChangeLog:
PR sarif-replay/123056
* libsarifreplay.cc (struct embedded_link): Move decl earlier.
(sarif_replayer::append_embeddded_link): New.
(sarif_replayer::make_plain_text_within_result_message): Move the
link-replay logic to the above, and skip the link part of
intra-sarif links.
gcc/testsuite/ChangeLog:
PR sarif-replay/123056
* sarif-replay.dg/2.1.0-valid/3.11.6-embedded-links-pr123056.sarif: New test.
* sarif-replay.dg/2.1.0-valid/embedded-links-pr123056-check-html.py:
New test script.
* sarif-replay.dg/2.1.0-valid/embedded-links-pr123056-check-sarif-roundtrip.py:
New test script.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Tue, 20 Jan 2026 17:06:11 +0000 (12:06 -0500)]
analyzer: fix -Wmaybe-uninitialized of 'edge_sense'
gcc/analyzer/ChangeLog:
* checker-event.cc (cfg_edge_event::maybe_get_edge_sense): New.
* checker-event.h (cfg_edge_event::maybe_get_edge_sense): New decl.
* diagnostic-manager.cc
(diagnostic_manager::consolidate_conditions): Use the above to
ensure that edge_sense is initialized if used, and to simplify
the check for a run of conditions.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Jakub Jelinek [Tue, 20 Jan 2026 16:06:54 +0000 (17:06 +0100)]
c++: Fix -Wmisleading-indentation ICE on expansion stmt [PR123694]
The following testcase ICEs in the -Wmisleading-indentation warning.
For C++11 and later expansion statement can appear in the set of keywords
the warning sees and it is the first keyword of it (for expansion stmt
of a pair of keywords), so RID_TEMPLATE.
2026-01-20 Jakub Jelinek <jakub@redhat.com>
PR c++/123694
* c-indentation.cc (guard_tinfo_to_string): Handle RID_TEMPLATE
for C++11 or later.
Jakub Jelinek [Tue, 20 Jan 2026 14:38:24 +0000 (15:38 +0100)]
aarch64: Ignore debug stmts in aarch64_possible_by_lane_insn_p [PR123724]
Like in many other spots, when walking immediate uses for optimization decisions
we should just ignore debug stmts. aarch64_possible_by_lane_insn_p wasn't
ignoring those and wasted time on doing lookup for those and ICEd because
it wasn't a vectorizable stmt.
Fixed by ignoring debug stmts early during the immediate use walk.
Marek Polacek [Fri, 16 Jan 2026 18:00:35 +0000 (13:00 -0500)]
c++: adjust visibility of _DECLs with no linkage
This came up during Reflection review:
<https://gcc.gnu.org/pipermail/gcc-patches/2026-January/705175.html>
Certain entities, e.g. vars in public inline functions or template
functions should be exported. But entities defined within TU-local
should not be exported.
This patch adjusts min_vis_expr_r to that effect as per the Reflection
discussion.
gcc/cp/ChangeLog:
* decl2.cc (min_vis_expr_r): For _DECLs with no linkage refer to the
linkage of the containing entity that does have a name with linkage.
Roger Sayle [Tue, 20 Jan 2026 14:07:55 +0000 (14:07 +0000)]
PR rtl-optimization/123585: ICE in vec_select simplification on x86_64.
This patch is my proposed fix to PR rtl-optimization/123585, an ICE caused
by some incorrect logic in a gcc_assert.
2026-01-20 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR rtl-optimization/123585
* simplify-rtx.cc (simplify_context::simplify_binary_operation_1)
<case VEC_SELECT>: Correct gcc_assert when optimizing a vec_select
of a vec_select with differing vector lengths.
gcc/testsuite/ChangeLog
PR rtl-optimization/123585
* gcc.target/i386/pr123585.c: New test case.
Kyrylo Tkachov [Thu, 15 Jan 2026 13:22:46 +0000 (05:22 -0800)]
aarch64: Adjust predicate used for SVE2 SHA3 XAR rotate amount
While fixing the Advanced SIMD XAR patterns I looked at SVE2 and
it looks okay there but the rotate amount should use the
aarch64_simd_rshift_imm predicate rather than lshift_imm since the
instruction (unlike the Advanced SIMD version) takes values from
[1, bitwidth].
Bootstrapped and tested on aarch64-none-linux-gnu.
Kyrylo Tkachov [Thu, 15 Jan 2026 13:10:31 +0000 (05:10 -0800)]
aarch64: PR target/123584 - Fix expansion of SHA3 XAR with 0 amount
In this PR the vxarq_u64 intrinisc gets passed a rotate amount of 0
and the patterns don't handle it right. Because we adjust RTL amount
during expand to account for the canonical representation we end up
emitting a V2DImode rotate of 64, which the output instruction is not
prepared to handle. What we should be doing is leaving it as 0 in
that case, which is what this patch does.
A XAR with a rotate of 0 is really just an EOR and we could have emitted
it as such but I thought that, at least at -O0, it would be nicer to emit
the XAR-0 form as it's still a legal instruction and the user did ask for
it through the intrinsic. At -O1 and above the optimisers kick in and simplify
it to an EOR anyway.
Note: the SVE2 XAR instruction doesn't suffer from this problem because a
rotate amount of 0 is actually not allowed by the instruction itself and
the early intrinsic validation rejects it anyway.
Bootstrapped and tested on aarch64-none-linux-gnu.
PR target/123584
* config/aarch64/aarch64-simd.md (aarch64_xarqv2di): Leave zero
rotate amounts as zero during expansion.
(*aarch64_xarqv2di_insn): Account for zero rotate amounts. Print #
in rotate immediate.
gcc/testsuite/
PR target/123584
* gcc.target/aarch64/torture/xar-zero.c: New test.
Prachi Godbole [Tue, 20 Jan 2026 04:49:38 +0000 (20:49 -0800)]
ipa-reorder-for-locality - Introduce C++ template heuristics
This patch introduces a new heuristics for reordering functions, to be used
in the absense of profile information. This approach uses C++ template
instantiation types to group functions together. Entry functions are sorted
in the beginning, and callees are sorted as part of partition_callchain ().
Bootstrapped and tested on aarch64-none-linux-gnu.
Prachi Godbole [Tue, 20 Jan 2026 04:31:43 +0000 (20:31 -0800)]
ipa-reorder-for-locality - Address compile time issues for locality cloning pass
This patch attempts to reduce compile time for locality cloning pass by
reducing recursive calls to partition_callchain (). This is achieved by
precomputing caller callee information into locality_info. locality_info
stores all callees of a node, either directly or via inlined nodes thereby
avoiding calls to partition_callchain () for inlined nodes which are already
partitioned with their inlined_to nodes. locality_info stores precomputed
accumulated incoming edge frequencies per unique caller and avoids repeated
computation within partition_callchain (). It also stores preaccumulated and
sorted outgoing edge frequencies for unique callees.
This patch refines is_entry_node_p () check by calling local_p () instead of
just alias check.
Approximately 45% compile time improvement is observed for
bootstrap-lto-locality config, and takes 2-5% more time on top of
bootstrap-lto.
This patch also handles appropriate memory management of pass specific data
structures.
Bootstrapped and tested on aarch64-none-linux-gnu.
Richard Biener [Tue, 20 Jan 2026 09:57:34 +0000 (10:57 +0100)]
middle-end/123697 - fix .MASK_LOAD_LANES folding
.MASK_LOAD_LANES has an aggregate (array of vectors) return value
which is not compatible with the else value used when trying to
fold this with all lanes inactive. Instead use an empty CTOR if
the else value is zero and otherwise do not simplify.
PR middle-end/123697
* gimple-fold.cc (gimple_fold_partial_load_store): Use an
empty CTOR for a zero else value in .MASK_LOAD_LANES.
Jakub Jelinek [Tue, 20 Jan 2026 11:01:07 +0000 (12:01 +0100)]
libstdc++: Disable __cpp_lib_reflection for old CXX ABI
Reflection currently doesn't work with -D_GLIBCXX_USE_CXX11_ABI=0.
The problem is that std::meta::exception currently uses under the
hood std::string and std::u8string and those aren't constexpr in
the old ABI.
While those members are in the standard exposition-only and so
we could make it to work by writing a custom class template that
just remembers const char{,8_t} * and size_t, there shouldn't be
many people trying to use C++26 features with the ABI that isn't
even compatible with C++11.
Last night I was surprised because make check help.exp reported the missing
dot at the end of cobol/lang.opt description below:
Wmove-index
Cobol Warning Var(move_index, 1) Init(1)
Warn if MOVE INDEX is used
but has not reported
fexec-national-charset=
Cobol Joined Var(cobol_national_charset) RejectNegative
Set the default execution character set for NATIONAL data items
a few lines earlier.
The problem is that help.exp verified output of
--help={common,optimizers,param,target,warnings} and just selected FEs:
--help={ada,c,c++,d,fortran,go} and no other languages.
Wmove-index above got reported because it appears in --help=warnings,
but fexec-national-charset= didn't, because it only appears in --help=cobol
So, the following patch adds 6 further languages to what help.exp tests
and fixes the reported bugs.
2026-01-20 Jakub Jelinek <jakub@redhat.com>
gcc/testsuite/
* gcc.misc-tests/help.exp: Check for descriptions without terminating
dot or semicolon also for objc, objc++, rust, modula-2, cobol and
algol68.
gcc/rust/
* lang.opt (frust-crate=, frust-extern=,
frust-incomplete-and-experimental-compiler-do-not-use,
frust-max-recursion-depth=, frust-crate-type=, frust-mangling=,
frust-cfg=, frust-edition=, frust-embed-metadata,
frust-metadata-output=, frust-compile-until=,
frust-name-resolution-2.0, frust-panic=, frust-overflow-checks): Add
dot at the end of the description.
gcc/cobol/
* lang.opt (fexec-national-charset=): Add dot at the end of the
description.
gcc/algol68/
* lang.opt (std=algol68, std=gnu68): Add dot at the end of the
description.
gcc/m2/
* lang.opt (Wpedantic-param-names, Wpedantic-cast, Wverbose-unbounded,
Wstyle, fauto-init, fbounds, fcase, fcpp, fcpp-end, fcpp-begin,
fdebug-builtins, fd, fdebug-function-line-numbers, fdef=,
fdump-system-exports, fextended-opaque, ffloatvalue,
fgen-module-list=, findex, fiso, flocation=, fm2-debug-trace=,
fm2-dump=, fm2-dump-decl=, fm2-dump-gimple=, fm2-dump-quad=,
fm2-dump-filter=, fm2-file-offset-bits=, fm2-g, fm2-lower-case,
fm2-pathname=, fm2-pathname-root=, fm2-pathname-rootI=, fm2-plugin,
fm2-prefix=, fm2-statistics, fm2-strict-type, fm2-strict-type-reason,
fm2-whole-program, fmod=, fnil, fpim, fpim2, fpim3, fpim4,
fpositive-mod-floor-div, fpthread, fq, frange, freturn,
fruntime-modules=, fscaffold-dynamic, fscaffold-c, fscaffold-c++,
fscaffold-main, fscaffold-static, fshared, fsoft-check-all, fsources,
fswig, fuse-list=, fwideset, fwholediv, fwholevalue, save-temps,
save-temps=): Add dot at the end of the description.
Richard Biener [Tue, 20 Jan 2026 09:24:20 +0000 (10:24 +0100)]
tree-optimization/123729 - fix reduction epilog flowing into abnormal edge
When we vectorize a reduction and the reduction value flows across
an abnormal edge we have to make sure to mark the final SSA properly.
The following serves as a recipie how to avoid blindly copying
SSA_NAME_OCCURS_IN_ABNORMAL_PHI but instead set it when needed during
use replacement.
PR tree-optimization/123729
* tree-vect-loop.cc (vect_create_epilog_for_reduction): Set
SSA_NAME_OCCURS_IN_ABNORMAL_PHI if the reduction flows
across an abnomal edge.
libgomp: Ensure memory sync after performing tasks
As described in PR 122356 there is a theoretical bug around not
"publishing" user data written in a task when that task has been
executed by a thread after entry to a barrier.
Key points of the C memory model that are relevant:
1) Memory writes can be seen in a different order in different threads.
2) When one thread (A) reads a value with acquire memory ordering that
another thread (B) has written with release memory ordering, then all
data written in thread (B) before the write that set this value will
be visible to thread (A) after that read.
3) This point requires that the read and write operate on the same
value. The guarantee is one-way: It specifies that thread (A) will
see the writes that thread (B) has performed before the specified
write. It does not specify that thread (B) will see writes that
thread (A) has performed before reading this value.
Outline of the issue:
1) While there is a memory sync at entry to the barrier, user code can
be ran after threads have all entered the barrier.
2) There are various points where a memory sync can occur after entry to
the barrier:
- One thread getting the `task_lock` mutex that another thread has
released.
- Last thread incrementing `bar->generation` with `MEMMODEL_RELEASE`
and some other thread reading it with `MEMMODEL_ACQUIRE`.
However there are code paths that can avoid these points.
3) On the code-paths that can avoid these points we could have no memory
synchronisation between a write to user data that happened in a task
executed after entry to the barrier, and some other thread running
the implicit task after the barrier. Hence that "other thread" may
read a stale value that should have been overwritten in the explicit
task.
There are two code-paths that I believe I've identified:
1) The last thread sees `task_count == 0` and increments the generation
with `MEMMODEL_RELEASE` before continuing on to the next implicit
task.
If some other thread had executed a task that wrote user data I
don't see any way in which an acquire-release ordering *from* the
thread writing user data *to* the last thread would have been formed.
2) After all threads have entered the barrier. Some thread (A) is
waiting in `do_wait`. Some other thread (B) completes a task writing
user data. Thread (B) increments the generation using
`gomp_team_barrier_done` (non atomically -- hence not allowing the
formation of any acquire-release ordering with this write). Thread
(A) reads that data with `MEMMODEL_ACQUIRE`, but since the write was
not atomic that does not form an ordering.
This patch makes two changes:
1) The write of `task_count == 0` in `gomp_barrier_handle_tasks` is done
atomically while the read of `task_count` in
`gomp_team_barrier_wait_end` is also made atomic. This addresses the
first case by forming an acquire-release ordering *from* the thread
executing tasks *to* the thread that will increment the generation
and continue.
2) The write of `bar->generation` via `gomp_team_barrier_done` called
from `gomp_barrier_handle_tasks` is done atomically. This means that
it will form an acquire-release synchronisation with the existing
atomic read of `bar->generation` in the main loop of
`gomp_team_barrier_wait_end`.
Testing done:
- Bootstrap & regtest on aarch64 and x86_64.
- With & without _LIBGOMP_CHECKING_.
- Testsuite with & without OMP_WAIT_POLICY=passive
- Cross compilation & regtest on arm.
- TSAN done on this as part of all my upstream patches.
libgomp: Enforce tasks executed lexically after scheduled
In PR122314 we noticed that our implementation of a barrier could
execute tasks from the next "Task scheduling" region. This was because
of a race condition where a barrier could be "completed", and some
thread raced ahead to schedule another task on the "next" barrier all
before some other thread checks for a bit on the generation number to
tell if there is a task pending.
The solution provided here is to check whether the generation number has
"incremented" past the state that this barrier was entered with. As it
happens the `state` variable already provided to
`gomp_barrier_handle_tasks` is enough for the targets to tell whether
the current global generation has incremented from the existing one.
This requires some changes in the two loops in bar.c that are waiting on
tasks being available. These loops now need to check for "generation
has incremented" rather than "generation is identical to one increment
forward". Without such an adjustment of the check a thread that is
refusing to execute tasks because they have been scheduled for the next
barrier will not continue into the next region until some other thread
has completed the task (and removed the BAR_TASK_PENDING flag).
This problem could be seen by a hang in testcases like
task-reduction-13.c.
Testing done:
- Bootstrap & regtest on aarch64 and x86_64.
- With & without _LIBGOMP_CHECKING_.
- Testsuite with & without OMP_WAIT_POLICY=passive
- Cross compilation & regtest on arm.
- TSAN done on this as part of all my upstream patches.
Jakub Jelinek [Tue, 20 Jan 2026 00:18:51 +0000 (01:18 +0100)]
cobol: Fix up -Wmove-index option description
I'm seeing
FAIL: compiler driver --help=warnings option(s): "^ +-.*[^:.]\$" absent from output: " -Wmove-index Warn if MOVE INDEX is used"
That is a test which verifies all option descriptions end with a dot or semicolon.
Fixed thusly:
2026-01-20 Jakub Jelinek <jakub@redhat.com>
* lang.opt (Wmove-index): Add missing dot at the end of description.
Pietro Monteiro [Tue, 20 Jan 2026 00:00:44 +0000 (19:00 -0500)]
algol68: Add allocation function for leaf objects
Boehm GC has a malloc_atomic function that doesn't clear the new
allocation and doesn't scan it for pointers.
Add a wrapper for the GC malloc_atomic in the run-time library and use it to
allocate GC-collectable strings in the library.
Change the lowering of malloc on the front end to select the run-time GC malloc
function to be used based on the mode having pointers or not. Use leaf
allocations for modes that are not refs or that don't contain refs.
A boolean `has_refs' member was added to MOID_T and the computation of the
atrribute is done by the parser when generating the mode list.
gcc/algol68/ChangeLog:
* a68-low-clauses.cc (a68_lower_collateral_clause): Update
call to a68_lower_alloca.
* a68-low-coercions.cc (a68_lower_widening): Likewise.
* a68-low-generator.cc (allocator_t): Adjust typedef.
(fill_in_buffer): Adjust call to allocator.
(gen_mode): Likewise.
* a68-low-multiples.cc (a68_row_malloc): Change type parameter to MOID_T
from tree. Adjust call to a68_lower_malloc.
* a68-low-posix.cc (a68_posix_fgets): Adjust call to a68_row_malloc.
(a68_posix_gets): Likewise.
* a68-low-runtime.def (MALLOC_LEAF): Add definition for
_libga68_malloc_leaf.
* a68-low-strings.cc (a68_string_concat): Adjust call to
a68_lower_malloc.
(a68_string_from_char): Likewise.
* a68-low-units.cc (a68_lower_slice): Likewise.
* a68-low.cc (a68_low_dup): Adjust calls to a68_lower_malloc
and a68_lower_alloca.
(a68_lower_alloca): Change type parameter to MOID_T from tree.
(a68_lower_malloc): Likewise. Use _libga68_malloc_leaf if the MOID_T
doesn't have refs, use _libga68_malloc otherwise.
* a68-parser-modes.cc (a68_create_mode): Set has_refs on the new mode.
(is_mode_has_refs): New function.
(compute_derived_modes): Set has_refs on the chain of modes.
* a68-parser.cc (a68_new_moid): Set has_refs to false by
default.
* a68-types.h (struct MOID_T): Add member `has_refs`.
(HAS_REFS): New macro.
* a68.h (a68_row_malloc): Update prototype.
(a68_lower_alloca): Likewise.
(a68_lower_malloc): Likewise.
libga68/ChangeLog:
* ga68-alloc.c (_libga68_malloc_leaf): New function.
* ga68-posix.c (_libga68_posixfgets): Use _libga68_malloc_leaf
instead of _libga68_malloc.
* ga68-unistr.c (_libga68_u32_to_u8): Likewise.
(_libga68_u8_to_u32): Likewise.
* ga68.h (_libga68_malloc_leaf): New prototype.
* ga68.map: Add _libga68_malloc_leaf to the global map.
Signed-off-by: Pietro Monteiro <pietro@sociotechnical.xyz>
Jeff Law [Mon, 19 Jan 2026 22:53:22 +0000 (15:53 -0700)]
[RISC-V][PR rtl-optimization/121787] Work around bad cfglayout interaction with asm goto
This is a suggestion from Richi in the PR.
The RISC-V backend calls the loop initialization routines during setup for
vsetvl insertion/optimization. Right now that uses LOOPS_NORMAL which allows
various adjustments to the loop structure. The interaction between those CFG
adjustments and asm goto support is putting the CFG into an undesirable state.
There's potentially an issue in the CFG layout bits, but we can punt that out
by using AVOID_CFG_MODIFICATIONS when calling loop_optimizer_init. My review
of the vsetvl code doesn't show any direct need for clean preheaders, latches,
etc -- the biggest thing it needs is for infinite loops to be connected to the
exit block which is handled outside of loop_optimizer_init.
So this is a workaround, but enough to get the PR off the regression list.
Waiting for pre-commit CI to do its thing, though it has already passed
riscv{32,64}-elf for me. Bootstrap on the Pioneer is in flight.
PR rtl-optimization/121787
gcc/
* config/riscv/riscv-vsetvl.cc (pre_vsetvl): Adjust call to
loop_optimizer_init to avoid making CFG changes.
gcc/testsuite/
* gcc.target/riscv/pr121787-1.c: New test.
* gcc.target/riscv/pr121787-2.c: New test.
Joseph Myers [Mon, 19 Jan 2026 21:16:46 +0000 (21:16 +0000)]
testsuite: Do not restrict five tests to { target native }
Five miscellaneous tests use { target native }, while not doing
anything that actually needs some kind of special handling for cross
testing. Remove the { target native } restriction from those tests.
Tested for x86_64-pc-linux-gnu, and with cross to aarch64-linux.
* g++.old-deja/g++.mike/eh30.C, g++.old-deja/g++.mike/p4750.C,
g++.old-deja/g++.robertl/eb106.C, g++.old-deja/g++.robertl/eb83.C,
gcc.dg/20020201-1.c: Do not use { target native }.
Rainer Orth [Mon, 19 Jan 2026 20:51:28 +0000 (21:51 +0100)]
Silently ignore -pthread etc. on Solaris
gcc supports -pthread/-pthreads on Solaris to provide a way to
transparently handle the platform-specific needs of multitheaded
programs. In the past, this used to link with -lpthread. However, this
has been removed in
config: -pthread shouldn't link with -lpthread on Solaris
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615080.html
since libpthread had been folded into libc.
The only thing these options do now is to define _REENTRANT and
_PTHREADS. In Solaris 11.4, the system headers no longer reference the
former. Checking gnulib as an important source of portability
information, I find that _REENTRANT is used for two purposes:
* Ensure that strerror_r, localtime_r and gmtime_r are declared.
However, these declarations are no longer guarded by _REENTRANT, so
this is moot.
* Besides, _REENTRANT is defined on Solaris in general, but this has no
longer any effect.
There's no reference _PTHREADS at all, so this seems to be an ancient
relic no longer needed at all.
This patch silently ignores both options, keeping them for portability's
sake.
Bootstrapped without regressions on i386-pc-solaris2.11 and
sparc-sun-solaris2.11.
Georg-Johann Lay [Mon, 19 Jan 2026 17:33:30 +0000 (18:33 +0100)]
testsuite/123175 - Use int32_t instead of int in vec-type construction.
gcc/testsuite/
PR testsuite/123175
* gcc.dg/torture/pr123175-1.c: Use int32_t instead of int in
vec-type construction.
* gcc.dg/torture/pr123175-2.c: Same.
If we're extracting an element out of a uniform vector, then any element
will do and it's conveniently returned by uniform_vector_p. So with a
simple match.pd pattern that simplifies to _26 = 0. That in turn allows
elimination of all the vector code and simplify the return value to a
constant as well, resulting in the desired code shown earlier.
One could easily argue that this need not be restricted to a uniform
vector and I would totally agree. But given we're in stage4, the
minimal fix for the regression seems more appropriate. But I could
certainly be convinced to handle the more general case here.
Bootstrapped and regression tested on x86 & riscv64. Tested across the
cross configurations as well with no regressions.
PR target/113666
gcc/
* fold-const-call.cc (fold_const_vec_extract): New function.
(fold_const_call, case CFN_VEC_EXTRACT): Call it.
* match.pd (IFN_VEC_EXTRACT): Handle extraction from a uniform
vector.
gcc/testsuite
* gcc.target/riscv/rvv/base/pr113666.c: New test.
Co-authored-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Richard Biener [Wed, 7 Jan 2026 09:23:22 +0000 (10:23 +0100)]
tree-optimization/123061 - invalid hoisting of division
The following fixes the computation of always-exeecuted-in in the LIM
pass which was enhanced to handle inner loops in a better way but
in this process ended up setting inner loop always-executed-in state
based on outer loop analysis, which is wrong because an inner loop
block needs to be proven to be always executed for all inner loop
iterations as well, not only for all outer loop iterations.
The fix is to iterate over inner loops first and when processing
an outer loop only update always-executedness if a block belongs
to the very same loop or an immediately nested loop and always
executed inside that.
PR tree-optimization/123061
PR tree-optimization/123636
* tree-ssa-loop-im.cc (fill_always_executed_in_1): Change
outer-to-inner to inner-to-outer iteration. Update inner
loop state only when always executed in an immediately
nested loop.
* gcc.dg/torture/pr123061.c: New testcase.
* gcc.dg/torture/pr123636.c: Likewise.
* gcc.dg/tree-ssa/ssa-lim-26.c: Likewise.
Tomasz Kamiński [Fri, 16 Jan 2026 13:01:53 +0000 (14:01 +0100)]
libstdc++: Use overload operator<=> when provided in relational functors [PR114153]
The implementation of less<> did not consider the possibility of t < u being
rewritten from overloaded operator<=>. This lead to situation when for t,u that:
* provide overload operator<=>, such that (t < u) is rewritten to (t <=> u) < 0,
* are convertible to pointers,
the expression std::less<>(t, u) would incorrectly result in call of
std::less<void*> on values converted to the pointers, instead of t < u.
The similar issues also occurred for greater<>, less_equal<>, greater_equal<>,
their range equivalents, and in three_way_compare for heterogeneous calls.
This patch addresses above, by also checking for free-functions and member
overloads of operator<=>, before falling back to pointer comparison. We do
not put any constraints on the return type of selected operator, in particular
in being one of the standard defined comparison categories, as the language
does not put any restriction of returned type, and if (t <=> u) is well
formed, (t op u) is interpreted as (t <=> u) op 0. If that later expression
is ill-formed, the expression using op also is (see included tests).
The relational operator rewrites try both order of arguments, t < u,
can be rewritten into operator<=>(t, u) < 0 or 0 < operator<=>(u, t), it
means that we need to test both operator<=>(T, U) and operator<=>(U, T)
if T and U are not the same types. This is now extracted into
__not_overloaded_spaceship helper concept, placed in <concepts>, to
avoid extending set of includes.
The compare_three_way functor defined in compare, already considers overloaded
operator<=>, however it does not consider reversed candidates, leading
to situation in which t <=> u results in 0 <=> operator<=>(u, t), while
compare_three_way{}(t, u) uses pointer comparison. This is also addressed by
using __not_overloaded_spaceship, that check both order of arguments.
Finally, as operator<=> is introduced in C++20, for std::less(_equal)?<>,
std::greater(_equal)?<>, we use provide separate __ptr_cmp implementation
in that mode, that relies on use of requires expression. We use a nested
requires clause to guarantee short-circuiting of their evaluation.
The operator() of aforementioned functors is reworked to use if constexpr,
in all standard modes (as we allow is as extension), eliminating the need
for _S_cmp function.
PR libstdc++/114153
libstdc++-v3/ChangeLog:
* include/bits/ranges_cmp.h (__detail::__less_builtin_ptr_cmp):
Add __not_overloaded_spaceship spaceship check.
* include/bits/stl_function.h (greater<void>::operator())
(less<void>::operator(), greater_equal<void>::operator())
(less_equal<void>::operator()): Implement using if constexpr.
(greater<void>::__S_cmp, less<void>::__S_cmp)
(greater_equal<void>::__ptr_comp, less_equal<void>::S_cmp):
Remove.
(greater<void>::__ptr_cmp, less<void>::__ptr_cmp)
(greater_equal<void>::__ptr_comp, less_equal<void>::ptr_cmp): Change
tostatic constexpr variable. Define in terms of requires expressions
and __not_overloaded_spaceship check.
* include/std/concepts: (__detail::__not_overloaded_spaceship):
Define.
* libsupc++/compare: (__detail::__3way_builtin_ptr_cmp): Use
__not_overloaded_spaceship concept.
* testsuite/20_util/function_objects/comparisons_pointer_spaceship.cc: New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
The following fixes an omission in find_or_generate_expression to
check for SSA_NAME_OCCURS_IN_ABNORMAL_PHI as already done in
create_expression_by_pieces.
PR tree-optimization/123602
* tree-ssa-pre.cc (find_or_generate_expression): Do not
generate references to abnormal SSA names.
Tomasz Kamiński [Mon, 19 Jan 2026 09:03:08 +0000 (10:03 +0100)]
libstdc++: Fix std::erase_if for std::string with -D_GLIBCXX_USE_CXX11_ABI=0.
The __cow_string used with -D_GLIBCXX_USE_CXX11_ABI=0, does not provide
erase accepting const_iterator, so we adjust __detail::__erase.if
(introduced in r16-6889-g3287) to call __cont.erase with mutable iterators.
libstdc++-v3/ChangeLog:
* include/bits/erase_if.h (__detail::__erase_if): Pass mutable
iterators to __cont.erase.
Support for -m31 is deprecated and will be removed in a future release.
In order to let users know, emit an error/warning during configure. An
error is thrown if --enable-multilib is given implicitly, or if
explicitly but not --enable-obsolete.
Jakub Jelinek [Mon, 19 Jan 2026 08:46:36 +0000 (09:46 +0100)]
vect-generic: Fix up expand_vector_mult [PR123656]
The alg_sub_factor handling in expand_vector_mult had the arguments
reversed.
As documented in expmed.h, the algorithms should be
These are the operations:
alg_zero total := 0;
alg_m total := multiplicand;
alg_shift total := total * coeff
alg_add_t_m2 total := total + multiplicand * coeff;
alg_sub_t_m2 total := total - multiplicand * coeff;
alg_add_factor total := total * coeff + total;
alg_sub_factor total := total * coeff - total;
alg_add_t2_m total := total * coeff + multiplicand;
alg_sub_t2_m total := total * coeff - multiplicand;
The first operand must be either alg_zero or alg_m. */
So, alg_sub_factor should be identical to alg_sub_t2_m with the
difference that one subtracts accumulator and the other subtracts
op0. I went through all the other ones and they seem to match
the description except for alg_sub_factor and tree-vect-patterns.cc
seems to be fully correct. expand_vector_mult at times has
pretty random order of PLUS_EXPR arguments, but that is a commutative
operation, so makes no difference.
Furthermore, I saw weird formatting in the alg_add_t_m2 case, so fixed
that too.
2026-01-19 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/123656
* tree-vect-generic.cc (expand_vector_mult): Fix up alg_sub_factor
handling. Fix up formatting in alg_add_t_m2 handling.
projects / thirdparty / gcc.git / log
