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.
1. The optimization for avoiding indirect calls while using
declarations like:
proc(string)int puts = nest C "_libga68_posixputs";
has been completed.
2. Algol 68 procedures getting strings as arguments can now
wrap corresponding C functions. Note this does not include
procedures yielding strings as for now.
3. Wrappers are now built for all formal holes having proc mode. This
allows for a more robust implementation.
Signed-off-by: Jose E. Marchesi <jemarch@gnu.org>
gcc/algol68/ChangeLog
* Make-lang.in (ALGOL68_OBJS): Add algol68/a68-low-holes.o.
* a68.h: Update prototypes.
* a68-types.h (struct TAG_T): New field nest_proc.
(NEST_PROC): Define.
* a68-parser.cc (a68_new_tag): Initialize NEST_PROC.
* a68-parser-extract.cc (extract_identities): Use NEST_PROC
instead of IN_PROC for taxes for defining-identifiers in identity
declarations of proc modes with formal holes as actual parameters.
* a68-moids-misc.cc (a68_is_c_mode): Modified to allow strings as
direct parameters.
* a68-low.cc (a68_make_proc_formal_hole_decl): Remove.
* a68-low-units.cc (a68_lower_identifier): Improve commentary.
(a68_lower_formal_hole): Factorize.
* a68-low-holes.cc: New file.
* a68-low-decls.cc (a68_lower_identity_declaration): Optimize
identity declarations of proc mode with formal holes as actual
parameters.
* a68-exports.cc (a68_add_identifier_to_moif): Honor NEST_PROC.
* ga68.texi (Communicating with C): Strings can now be passed as
parameters in formal holes.
gcc/testsuite/ChangeLog
* algol68/compile/error-nest-4.a68: Strings can now be passed as
arguments in formal holes.
build: Only use gas_flag/gnu_ld_flag internally [PR123841]
caused testsuite regressions on Linux/x86_64 in one configuration: if
configured without --with-gnu-as/--with-gnu-ld, taking as and ld from
PATH, the stage 1 gcc/auto-host.h differs:
gas_flag and gnu_ld_flag weren't set correctly in this case:
Without --with-gnu-ld, AC_ARG_WITH(gnu-ld) sets gnu_ld_flag to no. The
later check to determine gnu_ld_flag from $gcc_cv_ld --version isn't
even run because it is guarded by test -z "$gnu_ld_flag".
To avoid this, two things need to happen:
* The ld --version check needs to be done in the ACTION_IF_NOT case of
AC_ARG_WITH(gnu-ld), not afterwards.
* For this to work, gcc_cv_ld needs to be set at this point.
Therefore this patch does the first. In order for the second to work,
AC_ARG_WITH(gnu-ld) is moved later when gcc_cv_ld has already been set.
The same applies to gas_flag, too.
Tested on x86_64-pc-linux-gnu and sparc64-unknown-linux-gnu like so:
* Establish a baseline before my gas_flag/gnu_ld_flag patches:
gcc:
* configure.ac (gnu_ld_flag): Move $gcc_cv_ld --version check into
AC_ARG_WITH(gnu-ld).
(gcc_cv_ld): Set before gnu_ld_flag.
(gas_flag): Move $gcc_cv_ld --version check into AC_ARG_WITH(gnu-ld).
(gcc_cv_as): Set before gas_flag.
* configure: Regenerate.
Jakub Jelinek [Fri, 6 Feb 2026 19:26:01 +0000 (20:26 +0100)]
Allow TYPE_CANONICAL (TYPE_MAIN_VARIANT (t)) not to be its own TYPE_MAIN_VARIANT [PR101312]
I had to revert my r16-7102 patch
https://gcc.gnu.org/pipermail/gcc-patches/2026-January/706424.html
(first patch in
https://gcc.gnu.org/pipermail/gcc-patches/2025-December/704097.html )
in r16-7328 because it regressed the testcase added in r16-7331 for PR123882.
typedef int T;
void foo (unsigned long, T[]);
void foo (unsigned long x, T[restrict x]);
The ICE was on the array_as_string hack which used qualifiers on
ARRAY_TYPE for printing and then FE called get_aka_type and errored
that restrict is not allowed on ARRAY_TYPEs.
Anyway, guess that would be fixable with further hacks, but when looking
into that, I've noticed my approach was completely broken, my assumption
that TYPE_CANONICAL (volatile int) is int is not true, TYPE_CANONICAL
(volatile int) is itself. For volatile int[2], C/C++ pushes the cv quals
to the element type, so it is ARRAY_TYPE of volatile int, and this
modified ARRAY_TYPE is made a type variant of int[2], but its TYPE_CANONICAL
is again volatile int[2].
Furthermore, a lot of places including build_type_attribute_variant call
build_type_attribute_qual_variant like:
return build_type_attribute_qual_variant (ttype, attribute,
TYPE_QUALS (ttype));
so pass the quals of the type to it. If build_type_attribute_qual_variant
for ARRAY_TYPEs behaves differently between C/C++ (in that case it
pushes quals to the element type) and other languages, then this will
do unexpected changes, namely because the ARRAY_TYPE usually (except for
array_as_string hack) don't contain cv quals,
build_type_attribute_variant (volatile int[2], may_alias,
TYPE_QUALS (volatile int[2]))
would create int [2] with may_alias attribute for C/C++.
Now, the ICE on the testcases was in 2 spots, in get_alias_check
gcc_checking_assert and in verify_type -fchecking stuff, the assumption
was that
TYPE_MAIN_VARIANT (TYPE_CANONICAL (TYPE_MAIN_VARIANT (type)))
== TYPE_CANONICAL (TYPE_MAIN_VARIANT (type))
for any type where TYPE_CANONICAL is non-NULL. The reason why
this works e.g. for the C/C++ volatile int[2] is that the ARRAY_TYPE
is variant type of int[2], so the first TYPE_MAIN_VARIANT gets us
int[2] and its TYPE_CANONICAL is int[2] which is the main variant.
Now, if TYPE_CANONICAL (volatile int) needs to be itself (but sure with
typedef volatile int V; TYPE_CANONICAL (V) is volatile int) and I Richi
tried to change that and it broke everything, my change was wrong and
we really need
TYPE_CANONICAL (volatile int[2] __attribute__((may_alias))) to be
volatile int[2] and we create the attribute variants as distinct types,
using build_distinct_type_copy, so
TYPE_MAIN_VARIANT (volatile int[2] __attribute__((may_alias)))
is itself, then the alias/tree assumption that the
TYPE_MAIN_VARIANT (TYPE_CANONICAL (TYPE_MAIN_VARIANT (type)))
== TYPE_CANONICAL (TYPE_MAIN_VARIANT (type))
can't hold. We need one further hop, so just guarantee that
TYPE_CANONICAL (TYPE_MAIN_VARIANT (TYPE_CANONICAL (TYPE_MAIN_VARIANT (type))))
== TYPE_MAIN_VARIANT (TYPE_CANONICAL (TYPE_MAIN_VARIANT (type))).
The following patch changes get_alias_set and tree.cc to verify that
instead. For get_alias_set the checking checks more than before,
in particular that for both steps TYPE_CANONICAL is its own TYPE_CANONICAL
rather than just that !TYPE_STRUCTURAL_EQUALITY_P (i.e. TYPE_CANONICAL
is non-NULL). verify_type already checks that though.
I've tried even
typedef volatile int A[1] __attribute__((may_alias));
typedef A __attribute__((btf_type_tag ("foo"))) B;
B c;
i.e. cascading more than one type attribute on the ARRAY_TYPE and it
still works, TYPE_CANONICAL (A) will be volatile int A[1] without
attribute and TYPE_CANONICAL (B) the same.
2026-02-06 Jakub Jelinek <jakub@redhat.com>
PR c/101312
* alias.cc (get_alias_set): Allow TYPE_CANONICAL (mv) to be
not its own TYPE_MAIN_VARIANT, as long as its TYPE_MAIN_VARIANT
has TYPE_CANONICAL equal to itself.
* tree.cc (verify_type): Likewise.
* gcc.dg/pr101312-1.c: New test.
* gcc.dg/pr101312-2.c: New test.
Andrew Stubbs [Fri, 6 Feb 2026 16:09:57 +0000 (16:09 +0000)]
amdgcn: Clean up the mov insn definitions
This patch should not change anything functional; it just deletes some cruft
and converts the constraints to the new format. This is to make it easier
to edit later.
* The long-commented-out insns are now deleted.
* The vestigial support for unaligned register pairs has been removed (it
was disabled and removed elsewhere long ago).
gcc/ChangeLog:
* config/gcn/gcn-valu.md (*mov<mode>_exec_match): Delete.
(*mov<mode>_exec_match): Likewise.
(*mov<mode>): Delete unaligned register support, and convert to new
constraint syntax.
(mov<mode>_exec): Likewise.
(@mov<mode>_sgprbase): Likewise.
* config/gcn/gcn.md (*movbi): Likewise.
David Malcolm [Fri, 6 Feb 2026 15:54:52 +0000 (10:54 -0500)]
analyzer: use value_range and range_op in eval_condition [PR98447]
PR analyzer/98447 covers a false positive from -fanalyzer.
The root cause is that the analyzer's constraint-handling code
doesn't "know" that if X := Y % 64, then X < 64.
This patch adds some minimal usage of value_range and range_op to
-fanalyzer. It adds a new svalue::maybe_get_value_range vfunc, which
attempts to get a value_range for an svalue (but bails out for awkward
cases), and if value_ranges are available, uses them in eval_condition
to determine if the result is known based on range_op.
Doing so fixes the above false positive, improves a couple of other
tests in the DejaGnu testsuite, and eliminates 31 false +ves in the
analyzer integration testsuite (out of ~2200), along with a slight
speedup to the latter (albeit testing with a debug build of gcc).
A deeper integration with ranger could probably be made, but that is
clearly stage 1 material.
gcc/analyzer/ChangeLog:
PR analyzer/98447
* common.h: Include "value-range.h".
* region-model.cc: Include "value-relation.h" and "range-op.h".
(region_model::eval_condition): Try using range_op to see if we
can get a known boolean from the value_ranges of the operands.
* svalue.cc: Include "value-relation.h" and "range-op.h".
(type_can_have_value_range_p): New.
(svalue::maybe_get_value_range): New.
(constant_svalue::maybe_get_value_range): New.
(unknown_svalue::maybe_get_value_range): New.
(unaryop_svalue::maybe_get_value_range): New.
(binop_svalue::maybe_get_value_range): New.
* svalue.h (svalue::maybe_get_value_range): New vfunc decl.
(constant_svalue::maybe_get_value_range): New decl.
(unknown_svalue::maybe_get_value_range): New decl.
(unaryop_svalue::maybe_get_value_range): New decl.
(binop_svalue::maybe_get_value_range): New decl.
gcc/testsuite/ChangeLog:
PR analyzer/98447
* c-c++-common/analyzer/conditionals-pr98447-1.c: New test.
* c-c++-common/analyzer/conditionals-pr98447-2.c: New test.
* c-c++-common/analyzer/null-deref-pr108400-SoftEtherVPN-WebUi.c:
Updated for false positive being fixed for C.
* gcc.dg/analyzer/data-model-1.c: Update expected output to
reflect improved output.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Tomasz Kamiński [Fri, 6 Feb 2026 11:03:37 +0000 (12:03 +0100)]
libstdc++: Update guards on __heterogeneous_hash_key and __heterogeneous_tree_key
The r16-7359-gae04c1afd1526a changed __heterogeneous_key to be
defined if __glibcxx_associative_heterogeneous_erasure, but missed
guards on derived __heterogeneous_hash_key and __heterogeneous_tree_key
concept.
libstdc++-v3/ChangeLog:
* include/bits/hashtable.h (std::__heterogeneous_hash_key)
[__glibcxx_associative_heterogeneous_erasure]: Changed guard.
* include/bits/stl_tree.h (std::__heterogeneous_tree_key)
[__glibcxx_associative_heterogeneous_erasure]: Likewise.
* include/bits/stl_function.h: Add comment with C++ version
for __glibcxx_associative_heterogeneous_erasure guard.
Richard Biener [Fri, 6 Feb 2026 10:03:54 +0000 (11:03 +0100)]
rtl-optimization/119982 - XFAIL part of gcc.target/i386/pr109362.c
This XFAILs the gcc.target/i386/pr109362.c testcase where we now
need an additional register for the address part of a sequence
of two atomic loads because TER no longer applies after we now
hoist the address computation out of a loop. In the PR I noted
how RTL propagation could handle this. In the end this restores
the state we had in GCC 12 and earlier where in GCC 13 the code
generation improved by accident.
Richard Biener [Fri, 6 Feb 2026 08:26:37 +0000 (09:26 +0100)]
tree-optimization/114274 - avoid stray BLOCK refrence from CSWTCH vars
The following removes the location from CSWTCH variables which are
DECL_IGNORED_P and have no DECL_CONTEXT. The location is currently
taken from the gswitch statement and thus includes a BLOCK reference
which can eventually be elided and GCd, causing later ICEs when
ICF decides to merge the variable with some other.
PR tree-optimization/114274
* tree-switch-conversion.cc (switch_conversion::build_one_array):
Use UNKNOWN_LOCATION for the CSWTCH decl.
Nathan Myers [Fri, 6 Feb 2026 08:56:42 +0000 (03:56 -0500)]
libstdc++: fix C++17 regression in concept __heterogeneous_key (2nd)
The commit 3f7905550483408a2c4c5096a1adc8d7e863eb12 defined a
concept __heterogeneous_key using a name not defined in C++17.
This is fixed by guarding the definition behind a name defined
in C++23 the earliest Standard that uses the definition.
Jakub Jelinek [Fri, 6 Feb 2026 10:27:52 +0000 (11:27 +0100)]
tree: Fix up build_function_type for (...) fntypes [PR123977]
The following testcase ICEs in -std=c++26 mode since my r16-4338 C++26
va_start changes.
The problem is that if we have anything non-canonical in a function
type with (...) in C++26 (or C23/C2Y) mode, in this case the R typedef
on return type rather than void, then we try to build TYPE_CANONICAL
for that, but weren't passing in the no_named_args_stdarg_p, so
a type with TYPE_NO_NAMED_ARGS_STDARG_P flag set got TYPE_CANONICAL
with TYPE_NO_NAMED_ARGS_STDARG_P flag cleared and comptypes then
didn't like that as those aren't really compatible types
(...) vs. the C89-ish () which even C++ uses for some type-generic
etc. builtins.
2026-02-05 Jakub Jelinek <jakub@redhat.com>
PR c++/123977
* tree.cc (build_function_type): Pass no_named_args_stdarg_p
as last argument to recursive call.
Jonathan Wakely [Tue, 9 Dec 2025 21:02:56 +0000 (21:02 +0000)]
libstdc++: Prevent std::stacktrace from using atomics on arm-eabi [PR120567]
The conftest.cc in GLIBCXX_ENABLE_BACKTRACE checks if calls to
__atomic_load and __atomic_store result in libatomic calls. For arm-eabi
those expand to normal loads with a call to __sync_synchronize to ensure
correct ordering. That means the generated assembly does not match the
grep pattern "__atomic_" and so configure incorrectly assumes we can use
atomics in libbacktrace.
The fix is to grep for "__atomic_|__sync_" instead of just "__atomic_".
As explained in the bug comments, the similar grep for "__atomic_" in
the GLIBCXX_ENABLE_ATOMIC_BUILTINS macro doesn't need the same change.
That conftest.cc program does emit a call to a libatomic function that
matches the grep pattern "__atomic_" so the test gives the right answer
for arm-eabi.
libstdc++-v3/ChangeLog:
PR libstdc++/120567
* acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Include "__sync_" in
grep command to check for extern calls to libatomic.
* configure: Regenerate.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jonathan Wakely [Thu, 5 Feb 2026 16:52:46 +0000 (16:52 +0000)]
testsuite: Fix pr61053.c testsuite failure on mingw
This test expects an error for x32 where long has smaller alignment than
long long and double, but the same is also true for *-*-mingw* targets.
Add that triplet to the target selectors for the dg-error directives.
gcc/testsuite/ChangeLog:
* gcc.dg/pr61053.c: Add *-*-mingw* to the dg-error directives
that currently only match x32.
Jonathan Wakely [Wed, 7 Jan 2026 14:29:44 +0000 (14:29 +0000)]
libstdc++: Allow new-abi-baseline target to overwrite existing file
There doesn't seem to be much benefit to writing the symbols to
baseline_symbols.txt.new when an existing file is already present. It
just adds a manual step for maintainers to move the .txt.new file to
replace the .txt one. Overwriting the file directly allows you to use
git diff to see what changed immediately, and you can easly use git
commands to revert to the original file too.
David Malcolm [Thu, 5 Feb 2026 23:36:32 +0000 (18:36 -0500)]
value-range: update comments
One of the difficulties I ran into when familiarizing myself with
value-range.{h,cc} is that the comments and classes refer to
representations of "ranges", but the implementation has grown beyond
mere ranges of values (such as with bitmasks and NaN-tracking).
Arguably "range" could refer to the mathematical definition: the set
of possible outputs of a function, but I find it much clearer to think
of these classes as efficient representations of subsets of possible
values of a type.
This patch updates various leading comments in a way that clarifies
the intent of these classes (for me, at least).
gcc/ChangeLog:
* value-range.cc (irange_bitmask::irange_bitmask): Fix typo in
comment.
* value-range.h (class vrange): Update leading comment to refer
to "subsets" rather than "ranges". Allude to the available
subclasses. Warn that the classes can be over-approximations and
thus can introduce imprecision.
(class irange_bitmask): Updating leading comment to refer to
knowledge about a "value", rather than a "range". Reword
description of MASK and VALUE to clarify implementation, and
add an example.
(class irange): Update leading comment to refer to a
"subset of possible values" rather than a "range", and
that subclasses have responsibility for storage.
(class nan_state): Rewrite leading comment.
(class frange final): Update leading comment to refer to
subsets of possible values, rather than ranges, and to
consistently use "Nan" when capitalizing.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Robert Dubner [Thu, 5 Feb 2026 15:45:40 +0000 (10:45 -0500)]
cobol: Use _perform_line_pairs instead of injecting encoded label names.
The gcobol front end has been communicating with GDB-COBOL by encoding
information into labels that are injected into the assembly language
with ASM_EXPR nodes. That behavior is, at best, questionable.
These changes replace the "proccall" and "procret" types of those labels
in favor of a static _perform_line_pairs table that contains the same
information and is accessible by GDB-COBOL by virtue of its known name.
That table allows GDB-COBOL to "NEXT over COBOL PERFORM" statements in a
way that is familiar to users who have used "NEXT over function call".
Eventually that information should find its way into the .debug_info
section, but at the present time I don't know how to do that on either
the compiler or debugger sides.
Most of these changes involve eliminating gg_insert_into_assembler calls
and replacing them with the perform_is_armed/perform_line_pairs logic.
Some COBOL variable initialization changes crept in here, as well.
gcc/cobol/ChangeLog:
* genapi.cc (DEFAULT_LINE_NUMBER): Remove unused #define.
(parser_statement_begin): Implement perform_is_armed logic.
(initialize_variable_internal): Handle both real and int types in
SHOW_PARSE tracing.
(section_label): Comment a renumbered insert_nop() for gdb-cobol
logic.
(paragraph_label): Likewise.
(leave_procedure): Eliminate call to gg_insert_into_assembler().
(parser_enter_section): Renumber insert_nop().
(parser_perform): Eliminate call to gg_insert_into_assembler().
(parser_perform_times): Likewise.
(internal_perform_through): Likewise.
(internal_perform_through_times): Likewise.
(parser_leave_file): Create the static _perform_line_pairs table.
(parser_sleep): Renumber insert_nop().
(parser_division): Remove calls to initialize_the_data().
(parser_perform_start): New call to insert_nop().
(parser_perform_conditional): Likewise.
(perform_outofline_before_until): Expanded comment.
(perform_outofline_after_until): Eliminate call to
gg_insert_into_assembler().
(perform_outofline_testafter_varying): Likewise.
(perform_outofline_before_varying): Likewise.
(perform_inline_testbefore_varying): New call to insert_nop().
(create_and_call): Change a comment.
* gengen.cc (gg_create_goto_pair): Change characteristics of a
label.
* parse.y: Change how data are initialized.
* parse_ante.h (field_type_update): Likewise.
* symbols.cc (cbl_field_t::set_signable): Likewise.
(cbl_field_t::encode): Likewise.
* symbols.h (struct cbl_field_t): Likewise.
* util.cc (symbol_field_type_update): Likewise.
(cbl_field_t::encode_numeric): Likewise.
Jonathan Wakely [Tue, 3 Feb 2026 15:57:47 +0000 (15:57 +0000)]
libstdc++: Fix ambiguity caused by new std::source_location constructor
The new constructor added for Contracts support was not explicit, so
caused ambiguities when arbitrary pointers were used in contexts which
could convert to std::source_location.
We don't actually need a constructor, the contract_violation::location()
function can just set the data member directly.
libstdc++-v3/ChangeLog:
* include/std/contracts (contract_violation::location): Use
source_location default constructor and then set _M_impl.
* include/std/source_location (source_location(const void*)):
Remove constructor.
* testsuite/18_support/contracts/includes.cc: Move to...
* testsuite/18_support/contracts/srcloc.cc: ...here. Test for
ambiguity caused by new constructor.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Matthieu Longo [Fri, 30 Jan 2026 15:08:41 +0000 (15:08 +0000)]
libiberty: add helper to swap doubly-linked list wrappers
This patch introduces a new helper to swap the contents of two
doubly-linked list wrappers. The new *_swap_lists operation exchanges
the first, last, and size fields, allowing two lists to be swapped
efficiently without iterating over their elements.
This helper is intended for cases where the ownership of a list must be
exchanged but swapping wrapper pointers is not possible. For simple
references to lists, when wrappers are dynamically allocated, swapping
the wrapper pointers themselves is sufficient and remains the preferred
approach.
This change adds the necessary declaration and definition macros to
doubly-linked-list.h and integrates them into the set of mutative
list operations.
The testsuite is updated accordingly to cover the new functionality.
This happens in C,C++ frontends before cgraph is created where the
relevant flags are located.
We can suppress these warnings with OPT_Wunused.
C,C++ frontends and cgraphunit suppressed OPT_Wunused and
OPT_Wunused_function interchangeably, so we unify suppression to
only OPT_Wunused.
Jakub Jelinek [Thu, 5 Feb 2026 13:59:12 +0000 (14:59 +0100)]
Revert c, c++: Use c*_build_qualified_type instead of build_qualified_type from within build_type_attribute
As seen in PR123882, this broke more than it fixed, a lot of
build_type_attribute_qual_variant including build_type_attribute_variant
just pass in TYPE_QUALS (type) as the last argument and for C/C++
when the code pushes the quals to the element type, it will effectively
make those unqualified. The PR123882 ICE is then on the array_as_string
terrible hack if the FE calls get_aka_type on that, it wants to create
qualified attribute variant of that and errors on the restrict qual.
So, to fix both PR c/123882 and other unknown regressions caused by
PR c/101312 I'm reverting it now.
testsuite: lto: transform gcc-ar to include prefix
When the the gcc binary is named arm-none-eabi-gcc, the gcc-ar binary
will be named arm-none-eabi-gcc-ar. The current approach works fine as
long as the binary does not contain any prefix, but if it does, the
gcc-ar binary will not be found.
Richard Biener [Thu, 5 Feb 2026 11:26:18 +0000 (12:26 +0100)]
tree-optimization/123986 - upon SLP analysis rollback, release data
The following makes sure to release any SLP kind specific data when
rolling back earlier successful analysis. This avoids crashing
when re-analyzing such node via another graph entry.
PR tree-optimization/123986
* tree-vect-slp.cc (vect_slp_analyze_operations): When
rolling back analyzed nodes, release node specific data
and reset SLP_TREE_TYPE.
compare-elim: arm: enable compare-elimination on Arm [PR123604]
The Arm port has never had the compare elimination pass enabled by
adding a definition of TARGET_FLAGS_REGNUM. But just adding this is
insufficient because the target uses COND_EXEC and compare-elim is not
yet set up to handle this.
This seems to be quite simple, since we just need to recognize
COND_EXEC in insns when scanning for uses of the condition code
register.
This is a partial mitigation for the code quality regression
reported in PR target/123604.
Jakub Jelinek [Thu, 5 Feb 2026 12:39:42 +0000 (13:39 +0100)]
ranger: Fix up WIDEN_MULT_EXPR handling in the ranger [PR123978]
In r13-6617 WIDEN_MULT_EXPR support has been added to the ranger, though
I guess until we started to use ranger during expansion in r16-1398
it wasn't really used much because vrp2 happens before widen_mul.
WIDEN_MULT_EXPR is documented to be
/* Widening multiplication.
The two arguments are of type t1 and t2, both integral types that
have the same precision, but possibly different signedness.
The result is of integral type t3, such that t3 is at least twice
the size of t1/t2. WIDEN_MULT_EXPR is equivalent to first widening
(promoting) the arguments from type t1 to type t3, and from t2 to
type t3 and then multiplying them. */
and IMHO ranger should follow that description, so not relying on
the precisions to be exactly 2x but >= 2x. More importantly, I don't
see convert_mult_to_widen actually ever testing TYPE_UNSIGNED on the
result, why would it when the actual RTL optabs don't care about that,
in RTL the signs are relevant just whether it is smul_widen, umul_widen
or usmul_widen. Though on GIMPLE whether the result is signed or unsigned
is important, for value rangers it is essential (in addition to whether the
result type is wrapping or undefined overflow). Unfortunately the ranger
doesn't tell wi_fold about the signs of the operands and wide_int can be
both signed and unsigned, all it knows is the precision of the operands,
so r13-6617 handled it by introducing two variants (alternate codes for
WIDEN_MULT_EXPR). One was assuming first operand is signed, the other
the first operand is unsigned and both were assuming that the second operand
has the same sign as the result and that result has exactly 2x precision
of the arguments. That is clearly wrong, on the following testcase
we have u w* u -> s stmt and ranger incorrectly concluded that the result
has [0, 0] range because the operands were [0, 0xffffffff] and
[0, -1] (both had actually [0, 0xffffffff] range, but as it used sign
extension rather than zero extension for the latter given the signed result,
it got it wrong). And when we see [0, 0] range for memset length argument,
we just optimize it away completely at expansion time, which is wrong for
the testcase where it can be arbitrary long long int [0, 0xffffffff]
* long long int [0, 0xffffffff], so because of signed overflow I believe
the right range is long long int [0, 0x7fffffffffffffff], as going above
that would be UB and both operands are non-negative.
The following patch fixes it by not having 2 magic ops for WIDEN_MULT_EXPR,
but 3, one roughly corresponding to smul_widen, one to umul_widen and
one to usmul_widen (though confusingly with sumul order of operands).
The first one handles s w* s -> {u,s}, the second one u w* u -> {u,s}
and the last one s w* u -> {u,s} with u w* s -> {u,s} handled by swapping
the operands as before. Also, in all cases it uses TYPE_PRECISION (type)
as the precision to extend to, because that is the precision in which
the actual multiplication is performed, the operation as described is
(type) op1 * (type) op2.
Note, r13-6617 also added OP_WIDEN_PLUS_{SIGNED,UNSIGNED} and handlers
for that, but it doesn't seem to be wired up in any way, so I think it
is dead code:
|git grep OP_WIDEN_PLUS_ .
|ChangeLog-2023: (OP_WIDEN_PLUS_SIGNED): New.
|ChangeLog-2023: (OP_WIDEN_PLUS_UNSIGNED): New.
|range-op.cc: set (OP_WIDEN_PLUS_SIGNED, op_widen_plus_signed);
|range-op.cc: set (OP_WIDEN_PLUS_UNSIGNED, op_widen_plus_unsigned);
|range-op.h:#define OP_WIDEN_PLUS_SIGNED ((unsigned) MAX_TREE_CODES + 2)
|range-op.h:#define OP_WIDEN_PLUS_UNSIGNED ((unsigned) MAX_TREE_CODES + 3)
My understanding is that it is misnamed attempt to implement WIDEN_SUM_EXPR
handling but one that wasn't hooked up in maybe_non_standard.
I wonder if we shouldn't keep it as is for GCC 16, rename to OP_WIDEN_SUM_*
in stage1, hook it up in maybe_non_standard (in this case 2 ops are
sufficient, the description is
/* Widening summation.
The first argument is of type t1.
The second argument is of type t2, such that t2 is at least twice
the size of t1. The type of the entire expression is also t2.
WIDEN_SUM_EXPR is equivalent to first widening (promoting)
the first argument from type t1 to type t2, and then summing it
with the second argument. */
and so we know second argument has the same type as the result, so all
we need to encode is the sign of the first argument.
And the ops should be both renamed and fixed, instead of
wi::overflow_type ov_lb, ov_ub;
signop s = TYPE_SIGN (type);
r = int_range<2> (type, new_lb, new_ub);
I'd go for
wide_int lh_wlb = wide_int::from (lh_lb, TYPE_PRECISION (type), SIGNED);
wide_int lh_wub = wide_int::from (lh_ub, TYPE_PRECISION (type), SIGNED);
return op_plus.wi_fold (r, type, lh_wlb, lh_wub, rh_lb, rh_ub);
(and similarly for the unsigned case with s/SIGNED/UNSIGNED/g).
Reasons: the precision again needs to be widen to type's precision, there
is no point to widen the second operand as it is already supposed to have
the right precision and operator_plus actually ends with
value_range_with_overflow (r, type, new_lb, new_ub, ov_lb, ov_ub);
to handle the overflows etc., r = int_range<2> (type, new_lb, new_ub);
won't do it.
2026-02-04 Jakub Jelinek <jakub@redhat.com>
PR middle-end/123978
* range-op.h (OP_WIDEN_MULT_SIGNED_UNSIGNED): Define.
(OP_WIDEN_PLUS_SIGNED, OP_WIDEN_PLUS_UNSIGNED,
RANGE_OP_TABLE_SIZE): Renumber.
* gimple-range-op.cc (imple_range_op_handler::maybe_non_standard):
Use 3 different classes instead of 2 for WIDEN_MULT_EXPR, one
for both operands signed, one for both operands unsigned and
one for operands with different signedness. In the last case
canonicalize to first operand signed second unsigned.
* range-op.cc (operator_widen_mult_signed::wi_fold): Use
TYPE_PRECISION (type) rather than wi::get_precision (whatever) * 2,
use SIGNED for all wide_int::from calls.
(operator_widen_mult_unsigned::wi_fold): Similarly but use UNSIGNED
for all wide_int::from calls.
(class operator_widen_mult_signed_unsigned): New type.
(operator_widen_mult_signed_unsigned::wi_fold): Define.
Jonathan Wakely [Wed, 4 Feb 2026 22:57:34 +0000 (22:57 +0000)]
libstdc++: Fix std::shared_ptr pretty printer for GDB 11
This pretty printer was updated for GCC 16 to match a change to
std::atomic<shared_ptr<T>>. But the gdb.Type.is_scalar property was
added in GDB 12.1, so we get an error for older GDB versions.
This adds a workaround for older GDB versions. The gdb.Type.tag property
is None for scalar types, and should always be defined for the
std::atomic class template. Another option would be to use the
is_specialization_of function defined in printers.py, but just checking
for the tag is simpler.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (SharedPointerPrinter): Only
use gdb.Type.is_scalar if supported.
* testsuite/libstdc++-prettyprinters/compat.cc: Test printer for
old implementation of std::atomic<std::shared_ptr<T>>.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jan Hubicka [Thu, 5 Feb 2026 11:30:50 +0000 (12:30 +0100)]
Fix speculative devirtualization ICE
this patch fixes cgraph verifier ICE about missing indirect call in the
speculative call sequence. This is triggered when tree-inline manages to
devirtualize call during folding it does and the call has multiple specualtive
targets. cgraph_update_edges_for_call_stmt_node calls
cgraph_edge::resolve_speculation which resolves one edge, but it should make
the whole sequence direct which is done by cgraph_edge::make_direct.
The code was also handling the case that call changed but it is not direct.
This should be impossible (and would require similar updating) so I added unreachable.
Bootstrapped/regtested x86_64-linux and also tested with autofdo and spec2017.
gcc/ChangeLog:
PR ipa/123226
* cgraph.cc (cgraph_update_edges_for_call_stmt_node): Fix handling
of multi-target speculations resolved at clone materialization time
xiezhiheng [Wed, 14 Jan 2026 02:07:22 +0000 (10:07 +0800)]
aarch64: Add support for Hisilicon's hip12 core (-mcpu=hip12)
This patch adds initial support for Hisilicon's hip12 core
(Kunpeng 950 processor).
For more information, see:
https://www.huawei.com/en/news/2025/9/hc-xu-keynote-speech
Bootstrapped and tested on aarch64-linux-gnu, no regression.
Robin Dapp [Wed, 4 Feb 2026 20:20:22 +0000 (21:20 +0100)]
RISC-V: Fix xtheadvector ratio attribute. [PR123870]
As reported in PR123870 we miscompile an RVV-optimized jpeg-quantsmooth
with xtheadvector. The core issue is that we forget to emit a vsetvl
before a -fschedule-insn induced spill restore. Spills are usually
handled by full-register loads and stores but xtheadvector doesn't have
those. Instead, the regular loads and stores are used which differ from
full-register loads/store in the fact that they don't encode the LMUL
in the instruction directly and thus require a proper SEW and LMUL in
the vtype rather than just the ratio.
This patch makes vlds have an SEW/LMUL demand instead of a "ratio only"
demand for theadvector.
I didn't manage to come up with a simple test case, though.
PR123969 has a test but it won't fail without slight changes to the
16 codebase. I'm still adding it for documentation and backport
reasons.
Regtested on rv64gcv_zvl512b.
PR target/123870
PR target/123969
gcc/ChangeLog:
* config/riscv/vector.md: Add vlds to "no ratio" for
theadvector.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/xtheadvector/pr123969.c: New test.
Signed-off-by: Robin Dapp <rdapp@oss.qualcomm.com>
Robin Dapp [Wed, 4 Feb 2026 11:51:36 +0000 (12:51 +0100)]
RISC-V: Allow vector modes for xtheadvector. [PR123971]
In riscv_vector_mode_supported_any_target_p we disallow any vector mode
when TARGET_XTHEADVECTOR.
Things go wrong when we check if a permutation for a mode is supported
by just looking at the optab (e.g. in forwprop). Then later we try to
expand that permutation but cannot find a related int vector mode because
we don't allow any vector mode.
Strictly speaking, this is fallout from the simplify_vector_constructor
changes but it's still a target issue as the common code has done the
proper check and we don't live up to the promise of being able to extend
a certain mode.
This patch just allows all modes in
riscv_vector_mode_supported_any_target_p, even for theadvector.
Robin Dapp [Mon, 2 Feb 2026 20:48:05 +0000 (21:48 +0100)]
forwprop: Handle nop-conversion for maybe_ident. [PR123925]
The same handling for nop conversions we did in the !maybe_ident case is
also necessary in for maybe_ident. This patch performs the necessary
preprocessing before the if and unifies the nop-conversion handling.
PR tree-optimization/123925
gcc/ChangeLog:
* tree-ssa-forwprop.cc (simplify_vector_constructor):
Add nop-conversion handling for maybe_ident.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr123925.c: New test.
Signed-off-by: Robin Dapp <rdapp@oss.qualcomm.com>
Robin Dapp [Mon, 2 Feb 2026 09:28:08 +0000 (10:28 +0100)]
RISC-V: Disable small memsets for xtheadvector [PR123910].
This patch disables memsets with size less than a vector for
xtheadvector. As xtheadvector does not support fractional
LMUL we need to ensure to not emit those vectors that might
use it.
a68: make SET, CLEAR and TEST bits operators zero-based
After some discussion at the working group we have decided that the
bits operators SET, CLEAR and TEST, which are a GNU extension, shall
get bit numbers which are zero-based rather than one-based.
Signed-off-by: Jose E. Marchesi <jemarch@gnu.org>
gcc/algol68/ChangeLog
* a68-low-bits.cc (a68_bits_set): Make bit number zero-based rathe
than one-based.
(a68_bits_clear): Likewise.
(a68_bits_test): Likewise.
* ga68.texi (Extended bits operators): Adapt documentation
accordingly.
gcc/testsuite/ChangeLog
* algol68/execute/bits-clear-1.a68: Adapt test to new CLEAR
semantics.
* algol68/execute/bits-set-1.a68: Likewise for SET.
* algol68/execute/bits-test-1.a68: Likewise for TEST.
With commit r16-5947-ga6c50ec2c6ebcbda2b032eee0552a6a486355e12
"Add -ffuse-ops-with-volatile-access", GCC/nvptx avoids use of intermediate
registers in applicable cases (nice!). This causes one test suite regression:
PASS: gcc.target/nvptx/alloca-5.c (test for excess errors)
XFAIL: gcc.target/nvptx/alloca-5.c execution test
[-PASS:-]{+FAIL:+} gcc.target/nvptx/alloca-5.c check-function-bodies f
PASS: gcc.target/nvptx/alloca-5.c check-function-bodies g
Adjust the FAILing 'check-function-bodies' as per the improved code generation.
Richard Biener [Tue, 3 Feb 2026 11:18:56 +0000 (12:18 +0100)]
tree-optimization/121726 - TBAA bug with SRA of address-taken decls
The following fixes re-materialization of aggregates before calls
that take the address of a scalarized decl. The issue here is that
we do not know the appropriate effective type to use for the stores.
So we use ref-all accesses for the re-materialization to properly
support TBAA info modref might have recorded. The same holds
true for the re-load after the call.
PR tree-optimization/121726
* tree-sra.cc (build_ref_for_offset): Add force_ref_all
parameter and use ptr_type_node as alias pointer type in
that case.
(build_ref_for_model): Add force_ref_all parameter and
pass it through, forcing build_ref_for_offset.
(generate_subtree_copies): Likewise.
(sra_modify_call_arg): Force ref-all accesses.
Tamar Christina [Thu, 5 Feb 2026 08:07:33 +0000 (08:07 +0000)]
middle-end: use inner variable when determining deferred FMA order [PR123898]
If we defer an FMA creation the code tries to determine the order of the
operands before deferring. To do this it compares the operands against the
result expression (which should contain the multiplication expression).
However the multiply might be wrapped in a conversion. This change has us strip
one level of conversion (the most that convert_mult_to_fma) supports handling
and only then do the comparison.
We cannot strip ops[0] and ops[1] and store them stripped since after the
deferrence, if we create an FMA we need to know the original types and
convert_mult_to_fma handles the conversions during FMA creation anyway.
There's probably a similar helper to strip_nop_view_converts but I couldn't
find one, since many of the stripping helpers are recursive or don't support
stripping VIEW_CONVERTS.
gcc/ChangeLog:
PR tree-optimization/123898
* tree-ssa-math-opts.cc (strip_nop_view_converts): New.
(convert_mult_to_fma): Use it.
gcc/testsuite/ChangeLog:
PR tree-optimization/123898
* gcc.target/aarch64/sve/pr123898.c: New test.
Alexandre Oliva [Thu, 5 Feb 2026 02:53:11 +0000 (23:53 -0300)]
testsuite: aarch64: state pr123775.c requirements
The execution testcase requires sve2 and 128-bit sve hardware, but it
doesn't state those requiremnets. I'm think the latter is implied by
the former, but I'm not entirely sure, so I'm requiring both
explicitly.
for gcc/testsuite/ChangeLog
PR middle-end/123775
* gcc.target/aarch64/sve2/pr123775.c: Add sve128 and sve2 hw
requirements.
Alexandre Oliva [Thu, 5 Feb 2026 02:48:55 +0000 (23:48 -0300)]
simplify-rtx: fix riscv redundant-bitmap-2.C
The insn simplification expected by the test, to get a bset
instruction, has been prevented since r15-9239, because we get rotates
for bit clear and shifts for bit flip, and we don't know how to
simplify those.
Teach the rtl simplifier, at the spots where it had been extended to
handle these logical simplifications, to also handle these less
obvious negations.
for gcc/ChangeLog
* simplify-rtx.cc (negated_ops_p): New.
(simplify_context::simplify_binary_operation_1): Use it.
Pan Li [Wed, 4 Feb 2026 04:55:28 +0000 (12:55 +0800)]
RISC-V: Introduce vr2fpr-cost= for customizing the cost when vr2fpr
Similar to vr2gpr-cost=, add the one for fpr as well.
PR/target 123916
gcc/ChangeLog:
* config/riscv/riscv-opts.h (VR2FPR_COST_UNPROVIDED): Add new
sentinel for unprovided cost.
* config/riscv/riscv-protos.h (get_vr2fr_cost): Add new func
decl.
* config/riscv/riscv-vector-costs.cc (costs::adjust_stmt_cost):
Leverage new func to get cost of vr2fpr.
* config/riscv/riscv.cc (riscv_register_move_cost): Ditto.
(get_vr2fr_cost): Add new func to wrap access to the cost
of the vr2fpr.
* config/riscv/riscv.opt: Add new param vr2fpr-cost.
Pan Li [Wed, 4 Feb 2026 02:13:38 +0000 (10:13 +0800)]
RISC-V: Introduce vr2gpr-cost= for customizing the cost when vr2gpr
The middle-end pass NULL_TREE in previous, and then skip the
adjust_stmt_cost step which has count the cost of vr2gpr.
After Richard introduced more like slp_node with its vectype for
recording the cost, the adjust_stmt_cost will be hit and plus
the cost of vr2gpr now.
And then fail to vectorize due to cost value of vr2gpr is counted.
This PATCH would like to introduce another param named vr2gpr-cost,
to allow the cmdline provide the cost value of vr2gpr. Then we can
leverage the this param to make the failed test happy.
For further enhancement of the cost value customization, we would
like to defer to next stage-1, aka GCC-17.
PR/target 123916
gcc/ChangeLog:
* config/riscv/riscv-opts.h (GPR2VR_COST_UNPROVIDED): Depend on
default unprovided value.
(FPR2VR_COST_UNPROVIDED): Ditto.
(VR2GPR_COST_UNPROVIDED): Ditto.
(COST_UNPROVIDED): Add new default unprovided value.
* config/riscv/riscv-protos.h (get_vr2gr_cost): Add new func
decl.
* config/riscv/riscv-vector-costs.cc (costs::adjust_stmt_cost):
Leverage new func to get cost of vr2gpr.
* config/riscv/riscv.cc (riscv_register_move_cost): Ditto.
(get_vr2gr_cost): Add new func to wrap access to the cost
of the vr2gpr.
* config/riscv/riscv.opt: Add new param vr2gpr-cost.
Remaining to do:
* Add new declarations in debug headers too.
Implement C++23 P2077R3 "Heterogeneous erasure overloads for
associative containers". Adds template overloads for members
erase and extract to address elements using an alternative key
type, such as string_view for a container of strings, without
need to construct an actual key object.
The new overloads enforce concept __heterogeneous_tree_key or
__heterogeneous_hash_key to verify the function objects provided
meet requirements, and that the key supplied is not an iterator
or the native key.
libstdc++-v3/ChangeLog:
PR libstdc++/117404
* include/bits/version.def (associative_heterogeneous_erasure):
Define.
* include/bits/version.h: Regenerate.
* include/std/map: Request new feature from version.h.
* include/std/set: Same.
* include/std/unordered_map: Same.
* include/std/unordered_set: Same.
* include/bits/stl_map.h (extract, erase): Define overloads.
* include/bits/stl_set.h: Same.
* include/bits/stl_multimap.h: Same.
* include/bits/stl_multiset.h: Same.
* include/bits/unordered_map.h: Same, 2x.
* include/bits/unordered_set.h: Same, 2x.
* include/bits/stl_function.h (concepts __not_container_iterator,
__heterogeneous_key): Define.
* include/bits/hashtable.h (_M_find_before_node, _M_locate, extract):
Delegate to more-general _tr version.
(_M_find_before_node_tr, _M_locate_tr, _M_extract_tr, _M_erase_tr):
Add new members to support a heterogeneous key argument.
(_M_erase_some): Add new helper function.
(concept __heterogeneous_hash_key): Define.
* include/bits/stl_tree.h (_M_lower_bound_tr, _M_upper_bound_tr,
_M_erase_tr, _M_extract_tr): Add new members to support a
heterogeneous key argument.
(concept __heterogeneous_tree_key): Define.
* testsuite/23_containers/map/modifiers/hetero/erase.cc: New test.
* testsuite/23_containers/multimap/modifiers/hetero/erase.cc: Same.
* testsuite/23_containers/multiset/modifiers/hetero/erase.cc: Same.
* testsuite/23_containers/set/modifiers/hetero/erase.cc: Same.
* testsuite/23_containers/unordered_map/modifiers/hetero/erase.cc: Same.
* testsuite/23_containers/unordered_multimap/modifiers/hetero/erase.cc:
Same.
* testsuite/23_containers/unordered_multiset/modifiers/hetero/erase.cc:
Same.
* testsuite/23_containers/unordered_set/modifiers/hetero/erase.cc: Same.
LRA rarely splits hard reg live ranges to assign regs to pseudos when
other possibility to allocate regs failed. During the pseudo
assignment LRA updates hard reg preferences of pseudos connected to
given pseudo through copies. For this LRA uses array
update_hard_regno_preference_check which was not allocated during hard
reg live range splitting. The patch fixes the bug by allocation of
the array during hard reg live range splitting.
gcc/ChangeLog:
PR rtl-optimization/123922
* lra-assigns.cc (lra_split_hard_reg_for): Allocate and free
update_hard_regno_preference_check. Clear non_reload_pseudos for
successful spilling too.
Andrew Pinski [Wed, 4 Feb 2026 03:20:48 +0000 (19:20 -0800)]
complex: Directly emit gimple from extract_component [PR121661]
Currently extract_component uses force_gimple_operand_gsi to emit
gimple including loads. The problem with that decls that have
DECL_EXPR_DECL set on it will change over to use the DECL_EXPR_DECL instead.
Normally this is ok except for nested functions where the original decl
is a PARAM_DECL, there is a copy from the param decl to the new frame based
location.
Well instead we should just create the gimple ourselves.
The only special case that needs to be handled is BIT_FIELD_REF and
a VCE of SSA_NAME. BIT_FIELD_REF was already handled specially
so we can just emit the load there. VCE of SSA_NAME on the other
hand needed some extra code.
Note VCE of s SSA_NAME case could be optimized, I filed PR 123968
for that. Since that is not a regression at this point and we are
now producing the same code as before.
Bootstrapped and tested on x86_64-linux-gnu.
PR middle-end/121661
gcc/ChangeLog:
* tree-complex.cc (extract_component): Create gimple
assign statements directly rather than call force_gimple_operand_gsi.
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr121661-1.c: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
OpenMP/Fortran: Fix present modifier in map clauses for allocatables
The OpenMP 6.0 spec reads (Section 7.9.6 "map Clause"):
"Unless otherwise specified, if a list item is a referencing variable then the
effect of the map clause is applied to its referring pointer and, if a
referenced pointee exists, its referenced pointee."
In other words, the map clause (and its modifiers) applies to the array
descriptor (unconditionally), and also to the array data if it is allocated.
Without this patch, the semantics enforced in libgomp is incorrect: an
allocatable is deemed present only if it is allocated. Correct semantics: an
allocatable is in the present table as long as its descriptor is mapped, even if
no data exists.
libgomp/ChangeLog:
* target.c (gomp_present_fatal): New function.
(gomp_map_vars_internal): For a Fortran allocatable array, present
causes runtime termination only if the descriptor is not mapped.
(gomp_update): Call gomp_present_fatal.
* testsuite/libgomp.fortran/map-alloc-present-1.f90: New test.
I made a pass through the parameter documentation to fix various
issues with grammar, markup, punctuation, capitalization, inconsistent
use of terminology, and so on. I'm sure there's still room for improvement
but this is at least a step in the right direction.
As internal documentation, the parameter descriptions naturally
contain a lot of jargon and abbreviations for compiler passes. This
patch does not attempt to fix that. Probably a more critical area for
future improvement is making it more obvious what pass or part of the
compiler each parameter controls and perhaps adding some additional
subsectioning to group them.
gcc/ChangeLog
PR translation/89915
* doc/params.texi: Copy-edit text throughout the file.
* params.opt: Likewise in documentation strings.
doc: Remove references to parameters in user documentation [PR123245] [PR89915]
We shouldn't point users at specific parameters that control GCC
behavior since those are explicitly internal GCC interfaces subject to
incompatible changes or removal. This patch removes all such
references in the GCC user manual, either by replacing them with more
user-centric language, vague references to parameters generally, or
just removing the text as being unhelpful.
gcc/ChangeLog
PR target/123245
PR translation/89915
* doc/invoke.texi (Warning Options): Remove discussion of parameters
from -Winterference-size documentation.
(Static Analyzer Options): Ditto for -Wanalyzer-symbol-too-complex,
the list of things the analyzer has specific knowledge of, and
-fanalyzer-call-summaries.
(Optimize Options): Ditto for -finline-limit and fipa-cp-clone.
(Instrumentation Options): Likewise for -fsanitize=kernel-hwaddress
and -fharden-control-flow-redundancy.
(C++ Compiled Module Interface): Likewise for discussion of limits
on number of open files.
doc: Move parameter docs to the GCC internals manual [PR123245] [PR89915]
There appears to be some consensus that parameter documentation should
be moved from the GCC user manual to the internals manual. Aside from
the explicit disclaimer that parameters are implementation details and
subject to change, many of them are documented in pure "implementor-speak"
using jargon that users are unlikely to be familiar with.
This patch moves the documentation more or less as-is. I added some
sectioning and a new index to make things easier to find, but I did
not modify the parameter descriptions to correct even obvious grammar
and markup issues. That will be addressed in a subsequent patch.
There are several places in the user manual that make dangling
reference to parameters controlling the behavior of user-visible
options, in spite of the caveats elsewhere that parameters are
internal and can't be relied on. There's also a separate patch for this.
gcc/ChangeLog
PR target/123245
PR translation/89915
* Makefile.in (TEXI_GCCINT_FILES): Add params.texi.
* doc/gccint.texi (pa): New index.
(Top): Add new Parameters and Parameters Index nodes to menu.
Include params.texi.
(Parameter Index): New.
* doc/invoke.texi (Option Summary): Move --param from Optimization
Options to Developer Options.
(Optimization Options): Move parameter documentation to params.texi.
(Developer Options): Add abbreviated discussion of --param here.
(LoongArch Options): Move parameter documentation to params.texi.
(RISC-V Options): Likewise.
(RS/6000 and PowerPC Options): Likewise.
* doc/params.texi: New file.
Yangyu Chen [Wed, 4 Feb 2026 14:48:17 +0000 (07:48 -0700)]
[PATCH] RISC-V: fix nullptr dereference in parse_arch
When parsing target attributes, if an invalid architecture string is
provided, the function parse_single_ext may return nullptr. The existing
code does not check for this case, leading to a nullptr dereference when
attempting to access the returned pointer. This patch adds a check to
ensure that the returned pointer is not nullptr before dereferencing it.
If it is nullptr, an appropriate error message is generated.
Jakub Jelinek [Wed, 4 Feb 2026 11:30:42 +0000 (12:30 +0100)]
c++: Fix up eval_parameters_of for function types [PR123913]
eval_parameters_of was trying to share 3 lines of code between the
function declaration and function type cases, but got it wrong in
multiple ways for the latter. One thing is that we should override
reflect_kind only for the function decl case to REFLECT_PARM, there
we need to differentiate function parameter reflection vs. variable
reflection, for function type it is just type. Another one is that
we iterate over PARM_DECLs through DECL_CHAIN in the function decl
case, but for types we iterate over the TREE_LIST nodes and the
type is only TREE_VALUE of that.
And last, but am not sure about that, maybe
https://eel.is/c++draft/meta.reflection#queries-62.2 should be clarified,
I think we want to apply dealias. We have notes like
https://eel.is/c++draft/meta.reflection#queries-note-7
https://eel.is/c++draft/meta.reflection#traits-5
but those don't apply to type_of or parameters_of. And I think there was
an agreement that meta fns which return reflection of a type don't return
type aliases, but can't see it written explicitly except for the traits.
2026-02-04 Jakub Jelinek <jakub@redhat.com>
PR c++/123913
PR c++/123964
* reflect.cc (eval_parameters_of): Fix up handling of function
types.
Jakub Jelinek [Wed, 4 Feb 2026 11:29:24 +0000 (12:29 +0100)]
c++: Perform the iterating expansion stmt N evaluation in immediate context [PR123611]
For the N evaluation for iterating expansion stmts where the standard says
to evaluate:
[] consteval {
std::ptrdiff_t result = 0;
for (auto i = begin; i != end; ++i) ++result;
return result; // distance from begin to end
}()
right now (subject to further changes in CWG3140) I wanted to save compile
time/memory and effort to actually construct the lambda and it is evaluated
just using TARGET_EXPRs. On the following testcase it makes a difference,
when the lambda is consteval, the expressions inside of it are evaluated
in immediate context and so the testcase should be accepted, but we
currently reject it when i has consteval-only type and expansion stmt
doesn't appear in an immediate or immediate-escalating function.
The following patch fixes this by forcing in_immediate_context () to be true
around the evaluation.
2026-02-04 Jakub Jelinek <jakub@redhat.com>
PR c++/123611
* pt.cc (finish_expansion_stmt): Temporarily enable
in_immediate_context () for the iterating expansion stmt N
computation.
Jakub Jelinek [Wed, 4 Feb 2026 10:49:01 +0000 (11:49 +0100)]
toplevel: Build stage1/stage2/stageprofile libstdc++ with --disable-libstdcxx-pch when bootstrapping
The following patch saves ~ 2.4GiB of disk space in x86_64-linux
bootstrapped object directory:
find obj80 -name \*.gch -a -type f | xargs du -shc | grep total
3.7G total
find obj82 -name \*.gch -a -type f | xargs du -shc | grep total
1.3G total
and ~ 800MiB for i686-linux:
find obj81 -name \*.gch -a -type f | xargs du -shc | grep total
1.2G total
find obj83 -name \*.gch -a -type f | xargs du -shc | grep total
409M total
by disabling PCH in stage1/stage2/stageprofile builds, so only
building it in stage3/stagefeedback etc.
I think in stage1/stage2 it is a pure waste of bootstrap time and disk
space, for profiledbootstrap I'd say PCH isn't used commonly enough
in the wild that it is worth training GCC on that (but if you disagree,
I can surely take out that single line in there).
Jakub Jelinek [Wed, 4 Feb 2026 10:36:08 +0000 (11:36 +0100)]
tree: Fix up wrong-code with certain C++ default arguments [PR123818]
The following testcase is miscompiled since r0-69852-g4038c495f (at least
if one can somehow arrange in C++98 to have AGGR_INIT_EXPR or any other
FE specific trees nested in constructor elts for CONSTRUCTOR nested inside
of default argument, if not, then since C++11 support that allows that has
been implemented).
The problem is that we unfortunately store default arguments in TREE_PURPOSE
of TYPE_ARG_TYPES nodes of the FUNCTION/METHOD_TYPE and those are shared,
with type_hash_canon used to unify them. The default arguments aren't
considered in type_hash_canon_hash at all, but the equality hook considers
them in type_list_equal by calling simple_cst_equal on those default
arguments. That function is a tri-state, returns 0 for surely unequal,
1 for equal and -1 for "I don't know", usually because there are FE trees
etc. (though, admittedly it is unclear why such distinction is done, as
e.g. for VAR_DECLs etc. it sees in there it returns 0 rather than -1).
Anyway, the r0-69852-g4038c495f change changed CONSTRUCTOR_ELTS from
I think a tree list of elements to a vector and changed the simple_cst_equal
implementation of CONSTRUCTOR from just recursing on CONSTRUCTOR_ELTS (which
I think would just return -1 because I don't see simple_cst_equal having
TREE_LIST nor TREE_VEC handling) to something that thinks simple_cst_equal
returns a bool rather than tri-state, plus has a comment whether it should
handle indexes too.
So, in particular on the testcase which has in default arguments with
CONSTRUCTOR inside it with AGGR_INIT_EXPR as the single element (but
could be as well in multiple elements), the recursive call returns -1
for "I don't know" on the element and the function considers it the same
as if it returned 1, they are equal.
The following patch fixes it by calling the recursive non tail-recursive
simple_cst_equal calls like everywhere else in the function, by returning
what it returned if it returned <= 0 and otherwise continuing.
Plus given the comment I've also implemented checking the index.
The special case for FIELD_DECL is so that if both indexes are FIELD_DECLs
and they are different, we don't return -1 but 0.
2026-02-04 Jakub Jelinek <jakub@redhat.com>
PR c++/123818
* tree.cc (simple_cst_equal) <case CONSTRUCTOR>: Return -1 if some
recursive call returns -1. Also compare indexes.
Jakub Jelinek [Wed, 4 Feb 2026 10:25:01 +0000 (11:25 +0100)]
bitint: Don't try to extend PHI in the min_prec == prec case [PR122689]
The following testcase is miscompiled on aarch64-linux, the problem is that
the PHI argument is lowered to
VIEW_CONVERT_EXPR<unsigned long[196]>(y) = VIEW_CONVERT_EXPR<unsigned long[196]>(*.LC0);
MEM <unsigned long[1]> [(unsigned _BitInt(12419) *)&y + 1568B] = {};
on the edge, where for aarch64 unsigned _BitInt(12419) the size of the type
is already 1568 bytes (aka 196 DImode limbs, 98 TImode ABI limbs), so the
fir stmt copies everything and the second stmt clobbers random unrelated memory
after it.
Usually when min_prec == prec (otherwise we guarantee that min_prec is either 0,
or a single limb (which doesn't have padding bits) or something without any
padding bits (multiple of abi_limb_prec)) we take the
if (c)
{
if (VAR_P (v1) && min_prec == prec)
{
tree v2 = build1 (VIEW_CONVERT_EXPR,
TREE_TYPE (v1), c);
g = gimple_build_assign (v1, v2);
gsi_insert_on_edge (e, g);
edge_insertions = true;
break;
}
path and need nothing else, but in this case v1 is a PARM_DECL, so we need to
take the code path with VCE on the lhs side as well. But after the assignment
we fall through into the handling of the extension, but for min_prec == prec
that isn't needed and is actually harmful, we've already copied everything
and the code later on assumes there are no padding bits and uses just
TYPE_SIZE_UNIT.
So, this patch just avoids the rest after we've copied all the bits for
min_prec == prec.
2026-02-04 Jakub Jelinek <jakub@redhat.com>
PR middle-end/122689
* gimple-lower-bitint.cc (gimple_lower_bitint): For the PHI handling
if min_prec == prec, break after emitting assignment from c.
Prachi Godbole [Wed, 4 Feb 2026 07:23:10 +0000 (23:23 -0800)]
ipa-reorder-for-locality - Adjust bootstrap-lto-locality and param to reduce compile time
This patch turns off -fipa-reorder-for-locality for -fprofile-generate because
it's not required and contributes to the bloated time taken by bootstrap. It
also reduces the default partition size by half; the increased number of
partitions speeds up LTRANS phase.
Bootstrapped and tested on aarch64-none-linux-gnu. OK for mainline?
David Malcolm [Tue, 3 Feb 2026 23:52:35 +0000 (18:52 -0500)]
analyzer: fix ICE on pointer offsets [PR116865]
gcc/analyzer/ChangeLog:
PR analyzer/116865
* region-model-manager.cc
(region_model_manager::get_offset_region): Use POINTER_PLUS_EXPR
rather than PLUS_EXPR for pointer offsets.
gcc/testsuite/ChangeLog:
PR analyzer/116865
* c-c++-common/analyzer/ice-pr116865.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
projects / thirdparty / gcc.git / log
