Philipp Tomsich [Mon, 23 Feb 2026 19:22:03 +0000 (20:22 +0100)]
fold-mem-offsets: Clarify why do_analysis pre-marks the memory insn
The bitmap_set_bit call before fold_offsets in do_analysis is
intentional: fold_offsets requires all uses of a definition to already
be in can_fold_insns before it will mark the definition as foldable.
Pre-marking the memory instruction (which is the root use) is necessary
for its address definitions to pass this check during the DFS.
Replace the generic comment with one that explains this dependency.
Jonathan Wakely [Wed, 11 Mar 2026 21:22:12 +0000 (21:22 +0000)]
libstdc++: Fix mingw-w64 build due to __max macro
The stdlib.h header on mingw defines a function-like macro called __max,
which causes an error here:
include/format:3785:55: error: macro '__max' requires 2 arguments, but only 1 given
3785 | iter_difference_t<_OutIter> __max(_M_max);
We have lots of existing variables called __max, but this is the only
case that uses direct-initialization and so interferes with the
function-like macro in stdlib.h
The fix applied here is just to rename the variable. We can't use
direct-list-initialization because the conversion from size_t to the
difference type would be narrowing. We prefer not to use
copy-initialization so that conversion to the difference type is
explicit not implicit.
Andrew Pinski [Wed, 11 Mar 2026 21:41:31 +0000 (14:41 -0700)]
symtab: Fix init and fini priority to reset to default [PR120030]
Right now if try to reset the priority of a constructor to the
default (65535), there is an ICE.
To fix this the assert is wrong and intead we should check
if the priority is already the default if not then we should
just update it.
Bootstrapped and tested on x86_64-linux-gnu.
PR middle-end/120030
gcc/ChangeLog:
* symtab.cc (symtab_node::set_init_priority): Better
handle the case of setting the priority back to default.
(cgraph_node::set_fini_priority): Likewise.
gcc/testsuite/ChangeLog:
* gcc.dg/constructor-2.c: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Again while looking into PR 120030, there was no documentation
of what it means to have multiple constructor/destructor attributes
on the same function. Basically the last priority wins.
gcc/ChangeLog:
* doc/extend.texi (constructor/destructor): Add documentation
about multiple attributes here.
Andrew Pinski [Wed, 11 Mar 2026 21:29:20 +0000 (14:29 -0700)]
doc/extend: Document constructor/destructor priority when none is supplied
Noticed while working on PR 120030, the priority/order of constructor/destructor
without an argument is not documented.
This adds that the default priority is 65535 (last in order).
gcc/ChangeLog:
* doc/extend.texi (constructor/destructor): Document
the priority when none is supplied.
Jakub Jelinek [Thu, 12 Mar 2026 08:09:42 +0000 (09:09 +0100)]
openmp, c++: Fix up TREE_TYPE of OMP_TASK
I've made a typo a few years ago and used void_node instead of void_type_node
as TREE_TYPE of OMP_TASK in the taskwait depend case. This got later
on copied also for dispatch.
With reflection this leads to ICEs (but guess except for the testcase
we should also backport it to release branches).
2026-03-12 Jakub Jelinek <jakub@redhat.com>
* parser.cc (cp_parser_omp_taskwait): Set TREE_TYPE of OMP_TASK
to void_type_node rather than void_node.
(cp_parser_omp_dispatch): Likewise.
Jakub Jelinek [Thu, 12 Mar 2026 07:50:35 +0000 (08:50 +0100)]
libstdc++: Use CTAD for span in std::define_static_object [PR124443]
The standard in https://eel.is/c++draft/meta.reflection#meta.define.static-17
uses CTAD for span but we were avoiding that and using span<const _Up>
instead.
2026-03-12 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/124443
* include/std/meta (std::define_static_object): Use CTAD for span.
Jakub Jelinek [Thu, 12 Mar 2026 07:48:47 +0000 (08:48 +0100)]
c++: Support proxy iterators in reflection get_range_elts [PR124425]
I've punted up on proxy iterators because I didn't know how to construct
a test for those.
The following patch adds support for thosse. Besides converting those
to valuet if needed and for classes making sure they live in a TARGET_EXPR
where they can be subsequently destructed, the patch adds
CLEANUP_POINT_EXPRs around the deref and inc expressions such that the
TARGET_EXPRs in those expressions are immediately destructed after returning
what we need.
cmp doesn't need that because
cmp = condition_conversion (cmp);
already adds that.
Without the CLEANUP_POINT_EXPRs stuff is destructed (and marked as if out of
lifetime) only in some CLEANUP_POINT_EXPR surrounding the metafn call, which
is certainly too late for stuff that is reentered and left again in every
iteration.
I wrongly thought I'd need to duplicate the first part of CLEANUP_POINT_EXPR
handling in reflect.cc (which is complicated because struct constexpr_ctx
is only defined in constexpr.cc), then cxx_eval_constant_expression
e.g. deref and then duplicate the second part of CLEANUP_POINT_EXPR
handling, but it seems that the CLEANUP_POINT_EXPR evaluation just returns
what was returned from the recursive call on its operand, which is I think
exactly what we need.
This change broke 2 testcases, reflect_constant_array4.C and
define_static_array4.C, but IMHO correctly so, apparently what I had
there was creating std::pair<const int &, const int &> with references
to something that should have been immediately destructed in each iteration.
So, the patch fixes those tests to use std::pair<int, int> instead.
2026-03-12 Jakub Jelinek <jakub@redhat.com>
PR c++/124425
* reflect.cc (get_range_elts): Handle proxy iterators. Call
fold_build_cleanup_point_expr on both deref and inc.
* g++.dg/reflect/define_static_array4.C: Enable commented out
static_asserts and fix up the first one.
(as_pair): Make sure to return std::pair <int, int>.
* g++.dg/reflect/reflect_constant_array4.C: Enable commented out
static_asserts and fix up the first one.
(as_pair): Make sure to return std::pair <int, int>.
* g++.dg/reflect/reflect_constant_array7.C: New test.
* g++.dg/reflect/reflect_constant_array8.C: New test.
Nathaniel Shead [Wed, 11 Mar 2026 12:21:02 +0000 (23:21 +1100)]
c++/modules: Allow merging members of instantiations attached to named modules [PR124431]
The crash in the linked PR occurs because we treat all entities attached
to a (different) named module as being unmergeable, and so end up with
two different FIELD_DECLs for the member of a type.
But templates can be instantiated or specialised in any module, not just
the module they originated from, but are still considered attached to
that named module. It seems that we already handle class-scope
VAR_DECL, FUNCTION_DECL, TYPE_DECL, and TEMPLATE_DECL correctly by using
a MK_decl_spec or MK_type_spec merge kind, but FIELD_DECLs and
CONST_DECLs are not depended upon separately and so never get
MK_template_mask specs.
For these cases I think we can always rely on the container being
accurate and having its fields already setup, so this patch fixes the
issue by allowing non-unique merge kind for decls with a template
specialisation container of code TYPE_DECL.
PR c++/124431
gcc/cp/ChangeLog:
* module.cc (trees_in::key_mergeable): Allow merging members of
template specialisations.
gcc/testsuite/ChangeLog:
* g++.dg/modules/merge-21_a.C: New test.
* g++.dg/modules/merge-21_b.C: New test.
* g++.dg/modules/merge-21_c.C: New test.
* g++.dg/modules/merge-21_d.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Fortran: Fix ICE after rejected CHARACTER duplicate declaration [PR82721]
When a CHARACTER declaration is rejected because the symbol already has
a different basic type, declaration parsing may already have created a
fresh gfc_charlen node for the rejected entity. reject_statement()
undoes symbol-table changes, but it does not roll back the namespace
charlen list, so the stale len(...) expression can survive and later be
resolved through dangling symtree pointers, causing corrupted
diagnostics or an ICE.
Fix this in build_sym by discarding only the unattached gfc_charlen
node created for the rejected declaration before it is ever attached to
any surviving symbol. Keep shared charlen nodes intact so other
invalid-code diagnostics still see the state they expect. Also add a
regression test that uses MALLOC_PERTURB_ to make the old crash
reproducible.
gcc/fortran/ChangeLog:
PR fortran/82721
* decl.cc (discard_pending_charlen): New helper.
(build_sym): Discard unattached CHARACTER length nodes when
gfc_add_type rejects the declaration.
gcc/testsuite/ChangeLog:
PR fortran/82721
* gfortran.dg/pr82721.f90: New test.
Signed-off-by: Christopher Albert <albert@tugraz.at>
Andrew Pinski [Wed, 11 Mar 2026 05:28:43 +0000 (22:28 -0700)]
riscv/docs: Increment the required binutils to 2.40 [PR124409]
GCC has not able to build with binutils 2.30 due to the requirement
of needing zmull support. This changes the documentation to tbe
first binutils release that supported zmull.
PR target/124409
gcc/ChangeLog:
* doc/install.texi: Increment the required binutils for
riscv to 2.40.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Fortran: Fix ICE on invalid CLASS component in derived type [PR106946]
When a CLASS component declaration inside a derived type has a syntax
error (for example, a missing comma), gfc_build_class_symbol creates a
CLASS container symbol outside the undo mechanism. Error recovery then
frees the referenced type but leaves the CLASS container orphaned with
dangling pointers, leading to an ICE during later resolution.
Fix this by removing CLASS components created during a failed data
declaration from the derived type component chain, deleting their
namespace symtree entries only when they are still present, releasing
the CLASS container symbol, and freeing the component itself. Also
expand the regression coverage to exercise allocatable and pointer CLASS
declarations, including a valid component followed by a bad one.
gcc/fortran/ChangeLog:
PR fortran/106946
* decl.cc (gfc_match_data_decl): Remove CLASS components added by a
failed declaration in a derived type, and guard symtree deletion.
* gfortran.h (gfc_free_component, gfc_delete_symtree): Declare.
* symbol.cc (gfc_free_component): New function.
(free_components): Use it.
(gfc_delete_symtree): Make non-static.
gcc/testsuite/ChangeLog:
PR fortran/106946
* gfortran.dg/pr106946.f90: Cover allocatable and pointer CLASS
declarations, including a valid component followed by a bad one.
Signed-off-by: Christopher Albert <albert@tugraz.at>
David Malcolm [Thu, 12 Mar 2026 00:45:29 +0000 (20:45 -0400)]
analyzer: fix false +ves when testing <stdbool.h>/_Bool values [PR124451]
PR analyzer/124451 reports false positives from -Wanalyzer-malloc-leak
when using inverted "bool" values to track whether an allocation
happened.
The root cause is that with _Bool, the inversion is a bitwise not,
and this leads to the test of the condition against 0 to not be
recognized by malloc_state_machine::on_condition. Hence on_condition
fails to transition the state machine for the pointer from "unchecked"
to "null" or "nonnull", leaving it in the "unchecked" state.
This patch generalizes the folding logic in the analyzer that folds
"!(x CMP y)" => "x !CMP y"
so that it also folds
"~(x CMP y)" => "x !CMP y"
when the bitwise not is on a boolean type, fixing the false positives.
gcc/analyzer/ChangeLog:
PR analyzer/124451
* region-model-manager.cc
(region_model_manager::maybe_invert_comparison_in_unaryop): New,
adapted from...
(region_model_manager::maybe_fold_unaryop): ...here, splitting out
the comparison inversion case for TRUTH_NOT_EXPR. Add a case for
BIT_NOT_EXPR, reusing the inversion logic when dealing with
boolean types.
* region-model-manager.h
(region_model_manager::maybe_invert_comparison_in_unaryop): New decl.
gcc/testsuite/ChangeLog:
PR analyzer/124451
* gcc.dg/analyzer/conditionals-pr124451-_Bool.c: New test.
* gcc.dg/analyzer/conditionals-pr124451-enum.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Thu, 12 Mar 2026 00:45:29 +0000 (20:45 -0400)]
analyzer: fix ICE on computed goto [PR124375]
gcc/analyzer/ChangeLog:
PR analyzer/124375
* ops.cc (ggoto_edge_op::apply_constraints): Ensure that we write
back a rejected_constraint if the edge is infeasible.
* region-model.cc (region_model::add_constraint): Convert
rejected_op_constraint from tree to const svalue *.
(rejected_op_constraint::dump_to_pp): Likewise.
* region-model.h (class rejected_op_constraint): Likewise.
gcc/testsuite/ChangeLog:
PR analyzer/124375
* gcc.dg/analyzer/ice-pr124375-1.c: New test.
* gcc.dg/analyzer/ice-pr124375-2.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Thu, 12 Mar 2026 00:45:29 +0000 (20:45 -0400)]
analyzer: fix ICE on effective modulo by zero [PR124433]
gcc/analyzer/ChangeLog:
PR analyzer/124433
* region-model-manager.cc
(region_model_manager::maybe_fold_binop): When checking for
division by zero, use the value range of the divisor, rather
than merely checking for constant 0.
* region-model.cc (region_model::get_gassign_result): Likewise.
gcc/testsuite/ChangeLog:
PR analyzer/124433
* gcc.dg/analyzer/divide-by-zero-ice-pr124433.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Marek Polacek [Sun, 8 Mar 2026 16:34:30 +0000 (12:34 -0400)]
c++: error routines re-entered with uneval lambda [PR124397]
As discussed in
<https://gcc.gnu.org/pipermail/gcc-patches/2026-March/710075.html>
we shouldn't override complain with tf_warning_or_error when we are
emitting cp_printer diagnostics. We had no way to check that so
this patch adds emitting_diagnostic_p.
PR c++/124397
gcc/cp/ChangeLog:
* pt.cc (tsubst_lambda_expr): Don't override complain when emitting
diagnostics.
fortran: Fix mixed ENTRY union ABI under -ff2c [PR95338]
Mixed ENTRY masters store each result in a shared union. Under -ff2c,
default REAL entries use the C double ABI even though their Fortran result
symbols remain default REAL. Building the union directly from the Fortran
result symbols therefore gives the entry wrapper a real(kind=8) return type
but leaves the master union field at real(kind=4), which later trips the
GIMPLE verifier with a non-trivial conversion in COMPONENT_REF.
Build the mixed ENTRY union fields from the ABI return type instead, so
default REAL entries under -ff2c contribute a real(kind=8) field. Add a
regression test for the original mixed INTEGER/REAL ENTRY reproducer.
gcc/fortran/ChangeLog:
PR fortran/95338
* trans-types.cc (gfc_get_entry_result_type): New helper to use the
ABI return type for mixed ENTRY union fields.
(gfc_get_mixed_entry_union): Use it for each entry result field.
gcc/testsuite/ChangeLog:
PR fortran/95338
* gfortran.dg/pr95338.f90: New test.
Signed-off-by: Christopher Albert <albert@tugraz.at>
Marek Polacek [Mon, 9 Mar 2026 15:40:54 +0000 (11:40 -0400)]
c++: ICE with structured bindings and arrays [PR120285]
In r15-3933 I started using a CONSTRUCTOR to signal direct-init
to build_vec_init rather than a TREE_LIST. That broke
struct S {
int a = 1;
};
void foo() {
S arr[2];
auto [x, y](arr);
}
because we pass that new CONSTRUCTOR not to build_vec_init but to
build_aggr_init which then crashes in digest_init_r because the
new CONSTRUCTOR wasn't reshaped. It should work to reshape it if
its type is CP_AGGREGATE_TYPE_P but it might be safer to resort
back to building up a list if we're not going to go to build_vec_init.
PR c++/120285
gcc/cp/ChangeLog:
* init.cc (build_vec_init): Only build up a CONSTRUCTOR for
arrays, otherwise use a TREE_LIST like prior to r15-3933.
Jakub Jelinek [Wed, 11 Mar 2026 16:28:58 +0000 (17:28 +0100)]
genautomata: Support INSN_UIDs up to INT_MAX-1 [PR124436]
With --param=min-nondebug-insn-uid= parameter one can force really large
INSN_UIDs even in moderately large functions.
Obviously the compiler will break badly if INSN_UID (which is host int)
wraps around, but in dfa_insn_code_enlarge it actually breaks already
when INSN_UID reaches INT_MAX / 2 + 1, because it tries to resize
vector to twice the max INSN_UID and overflows (UB on the compiler side
and then trying to allocate 0xfffffffe00000001-ish bytes).
The following patch fixes it by making sure not to overflow and cap
the allocation size at INT_MAX (that means even maximum INSN_UID INT_MAX
will not work properly, but just reaching that is highly undesirable
anyway). Alternatively dfa_insn_codes_length could be e.g. HOST_WIDE_INT
and we could just use HOST_WIDE_INT_C (2) * uid, but then we'd allocate
parts of vector for something that we really won't use anyway.
Of course, it is really bad idea to use
--param=min-nondebug-insn-uid=1073741824
or even huge numbers several times smaller than that, because the compiler
often allocates arrays sized by maximum INSN_UID, so e.g. compiling empty
function on cross to mips64-linux with that argument needed around 38GiB
of RAM.
2026-03-11 Jakub Jelinek <jakub@redhat.com>
PR target/124436
* genautomata.cc (output_dfa_insn_code_func): Use
MIN (INT_MAX, 2U * uid) instead of 2 * uid in dfa_insn_code_enlarge.
This commit adds three variants of this test case with options that
introduce more predictability to code generation. This will make it less
probable that these tests will break with any other future change. The
options used are:
1. -fno-section-anchors
2. -mcmodel=tiny
3. -mcmodel=small.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/mingw/variadic_hva.c: Deleted and created
three variants.
* gcc.target/aarch64/mingw/variadic_hva1.c: Derived from
variadic_hva.c and compiled with option -fno-section-anchors.
* gcc.target/aarch64/mingw/variadic_hva2.c: Derived from
variadic_hva.c and compiled with option -mcmodel=tiny.
* gcc.target/aarch64/mingw/variadic_hva3.c: Derived from
variadic_hva.c and compiled with option -mcmodel=small.
Marek Polacek [Mon, 9 Mar 2026 21:30:26 +0000 (17:30 -0400)]
c++/reflection: fix for substituting ^^T::mem [PR124331]
In compare11.C, the static_assert was wrongly failing because
compare_reflections got a FIELD_DECL and COMPONENT_REF for ^^S::mem.
We shouldn't have created the COMPONENT_REF. So this patch avoids
creating the COMPONENT_REF by avoiding the finish_qualified_id_expr
call in tsubst_qualified_id when processing a REFLECT_EXPR.
Happily, it fixed some other issues too.
Unfortunately, I found another issue (PR124440) while trying to test
this patch more extensively. I plan to fix that separately next.
PR c++/124331
gcc/cp/ChangeLog:
* pt.cc (tsubst_qualified_id): New name_lookup_p parameter. Don't
call adjust_result_of_qualified_name_lookup and
finish_qualified_id_expr if name_lookup_p is false.
(tsubst_expr) <case REFLECT_EXPR>: Handle SCOPE_REF specially by
calling tsubst_qualified_id with name_lookup_p=false.
gcc/testsuite/ChangeLog:
* g++.dg/reflect/expr13.C: Uncomment the commented out assert.
* g++.dg/reflect/serialize2.C: Replace #if 0 with #ifdef.
* g++.dg/reflect/compare11.C: New test.
* g++.dg/reflect/member21.C: New test.
* g++.dg/reflect/serialize3.C: New test.
When splitting out store_field_updates_msb_p, r16-7265-ga9e48eca3a6eef
accidentally replaced GET_MODE_BITSIZE with GET_MODE_SIZE.
A matching rename of to_size to to_bitsize would have overflowed a line,
so it seemed worth breaking the endian cases apart.
gcc/
PR middle-end/124435
* expr.cc (store_field_updates_msb_p): Use GET_MODE_BITSIZE
instead of GET_MODE_SIZE. Handle the two endiannesses separately.
gcc/testsuite/
PR middle-end/124435
* gcc.dg/torture/pr124435.c: New test.
Patrick Palka [Wed, 11 Mar 2026 14:00:57 +0000 (10:00 -0400)]
c++: add fixed test [PR124389]
This one is also fixed by r16-7055. The testcases from that commit
utilize the concepts satisfaction cache, whereas this one utilizes
the constexpr call cache.
Richard Earnshaw [Wed, 11 Mar 2026 11:14:47 +0000 (11:14 +0000)]
arm: Fix trapping arithmetic [PR123271]
Patch r10-3995 accidentally defined insn patterns that overrode the
default behaviour of overflow-trapping arithmetic; this broke the
implementation of -ftrapv. Fixed by renaming the internal patterns.
For consistency I've renamed more than is strictly necessary.
gcc/ChangeLog:
PR target/123271
* config/arm/arm.md (subvsi3_intmin): Renamed to ...
(sub_cmpVsi3_intmin): ... this.
(subvsi3): Renamed to ...
(sub_cmpVsi3): ... this.
(subvsi3_imm1): Renamed to ...
(sub_cmpVsi3_imm1): ... this.
(usubvsi3_borrow): Renamed to ...
(usub_cmpVsi3_borrow): ... this.
(usubvsi3_borrow_imm): Renamed to ...
(usub_cmpVsi3_borrow_imm): ... this.
(subvsi3_borrow): Renamed to ...
(sub_cmpVsi3_borrow): ... this.
(subvsi3_borrow_imm): Renamed to ...
(sub_cmpVsi3_borrow_imm): ... this.
gcc/testsuite/ChangeLog:
PR target/123271
* gcc.target/arm/pr123271.c: New test.
Arsen Arsenović [Tue, 24 Feb 2026 10:24:09 +0000 (10:24 +0000)]
gcc/gcn: Use 'shared_base' register for LDS<->flat conversion
This speeds up address space conversions by about 8x in
micro-benchmarks. Those may be slightly unrepresentative, because the
RTL optimizer is free to do whatever it wants with the two registers
address space conversion uses (a temporary register and shared_base).
gcc/ChangeLog:
* config/gcn/gcn.cc (gcn_addr_space_convert): Use
SHARED_BASE_REG to find flat address space base of LDS.
gcc/testsuite/ChangeLog:
* gcc.target/gcn/addr-space-convert-1.c: New test.
* gcc.target/gcn/addr-space-convert-2.c: New test.
Arsen Arsenović [Tue, 24 Feb 2026 10:11:27 +0000 (10:11 +0000)]
gcc/gcn: fix address space conversion between __flat and default [PR124044]
The default address space in the GCN backend is distinct from the
flat/global address space that it normally coincides with so that it can
be changed. But, as a result, address space conversion must be aware of
this difference and handle the default address space explicitly.
Currently, it fails to do so, and so it reaches a gcc_unreachable.
This patch fixes that by resolving the default address space into
whatever address space it effectively is.
gcc/ChangeLog:
PR target/124044
* config/gcn/gcn.cc (gcn_addr_space_resolve_default): New
function. Converts from ADDR_SPACE_DEFAULT to
DEFAULT_ADDR_SPACE.
(gcn_addr_space_convert): Resolve from_type and to_type address
spaces.
Arsen Arsenović [Thu, 19 Feb 2026 13:58:01 +0000 (13:58 +0000)]
gcc/gcn: add memory aperture register definitions
Memory aperture registers on GCN are special read-only registers that
hold the 64-bit (i.e. pointer-sized) values. These registers are
accessible as the full value or by their lower half (but not upper
half!), and are also aligned to 2^32 (so the lower half is useless..).
They come in two pairs: shared_base/shared_limit and
private_base/private_limit. The base registers contain the address at
which the LDS and scratch spaces are mapped to, respectively, in the
flat memory space, an the limit registers contain the size of these
mappings.
In a subsequent patch, this will allow us to use a pair of moves to do
conversions from LDS to the flat address space, saving us a few
expensive reads at runtime.
gcc/ChangeLog:
* config/gcn/gcn.cc (gcn_regno_reg_class): Handle
MEMORY_APERTURE_REGS.
(gcn_hard_regno_rename_ok): Return false for memory aperture
regs.
(gcn_memory_move_cost): Handle memory aperture regs the same as
general registers.
(gcn_hard_regno_nregs): Handle MEMORY_APERTURE_REGS.
* config/gcn/gcn.h (SHARED_BASE_REG): Define.
(SHARED_LIMT_REG): Ditto.
(PRIVATE_BASE_REG): Ditto.
(PRIVATE_LIMT_REG): Ditto.
(MEMORY_APERTURE_REG_P): New macro. Evaluates to non-zero if
parameter is one of the above registers.
(SSRC_REGNO_P): Also evaluate to non-zero for aperture regs, as
they can be sources to scalar instructions.
(enum reg_class): New class: MEMORY_APERTURE_REGS.
(REG_CLASS_NAMES): Provide name for that class.
(MEMORY_APERTURE_REGS_MASK): New helper macro. Value of
NAMED_REG_MASK2 for each of the memory aperture regs.
(REG_CLASS_CONTENTS): Add the above registers to
MEMORY_APERTURE_REGS, SGPR_VOP_SRC_REGS, and SGPR_SRC_REGS.
Philipp Tomsich [Mon, 23 Feb 2026 16:22:47 +0000 (17:22 +0100)]
fold-mem-offsets: Fix wrong mode in memory_address_addr_space_p
The validity check in do_check_validity was passing the address mode
(GET_MODE of the address RTX, e.g. DImode) to memory_address_addr_space_p
instead of the memory access mode (GET_MODE of the MEM RTX, e.g. SImode).
The first argument to memory_address_addr_space_p is the mode of the
memory access, not the address mode.
On targets where address validity depends on the access width (e.g.
alignment-sensitive modes, vector modes), this could accept an illegal
offset or reject a valid one.
Rename the variable to 'addr_mode' for address construction and add a
separate 'mem_mode' for the validity check.
gcc/ChangeLog:
* fold-mem-offsets.cc (do_check_validity): fix wrong mode
and rename arguments to avoid future confusion
Jakub Jelinek [Wed, 11 Mar 2026 10:55:56 +0000 (11:55 +0100)]
testsuite: Fix up g++.dg/reflect/eh8.C for Solaris iconv [PR124118]
I forgot about PR112652 and added a test that relies on iconv actually
failing when converting from UTF-8 with some emojis to a character set
without those characters.
Seems Solaris iconv just transcodes such characters as ? instead of
reporting an error.
The following patch splits the test into two halves, so that the first one
is tested on Solaris, and uses dg-skip-if for Solaris like in r16-6209
in the second half (rather than expecting no diagnostics for Solaris,
because one can use GNU libiconv on Solaris too).
2026-03-11 Jakub Jelinek <jakub@redhat.com>
PR c++/124118
* g++.dg/reflect/eh8.C (bar, c): Move second part of tests to ...
* g++.dg/reflect/eh10.C: ... here, new test. Add dg-skip-if for
solaris.
Jakub Jelinek [Wed, 11 Mar 2026 06:55:58 +0000 (07:55 +0100)]
libstdc++: Use __builtin_constexpr_diag instead of __asm__("") in <meta> if possible
Your asm -> __asm__ patch made me think that these are perfect
candidates for __builtin_constexpr_diag, the asms were there just
to make it provably non-constant expression (guess *(char*)nullptr = 0;
would do as well). But with __builtin_constexpr_diag we can tell
the user the details.
Additionally, when testing it I've found that the
https://eel.is/c++draft/meta.reflection#access.context-13
Throws: meta::exception unless cls is either the null reflection
or a reflection of a complete class type.
part of via's description was implemented wierdly, it did throw
an exception, but not by telling user that via has been called with
something that is not a null reflection nor reflection of a complete
class type, but that is_class_type has been called on a reflection
of something other than a type.
2026-03-11 Jakub Jelinek <jakub@redhat.com>
* include/std/meta (std::meta::exception::what()): Use
__builtin_constexpr_diag instead of __asm__("") if supported.
(std::meta::access_context::via(info)): Don't call is_class_type
if __cls is not a type. Use __builtin_constexpr_diag instead of
__asm__("") if supported for -fno-exceptions.
* g++.dg/reflect/eh8.C: Expect different diagnostics.
* g++.dg/reflect/no-exceptions2.C: New test.
Jakub Jelinek [Wed, 11 Mar 2026 06:54:36 +0000 (07:54 +0100)]
c++: Emit error if not quiet and set *non_constant_p for -fno-exceptions metafn error cases [PR124417]
For -fno-exceptions, we reject throw statements in the source, and a lot
of code in the header has #ifdef __cpp_exceptions guarded stuff and the
FE for !flag_exceptions doesn't emit some parts of the IL needed for
exceptions. For the errors in metafns, we had just a todo to handle it
in the source but no actual implementation, so we allowed throwing
an exception and sometimes it worked to some extent and sometimes
it didn't.
The following patch fixes it by not throwing an exception if user
asked for -fno-exceptions - instead we just emit an error including
the planned what () (unless ctx->quiet) and make the evaluation
non-constant.
2026-03-11 Jakub Jelinek <jakub@redhat.com>
PR c++/124417
* reflect.cc (get_meta_exception_object): Add CTX argument. For
!flag_exceptions emit error unless ctx->quiet, set *non_constant_p
to true and return NULL_TREE instead of throwing an exception.
(throw_exception): Adjust get_meta_exception_object caller.
Jakub Jelinek [Wed, 11 Mar 2026 06:50:22 +0000 (07:50 +0100)]
c++: Fix up __builtin_constexpr_diag for std::string operands [PR124404]
__builtin_constexpr_diag works fine with string literals or class arguments
like std::{,u8}string_view or string view like classes, but as the following
testcase shows doesn't work with std::string argument.
I believe the important difference is that std::string has non-trivial
destructor and so needs to be passed by invisible reference while
std::string_view doesn't.
Anyway, the following patch makes it work even with std::string.
2026-03-11 Jakub Jelinek <jakub@redhat.com>
PR c++/124404
* constexpr.cc (cxx_eval_constexpr_diag): Call convert_from_reference
on arguments.
Jakub Jelinek [Tue, 10 Mar 2026 20:27:10 +0000 (21:27 +0100)]
c++: For reflection comparison of annotations compare TREE_VALUE [PR124399]
https://eel.is/c++draft/meta.reflection#annotation-4
testcase also contains
[[=1]] int x, y;
static_assert(annotations_of(^^x)[0] == annotations_of(^^y)[0]);
so in case of an annotation shared by multiple declarations we need
to compare the TREE_VALUE of the attributes (which is shared in that
case) rather than the TREE_LIST with that TREE_VALUE and TREE_PURPOSE
being "internal ":"annotation ".
For mangling we already handle it right:
if (eval_is_annotation (h, kind) == boolean_true_node)
{
strcpy (prefix, "an");
if (TREE_PURPOSE (TREE_VALUE (h)) == NULL_TREE)
TREE_PURPOSE (TREE_VALUE (h))
= build_int_cst (integer_type_node, annotation_idx++);
return TREE_PURPOSE (TREE_VALUE (h));
}
so the annotation index is stored on TREE_PURPOSE of the TREE_VALUE,
so in shared annotation like the above it will have the same index
in both cases.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
When I was adding further tests for this, I've noticed that we don't
handle correctly
[[=1]] int x [[=2]], y [[=3]];
because the attributes list which is shared is clearly added as a shared
tail of the other attributes. For now this is commented out in the
test, will try to deal with it somehow incrementally.
2026-03-10 Jakub Jelinek <jakub@redhat.com>
PR c++/124399
* reflect.cc (compare_reflections): For REFLECT_ANNOTATION, compare
TREE_VALUE of lhs and rhs instead of lhs and rhs.
* g++.dg/reflect/annotations12.C: Add further tests.
Jakub Jelinek [Tue, 10 Mar 2026 20:24:33 +0000 (21:24 +0100)]
c++: Use complete_type on first annotations_of argument if it is a type [PR124399]
The following testcases FAIL (annotations12.C is directly from
https://eel.is/c++draft/meta.reflection#annotation-4 ) because it is
called on a reflection of class template instantiation which has been
just looked up but not yet completed, and in that case it doesn't
have any attributes instantiated.
Only complete_type instantiates those. Unlike the second argument
of annotations_of_with_type where the standard requires is_complete_type,
in this case it doesn't, so it is fine if one uses
struct S;
static_assert (annotations_of (^^S).size () == 0);
but I'm afraid we need to instantiate the argument to get the annotations.
2026-03-10 Jakub Jelinek <jakub@redhat.com>
PR c++/124399
* reflect.cc (eval_annotations_of): Call complete_type on r if it
is a type.
* g++.dg/reflect/annotations3.C: Uncomment 3 test lines.
* g++.dg/reflect/annotations12.C: New test.
* g++.dg/reflect/constant_of5.C: Enable some commented out
or #if 0ed out tests.
* g++.dg/reflect/constant_of6.C: Remove dg-error directive.
* g++.dg/reflect/extract6.C: Remove 2 dg-error directives.
Jason Merrill [Tue, 10 Mar 2026 19:44:53 +0000 (15:44 -0400)]
c++/testsuite: -fimplicit-constexpr adjustments
Various tests were failing because they rely on non-constexpr functions
staying that way. The constexpr-diag tests are easier to just skip if
impcx; the reflection tests can be adjusted.
Jonathan Wakely [Tue, 10 Mar 2026 15:44:48 +0000 (15:44 +0000)]
libstdc++: Add comment to chrono::hh_mm_ss constructor for LWG 4274
LWG 4274 was approved in Kona 2025 but I implemented the resolution back
in 2023 for PR libstdc++/108265. This just adds a comment noting that we
implement the resolution.
libstdc++-v3/ChangeLog:
* include/std/chrono (hh_mm_ss): Add comment about LWG 4274.
Jonathan Wakely [Tue, 10 Mar 2026 17:18:59 +0000 (17:18 +0000)]
libstdc++: Do not use projection for ranges::replace default args (LWG 4444)
Implement the resolution of LWG 444, accepted in Kona 2025.
The new value to be assigned to the matching elements should default to
the value type of the range, not the type returned by the projection.
The type returned by the projection is only used to find the matching
elements, and might not be assignable to the value type at all.
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__replace_fn, __replace_if_fn):
Change default template argument for type of new value, as per
LWG 4444.
* testsuite/25_algorithms/replace/lwg4444.cc: New test.
* testsuite/25_algorithms/replace_if/lwg4444.cc: New test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jonathan Wakely [Tue, 10 Mar 2026 16:00:40 +0000 (16:00 +0000)]
libstdc++: Constrain std::as_bytes to disallow span<volatile T>
Implement the accepted resolution of LWG 4243, approved in Kona 2025.
libstdc++-v3/ChangeLog:
* include/std/span (as_bytes, as_writable_bytes): Add
constraints to disallow volatile elements, as per LWG 4243.
* testsuite/23_containers/span/lwg4243.cc: New test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Implement proposals adopted for C++23:
P0401R6, "Providing size feedback in the Allocator interface"
P2652R2, "Disallow User Specialization of allocator_traits".
This is the minimal conforming implementation, i.e. without the
useful parts. Useful parts, to come in future patches, would
include giving access to any extra storage reserved, and use of
it in vector, string, and other contiguous containers.
libstdc++-v3/ChangeLog:
PR libstdc++/118030
* include/bits/alloc_traits.h (allocate_at_least (2x)): Define.
* include/bits/allocator.h (allocate_at_least): Define.
* include/std/memory (__glibcxx_want_allocate_at_least): Define.
* include/bits/memoryfwd.h (allocation_result): Define, #include
<bits/version.h> first so that will work.
* include/bits/version.def (allocate_at_least): Add.
* include/bits/version.h: Regenerate.
* testsuite/20_util/allocator/allocate_at_least.cc: New test.
* testsuite/20_util/allocator/allocate_at_least_neg.cc: New test.
Currently, the implementation of TARGET_CHECK_TARGET_CLONE_VERSION for
RISC-V is incomplete and will emit an error for invalid target_clones
versions. This can be problematic during transitions to new extensions,
as it may break builds that have not yet updated their target_clones
versions.
This commit implements TARGET_CHECK_TARGET_CLONE_VERSION for RISC-V, by
using the riscv_process_target_version_str with loc set to NULL to
prevent emitting errors for invalid versions. This allows for a smoother
transition to new extensions, while still providing a mechanism for
checking target_clones versions when needed.
Signed-off-by: Yangyu Chen <cyy@cyyself.name>
---
Note: I think it should be safe to push to GCC-16 with the new test, to align
FMV with aarch64 for invalid version string. Future ISA extensions may cause
build breakage if the version string is not updated, and this test can help
catch such issues early.
Aarch64 in GCC-16 already merged this new feature. X86 [1] may also merge this
feature in GCC-16, but it is not yet clear. If X86 also merges this feature in
GCC-16, then it would be more consistent to also merge the RISC-V
implementation in GCC-16.
Richard Earnshaw [Tue, 10 Mar 2026 13:03:16 +0000 (13:03 +0000)]
arm: testsuite: avoid pr45701 matching asm across newlines
The tests I added yesterday used '.*' in a scan-assembler-not pattern,
but that can match across multiple lines leading to some false matches
in the not variant. Avoid that by scanning for [^\n]*.
gcc/testsuite/ChangeLog:
* gcc.target/arm/pr45701-1.c: Don't match across lines.
* gcc.target/arm/pr45701-2.c: Likewise.
* gcc.target/arm/pr45701-3.c: Likewise.
Jakub Jelinek [Tue, 10 Mar 2026 12:26:09 +0000 (13:26 +0100)]
testsuite: Fix up gcc.dg/plugin/analyzer_cpython_plugin.cc [PR112520]
The recent r16-7938 PR112520 fix hasn't changed much in the testsuite
results for me:
@@ -154,41 +151,34 @@ FAIL: gcc.dg/plugin/cpython-plugin-test-
FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_Append.c -fplugin=./analyzer_cpython_plugin.so (test for warnings, line 42)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_Append.c -fplugin=./analyzer_cpython_plugin.so at line 18 (test for warnings, line 17)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_Append.c -fplugin=./analyzer_cpython_plugin.so at line 43 (test for warnings, line 42)
-FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_Append.c -fplugin=./analyzer_cpython_plugin.so (internal compiler error: Segmentation fault)
+FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_Append.c -fplugin=./analyzer_cpython_plugin.so (internal compiler error: tree check: expected record_type or union_type or qual_union_type, have integer_type in get_field_by_name, at /home/jakub/src/gcc/gcc/testsuite/gcc.dg/plugin/analyzer_cpython_plugin.cc:62)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_Append.c -fplugin=./analyzer_cpython_plugin.so (test for excess errors)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_New.c -fplugin=./analyzer_cpython_plugin.so (test for warnings, line 17)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_New.c -fplugin=./analyzer_cpython_plugin.so (test for warnings, line 18)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_New.c -fplugin=./analyzer_cpython_plugin.so (test for warnings, line 21)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_New.c -fplugin=./analyzer_cpython_plugin.so (test for warnings, line 29)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_New.c -fplugin=./analyzer_cpython_plugin.so at line 37 (test for warnings, line 36)
-FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_New.c -fplugin=./analyzer_cpython_plugin.so (internal compiler error: Segmentation fault)
+FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_New.c -fplugin=./analyzer_cpython_plugin.so (internal compiler error: tree check: expected record_type or union_type or qual_union_type, have integer_type in get_field_by_name, at /home/jakub/src/gcc/gcc/testsuite/gcc.dg/plugin/analyzer_cpython_plugin.cc:62)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_New.c -fplugin=./analyzer_cpython_plugin.so (test for excess errors)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyLong_FromLong.c -fplugin=./analyzer_cpython_plugin.so (test for warnings, line 17)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyLong_FromLong.c -fplugin=./analyzer_cpython_plugin.so (test for warnings, line 18)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyLong_FromLong.c -fplugin=./analyzer_cpython_plugin.so (test for warnings, line 21)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyLong_FromLong.c -fplugin=./analyzer_cpython_plugin.so (test for warnings, line 29)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyLong_FromLong.c -fplugin=./analyzer_cpython_plugin.so at line 37 (test for warnings, line 36)
-FAIL: gcc.dg/plugin/cpython-plugin-test-PyLong_FromLong.c -fplugin=./analyzer_cpython_plugin.so (internal compiler error: Segmentation fault)
+FAIL: gcc.dg/plugin/cpython-plugin-test-PyLong_FromLong.c -fplugin=./analyzer_cpython_plugin.so (internal compiler error: tree check: expected record_type or union_type or qual_union_type, have integer_type in get_field_by_name, at /home/jakub/src/gcc/gcc/testsuite/gcc.dg/plugin/analyzer_cpython_plugin.cc:62)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyLong_FromLong.c -fplugin=./analyzer_cpython_plugin.so (test for excess errors)
...
The problem is that get_field_by_name now recurses on TREE_TYPE of
everything in TYPE_FIELDS (which can be FIELD_DECL but many other
things (though primarily for C++ and other languages)). More importantly,
it recurses even for FIELD_DECLs with scalar (e.g. INTEGER_TYPE) types
and using TYPE_FIELDS on such types results in checking ICE.
The following patch fixes that by only recursing on anonymous struct/union
FIELD_DECLs. For C those have NULL DECL_NAME, for C++ they would have
IDENTIFIER_ANON_P IDENTIFIER_NODE as DECL_NAME (but it seems this plugin
is only used for C).
No FAILs from plugin.exp now:
Running /usr/src/gcc/gcc/testsuite/gcc.dg/plugin/plugin.exp ...
=== gcc Summary ===
2026-03-10 Jakub Jelinek <jakub@redhat.com>
PR testsuite/112520
* gcc.dg/plugin/analyzer_cpython_plugin.cc (get_field_by_name):
If name is "ob_refcnt", recurse only for types of FIELD_DECLs
with no DECL_NAME and record or union type.
mips.exp overrides dg-options with some logic to (try to) enable
the transitive closure of features that would be needed to make the
dg-options valid for the current test run, downgrading from run to
assemble to compile as neecessary. In order to make sure that
every relevant option has been considered, this version of dg-options
errors out for things that it doesn't recognise.
-O options aren't in the list because mips.exp cycles through the usual
optimisation options. Instead, dg-skips are used if the test doesn't
make sense for a particular -O* option.
Removing the -O options makes pr118608-2.c identical to pr118608-1.c
and pr118608-4.c identical to pr118608-3.c.
Andrew Pinski [Tue, 10 Mar 2026 09:46:56 +0000 (02:46 -0700)]
testsuite/aarch64: Add testcase for already fixed bug [PR123094]
This bug was fixed by r16-7941-g2a155ceffe6639. The testcase is
different as this is an ICE rather than wrong code. So it seems
like a good idea to add a testcase for it.
Pushed as obvious after testing to make sure the new testcase
works for aarch64-linux-gnu.
PR rtl-optimization/123094
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/pr123094-1.c: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Now that check_cached_effective_target_indexed is a simple wrapper
around check_cached_effective_target, we can replace all uses of
the former with the latter.
gcc/testsuite/
PR testsuite/124066
* lib/target-supports.exp (check_cached_effective_target_indexed):
Remove. Replace all uses with check_cached_effective_target.
testsuite: Add EFFECTIVE_TARGETS info to cache keys [PR124066]
MIPS now uses an "effective target" mechanism to run the vectoriser
testsuite for multiple vector ISAs. This mechanism defines a couple
of wrapper procedures:
- et-dg-runtest wraps dg-runtest and invokes it for each effective
target. The procedure uses two global variables:
- EFFECTIVE_TARGETS gives the list of targets to test. This is
supplied by the test harness.
- et_index is the index of the current target in EFFECTIVE_TARGETS.
This is set by et-dg-runtest itself.
- et-is-effective-target wraps is-effective-target. When the effective
target mechanism is in use, et-is-effective-target tests whether the
supplied target matches index $et_index of $EFFECTIVE_TARGETS.
check_effective_target_* procedures that use et-is-effective-target
can therefore vary from one effective target to another. It seems
that all such procedures are expected to cache their results using
check_cached_effective_target_indexed instead of the standard
check_cached_effective_target.
check_cached_effective_target_indexed distinguishes effective targets by
adding $et_index to the cache key. One theoretical problem with this is
that it implicitly assumes that EFFECTIVE_TARGETS will always be set to
the same value (if it's set at all).
But the more immediate problem is that et_index is default-
initialised to 0 when the effective target mechanism is not in use.
This means that the same cached values are used for the default
target and for the first effective target. Also, et-dg-runtest
did not reset et_index after iterating through the targets,
leaving a stale value for later check_effective_target_*s.
As Richi points out in PR124066, a downside of the current
mechanism is that only et-is-effective-target tests are sensitive
to the current effective target. Automatic tests, like those that
use check_no_compiler_messages, do not use the flags for the current
effective target.
To cope with a future fix for PR124066, it seems better to add
the current effective target to all cache keys, rather than keep
the current distinction between check_cached_effective_target
and check_cached_effective_target_indexed. It should also be
less error prone.
Also, rather than expect et_index to be default-initialised,
it seems better to ensure that et_index is only defined while
running an effective target variant. Other procedures can then
key off whether et_index exists.
Doing this fixes some spurious failures on a plain mips64-linux-gnu
test run.
To make the patch easier to review and bisect, the mechanical
replacement of check_cached_effective_target_indexed is left
to a follow-on patch.
gcc/testsuite/
PR testsuite/124066
* lib/target-supports.exp (check_cached_effective_target): If
et_index is defined, add the associated EFFECTIVE_TARGETS element
to the cache key.
(check_cached_effective_target_indexed): Turn into a simple wrapper
around check_cached_effective_target.
(is-effective-target): Remove default-initialization of et_index.
(et-dg-runtest): Likewise. Unset et_index after each
EFFECTIVE_TARGETS run.
(et-is-effective-target): Key off the existence of et_index rather
than EFFECTIVE_TARGETS.
Some of the parallel MIPS tests that I ran recently seemed to be
nondeterministic. Some tests were skipped and others were duplicated.
This turned out to be because some MIPS check_effective_target
procedures accept optional command-line flags. Sometimes the
procedures are called as normal, without flags, and sometimes
they are passed an explicit -m option.
The problem is that both invocations use the same cache identifier.
This means that the result of the first invocation (with or without
flags) is used for all subsequent invocations (with or without flags).
And the first invocation depends on which tests are being run by a
particular parallel thread.
As a result, the parallel threads did not agree on which tests
needed to be run, and so got out of sync.
The flags passed to the procedures all seem to be valid filenames,
so this patch simply adds the flags to the cache identifier.
It's a bit of a hack, and I'm not sure that this pattern should
be followed for future tests.
Doing that made check_effective_target_mpaired_single always succeed
when no flags were passed, since it simply tests an empty function.
Since there is no predefined macro (AFAICT), the patch tests for support
using the same asm as check_mpaired_single_hw_available (but with an
assemble test rather than with a run test).
Also, check_mpaired_single_hw_available did not pass -mpaired-single
to the hardware test, unlike the loongson_mmi and mma equivalents.
gcc/testsuite/
* lib/target-supports.exp (check_effective_target_mips_loongson_mmi)
(check_effective_target_mips_msa): Add the arguments to the cache
identifier.
(check_effective_target_mpaired_single): Likewise. Use an asm
to test whether -mpaired-single is supported.
(check_mpaired_single_hw_available): Add -mpaired-single.
Andrew Pinski [Mon, 9 Mar 2026 22:38:33 +0000 (15:38 -0700)]
c: Fix ICE after an error: typedef and old style prototypes for nested functions [PR123461]
This started to ICE after r16-3747-gafa74d37e8170d which added
a call to mark_decl_used. You can't call mark_decl_used with a
typedef which is an error mark as you get an ICE.
There is a check right after the newly added call for error mark,
so let's move the call to inside that block instead.
Bootstrapped and tested on x86_64-linux-gnu.
PR c/123461
gcc/c/ChangeLog:
* c-decl.cc (declspecs_add_type): Move mark_decl_used
call after the check for error mark node.
gcc/testsuite/ChangeLog:
* gcc.dg/pr123461-1.c: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Tomasz Kamiński [Tue, 24 Feb 2026 15:17:30 +0000 (16:17 +0100)]
libstdc++: Introduce __format::_Ptr_sink for contiguous iterators.
This patch replaces the _Iter_sink specialization for contiguous
iterators of _CharT, with separate _Ptr_sink. This allow further
reduce the number of instantiations as single _Ptr_sink<_CharT>
specialization is used for all such iterators.
To make _Ptr_sink independent of iterator type, we no longer store
value of the iterator as _M_first member (the address pointed to is
still stored inside span). To produce the actual iterator position,
_Ptr_sink::_M_finish requires original pointer to be passed. As any
contiguous iterator is copyable, there is no issue in passing them
to both _Ptr_sink constructor and _M_finish method.
The __do_vformat_to method is reworked, to use _Ptr_sink when possible
(__contiguous_char_iterator is true). The implementation approach is
also changed to split the function into three constexpr branches:
_Sink_iter, contiguous char iterator, other iterators. The latter two
wrap iterators in _Ptr_sink and _Iter_sink respectively and forward
to _Sink_iter specialization.
To reduce the duplication, we introduce __do_format_to_n helper function,
that also handles wrapping iterator into _Ptr_sink and _Iter_sink as
appropriate.
libstdc++-v3/ChangeLog:
* include/std/format (__format::_Ptr_sink): Reworked
from _Iter_sink specialization below.
(__format::_Iter_sink<_CharT, contiguous_iterator _OutIter>):
Renamed and reworked to _Ptr_sink.
(__format::__contiguous_char_iter, __format::__do_vformat_to_n):
Define.
(__format::__do_vformat_to): Use _Ptr_sink when appropriate,
and delegate to _Sink_iter specialization.
(std::format_to_n): Delegate to __do_vformat_to_n.
(__format::_Counting_sink): Use _Ptr_sink as base class.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Tomasz Kamiński [Thu, 5 Mar 2026 14:00:31 +0000 (15:00 +0100)]
libstdc+: Eliminate usage of alloca for non-localized formatting
This patch eliminate the use of __builtin_alloca for non-localized formatting
of integers and pointers.
For integers, the transcoding to _CharT moved from _M_format_int function
to format. This makes the maximum size (that depends on sizeof(_Int)) of the
buffer known (__buf_size) and allows use local array of _CharT (__wbuf) for
the storage. The _M_format_int is modified to accept the string of _CharT.
For pointers, r16-7844-gbfc2b87f8244a1 modified _Pres_p and _Pres_P to have
same value as _Pres_x and _Pres_X, so format specifiers are subset of one
allowed for integers. In consequence we simply delegate to format method
of __formatter_int, reducing the code duplication. The set of allowed
specifiers is still limited per C++ standard by __formatter_ptr::parse.
This patch fix issue in __formatter_ptr::parse, where for 'p' and 'P' the value
of _M_alt was negated for _M_spec (result of previous parse) instead of __spec
(result of current parse), and adjust the __formatter_ptr default constructor
to set _M_spec._M_type and _M_spec._M_alt appropriately.
libstdc++-v3/ChangeLog:
* include/std/format (__formatter_int::format): Handle transcoding
to _CharT before calling _M_format_int.
(__formatter_int::_M_format_int): Accept basic_string_view<_CharT>
and remove transcoding.
(__formatter_ptr::__formatter_ptr): Configure _M_spec member.
(__formatter_ptr::parse): Negate _M_alt for __spec and not _M_spec.
(__formatter_ptr::format): Delegate to __formatter_int.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jan Hubicka [Tue, 10 Mar 2026 06:56:23 +0000 (07:56 +0100)]
Fix merging of flags in ipa_merge_modref_summary_after_inlining
When merging the modref summary after inlining, we merge all of the flags
of the outer functions that was inlined into. But things go wrong as
now the flags includes both ECF_NORETURN and ECF_NOTHROW. This happens
because the function which was being inlined had ECF_NOTHROW while caller
had ECF_NORETURN. When both of these are set, ignore_stores_p and
ignore_nondeterminism_p return true. But in this case the inner function is
still just nothrow and not noreturn.
Originally the code was written to only merge ECF_PURE and ECF_CONST where
this logic is correct. This fixes merigng of ignore_stores and
ECF_LOOPING_CONST_OR_PURE flags.
Bootstrapped and tested on x86_64-linux-gnu.
PR tree-optimization/120987
gcc/ChangeLog:
* ipa-modref.cc (ipa_merge_modref_summary_after_inlining): Mask
off non const/pure/novops related flags when combining of outer
functions.
gcc/testsuite/ChangeLog:
* g++.dg/torture/pr120987-1.C: New test.
Co-authored-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Jonathan Wakely [Sat, 7 Mar 2026 11:24:29 +0000 (11:24 +0000)]
libstdc++: Make <meta> header compatible with -fno-asm
We currently only use 'asm' in .cc files (where we control the build
flags) and in the experimental::simd headers. We could just say that
-fno-asm is not compatible with libstdc++ and so using it is not
supported, but we can also just make this small change.
libstdc++-v3/ChangeLog:
* include/std/meta (exception::what, access_context::via): Use
__asm__ instead of asm keyword.
Fortran: Evaluate all functions on the source image.
Formerly pure elemental functions were evaluated in the caf_accessor.
This had so many dependencies that there was no benefit. Evaluate
every function on the calling side now, which has the benefit, that
only one temporary has to be created instead of argument many.
PR fortran/121043
gcc/fortran/ChangeLog:
* coarray.cc (check_add_new_component): Evaluate all functions
on the source image.
* trans-decl.cc (gfc_build_builtin_function_decls): The only
argument of team_number() is of type void* in the library ABI.
Jonathan Wakely [Tue, 25 Nov 2025 14:29:50 +0000 (14:29 +0000)]
libstdc++: Add platform wait functions for FreeBSD [PR120527]
This defines __platform_wait, __platform_notify, and
__platform_wait_until for FreeBSD, making use of the _umtx_op syscall.
The Linux versions of those functions only support 32-bit integers, but
the FreeBSD versions use the syscall for both 32-bit and 64-bit types,
as the _umtx_op supports both.
We also need to change __spin_impl because it currently assumes the
waitable at args._M_obj is always a __platform_wait_t. Because FreeBSD
supports waiting on both 32-bit and 64-bit integers, we need a
platform-specific function for loading a value from _M_obj. This adds a
new __platform_load function, which does an atomic load of the right
size. The Linux definition just loads an int, but for FreeBSD it depends
on _M_obj_size. We also need a generic version of the function for
platforms without __platform_wait, because __spin_impl is always used,
even when the __waitable_state contains a condition_variable.
arm: testsuite: Improve stability of tests for pr45701
These tests have always been a bit flaky, but I noticed that they were
often running with completely unsuitable options (eg expecting tailcalls
to happen on Thumb1). So I took the opportunity while fixing that to
improve their overall stability by removing most of the code that was
trying to push up the register pressure and replacing it with a simple asm
statement. Doing this has the added advantage that it removes the
issues that -mpure-code can cause since the test no-longer needs to
access global variables.
gcc/testsuite/ChangeLog:
* gcc.target/arm/pr45701-1.c: Rework test to avoid global
variables. Require arm_arch_v7a_thumb as the effective
target.
* gcc.target/arm/pr45701-2.c: Likewise.
* gcc.target/arm/pr45701-3.c: Likewise.
Paul Thomas [Mon, 9 Mar 2026 16:07:48 +0000 (16:07 +0000)]
Fortran: Fix invalid free for PDTs without LEN components [PR122902]
2026-03-09 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/122902
* expr.cc (has_parameterized_comps): Moved from trans-array.cc.
* gfortran.h : Add prototype for has_parameterized_comps.
* trans-array.cc : Move has_parameterized_comps to expr.cc.
* trans-expr.cc (gfc_trans_scalar_assign): Don't deep copy PDTs
unless they have parameterized components.
gcc/testsuite/
PR fortran/122902
* gfortran.dg/pdt_39.f03: Deallocate a_r4 and a_r8.
* gfortran.dg/pdt_86.f03: New test.
Martin Jambor [Mon, 9 Mar 2026 13:01:00 +0000 (14:01 +0100)]
contrib/filter-clang-warnings.py: Ignore a C++ compat warning in libiberty
When building GCC master with Clang, we were getting (and not
filtering out) warning:
/home/worker/buildworker/tiber-gcc-clang/build/libiberty/regex.c:3978:24: warning: implicit conversion from 'int' to enumeration type 'reg_errcode_t' is invalid in C++ [-Wimplicit-int-enum-cast]
The flag is a C++ compatibility warning and libiberty is a C library, so
I think we can ignore the warning.
contrib/ChangeLog:
2026-03-09 Martin Jambor <mjambor@suse.cz>
* filter-clang-warnings.py (skip_warning): Also ingore
-Wimplicit-int-enum-cast in libiberty.
Martin Jambor [Mon, 9 Mar 2026 11:45:26 +0000 (12:45 +0100)]
ipa-cp: Allow more precise contexts in the verifier (PR124291)
Similarly to PR123629, the issue again stems from that when propagating
polymorphic contexts, when there are no known "values" in the corresponding
lattice of the caller we use just the information on the edge and when
there are some we combine them with the information, and from the fact that
we iterate the propagation in strongly connected components of the call
graph (SCCs).
In the first iteration over such SCC, we process the edge from
unmark/1097720 to onChild/1097719 before we determined the lattices of the
caller. In the second iteration, we already know what context there will
be in the first unmarks's parameter and so can add a more precise value to
the corresponding lattice of onChild. Because we always add values to the
lattices and never "improve" them, we get two values for the call.
In PR123629, that actually described reality well because the caller's
lattice had the variable flag set, without cloning the caller we could not
assume we could use the caller's lattice value and so both values were
possible (and in fact both cases happened, the problem was that their meet
failed).
In this case however, one could argue that the lattices contain wrong info
or at least information that is misleading because the caller's lattice
contains just that single "constant" and the variable flag is not set. We
know that regardless of cloning decisions for the caller the more precise
derived value will be the case. And indeed since I changed the cloning
code to re-gather all constants for the given set of callers, that code
arrives at the more precise context. For the record they only differ in
the fact that the more precise one has the dynamic flag cleared.
I have thought about how to fix up the lattices in one way or another but
so far it has always turned ugly. Therefore this patch simply changes the
verification to simply allow this situation because even though the final
result is just a bit more precise than what was expected, it is however
correct. There will not be any attempt to clone for the more precise
context because all the call graph edges will have been redirected away.
The only "issue" is that the less precise contexts take up place in the
lattice, which has a limited length. That should not be a problem in
practice.
gcc/ChangeLog:
2026-03-06 Martin Jambor <mjambor@suse.cz>
PR ipa/124291
* ipa-cp.cc (ipcp_val_replacement_ok_p): Allow more precise
contexts that what the clone was originally intended for.
Dhruv Chawla [Thu, 12 Feb 2026 08:27:49 +0000 (08:27 +0000)]
gcc-auto-profile: Force writing perf output to perf.data [PR124075]
This is a partial fix for PR124075 which forces perf record to write the
profile out to perf.data. This is required because I noticed on both
aarch64 and x86 that it was writing out the profile to stdout at times,
which would cause profile information to be dropped. This did not fail
in the various create_fdas_for_* targets because they would only try and
access the perf profiles if they existed at their paths.
Further work for this patch is to plumb the PERF_DATA make variable into
the perf record invocation, but that is a stage 1 thing.
Autoprofilebootstrapped and regtested on aarch64-linux-gnu.
Signed-off-by: Dhruv Chawla <dhruvc@nvidia.com>
gcc/ChangeLog:
PR gcov-profile/124075
* config/aarch64/gcc-auto-profile: Add "-o perf.data" to perf
record invocation.
* config/i386/gcc-auto-profile: Likewise.
Dhruv Chawla [Thu, 12 Feb 2026 03:57:51 +0000 (03:57 +0000)]
gcc-auto-profile: Force --inherit flag for perf record [PR123923]
This works around a bug I was seeing while testing autoprofiledbootstrap
where it appeared that perf record was only recording the make
invocation and not any of the child processes. I did not find any
configuration that would make it do so, so forcing the flag in
gcc-auto-profile will make sure that it doesn't happen regardless of
perf's settings.
Bootstrapped and regtested on aarch64-linux-gnu.
Signed-off-by: Dhruv Chawla <dhruvc@nvidia.com>
gcc/ChangeLog:
PR gcov-profile/123923
* config/aarch64/gcc-auto-profile: Add --inherit to perf record flags.
* config/i386/gcc-auto-profile: Likewise.
Sorry to be awkward, but I'd like to revert the rtlanal.cc and
config/mips/mips.md parts of r16-7265-ga9e48eca3a6eef. I think
the expr.cc part of that patch is enough to fix the bug. The other
parts seem unnecessary and are likely to regress code quality on MIPS
compared to previous releases. (See the testing below for examples.)
The rtlanal.cc part added the following code to truncated_to_mode:
/* This explicit TRUNCATE may be needed on targets that require
MODE to be suitably extended when stored in X. Targets such as
mips64 use (sign_extend:DI (truncate:SI (reg:DI x))) to perform
an explicit extension, avoiding use of (subreg:SI (reg:DI x))
which is assumed to already be extended. */
scalar_int_mode imode, omode;
if (is_a <scalar_int_mode> (mode, &imode)
&& is_a <scalar_int_mode> (GET_MODE (x), &omode)
&& targetm.mode_rep_extended (imode, omode) != UNKNOWN)
return false;
I think this has two problems. The first is that mode_rep_extended
describes a canonical form that is obtained by correctly honouring
TARGET_TRULY_NOOP_TRUNCATION. It is not an independent restriction
on what RTL optimisers can do. If we need to disable an optimisation
on MIPS-like targets, the restrictions should be based on
TARGET_TRULY_NOOP_TRUNCATION instead.
The second problem is that, although the comment treats MIPS-like
DI->SI truncation as a special case, truncated_to_mode is specifically
written for such cases. The comment above the function says:
/* Suppose that truncation from the machine mode of X to MODE is not a
no-op. See if there is anything special about X so that we can
assume it already contains a truncated value of MODE. */
Thus we're already in the realm of MIPS-like truncations that need
TRUNCATE rather than SUBREG (and that in turn guarantee sign-extension
in some cases). It's the caller that checks for that condition:
So I think the patch has the effect of disabling exactly the kind of
optimisation that truncated_to_mode is supposed to provide.
truncated_to_mode makes an implicit assumption that sign-extension is
enough to allow a SUBREG to be used in place of a TRUNCATE. This is
true for MIPS and was true for the old SH64 port. I don't know whether
it's true for gcn and nvptx, although I assume that it must be, since
no-one seems to have complained. However, it would not be true for a
port that required zero rather than sign extension (which AFAIK we've
never had).
It's probably worth noting that this assumption is in the opposite
direction from what mode_rep_extended describes. mode_rep_extended
says that "proper" truncation leads to a guarantee of sign extension.
truncated_for_mode assumes that sign extension avoids the need for
"proper" truncation. On MIPS, the former is only true for truncation
from 64 bits to 32 bits, whereas the latter is true for all cases (such
as 64 bits to 16 bits).
The old :SHORT pattern existed because QI and HI values are only
guaranteed to be sign-extensions of bit 31 of the register, not bits
7 or 15 (respectively). Thus we have the worst of both worlds:
(1) truncation from DI is not a nop. It requires a left shift by
at least 32 bits and a right shift by the same amount.
(2) sign extension to DI is not a nop. It requires a left shift and
a right shift in the normal way (by 56 bits for QI and 48 bits
for HI).
So a separate truncation and extension would yield four shifts.
The pattern above exists to reduce this to two shifts, since (2)
subsumes (1).
But the :SI case is different:
(1) truncation from DI is not a nop. It requires a left shift by 32
and a right shift by 32, as above.
(2) sign extension from SI to DI is a nop.
(2) is implemented by:
;; When TARGET_64BIT, all SImode integer and accumulator registers
;; should already be in sign-extended form (see TARGET_TRULY_NOOP_TRUNCATION
;; and truncdisi2). We can therefore get rid of register->register
;; instructions if we constrain the source to be in the same register as
;; the destination.
;;
;; Only the pre-reload scheduler sees the type of the register alternatives;
;; we split them into nothing before the post-reload scheduler runs.
;; These alternatives therefore have type "move" in order to reflect
;; what happens if the two pre-reload operands cannot be tied, and are
;; instead allocated two separate GPRs. We don't distinguish between
;; the GPR and LO cases because we don't usually know during pre-reload
;; scheduling whether an operand will be LO or not.
(define_insn_and_split "extendsidi2"
[(set (match_operand:DI 0 "register_operand" "=d,l,d")
(sign_extend:DI (match_operand:SI 1 "nonimmediate_operand" "0,0,m")))]
"TARGET_64BIT"
"@
#
#
lw\t%0,%1"
"&& reload_completed && register_operand (operands[1], VOIDmode)"
[(const_int 0)]
{
emit_note (NOTE_INSN_DELETED);
DONE;
}
[(set_attr "move_type" "move,move,load")
(set_attr "mode" "DI")])
So extending the first pattern above from :SHORT to :SUBDI is not really
an optimisation, in the sense that it doesn't add new information.
Not providing the combination allows the truncation or sign-extension
to be optimised with surrounding code.
I suppose the argument in favour of going from :SHORT to :SUBDI is
that it might avoid a move in some cases. But (a) I think that would
need to be measured further, (b) it might instead mean that the
extendsidi2 pattern needs to be tweaked for modern RA choices,
and (c) it doesn't really feel like stage 4 material.
I can understand where the changes came from. The output of combine
was clearly wrong before r16-7265-ga9e48eca3a6eef. And what combine
did looked bad. But I don't think combine itself did anything wrong.
IMO, all it did was expose the problems in the existing RTL. Expand
dropped a necessary sign-extension and the rest flowed from there.
In particular, the old decisions based on truncated_to_mode seemed
correct. The thing that the truncated_to_mode patch changed was the
assumption that a 64-bit register containing a "u16 lower" parameter
could be truncated with a SUBREG. And that's true, since it's
guaranteed by the ABI. The parameter is zero-extended from bit 16
and so the register contains a sign extension of bit 16 (i.e. 0).
And that was the information that truncated_to_mode was using.
I tested the patch on mips64-linux-gnu (all 3 ABIs). The patch fixes
regressions in:
a68: fix calls to strtol and stroll [PR algol68/124372]
This commit fixes the following problems related to parsing integer
and bits denotations:
1. strtou?l should be used only if itis 64-bit long. Otherwise, use
strtou?l.
2. Use unsigned conversions for bits denotations radix, for
consistency.
Tested in i686-linux-gnu and x86_64-linux-gnu.
Signed-off-by: Jose E. Marchesi <jemarch@gnu.org>
gcc/algol68/ChangeLog
PR algol68/124372
* a68-low-units.cc (a68_lower_denotation): Call to strtoull if
INT64_T_IS_LONG is not defined, strtol otherwise.
* a68-parser-scanner.cc (get_next_token): Use strtoul for radix
instead of strtol.
doc: Move specs documentation to GCC internals manual [PR69367] [PR69849]
The description of specs should have ended up in the GCC internals
manual instead of the user-facing documentation when the two manuals
were split many years ago.
Starting with C++11 we leverage on template parameter requirement to prevent
instantiation of methods taking iterators with invalid types.
So the _GLIBCXX_DEBUG mode do not need to check for potential ambiguity between
integer type and iterator type anymore.
Jørgen Kvalsvik [Sat, 7 Mar 2026 09:36:40 +0000 (10:36 +0100)]
Improve speed of masking table algorithm for MC/DC
The masking table was computed by considering the cartesian product of
incoming edges, ordering the pairs, and doing upwards BFS searches
from the sucessors of the lower topologically index'd ones (higher in
the graph). The problem with this approach is that all the nodes we
find from the higher candidates would also be found from the lower
candidates, and since we want to collect the set intersection, any
higher candidate would be dominated by lower candidates.
We need only consider adjacent elements in the sorted set of
candidates. This has a dramatic performance impact for large
functions. The worst case is expressions on the form (x && y && ...)
and (x || y || ...) with up-to 64 elements. I did a wallclock
comparison of the full analysis phase (including emitting the GIMPLE):
test.c:
int fn (int a[])
{
(a[0] && a[1] && ...) // 64 times
(a[0] && a[1] && ...) // 64 times
... // 500 times
}
int main ()
{
int a[64];
for (int i = 0; i != 10000; ++i)
{
for (int k = 0; k != 64; ++k)
a[k] = i % k;
fn1 (a);
}
}
Without this patch:
fn1 instrumented in 20822.303 ms (41.645 ms per expression)
With this patch:
fn1 instrumented in 1288.548 ms (2.577 ms per expression)
I also tried considering terms left-to-right and, whenever the search
found an already-processed expression it would stop the search and
just insert its complete table entry, but this had no measurable
impact on compile time, and the result was a slightly more complicated
function.
This inefficiency went unnoticed for a while, because these
expressions aren't very common. The most I've seen in the wild is 27
conditions, and that involved a lot of nested expressions which aren't
impacted as much.
gcc/ChangeLog:
* tree-profile.cc (struct conds_ctx): Add edges.
(topological_src_cmp): New function.
(masking_vectors): New search strategy.
We find (const_int 3 [0x3]) and a few others to be equivalent, among
them (reg:QI v1). This is a "fake set" that we create to help CSE extract
const_vector elements and reuse them. Element 0 is special, though.
We lowpart-subreg simplify it to (reg:QI v1) directly and, as the register
stays the same, consider it equivalent to (reg:V8QI v1).
Because both equivs refer to the same hard reg, in merge_equiv_classes, the
old (reg:V8QI) equiv is deleted and replaced by the new (reg:QI) one,
forgetting that the old equiv had 7 more elements.
Subsequently, extracting element 1 of a zero-extended QImode register results
in "0" instead of the correct "-4".
Therefore, this patch only uses those vec_select simplification that do
not directly result in a register.
PR rtl-optimization/121649
gcc/ChangeLog:
* cse.cc (find_sets_in_insn): Only use non-reg vec_select
simplifications.
Martin Uecker [Thu, 19 Feb 2026 17:20:01 +0000 (18:20 +0100)]
c: Fix ICE related to tags and hardbool attribute [PR123856]
The hardbool attribute creates special enumeration types,
but the tag is not set correctly, which causes broken diagnostics
and an ICE with the new helper function to get the tag.
David Malcolm [Fri, 6 Mar 2026 23:47:05 +0000 (18:47 -0500)]
testsuite: fix ICEs in analyzer plugin with CPython >= 3.11 [PR107646,PR112520]
In GCC 14 the testsuite gained a plugin that "teaches" the analyzer
about the CPython API, trying for find common mistakes:
https://gcc.gnu.org/wiki/StaticAnalyzer/CPython
Unfortunately, this has been crashing for more recent versions of
CPython.
Specifically, in Python 3.11, PyObject's ob_refcnt was moved to an
anonymous union (as part of PEP 683 "Immortal Objects, Using a Fixed
Refcount"). The plugin attempts to find the field but fails, but has
no error-handling, leading to a null pointer dereference.
Also, https://github.com/python/cpython/pull/101292 moved the "ob_digit"
from struct _longobject to a new field long_value of a new
struct _PyLongValue, leading to similar analyzer crashes when not
finding the field.
The following patch fixes this by
* looking within the anonymous union for the ob_refcnt field if it can't
find it directly
* gracefully handling the case of not finding "ob_digit" in PyLongObject
* doing more lookups once at plugin startup, rather than continuously on
analyzing API calls
* adding diagnostics and more error-handling to the plugin startup, so that
if it can't find something in the Python headers it emits a useful note
when disabling itself, e.g.
cc1: note: could not find field 'ob_digit' of CPython type 'PyLongObject' {aka 'struct _longobject'}
* replacing some copy-and-pasted code with member functions of a new
"class api" (though various other cleanups could be done)
Tested with:
* CPython 3.8: all tests continue to PASS
* CPython 3.13: fixes the ICEs, 2 FAILs remain (reference counting false
negatives)
Given that this is already a large patch, I'm opting to only fix the
crashes and defer the 2 remainings FAILs and other cleanups to followup
work.
gcc/analyzer/ChangeLog:
PR testsuite/112520
* region-model-manager.cc
(region_model_manager::get_field_region): Assert that the args are non-null.
gcc/testsuite/ChangeLog:
PR analyzer/107646
PR testsuite/112520
* gcc.dg/plugin/analyzer_cpython_plugin.cc: Move everything from
namespace ana:: into ana::cpython_plugin. Move global tree values
into a new "class api".
(pyobj_record): Replace with api.m_type_PyObject.
(pyobj_ptr_tree): Replace with api.m_type_PyObject_ptr.
(pyobj_ptr_ptr): Replace with api.m_type_PyObject_ptr_ptr.
(varobj_record): Replace with api.m_type_PyVarObject.
(pylistobj_record): Replace with api.m_type_PyListObject.
(pylongobj_record): Replace with api.m_type_PyLongObject.
(pylongtype_vardecl): Replace with api.m_vardecl_PyLong_Type.
(pylisttype_vardecl): Replace with api.m_vardecl_PyList_Type.
(get_field_by_name): Add "complain" param and use it to issue a
note on failure. Assert that type and name are non-null. Don't
crash on fields that are anonymous unions, and special-case
looking within them for "ob_refcnt" to work around the
Python 3.11 change for PEP 683 (immortal objects).
(get_sizeof_pyobjptr): Convert to...
(api::get_sval_sizeof_PyObject_ptr): ...this
(init_ob_refcnt_field): Convert to...
(api::init_ob_refcnt_field): ...this.
(set_ob_type_field): Convert to...
(api::set_ob_type_field): ..this.
(api::init_PyObject_HEAD): New.
(api::get_region_PyObject_ob_refcnt): New.
(api::do_Py_INCREF): New.
(api::get_region_PyVarObject_ob_size): New.
(api::get_region_PyLongObject_ob_digit): New.
(inc_field_val): Convert to...
(api::inc_field_val): ...this.
(refcnt_mismatch::refcnt_mismatch): Add tree params for refcounts
and initialize corresponding fields. Fix whitespace.
(refcnt_mismatch::emit): Use stored tree values, rather than
assuming we have constants, and crashing non-constants. Delete
commented-out dead code.
(refcnt_mismatch::foo): Delete.
(refcnt_mismatch::m_expected_refcnt_tree): New field.
(refcnt_mismatch::m_actual_refcnt_tree): New field.
(retrieve_ob_refcnt_sval): Simplify using class api.
(count_pyobj_references): Likewise.
(check_refcnt): Likewise. Don't warn on UNKNOWN values. Use
get_representative_tree for the expected and actual values and
skip the warning if it fails, rather than assuming we have
constants and crashing on non-constants.
(count_all_references): Update comment.
(kf_PyList_Append::impl_call_pre): Simplify using class api.
(kf_PyList_Append::impl_call_post): Likewise.
(kf_PyList_New::impl_call_post): Likewise.
(kf_PyLong_FromLong::impl_call_post): Likewise.
(get_stashed_type_by_name): Emit note if the type couldn't be
found.
(get_stashed_global_var_by_name): Likewise for globals.
(init_py_structs): Convert to...
(api::init_from_stashed_types): ...this. Bail out with an error
code if anything fails. Look up more things at startup, rather
than during analysis of calls.
(ana::cpython_analyzer_events_subscriber): Rename to...
(ana::cpython_plugin::analyzer_events_subscriber): ...this.
(analyzer_events_subscriber::analyzer_events_subscriber):
Initialize m_init_failed.
(analyzer_events_subscriber::on_message<on_tu_finished>):
Update for conversion of init_py_structs to
api::init_from_stashed_types and bail if it fails.
(analyzer_events_subscriber::on_message<on_frame_popped): Don't
run if plugin initialization failed.
(analyzer_events_subscriber::m_init_failed): New field.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Patrick Palka [Fri, 6 Mar 2026 22:59:11 +0000 (17:59 -0500)]
c++: ICE mangling C auto... tparm [PR124297]
After r16-7491, the constraint on a C auto... tparm is represented as a
fold-expression (in TEMPLATE_PARM_CONSTRAINTS) instead of a concept-id (in
PLACEHOLDER_TYPE_CONSTRAINTS). So we now need to strip this fold-expression
before calling write_type_constraint, like we do in the type template
parameter case a few lines below.
PR c++/124297
gcc/cp/ChangeLog:
* mangle.cc (write_template_param_decl) <case PARM_DECL>:
Strip fold-expression before calling write_type_constraint.
Andrew Pinski [Tue, 17 Feb 2026 22:03:44 +0000 (14:03 -0800)]
aarch64: Fix uint64_t[8] usage after including "arm_neon.h" [PR124126]
aarch64_init_ls64_builtins_types currently creates an array with type uint64_t[8]
and then sets the mode to V8DI. The problem here is if you used that array
type before, you would get a mode of BLK.
This causes an ICE in some cases, with the C++ front-end with -g, you would
get "type variant differs by TYPE_MODE" and in some cases even without -g,
"canonical types differ for identical types".
The fix is to do build_distinct_type_copy of the array in aarch64_init_ls64_builtins_types
before assigning the mode to that copy. We keep the same ls64 structures correct and
user provided arrays are not influenced when "arm_neon.h" is included.
Build and tested on aarch64-linux-gnu.
PR target/124126
gcc/ChangeLog:
* config/aarch64/aarch64-builtins.cc (aarch64_init_ls64_builtins_types): Copy
the array type before setting the mode.
gcc/testsuite/ChangeLog:
* g++.target/aarch64/pr124126-1.C: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
projects / thirdparty / gcc.git / log
