Patrick Palka [Thu, 12 Feb 2026 02:35:21 +0000 (21:35 -0500)]
libstdc++: Clear padding bits in std::atomic ctor in C++11 [PR114865]
After the front end change r16-7199 both GCC and Clang allow non-empty
constexpr constructor bodies in C++11 as an extension, so we can now
unconditionally enable the __builtin_clear_padding logic in std::atomic's
constructor.
PR libstdc++/114865
libstdc++-v3/ChangeLog:
* include/std/atomic (atomic<_Tp>::atomic(_Tp)) [C++11]:
Enable __builtin_clear_padding logic.
* testsuite/29_atomics/atomic/compare_exchange_padding.cc: Enable
this test in earlier modes, including C++11.
* testsuite/29_atomics/atomic/cons/zero_padding.cc [C++11]:
Enable tests verifying cleared padding bits for a non-static-init
std::atomic object.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
David Malcolm [Thu, 12 Feb 2026 01:49:44 +0000 (20:49 -0500)]
analyzer: fix false +ve buffer overflow on sprintf [PR117369]
gcc/analyzer/ChangeLog:
PR analyzer/117369
* kf.cc (kf_sprintf::impl_call_pre): Use the capacity of the
region when "faking" a write to the destination buffer, to
avoid buffer overflow false +ves.
gcc/testsuite/ChangeLog:
PR analyzer/117369
* c-c++-common/analyzer/sprintf-pr117369.c: New test.
* gcc.dg/analyzer/doom-d_main-IdentifyVersion.c: Update expected
results to reflect complexity limits being hit earlier.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Thu, 12 Feb 2026 01:49:43 +0000 (20:49 -0500)]
analyzer: fix ICE in push_frame with missing return statement [PR124073]
gcc/analyzer/ChangeLog:
PR analyzer/124073
* region-model.cc (region_model::push_frame): Bulletproof against
DECL_RESULT having null SSA on function missing a return
statement (-Wreturn-type).
gcc/testsuite/ChangeLog:
PR analyzer/124073
* g++.dg/analyzer/ice-pr124073.C: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Joseph Myers [Wed, 11 Feb 2026 23:53:41 +0000 (23:53 +0000)]
testsuite: Use color=never for more sanitizer tests
The sanitizer tests have logic to set ASAN_OPTIONS and UBSAN_OPTIONS
to color=never to avoid problems checking against output patterns, in
test configurations where the output is otherwise coloured by default.
This does not however cover all sanitizer tests with issues in such
configurations. There is no corresponding logic to set TSAN_OPTIONS
for tsan tests, and environment variable settings in
dg-set-target-env-var override the globally set color=never.
Add logic to set TSAN_OPTIONS similarly (following the UBSAN_OPTIONS
logic, that saves and restores any previous setting or lack thereof,
rather than the ASAN_OPTIONS logic, that just sets ASAN_OPTIONS in the
environment so that it remains set for all the rest of the possibly
unrelated tests included in the same runtest execution). Also add
color=never to dg-set-target-env-var in two such tests where I've seen
coloured output causing failures (but not for other tests where I
haven't seen the default producing such fallures).
Tested for x86_64-pc-linux-gnu, and with a cross to aarch64-linux
(together with other testsuite fixes) in a configuration where I
previously saw failures related to colour output from sanitizer tests.
* lib/tsan-dg.exp (orig_tsan_options_saved, orig_tsan_options):
New global variables.
(tsan_init): Save TSAN_OPTIONS and set it to color=never.
(tsan_finish): Restore TSAN_OPTIONS.
* c-c++-common/asan/pr64820.c: Include color=never in
ASAN_OPTIONS.
* c-c++-common/asan/use-after-return-1.c: Likewise.
[PR121191, LRA]: Check int modes to generate the right subreg offset when matching reload regs of different modes
In the PR test case (gcc.c-torture/compile/pr35318.c), LRA chose to
match operands in DFmode and SImode modes. On big endian targets,
this resulted in wrong subreg offset generation and wrong insn
generation. The offset would be right if the both operands were
scalar integers (see call of reload.cc:operands_match_p in
recog.cc:constrain_operands). The patch solves the problem.
gcc/ChangeLog:
PR rtl-optimization/121191
* lra-constraints.cc (get_matching_reload_reg_subreg): New.
(get_reload_reg, match_reload): Use it.
Tomasz Kamiński [Mon, 2 Feb 2026 09:19:51 +0000 (10:19 +0100)]
libstdc++: Make function_ref non-dangling for stateless wrappers
This patch makes the function_ref non-dangling for the stateless
wrappers:
* any functor for which operator() selected for arguments is static,
* standard functors, including pre-C++20 ones.
In other words, any function_ref fr, that is constructed from stateless
wrapper w, can be still called after the object w is destroyed, e.g.:
std::function_ref<bool(int, int)> fr(std::ranges::less{});
fr(1, 2); // OK, previously UB because fr referred to already destroyed
// temporary
As function_ref's operator() is not constexpr, we test the change by checking
if the above declaration can be made constexpr, as such variable cannot contain
dangling pointer values.
We adjust the function_ref generic constructor from any functor, to use more
specialized invoker:
* _S_static (newly added) if the called operator() overload is static,
after changes r16-5624-g0ea9d760fbf44c, this covers all post-c++20 functors;
* _S_nttp<_Fd{}> for pre-C++20 standard functors.
In both above cases the value of _M_ptrs is ignored and simply set to nullptr.
This follows same technique (checking _Fd::operator()(args...)), and support
the same set of types, as for one used for the transform views iterators in r16-5625-g9ed821d107f7a1.
As after this change we provide well-defined behavior for the code, that
previous was undefined, this changes is pure quality-of-implementation.
As illustrated by the test cases, it has observable side effects, where
non-longer dangling constructs can be used to define constexpr function_ref.
However, the standard does not define when the constructors defined constexpr
are actually usable at compile time, and the already have precedent in form
of SSO string for validity such constructs being implementation specific.
libstdc++-v3/ChangeLog:
* include/bits/funcref_impl.h (function_ref::function_ref(_Fn&&)):
Use _S_static and _S_nttp invokers.
* include/bits/funcwrap.h (_Base_invoker::_S_static):
Define.
* include/bits/stl_function.h (std::__is_std_op_template)
(std::__is_std_op_wrapper) [__cplusplus > 201703L]:
Moved from std/ranges.
* include/std/ranges (__detail::__is_std_op_template)
(__detail::__is_std_op_wrapper): Moved to bits/stl_function.h.
* testsuite/20_util/function_ref/dangling.cc: New test.
* testsuite/20_util/function_ref/dangling_neg.cc: New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Chris Bazley [Wed, 11 Feb 2026 15:53:22 +0000 (15:53 +0000)]
AArch64: Add tests to ensure rev is produced
If the compiler mistakenly vectorizes byte order reversal
then the resultant code is inevitably less efficient than a
rev instruction. This kind of error will become more likely if
SVE predication is ever used to vectorize smaller groups
than could be vectorized using ASIMD instructions. Add tests to
guard against future regressions.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/rev_32_1.c: New test.
* gcc.target/aarch64/rev_32_2.c: New test.
* gcc.target/aarch64/rev_32_3.c: New test
David Malcolm [Wed, 11 Feb 2026 13:51:16 +0000 (08:51 -0500)]
analyzer: fix uninit in null-termination checking [PR124055]
gcc/analyzer/ChangeLog:
PR analyzer/124055
* kf.cc (kf_strcpy::impl_call_pre): Ensure bytes_to_copy is
initialized. Assert that it was written to with non-null if
check_for_null_terminated_string_arg returns non-null.
* region-model.cc (region_model::scan_for_null_terminator):
Initialize *out_sval, and assert it is written to when
returning non-null.
(region_model::check_for_null_terminated_string_arg): Assert
that scan_for_null_terminator wrote to *out_sval if it
returns non-null.
gcc/testsuite/ChangeLog:
PR analyzer/124055
* gcc.dg/analyzer/ice-pr124055-1.c: New test.
* gcc.dg/analyzer/ice-pr124055-2.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Richard Biener [Wed, 11 Feb 2026 08:50:55 +0000 (09:50 +0100)]
Use dg-additional-options in vect.exp, simplify file globbing
This makes use of dg-additional-options for the remainder of tests
that were still getting those by filename based rules. This moves
all those under the vect option iteration and slightly simplifies
globbing by moving some files. I've kept the the veclower test glob.
IMO remaining simplification either needs mass renaming of files or/and moving
them into subdirectories. Possibly some regex or TCL expert can
figure out how to filter bb-slp-*.c and vec-scal-*.c from everything
else that's now catched by 17 inclusive regexp.
Tamar Christina [Wed, 11 Feb 2026 11:36:50 +0000 (11:36 +0000)]
middle-end: partially revert fix for PR123898 after fix for PR123940 [PR124038]
There were two mutually incompatible changes reviewed and
merged around the same time for different issues in
convert_mult_to_fma.
the change in r16-7353 keeps result in it's unpromoted form
and deals with it as such but the change in r16-7304 expects
it to be in it's promoted form.
This causes the assert to fail again and the SVE testcase I
added before to fail.
Since the value is now kept in it's unpromoted form, and result
is not used as any LHS side, I've partially reverted the
convert stripping to make use of it.
Eric Botcazou [Wed, 11 Feb 2026 10:38:24 +0000 (11:38 +0100)]
Ada: Fix internal error on access attribute used as subpool in allocator
This is a regression present for quite a long time: the compiler aborts
on an allocator whose subpool name is an access attribute and when an
allocation procedure must be generated, for example when the allocation
is controlled.
The fix is to do what is done elsewhere in Build_Allocate_Deallocate_Proc,
that is to say pass the allocation procedure as the new scope in the call
to the New_Copy_Tree function.
gcc/ada/
PR ada/124054
* exp_util.adb (Build_Allocate_Deallocate_Proc): Tidy up and pass
Proc_Id as the new scope in the call to the New_Copy_Tree function.
gcc/testsuite/
* gnat.dg/allocator4.adb: New test.
Optimize regex_traits::lookup_collatename and
regex_traits::lookup_classname.
For lookup_collatename we can hoist the static array into a
non-dependent function, then call that for the regex_traits<char>
specialization without performing any narrowing operations via the ctype
facet. For the regex_traits<wchar_t> specialization we populate a
std::string for the narrowed result, and call the non-dependent function.
For lookup_classname we can avoid the static array entirely, replacing
the iteration over that array with a nested switch that implements a
kind of manually-unrolled trie, only match one char at a time until we
either match a full string or get a mismatch. This avoids narrowing the
entire input and storing it in a temporary string. This improves
performance by 2-3x for -O2 and below (the benefit is much smaller for
-O3).
We can also check the input length for random access iterators, and
reject any strings longer than "xdigit" without doing any work at all.
For silly cases like [:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:]
this gives a 100x improvement.
libstdc++-v3/ChangeLog:
* include/bits/regex.tcc (__detail::__lookup_collatename): New
function.
(regex_traits::lookup_collatename): Use new function. Elide
redundant narrowing via ctype facet for regex_traits<char>.
(regex_traits::lookup_classname): Replace lookup table with
handwritten prefix match.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
This fixes a bug in regex_traits::lookup_classname(f, l, true) where the
result was always ctype_base::alpha for any input sequence [f, l) that
has the ctype_base::lower or ctype_base::upper bits set. For targets
that define alpha as lower|upper (rather than having a distinct bit for
alpha) this bug meant that all masks which have lower or upper bits set
were replaced with alpha when the icase parameter is true. This has the
effect that trying to do a case insensitive match for [:alnum:],
[:graph:], or [:print:] was equivalent to matching [:alpha:] instead,
which is obviously not correct.
Based on inspection of the ctype_base.h files under the config/os
directory, the bug appears to affect newlib, picolibc, qnx and vxworks.
libstdc++-v3/ChangeLog:
PR libstdc++/124015
* include/bits/regex.tcc (regex_traits::lookup_classname): Fix
handling of icase parameter.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jonathan Wakely [Tue, 10 Feb 2026 20:01:32 +0000 (20:01 +0000)]
libstdc++: Improve tests for std::regex_traits::lookup_classname [PR124015]
libstdc++-v3/ChangeLog:
PR libstdc++/124015
* testsuite/28_regex/traits/char/lookup_classname.cc: Check for
correct result for unrecognized classname. Check that lookup is
case insensitive. Check that all required classnames are
recognized. Check that icase flag only affects "lower" and
"upper".
* testsuite/28_regex/traits/wchar_t/lookup_classname.cc:
Likewise.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jakub Jelinek [Wed, 11 Feb 2026 10:34:09 +0000 (11:34 +0100)]
cfgexpand: Fix up "=@ccz" etc. outputs on asm goto [PR124056]
The following testcase is miscompiled, because after_md_seq which is
what is emitted for "=@cc?" outputs to initialize a pseudo with
the result is emitted just once, on the asm goto fallthru edge, before
after_rtl_seq (on that edge that is the correct ordering), but a copy
of after_rtl_seq is also emitted on the other edges from asm goto, but
after_md_seq is not.
So, the pseudo with the flags checking is initialized only in the
fallthru case and not when asm goto is left through one of the other
labels (unless those are degenerate).
The following patch arranges to emit that sequence duplicated on all the
edges before after_rtl_seq sequence, by modifying after_rtl_seq so that
it includes after_md_seq followed by the old after_rtl_seq.
2026-02-11 Jakub Jelinek <jakub@redhat.com>
PR middle-end/124056
* cfgexpand.cc (expand_asm_stmt): If after_md_seq is non-NULL, emit
it at the start of after_rtl_seq instead of after fallthru_label.
Jakub Jelinek [Wed, 11 Feb 2026 10:31:26 +0000 (11:31 +0100)]
cfgrtl: Fix up force_nonfallthru_and_redirect asm goto handling [PR123386]
force_nonfallthru_and_redirect has some extra code to handle asm gotos
if we are forcing or redirecting the EDGE_FALLTHRU in case. This was
done for PR51767, PR53589, PR54127.
It is done for the cases where some asm goto label points to the bb
after the fallthru edge (i.e. there is edge sharing between the fallthru
and the label, partly or fully degenerate asm goto) and/or if the label
points to the TARGET bb (before/after).
In such case it changes the label from e->dest's label to target's label
and similarly to the case of 2+ successor e->src a new bb is created
as new fallthru from e->src and in the asm goto case an additional edge
is added, so there is
|
asm goto -----+ maybe other edges
| fallthru \
v v
jumpblock -> target
and the jumpblock -> target edge isn't EDGE_FALLTHRU.
This was done that way to fix various ICEs with the degenerate asm gotos,
see above for list.
I believe it will still ICE if we decide to force_nonfallthru_and_redirect
E bb5->bb6 to l2, because in that case there are already two+ edges, one
pointing from bb5->l2 and we create another edge bb5->l2:
bb5:
asm goto ("" : : : : (l2));
bb6:
...
l2:
but maybe nothing tries that in that case. Anyway, the reason why
the following two (PR116600 and PR123386) testcases are miscompiled is
that we try to (during shrink-wrapping) emit some insns on the bb3->bb7
edge, and see bb7 predecessor edge is EDGE_FALLTHRU in:
bb3:
__asm__ goto ("" : : : : d);
if (c)
bar (a);
bb6:
__asm__ goto ("" : : : : d);
d: // == bb7
in rtl_split_edge:
/* We are going to place the new block in front of edge destination.
Avoid existence of fallthru predecessors. */
if ((edge_in->flags & EDGE_FALLTHRU) == 0)
{
edge e = find_fallthru_edge (edge_in->dest->preds);
if (e)
force_nonfallthru (e);
}
Now, the asm goto in bb6 is degenerate, so shrink-wrapping isn't aware
that there would be multiple edges from it, there is just single one.
But we still while splitting the bb3->bb7 edge in order to emit there
pending insns on that edge turn the single successor asm goto bb into
one with two successors (initially with two different ways to reach
the same destination). But unfortunately such change confuses the
shrink-wrapping logic which isn't aware of such a change and so the
separate shrink wrapping insns end up just on one of the paths instead
of being on both, and we then ICE in dwarf2 pass because there is an
disagreement on the CFI state (of course it is a wrong-code too).
Note, force_nonfallthru calls force_nonfallthru_and_redirect with
target set to e->dest.
The following patch reworks this.
Instead of creating that
|
asm goto -----+ maybe other edges
| fallthru \
v v
jumpblock -> target
for initially degenerate asm goto we now create
|
asm goto maybe other edges
| fallthru
v
jumpblock -> target
i.e. the asm goto keeps being degenerate, all we've changed is adding
a new bb on the fallthru edge and making the edge from that new bb
non-fallthru. Furthermore, for the case where there would be before
an asm goto -> target edge before for the e->dest != target case,
those edges are untouched.
For the immediate effect after the operation, the asm goto keeps
the existing behavior, if it falls through, it will reach target
by hopping through jumpblock, if it jumps to that label, previously
it jumped directly to target, now it jumps to jumpblock and from there
to target. But shrink-wrapping etc. then put the right fixups everywhere
where it belongs.
2026-02-11 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/116600
PR middle-end/123386
* cfgrtl.cc (force_nonfallthru_and_redirect): Don't do any
asm goto adjustments early, only note in asm_goto_edge if
any labels point originally to e->dest head. After jumpblock
creation don't add an extra edge for asm_goto_edge, instead
adjust those labels pointing to former e->dest head to point
to jumpblock instead.
* gcc.c-torture/compile/pr116600.c: New test.
* gcc.c-torture/compile/pr123386.c: New test.
The glob in g++.dg/vect/vect.exp was not catching the file and
the special option that was intended to be used no longer exists.
I've simplified the situation by renaming the test and fixing it
for the obvious out-of-bound access that is diagnosed. The test
likely doesn't test anything anymore, but probably better than
simply removing it.
* g++.dg/vect/vect.exp: Remove param-max-aliased-* handling.
* g++.dg/vect/param-max-aliased-pr26197.cc: Rename to ...
* g++.dg/vect/pr26197.cc: ... this and fixup array overflow.
Boris Staletic [Wed, 11 Feb 2026 07:20:49 +0000 (16:20 +0900)]
c++/reflection: Allow address-splicing of non-static members [PR123660, PR123661]
In case of expressions like `&[:expr:]` where `expr` depends on a
template parameter, and the splice expression represents a `FIELD_DECL` or
a non-static member `FUNCTION_DECL`, that's exactly what we'd pass on.
However, `build_x_unary_op()` for these expressions is expecting an
`OFFSET_REF`. `OFFSET_REF` is also what gets passed to
`build_x_unary_op()` when templates are not involved.
There's also a difference between the template argument being a type and
using `members_of()` to get to the reflections of members (in which case
evaluating the `SPLICE_EXPR` returns a `FUNCTION_DECL` - `splice10.C`
test) and passing `^^T::member` as the template argument (in which case
evaluating the `SPLICE_EXPR` returns a `BASELINK` - `splice11.C`).
Signed-off-by: Boris Staletic <boris.staletic@protonmail.com>
PR c++/123660
PR c++/123661
gcc/cp/ChangeLog:
* pt.cc (tsubst_splice_expr): Handle pointers to non-static members
from splice expressions
gcc/testsuite/ChangeLog:
* g++.dg/reflect/splice10.C: New test.
* g++.dg/reflect/splice11.C: New test.
Alexandre Oliva [Wed, 11 Feb 2026 00:36:48 +0000 (21:36 -0300)]
testsuite: i386: require glibc for C99 libm in vectorize-aocl1.c
x86_64-elf fails gcc.target/i386/vectorize-aocl1.c because various
functions aren't recognized as builtins because the target isn't
assumed to offer C99 math library functions, and then the expected
transformations don't occur when calling them.
It would presumably be possible to adjust the test so that it passes
under such conditions, but I'm not undertaking that. Requiring glibc
isn't quite ideal, but it's probably good enough, even though the test
makes some effort to compile with other libraries.
Alexandre Oliva [Wed, 11 Feb 2026 00:36:37 +0000 (21:36 -0300)]
testsuite: i386: vect-pr114375 vectorizes only with avx2 runtime
This test compiles with -mavx2 only if avx2_runtime passes, and
without that option, it is not expected to vectorize. Adjust the
effective target requirement for the dump pattern to match that of the
option.
for gcc/testsuite/ChangeLog
PR tree-optimization/114375
* gcc.dg/vect/vect-pr114375.c: Adjust dump pattern requirement
to match that of options.
Dimitry Andric [Tue, 10 Feb 2026 18:51:58 +0000 (19:51 +0100)]
build: Correctly restore CXXFLAGS/LDFLAGS for zstd test
Commit r16-5592-g56889bfec25 added saving and restoring of CXXFLAGS and
LDFLAGS in the gcc configure script, to avoid including the wrong zstd
headers.
However, due to misleading indentation in the configure script, the
restoration of CXXFLAGS and LDFLAGS was put after the if block where the
values were saved. This could cause various interesting effects, among
others segfaults while building gcc in the FreeBSD ports system.
Move the restoration of CXXFLAGS and LDFLAGS to just before the end of
the same if block to fix this.
Thanks to Mark Millard for spotting the actual mistake.
2026-02-10 Dimitry Andric <dimitry@andric.com>
gcc:
PR libfortran/123366
* configure.ac: Move restoring of CXXFLAGS/LDFLAGS for zstd test to
the correct place.
* configure: Regenerate.
Alice Carlotti [Wed, 14 Jan 2026 13:48:35 +0000 (13:48 +0000)]
aarch64: Disable shrink-wrap for locally-streaming functions [PR 123624]
The meaning of poly_int values changes depending on whether we are in
streaming or non-streaming mode, but this dependency is not explicitly
tracked. Locally-streaming functions can change streaming state in the
prologue and epilogue, so it is unsafe to apply shrink wrapping to these
functions, as doing so could change the mode seen by instructions like
cntd.
Alice Carlotti [Wed, 7 Jan 2026 19:47:45 +0000 (19:47 +0000)]
aarch64: Improve --with-arch checks
- Check for invalid characters before further processing. Allow only
alphanumeric characters, "-", "+" and ".".
- Convert "." to "\." before using user input in a sed expression.
- Reject zero-length extension names.
- Quote variables used in echo commands, to avoid unwanted shell
expansions.
Without these changes, various invalid inputs would be accepted, for
example due to misparsing of "*" and "." characters in regexps and
shell expansions. Some inputs could also lead to an infinite loop.
Marek Polacek [Mon, 9 Feb 2026 18:54:39 +0000 (13:54 -0500)]
c++: fix for saved_token_sentinel
In cp_parser_splice_spec_is_nns_p I didn't use saved_token_sentinel:
its rollback uses cp_lexer_previous_token so if we are the first token
in the file, there are no previous tokens so we crash.
It would be simple to just use the _safe variant of cp_lexer_previous_token
and be done with this. But that's not how this worked out: I saw a new
-fcompare-debug FAIL with pr104025.C. The problem is that at the end of
cp_parser_id_expression we have a saved_token_sentinel guarded by
warn_missing_template_keyword and in that spot lexer->buffer is NULL (so
cp_lexer_set_source_position_from_token would be skipped). pr104025.C
is compiled twice, the second time with "-w -fcompare-debug-second". So
the first time we don't _set_source_position back to where we were after the
_skip_entire_template_parameter_list (lexer->buffer is NULL) and the second
time we don't get to the saved_token_sentinel at all. That left us with
different columns in the location:
"pr104025.C":16:16 vs "pr104025.C":16:12
thus the -fcompare-debug FAIL. I assume we don't want -fcompare-debug
to ignore the column location. So we could just save input_location in
saved_token_sentinel instead of trying to recover it. And then
cp_parser_splice_spec_is_nns_p can be simplified.
gcc/cp/ChangeLog:
* parser.cc (struct saved_token_sentinel): Save input_location.
(saved_token_sentinel::rollback): Restore input_location.
(cp_parser_splice_spec_is_nns_p): Use saved_token_sentinel. Refactor.
When load/store with length is used and only QImode versions are
available, vectorizable_live_operation produces wrong results for
VEC_EXTRACT. Provide a flag to vect_get_loop_len to specify if
bias-adjusted length should be used or not.
Tomasz Kamiński [Thu, 29 Jan 2026 17:14:47 +0000 (18:14 +0100)]
libstdc++: Allow constant initialization of std::atomic of types with padding [PR123875]
Currently for the types T that contains padding bits, std::atomic<T>(T)
constructor was not usable at compile-time in C++14 or later modes. This
regression caused by use of __builtin_clear_padding introduced in r13-2548-g157236dbd62164.
This leads to two regressions when switching from C++11 to C++14
standard (or switching from GCC-12 to later version for C++14 standard),
where for type X that contains padding
* constexpr std::atomic<X> cx(X(...)) becomes ill-formed,
* std::atomic<X> gx(X(...)) with static storage duration, switch from
static to dynamic initialization.
The latter breakage is silent and may introduced very hard to localize
order of initialization issues.
This patch mitigates above issue by not invoking the __builtin_clear_padding,
during constant initialization (std::__is_constant_evaluated() is false).
This is considered to be safe, as:
* for objects with static storage duration, padding bits are already
cleared by zero-initialization
* for constexpr objects with non-static storage duration, there is no
API that would allow user to observe padding bits on const atomic objects
To elaborate on the second point, values of padding bits in atomic can
be observed by:
* The compare_exchange_weak/compare_exchange_strong operations are mutating,
so cannot be invoked on const objects.
* As atomic<X> is not required to store actual object of type X,
observing its object representation does (via bitcast, memcpy), does
not provide values of object representation of X. Furthermore, the
operations are defined only for trivially_copyable types, and atomic
specializations meets above requirement only due to bug in libstdc++
(see PR67572).
Note that above will no longer hold, and the solution will need to be
revisited during implementation of C++26 paper P3309R3: constexpr
atomic and atomic_ref (it will be possible to call compare_exchange
during constant evaluation).
PR libstdc++/123875
libstdc++-v3/ChangeLog:
* include/bits/atomic_base.h (__atomic_impl::__clear_padding):
Use if constexpr unconditionally.
(__atomic_float<_Fp>::__atomic_float(_Fp)): Skip __clear_padding
call for constant evaluation.
* include/std/atomic (atomic<_Tp>::atomic(_Tp)): Likewise.
* testsuite/29_atomics/atomic/cons/static_zero_padding.cc: New test.
Reviewed-by: Patrick Palka <ppalka@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Kyrylo Tkachov [Fri, 6 Feb 2026 10:34:29 +0000 (02:34 -0800)]
aarch64: Adjust SVE vector costs for NVIDIA Olympus
After some more analysis, I'd like to adjust the SVE load
cost for NVIDIA Olympus to more accurately reflect the core SWOG.
This leads to more sensible Advanced SIMD vs SVE autovec decisions.
Bootstrapped and tested on aarch64-none-linux-gnu.
The following adds a heuristic to ifcombine that avoids turning
analyzable loop exits into unanalyzable ones. This allows vectorizing
the testcase in the PR again. I've refrained from actually
analyzing niters but instead used a cheaper heuristic. I believe
we'll only ever attempt to combine two ifs if they are in the same
loop and if either both exit the loop or stay within.
PR tree-optimization/107690
* tree-ssa-ifcombine.cc (ifcombine_ifandif): Do not merge
possibly analyzable exit conditions.
David Malcolm [Tue, 10 Feb 2026 04:14:22 +0000 (23:14 -0500)]
analyzer: fix assertion failure in bounded_ranges::cmp [PR113496]
gcc/analyzer/ChangeLog:
PR analyzer/113496
* constraint-manager.cc (cmp_types): New.
(bounded_range::cmp): Compare the types of the constants, as well
as their values.
gcc/testsuite/ChangeLog:
PR analyzer/113496
* gcc.dg/analyzer/ice-pr113496.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Patrick Palka [Tue, 10 Feb 2026 01:32:39 +0000 (20:32 -0500)]
c++: tf_partial and alias_ctad_tweaks [PR122621]
Like in r15-6740-g27d620d6769715 for instantiate_template with dependent
arguments, we also need to set tf_partial during the alias_ctad_tweaks
transformation mainly for benefit of properly handling extra-args trees.
In this testcase during alias_ctad_tweaks we substitute the dependent
ElemTs={Tuple<Us...>}, Ts={Ts...} into the requires-clause, which
tsubst_pack_expansion decides to defer via extra-args, and for the
subsequent add_extra_args (during guide overload resolution) to merge
the deferred dependent arguments correctly, tf_partial has to have been
set.
PR c++/122621
gcc/cp/ChangeLog:
* pt.cc (tsubst_pack_expansion): Use tf_partial instead of
tf_none, except when substituting outer (non-dependent) template
arguments.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/class-deduction-alias26.C: New test.
Patrick Palka [Tue, 10 Feb 2026 01:04:12 +0000 (20:04 -0500)]
libstdc++/regex: Remove now unused __dfs_mode template parameter
This mechanical patch removes _Executor's __dfs_mode template parameter.
In passing we can also get rid of the _V2 inline namespace because this
removal alone achieve the goal of the inline namespace which is to make
all of _Executor's member function signatures different from the
previous (GCC < 16) recursive implementation, allowing for safe mixing
of the two incompatible implementations.
Patrick Palka [Tue, 10 Feb 2026 01:04:00 +0000 (20:04 -0500)]
libstdc++/regex: Replace __dfs_mode template parameter with run-time flag
That _Executor's __dfs_mode flag is a template parameter means
__regex_algo_impl has to instantiate two different (but largely the
same) versions of _Executor even though the BFS version is rarely used.
And it seems the compiler has trouble DCEing the unused version of
_Executor, which needlessly increases code size and burdens the optimizer.
This patch replaces the template parameter with a run-time data member
_M_search_mode. We in turn need to inline the _Executor::_State_info
member functions and data members into _Executor so that they depend on
the run-time instead of compile-time flag. This means _Executor is
three pointers bigger in DFS mode (due to the unused _M_match_queue and
_M_visited_states members), which we can reduce to one pointer if we
really want to, but that doesn't seem ver worthwhile.
The __dfs_mode template parameter is now unused but not yet removed,
that'll be done in the next patch.
After this patch, both code size and run time for the microbenchmark
for (int i = 0; i < 10000; i++)
regex_match(string(200, 'a'), regex("(a|b|c)*"));
decreases by about 15% each (with -O2). Compile time/memory use decreases
by 5-10%.
libstdc++-v3/ChangeLog:
* include/bits/regex.tcc (__regex_algo_impl): Pass __use_dfs
parameter to _Executor's constructor.
* include/bits/regex_executor.h (_Executor::_Search_mode): New.
(_Executor::_Executor): Add __use_dfs parameter and initialize
_M_search_mode. Adjust after inlining _State_info members into
_Executor.
(_Executor::~_Executor): Free _M_visted_states.
(_Executor::_M_main): Adjust after renaming _M_main_dispatch
overloads to _M_main_dfs and _M_main_bfs.
(_Executor::_State_info): Remove.
(_Executor::_M_visited): Inlined from _State_info.
(_Executor::_M_get_sol_pos): Likewise.
(_Executor::_M_states): Remove.
(_Executor::_M_start): Inlined from _State_info.
(_Executor::_M_sol_pos): Likewise.
(_Executor::_M_match_queue): Likewise.
(_Executor::_M_search_mode): New.
* include/bits/regex_executor.tcc (_Executor::_M_main_dispatch):
Renamed to...
(_Executor::_M_main_dfs, _Executor::_M_main_bfs): ... these.
(_Executor::_M_*): Adjust after _M_states removal.
(_Executor::_M_lookhead): Also adjust _Executor constructor
call.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
David Malcolm [Mon, 9 Feb 2026 23:41:22 +0000 (18:41 -0500)]
sarif output: Fix ICE due to overzealous caching [PR124014]
PR diagnostics/124014 identifies an ICE in sarif output of
diagnostics that occur after free_lang_data has called
tree_diagnostics_defaults, which happens e.g. with lto.
The issue is that in r16-413-g8ab6899dce92e6 I introduced to sarif_sink
a cached pointer to the logical_locations::manager, which for tree-using
clients is part of the compiler_data_hooks. Hence for the case above, the
pointer is freed from under the sarif_sink, and any diagnostic
issued after that point with a current_function_decl will
trigger a use-after-free.
Fix by removing the cached pointer.
gcc/ChangeLog:
PR diagnostics/124014
* diagnostics/sarif-sink.cc
(sarif_builder::get_logical_location_manager): Reimplement, to
eliminate m_logical_loc_mgr.
(sarif_builder::m_logical_loc_mgr): Drop field.
(sarif_builder::sarif_builder): Update for removed field.
(sarif_builder::set_any_logical_locs_arr): Likewise.
(sarif_builder::ensure_sarif_logical_location_for): Likewise.
(sarif_builder::make_minimal_sarif_logical_location): Likewise.
gcc/testsuite/ChangeLog:
PR diagnostics/124014
* gcc.dg/sarif-output/ice-pr124014.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Signed-off-by: Jose E. Marchesi <jemarch@gnu.org>
gcc/algol68/ChangeLog
* a68-low-holes.cc (a68_wrap_formal_proc_hole): The wrapper is not
a top-level function.
* a68-low-units.cc (a68_lower_formal_hole): Reorder code and
remove spurious comment.
Jonathan Wakely [Mon, 9 Feb 2026 20:41:46 +0000 (20:41 +0000)]
libstdc++: Fix doxygen comment for std::out_ptr [PR124024]
libstdc++-v3/ChangeLog:
PR libstdc++/124024
* include/bits/out_ptr.h (out_ptr): Fix doxygen comment to refer
to the right function.
(inout_ptr): Improve markup in doxygen comment.
David Faust [Wed, 4 Feb 2026 20:13:45 +0000 (12:13 -0800)]
bpf: set SLOW_BYTE_ACCESS to 0 [PR123556]
In general, BPF programs are JIT-ed to various architectures, and we
cannot say for certain what memory access patterns are preferable.
But it is clear that for the sake of the BPF verifier smaller loads are
to be preferred when possible, so set SLOW_BYTE_ACCESS to zero.
Tested on x86_64-linux-gnu host for bpf-unknown-none, no regressions.
Also tested against Linux kernel bpf-next selftests, no changes.
PR target/123556
gcc/
* config/bpf/bpf.h (SLOW_BYTE_ACCESS): Set to 0, update comment.
gcc/testsuite/
* gcc.target/bpf/pr123556.c: New test.
Jakub Jelinek [Mon, 9 Feb 2026 16:54:10 +0000 (17:54 +0100)]
c++: Add self reference to define_aggregate created aggregates [PR123984]
We weren't adding the DECL_SELF_REFERENCE_P TYPE_DECL to TYPE_FIELDS of
eval_define_aggregate created aggregates, which resulted in ICE in
accessible_base_p which relies on DECL_SELF_REFERENCE_P TYPE_DECL to be
present in base classes of other classes.
2026-02-09 Jakub Jelinek <jakub@redhat.com>
PR c++/123984
* reflect.cc (eval_define_aggregate): Set TYPE_BEING_DEFINED on type
after pushclass, call build_self_reference, remove assertion that
TYPE_FIELDS (type) is NULL and instead set fields to
TYPE_FIELDS (type).
Pin those tests to z14. Strictly speaking those are mostly fine for
z13, too. However, vectors with 32-bit float elements are only natively
supported since z14.
gcc:
PR other/123841
PR target/123926
* acinclude.m4 (gcc_GAS_FLAGS): Handle non-Darwin/Solaris as cases
alike on x86 and SPARC.
* configure: Regenerate.
[PR123796, LRA]: Propagate pointer flag from the equivalence target
Some targets can use pointer (frame related) flag to generate the
correct code and improve the code. Substitution of equivalence in an
insn and reloading it resulted in loosing pointer flag of the original
equivalence target in the reload register. The patch solves this
problem by using set of equivalences whose original targets have the
pointer flags and propagating this flag to equivalence copies and
reload registers.
gcc/ChangeLog:
PR rtl-optimization/123796
* lra-int.h (lra_pointer_equiv_set_add): Add prototype.
(lra_pointer_equiv_set_in, lra_finish_equiv): Ditto.
* lra.cc (lra_emit_move): Set up pointer flag of the destination
if necessary.
(lra): Call lra_finish_equiv.
* lra-constraints.cc: Include hash-set.h.
(pointer_equiv_set, lra_pointer_equiv_set_add): New.
(lra_pointer_equiv_set_in, lra_finish_equiv): New.
(get_equiv_with_elimination): Propagate pointer flag by adding to
pointer_equiv_set.
(process_addr_reg, curr_insn_transform): Ditto.
Richard Biener [Fri, 6 Feb 2026 14:47:08 +0000 (15:47 +0100)]
tree-optimization/123225 - require iteration estimate for uncounted loops
The following makes uncounted loops not profitable to vectorize
unless there's an estimate on the number of iterations, either
from array sizes, overflow, or PGO, that indicates proftiability.
Or trivial profitability, but that's impossible to reach - Tamars
pending patch might change this in some cases.
I have verified that with PGO we do vectorize the testcase in the PR.
PR tree-optimization/123225
* tree-vect-loop.cc (vect_analyze_loop_costing): For uncounted
loops reject not trivially profitable loops that have no
estimate on the number of scalar iterations.
* gcc.dg/vect/costmodel/x86_64/costmodel-pr123225.c: New testcase.
Richard Biener [Mon, 9 Feb 2026 12:13:30 +0000 (13:13 +0100)]
Silence diagnostics on gcc.dg/torture/pr117567.c
The testcase now is diagnosed on s390x which has upped completely
peel times limits. It's clearly doing a bogus access at e[-63],
but it's a compile-time only test, so silence diagnostics.
Richard Biener [Mon, 9 Feb 2026 09:53:01 +0000 (10:53 +0100)]
tree-optimization/124034 - remove early-break special-casing of inductions
After recent improvements to how we deal with early-break requirements
of induction variable updates we no longer need to force induction
latch defs relevant. This in turn makes only-live defs visible to
SLP discovery, resolving the miscompilation in this PR.
PR tree-optimization/124034
* tree-vect-stmts.cc (process_use): Never force induction
latch defs relevant when doing early break vectorization.
* gcc.dg/vect/vect-early-break_142-pr124034.c: New testcase.
Martin Jambor [Mon, 9 Feb 2026 09:31:10 +0000 (10:31 +0100)]
tree-sra: Do not propagate bit-field accesses across assignments (PR 117217)
On master at least, this is a bug which no longer reproduces with the
provided test-cases because after r15-5747-gfd62fdc5e1b3c4:(Jakub
Jelinek: c++: Small initial fixes for zeroing of padding bits
[PR117256]), the input to SRA looks very different and SRA does not do
anything.
However, before that commit, SRA sees the following input and if it
encountered something similar now, it could still misbehave in the
same way:
D.2908.i = 0;
D.2908.b = 0;
e ={v} {CLOBBER(bob)};
e.b = MEM[(const struct B &)&D.2908];
D.2908 ={v} {CLOBBER(eos)};
(Where the "e" in "e.b" is actually a MEM_REF of the union type into
&e so that is why the "data" field is missing.)
Field D.2908.b is a SRA candidate of boolean type and has size 1 bit
because its decl has size 1 bit even though its type has size 8 bits.
The SRA access representing the store to D.2908.b is then propagated
across the assignment to e and in the process
build_user_friendly_ref_for_offset tries to find a nice expression for
it to possibly use in warnings. It finds types_compatible_p
e.data.a.b which however has size 8 bits and so the verifier screams
when it discovers the discrepancy from the copied-over size of 1 bit.
This patch avoids the situation by refusing to propagate
non-byte-sized accesses across assignments.
gcc/ChangeLog:
2026-02-06 Martin Jambor <mjambor@suse.cz>
PR tree-optimization/117217
* tree-sra.cc (propagate_subaccesses_from_rhs): Do not propagate
bit-field children.
(propagate_subaccesses_from_lhs): Likewise.
gcc/testsuite/ChangeLog:
2026-02-06 Martin Jambor <mjambor@suse.cz>
PR tree-optimization/117217
* g++.dg/torture/pr117217-1.C: New test.
* g++.dg/torture/pr117217-2.C: Likewise.
Jakub Jelinek [Mon, 9 Feb 2026 08:06:47 +0000 (09:06 +0100)]
c++: Fix up diagnostics of wrong constexpr bodies in C++11 in templates [PR123889]
We emit weird diagnostics on the following testcase in C++11.
If it is not a template, maybe_save_constexpr_fundef calls first
if (!is_valid_constexpr_fn (fun, complain))
return;
(which doesn't fail) and then
tree massaged = massage_constexpr_body (fun, DECL_SAVED_TREE (fun));
if (massaged == NULL_TREE || massaged == error_mark_node)
{
if (!DECL_CONSTRUCTOR_P (fun) && complain)
error ("body of %<constexpr%> function %qD not a return-statement",
fun);
return;
}
which diagnoses it and if even that would succeed, go on with
bool potential = potential_rvalue_constant_expression (massaged);
if (!potential && complain)
require_potential_rvalue_constant_expression_fncheck (massaged);
In templates, maybe_save_constexpr_fundef returns early:
if (processing_template_decl
|| cp_function_chain->invalid_constexpr
|| (DECL_CLONED_FUNCTION_P (fun) && !DECL_DELETING_DESTRUCTOR_P (fun)))
return;
and then it is called again during instantiation.
But in that case DECL_GENERATED_P (fun) is true and so we silently return
on errors without diagnosing them:
bool complain = !DECL_GENERATED_P (fun) && !implicit;
Now, when we actually try to constexpr evaluate those (if at all), we
emit an error and then
'constexpr ...' is not usable as a 'constexpr' function because:
message and then explain_invalid_constexpr_fn tries to diagnose
the errors by calling is_valid_constexpr_fn (fun, true) and
require_potential_rvalue_constant_expression (massaged). So it diagnoses
those 2 cases, but misses the one where massaged was NULL or error_mark_node
for a non-constructor, so after the because: there is no reason emitted.
The following patch diagnoses even that.
2026-02-09 Jakub Jelinek <jakub@redhat.com>
PR c++/123889
* constexpr.cc (explain_invalid_constexpr_fn): Diagnose
NULL or error_mark_node massaged on non-constructor.
Jeff Law [Sun, 8 Feb 2026 15:23:07 +0000 (08:23 -0700)]
[PR target/123911][RISC-V] Fix infinite recursion in riscv_legitimize_move
I kept hoping I'd see a better solution, perhaps one where chunks of this
routine just go away, but that hasn't materialized. So...
This patch avoids infinite recursion through riscv_legitimize_move.
Essentially we end up calling it recursively with arguments that are a nop-move
and those particular arguments trigger infinite recursion.
So this patch just recognizes and elides the nop move. Bootstrapped on
riscv64-linux-gnu and regression tested on riscv{32,64}-elf with no
regressions. Pushing to the trunk.
This is a regression present on the mainline and 15 branch: the compiler
gives a bogus "potentially unsynchronized barrier" when the condition of
an entry barrier requires the creation of a controlled temporary, because
it comes with a transient scope that fools the test on scopes done in the
Is_Global_Entity procedure.
gcc/ada/
PR ada/124025
* exp_ch9.adb (Expand_Entry_Barrier.Is_Global_Entity): Use
Scope_Within_Or_Same to test whether the object is local.
gcc/testsuite/
* gnat.dg/protected_type1.adb: New test.
Eric Botcazou [Sun, 8 Feb 2026 23:14:49 +0000 (00:14 +0100)]
Ada: Fix too small component size for fixed-point array incorrectly accepted
This plugs a loophole in the validation of component size aspects/clauses
specified for array types, by copying what is done for record types.
gcc/ada/
PR ada/121576
* freeze.adb (Freeze_Array_Type): When the component size is
specified, check that it is valid when the component type is
either a fixed-point type or a bit-packed array type.
gcc/testsuite/
* gnat.dg/specs/component_size1.ads: New test.
Harald Anlauf [Sun, 8 Feb 2026 20:00:49 +0000 (21:00 +0100)]
Fortran: fix string length for array constructors with type-spec [PR85547]
PR fortran/85547
gcc/fortran/ChangeLog:
* decl.cc (gfc_match_volatile): Fix frontend memleak.
(gfc_match_asynchronous): Likewise.
* dump-parse-tree.cc (show_expr): Show type-spec for character
array constructor when given.
* simplify.cc (gfc_simplify_len): Simplify LEN() when type-spec
is provided for character array constructor.
* trans-intrinsic.cc (gfc_conv_intrinsic_len): Likewise.
Iain Buclaw [Sun, 8 Feb 2026 19:50:39 +0000 (20:50 +0100)]
d: Add convenient overload for build_libcall
Most generated calls to build_libcall don't require any special
conversions from the generic type returned by the library. Add an
overload that calls the library function without doing any nop casts.
gcc/d/ChangeLog:
* d-tree.h (build_libcall): New declaration.
* runtime.cc (build_libcall_1): New function.
(build_libcall): New overload.
* d-codegen.cc (build_assert_call): Call build_libcall without Type
argument.
(build_array_bounds_call): Likewise.
(build_bounds_index_condition): Likewise.
(build_bounds_slice_condition): Likewise.
(build_closure): Likewise.
* expr.cc (ExprVisitor::visit): Likewise.
* toir.cc (IRVisitor::visit): Likewise.
Iain Buclaw [Sun, 8 Feb 2026 17:31:50 +0000 (18:31 +0100)]
d: Fix error when passing assert(0) as argument [PR123995]
Library routines that either throw or halt execution already have the
call flag ECF_NORETURN. Make their internal type `noreturn' as well, so
that they can be "passed" to functions accepting noreturn arguments.
testsuite: Fix ice-pr116228.C test for 32-bit targets
This test fails on 32-bit targets:
..../gcc/gcc/testsuite/g++.dg/analyzer/ice-pr116228.C:3:7: error: 'operator new' takes type 'size_t' ('unsigned int') as first parameter [-fpermissive]
Fix by using proper __SIZE_TYPE__ type.
Ensured that the test still passes with this patch. Also, reverted the
fix for r16-7383-gf3f7e7514a794f, and ensured that the test still can
expose the ICE on x86_64-pc-linux-gnu:
$ make check-gcc-c++ RUNTESTFLAGS="--target_board=unix/ analyzer.exp=ice-pr116228.C"
FAIL: g++.dg/analyzer/ice-pr116228.C -std=c++20 (internal compiler error: in get_or_create_null_ptr, at analyzer/region-model-manager.cc:257)
# of unexpected failures 6
$ make check-gcc-c++ RUNTESTFLAGS="--target_board=unix/-m32 analyzer.exp=ice-pr116228.C"
FAIL: g++.dg/analyzer/ice-pr116228.C -std=c++20 (internal compiler error: in get_or_create_null_ptr, at analyzer/region-model-manager.cc:257)
# of unexpected failures 6
gcc/testsuite/ChangeLog:
* g++.dg/analyzer/ice-pr116228.C: Use __SIZE_TYPE__ for "new"
operator declaration.
Paul Thomas [Sun, 8 Feb 2026 07:59:15 +0000 (07:59 +0000)]
Fortran: [PDT] Fix faults in fiats runtime [PR123545,PR123673,PR122949]
2026-02-08 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/123545
PR fortran/123673
* decl.cc (gfc_get_pdt_instance): If a pdt_type component is
allocatable or has allocatable components, mark it alloc_comp.
(gfc_match_decl_type_spec): Sometimes in compiling contained
functions, the symtree for the constructor points to the type
instead of the constructor symbol. This corrects itself later
in compilation so return MATCH_YES.
* trans-decl.cc (gfc_generate_function_code): Unconditionally
nullify allocatable components as well as applying the default
initializer.
* trans-expr.cc (gfc_trans_alloc_subarray_assign): Restrict the
freeing of the destination data to non-allocatable expressions
and, instead, add the se finalblock to the encompassing final_
block.
gcc/testsuite
PR fortran/123545
* gfortran.dg/pdt_82.f03: New test.
PR fortran/123673
* gfortran.dg/pdt_83.f03: New test.
PR fortran/122949
* gfortran.dg/pr122949.f90: New test.
Nathaniel Shead [Sat, 31 Jan 2026 10:45:39 +0000 (21:45 +1100)]
c++/modules: Fix ICE with multiple module declarations and -M [PR123738]
When only doing preprocessing, we do not call declare_module, and so we
do not check that a module has been declared multiple times. This means
we end up with multiple "primary modules" being passed to the dependency
producing logic, which asserts. Fixed by checking if we've already seen
a module declaration and complaining.
PR c++/123738
gcc/cp/ChangeLog:
* module.cc (preprocess_module): Complain for any non-imported
module declaration in a module purview.
gcc/testsuite/ChangeLog:
* g++.dg/modules/dep-5.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Jonathan Yong [Sun, 8 Feb 2026 03:25:22 +0000 (03:25 +0000)]
gcc.dg/analyzer/null-deref-pr105755.c: fix llp64
Fix compile warnings with mingw-w64.
Signed-off-by: Jonathan Yong <10walls@gmail.com>
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/null-deref-pr105755.c:
(ptrdiff_t): Change from long int to __PTRDIFF_TYPE__.
(EMACS_INT): Change from long int to __UINTPTR_TYPE__.
(intmax_t): change from long int to __INTMAX_TYPE__.
Marek Polacek [Mon, 26 Jan 2026 19:51:02 +0000 (14:51 -0500)]
c++/reflection: splice parsing fixes [PR123823]
This patch fixes the problem that when cp_parser_splice_specifier sees
:]<, it always thinks it's a template-id. Consequently, this should compile
but does not:
int i;
constexpr auto r = ^^i;
bool b = [:r:] < 42;
because we think that a template argument list follows the splice.
Fixed by implementing [temp.names]/3 better: only attempt to parse
a template argument list if we saw template or typename. As an
extension, also parse a template argument list if the splice yielded
a TEMPLATE_DECL -- in that case, chances are that the user simply
forgot to specify 'template'. In that case we'll suggest adding
'template' in cp_parser_splice_expression.
We should accept the following given [temp.names]/3:
S<[:r:] < 43> s;
and we should also accept:
[:r:] < 42 > 0;
I also realized that my code to detect unparenthesized splice
expressions as template arguments is wrong. [expr.prim.splice] says that
constexpr auto i = e<[:^^h:]>;
is ill-formed, but "S<[:r:] >= 1>" is fine as per [temp.names]/6. I moved
the checking to cp_parser_template_argument while making sure that we
only complain when the splice-expression is the whole template-argument.
This patch also fixes 123640.
PR c++/123823
PR c++/123640
gcc/cp/ChangeLog:
* parser.cc (cp_parser_splice_specifier): New typename_p parameter.
Use cp_parser_nth_token_starts_template_argument_list_p instead of
checking CPP_LESS. Check for typename/template/TEMPLATE_DECL before
parsing a template-id.
(cp_parser_splice_type_specifier): Adjust the call to
cp_parser_splice_specifier.
(cp_parser_splice_expression): Don't detect unparenthesized splice
expressions here. Adjust the call to cp_parser_splice_specifier.
(cp_parser_splice_scope_specifier): Adjust the call to
cp_parser_splice_specifier.
(cp_parser_skip_entire_splice_expr): New, broken out of...
(cp_parser_splice_spec_is_nns_p): ...this.
(cp_parser_template_id): Call pop_deferring_access_checks.
(cp_parser_template_argument): Detect unparenthesized splice
expressions here.
gcc/testsuite/ChangeLog:
* g++.dg/reflect/crash6.C: Adjust expected diagnostic.
* g++.dg/reflect/expr3.C: Likewise. Test more cases.
* g++.dg/reflect/splice4.C: Adjust expected diagnostic.
* g++.dg/reflect/error12.C: New test.
* g++.dg/reflect/parse1.C: New test.
* g++.dg/reflect/parse2.C: New test.
* g++.dg/reflect/parse3.C: New test.
* g++.dg/reflect/parse4.C: New test.
* g++.dg/reflect/parse5.C: New test.
* g++.dg/reflect/parse6.C: New test.
Jeff Law [Sat, 7 Feb 2026 18:49:30 +0000 (11:49 -0700)]
Fix testsuite scan failure on loongarch64
Robin's patch to fix nonzero bits for the result of a popcount triggered a
minor testsuite scan failure for loongarch. Essentially it was expecting to
see an ANDI for a zero-extend, but after the change we get a slli with a count
0, which is used for sign extension on loongarch.
Both are likely equally performant. So this just adjusts the test to accept
both forms. Now one could argue that the result of the popcount is already
sign extended and you'd be right -- that's a separate missed optimization issue
and unrelated to this testsuite regression.
Anyway, pushing this to the trunk.
gcc/testsuite/
* gcc.dg/pr90838.c: Adjust expected output for loongarch.
Jakub Jelinek [Sat, 7 Feb 2026 17:45:13 +0000 (18:45 +0100)]
forwprop: Fix up calc_perm_vec_perm_simplify_seqs [PR123672]
Since r15-5563-g1c4d39ada we have an optimization to try to blend 2
sequences of 2xVEC_PERM_EXPR + 2x binop + 1x VEC_PERM where the first two
VEC_PERMs are permuting a single input and the last one permutes result from
those 2 binops into 2 VEC_PERM_EXPRs from 2 inputs, 2 binops and 2 final
VEC_PERMs.
On the following testcase, the intended change (i.e. after patch) is
(including DCE after it which the optimizations relies on):
a_7 = *x_6(D);
b_9 = *y_8(D);
- c_10 = VEC_PERM_EXPR <a_7, a_7, { 0, 2, 0, 2 }>;
- d_11 = VEC_PERM_EXPR <a_7, a_7, { 1, 3, 1, 3 }>;
- e_12 = VEC_PERM_EXPR <b_9, b_9, { 0, 2, 0, 2 }>;
- f_13 = VEC_PERM_EXPR <b_9, b_9, { 1, 3, 1, 3 }>;
+ c_10 = VEC_PERM_EXPR <a_7, b_9, { 0, 2, 4, 6 }>;
+ d_11 = VEC_PERM_EXPR <a_7, b_9, { 1, 3, 5, 7 }>;
_1 = c_10 + d_11;
_2 = c_10 - d_11;
g_14 = VEC_PERM_EXPR <_1, _2, { 0, 4, 1, 5 }>;
- _3 = e_12 + f_13;
- _4 = e_12 - f_13;
- h_15 = VEC_PERM_EXPR <_3, _4, { 0, 4, 1, 5 }>;
+ h_15 = VEC_PERM_EXPR <_1, _2, { 2, 6, 3, 7 }>;
*x_6(D) = g_14;
*y_8(D) = h_15;
This works by first identifying the two sequences, attempting to use vect
elem redundancies to only use at most half of the vector elements
(in this testcase a nop because 0, 4, 1, 5 perms already use only half of
the vector elts), remembering details of such sequences and later comparing
them if there are at least two (up to 8 I think) and trying to merge them.
The optimization is meant to improve SPEC x264.
Anyway, in r15-6387-geee289131 the optimization was changed to fix some
regressions but regressed this testcase, instead of the desirable
{ 0, 2, 4, 6 } and { 1, 3, 5, 7 } first 2 VEC_PERMs 15 branch and trunk
uses { 0, 2, 4, 4 } and { 1, 3, 5, 5 } and on this testcase that means
computing incorrect result.
On this testcase, it identified the two sequences (one ending with g_14
and one with h_15 with no changes (see above). The first one (it has
some code to attempt to swap them if needed, but here the first one remains
g_14) keeps using the final VEC_PERM_EXPR as is (or with whatever
simplification recognise_vec_perm_simplify_seq performed on just that to
reduce to at most half of nelts) and the second one is modified so that
it uses the other elts of the two vectors.
So, we have { 0, 4, 1, 5 } (i.e. twice first lanes and twice second lanes)
from the first sequence and look up unused lanes (third and fourth) to
transform the other { 0, 4, 1, 5 } to, and find that is { 2, 6, 3, 7 }.
So far good. But the next operation is to compute the new selectors
for the first 2 VEC_PERM_EXPRs, which are changed from single input to
two input ones. For that, the code correctly uses the VECTOR_CST elts
unmodified for the lanes used by the first sequence (in this
testcase first/second lanes), so { 0, 2, X, X } and { 1, 3, X, X }
and then need to find out what to use for the needs of the second sequence.
Here is what it does currently:
for (i = 0; i < nelts; i++)
{
bool use_seq1 = lane_assignment[i] != 2;
unsigned int l1, l2;
if (use_seq1)
{
/* Just reuse the selector indices. */
tree s1 = gimple_assign_rhs3 (seq1->v_1_stmt);
tree s2 = gimple_assign_rhs3 (seq1->v_2_stmt);
l1 = TREE_INT_CST_LOW (VECTOR_CST_ELT (s1, i));
l2 = TREE_INT_CST_LOW (VECTOR_CST_ELT (s2, i));
}
else
{
/* We moved the lanes for seq2, so we need to adjust for that. */
tree s1 = gimple_assign_rhs3 (seq2->v_1_stmt);
tree s2 = gimple_assign_rhs3 (seq2->v_2_stmt);
unsigned int j = 0;
for (; j < i; j++)
{
unsigned int sel_new;
sel_new = seq2_stmt_sel_perm[j].to_constant ();
sel_new %= nelts;
if (sel_new == i)
break;
}
/* This should not happen. Test anyway to guarantee correctness. */
if (j == i)
return false;
seq1_v_1_stmt_sel_perm.quick_push (l1 + (use_seq1 ? 0 : nelts));
seq1_v_2_stmt_sel_perm.quick_push (l2 + (use_seq1 ? 0 : nelts));
}
seq2_stmt_sel_perm is the newly computed { 2, 6, 3, 7 } selector and
seq1->v_{1,2}_stmt are def stmts of {c_10,d_11} and seq2->v_{1,2}_stmt
are def stmts of {e_12,f_13}. For i 0 and 1 it is use_seq1 and
correct, then for i 2 the loop checks first seq2_stmt_sel_perm[0],
it is 2 % 4, equal to i, so picks up VECTOR_CST_ELTS (s{1,2}, 2),
which happens to be correct in this case, for i 3 the loop loops until
seq2_stmt_sel_perm[2] which is 3 % 4, stops and picks the wrong
VECTOR_CST_ELTS (s{1,2}, 2) which has the same value as
VECTOR_CST_ELTS (s{1,2}, 0), when the correct value would be in this
case either 1 or 3 (due to the duplication).
What the loop should do for !use_seq1 is to take the lane transformations
into account, we've changed { 0, 4, 1, 5 } to { 2, 6, 3, 7 }, so instead
of using lanes 0, 0, 1, 1 we now use lanes 2, 2, 3, 3 (x / 4 is about
which input it is picked from, here + or -). So, for 2 which got remapped
from 0 we want to use 0 and for 3 which got remapped from 1 we want to use
1.
The function uses an auto_vec lane_assignment with values 0 (unused lane,
so far or altogether), 1 (used by first sequence) and 2 (used by second
sequence). When we store in there 2, we know exactly which lane we are
remapping to which lane, so instead of computing it again the following
patch stores there 2 + l_orig, such that value >= 2 means second lane
and lane_assignment[i] - 2 in that case is the lane that got remapped to i.
And then the last loop doesn't need to recompute anything and can just use
the remembered transformation.
The rest of the changes (hunks 1-5 and 7) are just random small fixes I've
noticed while trying to understand the code. The real fix is
- lane_assignment[lane] = 2;
+ lane_assignment[lane] = 2 + l_orig;
and
- bool use_seq1 = lane_assignment[i] != 2;
+ bool use_seq1 = lane_assignment[i] < 2;
and the rest of the last hunk. Also, the last loop was kind of assuming
VEC_PERM_EXPR canonicalization happened and for single input perm the
selector elts are never >= nelts, I've added %= nelts just to be sure.
2026-02-07 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/123672
* tree-ssa-forwprop.cc (recognise_vec_perm_simplify_seq): Use std::swap
instead of fetching gimple_assign_rhs{1,2} again. Change type of lanes
vector from auto_vec<unsigned int> to auto_vec<bool> and store true
instead of 1 into it. Fix comment typo and formatting fix.
(can_blend_vec_perm_simplify_seqs_p): Put end of comment on the same
line as the last sentence in it.
(calc_perm_vec_perm_simplify_seqs): Change lane_assignment type from
auto_vec<int> to auto_vec<unsigned> and store 2 + l_orig into it
instead of true. Fix comment typo and formatting fix. Set use_seq1
to line_assignment[i] < 2 instead of line_assignment[i] != 2. Replace
bogus computation of index for !use_seq with using
line_assignment[i] - 2. Set l1 to l1 % nelts and similarly for l2.
David Malcolm [Sat, 7 Feb 2026 15:21:00 +0000 (10:21 -0500)]
analyzer: fix ICE on operator new with discarded result [PR116228]
gcc/analyzer/ChangeLog:
PR analyzer/116228
* kf-lang-cp.cc (kf_operator_new::impl_call_post): Don't try to
add a constraint if the return value is discarded.
gcc/testsuite/ChangeLog:
PR analyzer/116228
* g++.dg/analyzer/ice-pr116228.C: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Jakub Jelinek [Sat, 7 Feb 2026 10:07:28 +0000 (11:07 +0100)]
c++: Handle SPLICE_SCOPE in cp_walk_subtrees [PR123659]
SPLICE_SCOPE is a TYPE_P, but didn't have its SPLICE_SCOPE_EXPR
walked by cp_walk_tree, so the following testcase has been rejected
because it didn't find a pack in it.
SPLICE_EXPR is fine, as it is tcc_expression and walk_tree by default
walks all the tcc_exception operands for unknown trees.
Jakub Jelinek [Sat, 7 Feb 2026 10:06:35 +0000 (11:06 +0100)]
c++: Fix error recovery of invalid splice during tsubst_splice_expr [PR123752]
splice can return error_mark_node, e.g. if the evaluation of the
constant expression throws without being caught, and the error_mark_node
later on causes ICEs in various asserts.
The following patch fixes it by returning early if error_mark_node is
returned.
2026-02-07 Jakub Jelinek <jakub@redhat.com>
PR c++/123752
* pt.cc (tsubst_splice_expr): Return error_mark_node if
splice returned it.
The following reverts part of the changes done by r16-869-ge3d3d6d7d2c8ab
which AFAICS was never posted on the mailing list. The hunk reverted
adds extra costs for vector construction of AVX or AVX512 vectors
because Honza thought we're only adding 1 conversion for all constructs,
but in fact we're costing each individual unique scalar source used.
Noticed when investigating PR120234, but this does not affect it
since there it's all SSE sized operations.
Still this is a regression, though reading r16-869-ge3d3d6d7d2c8ab
commit message indicating "correct numbers regress benchmarks" might
make this somewhat dangerous. Still r16-531-g37e61c793c1b22 already
made the constructor costs much more expensive for integers, so
this might compensate.
* config/i386/i386.cc (ix86_vector_costs::add_stmt_cost):
Remove double and triple accounting of GPR -> XMM moves
in construction of AVX and AVX512 vectors.
During cse1, in insn 12 pseudo 120 is substituted with hard register 33
rendering the resulting insn trivial which is why the insn gets removed
afterwards. Since hard register 33 has a use after insn 12, the
register is live before and after insn 10. This leaves us with the
non-trivial problem, during LRA, to also assign hard register 33 to
pseudo 124 which is coming from the constraint of insn 10. Since hard
registers are not tracked, except for liveness, this cannot be solved by
reloads which is why we end up with an error. Therefore, treat single
register constraints as clobbers of the respective hard registers.
For the sake of symmetry this should also be done for constraints
associated a single register class. However, since we are in stage 4,
there is no open PR, and I haven't done any extensive testing for single
register classes, I'm skipping this for the moment. Once we are back in
stage 1, something along the lines could be added:
else
{
enum reg_class cl
= reg_class_for_constraint (lookup_constraint (p));
if (cl == NO_REGS)
continue;
machine_mode mode = recog_data.operand_mode[nop];
int regno = ira_class_singleton[cl][mode];
if (regno >= 0)
invalidate_reg (gen_rtx_REG (mode, regno));
}
gcc/ChangeLog:
* cse.cc (invalidate_from_sets_and_clobbers): Consider any hard
register referred to by any single register constraint
potentially being clobbered.
Roger Sayle [Sat, 7 Feb 2026 08:04:40 +0000 (08:04 +0000)]
PR tree-optimization/123958: FMA vs pow(x,2.0) [vs errno]
This is my proposed solution to PR123958 (and PR124002) which is a
regression exposed by my recent change to avoid expanding pow(x,2.0)
to x*x with -fmath-errno (the default) when we can't guarantee that
errno shouldn't be updated. The problem is that the logic to convert
pow(x,2.0) was also duplicated (but unused) in tree-ssa-math-opts
where it's intended to perform this conversion in order to expose
fused-multiply-add instructions when supported by the target. The
issue is that this "vestigial" code has bit-rotten over the years,
and incorrectly updates vdefs when changing vops, tiggering an ICE.
My pragmatic solution to this is to simply delete the problematic
code; the decision of whether pow(x,2.0) should be expanded is left
to the earlier pow_expand pass (which is what it's designed for), and
the later FMA pass can make use of any resulting FP multiplications.
Not only does this avoid the PHI related ICE, but also fixes the
original PR (on updating errno) on targets with FMA, e.g. aarch64
and recent x86_64 architectures (such as -march=znver3).
2026-02-07 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR middle-end/123826
PR tree-optimization/123958
PR c++/124002
* tree-ssa-math-opts.cc (math_opts_dom_walker::after_dom_children):
Delete code that (mis)handled conversion of pow(x,2.0) to x*x.
gcc/testsuite/ChangeLog
PR middle-end/123826
PR tree-optimization/123958
PR c++/124002
* g++.target/i386/pr124002.C: New test case.
* gcc.target/i386/pr123958.c: Likewise.
* gcc.dg/errno-4.c: Likewise.
Roger Sayle [Sat, 7 Feb 2026 07:50:41 +0000 (07:50 +0000)]
PR rtl-optimization/123833: Use of insn attributes in insn_costs corrupts recog_data.
Thanks again to Jeff Law and Andrew Pinski. Here's a revised patch that
addresses the true underlying cause of PR 128333. recog.cc's cancel_changes
was not correctly updating the recog_data cache, which leads to strange
(incorrect) behavior in fwprop and ifcvt.
2026-02-07 Roger Sayle <roger@nextmovesoftware.com>
Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Jeff Law <jeffrey.law@oss.qualcomm.com>
gcc/ChangeLog
PR rtl-optimization/123833
* recog.cc (cancel_changes): Update the recog_data cache if it
holds the instruction being changed.
gcc/testsuite
PR rtl-optimization/123833
* gcc.target/mips/pr123833.c: New test case.
Martin Jambor [Fri, 6 Feb 2026 21:49:43 +0000 (22:49 +0100)]
ipa-cp: Fix assert triggering with -fno-toplevel-reorder (PR 106260)
with -fno-toplevel-reorder (and -fwhole-program), there apparently can
be local functions without any callers. This is something that IPA-CP
does not like because its propagation verifier checks that local
functions do not end up with TOP in their lattices. Therefore there
is an assert checking that all call-less unreachable functions have
been removed, which tigers in PR 106260 with these two options.
This patch detects the situation and marks the lattices as variable,
thus avoiding both the assert trigger and the verification failure.
gcc/ChangeLog:
2022-07-13 Martin Jambor <mjambor@suse.cz>
PR ipa/106260
* ipa-cp.cc (initialize_node_lattices): Replace assert that there are
callers with handling that situation when -fno-toplevel_reorder.
projects / thirdparty / gcc.git / log
