Sandra Loosemore [Sat, 29 Nov 2025 02:40:24 +0000 (02:40 +0000)]
doc: Fix alphabetization of FRV/FT32 option documentation sections.
The FRV and FT32 options were incorrectly alphabetized with respect to
each other in the Options Summary, the menu for the Submodel Options
section, and in the order of their respective subsections. Fixed
thusly.
gcc/ChangeLog
* doc/invoke.texi (Options Summary): Switch ordering of FRV
and FT32.
(Submodel Options): Likewise in the menu and section ordering.
doc, frv: Clean up FRV option documentation [PR122243]
frv.opt has a few options that have never been documented in the
manual. In the initial commit of the FRV port (prior to the adoption
of .opt files) they were marked as "Internal debug switch" so I have
explicitly made them "Undocumented", consistently with other options
similarly marked in the original port.
The documentation changes all straightforward here, to bring this
section into conformance with conventions being applied through this
chapter of the manual.
gcc/ChangeLog
PR other/122243
* config/frv/frv.opt (mbranch-cost=): Mark as Undocumented.
(mcond-exec-insns=): Likewise.
(mcond-exec-tempss=): Likewise.
* doc/invoke.texi (Option Summary) <FRV Options>: Remove duplicate
positive/negative forms from the list.
(FRV Options): Combine documentation of positive/negative forms
where they were listed separately. Add @opindex entries for
negative forms.
Sandra Loosemore [Tue, 18 Nov 2025 23:34:09 +0000 (23:34 +0000)]
doc, darwin: Clean up Darwin options and documentation [PR122243]
The Darwin target options documentation was a bit of a mess, with several
undocumented options, some that were listed in the option summary or mentioned
in discussion of other options but not actually documented, and a large
number of options listed in darwin.opt as being obsolete.
I've undocumented all the obsolete options to streamline things, plus a few
others that seem to have been intentially undocumented or supplanted by
other options. For the others that were probably supposed to documented,
I did my best to guess what they're for by reading the code or just
copying the documentation string in the .opt file, but it's certainly
possible I screwed some up.
gcc/ChangeLog
PR other/122243
* config/darwin.opt (findirect-virtual-calls): Mark as Undocumented.
(fterminated-vtables): Likewise.
(multi_module): Likewise.
(multiply_defined): Likewise.
(multiply_defined_unused): Likewise.
(no_dead_strip_inits_and_terms): Likewise.
(noprefixbinding): Likewise.
(nomultidefs): Likewise.
(noprebind): Likewise.
(noseglinkedit): Likewise.
(ObjC, ObjC++): Add documentation strings.
(object): Mark as Undocumented.
(prebind): Likewise.
(prebind_all_twolevel_modules): Likewise.
(private_bundle): Likewise.
(sectobjectsymbols): Likewise.
(sectorder): Likewise.
(seg_addr_table_filename): Likewise.
(segcreate): Likewise.
(seglinkedit): Likewise.
(single_module): Likewise.
(X): Likewise.
(y): Likewise.
(Mach): Likewise.
* doc/invoke.texi (Option Summary) <Darwin Options>: Improve
alphabetization of the list. Remove obsolete/undocumented
options and add missing entries.
(Darwin Options): Add documentation for -arch, -dependency-file,
-fapple-kext, -matt-stubs, -fconstant-cfstrings, -mdynamic-no-pic,
-asm_macosx_version_min, -msymbol-stubs, -mtarget-linker,
-ObjC, -ObjC++, -Wnonportable-cfstrings. Update the list
of options passed to the linker to remove obsolete options
and add missing ones; also move the block of @opindex entries
before the list items instead of putting it in the middle.
gcc/ChangeLog
PR other/122243
* doc/invoke.texi (Option Summary) <C-SKY Options>: Remove
entries for "Undocumented" options -EB, -EL, -mhard-float,
-msoft-float, and nonexistent option -mcse-cc.
(C-SKY Options): Likewise. Also remove references to "Undocumented"
option -mstm and uniformly index/document the -mno- forms for
consistency with other options in this section that already do so.
doc, cris: Clean up CRIS option documentation [PR122243]
This is another patch in the series to make documentation of
target-specific options in invoke.texi match what is in the
corresponding .opt files.
The cris.opt file is a bit strange, with many cases where negative
forms are listed explicitly as separate options from the positive
forms, with both having "RejectNegative" and one (typically the form
that is the default) being marked as "Undocumented". I've left that
alone since fixing it to the more normal style of having a single
option setting a boolean flag would require code changes, and I'm not
set up to build or test this target.
Beyond that, the "Undocumented" status of options in the .opt file did
not in several cases match what was actually documented in the manual.
I've generally assumed that the manual is correct, and e.g. the
-m32-bit, -m16-bit, and -m8-bit options, all previously marked
"Undocumented" but listed in invoke.texi, are preferred to the
equivalent options without the hyphen. I've removed the references to
the obsolete -melf and -maout options and added documentation in the
manual for some options that were previously documented only in the .opt
file.
gcc/ChangeLog
PR other/122243
* config/cris/cris.opt (m32-bit, m16-bit, m8-bit): Remove
Undocumented property.
(m32bit, m8bit): Add Undocumented property.
* doc/invoke.texi (Option Summary) <CRIS Options>: Remove
obsolete -melf and -maout options from table, plus redundant
-mno-mul-bug-workaround.
(CRIS Options): Add @opindex for -mno- forms that didn't already
have one. Remove obsolete -melf documentation. Document
-mbest-lib-options, -moverride-best-lib-options,
-mtrap-using-break8, -mtrap-unaligned-atomic, and
-munaligned-atomic-may-use-library.
doc, blackfin: Don't separately document no- form of Blackfin options [PR122243]
The documentation for Blackfin options had separate entries for the
positive and negative forms of many options, both in the Option Summary
and detailed documentation. This is unnecessarily verbose and counter
to the general rule that only one form of each option is documented.
gcc/ChangeLog
PR other/122243
* doc/invoke.texi (Option Summary) <Blackfin Options>:
Remove redundant -mno- entries.
(Blackfin Options): Combine explicit -mno-* documentation
with that for the corresponding positive form of the option.
Add @opindex entries for the negative forms of options that
didn't already have one.
doc, arm: Clean up ARM option documentation [PR122243]
This patch undocuments ARM target-specific options that have never
been implemented, are already marked as "Undocumented" in arm.opt
file, and/or are presently documented as obsolete or only useful for
back end debugging. I've also cleaned up the option summary to list
only one of the positive or negative forms of each option, and to
consistently index both forms.
gcc/ChangeLog
PR other/122243
* config/arm/arm.opt (mapcs-reentrant): Mark as "Undocumented",
updatehelp string for internal documentation.
(mapcs-stack-check): Likewise update help string.
(mprint-tune-info, mneon-for-64bits): Mark as "Undocumented".
* doc/invoke.texi (Option Summary) <ARM Options>: Remove duplicate
entries for negative forms and entries for options that are
explicitly "Undocumented". Add missing entry for
-mpic-data-is-text-relative. Fix some formatting issues.
(ARM Options): Remove documentation for -mapcs-stack-check,
-mapcs-reentrant, -mflip-thumb, -mneon-for-64-bits,
-mprint-tune-info, and -mverbose-cost-dump. Add index entries
for -mno- option forms. Minor editing for clarity.
doc, gcn: Clean up gcn target options and docs [PR122243] [PR122288]
Per PR target/122288, gcn.opt contained some invalid syntax that was
quietly accepted by the options processor. This patch fixes that,
marks some useless options as "Undocumented", and brings the
documentation into sync with the options file.
I tested the .opt file changes on both a standalone gcn build (gcc and
g++ testsuites) and in an x86_64-linux-gnu build with gcn as offload
target (libgomp).
gcc/ChangeLog
PR other/122243
PR target/122288
* config/gcn/gcn.opt (m32, m64, mgomp): Mark "Undocumented"
since these options don't actually do anything useful.
(flag_bypass_init_error, stack_size_opt, gang_size_opt): Correct
opt file syntax.
(mstack-size=): Mark "Undocumented" since it's obsolete.
* doc/invoke.texi (Option Summary) <AMD GCN Options>:
Remove obsolete options, add missing entries for
-mgang-private-size=, -msram-ecc=, and -mxnack=.
(AMD GCN Options): Likewise.
doc, epiphany: Clean up epiphany target options and docs [PR122243]
gcc/ChangeLog
PR other/122243
* config/epiphany/epiphany.opt (mlong-calls): Make it do something
useful.
(may-round-for-trunc): Make this undocumented option with a weird
name an alias for -mmay-round-for-trunc.
(mfp-iarith): Fix doc string.
* doc/invoke.texi (Option Summary) <Adapteva Epiphany Options>:
Add missing options.
(Adapteva Epiphany Options): Document negative forms also when
that is not the default, or where it's unclear. Document
-may-round-for-trunc and -mfp-iarith. Fix spelling of
-mpost-inc and -mpost-modify.
doc, aarch64: Clean up aarch64 options and documentation [PR122243]
gcc/ChangeLog
PR other/122243
* config/aarch64/aarch64.opt (Wexperimental-fmv-target): Mark
as "Undocumented".
* doc/invoke.texi (Option Summary) <AArch64 Options>: Don't
list "Undocumented" aarch64 options -mverbose-cost-dump or
-Wexperimental-fmv-target, or both positive and negative forms
of other options. Add missing options. Fix whitespace problems.
(AArch64 Options): Light copy-editing. Add missing @opindex
entries to match the documented options. Undocument
-mverbose-cost-dump and -Wexperimental-fmv-target.
Jakub Jelinek [Fri, 28 Nov 2025 21:06:30 +0000 (22:06 +0100)]
analyzer: Fix 3 C++20 warnings in analyzer
I've noticed
../../gcc/analyzer/known-function-manager.cc:86:33: warning: arithmetic between different enumeration types ‘internal_fn’ and ‘built_in_function’ is deprecated
+[-Wdeprecated-enum-enum-conversion]
../../gcc/analyzer/known-function-manager.cc:87:26: warning: arithmetic between different enumeration types ‘internal_fn’ and ‘built_in_function’ is deprecated
+[-Wdeprecated-enum-enum-conversion]
../../gcc/analyzer/known-function-manager.cc:140:33: warning: arithmetic between different enumeration types ‘internal_fn’ and ‘built_in_function’ is deprecated
+[-Wdeprecated-enum-enum-conversion]
warnings. Fixed thusly.
2025-11-28 Jakub Jelinek <jakub@redhat.com>
* known-function-manager.cc (known_function_manager::add): Avoid
arithmetics between enumerators from different enum types.
(known_function_manager::get_internal_fn): Likewise.
Jakub Jelinek [Fri, 28 Nov 2025 21:05:34 +0000 (22:05 +0100)]
powerpc: PowerPC backend, meet C++20
C++20, in particular https://wg21.link/P1120R0 paper voted into it,
deprecates various operations between enumerators from different enumeration
types etc., and as we've switched to -std=gnu++20 by default, this now
results in warnings or errors during stage2 and onwards.
The following patch should fix rs6000 build.
2025-11-28 Jakub Jelinek <jakub@redhat.com>
* config/rs6000/rs6000.cc (complex_multiply_builtin_code):
Avoid arithmetics between enumerators from different enum types.
(complex_divide_builtin_code): Likewise.
Jakub Jelinek [Fri, 28 Nov 2025 21:04:57 +0000 (22:04 +0100)]
loongarch: LoongArch backend, meet C++20
C++20, in particular https://wg21.link/P1120R0 paper voted into it,
deprecates various operations between enumerators from different enumeration
types etc., and as we've switched to -std=gnu++20 by default, this now
results in warnings or errors during stage2 and onwards.
The following patch should fix loongarch build.
2025-11-28 Jakub Jelinek <jakub@redhat.com>
* config/loongarch/loongarch.cc (loongarch_unspec_address_offset):
Avoid arithmetics between enumerators from different enum types.
(loongarch_call_tls_get_addr): Likewise.
Jakub Jelinek [Fri, 28 Nov 2025 21:04:25 +0000 (22:04 +0100)]
mips: MIPS backend, meet C++20
C++20, in particular https://wg21.link/P1120R0 paper voted into it,
deprecates various operations between enumerators from different enumeration
types etc., and as we've switched to -std=gnu++20 by default, this now
results in warnings or errors during stage2 and onwards.
The following patch should fix mips build.
2025-11-28 Jakub Jelinek <jakub@redhat.com>
* config/mips/mips.cc (mips_unspec_address_offset): Avoid
arithmetics between enumerators from different enum types.
Jakub Jelinek [Fri, 28 Nov 2025 21:03:19 +0000 (22:03 +0100)]
riscv: RISCV backend, meet C++20
C++20, in particular https://wg21.link/P1120R0 paper voted into it,
deprecates various operations between enumerators from different enumeration
types etc., and as we've switched to -std=gnu++20 by default, this now
results in warnings or errors during stage2 and onwards.
The following patch should fix riscv build.
2025-11-28 Jakub Jelinek <jakub@redhat.com>
* config/riscv/riscv-v.cc (expand_const_vector_onestep): Avoid
bitwise ops between enumerators from different enum types.
(emit_vec_cvt_x_f): Likewise.
(emit_vec_cvt_x_f_rtz): Likewise.
* config/riscv/riscv.cc (riscv_unspec_address_offset): Avoid
arithmetics between enumerators from different enum types.
Patrick Palka [Fri, 28 Nov 2025 20:38:04 +0000 (15:38 -0500)]
libstdc++: Correctly implement LWG 3946 changes to const_iterator_t [PR122842]
LWG 3946 made const_iterator_t/sentinel_t agree with ranges::cbegin/cend
by defining the aliases in terms of the CPOs, but I defined it the other
way around in an incorrect way that made the aliases not consider
range-ness of const T via __possibly_const_range. This patch
reimplements the proposed resolution in a more obviously correct way,
mirroring the wording.
PR libstdc++/122842
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (__access:_CBegin): Define in
terms of const_iterator directly, not const_iterator_t.
(__access::_CEnd): Likewise in terms of const_sentinel vs
const_sentinel_t.
(const_iterator_t): Move down definition and define in terms
of ranges::cbegin as per LWG 3946.
(const_sentinel_t): Likewise in terms of ranges::cend.
* testsuite/24_iterators/const_iterator/1.cc (test02): Correct
test for int[], std::array and std::vector. Also test
std::string.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Andrew MacLeod [Wed, 26 Nov 2025 19:21:13 +0000 (14:21 -0500)]
Undefined bitmasks imply undefined ranges.
bitmask have no way of representing UNDEFINED, and as such, bitmask
intersection returns an unknown_p values instead. This patch has the
function return false in this case, which will indicate UNDEFINED.
PR tree-optimization/122686
gcc/
* range-op.cc (operator_bitwise_and::op1_range): Check for
undefined bitmask.
* value-range.cc (prange::intersect): Handle undefined bitmask
intersection.
(irange::get_bitmask): Ditto.
(irange::intersect_bitmask): Ditto.
* value-range.h (irange_bitmask::intersect): Return false if the
result is UNDEFINED.
Tobias Burnus [Fri, 28 Nov 2025 13:56:30 +0000 (14:56 +0100)]
GCN: Use generic instead of specific arch for default-built multilibs
GCC 15 and ROCm 6.4.0 (released April/May 2025) support generic archs.
Thus, by moving to generic archs, the number of multilibs build by GCC
can be reduced - while the number of supported devices increases.
This commit now replaces the specific gfx... by gfx{9,9-4,10-3,11}-generic,
keeping gfx908 and gfx09a as no generic exists for those.
When building for a device without a multilib but the generic one exists,
there is a diagnostic like:
gcn mkoffload: fatal error: GCC was built without library support for
‘-march=gfx1150’; consider compiling for the associated generic
architecture ‘-march=gfx11-generic’ instead
As gfx900 is no longer build by default, gfx90a was picked as new
default device.
gcc/ChangeLog:
* config.gcc (amdgcn-*-*): Use gfx90a for 'with_arch'.
For TM_MULTILIB_CONFIG, replace specific archs by
gfx{9,9-4,10-3,11}-generic, keep gfx90{8,a}.
* config/gcn/gcn.opt (march=, mtune=): Use gfx90a.
* doc/install.texi (amdgcn): Update accordingly.
With the recent switch in commit r16-5628 defaulting to C++20 some
enumeration arithmetic errors are thrown during bootstrap, now. Fixed
by casting those to type int. I'm using type int here merely because
S390_ALL_BUILTIN_MAX is used in comparisons with other operands of type
int.
Tobias Burnus [Fri, 28 Nov 2025 10:44:41 +0000 (11:44 +0100)]
OpenMP/Fortran: Reject ALLOCATE on non-local static variables with trait:cgroup/pteam/thread [PR122892]
OpenMP 6.0 clarified that static-storage objects may only specify the
omp_cgroup_mem_alloc, omp_pteam_mem_alloc, or omp_thread_mem_alloc allocator
inside a BLOCK or procedure. Let's check for this for Fortran.
PR c/122892
gcc/fortran/ChangeLog:
* openmp.cc (gfc_resolve_omp_allocate): Reject non-local
static variables with cgroup/pteam/thread allocators.
* parse.cc: Permit OMP ALLOCATE in BLOCK DATA.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/allocate-15.f90: Use another allocator as
omp_{cgroup,pteam}_mem_alloc is invalid for non-local static vars.
* gfortran.dg/gomp/allocate-7.f90: Likewise.
* gfortran.dg/gomp/allocate-static-3.f90: New test.
Jakub Jelinek [Fri, 28 Nov 2025 09:59:35 +0000 (10:59 +0100)]
c++: Remove PMF special cases from cxx_get_alias_set [PR119969]
The use of 0 alias set for PMF * types seems to break modref for some reason,
but because PMFs are canonicalized, there should be no reason to special
case the alias set of PMF or PMF * anymore.
2025-11-27 Jakub Jelinek <jakub@redhat.com>
PR c++/119969
* cp-objcp-common.cc (cxx_get_alias_set): Remove special cases
for TYPE_PTRMEMFUNC_P and INDIRECT_TYPE_P for TYPE_PTRMEMFUNC_P.
Charlie Jenkins [Wed, 26 Nov 2025 19:29:51 +0000 (11:29 -0800)]
RISC-V: Support --with-cpu
The --with-cpu will allow riscv compilers to have a default mcpu flag.
Setting -mcpu or -march at compile time will override the configured
--with-cpu.
gcc/ChangeLog:
* config.gcc: Add cpu to supported configure options
* config/riscv/riscv.h (riscv_arch_help): Use --with-cpu during
compilation
* doc/install.texi: Mention in docs that --with-cpu is supported
Jakub Jelinek [Fri, 28 Nov 2025 09:04:53 +0000 (10:04 +0100)]
match.pd: Re-add (y << x) {<,<=,>,>=} x simplifications [PR122733]
Here is my attempt to implement what has been reverted in r16-5648 using ranger.
Note also the changes to the equality pattern, first of all, there
could be e.g. vector << scalar shifts, although they'll likely
fail on the nop_convert vs. nop_convert, but also it would never
match for say unsigned long long @0 and unsigned int @1 etc., pretty
common cases.
The new simplifier asks the ranger about ranges and bitmasks, verifies
@0 is non-zero and that clz of the @0 nonzero bits bitmask (i.e. the minimum
clz of all possible values of @0) is greater than (or greater than or equal
to) maximum shift count. Which one of those depends on if the actual
non-equality comparison is signed or unsigned.
And gimple_match_range_of_expr now includes in itself undefined_p check
and returns false even for that, so that many of the callers don't
need to check that.
2025-11-28 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/122733
* gimple-match-head.cc (gimple_match_range_of_expr): Return false
even when range_of_expr returns true, but the range is undefined_p.
* match.pd ((mult (plus:s@5 (mult:s@4 @0 @1) @2) @3)): Remove
vr0.undefined_p () check.
((plus (mult:s@5 (plus:s@4 @0 @1) @2) @3)): Likewise.
((X + M*N) / N -> X / N + M): Remove vr4.undefined_p () check.
((X - M*N) / N -> X / N - M): Likewise.
((y << x) == x, (y << x) != x): Use convert2? instead of
nop_convert2? and test INTEGRAL_TYPE_P on TREE_TYPE (@0) rather than
TREE_TYPE (@1).
((y << x) {<,<=,>,>=} x): New simplification.
(((T)(A)) + CST -> (T)(A + CST)): Remove vr.undefined_p () check.
(x_5 == cstN ? cst4 : cst3): Remove r.undefined_p () check.
* gcc.dg/match-shift-cmp-4.c: New test.
* gcc.dg/match-shift-cmp-5.c: New test.
Jakub Jelinek [Thu, 27 Nov 2025 19:18:57 +0000 (20:18 +0100)]
c: Fix ICE in c_type_tag on va_list [PR121506]
The C and C++ FEs disagree on what TYPE_NAME on RECORD_TYPE for
structure/class definition is (rather than typedef/using, for
those both have TYPE_NAME of TYPE_DECL with DECL_ORIGINAL_TYPE),
the C FE just uses IDENTIFIER_NODE as TYPE_NAME on RECORD_TYPE,
while the C++ FE uses TYPE_DECL as TYPENAME on RECORD_TYPE and
only DECL_NAME on the TYPE_DECL provides the IDENTIFIER_NODE.
The reason for the C++ FE way is that there can be type definitions
at class scope (rather than just typedefs) and those need to be
among TYPE_FIELDS (so the corresponding TYPE_DECL is in that chain)
etc.
The middle-end can cope with it, e.g.
if (TREE_CODE (TYPE_NAME (node)) == IDENTIFIER_NODE)
pp_tree_identifier (pp, TYPE_NAME (node));
else if (TREE_CODE (TYPE_NAME (node)) == TYPE_DECL
&& DECL_NAME (TYPE_NAME (node)))
dump_decl_name (pp, TYPE_NAME (node), flags);
and many other places.
Now, the backends on various targets create artificial structure
definitions for va_list, e.g. x86 creates struct __va_list_tag
and they do it the C++ FE way so that the C++ FE can cope with those.
Except the new c_type_tag can't deal with that and ICEs.
The following patch fixes it so that it can handle it too.
2025-11-27 Jakub Jelinek <jakub@redhat.com>
PR c/121506
* c-typeck.cc (c_type_tag): If TYPE_NAME is TYPE_DECL
with non-NULL DECL_NAME, return that.
Jakub Jelinek [Thu, 27 Nov 2025 18:04:58 +0000 (19:04 +0100)]
gccrs: Partially unbreak rust build with C++20
I've committed earlier today https://gcc.gnu.org/r16-5628 to switch C++ to
-std=gnu++20 by default. That apparently broke rust build (I don't have
cargo installed, so am not testing rust at all).
Here is a completely untested attempt to fix that.
Note, in C++20 u8"abc" literal has const char8_t[4] type rather than
const char[4] which was the case in C++17, and there is std::u8string
etc.
The casts below to (const char *) is what I've used in libcody as well
to make it compilable with all of C++11 to C++26.
Another thing is that the source for some reason expects -fexec-charset=
to be ASCII compatible and -fwide-exec-charset= to be UTF-16 or UTF-32
or something similar. That is certainly not guaranteed.
Now, if rust-lex.cc can be only compiled with C++17 or later, we
could just use u8'_' etc., but as GCC still only requires C++14, I'd
go with u'_' etc.
2025-11-27 Jakub Jelinek <jakub@redhat.com>
* lex/rust-lex.cc (rust_input_source_test): Cast char8_t string
literals to (const char *) to make it compilable with C++20. Use
char16_t or char32_t character literals instead of ordinary
character literals or wide character literals in expected
initializers.
Matthieu Longo [Mon, 24 Nov 2025 14:56:19 +0000 (14:56 +0000)]
aarch64: Define __ARM_BUILDATTR64_FV
Support for Build Attributes (BA) was originally added in [1]. To facilitate their
use in customers codebases and avoid requiring a new Autotools test for BA support,
the specification was later amended. Toolchains that generate BA sections and
support the assembler directives should define the following preprocessor macro:
__ARM_BUILDATTR64_FV <format-version>
Where <format-version> is the same value as in [2]. Currently, only version 'A'
(0x41) is defined.
This patch also introduces two tests: one that verifies the macro definition for
positive detection of BA support; and another that ensures that no such macro is
defined when BA support is absent.
[1]: 98f5547dce2503d9d0f0cd454184d6870a315538
[2]: [Formal syntax of an ELF Attributes Section](https://github.com/smithp35/
abi-aa/blob/build-attributes/buildattr64/buildattr64.rst#formal-syntax-of-an-elf
-attributes-section)
gcc/ChangeLog:
* config/aarch64/aarch64-c.cc (aarch64_define_unconditional_macros): Define
__ARM_BUILDATTR64_FV when BA support is detected in GAS.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/build-attributes/build-attribute-define-nok.c: New test.
* gcc.target/aarch64/build-attributes/build-attribute-define-ok.c: New test.
Wilco Dijkstra [Thu, 6 Nov 2025 20:49:22 +0000 (20:49 +0000)]
AArch64: Improve ctz and ffs
Use the ctz insn in the ffs expansion so it uses ctz if CSSC
is available. Rather than splitting, keep ctz as a single
insn for simplicity and possible fusion opportunities.
Move clz, ctz, clrsb, rbit and ffs instructions together.
gcc:
* config/aarch64/aarch64.md (ffs<mode>2): Use gen_ctz.
(ctz<mode>2): Model ctz as a single target instruction.
Andrew Pinski [Wed, 26 Nov 2025 21:55:41 +0000 (13:55 -0800)]
reassociation: Fix canonical ordering in some cases
This was noticed in PR122843 were sometimes reassociation
would create the uncanonical order of operands. This fixes
the problem by swapping the order as the rewrite happens.
Wstringop-overflow.c needed to be xfailed since it started
not to warn because well the warning is too dependent on
the order of operands to MIN_EXPR. This testcase
failed if we had supplied -fno-tree-reassoc before too;
but nothing in the IR changes except the order of 2 operands
of MIN_EXPR. I filed PR 122881 for this xfail.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* tree-ssa-reassoc.cc (rewrite_expr_tree): Swap
oe1 and oe2 if commutative code and not in
canonical order.
Jonathan Wakely [Thu, 27 Nov 2025 16:13:44 +0000 (16:13 +0000)]
analyzer: Add missing 'const' to equiv_class::operator==
This produces a warning in C++20:
/home/test/src/gcc/gcc/analyzer/constraint-manager.cc: In member function ‘bool ana::constraint_manager::operator==(const ana::constraint_manager&) const’:
/home/test/src/gcc/gcc/analyzer/constraint-manager.cc:1610:42: warning: C++20 says that these are ambiguous, even though the second is reversed:
1610 | if (!(*ec == *other.m_equiv_classes[i]))
| ^
/home/test/src/gcc/gcc/analyzer/constraint-manager.cc:1178:1: note: candidate 1: ‘bool ana::equiv_class::operator==(const ana::equiv_class&)’
1178 | equiv_class::operator== (const equiv_class &other)
| ^~~~~~~~~~~
/home/test/src/gcc/gcc/analyzer/constraint-manager.cc:1178:1: note: candidate 2: ‘bool ana::equiv_class::operator==(const ana::equiv_class&)’ (reversed)
/home/test/src/gcc/gcc/analyzer/constraint-manager.cc:1178:1: note: try making the operator a ‘const’ member function
Robin Dapp [Wed, 26 Nov 2025 09:27:24 +0000 (10:27 +0100)]
forwprop: Nop-convert operands if necessary [PR122855].
This fixes up r16-5561-g283eb27d5f674b where I allowed nop conversions
for the input operands. There are several paths through the function
that still require an explicit nop conversion for them. This patch adds
them.
Andrew Stubbs [Tue, 11 Nov 2025 15:41:04 +0000 (15:41 +0000)]
amdgcn: Auto-detect USM mode and set HSA_XNACK
The AMD GCN runtime must be set to the correct "XNACK" mode for Unified Shared
Memory and/or self-mapping to work, but this is not always clear at compile and
link time due to the split nature of the offload compilation pipeline.
When XNACK mode is enabled, the runtime will restart GPU load/store
instructions that fail due to memory exceptions caused by page-misses. While
this is important for shared-memory systems that might experience swapping, we
are mostly interested in it because it is also used to implement page migration
between host and GPU memory, which is the basis of USM.
This patch checks that the XNACK mode is configured appropriately in the
compiler, and mkoffload then adds a runtime check into the final program to
ensure that the HSA_XNACK environment variable passes the correct mode to the
GPU.
The HSA_XNACK variable must be set before the HSA runtime is even loaded, so
it makes more sense to have this set within the constructor than at some point
later within libgomp or the GCN plugin.
Other toolchains require the end-user to set HSA_XNACK manually (or else wonder
why it's not working), so the constructor also checks that any existing manual
setting is compatible with the binary's requirements.
gcc/ChangeLog:
* config/gcn/gcn.cc (gcn_init_cumulative_args): Emit a warning if the
-mxnack setting looks wrong.
* config/gcn/mkoffload.cc: Include tree.h and omp-general.h.
(process_asm): Add omp_requires parameter.
Emit HSA_XNACK code into mkoffload_setup, as required.
(main): Modify HSACO_ATTR_OFF to preserve user-set -mxnack.
Pass omp_requires to process_asm.
Tomasz Kamiński [Thu, 27 Nov 2025 13:31:51 +0000 (14:31 +0100)]
libstdc++: Fix exposure of TU-local lambda in __detail::__func_handle_t.
The lambda is considered to be TU-local entity, use a named function
instead.
As drive-by, a functor stored inside __func_handle::_Inplace is renamed
to _M_fn, as we no longer limit the functor type to function pointers.
libstdc++-v3/ChangeLog:
* include/std/ranges (__func_handle::__select): Named function
extracted from local lambda.
(__detail::__func_handle_t): Define using __func_handle::__select.
(__func_handle::_Inplace): Raname _M_ptr to _M_fn.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Eric Botcazou [Wed, 19 Nov 2025 08:45:05 +0000 (09:45 +0100)]
ada: Couple of minor fixes for build-in-place calls in anonymous contexts
The current code does not deal with all the anonymous contexts uniformly,
since it potentially creates an activation chain and a master only in the
case of an actual in a call; moreover, the master is created in the scope
of the actual's type, instead of in the context of the call like the chain.
The change also aligns Make_Build_In_Place_Call_In_Anonymous_Context with
sibling routines by calling Make_Build_In_Place_Call_In_Object_Declaration
directly instead of letting the expander recursively do it. It also adds
a missing rewriting in Make_Build_In_Place_Iface_Call_In_Anonymous_Context.
gcc/ada/ChangeLog:
* exp_ch6.adb (Expand_Actuals): Do not create activation chain and
master for build-in-place calls here but...
(Make_Build_In_Place_Call_In_Allocator): Use Unqual_Conv.
(Make_Build_In_Place_Call_In_Anonymous_Context): ...here instead.
Call Make_Build_In_Place_Call_In_Object_Declaration directly.
(Make_Build_In_Place_Iface_Call_In_Anonymous_Context): ...and here
instead. Add missing rewriting of the call.
Eric Botcazou [Wed, 19 Nov 2025 07:39:20 +0000 (08:39 +0100)]
ada: Fix undefined reference with inline subprogram containing generic instance
The problem is that, for an inline subprogram declared in an instance, the
cross-unit inlining machinery does not have the body by the time it decides
to inline calls to the subprogram, because the instantiation of bodies is
deferred until the end of the compilation. So it cannot see whether this
body contains excluded declarations or statements by that time, typically
nested packages or instances thereof.
The fix is to check that Is_Inlined is still set on the subprogram before
passing it on to the back-end for cross-unit inlining. It also removes an
obsolete check that was done precisely there.
This also adjusts the description of the -gnatwp switch, which can be used
to get the reason why cross-inlining has failed, for example here:
g.ads:4:01: warning: in instantiation at generic_si.adb:60 [-gnatwp]
g.ads:4:01: warning: cannot inline "*" (nested package instantiation)
gcc/ada/ChangeLog:
PR ada/122574
* doc/gnat_ugn/building_executable_programs_with_gnat.rst (-gnatwp):
Replace reference to -gnatN with -gnatn and adjust accordingly.
* inline.adb: Remove clauses for Exp_Tss.
(Has_Initialized_Type): Delete.
(Add_Inlined_Subprogram): Test that the Is_Inlined flag is still set
on the subprogram.
* usage.adb (Usage): Adjust description of -gnatwp.
* gnat_ugn.texi: Regenerate.
Denis Mazzucato [Mon, 17 Nov 2025 10:54:10 +0000 (11:54 +0100)]
ada: Fix spurious error during record initialization of limited types
This patch fixes the spurious error regarding assignment to limited types.
Inside record initialization, the assignment calling a constructor is actually
its initialization, and is considered legal.
gcc/ada/ChangeLog:
* sem_ch5.adb: Skip check for assignment that doesn't come from source.
ada: Fix spurious exceptions with iterated aggregates
When an array aggregate has an iterated component association over a
range that we know is empty, we don't create a loop during expansion but
we still analyze the expression of the component association in a
unusual context.
Before this patch, this analysis could incorrectly insert actions in an
enclosing scope. This patch fixes it by only doing preanalysis of the
expression in that case.
gcc/ada/ChangeLog:
* exp_aggr.adb (Gen_Loop): Only preanalyze expressions we know won't
evaluated.
Tom Tromey [Tue, 23 Sep 2025 15:36:47 +0000 (09:36 -0600)]
ada: Add Visitor generic to Repinfo
For a gnat-llvm debuginfo patch, it was convenient to be able to
inspect the expressions created during back-annotation. This patch
adds a new generic Visit procedure that can be implemented to allow
such inspection. List_GCC_Expression is reimplemented in terms of
this procedure as a proof of concept.
gcc/ada/ChangeLog:
* repinfo.adb (Visit): New procedure.
(List_GCC_Expression): Rewrite.
* repinfo.ads (Visit): New generic procedure.
VADS inline assembly works by using a qualified expression for one of
the types defined in the Machine_Code package, e.g.
procedure P is
begin
code_2'(INSTR, OPERAND1, OPERAND2);
end y;
This is different from GNAT's own inline assembly machinery, which
instead expects a call to Machine_Code.ASM with a set of
differently-typed arguments.
This incompatibility is preventing GNATSAS' GNAT-Warnings engine from
analyzing VADS code, hence we adapt sem_ch13.adb to not fail on such
constructs when GNAT is running under both Check_Semantics_Only_Mode and
Relaxed_RM_Semantics mode.
gcc/ada/ChangeLog:
* sem_ch13.adb (Analyze_Code_Statement): Do not emit error
message when only checking relaxed semantics.
Eric Botcazou [Fri, 14 Nov 2025 21:39:51 +0000 (22:39 +0100)]
ada: Streamline processing for shared passive and protected objects
The Add_Shared_Var_Lock_Procs procedure in Exp_Smem contains a very ad-hoc
management of transient scopes, which is probably unavoidable but can be
streamlined by changing the insertion point of the finalizer to be the one
used in the presence of controlled objects.
However, the latter change badly interacts with the special processing of
protected subprogram bodies implemented in Build_Finalizer_Call. Now this
processing is obsolete after the recent overhaul of the expansion of these
protected subprogram bodies and can be entirely removed.
No functional changes.
gcc/ada/ChangeLog:
* exp_ch7.adb (Build_Finalizer_Call): Delete.
(Build_Finalizer): Always insert the finalizer at the end of the
statement list in the non-package case.
(Expand_Cleanup_Actions): Attach the finalizer manually, if any.
* exp_smem.adb (Add_Shared_Var_Lock_Procs): Insert all the actions
directly in the transient scope.
Eric Botcazou [Sun, 16 Nov 2025 13:29:39 +0000 (14:29 +0100)]
ada: Couple of small and unrelated cleanups
No functional changes.
gcc/ada/ChangeLog:
* exp_ch11.adb (Expand_N_Handled_Sequence_Of_Statement): Merge the
eslif condition with the if condition for cleanup actions.
* sem_ch6.adb (Analyze_Procedure_Call.Analyze_Call_And_Resolve): Get
rid of if statement whose condition is always true.
* sinfo.ads (Finally_Statements): Document their purpose.
Eric Botcazou [Mon, 17 Nov 2025 07:45:21 +0000 (08:45 +0100)]
ada: Streamline implementation of masters in Exp_Ch9
The incidental discovery of an old issue and its resolution has exposed the
convoluted handling of masters in Exp_Ch9, which uses two totally different
approaches to achieve the same goal, respectively in Build_Master_Entity and
Build_Class_Wide_Master, the latter being quite hard to follow. The handling
of activation chains for extended return statements is also a bit complex.
This gets rid of the second approach entirely for masters, as well as makes
the handling of activation chains uniform for all nodes.
No functional changes.
gcc/ada/ChangeLog:
* gen_il-gen-gen_nodes.adb (N_Extended_Return_Statement): Add
Activation_Chain_Entity semantic field.
* exp_ch3.adb (Build_Master): Use Build_Master_{Entity,Renaming} in
all cases.
(Expand_N_Object_Declaration): Small tweak.
* exp_ch6.adb (Make_Build_In_Place_Iface_Call_In_Allocator): Use
Build_Master_{Entity,Renaming} to build the master.
* exp_ch7.adb (Expand_N_Package_Declaration): Do not guard the call
to Build_Task_Activation_Call for the sake of consistency.
* exp_ch9.ads (Build_Class_Wide_Master): Delete.
(Find_Master_Scope): Likewise.
(Build_Protected_Subprogram_Call_Cleanup): Move to...
(First_Protected_Operation): Move to...
(Mark_Construct_As_Task_Master): New procedure.
* exp_ch9.adb (Build_Protected_Subprogram_Call_Cleanup): ...here.
(First_Protected_Operation): ...here.
(Build_Activation_Chain_Entity): Streamline handling of extended
return statements.
(Build_Class_Wide_Master): Delete.
(Build_Master_Entity): Streamline handling of extended return
statements and call Mark_Construct_As_Task_Master on the context.
(Build_Task_Activation_Call): Assert that the owner is not an
extended return statement.
(Find_Master_Scope): Delete.
(Mark_Construct_As_Task_Master): New procedure.
* sem_ch3.adb (Access_Definition): Use Build_Master_{Entity,Renaming}
in all cases to build a master.
* sem_ch6.adb (Check_Anonymous_Return): Rename to...
(Check_Anonymous_Access_Return_With_Tasks): ...this. At the end,
call Mark_Construct_As_Task_Master on the parent node.
(Analyze_Subprogram_Body_Helper): Adjust to above renaming.
(Create_Extra_Formals): Do not set Has_Master_Entity here.
* sinfo.ads (Activation_Chain_Entity): Adjust description.
Bob Duff [Fri, 14 Nov 2025 21:29:45 +0000 (16:29 -0500)]
ada: VAST found bug: Missing Parent in annotate aspect
In case of an Annotate aspect of the form "Annotate => Expr",
where Expr is an identifier (as opposed to an aggregate),
the Parent field of the N_Identifier node for Expr was
destroyed. This patch changes the code that turns the aspect
into a pragma, so that it no longer has that bug.
The problem was in "New_List (Expr)"; which sets the Parent of
Expr to Empty. But Expr is still part of the tree of the aspect,
so it should have a proper Parent; we can't just stick it in a
temporary list.
The new algorithm constructs the pragma arguments without disturbing
the tree of the aspect.
This is the last known case of missing Parent fields, so we can
now enable the VAST check that detected this bug.
gcc/ada/ChangeLog:
* sem_ch13.adb (Aspect_Annotate): Avoid disturbing the tree of the
aspect.
* vast.adb: Enable Check_Parent_Present.
* exp_ch6.adb (Validate_Subprogram_Calls): Minor reformatting.
Eric Botcazou [Thu, 13 Nov 2025 20:12:54 +0000 (21:12 +0100)]
ada: Fix fallout of recent finalization fix for limited types
The recent finalization fix made for limited types has uncovered cases where
the object returned by calls to build-in-place functions was not finalized
in selected anonymous contexts, most notably the dependent expressions of
conditional expressions. The specific finalization machinery that handles
conditional expressions requires the temporaries built for their dependent
expressions to be visible as early as possible, and this was not the case.
gcc/ada/ChangeLog:
* exp_ch4.adb (Expand_N_Case_Expression): When not optimizing for a
specific context, call Make_Build_In_Place_Call_In_Anonymous_Context
on expressions of alternatives when they are calls to BIP functions.
(Expand_N_If_Expression): Likewise for the Then & Else expressions.
Bob Duff [Thu, 13 Nov 2025 16:40:55 +0000 (11:40 -0500)]
ada: VAST: Check basic tree properties
Miscellaneous improvements to VAST. Mostly debugging improvements.
Move the call to VAST from Frontend to Gnat1drv, because
there is code AFTER the call to Frontend that notices
certain errors, and disables the back end. We want VAST
to be enabled only when the back end will be called.
This is needed to enable Check_Error_Nodes, among other
things.
gcc/ada/ChangeLog:
* frontend.adb: Move call to VAST from here...
* gnat1drv.adb: ...to here.
* vast.ads (VAST_If_Enabled): Rename main entry point of VAST from
VAST to VAST_If_Enabled.
* vast.adb: Miscellaneous improvements. Mostly debugging
improvements. Also enable Check_Error_Nodes. Also add checks:
Check_FE_Only, Check_Scope_Present, Check_Scope_Correct.
* debug.ads: Minor comment tweaks. The comment, "In the checks off
version of debug, the call to Set_Debug_Flag is always a null
operation." appears to be false, so is removed.
* debug.adb: Minor: Remove some code duplication.
* sinfo-utils.adb (nnd): Add comment warning about C vs. Ada
confusion.
Eric Botcazou [Thu, 13 Nov 2025 08:16:52 +0000 (09:16 +0100)]
ada: Fix missing activation of task returned through class-wide type
This fixes an old issue whereby a task returned through the class-wide type
of a limited record type is not activated by the caller, because it is not
moved onto the activation chain that the caller passes to the function.
gcc/ada/ChangeLog:
* exp_ch6.ads (Needs_BIP_Task_Actuals): Adjust description.
* exp_ch6.adb (Expand_N_Extended_Return_Statement): Move activation
chain for every build-in-place function with task formal parameters
when the type of the return object might have tasks.
A recent patch made Multi_Module_Symbolic_Traceback have two consecutive
formal parameters of type Boolean, which opens the door for mixing up
actual parameters in calls. And that mistake was actually made in a call
introduced by the same patch.
This commit fixes the call and also introduces a new enumerated type to
make this kind of mistake less likely in the future.
gcc/ada/ChangeLog:
* libgnat/s-dwalin.ads (Display_Mode_Type): New enumerated type.
(Symbolic_Traceback): Use new type in profile.
* libgnat/s-dwalin.adb (Symbolic_Traceback): Use new type in profile
and adapt body.
* libgnat/s-trasym__dwarf.adb (Multi_Module_Symbolic_Traceback): Fix
wrong call in body of one overload. Use new type in profile. Adapt
body.
(Symbolic_Traceback, Symbolic_Traceback_No_Lock,
Module_Symbolic_Traceback): Use new type in profile and adapt body.
(Calling_Entity): Adapt body.
Jakub Jelinek [Thu, 27 Nov 2025 12:55:17 +0000 (13:55 +0100)]
bitint: Fix up big-endian handling in limb_access [PR122714]
The bitint_extended changes in limb_access broke bitint_big_endian.
As we sometimes (for bitint_extended) access the MEM_REFs using
atype rather than m_limb_type, for big-endian we need to adjust
the MEM_REFs offset if atype has smaller TYPE_SIZE_UNIT than m_limb_size.
2025-11-27 Jakub Jelinek <jakub@redhat.com>
PR target/122714
* gimple-lower-bitint.cc (bitint_large_huge::limb_access): Adjust
MEM_REFs offset for bitint_big_endian if ltype doesn't have the
same byte size as m_limb_type.
Richard Biener [Thu, 27 Nov 2025 09:56:43 +0000 (10:56 +0100)]
Fix OMP SIMD clone mask record/get again
Post-CI checkin detected aarch64 fallout for the last change. AARCH64
has ABI twists that run into a case where an unmasked call when loop
masked allows for a mask that has different shape than that of the
return value which in turn has different type than that of an actual
argument.
While we do not support a mismatch of call mask shape with the
OMP SIMD ABI mask shape when there's no call mask we have no such
restriction.
So the following fixes the record/get of a loop mask in the unmasked
call case, also fixing a latent issue present before. In particular
do not record a random scalar operand as representing the mask.
A testcase is in gcc.target/aarch64/vect-simd-clone-4.c.
* tree-vect-stmts.cc (vectorizable_simd_clone_call): Fix
recording of the mask type again. Adjust placing of
mask arguments for non-masked calls.
Dhruv Chawla [Thu, 27 Nov 2025 11:12:33 +0000 (12:12 +0100)]
remove patterns for (y << x) {<,<=,>,>=} x [PR122733]
These patterns should not be in match.pd as they require range
information checks that ideally belong in VRP. They were also causing
breakages as the checks weren't tight enough.
PR tree-optimization/122733
* match.pd ((y << x) {<,<=,>,>=} x): Remove.
((y << x) {==,!=} x): Call constant_boolean_node instead of
build_one_cst/build_zero_cst and combine into one pattern.
* gcc.dg/match-shift-cmp-1.c: Update test to only check
equality.
* gcc.dg/match-shift-cmp-2.c: Likewise.
* gcc.dg/match-shift-cmp-3.c: Likewise.
* gcc.dg/match-shift-cmp-4.c: Removed.
Jakub Jelinek [Thu, 27 Nov 2025 10:57:02 +0000 (11:57 +0100)]
fold-const, match.pd: Pass stmt to expr_not_equal if possible
The following patch is a small extension of the previous patch to pass stmt
context to the ranger queries from match.pd where possible, so that we can
use local ranges on a particular statement rather than global ones.
expr_not_equal_to also uses the ranger, so when possible this passes it
the statement context.
2025-11-27 Jakub Jelinek <jakub@redhat.com>
* fold-const.h (expr_not_equal_to): Add gimple * argument defaulted
to NULL.
* fold-const.cc (expr_not_equal_to): Likewise, pass it through to
range_of_expr.
* generic-match-head.cc (gimple_match_ctx): New static inline.
* match.pd (X % -Y -> X % Y): Capture NEGATE and pass
gimple_match_ctx (@2) as new 3rd argument to expr_not_equal_to.
((A * C) +- (B * C) -> (A+-B) * C): Pass gimple_match_ctx (@3)
as new 3rd argument to expr_not_equal_to.
(a rrotate (bitsize-b) -> a lrotate b): Likewise.
On Wed, Nov 26, 2025 at 09:52:50AM +0100, Richard Biener wrote:
> I wonder if it makes sense to wrap
> get_range_query (cfun)->range_of_expr (r, @0, gimple_match_ctx (@4))
> into sth like gimple_match_range_of_expr (r, @0, @4)?
It does make sense, so the following patch implements that.
Note, gimple-match.h is a bad location for that helper, because
lots of users use it without having value-range.h included and
it is for APIs to use the gimple folders, not for match.pd helpers
themselves, so I've moved there gimple_match_ctx as well.
2025-11-27 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/119683
* gimple-match.h (gimple_match_ctx): Move to ...
* gimple-match-head.cc (gimple_match_ctx): ... here. Make static.
(gimple_match_range_of_expr): New static inline.
* match.pd ((mult (plus:s (mult:s @0 @1) @2) @3)): Use
gimple_match_range_of_expr.
((plus (mult:s (plus:s @0 @1) @2) @3)): Likewise.
((t * u) / u -> t): Likewise.
((t * u) / v -> t * (u / v)): Likewise.
((X + M*N) / N -> X / N + M): Likewise.
((X - M*N) / N -> X / N - M): Likewise.
((X + C) / N -> X / N + C / N): Likewise.
(((T)(A)) + CST -> (T)(A + CST)): Likewise
(x_5 == cstN ? cst4 : cst3): Likewise. Do r.set_varying
even when gimple_match_range_of_expr failed.
Richard Biener [Thu, 27 Nov 2025 09:04:19 +0000 (10:04 +0100)]
tree-optimization/122885 - avoid re-using accumulator for some bool vectors
When boolean vectors do not use vector integer modes we are not
set up to produce the partial epilog in a correctly typed way,
so avoid this situation. For the integer mode case we are able
to pun things correctly, so keep that working.
PR tree-optimization/122885
* tree-vect-loop.cc (vect_find_reusable_accumulator): Reject
mask vectors which do not use integer vector modes.
(vect_create_partial_epilog): Assert the same.
Jonathan Wakely [Sat, 15 Nov 2025 18:19:28 +0000 (18:19 +0000)]
libstdc++: Future-proof C++20 atomic wait/notify
This will allow us to extend atomic waiting functions to support a
possible future 64-bit version of futex, as well as supporting
futex-like wait/wake primitives on other targets (e.g. macOS has
os_sync_wait_on_address and FreeBSD has _umtx_op).
Before this change, the decision of whether to do a proxy wait or to
wait on the atomic variable itself was made in the header at
compile-time, which makes it an ABI property that would not have been
possible to change later. That would have meant that
std::atomic<uint64_t> would always have to do a proxy wait even if Linux
gains support for 64-bit futex2(2) calls at some point in the future.
The disadvantage of proxy waits is that several distinct atomic objects
can share the same proxy state, leading to contention between threads
even when they are not waiting on the same atomic object, similar to
false sharing. It also result in spurious wake-ups because doing a
notify on an atomic object that uses a proxy wait will wake all waiters
sharing the proxy.
For types that are known to definitely not need a proxy wait (e.g. int
on Linux) the header can still choose a more efficient path at
compile-time. But for other types, the decision of whether to do a proxy
wait is deferred to runtime, inside the library internals. This will
make it possible for future versions of libstdc++.so to extend the set
of types which don't need to use proxy waits, without ABI changes.
The way the change works is to stop using the __proxy_wait flag that was
set by the inline code in the headers. Instead the __wait_args struct
has an extra pointer member which the library internals populate with
either the address of the atomic object or the _M_ver counter in the
proxy state. There is also a new _M_obj_size member which stores the
size of the atomic object, so that the library can decide whether a
proxy is needed. So for example if linux gains 64-bit futex support then
the library can decide not to use a proxy when _M_obj_size == 8.
Finally, the _M_old member of the __wait_args struct is changed to
uint64_t so that it has room to store 64-bit values, not just whatever
size the __platform_wait_t type is (which is a 32-bit int on Linux).
Similarly, the _M_val member of __wait_result_type changes to uint64_t
too.
libstdc++-v3/ChangeLog:
* config/abi/pre/gnu.ver: Adjust exports.
* include/bits/atomic_timed_wait.h (_GLIBCXX_HAVE_PLATFORM_TIMED_WAIT):
Do not define this macro.
(__atomic_wait_address_until_v, __atomic_wait_address_for_v):
Adjust assertions to check that __platform_wait_uses_type is
true.
* include/bits/atomic_wait.h (__waitable): New concept.
(__platform_wait_uses_type): Different separately for platforms
with and without platform wait.
(_GLIBCXX_HAVE_PLATFORM_WAIT): Do not define this macro.
(__wait_value_type): New typedef.
(__wait_result_type): Change _M_val to __wait_value_type.
(__wait_flags): Remove __proxy_wait enumerator. Reduce range
reserved for ABI version by the commented-out value.
(__wait_args_base::_M_old): Change type to __wait_args_base.
(__wait_args_base::_M_obj, __wait_args_base::_M_obj_size): New
data members.
(__wait_args::__wait_args): Set _M_obj and _M_obj_size on
construction.
(__wait_args::_M_setup_wait): Change void* parameter to deduced
type. Adjust bit_cast to work for types of different sizes.
(__wait_args::_M_load_proxy_wait_val): Remove function, replace
with ...
(__wait_args::_M_setup_proxy_wait): New function.
(__wait_args::_S_flags_for): Do not set __proxy_wait flag.
(__atomic_wait_address_v): Adjust assertion to check that
__platform_wait_uses_type is true.
* src/c++20/atomic.cc (_GLIBCXX_HAVE_PLATFORM_WAIT): Define here
instead of in header. Check _GLIBCXX_HAVE_PLATFORM_WAIT instead
of _GLIBCXX_HAVE_PLATFORM_TIMED_WAIT.
(__platform_wait, __platform_notify, __platform_wait_until): Add
unused parameter for _M_obj_size.
(__spin_impl): Adjust for 64-bit __wait_args_base::_M_old.
(use_proxy_wait): New function.
(__wait_args::_M_load_proxy_wait_val): Replace with ...
(__wait_args::_M_setup_proxy_wait): New function. Call
use_proxy_wait to decide at runtime whether to wait on the
pointer directly instead of using a proxy. If a proxy is needed,
set _M_obj and _M_obj_size to refer to its _M_ver member. Adjust
for change to type of _M_old.
(__wait_impl): Wait on _M_obj unconditionally. Pass _M_obj_size
to __platform_wait.
(__notify_impl): Call use_proxy_wait to decide whether to notify
on the address parameter or a proxy
(__spin_until_impl): Adjust for change to type of _M_val.
(__wait_until_impl): Wait on _M_obj unconditionally. Pass
_M_obj_size to __platform_wait_until.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jonathan Wakely [Wed, 26 Nov 2025 14:44:03 +0000 (14:44 +0000)]
libstdc++: Fix std::counting_semaphore<> default max value
My recent (uncommitted) changes to support a 64-bit __platform_wait_t
for FreeBSD and Darwin revealed a problem in std::counting_semaphore.
When the default template argument is used and __platform_wait_t is a
64-bit type, the numeric_limits<__platform_wait_t>::max() value doesn't
fit in ptrdiff_t and so we get ptrdiff_t(-1), which fails a
static_assert in the class body.
The solution is to cap the value to PTRDIFF_MAX instead of allowing it
to go negative.
libstdc++-v3/ChangeLog:
* include/bits/semaphore_base.h (__platform_semaphore::_S_max):
Limit to PTRDIFF_MAX to avoid negative values.
* testsuite/30_threads/semaphore/least_max_value.cc: New test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
liuhongt [Tue, 25 Nov 2025 05:33:46 +0000 (21:33 -0800)]
Refactor mgather/mscatter implementation.
Current implementation is an alias to -mtune-crtl=(Alias(mtune-ctrl=,
use_gather, ^use_gather)), and maybe override by another -mtune-crtl=
.i.e -mgather -mscatter will only enable mscatter
The patch fixes the issue.
gcc/ChangeLog:
* config/i386/i386-options.cc (set_ix86_tune_features): Set
gather/scatter tune if OPTION_SET_P.
* config/i386/i386.opt: Refactor mgather/mscatter.
Lulu Cheng [Mon, 24 Nov 2025 09:03:49 +0000 (17:03 +0800)]
LoongArch: fmv: Fix compilation errors when using glibc versions earlier than 2.38.
The macros HWCAP_LOONGARCH_LSX and HWCAP_LOONGARCH_LASX were defined
in glibc 2.38. However, r16-5155 uses these two macros directly
without checking whether they are defined. This causes errors when
compiling libgcc with glibc versions earlier than 2.38.
gcc/ChangeLog:
* doc/extend.texi: Remove the incorrect prompt message.
libgcc/ChangeLog:
* config/loongarch/cpuinfo.c (HWCAP_LOONGARCH_LSX): Define
it if it is not defined.
(HWCAP_LOONGARCH_LASX): Likewise.
Sandra Loosemore [Thu, 27 Nov 2025 01:25:33 +0000 (01:25 +0000)]
doc: Add --compile-std-module to option summary
Commit 3ad2e2d707c3d6b0c6bd8c3ef0df4f7aaee1c3c added documentation
for this new C++ option, but missed also adding it to the corresponding
Option Summary list.
* c-parser.cc (c_parser_maxof_or_minof_expression): New func.
(c_parser_unary_expression): Add RID_MAXOF & RID_MINOF cases.
* c-tree.h (c_expr_maxof_type): New prototype.
(c_expr_minof_type): New prototype.
* c-typeck.cc (c_expr_maxof_type): New function.
(c_expr_minof_type): New function.
gcc/testsuite/ChangeLog:
* gcc.dg/maxof-bitint.c: New test.
* gcc.dg/maxof-bitint575.c: New test.
* gcc.dg/maxof-compile.c: New test.
* gcc.dg/maxof-pedantic-errors.c: New test.
* gcc.dg/maxof-pedantic.c: New test.
Tamar Christina [Wed, 26 Nov 2025 22:00:07 +0000 (22:00 +0000)]
middle-end: guard against non-single use compares in emit_cmp_and_jump_insns
When I wrote this optimization my patch stack included a change in
tree-out-of-ssa that would duplicate the compares such that the
use is always single use and get_gimple_for_ssa_name would always
succeed.
However I have dropped that for GCC 16 since I didn't expect the
vectorizer to be able to produce duplicate uses of the same
compare results.
But I neglected that you can get it by other means. So this simply
checks that get_gimple_for_ssa_name succeeds for the LEN cases.
The non-LEN cases already check it earlier on.
To still get the optimization in this case the tree-out-of-ssa
change is needed, which is staged for next stage-1.
gcc/ChangeLog:
* optabs.cc (emit_cmp_and_jump_insns): Check for non-single use.
Jeff Law [Wed, 26 Nov 2025 21:52:11 +0000 (14:52 -0700)]
[RISC-V][PR rtl-optimization/122735] Avoid bogus calls to simplify_subreg
Recent changes to simplify_binary_operation_1 reassociate a SUBREG expression
in useful ways. But they fail to account for the asserts at the beginning of
simplify_subreg.
In particular simplify_subreg asserts that the mode can not be VOID or BLK --
the former being the problem here as it's used on CONST_INT nodes which may
appear in an unsimplified REG_EQUAL note like:
That triggers the new code in simplify-rtx to push the subreg into an inner
object. In particular it'll try to push the subreg to the first operand of the
LSHIFTRT. We pass that to simplify_subreg via simplify_gen_subreg and boom!
You could legitimately ask why the original note wasn't simplified further or
removed. That approach could certainly be used to fix this specific problem.
But we've never had that kind of requirement on REG_EQUAL notes and I think it
opens up a huge can of worms if we impose it now. So I chose to make the
newer simplify-rtx code more robust.
Bootstrapped and regression tested on x86_64 and riscv and tested on the
various embedded targets without regressions. I'll wait for the pre-commit CI
tester before committing.
PR rtl-optimization/122735
gcc/
* simplify-rtx.cc (simplify_binary_operation_1): When moving a SUBREG
from an outer expression to an inner operand, make sure to avoid
trying to create invalid SUBREGs.
Declare target's 'link' clause disallows 'nohost'; check for it.
Additionally, some other cleanups have been done.
The 'local' clause to 'declare target' is now supported in the FE,
but a 'sorry, unimplemented' is printed at TREE generation time.
This commit also adds the 'groupprivate' directive, which implies
'declare target' with the 'local' clause. And for completeness also
the 'dyn_groupprivate' clause to 'target'. However, all those new
features will eventually print 'sorry, unimplemented' for now.
gcc/fortran/ChangeLog:
* dump-parse-tree.cc (show_attr): Handle OpenMP's 'local' clause
and the 'groupprivate' directive.
(show_omp_clauses): Handle dyn_groupprivate.
* frontend-passes.cc (gfc_code_walker): Walk dyn_groupprivate.
* gfortran.h (enum gfc_statement): Add ST_OMP_GROUPPRIVATE.
(enum gfc_omp_fallback, gfc_add_omp_groupprivate,
gfc_add_omp_declare_target_local): New.
* match.h (gfc_match_omp_groupprivate): New.
* module.cc (enum ab_attribute, mio_symbol_attribute, load_commons,
write_common_0): Handle 'groupprivate' + declare target's 'local'.
* openmp.cc (gfc_omp_directives): Add 'groupprivate'.
(gfc_free_omp_clauses): Free dyn_groupprivate.
(enum omp_mask2): Add OMP_CLAUSE_LOCAL and OMP_CLAUSE_DYN_GROUPPRIVATE.
(gfc_match_omp_clauses): Match them.
(OMP_TARGET_CLAUSES): Add OMP_CLAUSE_DYN_GROUPPRIVATE.
(OMP_DECLARE_TARGET_CLAUSES): Add OMP_CLAUSE_LOCAL.
(gfc_match_omp_declare_target): Handle groupprivate + fixes.
(gfc_match_omp_threadprivate): Code move to and calling now ...
(gfc_match_omp_thread_group_private): ... this new function.
Also handle groupprivate.
(gfc_match_omp_groupprivate): New.
(resolve_omp_clauses): Resolve dyn_groupprivate.
* parse.cc (decode_omp_directive): Match groupprivate.
(case_omp_decl, parse_spec, gfc_ascii_statement): Handle it.
* resolve.cc (resolve_symbol): Handle groupprivate.
* symbol.cc (gfc_check_conflict, gfc_copy_attr): Handle 'local'
and 'groupprivate'.
(gfc_add_omp_groupprivate, gfc_add_omp_declare_target_local): New.
* trans-common.cc (build_common_decl,
accumulate_equivalence_attributes): Print 'sorry' for
groupprivate and declare target's local.
* trans-decl.cc (add_attributes_to_decl): Likewise..
* trans-openmp.cc (gfc_trans_omp_clauses): Print 'sorry' for
dyn_groupprivate.
(fallback): Process declare target with link/local as
done for 'enter'.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/crayptr2.f90: Move dg-error line.
* gfortran.dg/gomp/declare-target-2.f90: Extend.
* gfortran.dg/gomp/declare-target-4.f90: Update comment,
enable one test.
* gfortran.dg/gomp/declare-target-5.f90: Update dg- wording,
add new test.
* gfortran.dg/gomp/declare-target-indirect-2.f90: Expect
'device_type(any)' in scan-tree-dump.
* gfortran.dg/gomp/declare-target-6.f90: New test.
* gfortran.dg/gomp/dyn_groupprivate-1.f90: New test.
* gfortran.dg/gomp/dyn_groupprivate-2.f90: New test.
* gfortran.dg/gomp/groupprivate-1.f90: New test.
* gfortran.dg/gomp/groupprivate-2.f90: New test.
* gfortran.dg/gomp/groupprivate-3.f90: New test.
* gfortran.dg/gomp/groupprivate-4.f90: New test.
* gfortran.dg/gomp/groupprivate-5.f90: New test.
* gfortran.dg/gomp/groupprivate-6.f90: New test.
Marek Polacek [Mon, 24 Nov 2025 22:31:22 +0000 (17:31 -0500)]
c++: fix crash with pack indexing in noexcept [PR121325]
In my r15-6792 patch I added a call to tsubst in tsubst_pack_index
to fully instantiate args#N in the pack.
Here we are in an unevaluated context, but since the pack is
a TREE_VEC, we call tsubst_template_args which has cp_evaluated
at the beginning. That causes a crash because we trip on the
assert in tsubst_expr/PARM_DECL:
gcc_assert (cp_unevaluated_operand);
because retrieve_local_specialization didn't find anything (becase
there are no local_specializations yet).
We can avoid the cp_evaluated by calling the new tsubst_tree_vec,
which creates a new TREE_VEC and substitutes each element.
PR c++/121325
gcc/cp/ChangeLog:
* pt.cc (tsubst_tree_vec): New.
(tsubst_pack_index): Call it.
The CBN?Z instructions have a very small range (just 128 bytes
forwards). The compiler knows how to handle cases where we
exceed that, but only if the range remains within that which
a condition branch can support. When compiling some machine
generated code it is not too difficult to exceed this limit,
so arrange to fall back to a conditional branch over an
unconditional one in this extreme case.
gcc/ChangeLog:
PR target/122867
* config/arm/arm.cc (arm_print_operand): Use %- to
emit LOCAL_LABEL_PREFIX.
(arm_print_operand_punct_valid_p): Allow %- for punct
and make %_ valid for all compilation variants.
* config/arm/thumb2.md (*thumb2_cbz): Handle very
large branch ranges that exceed the limit of b<cond>.
(*thumb2_cbnz): Likewise.
gcc/testsuite/ChangeLog:
PR target/122867
* gcc.target/arm/cbz-range.c: New test.
The following avoids re-calling of vect_need_peeling_or_partial_vectors_p
after peeling. This was neccesary because the function does not
properly handle being called for epilogues since it looks for the
applied prologue peeling not in the main vector loop but the current
one operated on.
PR tree-optimization/110571
* tree-vectorizer.h (vect_need_peeling_or_partial_vectors_p): Remove.
* tree-vect-loop.cc (vect_need_peeling_or_partial_vectors_p):
Fix when called on epilog loops. Make static.
* tree-vect-loop-manip.cc (vect_do_peeling): Do not
re-compute LOOP_VINFO_PEELING_FOR_NITER.
In emit_cmp_and_jump_insns I tried to detect if the operation is signed or
unsigned in order to convert the condition code into an unsigned code.
However I did this based on the incoming tree compare, which is done on the
boolean result. Since booleans are always signed in tree the result was that
we never used an unsigned compare when needed.
This checks one of the arguments of the compare instead.
Bootstrapped Regtested on aarch64-none-linux-gnu,
arm-none-linux-gnueabihf, x86_64-pc-linux-gnu
-m32, -m64 and no issues.
Ok for master?
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
PR tree-optimization/122861
* optabs.cc (emit_cmp_and_jump_insns): Check argument instead of result.
gcc/testsuite/ChangeLog:
PR tree-optimization/122861
* gcc.target/aarch64/sve/vect-early-break-cbranch_10.c: New test.
* gcc.target/aarch64/sve/vect-early-break-cbranch_11.c: New test.
* gcc.target/aarch64/sve/vect-early-break-cbranch_12.c: New test.
* gcc.target/aarch64/sve/vect-early-break-cbranch_13.c: New test.
* gcc.target/aarch64/sve/vect-early-break-cbranch_14.c: New test.
* gcc.target/aarch64/sve/vect-early-break-cbranch_15.c: New test.
* gcc.target/aarch64/sve/vect-early-break-cbranch_9.c: New test.
* gcc.target/aarch64/vect-early-break-cbranch_4.c: New test.
* gcc.target/aarch64/vect-early-break-cbranch_5.c: New test.
Jakub Jelinek [Wed, 26 Nov 2025 14:01:11 +0000 (15:01 +0100)]
Change the default C++ dialect to gnu++20
On Mon, Nov 03, 2025 at 01:34:28PM -0500, Marek Polacek via Gcc wrote:
> I would like us to declare that C++20 is no longer experimental and
> change the default dialect to gnu++20. Last time we changed the default
> was over 5 years ago in GCC 11:
> <https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=0801f419440c14f6772b28f763ad7d40f7f7a580>
> and before that in 2015 in GCC 6.1, so this happens roughly every 5 years.
>
> I had been hoping to move to C++20 in GCC 15 (see bug 113920), but at that time
> libstdc++ still had incomplete C++20 support and the compiler had issues to iron
> out (mangling of concepts, modules work, etc.). Are we ready now? Is anyone
> aware of any blockers? Presumably we still wouldn't enable Modules by default.
>
> I'm willing to do the work if we decide that it's time to switch the default
> C++ dialect (that includes updating cxx-status.html and adding a new caveat to
> changes.html).
I haven't seen a patch posted for this, so just that something is posted
during stage1 if we decide to do it, here is a patch.
The patch makes -std=gnu++20 the default C++ dialect and documents that
-fmodules is still not implied by that or -std=c++20 and modules support
is still experimental.
2025-11-26 Jakub Jelinek <jakub@redhat.com>
gcc/
* doc/invoke.texi (gnu++17): Remove comment about the default.
(c++20): Remove note about experimental support, except add a note
that modules are still experimental and need to be enabled separately.
(gnu++20): Likewise. Move here comment about the default.
(fcoroutines): Mention it is enabled by default for C++20 and later.
* doc/standards.texi: Document that the default for C++ is
-std=gnu++20.
gcc/c-family/
* c-opts.cc (c_common_init_options): Call set_std_cxx20 rather than
set_std_cxx17.
* c.opt (std=c++2a): Change description to deprecated option wording.
(std=c++20): Remove experimental support part.
(std=c++2b): Change description to deprecated option wording.
(std=gnu++2a): Likewise.
(std=gnu++20): Remove experimental support part.
(std=gnu++2b): Change description to deprecated option wording.
gcc/testsuite/
* lib/target-supports.exp: Set cxx_default to c++20 rather than
c++17.
* lib/g++-dg.exp (g++-std-flags): Reorder list to put 20 first
and 17 after 26.
* g++.dg/debug/pr80461.C (bar): Use v = v + 1; instead of ++v;.
* g++.dg/debug/pr94459.C: Add -std=gnu++17 to dg-options.
* g++.dg/diagnostic/virtual-constexpr.C: Remove dg-skip-if,
instead use { c++11 && c++17_down } effective target instead of
c++11.
* g++.dg/guality/pr67192.C: Add -std=gnu++17.
* g++.dg/torture/pr84961-1.C: Likewise.
* g++.dg/torture/pr84961-2.C: Likewise.
* g++.dg/torture/pr51482.C (anim_track_bez_wvect::tangent): Cast
key_class to int before multiplying it by float.
* g++.dg/torture/stackalign/unwind-4.C (foo): Use g_a = g_a + 1;
instead of g_a++;.
* g++.dg/tree-prof/partition1.C (bar): Use l = l + 1; return l;
instead of return ++l;.
* obj-c++.dg/exceptions-3.mm: Add -std=gnu++17.
* obj-c++.dg/exceptions-5.mm: Likewise.
libgomp/
* testsuite/libgomp.c++/atomic-12.C (main): Add ()s around array
reference index.
* testsuite/libgomp.c++/atomic-13.C: Likewise.
* testsuite/libgomp.c++/atomic-8.C: Likewise.
* testsuite/libgomp.c++/atomic-9.C: Likewise.
* testsuite/libgomp.c++/loop-6.C: Use count = count + 1;
return count > 0; instead of return ++count > 0;.
* testsuite/libgomp.c++/pr38650.C: Add -std=gnu++17.
* testsuite/libgomp.c++/target-lambda-1.C (merge_data_func):
Use [=,this] instead of just [=] in lambda captures.
* testsuite/libgomp.c-c++-common/target-40.c (f1): Use v += 1;
instead of v++;.
* testsuite/libgomp.c-c++-common/depend-iterator-2.c: Use v = v + 1;
instead of v++.
Tomasz Kamiński [Thu, 13 Nov 2025 13:54:11 +0000 (14:54 +0100)]
libstdc++: Optimize functor storage for transform views iterators.
The iterators for transform views (views::transform, views::zip_transform,
and views::adjacent_transform) now store a function handle from (from
__detail::__func_handle namespace) instead of a pointer to the view object
(_M_parent).
The following handle templates are defined in __func_handle namespace:
* _Inplace: Used if the functor is a function pointer or standard operator
wrapper (std::less<>, etc). The functor is stored directly in __func_handle
and the iterator. This avoid double indirection through a pointer to the
function pointer, and reduce the size of iterator for std wrappers.
* _InplaceMemPtr: Used for data or function member pointers. This behaves
similarly to _Inplace, but uses __invoke for invocations.
* _StaticCall: Used if the operator() selected by overload resolution
for the iterator reference is static. In this case, __func_handle is empty,
reducing the iterator size.
* _ViaPointer: Used for all remaining cases. __func_handle stores a pointer
to the functor object stored within the view. Only for this template the
cv-qualification of the functor template parameter (_Fn) relevant, and
specialization for both const and mutable types are generated.
As a consequence of these changes, the iterators of transform views no longer
depend on the view object when handle other than __func_handle::_ViaPointer
is used. The corresponding views are not marked as borrowed_range, as they
are not marked as such in the standard.
The use of _Inplace is limited to only set of pre-C++20 standard functors,
as for once introduced later operator() was retroactively made static.
We do not extent to to any empty fuctor, as it's oprator may still depend on
value of this pointer as illustrated by test12 in
std/ranges/adaptors/transform.cc test file.
Storing function member pointers directly increases the iterator size in that
specific case, but this is deemed beneficial for consistent treatment of
function and data member pointers.
To avoid materializing temporaries when the underlying iterator(s) return a
prvalue, the _M_call_deref and _M_call_subscript methods of handles are
defined to accept the iterator(s), which are then dereferenced as arguments
of the functor.
Using _Fd::operator()(*__iters...) inside requires expression is only
supported since clang-20, however at the point of GCC-16 release, clang-22
should be already available.
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::__is_std_op_template)
(__detail::__is_std_op_wrapper, __func_handle::_Inplace)
(__func_handle::_InplaceMemPtr, __func_handle::_ViaPointer)
(__func_handle::_StaticCall, __detail::__func_handle_t): Define.
(transform_view::_Iterator, zip_transform_view::_Iterator)
(adjacent_tranform_view::_Iterator): Replace pointer to view
(_M_parent) with pointer to functor (_M_fun). Update constructors
to construct _M_fun from *__parent->_M_fun. Define operator* and
operator[] in terms of _M_call_deref and _M_call_subscript.
* testsuite/std/ranges/adaptors/adjacent_transform/1.cc: New tests.
* testsuite/std/ranges/adaptors/transform.cc: New tests.
* testsuite/std/ranges/zip_transform/1.cc: New tests.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Reviewed-by: Patrick Palka <ppalka@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Tomasz Kamiński [Thu, 20 Nov 2025 10:23:30 +0000 (11:23 +0100)]
libstdc++: Make C++20s operator wrappers operator() static.
The operator() for function objects introduced in C++20 (e.g., std::identity,
std::compare_three_way, std::ranges::equal) is now defined as static.
Although static operator() is a C++23 feature, it is supported in C++20 by
both GCC and clang (since their support was added in clang-16).
This change is not user-observable, as all affected operators are template
functions. Taking the address of such an operator requires casting to a pointer
to member function with a specific signature. The exact signature is unspecified
per C++20 [member.functions] p2 (e.g. due to potential parameters with default
arguments).
libstdc++-v3/ChangeLog:
* include/bits/ranges_cmp.h (std::identity::operator()):
(ranges::equal_to:operator(), ranges::not_equal_to:operator())
(ranges::greater::operator(), ranges::greater_equal::operator())
(ranges::less::operator(), ranges::less_equal::operator()):
Declare as static.
* libsupc++/compare (std::compare_three_way::operator()):
Declare as static.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Reviewed-by: Patrick Palka <ppalka@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jakub Jelinek [Wed, 26 Nov 2025 10:05:42 +0000 (11:05 +0100)]
eh: Invoke cleanups/destructors in asm goto jumps [PR122835]
The eh pass lowers try { } finally { } stmts and handles
in there e.g. GIMPLE_GOTOs or GIMPLE_CONDs which jump from
within the try block out of that by redirecting the jumps
to an artificial label with code to perform the cleanups/destructors
and then continuing the goto, ultimately to the original label.
Now, for computed gotos and non-local gotos, we document we don't
invoke destructors (and cleanups as well), that is something we really
can't handle, similarly longjmp.
This PR is about asm goto though, and in that case I don't see why
we shouldn't be performing the cleanups, while the user doesn't
specify which particular label will be jumped to, so it is more
like GIMPLE_COND (i.e. conditional goto) rather than unconditional
GIMPLE_GOTO, even with potentiall more different maybe gotos, there is
still list of the potential labels and we can adjust some or all of them
to artificial labels performing cleanups and continuing jump towards the
user label, we know from where the jumps go (asm goto) and to where
(the different LABEL_DECLs).
So, the following patch handles asm goto in the eh pass similarly to
GIMPLE_COND and GIMPLE_GOTO.
Jakub Jelinek [Wed, 26 Nov 2025 09:57:37 +0000 (10:57 +0100)]
match.pd: Use get_range_query (cfun) in more simplifications and pass current stmt to range_of_expr [PR119683]
The following testcase regressed with r13-3596 which switched over
vrp1 to ranger vrp. Before that, I believe vrp1 was registering
SSA_NAMEs with ASSERT_EXPRs at the start of bbs and so even when
querying the global ranges from match.pd patterns during the vrp1
pass, they saw the local ranges for a particular bb rather than global
ranges. In ranger vrp that doesn't happen anymore, so we need to
pass a stmt to range_of_expr if we want the local ranges rather
than global ones, plus should be using get_range_query (cfun)
instead of get_global_range_query () (most patterns actually use
the former already). Now, for stmt the following patch attempts
to pass the innermost stmt on which that particular capture appears
as operand, but because some passes use match.pd folding on expressions
not yet in the IL, I've added a helper function which tries to find out
from a capture of the LHS operation whether it is a SSA_NAME with
SSA_NAME_DEF_STMT which is in the IL right now and only query
the ranger with that in that case, otherwise NULL (i.e. what it has
been using before).
2025-11-26 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/119683
* gimple-match.h (gimple_match_ctx): New inline function.
* match.pd ((mult (plus:s (mult:s @0 @1) @2) @3)): Capture
PLUS, use get_range_query (cfun) instead of
get_global_range_query () and pass gimple_match_ctx (@5)
as 3rd argument to range_of_expr.
((plus (mult:s (plus:s @0 @1) @2) @3)): Similarly for MULT,
with @4 instead of @5.
((t * u) / u -> t): Similarly with @2 instead of @4.
((t * u) / v -> t * (u / v)): Capture MULT, pass gimple_match_ctx (@3)
as 3rd argument to range_of_expr.
((X + M*N) / N -> X / N + M): Pass gimple_match_ctx (@3) or
gimple_match_ctx (@4) as 3rd arg to some range_of_expr calls.
((X - M*N) / N -> X / N - M): Likewise.
((X + C) / N -> X / N + C / N): Similarly.
(((T)(A)) + CST -> (T)(A + CST)): Capture CONVERT, use
get_range_query (cfun) instead of get_global_range_query ()
and pass gimple_match_ctx (@2) as 3rd argument to range_of_expr.
(x_5 == cstN ? cst4 : cst3): Capture EQNE and pass
gimple_match_ctx (@4) as 3rd argument to range_of_expr.
projects / thirdparty / gcc.git / log
