Jeff Law [Thu, 2 Oct 2025 12:25:47 +0000 (06:25 -0600)]
[RISC-V][PR target/122051] Fix pmode_reg_or_uimm5_operand for thead vector
For this bug we're failing during vsetvl insertion, but the real problem
happens earlier.
Basically the slide instructions are using pmode_reg_or_uimm5_operand which has
an implementation that was appropriate when we integrated RVV, but which is
bogus once thead vector was added. It was just a thin wrapper around
vector_length_operand.
vector_length_operand rejects most constants when thead vector is enabled. LRA
saw the rK constraint, so it figured the (const_int 1) was a sensible
substitution for the relevant operand. It was only during vsetvl insertion
that we made another change to the insn and tried to recognize it and boom
things blew up.
This patch makes pmode_reg_or_uimm5_operand independent of
vector_length_operand and everything is happy again.
Tested on riscv32-elf (verifying the selector properly skips the test) and
riscv64-elf where the ICE could be seen. Bootstrap on the Pioneer and BPI just
started a short while ago, so no data for another 7/24 hours respectively, but
not expecting issues.
PR target/122051
gcc/
* config/riscv/predicates.md (pmode_reg_or_uimm5_operand): Implement
directly rather than using vector_length_operand.
gcc/testsuite/
* gcc.target/riscv/pr122051.c: New test.
c: fmv: Prevent FMV being combined with other cloning/renaming extensions.
This patch adds exclusions and diagnostics to prevent function multi-versioning
being used with omp simd pragmas and renaming extensions.
This behaviour is forbidden by the ACLE as the expected behaviour is not clear.
gcc/c-family/ChangeLog:
* c-attribs.cc (attr_target_clones_exclusions): Add simd and omp
exclusions.
(attr_target_version_exclusions): New definition with simd and omp
exclusions.
(attr_omp_declare_simd_exclusions): New definition with target_version
and clones exclusions.
(attr_simd_exclusions): Ditto.
(c_common_gnu_attributes): Add new target_version, simd, and omp
declare simd variables.
This mostly tests c front end code, but has to be target specific as FMV
requires specifying target extensions.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/mv-and-mvc-error1.c: New test.
* gcc.target/aarch64/mv-and-mvc-error2.c: New test.
* gcc.target/aarch64/mv-and-mvc-error3.c: New test.
* gcc.target/aarch64/mv-error1.c: New test.
* gcc.target/aarch64/mv-error2.c: New test.
* gcc.target/aarch64/mv-error3.c: New test.
* gcc.target/aarch64/mv-error4.c: New test.
* gcc.target/aarch64/mv-error5.c: New test.
* gcc.target/aarch64/mv-error6.c: New test.
* gcc.target/aarch64/mv-error7.c: New test.
* gcc.target/aarch64/mv-error8.c: New test.
* gcc.target/aarch64/mv-error9.c: New test.
* gcc.target/aarch64/mv-error10.c: New test.
* gcc.target/aarch64/mvc-error1.c: New test.
* gcc.target/aarch64/mvc-error2.c: New test.
* gcc.target/aarch64/mvc-warning1.c: New test.
This commit introduces support for the target_version attribute in the c
frontend, following the behavior defined in the Arm C Language Extension.
Key changes include:
- During pushdecl, the compiler now checks whether the current symbol is
part of a multiversioned set.
- New versions are added to the function multiversioning (FMV) set, and the
symbol binding is updated to include the default version (if present).
This means the binding for a multiversioned symbol will always reference
the default version (if present), as it defines the scope and signature
for the entire set.
- Pre-existing versions are merged with their previous version (or diagnosed).
- Lookup logic is adjusted to prevent resolving non-default versions.
- start_decl and start_function are updated to handle marking and mangling of
versioned functions.
- c_parse_final_cleanups now includes a call to process_same_body_aliases.
This has no functional impact other than setting cpp_implicit_aliases_done
on all nodes, which is necessary for certain shared FMV logic.
gcc/c/ChangeLog:
* c-decl.cc (maybe_mark_function_versioned): New function.
(merge_decls): Preserve DECL_FUNCTION_VERSIONED in merging.
(duplicate_decls): Add check and diagnostic for unmergable version decls.
(pushdecl): Add FMV target_version logic.
(lookup_name): Don't resolve non-default versions.
(start_decl): Mark and mangle versioned functions.
(start_function): Mark and mangle versioned functions.
(c_parse_final_cleanups): Add call to process_same_body_aliases.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/mv-1.c: New test.
* gcc.target/aarch64/mv-and-mvc1.c: New test.
* gcc.target/aarch64/mv-and-mvc2.c: New test.
* gcc.target/aarch64/mv-and-mvc3.c: New test.
* gcc.target/aarch64/mv-and-mvc4.c: New test.
* gcc.target/aarch64/mv-symbols1.c: New test.
* gcc.target/aarch64/mv-symbols10.c: New test.
* gcc.target/aarch64/mv-symbols11.c: New test.
* gcc.target/aarch64/mv-symbols12.c: New test.
* gcc.target/aarch64/mv-symbols13.c: New test.
* gcc.target/aarch64/mv-symbols14.c: New test.
* gcc.target/aarch64/mv-symbols2.c: New test.
* gcc.target/aarch64/mv-symbols3.c: New test.
* gcc.target/aarch64/mv-symbols4.c: New test.
* gcc.target/aarch64/mv-symbols5.c: New test.
* gcc.target/aarch64/mv-symbols6.c: New test.
* gcc.target/aarch64/mv-symbols7.c: New test.
* gcc.target/aarch64/mv-symbols8.c: New test.
* gcc.target/aarch64/mv-symbols9.c: New test.
* gcc.target/aarch64/mvc-symbols1.c: New test.
* gcc.target/aarch64/mvc-symbols2.c: New test.
* gcc.target/aarch64/mvc-symbols3.c: New test.
* gcc.target/aarch64/mvc-symbols4.c: New test.
Richard Biener [Wed, 1 Oct 2025 12:55:17 +0000 (14:55 +0200)]
tree-optimization/122079 - PRE antic compute doesn't converge
The following re-instantiates the pruning of the ANTIC_IN value set
by the previous iterations one by reverting part of r16-3945-gc30f58c3f7ec25. The earlier fixes made sure the initial
value set is appropriately big to not cause this to lose optimizations.
But it seems to be still required for correctness given iteration
order means we combine ANTIC_IN sets from different generations which
can be prone to oscillations in CFG cycles.
PR tree-optimization/122079
* tree-ssa-pre.cc (compute_antic_aux): Re-instantiate
ANTIC_IN value pruning by the old solution.
* gcc.dg/torture/pr122079-2.c: New testcase.
* gcc.dg/torture/pr122079-3.c: Likewise.
Richard Biener [Wed, 1 Oct 2025 12:16:50 +0000 (14:16 +0200)]
tree-optimization/122079 - PRE antic_compute doesn't converge
The following fixes another case of us pruning from the value set
based on the expression set after expression removal when the
maximum expression set is involved.
PR tree-optimization/122079
* tree-ssa-pre.cc (prune_clobbered_mems): Do not prune
values when the maximum expression set is involved.
binutils: Pass target plugin file to target ar/nm/ranlib
There are 2 kinds of binutils tests:
1. Tests of binutils object files and libraries using the build tools,
like CC, AR, NM and RANLIB.
2. Tests of binutils programs as the target tools, like CC_FOR_TARGET,
AR_FOR_TARGET, NM_FOR_TARGET and RANLIB_FOR_TARGET.
Set AR_PLUGIN_OPTION_FOR_TARGET, NM_PLUGIN_OPTION_FOR_TARGET and
RANLIB_PLUGIN_OPTION_FOR_TARGET to the target compiler plugin file for
target ar/nm/ranlib.
Binutils/GCC: Add clang LTO support to AR, NM and RANLIB
Add CLANG_PLUGIN_FILE to find the clang plugin file and pass it to
--plugin for ar, nm and ranlib so that binutils can be built with
clang LTO. Run CLANG_PLUGIN_FILE before GCC_PLUGIN_OPTION since
GCC_PLUGIN_OPTION may return the wrong PLUGIN_OPTION with clang.
autoupdate: replace old version of AC_INIT by the new one
- old AC_INIT by AC_INIT + AC_CONFIG_SRC_DIR
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fINIT-3
- AC_CANONICAL_SYSTEM by:
* AC_CANONICAL_HOST where host, and host_alias are needed
* AC_CANONICAL_TARGET where target_alias is needed
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fCANONICAL_005fTARGET-1
We have a discrepancy with 64-bit BFD handling across our component
subdirectories leading to link failures such as:
ld: ../opcodes/.libs/libopcodes.a(disassemble.o): in function `disassembler': disassemble.c:(.text+0x65): undefined reference to `print_insn_alpha'
ld: disassemble.c:(.text+0x105): undefined reference to `print_insn_ia64'
ld: disassemble.c:(.text+0x11d): undefined reference to `print_insn_loongarch'
ld: disassemble.c:(.text+0x1a1): undefined reference to `print_insn_big_mips'
[...]
with some configurations having a 32-bit host and 64-bit BFD, such as:
`--host=i386-linux-gnu --target=riscv64-linux-gnu --enable-targets=all'.
This is ultimately due to how 64-bit BFD is enabled for bfd/ itself and
other subdirectorses and has been a regression from commit 1d5269c994bf
("unify 64-bit bfd checks").
For bfd/ the BFD_64_BIT autoconf macro from config/bfd64.m4 is used
combined with this logic in bfd/configure.ac:
case ${host64}-${target64}-${want64} in
*true*)
wordsize=64
bfd64_libs='$(BFD64_LIBS)'
all_backends='$(BFD64_BACKENDS) $(BFD32_BACKENDS)'
[...]
;;
false-false-false)
wordsize=32
all_backends='$(BFD32_BACKENDS)'
;;
esac
where the value of ${wordsize} switches between 32-bit and 64-bit BFD
via these pieces:
#define BFD_ARCH_SIZE @wordsize@
and:
#if BFD_ARCH_SIZE >= 64
#define BFD64
#endif
in bfd/bfd-in.h, which ultimately becomes a part of "bfd.h".
Then ${host64} is determined in bfd/configure.ac from the host's word
size, via the host's pointer size:
if test "x${ac_cv_sizeof_void_p}" = "x8"; then
host64=true
fi
And ${target64} is determined in bfd/configure.ac from the target's word
size:
if test ${target_size} = 64; then
target64=true
fi
Where multiple targets have been requested with `--enable-targets=all'
the presence of any 64-bit target will set "true" here.
Finally ${want64} is set according to `--enable-64-bit-bfd' user option
with an arrangement involving BFD_64_BIT:
BFD_64_BIT
if test $enable_64_bit_bfd = yes ; then
want64=true
else
want64=false
fi
which also, redundantly, checks and sets its result upon the host's word
size. Lastly ${want64} is also selectively set by target fragments in
bfd/config.bfd, which mostly if not completely overlaps with ${target64}
setting as described above.
Conversely other subdirectories only rely on BFD_64_BIT, so they fail to
notice that BFD is 64-bit and do not enable their 64-bit handling where
the host requested is 32-bit and 64-bit BFD has been enabled other than
with `--enable-64-bit-bfd'. One consequence is opcodes/disassemble.c
enables calls to its numerous own 64-bit backends by checking the BFD64
macro from "bfd.h", however does not actually enable said backends in
its Makefile. Hence the link errors quoted above.
Address the problem then by moving the `--enable-64-bit-bfd' option back
to bfd/configure.ac and remove the call to BFD_64_BIT from there and
then rewrite the macro in terms of checking for the presence of BFD64
macro in "bfd.h", which is the canonical way of determining whether BFD
is 64-bit or not.
Rather than running `grep' directly on ../bfd/bfd-in3.h as the opcodes/
fragment used to before the problematic commit:
if grep '#define BFD_ARCH_SIZE 64' ../bfd/bfd-in3.h > /dev/null; then
run the preprocessor on "bfd.h", which allows to invoke the macro from
configure.ac files placed in subdirectories located at deeper levels, by
relying on the preprocessor's search path.
This requires however that the invokers rely on `all-bfd' rather than
`configure-bfd' for their `configure' invocation stage, because "bfd.h"
is made by `make all' rather than `configure' in bfd/.
Do not cache the result of this check however, as reconfiguring a tree
such as to flip `--enable-64-bit-bfd' on or to change a secondary target
may affect BFD64 and we have no access to information about secondary
targets in BFD_64_BIT.
Also remove the ENABLE_BFD_64_BIT automake conditional, as it's not used
anywhere.
Last but not least remove the hack from gdb/configure.ac to fail builds
for `mips*-*-*' hosts where `--enable-targets=all' has been requested,
but `--enable-64-bit-bfd' has not as it's no longer needed. Such builds
complete successfully now, having enabled 64-bit BFD implicitly.
Tested-By: Guinevere Larsen <guinevere@redhat.com> Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Alan Modra <amodra@gmail.com> Approved-By: Luis Machado <luis.machado@arm.com>
* Makefile.def: Synced from binutils-gdb.
* Makefile.in: Regenerated.
This patch caused problems for some users when building gdb, because
it would cause 'guild' to be invoked with the wrong versin of guile.
On the whole it seems simpler to just back this out.
I'm checking this in to the binutils-gdb repository in the interest of
fixing the build for Andrew. No one has responded to the identical
patch sent to gcc-patches, but I will ping it there.
Make gdbserver's build system locate libiconv when building for Linux.
Commit 07b3255c3bae ("Filter invalid encodings from Linux thread names")
make libiconv madantory for building gdbserver on Linux.
While trying to cross-compile gdb for xtensa-fsf-linux-uclibc (with a
toolchain generated with crosstool-ng), I got:
/home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:48:10: fatal error: iconv.h: No such file or directory
48 | #include <iconv.h>
| ^~~~~~~~~
I downloaded GNU libiconv, built it for that host, and installed it in
an arbitrary directory. I had to modify the gdbserver build system to
locate libiconv and use it, the result is this patch.
I eventually found that crosstool-ng has a config option to make uclibc
provide an implementation of iconv, which is of course much easier. But
given that this patch is now written, I think it would be worth merging
it, it could help some people who do not have iconv built-in their libc
in the future (and may not have the luxury of rebuilding their libc like
I do).
Using AM_ICONV in configure.ac adds these options for configure (the
same we have for gdb):
--with-libiconv-prefix[=DIR] search for libiconv in DIR/include and DIR/lib
--without-libiconv-prefix don't search for libiconv in includedir and libdir
--with-libiconv-type=TYPE type of library to search for (auto/static/shared)
It sets the `LIBICONV` variable with whatever is needed to link with
libiconv, and adds the necessary `-I` flag to `CPPFLAGS`.
To avoid unnecessarily linking against libiconv on hosts that don't need
it, set `MAYBE_LIBICONV` with the contents of `LIBICONV` only if the
host is Linux, and use `MAYBE_LIBICONV` in `Makefile.in`.
Since libiconv is a hard requirement for Linux hosts, error out if it is
not found.
The bits in acinclude.m4 are similar to what we have in
gdb/acinclude.m4.
Update the top-level build system to support building against an in-tree
libiconv (I did not test this part though). Something tells me that the
all-gdbserver dependency on all-libiconv is unnecessary, since there is
already a dependency of configure-gdbserver on all-libiconv (and
all-gdbserver surely depends on configure-gdbserver). I just copied
what's done for GDB though.
c++, contracts: Abstract interfaces to constexpr [NFC].
We want to move to having different representations of the contract
semantic for C++26, since that wants values outside the range that
can be accommodated using the cxx2a mechanisms. First part, abstract
the interfaces to constexpr, so that they do not see the underlying
source of data.
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_constant_expression): Use revised
interfaces to determine if contracts are ignored and, if not,
whether they are evaluated.
* contracts.h (contract_ignored_p, contract_evaluated_p): New.
Jeff Law [Wed, 1 Oct 2025 21:12:49 +0000 (15:12 -0600)]
[RISC-V][PR target/122106] Add missing predicate on crc expanders
This is a minor bug in the CRC code for RISC-V.
Essentially in the expander we have an operand without a predicate. So it
matches anything. But that operand really has to be a CONST_INT. So this
patch adds the missing predicate. I noticed we had constraints on our
define_expand. It doesn't hurt anything, but they're never used and can easily
get out of date, so this removes the unnecessary constraints.
Tested on riscv32-elf and riscv64-elf. Bootstrap & regression test on the
Pioneer is in flight and should finish in the next few hours.
Pushing to the trunk once CI confirms it's OK.
PR target/122106
gcc/
* config/riscv/bitmanip.md (crc expanders): Add predicate for
polynomial argument. Drop unnecessary constraints.
Harald Anlauf [Tue, 30 Sep 2025 19:14:12 +0000 (21:14 +0200)]
Fortran: UBSAN uninitialized stride for missing optional argument [PR122080]
PR fortran/122080
gcc/fortran/ChangeLog:
* trans-array.cc (gfc_conv_array_parameter): Wrap the derivation of
bounds and strides for the descriptor of an optional dummy array
argument by a test on argument presence when it is supposed to be
passed to an optional argument.
gcc/testsuite/ChangeLog:
* gfortran.dg/ubsan/missing_optional_dummy_9.f90: New test.
Jan Hubicka [Wed, 1 Oct 2025 15:58:00 +0000 (17:58 +0200)]
Add --parm auto-profile-bbs
This patch adds a parameter that controls whether BB profile is read from auto-profile
or we just scale guessed profile according to known counts. This is mostly useful as
a first aid when auto-profile goes wrong. Once we fix enough bugs I think it may be
removed but so far it is quite useful, so I decided to push it.
gcc/ChangeLog:
* auto-profile.cc (determine_scale): Break out from ...
(afdo_adjust_guessed_profile): ... here.
(scale_bb_profile): New function.
(afdo_annotate_cfg): Use it.
* params.opt (auto-profile-bbs): New parmaeter.
* doc/invoke.texi (auto-profile-bbs): Document.
Jan Hubicka [Wed, 1 Oct 2025 15:18:44 +0000 (17:18 +0200)]
Fix handling of goto locuses and phi args in auto-profile
afdo_set_bb_count had code that, only if no count was determined in the BB itself,
looked into its outgoing edges and tried to determine counts based on location of
phi args. This is not quite correct, since value detemrined is the count of edge
which may be lower than count of BB.
This patchs moves the logic into afdo_unscaled_edge_count and extends it to
also use goto_locus. BB profile is infered only if BB has single successor and
otherwise the edge counts are stored into correct location in
afdo_calculate_branch_prob.
gcc/ChangeLog:
* auto-profile.cc (afdo_unscaled_edge_count): New function based on
part of ...
(afdo_set_bb_count): ... this function; use it here.
(afdo_calculate_branch_prob): Try to determine edge counts using
phi args and goto locuses.
Jan Hubicka [Wed, 1 Oct 2025 15:06:41 +0000 (17:06 +0200)]
make autprofiledbootstrap with LTO meaningful
currently autoprofiled bootstrap produces auto-profiles for cc1 and cc1plus
binaries. Those are used to build respective frontend files. For backend
cc1plus.fda is used. This does not work well with LTO bootstrap where cc1plus
backend is untrained since it is used only for parsing and ealry opts. As a
result all binaries gets most of the backend optimized for size rather then
speed.
This patch adds lto1.fda and then combines all of cc1, cc1plus and lto1 into
all.fda that is used compiling common modules. This is more or less equivalent
to what -fprofile-use effectively uses modulo that with -fprofile-use we know
number of runs of evety object file and scale accordingly at LTO time.
gcc/ChangeLog:
* Makefile.in (ALL_FDAS): New variable.
(ALL_HOST_BACKEND_OBJ): Use all.fda instead of cc1plus.fda
(all.fda): New target
gcc/c/ChangeLog:
* Make-lang.in: Add c_FDAS
(create_fdas_for_cc1): Be sure that build fails if create_gcov fails.
gcc/cp/ChangeLog:
* Make-lang.in: Add c++_FDAS
(create_fdas_for_cc1plus): Be sure that build fails if create_gcov fails.
gcc/lto/ChangeLog:
* Make-lang.in: Add lto_FDAS; enable FDA collection
(create_fdas_for_lto1): Be sure that build fails if create_gcov fails.
Jan Hubicka [Wed, 1 Oct 2025 14:56:15 +0000 (16:56 +0200)]
Improve profile update in merge_blocks
When merging blocks we currently alway use count of the first basic block.
In some cases we merge block containing call to cold noreturn function (thus
having count 0 (reliable)) with earlier block with weaker form of profile.
In this case we can still preserve reliable count of 0.
The patch also makes block merging to pick higher of the counts if quality
is the same. This should reduce chances of losing track of hot code in broken
profiles.
gcc/ChangeLog:
* cfghooks.cc (merge_blocks): Choose more reliable or higher BB
count.
Jan Hubicka [Wed, 1 Oct 2025 14:51:26 +0000 (16:51 +0200)]
Propagate unlikely executed BBs even on measured profiles
While looking into AutoFDO porfiles I noticed that sometimes we lost
precise zero counts due to inlining and merging basic blocks. Propagating
precise zero counts should be safe even for measured profiles and thus
this patch enables it.
gcc/ChangeLog:
* predict.cc (unlikely_executed_stmt_p): Remove redundant check.
(rebuild_frequencies): Also recompute unlikely bbs when profile is
present or consistent.
Jonathan Wakely [Wed, 1 Oct 2025 12:11:38 +0000 (13:11 +0100)]
libstdc++: Fix sizeof(wide-string)-1 bug in std::regex test
This uses sizeof on a wide string to get the length, which is wrong
because each wchar_t is more than one byte. This was presumably copied
from a narrow char test.
libstdc++-v3/ChangeLog:
* testsuite/28_regex/basic_regex/assign/wchar_t/pstring.cc: Use
wcslen(cs) instead of sizeof(cs)-1.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Andrew MacLeod [Tue, 30 Sep 2025 19:59:38 +0000 (15:59 -0400)]
Fix off by one in range_from_loop_direction.
When bounds_of_var_in_loop was converted to range_from_loop_direction,
the final check returned FALSE when the beginning and end bounds were
the same... The new code was using wi::gt_p, when it should have been
wi::ge_p when checking for the fail condition.
PR tree-optimization/120560
gcc/
* vr-values.cc (range_from_loop_direction): Use wi::ge_p rather
than wi::gt_p.
Jonathan Wakely [Tue, 30 Sep 2025 09:49:08 +0000 (10:49 +0100)]
libstdc++: Suppress -Wclass-memaccess warnings in bits/stl_uninitialized.h
Running the testsuite with warnings enabled gives:
FAIL: 20_util/specialized_algorithms/uninitialized_copy/58982.cc -std=gnu++26 (test for excess errors)
Excess errors:
.../libstdc++-v3/include/bits/stl_uninitialized.h:293: warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)' writing to an object of type 'struct T' with no trivial copy-assignment; use copy-initialization instead [-Wclass-memaccess]
This is because -Wclass-memaccess warns about using memcpy on types
which have a deleted assignment, even though those can be trivially
copyable and so using memcpy on them is technically valid. Where these
warnings occur in bits/stl_uninitialized.h we're only using memcpy after
checking for trivially copyable (and any other relevant conditions) so
we can be confident that we're using it safely. We also don't actually
care about assignment here because we're only constructing new objects,
not copying over existing ones (which is what std::copy does, but not
std::uninitialized_copy).
Uses of memcpy in the C++98 code don't need to have -Wclass-memaccess
suppressed, because there are no deleted functions in C++98 so there are
no types which are trivially copyable but trigger the warning.
libstdc++-v3/ChangeLog:
* include/bits/stl_uninitialized.h (uninitialized_copy)
(uninitialized_fill, uninitialized_fill_n): Use pragmas to
suppress -Wclass-memaccess warnings.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Paul Thomas [Wed, 1 Oct 2025 07:14:00 +0000 (08:14 +0100)]
Fortran: Generic interface checking with use associated PDTs [PR122089]
2025-10-01 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/122089
* decl.cc (gfc_get_pdt_instance): If the pdt_template is use
associated, 'module' field should be copied to this instance.
gcc/testsuite/
PR fortran/122089
* gfortran.dg/pdt_51.f03: New test.
David Malcolm [Tue, 30 Sep 2025 21:23:32 +0000 (17:23 -0400)]
diagnostics::output_spec: fix "color" in "text" output scheme
The previous refactoring highlighted that we were ignoring the "color"
key within the "text" output scheme for diagnostics.
Fixed thusly.
gcc/ChangeLog:
* diagnostics/output-spec.cc (text_scheme_handler::make_sink): Use
the value of the "color" to determine if the sink's printer is
colorized.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
gcc/ChangeLog:
* diagnostics/output-spec.cc: Add comments. Introduce a
"struct decoded_args" within each scheme_handler subclass,
and split out per-scheme key-value parsing from each make_sink
implementation into new per-scheme decode_kv member functions.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Tue, 30 Sep 2025 21:23:31 +0000 (17:23 -0400)]
diagnostics: simplifying output-spec.cc
No functional change intended.
gcc/ChangeLog:
* diagnostics/output-spec.cc: Rename "parsed_arg" to
"scheme_and_kvs" throughout. Rename "unparsed_arg" to
"unparsed_spec" throughout, and make a member of
output_spec::context rather than passing it around.
* diagnostics/output-spec.h: Likewise.
* libgdiagnostics.cc: Likewise.
* opts-diagnostic.cc: Likewise.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Martin Uecker [Sat, 13 Sep 2025 06:37:32 +0000 (08:37 +0200)]
c: Fix regression related to DECL_NONLOCAL on aarch64 [PR121933]
The recent patch r16-3747-gafa74d37e81 to detect the use of non-local
context by nested functions caused regressions on aarch64, because
DECL_NONLOCAL was set on labels. Fix this by setting it only to
the same types of decls as before.
PR target/121933
gcc/c/ChangeLog:
* c-typeck.cc (mark_decl_used): Set DECL_NONLOCAL
only for VAR_DECL, FUNC_DECL, PARM_DECL.
Adds an optimisation in FMV to redirect to a specific target if possible.
A call is redirected to a specific target if both:
- the caller can always call the callee version
- and, it is possible to rule out all higher priority versions of the callee
fmv set. That is estabilished either by the callee being the highest priority
version, or each higher priority version of the callee implying that, were it
resolved, a higher priority version of the caller would have been selected.
For this logic, introduces the new TARGET_OPTION_FUNCTIONS_B_RESOLVABLE_FROM_A
hook. Adds a full implementation for Aarch64, and a weaker default version
for other targets.
This allows the target to replace the previous optimisation as the new one is
able to cover the same case where two function sets implement the same versions.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_functions_b_resolvable_from_a): New
function.
(TARGET_OPTION_FUNCTIONS_B_RESOLVABLE_FROM_A): New define.
* doc/tm.texi: Regenerate.
* doc/tm.texi.in: Add documentation for
TARGET_OPTION_FUNCTIONS_B_RESOLVABLE_FROM_A.
* multiple_target.cc (redirect_to_specific_clone): Add new optimisation
logic.
(ipa_target_clone): Remove check for TARGET_HAS_FMV_TARGET_ATTRIBUTE.
* target.def: Document new hook..
* attribs.cc: (functions_b_resolvable_from_a) New function.
* attribs.h: (functions_b_resolvable_from_a) New function.
gcc/testsuite/ChangeLog:
* g++.target/aarch64/fmv-selection1.C: New test.
* g++.target/aarch64/fmv-selection2.C: New test.
* g++.target/aarch64/fmv-selection3.C: New test.
* g++.target/aarch64/fmv-selection4.C: New test.
* g++.target/aarch64/fmv-selection5.C: New test.
* g++.target/aarch64/fmv-selection6.C: New test.
* g++.target/aarch64/fmv-selection7.C: New test.
Jan Hubicka [Tue, 30 Sep 2025 12:51:39 +0000 (14:51 +0200)]
Fix discriminators of gimple PHI arguments
while gimple PHI itself does not have locations, the arguments does and they
can be used to determine count of edges in CFG. Assign_discriminators already
knows how to handle goto_locus and PHI args should be handled same way as
done by this patch.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/ChangeLog:
* auto-profile.cc (function_instance::match): Sanity check
that gimple PHI has no location.
* tree-cfg.cc (assign_discriminators): Also remap locations
of gimple PHI arguments.
Jan Hubicka [Tue, 30 Sep 2025 11:07:53 +0000 (13:07 +0200)]
Fix overflow in ipa_profile_generate_summary
With profile count scaling we now get overflow in ipa_profile_generate_summary
which uses old macro GCOV_COMPUTE_SCALE that is not ready for very large
counts. This patch replaces remaining two uses of it by (somewhat elaborate)
profile-count based equivalent which is overflow safe.
Jan Hubicka [Mon, 29 Sep 2025 22:22:48 +0000 (00:22 +0200)]
Restrict what kind of statements are used for auto-profile
When building profile of walk_tree_1 during autoprofiledbootstrap we produce
non-zero counts to call of tree_check_failed because location of INLINE_ENTRY
debug statement is misplaced. Auto-profile already knows it should skip
clobbers since their locations will never go into debug info. This patch extend
it to all kind of debug statement except for DEBUG_BEGIN_STMT, nops, labels
and predict.
autoprofilebootstrapped/regtested x86_64-linux.
gcc/ChangeLog:
* auto-profile.cc (stmt_loc_used_by_debug_info): New function.
(autofdo_source_profile::get_count_info): Use it.
(afdo_set_bb_count): Likewise.
(afdo_vpt_for_early_inline): Likewise.
Eric Botcazou [Tue, 30 Sep 2025 09:55:18 +0000 (11:55 +0200)]
Ada: Fix internal error on ill-formed Reduce attribute in Ada 2022
This is an internal error on the new Reduce attribute of Ada 2022 when the
programmer swaps its arguments(!) The change makes it so that the compiler
gives an error message instead.
gcc/ada/
PR ada/117517
* sem_attr.adb (Resolve_Attribute) <Attribute_Reduce>: Try to
resolve the reducer first. Fix casing of error message.
Andre Vieira [Tue, 30 Sep 2025 09:57:58 +0000 (10:57 +0100)]
libgcc, bitint: do not use softfp_wrap for bitint and add build option
This patch circumvents the softfp_wrap for bitint functions in libgcc as certain
ports, like arm, can use softfp_wrap to distinquigh between targets they want to
use specialized assembly functions for and targets that they use the soft-fp
C implementations for. This is an orthogonal choice to the use of the soft-fp
C implementations for bitint conversions.
This patch also adds extra options to build bitint soft-fp functions, this is
needed by the arm port to build HF bitint conversion functions.
libgcc/ChangeLog:
* config/t-softfp: Don't use softfp_wrap for bitint functions.
(softfp_cflags): New parameter that is passed to the building of bitint
functions.
Andre Vieira [Tue, 30 Sep 2025 09:57:46 +0000 (10:57 +0100)]
bitint: fix inconsistency in bitint_precision_kind
This patch fixes an issue where the first call to bitint_precision_kind would
return the bitint kind, which was also inconsistent with subsequent calls with
the same bitint size.
gcc/ChangeLog:
* gimple-lower-bitint.cc (bitint_precision_kind): Fix inconsistency in
results between first and consecutive calls to this function.
Paul Thomas [Tue, 30 Sep 2025 08:24:11 +0000 (09:24 +0100)]
Fortran: ICE in derived type with a PDT component [PR102241,PR105380]
2025-09-30 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/102241
* gfortran.h: Add symbol attribute 'pdt_comp'.
* module.cc : Add 'pdt_comp' to 'ab_attribute' and 'attr_bits'.
(mio_symbol_attribute): Set 'pdt_comp'.
* resolve.cc (resolve_component): If a PDT component is found
in a non-PDT type, generate the PDT instance, if necessary, and
set the 'pdt_comp' attribute. Fix some whitespace issues.
* trans-decl.cc (gfc_get_symbol_decl, gfc_trans_deferred_vars):
If 'pdt_comp' set, initialize the PDT components.
* trans-stmt.cc (gfc_trans_deallocate): Verify that a typespec
parameter list is available for PDT components of ordinary
derived types.
gcc/testsuite/
PR fortran/105380
* gfortran.dg/pdt_49.f03: New test.
PR fortran/102241
* gfortran.dg/pdt_11.f03: Deallocate 'o_fdef'.
* gfortran.dg/pdt_15.f03: Reinstate final 'pop_8' and update
the tree dump counts.
* gfortran.dg/pdt_20.f03: Deallocate 'x'.
* gfortran.dg/pdt_23.f03: Deallocate 'x'.
* gfortran.dg/pdt_3.f03: Eliminate the temporary 'matrix' and
use w%d directly in the allocation. Change the TODO comment and
comment on memory leak in allocation.
* gfortran.dg/pdt_39.f03: Comments on memory leaks.
* gfortran.dg/pdt_40.f03: Deallocate 'foo' and bar%x.
* gfortran.dg/pdt_50.f03: New test.
Piotr Trojanek [Tue, 15 Jul 2025 13:18:26 +0000 (15:18 +0200)]
ada: Add special-case for 'Constrained on stand-alone objects in SPARK
GNAT relies on standalone objects of indefinite, non-class-wide types getting a
constrained itypes; GNATprove relies on the same objects keeping their nominal,
unconstrained types. None of that can be simply changed, so instead we carry
this different handling to routine which provides the value of attribute
Constrained.
gcc/ada/ChangeLog:
* exp_util.adb (Attribute_Constrained_Static_Value): Special case
stand-alone objects for GNATprove.
package P is
type T1 is tagged limited null record;
type T2 is new T1 with private;
private
type T2 is limited new T1 with null record;
end P;
It should be rejected because of ARM 7.3 (10.1/3). Before this patch,
GNAT did reject it, with the following error message:
full view of non-limited extension cannot be limited
This message is not right because the partial view of T2 here *is*
limited even if it doesn't have an explicit limited keyword in its
declaration. This patch changes the error message to something that's a
better match for ARM 7.3 (10.1/3).
This patch also tweaks another related error message and substitutes
a mention of ARM 7.3 (10.1/3) for the Ada Issue it originated from in a
comment.
ada: exp_ch6.adb: entirely disable call validation in CodePeer_Mode
This call validation was introduced a couple of months ago and caused
GNAT2SCIL to fail a lot. It was determined that while being invalid for
GCC, the tree was valid for GNAT2SCIL. Since it was thought that only
the checking of the return type caused issue for CodePeer_Mode, this is
the only part that disabled. Recent changes revealed that there also
exists differences in the AST expected by GCC and GNAT2SCIL, and that
checking the actuals also causes issues for GNAT2SCIL. We hence entirely
disable the checking of calls in CodePeer_Mode instead of just the
checking of return values.
gcc/ada/ChangeLog:
* exp_ch6.adb (Validate_Subprogram_Calls): Do not Check_Calls in CodePeer_Mode.
(Check_Calls): Remove CodePeer_Mode special case.
ada: Update the GNAT RM with assertion level documentation
* Add an entry for pragma Assertion Level.
* Point all assertion kind pragmas that support assertion level
associations to the relevant section in the SPARK RM.
gcc/ada/ChangeLog:
* doc/gnat_rm/implementation_defined_pragmas.rst: update
rules for pragmas affected by assertion levels.
* gnat_rm.texi: Regenerate.
For memset, the size of used vector is decided by MIN(MOVE_MAX_PIECES,
STORE_MAX_PIECES).
Unless there's u-arch prefer big size vector for memcpy and small size
vector for memset, there's no need to have a separate option or tune
for it.
In general, x86 backend always prefer big size vector for memset due
to STLF issue.
Peter Damianov [Fri, 19 Sep 2025 19:02:37 +0000 (20:02 +0100)]
diagnostics: Fix mojibake from displaying UTF-8 on Windows consoles
UTF-8 characters in diagnostic output (such as the warning emoji ⚠️
used by fanalyzer) display as mojibake on Windows unless the utf8
code page is being used
This patch adds UTF-8 to UTF-16 conversion when outputting to a console
on Windows.
gcc/ChangeLog:
* pretty-print.cc (decode_utf8_char): Move forward declaration.
(mingw_utf8_str_to_utf16_str): New function to convert UTF-8 to UTF-16.
(is_console_handle): New function to detect Windows console handles.
(write_all): Add UTF-8 to UTF-16 conversion for console output,
falling back to WriteFile for ASCII strings and regular files.
Signed-off-by: Peter Damianov <peter0x44@disroot.org> Signed-off-by: Jonathan Yong <10walls@gmail.com>
Jonathan Wakely [Fri, 26 Sep 2025 14:02:43 +0000 (15:02 +0100)]
libstdc++: Fix VERIFY(idx = 1) bugs in tests
These should be checking for equality, not performing assignments.
The tests for from_range on associative containers were actually
checking the wrong thing, but the bug in the is_equal function was
making the incorrect checks pass anyway, because all the values being
used were non-zero, so the result of lhs.id = rhs.id was true, but would
have been false if lhs.id == rhs.id had been used as intended.
libstdc++-v3/ChangeLog:
* testsuite/21_strings/basic_string/numeric_conversions/char/stoi.cc:
Fix assignment used instead of equality comparison.
* testsuite/21_strings/basic_string/numeric_conversions/char/stol.cc:
Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/char/stoll.cc:
Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/char/stoul.cc:
Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/char/stoull.cc:
Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/stoi.cc:
Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/stol.cc:
Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/stoll.cc:
Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/stoul.cc:
Likewise.
* testsuite/21_strings/basic_string/numeric_conversions/wchar_t/stoull.cc:
Likewise.
* testsuite/23_containers/map/cons/from_range.cc: Fix is_equal
function and expected value of comparison functions after
construction.
* testsuite/23_containers/multimap/cons/from_range.cc: Likewise.
* testsuite/23_containers/multiset/cons/from_range.cc: Likewise.
* testsuite/23_containers/set/cons/from_range.cc: Likewise.
* testsuite/23_containers/unordered_map/cons/from_range.cc: Fix
is_equal functions.
* testsuite/23_containers/unordered_multimap/cons/from_range.cc:
Likewise.
* testsuite/23_containers/unordered_multiset/cons/from_range.cc:
Likewise.
* testsuite/23_containers/unordered_set/cons/from_range.cc:
Likewise.
* testsuite/25_algorithms/minmax/constrained.cc: Fix assignment
used instead of equality comparison.
* testsuite/27_io/manipulators/extended/get_time/wchar_t/1.cc:
Likewise.
Jason Merrill [Tue, 23 Sep 2025 10:19:49 +0000 (11:19 +0100)]
c++: concepts and conversions [PR112632]
One case missed in my fix for this PR: Here we were omitting the
IMPLICIT_CONV_EXPR that expresses the conversion from int to char because
the target type was non-dependent and the argument was not type-dependent.
But we still need it if the argument is value-dependent.
PR c++/112632
gcc/cp/ChangeLog:
* pt.cc (convert_template_argument): Also force IMPLICIT_CONV_EXPR
if the argument is value-dependent.
Jason Merrill [Wed, 24 Sep 2025 21:31:37 +0000 (22:31 +0100)]
c++: implicit 'this' in generic lambda [PR122048]
Here template substitution was replacing a reference to the 'this' of X::f
with the implicit closure parameter of the operator(), which is wrong. The
closure parameter is never a suitable replacement for a 'this' parameter.
PR c++/122048
gcc/cp/ChangeLog:
* pt.cc (tsubst_expr): Don't use a lambda current_class_ptr.
Jie Mei [Fri, 17 Jan 2025 08:51:45 +0000 (16:51 +0800)]
MIPS: Add conditions for use of the -mmips16e2 and -mips16 option.
Changes from V1:
* Raise the minimal revision to r2.
MIPS16e2 ASE is a superset of MIPS16e ASE, which is again a superset
of MIPS16 ASE. Later, all of them are forbidden in Release 6.
Make -mmips16e2 imply -mips16 as the ASE requires, so users won't
be surprised even if they expect it to. Meanwhile, check if
mips_isa_rev <= 5 when -mips16 is effective and >= 2 when -mmips16e2
is effective.
Co-developed-by: Rong Zhang <rongrong@oss.cipunited.com> Signed-off-by: Rong Zhang <rongrong@oss.cipunited.com>
gcc/ChangeLog:
* config/mips/mips.cc(mips_option_override):Add conditions
for use of the -mmips16e2 and -mips16 option.
gcc/testsuite/ChangeLog:
* gcc.target/mips/mips16e2-cache.c: Use isa_rev>=2 instead of
-mips32r2 and remove -mips16 option.
* gcc.target/mips/mips16e2-cmov.c: Add isa_rev>=2 and remove
-mips16 option.
* gcc.target/mips/mips16e2-gp.c: Same as above.
* gcc.target/mips/mips16e2.c: Same as above.
Jie Mei [Sat, 14 Sep 2024 07:04:09 +0000 (15:04 +0800)]
MIPS: Add MSUBF.fmt instruction for MIPSr6
GCC currently uses two instructions (NEG.fmt and MADDF.fmt) for
operations like `x - (y * z)' for MIPSr6. We can further tune this by
using only MSUBF.fmt instead of those two.
This patch adds MSUBF.fmt instrutions with corresponding tests.
gcc/ChangeLog:
* config/mips/mips.md (fms<mode>4): Generates MSUBF.fmt
instructions.
(*fms<mode>4_msubf): Same as above.
(fnma<mode>4): Same as above.
(*fnma<mode>4_msubf): Same as above.
gcc/testsuite/ChangeLog:
* gcc.target/mips/mips-msubf.c: New tests for MIPSr6.
Add a new diagnostic, -Wmultiple-parameter-fwd-decl-lists, which
diagnoses uses of this obsolescent syntax.
Add this diagnostic in -Wextra.
Forward declarations of parameters are very rarely used. And functions
that need two forward declaractions of parameters are also quite rare.
This combination results in this code almost not existing in any code
base, which makes adding this to -Wextra okay. FWIW, I've tried finding
such code using a code search engine, and didn't find any cases (but the
regex for that isn't easy to writei, so I wouldn't trust it).
* doc/extend.texi: Clarify documentation about lists of
parameter forward declarations, and mention that more than one
of them are unnecessary.
* doc/invoke.texi: Document the new
-Wmultiple-parameter-fwd-decl-lists.
gcc/testsuite/ChangeLog:
* gcc.dg/Wmultiple-parameter-fwd-decl-lists.c: New test.
Harald Anlauf [Fri, 26 Sep 2025 17:20:39 +0000 (19:20 +0200)]
Fortran: fix uninitialized read in testcase gfortran.dg/pdt_48.f03
Running the testcase using valgrind --leak-check=full --track-origins=yes:
==28585== Conditional jump or move depends on uninitialised value(s)
==28585== at 0x400E19: MAIN__ (pdt_48.f03:48)
==28585== by 0x400EDB: main (pdt_48.f03:34)
==28585== Uninitialised value was created by a heap allocation
==28585== at 0x4841984: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28585== by 0x400975: __pdt_m_MOD_add (pdt_48.f03:30)
==28585== by 0x400D84: MAIN__ (pdt_48.f03:44)
==28585== by 0x400EDB: main (pdt_48.f03:34)
The cause was a partial initialization of a vector used in a subsequent
addition. Initialize the remaining elements of the first vector by zero.
Jan Hubicka [Fri, 26 Sep 2025 13:57:03 +0000 (15:57 +0200)]
Fix precise 0 handling in afdo_propagate_edge
Currently afdo_propagate_edge will turn precise 0 to autofdo 0 because it thinks
auto-profile claims some samples has been executed in the given basic block, while
this is only a consequence of < being defined by
0 (predise) < 0 (autofdo)
gcc/ChangeLog:
* auto-profile.cc (afdo_propagate_edge): Fix handling of precize 0
counts.
Andrew Stubbs [Wed, 24 Sep 2025 11:58:23 +0000 (11:58 +0000)]
amdgcn: Remove vector alignment restrictions
The supported misalignment logic seems to be a bit arbitrary. Some of it looks
like it was copied from the Arm implementation, although testing shows that the
packed accesses do not work (weird subregs happen).
AMD GCN does have some alignment restrictions on Buffer instructions, but as we
don't use those that's irrelvant. The Flat and Global instructions (that we do
use) have no such restrictions.
LDS memory -- which can be accessed via Flat instructions -- does have
alignment restrictions, but the compiler is not using LDS for arbitrary
vectors. If the user deliberately choses to place unaligned data in
low-latency memory then a runtime exception should occur (no silent bad
behaviour), so there's no reason to pessimise the normal case.
gcc/ChangeLog:
* config/gcn/gcn.cc
(gcn_vectorize_support_vector_misalignment): Allow any alignment, as
long as it's not packed.
Joseph Myers [Fri, 26 Sep 2025 11:12:12 +0000 (11:12 +0000)]
c: Give permerror for excess braces in scalar initializers [PR88642]
As noted in bug 88642, the C front end fails to give errors or
pedwarns for scalar initializers with too many levels of surrounding
braces. There is a warning for redundant braces around a scalar
initializer within a larger braced initializer (valid for a single
such level within a structure, union or array initializer; not valid
for more than one such level, or where the outer layer of braces is
itself for a scalar, either redundant braces themselves or part of a
compound literal), but this never becomes an error even for invalid
cases. Check for this case and turn the warning into a permerror when
there are more levels of braces than permitted. The existing warning
is unchanged for a single (permitted) level of redundant braces around
a scalar initializer inside a structure, union or array initializer,
and it's also unchanged that no such warning is given for a single
(permitted) level of redundant braces around a top-level scalar
initializer.
Technically this is a C2y issue (these rules on valid initializers
moved into Constraints as a result of N3346, accepted in Minneapolis;
previously, as a "shall" outside constraints, violating these rules
resulted in compile-time undefined behavior without requiring a
diagnostic).
Hopefully little code is actually relying on not getting an error
here. In view of gcc.dg/tree-ssa/ssa-dse-10.c showing that at least
some code may be using such over-braced initializers (initializer of
pubKeys at line 1167 in that test; I'm not at all sure how that
initializer ends up getting interpreted to translate it to something
equivalent but properly structured), this is made a permerror rather
than a hard error, so -fpermissive (as already used by that test) can
be used to disable the error (the default -fpermissive for old
standards modes is not a problem given that before C2y this is
undefined behavior not a constraint violation).
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
PR c/88642
gcc/c/
* c-typeck.cc (constructor_braced_scalar): New variable.
(struct constructor_stack): Add braced_scalar field.
(really_start_incremental_init): Handle constructor_braced_scalar
and braced_scalar field.
(push_init_level): Handle constructor_braced_scalar and
braced_scalar field. Give permerror rather than warning for
nested braces around scalar initializer.
(pop_init_level): Handle constructor_braced_scalar and
braced_scalar field.
Jan Hubicka [Fri, 26 Sep 2025 10:39:07 +0000 (12:39 +0200)]
Fix integer overflow in profile_count::probability_in
This patch fixes integer overflow in profile_count::probability_in which happens
for very large counts. This was probably not that common in practice until
scaled AutoFDO profiles were intorduces.
This was introduced as cut&paste from profile_probability implementation.
I reviewed multiplicaitons in the file for safety and noticed that in some
cases the code is over-protective. In profile_probability::operator/ we alrady
scale that m_val <= other.m_val and thus we know result will be in the range
0...max_probability. In profile_probability::apply_scale we deal with 30bit
value from profile_probability so no overflow can happen.
gcc/ChangeLog:
* profile-count.h (profile_probability::operator/): Do not cap
twice.
(profile_probability::operator/=): Likewise.
(profile_probability::apply_scale): Do not watch for overflow.
(profile_count::probability_in): Watch overflow.
Jonathan Wakely [Wed, 10 Sep 2025 09:10:07 +0000 (10:10 +0100)]
libstdc++: Reuse predicates in std::search and std::is_permutation
Hoist construction of the call wrappers out of the loop when we're
repeatedly creating a call wrapper with the same bound arguments.
We need to be careful about iterators that return proxy references,
because bind1st(pred, *first) could bind a reference to a prvalue proxy
reference returned by *first. That would then be an invalid reference by
the time we invoked the call wrapper.
If we dereference the iterator first and store the result of that on the
stack, then we don't have a prvalue proxy reference, and can bind it (or
the value it refers to) into the call wrapper:
auto&& val = *first; // lifetime extension
auto wrapper = bind1st(pred, val);
for (;;)
/* use wrapper */;
This ensures that the reference returned from *first outlives the call
wrapper, whether it's a proxy reference or not.
For C++98 compatibility in __search we can use __decltype(expr) instead
of auto&&.
libstdc++-v3/ChangeLog:
* include/bits/stl_algobase.h (__search, __is_permutation):
Reuse predicate instead of creating a new one each time.
* include/bits/stl_algo.h (__is_permutation): Likewise.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jonathan Wakely [Fri, 19 Sep 2025 15:03:11 +0000 (16:03 +0100)]
libstdc++: Simplify std::erase functions for sequence containers
This removes the use of std::ref that meant that __remove_if used an
indirection through the reference, which might be a pessimization. Users
can always use std::ref to pass expensive predicates into erase_if, but
we shouldn't do it unconditionally. We can std::move the predicate so
that if it's not cheap to copy and the user didn't use std::ref, then we
try to use a cheaper move instead of a copy.
There's no reason that std::erase shouldn't just be implemented by
forwarding to std::erase_if. I probably should have done that in r12-4083-gacf3a21cbc26b3 when std::erase started to call __remove_if
directly.
libstdc++-v3/ChangeLog:
* include/std/deque (erase_if): Move predicate instead of
wrapping with std::ref.
(erase): Forward to erase_if.
* include/std/inplace_vector (erase_if, erase): Likewise.
* include/std/string (erase_if, erase): Likewise.
* include/std/vector (erase_if, erase): Likewise.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jonathan Wakely [Fri, 13 Jun 2025 16:27:51 +0000 (17:27 +0100)]
libstdc++: Eliminate __gnu_cxx::__ops function objects
This removes the indirect functors from <bits/predefined_ops.h> that are
used by our STL algorithms. Currently we wrap all predicates and values
into callables which accept iterator arguments, and automatically
dereference the iterators. With this change we no longer do that
dereferencing and so all predicates are passed values not iterators, and
the algorithms that invoke those predicates must dereference the
iterators.
This avoids wrapping user-provided predicates into another predicate
that does the dereferencing. User-provided predicates are now passed
unchanged to our internal algos like __search_n. For the overloads that
take a value instead of a predicate, we still need to create a predicate
that does comparison to the value, but we can now use std::less<void>
and std::equal_to<void> as the base predicate and bind the value to
those base predicates.
Because the "transparent operators" std::less<void> and
std::equal_to<void> were not added until C++14, this change defines
those explicit specializations unconditionally for C++98 and C++11 too
(but the default template arguments that make std::less<> and
std::equal_to<> refer to those specializations are still only present
for C++14 and later, because we don't need to rely on those default
template arguments for our internal uses).
When binding a predicate and a value into a new call wrapper, we now
decide whether to store the predicate by value when it's an empty type
or a scalar (such as a function pointer). This avoids a
double-indirection through function pointers, and avoids storing and
invoking stateless empty functors through a reference. For C++11 and
later we also use [[no_unique_address]] to avoid wasted storage for
empty predicates (which includes all standard relational ops, such as
std::less).
The call wrappers in bits/predefined_ops.h all have non-const operator()
because we can't be sure that the predicates they wrap are
const-invocable. The requirements in [algorithms.requirements] for
Predicate and BinaryPredicate template arguments require pred(*i) to be
valid, but do not require that std::to_const(pred)(*i) has to be valid,
and similarly for binary_pred.
Jonathan Wakely [Thu, 25 Sep 2025 16:23:28 +0000 (17:23 +0100)]
libstdc++: Fix unsafe comma operators in <random> [PR122062]
This fixes a 'for' loop in std::piecewise_linear_distribution that
increments two iterators with a comma operator between them, making it
vulnerable to evil overloads of the comma operator.
It also changes a 'for' loop used by some other distributions, even
though those are only used with std::vector<double>::iterator and so
won't find any overloaded commas.
libstdc++-v3/ChangeLog:
PR libstdc++/122062
* include/bits/random.tcc (__detail::__normalize): Use void cast
for operands of comma operator.
(piecewise_linear_distribution): Likewise.
* testsuite/26_numerics/random/piecewise_linear_distribution/cons/122062.cc:
New test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Reviewed-by: Hewill Kang <hewillk@gmail.com>
Paul Thomas [Fri, 26 Sep 2025 06:30:07 +0000 (07:30 +0100)]
Fortran: Fix uninitialized reads for pdt_13.f03 etc. [PR122002]
2025-09-26 Harald Anlauf <anlauf@gcc.gnu.org>
gcc/fortran
PR fortran/122002
* decl.cc (gfc_get_pdt_instance): Initialize 'instance' to NULL
and set 'kind_value' to zero before calling gfc_extract_int.
* primary.cc (gfc_match_rvalue): Intitialize 'ctr_arglist' to
NULL and test for default values if gfc_get_pdt_instance
returns NULL.
Because LoongArch does not implement TARGET_CAN_INLINE_P,
functions with the target attribute set and those without
it cannot be inlined. At the same time, setting the
always_inline attribute will cause compilation failure.
To solve this problem, I implemented this hook. During the
implementation process, it checks the status of the target
special options of the caller and callee, such as the ISA
extension.
PR target/121875
gcc/ChangeLog:
* config/loongarch/loongarch.cc
(loongarch_can_inline_p): New function.
(TARGET_CAN_INLINE_P): Define.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/can_inline_1.c: New test.
* gcc.target/loongarch/can_inline_2.c: New test.
* gcc.target/loongarch/can_inline_3.c: New test.
* gcc.target/loongarch/can_inline_4.c: New test.
* gcc.target/loongarch/can_inline_5.c: New test.
* gcc.target/loongarch/can_inline_6.c: New test.
* gcc.target/loongarch/pr121875.c: New test.
For padded layouts we want to check that the product of the
padded stride with the remaining extents is representable.
Creating a second overload, allows passing in subspans of the
static extents and retains the ergonomics for the common case
of passing in all static extents.
libstdc++-v3/ChangeLog:
* include/std/mdspan (__static_quotient): New overload.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Luc Grosheintz <luc.grosheintz@gmail.com>
Jonathan Wakely [Wed, 24 Sep 2025 13:37:37 +0000 (14:37 +0100)]
libstdc++: Check feature test macro for robust_nonmodifying_seq_ops
We should check the relevant feature test macro instead of just the
value of __cplusplus.
Also add a comment explaining why the __cplusplus check guarding
__sample *can't* be changed to check __glibcxx_sample (because __sample
is also used in C++14 by std::experimental::sample, not only by C++17
std::sample).
libstdc++-v3/ChangeLog:
* include/bits/stl_algo.h: Check robust_nonmodifying_seq_ops
feature test macro instead of checking __cplusplus value. Add
comment to another __cplusplus check.
* include/bits/stl_algobase.h: Add comment to #endif.
Jonathan Wakely [Fri, 19 Sep 2025 11:11:26 +0000 (12:11 +0100)]
libstdc++: Remove unwanted STDC_HEADERS macro from c++config.h [PR79147]
Similar to r16-4034-g1953939243e1ab, this comments out another macro
that Autoconf adds to the generated config.h but which is not wanted in
the c++config.h file that we install.
There's no benefit to defining _GLIBCXX_STDC_HEADERS in user code, so we
should just prevent it from being defined.
libstdc++-v3/ChangeLog:
PR libstdc++/79147
PR libstdc++/103650
* include/Makefile.am (c++config.h): Adjust sed command to
comment out STDC_HEADERS macro.
* include/Makefile.in: Regenerate.
libstdc++: Prepare mapping layout tests for padded layouts.
Using the existing tests for padded layouts requires the following
changes:
* The padded layouts are template classes. In order to be able to use
partially specialized templates, functions need to be converted to
structs.
* The layout mapping tests include a check that only applies if
is_exhaustive is static. This commit introduces a concept to check if
is_exhaustive is a static member function.
* Fix a test to not use a hard-coded layout_left.
The test empty.cc contains indentation mistakes that are fixed.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/mdspan/layouts/empty.cc: Fix indent.
* testsuite/23_containers/mdspan/layouts/mapping.cc
(test_stride_1d): Fix test.
(test_stride_2d): Rewrite using a struct.
(test_stride_3d): Ditto.
(has_static_is_exhaustive): New concept.
(test_mapping_properties): Update test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Luc Grosheintz <luc.grosheintz@gmail.com>
This assertion, despite what I said in r16-4070, is not valid: we can
reach here when deduping a VAR_DECL that didn't get a LANG_SPECIFIC in
the current TU. It's still correct to always use lang_cplusplus however
as for anything else the decl would have been created with an
appropriate LANG_SPECIFIC to start with.
projects / thirdparty / gcc.git / log
