Tobias Burnus [Wed, 12 Nov 2025 13:15:43 +0000 (14:15 +0100)]
libgomp.{c-c++-common,fortran}/target-is-accessible-1.c: Fix testcases for omp_default_device [P119677]
Commit r16-5188-g5da963d988e8ea added omp_default_device such that -5
became a conforming device number, but the tests used them to test
for as non-conforming number; now -6 is used.
libgomp/ChangeLog:
PR libgomp/119677
* testsuite/libgomp.c-c++-common/target-is-accessible-1.c: Modify
test as -5 is now a conforming device number.
* testsuite/libgomp.fortran/target-is-accessible-1.f90: Likewise.
Andre Vieira [Wed, 12 Nov 2025 10:33:09 +0000 (10:33 +0000)]
arm: Fix out of bounds when using cmse with FP types in aggregates [PR122539]
Skip partial register clearing logic when dealing with FP_REGS in aggregates as
these are always fully cleared and the logic assumes a mask for each of the 4
argument GPR_REGS.
Andre Vieira [Wed, 12 Nov 2025 10:25:14 +0000 (10:25 +0000)]
arm: Fix CMSE clearing of union members with no padding [PR122539]
This patch fixes the CMSE register clearing to make sure we don't clear
registers used by a function call. Before this patch the algorithm would only
correctly handle registers with padding bits to clear, any registers that were
fully utilised would be wrongfully cleared.
gcc/ChangeLog:
PR target/122539
* config/arm/arm.cc (comp_not_to_clear_mask_str_un): Update
not_to_clear_reg_mask for union members.
gcc/testsuite/ChangeLog:
* gcc.target/arm/cmse/union-3.x: New test.
* gcc.target/arm/cmse/baseline/union-3.c: New test.
* gcc.target/arm/cmse/mainline/8m/union-3.c: New test.
* gcc.target/arm/cmse/mainline/8_1m/union-3.c: New test.
So far only a per thread canary in the TLS block is supported. This
patch adds support for a global canary, too. For this the new option
-mstack-protector-guard={global,tls} is added which defaults to tls.
The global canary is expected at symbol __stack_chk_guard which means
for a function prologue instructions larl/l(g)fr + mvc are emitted and
for an epilogue larl/l(g)fr + clc.
Furthermore, option -mstack-protector-guard-record is added which is
inspired by -mrecord-mcount and generates section __stack_protector_loc
containing pointers to all instructions which load the address of the
global guard. Thus, this option has only an effect in conjunction with
-mstack-protector-guard=global. The intended use is for the Linux
kernel in order to support run-time patching. In each task_struct of
the kernel a canary is held which will be copied into the lowcore.
Since the kernel supports migration of the lowcore at boot time,
addresses are not necessarily constant. Therefore, the kernel expects
that all instructions loading the address of the canary to be of format
RIL or more precisely are either larl or lgrl and that the instructions
addresses are recorded in section __stack_protector_loc. The kernel is
then required to patch those instructions e.g. to llilf during boot.
In total this means -mstack-protector-guard=global emits code suitable
for user and kernel space.
gcc/ChangeLog:
* config/s390/s390-opts.h (enum stack_protector_guard): Define
SP_TLS and SP_GLOBAL.
* config/s390/s390.h (TARGET_SP_GLOBAL_GUARD): Define predicate.
(TARGET_SP_TLS_GUARD): Define predicate.
* config/s390/s390.md (stack_protect_global_guard_addr<mode>):
New insn.
(stack_protect_set): Also deal with a global guard.
(stack_protect_test): Also deal with a global guard.
* config/s390/s390.opt (-mstack-protector-guard={global,tls}):
New option.
(-mstack-protector-guard-record) New option.
gcc/testsuite/ChangeLog:
* gcc.target/s390/stack-protector-guard-global-1.c: New test.
* gcc.target/s390/stack-protector-guard-global-2.c: New test.
* gcc.target/s390/stack-protector-guard-global-3.c: New test.
* gcc.target/s390/stack-protector-guard-global-4.c: New test.
Richard Biener [Wed, 12 Nov 2025 09:03:23 +0000 (10:03 +0100)]
tree-optimization/122647 - missing bool pattern for bool -> float conversion
The following adds missing support for bool to float conversion which
can be exposed via C++ __builtin_bit_cast. It also corrects a too
lose check in vectorizable_conversion which would have resolved the
ICE but left us with the missed optimization.
PR tree-optimization/122647
* tree-vect-stmts.cc (vectorizable_conversion): Fix guard on
bool to non-bool conversion.
* tree-vect-patterns.cc (vect_recog_bool_pattern): Also handle
FLOAT_EXPR from bool.
Tomasz Kamiński [Thu, 6 Nov 2025 14:22:12 +0000 (15:22 +0100)]
libstdc++: optional<T&> for function and unbounded array should not be range [PR122396]
This implements proposed resolution for LWG4308 [1].
For T denoting either function type or unbounded array, the optional<T&> no
longer exposes iterator, and viable begin/end members. The conditionally
provided iterator type, it is now defined in __optional_ref_base
base class.
Furthermore, range support for optional<T&> is now also guarded by
__cpp_lib_optional_range_support.
[1] https://cplusplus.github.io/LWG/issue4308
PR libstdc++/122396
libstdc++-v3/ChangeLog:
* include/std/optional (__optional_ref_base): Define.
(std::optional<_Tp&>): Inherit from __optional_ref_base<_Tp>.
(optional<_Tp&>::iterator): Move to base class.
(optional<_Tp&>::begin, optional<_Tp&>::end): Use deduced return
type and constrain accordingly.
* testsuite/20_util/optional/range.cc: Add test for optional<T&>.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Eric Botcazou [Wed, 12 Nov 2025 08:03:18 +0000 (09:03 +0100)]
Ada: Fix variable initialized with if-expression not flagged as constant
This is a regression present on the mainline and 15 branch: the -gnatwk
switch no longer flags a string variable initialized with an if-expression
as constant when it is not modified in the program. The fix is to set the
Has_Initial_Value and Never_Set_In_Source flags earlier during analysis in
the Analyze_Object_Declaration procedure.
gcc/ada/
PR ada/122640
* sem_ch3.adb (Analyze_Object_Declaration): Set Is_True_Constant
on entry for constants and Never_Set_In_Source in all cases.
If an initialization expression is present, set Has_Initial_Value
and Is_True_Constant on variables.
Jason Merrill [Fri, 7 Nov 2025 13:16:30 +0000 (18:46 +0530)]
libstdc++: use -Wno-deprecated-declarations
-Wno-deprecated doesn't work with header units, since the testcase can't
change the header unit's version of the __DEPRECATED macro. But
-Wno-deprecated-declarations works just fine to avoid warning about
deprecated things.
Jason Merrill [Tue, 11 Nov 2025 13:15:31 +0000 (18:45 +0530)]
libstdc++: sync prune.exp with GCC
I needed to add module context to dg-prune for libstdc++, and figured it
made sense to sync it with the GCC version rather than maintain slightly
different approaches to stripping the same messages.
libstdc++-v3/ChangeLog:
* testsuite/lib/prune.exp: Sync with gcc prune.exp.
fortran: Fix ICE and self-assignment bugs with recursive allocatable finalizers [PR90519]
Derived types with recursive allocatable components and FINAL procedures
trigger an ICE in gimplify_call_expr because the finalizer wrapper's result
symbol references itself (final->result = final), creating a cycle. This
patch creates a separate __result_<typename> symbol to break the cycle.
Self-assignment (a = a) with such types causes use-after-free because the
left-hand side is finalized before copying, destroying the source. This
patch adds detection using gfc_dep_compare_expr at compile time and pointer
comparison at runtime to skip finalization when lhs == rhs.
Parenthesized self-assignment (a = (a)) creates a temporary, defeating the
simple self-assignment detection. This patch adds strip_parentheses() to
look through INTRINSIC_PARENTHESES operators and ensure deep_copy is enabled
for such cases.
Test pr112459.f90 now expects 6 _final calls instead of 12 because separate
result symbols eliminate double-counting in tree dumps.
PR fortran/90519
gcc/fortran/ChangeLog:
* trans-expr.cc (strip_parentheses): New helper function to strip
INTRINSIC_PARENTHESES operators from expressions.
(is_runtime_conformable): Use strip_parentheses to handle cases
like a = (a) when checking for self-assignment.
(gfc_trans_assignment_1): Strip parentheses before checking if
expr2 is a variable, ensuring deep_copy is enabled for cases like
a = (a). Also strip parentheses when checking for self-assignment
to avoid use-after-free in finalization.
(gfc_trans_scalar_assign): Add comment about parentheses handling.
* class.cc (generate_finalization_wrapper): Create separate result
symbol for finalizer wrapper functions instead of self-referencing
the procedure symbol, avoiding ICE in gimplify_call_expr.
gcc/testsuite/ChangeLog:
* gfortran.dg/finalizer_recursive_alloc_1.f90: New test for ICE fix.
* gfortran.dg/finalizer_recursive_alloc_2.f90: New execution test.
* gfortran.dg/finalizer_self_assign.f90: New test for self-assignment
including a = a, a = (a), and a = (((a))) cases using if/stop pattern.
* gfortran.dg/pr112459.f90: Update to expect 6 _final calls instead
of 12, reflecting corrected self-assignment behavior.
Signed-off-by: Christopher Albert <albert@tugraz.at>
Jerry DeLisle [Tue, 11 Nov 2025 18:47:31 +0000 (10:47 -0800)]
fortran: Implement optional type spec for DO CONCURRENT [PR96255]
This patch adds support for the F2008 optional integer type specification
in DO CONCURRENT and FORALL headers, allowing constructs like:
do concurrent (integer :: i=1:10)
The implementation handles type spec matching, creates shadow variables
when the type spec differs from any outer scope variable, and converts
iterator expressions to match the specified type.
Shadow variable implementation:
When a type-spec is provided and differs from an outer scope variable,
a shadow variable with the specified type is created (with _ prefix).
A recursive expression walker substitutes all references to the outer
variable with the shadow variable throughout the DO CONCURRENT body,
including in array subscripts, substrings, and nested operations.
Constraint enforcement:
Sets gfc_do_concurrent_flag properly (1 for block context, 2 for mask
context) to enable F2008 C1139 enforcement, ensuring only PURE procedures
are allowed in DO CONCURRENT constructs.
Additional fixes:
- Extract apply_typespec_to_iterator() helper to eliminate duplicated
shadow variable creation code (~70 lines)
- Add NULL pointer checks for shadow variables
- Fix iterator counting to handle both EXEC_FORALL and EXEC_DO_CONCURRENT
- Skip FORALL obsolescence warning for DO CONCURRENT (F2018)
- Suppress many-to-one assignment warning for DO CONCURRENT (reductions
are valid, formalized with REDUCE locality-spec in F2023)
PR fortran/96255
gcc/fortran/ChangeLog:
* gfortran.h (gfc_forall_iterator): Add bool shadow field.
* match.cc (apply_typespec_to_iterator): New helper function to
consolidate shadow variable creation logic.
(match_forall_header): Add type-spec parsing for DO CONCURRENT
and FORALL. Create shadow variables when type-spec differs from
outer scope. Replace duplicated code with apply_typespec_to_iterator.
* resolve.cc (replace_in_expr_recursive): New function to recursively
walk expressions and replace symbol references.
(replace_in_code_recursive): New function to recursively walk code
blocks and replace symbol references.
(gfc_replace_forall_variable): New entry point for shadow variable
substitution.
(gfc_resolve_assign_in_forall): Skip many-to-one assignment warning
for DO CONCURRENT.
(gfc_count_forall_iterators): Handle both EXEC_FORALL and
EXEC_DO_CONCURRENT with assertion.
(gfc_resolve_forall): Skip F2018 obsolescence warning for DO
CONCURRENT. Fix memory allocation check. Add NULL checks for shadow
variables. Implement shadow variable walker.
(gfc_resolve_code): Set gfc_do_concurrent_flag for DO CONCURRENT
constructs to enable constraint checking.
gcc/testsuite/ChangeLog:
* gfortran.dg/do_concurrent_typespec_1.f90: New test covering all
shadowing scenarios: undeclared variable, same kind shadowing, and
different kind shadowing.
Co-authored-by: Steve Kargl <kargl@gcc.gnu.org> Co-authored-by: Jerry DeLisle <jvdelisle@gcc.gnu.org> Signed-off-by: Christopher Albert <albert@tugraz.at>
* c-warn.cc (warn_parms_array_mismatch): Split out body of
per-pair in parameter lists iteration into...
(warn_parm_array_mismatch): ...this new function.
Jason Merrill [Mon, 10 Nov 2025 13:02:53 +0000 (18:32 +0530)]
c++/modules: avoid too many hidden friends in ADL
Most of the add_fns calls in adl_namespace_fns also call ovl_skip_hidden,
but we were forgetting that in the case of imports, which meant that for
24_iterators/const_iterator/112490.cc we were considering the
unreachable_sentinel_t hidden friend operator== and therefore failing.
gcc/cp/ChangeLog:
* name-lookup.cc (name_lookup::adl_namespace_fns): Also skip hidden
in the module case.
Jason Merrill [Sat, 8 Nov 2025 23:45:00 +0000 (05:15 +0530)]
c++/modules: use set_cfun
Assigning directly to cfun doesn't properly update the target and
optimization options for the new function, which causes trouble if we load a
function from a module that has different options than the one we were in
the middle of when the load happened. This broke the use of #pragma
optimize in 23_containers/array/iterators/begin_end.cc.
Nathan's comment in module.cc complained about the API doing too much, but
set_cfun seems to me to be exactly what we want here.
gcc/cp/ChangeLog:
* module.cc (module_state::read_cluster): Use set_cfun.
(post_load_processing): Likewise.
Andrew Stubbs [Tue, 11 Nov 2025 15:04:09 +0000 (15:04 +0000)]
amdgcn: Consolidate mkoffload setup constructors
We don't need every mkoffload runtime setting to use it's own constructor.
There was only two committed, but I have more uses for this soon. In theory,
we could also use this setup to choose not to register the kernel with libgomp.
The behaviour is not changed, just the generated code structure.
gcc/ChangeLog:
* config/gcn/mkoffload.cc (process_asm): Replace "configure_stack_size"
constructor with a new regular function, "mkoffload_setup".
(process_obj): Call mkoffload_setup from the "init" constructor.
David Malcolm [Tue, 11 Nov 2025 15:20:47 +0000 (10:20 -0500)]
diagnostics: add experimental SARIF JSON-RPC notifications for IDEs [PR115970]
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3358r0.html#msvc
describes a feature of Visual Studio 2022 version 17.8. which can send its
diagnostics in SARIF form to a pipe when setting the environment variable
SARIF_OUTPUT_PIPE:
https://learn.microsoft.com/en-us/cpp/build/reference/sarif-output?view=msvc-170#retrieving-sarif-through-a-pipe
The precise mechanism above involves Windows-specific details (windows pipes
and HANDLEs).
The following patch implements an analogous feature for GCC, using Unix
domain sockets rather than the Windows-specific details.
With this patch, GCC's cc1, cc1plus, etc will check if
EXPERIMENTAL_SARIF_SOCKET is set in the environment, and if so,
will attempt to connect to that socket. It will send a JSON-RPC
notification to the socket for every diagnostic emitted. Like the
MSVC feature, the diagnostics are sent one-at-a-time as SARIF
"result" objects, rather than sending a full SARIF "log" object.
The patch includes a python test script which runs a server.
Tested by running the script in one terminal:
$ ../../src/contrib/sarif-listener.py
listening on socket: /tmp/tmpjgts0u0i/socket
and then invoking a build in another terminal with the envvar
set to the pertinent socket:
$ EXPERIMENTAL_SARIF_SOCKET=/tmp/tmpjgts0u0i/socket \
make check-gcc RUNTESTFLAGS="analyzer.exp=*"
and watching as all the diagnostics generated during the build
get sent to the listener.
The idea is that an IDE ought to be able to create a socket and
set the environment variable when invoking a build, and then listen
for all the diagnostics, without needing to manually set build flags
to inject SARIF output.
This feature is experimental and subject to change or removal
without notice; I'm adding it to make it easier for IDE developers to
try it out and give feedback.
contrib/ChangeLog:
PR diagnostics/115970
* sarif-listener.py: New file.
gcc/ChangeLog:
PR diagnostics/115970
* diagnostics/sarif-sink.cc: Include <sys/un.h> and <sys/socket.h>.
(sarif_builder::end_group): Update comment.
(sarif_sink::on_end_group): Drop "final".
(class sarif_socket_sink): New subclass.
(maybe_open_sarif_sink_for_socket): New function.
* diagnostics/sarif-sink.h: (maybe_open_sarif_sink_for_socket):
New decl.
* doc/invoke.texi (EXPERIMENTAL_SARIF_SOCKET): Document new
environment variable.
* toplev.cc: Define INCLUDE_VECTOR. Add include of
"diagnostics/sarif-sink.h".
(toplev::main): Call
diagnostics::maybe_open_sarif_sink_for_socket.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Richard Biener [Fri, 7 Nov 2025 12:52:09 +0000 (13:52 +0100)]
Use ranger when simplifying conditions during niter analysis
The following uses ranger to try to simplify boolean expressions
in simplify_using_initial_conditions as used by niter analysis.
We also try to simplify niter expressions themselves, but we cannot
use ranger directly for this.
* tree-ssa-loop-niter.cc (simplify_using_initial_conditions):
Use the active ranger to simplify boolean expressions.
Jeff Law [Tue, 11 Nov 2025 14:19:03 +0000 (07:19 -0700)]
[RISC-V] Improve detection of packw
More infrastructure on the way to eliminating the define_insn_and_split
for zero-extensions.
Exposing the shift-pair approach in the expander may change the order in which
operands appear in later RTL. In the case of packw detection order matters.
It shouldn't, it's an IOR after all, but it does. So we should fix that.
In addition to the ordering issue it slightly changes the form of one operand.
So we want to handle that too. So there's a total of 3 new patterns.
There isn't commonly available hardware with zbkb and it's only lightly tested
in the testsuite. So I wouldn't be terribly surprised to find out there's
other ways we want to represent those operands to ultimately generate a pack
instruction.
Built and tested on riscv32-elf and riscv64-elf in my tester. I'll wait for
pre-commit CI to render a verdict before moving forward.
gcc/
* config/riscv/crypto.md (packf splitters): Variant with
operands reversed. Add variants with the ashift/sign extend
exchanged as well.
Jeff Law [Tue, 11 Nov 2025 14:17:12 +0000 (07:17 -0700)]
[RISC-V] Simplify riscv_extend_to_xmode_reg
So I was trying to untangle our define_insn_and_split situation for
zero-extensions and stumbled over some code we need to adjust & simplify in the
RISC-V backend. I probably should have caught this earlier.
riscv_extend_to_xmode_reg is just a poor implementation of convert_modes; we
can replace the whole thing will a call to convert_modes + force_reg.
Why is this important beyond code hygene?
convert_modes works with the expansion code wheres extend_to_xmode_reg makes
assumptions about the kinds of insns the target directly supports.
This shows up if you try to untangle the zero-extension support where the base ISA doesn't support zero extensions and should be going through an expander rather than using a define_insn_and_split.
The define_insn_and_split for the reg->reg case isn't split until after reload.
Naturally this inhibits some optimizations and forces further work in this
space that should be simple define_splits into also needing to be
define_insn_and_splits.
Anyway, without going further into the zero-extend rathole, this removes the
assumption that the target is providing a single insn zero/sign extension thus
allowing me to continue to untangle that mess.
Bootstrapped and regression tested on the Pioneer (which thoroughly exercises
this code as it does not have the B extension. I don't think the BPI has
picked up this one yet. Also built and regression tested riscv32-elf and
riscv64-elf.
Waiting on pre-commit CI before moving forward.
* config/riscv/riscv.cc (riscv_extend_to_xmode_reg): Simplify
by using convert_modes + force_reg.
Richard Biener [Fri, 7 Nov 2025 12:50:02 +0000 (13:50 +0100)]
Improve range_on_edge for GENERIC expressions
When feeding non-SSA names to range_on_edge we degrade to a
non-contextual query. The following uses the argument added in
the previous patch to indicate the edge as the location of the
range query.
* gimple-range.cc (gimple_ranger::range_on_edge): Pass
the edge as 'edge' to get_tree_range.
(dom_ranger::range_on_edge): Likewise.
Andrew MacLeod [Tue, 11 Nov 2025 07:27:43 +0000 (08:27 +0100)]
Support edge query for range_query::get_tree_range
The following adds an edge argument to get_tree_range and invoke_range_of_expr
to support range_on_edge queries for GENERIC expressions.
* value-query.cc (range_query::invoke_range_of_expr): New
edge argument. If set invoke range_on_edge.
(range_query::get_tree_range): Likewise and adjust.
* value-query.h (range_query::invoke_range_of_expr): New
edge argument.
(range_query::get_tree_range): Likewise.
Lulu Cheng [Thu, 16 Oct 2025 03:26:45 +0000 (11:26 +0800)]
LoongArch: doc: Add description of function attrubute.
Added implementation description of function attributes
target_clones and target_version under LoongArch.
Include the list of supported options and their corresponding
priorities, as well as the rules for setting priorities.
gcc/ChangeLog:
* doc/extend.texi: Add description for LoongArch function
attributes.
* g++.target/loongarch/mv-symbols1.C: New test.
* g++.target/loongarch/mv-symbols2.C: New test.
* g++.target/loongarch/mv-symbols3.C: New test.
* g++.target/loongarch/mv-symbols4.C: New test.
* g++.target/loongarch/mv-symbols5.C: New test.
* g++.target/loongarch/mv-symbols6.C: New test.
* g++.target/loongarch/mvc-symbols1.C: New test.
* g++.target/loongarch/mvc-symbols2.C: New test.
* g++.target/loongarch/mvc-symbols3.C: New test.
* g++.target/loongarch/mvc-symbols4.C: New test.
* g++.target/loongarch/mvc-symbols5.C: New test.
* gcc.target/loongarch/attr-check-error-message1.c: New test.
* gcc.target/loongarch/attr-check-error-message2.c: New test.
* gcc.target/loongarch/attr-check-error-message3.c: New test.
* gcc.target/loongarch/attr-check-error-message4.c: New test.
* gcc.target/loongarch/attr-check-error-message5.c: New test.
* gcc.target/loongarch/attr-check-error-message6.c: New test.
* gcc.target/loongarch/attr-check-error-message7.c: New test.
* gcc.target/loongarch/attr-check-error-message8.c: New test.
* gcc.target/loongarch/attr-check-error-message9.c: New test.
* config/loongarch/loongarch.cc
(loongarch_option_same_function_versions): Compare the target
attributes in two functions to determine which function’s
features get higher priority.
(TARGET_OPTION_SAME_FUNCTION_VERSIONS): Define.
Lulu Cheng [Wed, 15 Oct 2025 08:53:16 +0000 (16:53 +0800)]
LoongArch: Add support for setting priority in fmv.
gcc/ChangeLog:
* config/loongarch/loongarch-protos.h
(loongarch_parse_fmv_features): Modify the type of parameter.
(loongarch_compare_version_priority): Function declaration.
* config/loongarch/loongarch-target-attr.cc
(enum features_prio): Define LA_PRIO_MAX to indicate the
highest priority of supported attributes.
(loongarch_parse_fmv_features): Added handling of setting
priority in attribute string.
(loongarch_compare_version_priority): Likewise.
* config/loongarch/loongarch.cc
(loongarch_process_target_version_attr): Likewise.
(get_feature_mask_for_version): Likewise.
(loongarch_compare_version_priority): Delete.
This patch can obtain the CPUCFG and HWCAP value at runtime and
extract the flag bits of features for function selection.
HWCAP is used to obtain the support of LSX and LASX because the
kernel can control the enable/disable of these two features.
Note that this requires glibc version 2.38 or higher to compile
and run.
libgcc/ChangeLog:
* config/loongarch/t-loongarch64: Add cpuinfo.c to LIB2ADD.
* config/loongarch/cpuinfo.c: New file.
* config/loongarch/loongarch.cc
(loongarch_compare_version_priority): Returns true if DECL1
and DECL2 are versions of the same function.
(TARGET_COMPARE_VERSION_PRIORITY): Define.
* config/loongarch/genopts/gen-evolution.awk:
* config/loongarch/loongarch-evol-attr.def: Regenerate.
* config/loongarch/loongarch-protos.h
(loongarch_parse_fmv_features): Function declaration.
(get_feature_mask_for_version): Likewise.
* config/loongarch/loongarch-target-attr.cc
(enum features_prio): Defining the priority of features.
(struct loongarch_attribute_info): Add members about
features.
(LARCH_ATTR_MASK): Likewise.
(LARCH_ATTR_ENUM): Likewise.
(LARCH_ATTR_BOOL): Likewise.
(loongarch_parse_fmv_features): Parse a function
multiversioning feature string STR.
* config/loongarch/loongarch.cc
(get_suffixed_assembler_name): Return an identifier for the
base assembler name of a versioned function.
(get_feature_mask_for_version): Get the mask and priority of
features.
(add_condition_to_bb): Insert judgment statements for different
features functions.
(dispatch_function_versions): Generates the dispatch function for
multi-versioned functions.
(make_resolver_func): Make the resolver function decl to dispatch
the versions of a multi-versioned function.
(loongarch_generate_version_dispatcher_body): Generate the
dispatcher logic to invoke the right function version at run-time
for a given set of function versions.
(TARGET_GENERATE_VERSION_DISPATCHER_BODY): Define.
* common/config/loongarch/cpu-features.h: New file.
Implement TARGET_OPTION_VALID_VERSION_ATTRIBUTE_P for LoongArch.
This is used to determine whether the attribute ((target_version ("...")))
is valid and process it.
Define TARGET_HAS_FMV_TARGET_ATTRIBUTE to 0 to use "target_version"
for function versioning.
gcc/ChangeLog:
* config/loongarch/loongarch.cc
(loongarch_process_target_version_attr): New function.
(loongarch_option_valid_version_attribute_p): New function.
(TARGET_OPTION_VALID_VERSION_ATTRIBUTE_P): Define.
* config/loongarch/loongarch.h
(TARGET_HAS_FMV_TARGET_ATTRIBUTE): Define it to 0.
* config/loongarch/genopts/gen-evolution.awk: Output the
info needed for handling evolution features when parsing
the target pragma and attribute.
* config/loongarch/genopts/genstr.sh: Add support for
generating *.def files.
* config/loongarch/loongarch-target-attr.cc
(struct loongarch_attribute_info): Add structure member
record option mask.
(LARCH_ATTR_MASK): New macro.
(LARCH_ATTR_ENUM): Likewise.
(LARCH_ATTR_BOOL): Likewise.
(loongarch_handle_option): Support for new options.
(loongarch_process_one_target_attr): Added support for
the la64v1.1 extended instruction set.
* config/loongarch/t-loongarch: Generate loongarch-evol-attr.def.
* doc/extend.texi: Add new attribute description information.
* config/loongarch/loongarch-evol-attr.def: Generate.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/pragma-la64V1_1.c: New test.
* gcc.target/loongarch/pragma-la64V1_1-2.c: New test.
Andrew Pinski [Mon, 10 Nov 2025 20:22:28 +0000 (12:22 -0800)]
ifcvt: Fix factor_out_operators for BIT_FIELD_REF and BIT_INSERT_EXPR [PR122629]
So factor_out_operators will factor out some expressions but in the case
of BIT_FIELD_REF and BIT_INSERT_EXPR, this only allowed for operand 0 as the
other operands need to be constant.
Bootstrapped and tested on x86_64-linux-gnu.
PR tree-optimization/122629
gcc/ChangeLog:
* tree-if-conv.cc (factor_out_operators): Reject
BIT_FIELD_REF and BIT_INSERT_EXPR if operand other
than 0 is different.
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr122629-1.c: New test.
* gcc.dg/torture/pr122629-2.c: New test.
* gcc.dg/tree-ssa/pr122629-1.c: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Jakub Jelinek [Tue, 11 Nov 2025 07:29:22 +0000 (08:29 +0100)]
gimplify-me: Fix regimplification of gimple-reg-type clobbers [PR122620]
Since r11-2238-ge443d8213864ac337c29092d4767224f280d2062 the C++ FE
emits clobbers like *_1 = {CLOBBER}; where *_1 MEM_REF has some scalar
type like int for -flifetime-dse={1,2} and most of the compiler manages
to cope with that.
If we are very unlucky, we trigger an ICE while trying to regimplify it
(at least during inlining), as happens with GCC 15.2 on firefox-145.0
built with LTO+PGO.
I haven't managed to reduce that to a small testcase that would ICE though,
the clobber certainly appears in code like
template <typename T>
struct S {
T *p;
union { char a; T b; };
static S foo (T *x) { S s; s.p = x; s.b.~T (); return s; }
~S ();
};
void
bar ()
{
int i = 42;
S <int> s = S <int>::foo (&i);
}
but convincing inliner that it should id->regimplify = true; on exactly
that stmt has been difficult.
The ICE is because we try (in two spots) to regimplify the rhs of the
gimple_clobber_p stmt if gimple-reg-type type (i.e. the TREE_CLOBBER),
because it doesn't satisfy the is_gimple_mem_rhs_or_call predicate
returned by rhs_predicate_for for the MEM_REF lhs. And regimplify it
by trying to gimplify SSA_NAME = {CLOBBER}; INIT_EXPR and in there reach
a special case which stores that freshly made SSA_NAME into memory and
loads it from memory, so uses a SSA_NAME without SSA_NAME_DEF_STMT.
Fixed thusly by saying clobbers are ok even for the gimple-reg-types.
2025-11-11 Jakub Jelinek <jakub@redhat.com>
PR lto/122620
* gimplify-me.cc (gimple_regimplify_operands): Don't try to regimplify
TREE_CLOBBER on rhs of gimple_clobber_p if it has gimple_reg_type.
Hu, Lin1 [Tue, 28 Oct 2025 08:11:47 +0000 (16:11 +0800)]
i386: Support C++ template parameters in AMX intrinsics [PR122446]
The AMX intrinsics previously used string concatenation with the '#'
operator to construct register names, which prevented their use with
C++ template non-type parameters. This patch converts all AMX intrinsics
to use inline assembly constraints with the %c format specifier.
And Intel style registers also have % prefix, update Intel syntax to use plain
register names without % preifx.
Nathaniel Shead [Mon, 10 Nov 2025 12:41:25 +0000 (23:41 +1100)]
c++/modules: Propagate purviewness to all parent namespaces
In PR c++/100134, tsubst_friend_function was adjusted to ensure that
instantiating a friend function in an unopened namespace still correctly
marked the namespace as purview. This adjusts the fix to also apply
to nested namespaces.
gcc/cp/ChangeLog:
* pt.cc (tsubst_friend_function): Mark all parent namespaces as
purview if needed.
Store the 'rid' value in a local variable, and pass it to functions that
handle various keywords. This simplifies the code, and removes some
wrappers.
No functional change intended.
gcc/c/ChangeLog:
* c-parser.cc (c_parser_sizeof_expression): Remove function.
(c_parser_countof_expression): Remove function.
(c_parser_unary_expression): Store the 'rid', and pass it
directly to the function calls, without calling wrappers.
Suggested-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Sam James [Sun, 9 Nov 2025 02:00:52 +0000 (02:00 +0000)]
gcc: quote some expressions in `test x...`
$gcc_cv_nm may contain a string with spaces since r16-4178-g6051a849aa1e8e and r16-5013-gf8bb20167f8127. It was possible for this to happen via strange user
input in the past too. `test x$gcc_cv_nm != x` therefore produces some noise
like:
```
checking assembler for working .subsection -1...
/usr/m68k-unknown-linux-gnu/tmp/portage/sys-devel/gcc-16.0.9999/work/gcc-16.0.9999/gcc/configure: line 26132: test: syntax error: `--plugin' unexpected
```
Quote a bunch of such tests. I've drive-by quoted other such tests where
they're for a program and may have a similar problem, but not all other
such tests (much larger patch and not at least strictly necessary).
Andrew Pinski [Sat, 8 Nov 2025 05:08:42 +0000 (21:08 -0800)]
builtins: Fix atomics expansion after build_call_nary change [PR122605]
So before r16-5089-gc66ebc3e22138, we could call build_call_nary with more
arguments than was passed as the nargs. Afterwards we get an assert if there
were not exactly that amount.
In this case the code is easier to read when passing the correct number of args
in the first place.
This fixes the two places in builtins.cc where this pattern shows up.
Bootstrapped and tested on x86_64-linux-gnu (and tested the testcase with -m32 where
the failure showed up).
PR middle-end/122605
gcc/ChangeLog:
* builtins.cc (expand_ifn_atomic_bit_test_and): Split out the call to
build_call_nary into two different statements.
(expand_ifn_atomic_op_fetch_cmp_0): Likewise.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Sandra Loosemore [Thu, 30 Oct 2025 00:56:22 +0000 (00:56 +0000)]
Documentation for -fident and -Qy/-Qn options [PR122243]
I noticed that the comments for -fident in common.opt were garbled,
and its description is confusing; this is classed as a code generation
option rather than a preprocessor option, and it controls emission of all
".ident" directives in the assembly file, not just those inserted by the
"#ident" preprocessor directive. Also, the -Qy/-Qn options which have the
same effect as -fident/-fno-ident were documented as System V Options when
in fact they are available on all targets. Fixed thusly.
gcc/ChangeLog
PR other/122243
* common.opt: Clean up comments/documentation for -fident.
* doc/invoke.texi: Move -Qy/-Qn documentation from System V options
and combine with -fident/-fno-ident entry.
Sandra Loosemore [Wed, 29 Oct 2025 22:11:44 +0000 (22:11 +0000)]
Document linker options + -Q and -S [PR122243]
This patch adds documentation for several options that the GCC driver
passes to the linker via specs without further interpretation. I've
also added some comments/documentation strings to common.opt for these
and a couple other options that previously didn't have any.
GCC has long supported long-form command-line options with the same
meanings as its traditional one-character options, e.g. --output as an
alias for -o, --language for -x, and so on. However, these have never
been documented in the manual. This patch adds the missing
documentation for these options, plus some additional options that
have previously undocumented two-dash aliases with the same names as
the one-dash form (e.g., -dumpdir and --dumpdir).
Sandra Loosemore [Wed, 22 Oct 2025 01:58:01 +0000 (01:58 +0000)]
Only document -A/--assert options in cpp manual [PR122243]
Assertions are a preprocessor feature that has been declared obsolete
with strong warnings not to use them since 2001. The main GCC manual
documents the -A command-line option but doesn't include the section
that explains the purpose of the feature or that it is obsolete; that
material appears only in the preprocessor manual. It seems rather pointless
to clutter up the GCC manual with unhelpful documentation of an obsolete
feature, so I've restricted the option documentation to the
preprocessor manual too. I've also added the missing documentation
entries for the long form of the option, --assert.
gcc/ChangeLog
PR other/122243
* doc/cppopts.texi (-A): Restrict option documentation to the CPP
manual. Also document the --assert form.
* doc/invoke.texi (Option Summary): Don't list the -A option.
I noticed that several options (mostly C++ options, including those
for contracts) were documented in the manual but were not listed in
the corresponding option summary table. Besides adding the entries, I
also corrected the alphabetization in the C++ option table and some
formatting issues for option arguments.
gcc/ChangeLog
PR other/122243
* doc/invoke.texi (Option Summary): Add missing entries,
also correct alphabetization and formatting of the C++ options.
(C++ Language Options): Fix some formatting issues.
Sandra Loosemore [Tue, 28 Oct 2025 22:38:08 +0000 (22:38 +0000)]
Mark some undocumented options as such [PR122243]
We have a number of command-line options that are undocumented (either
intentionally or because they are obsolete and retained only for
compatibility), that ought to be marked as "Undocumented". I've also
added some comments to the .opt files.
gcc/c-family/ChangeLog
PR other/122243
* c.opt (fmodule-version-ignore): Mark as "Undocumented".
gcc/ChangeLog
PR other/122243
* common.opt (fhelp, fhelp=, ftarget-help, fversion): Mark as
"Undocumented".
(fbounds-check): Update comments.
(flag-graphite, fsel-sched-reschedule-pipelined): Mark as
"Undocumented".
(fstack-limit): Add comment.
Sandra Loosemore [Fri, 17 Oct 2025 15:11:47 +0000 (15:11 +0000)]
Add "RejectNegative" to some options where it doesn't make sense [PR122243]
This patch adds the "RejectNegative" property to several options where
it doesn't make sense. These are either options of the form
"name=value" rather than an on/off switch, those that are already in a
"no-" form, or options that form a mutually-exclusive set.
Also, the fhelp, ftarget-help, and fversion options that do not take
arguments ignore the "-no" prefix so that even "-fno-help" (etc)
causes help to be printed instead of suppressing help output. Since that
behavior is not useful, I've added RejectNegative to those options as well.
Sandra Loosemore [Wed, 15 Oct 2025 23:30:00 +0000 (23:30 +0000)]
Add some missing @opindex entries [PR122243]
The options handled in this patch already have documentation but are
either missing an @opindex entry entirely, or index only the negative
option form.
Splitting a CONST_INT address into base and offset can be beneficial
when accessing multiple addresses in the same UBYTE region. The base
constant load can be shared among those accesses.
There is no regression for single accesses per UBYTE memory region.
The transformation by TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS generates
practically equivalent code:
For PRU there is a small complication. While load/store instructions
support base+offset addressing, the call instructions do not.
But the TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS arguments do not show
which operation is using the address, so invalid address is emitted for
call instructions to CONST_INT addresses. This is solved by fixing up
the call address operands during expansion.
PR target/122415
gcc/ChangeLog:
* config/pru/pru-protos.h (pru_fixup_jump_address_operand):
Declare.
* config/pru/pru.cc (pru_fixup_jump_address_operand): New
function.
(pru_addr_space_legitimize_address): New function.
(TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS): Declare.
* config/pru/pru.md (call): Fixup the address operand.
(call_value): Ditto.
(sibcall): Ditto.
(sibcall_value): Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/pru/pr122415-1.c: New test.
* gcc.target/pru/pr122415-2.c: New test.
Tejas Belagod [Mon, 6 Jan 2025 05:53:44 +0000 (11:23 +0530)]
AArch64: Support C/C++ operations on svbool_t
Support a subset of C/C++ operations (bitwise, conditional etc.) on svbool_t.
gcc/c-family/ChangeLog:
* c-common.cc (c_build_vec_convert): Support vector boolean
types for __builtin_convertvector ().
gcc/c/ChangeLog:
* c-typeck.cc (build_binary_op): Support vector boolean types.
gcc/cp/ChangeLog:
* typeck.cc (cp_build_binary_op): Likewise.
* call.cc (build_conditional_expr): Support vector booleans.
* cvt.cc (ocp_convert): Call target hook to resolve conversion
between standard and non-standard booleans.
gcc/ChangeLog:
* config/aarch64/aarch64-sve-builtins.cc (register_builtin_types): Make
SVE vector boolean type equivalent to GNU vectors.
* config/aarch64/aarch64-sve.md (extend<vpred><mode>2,
zero_extend<vpred><mode>2, trunc<mode><vpred>2, vec_cmp<mode><mode>):
New patterns to support additional operations on predicate modes.
* config/aarch64/aarch64.cc (aarch64_valid_vector_boolean_op): New.
(aarch64_invalid_unary_op): Consider vector bool types.
(aarch64_invalid_binary_op): Likewise.
(aarch64_convert_to_type): Define target hook and handle standard to
non-standard bool conversion.
arm: Don't reject early mov?fcc patterns that we might be able to handle
The define_expand patterns for movdfcc, movsfcc and movhfcc had overly
tight contstraints that could cause the compiler to reject these
patterns when re-ordering the operands could lead to a successful
match. Relax the initial predicate test and rely on the test after
arm_validize_comparison has run to determine whether this is something
we can support. This fixes some test failures which were introduced
in the fix for PR118460
gcc/ChangeLog:
PR target/118460
* config/arm/arm.md (movhfcc): Use expandable_comparison_operator.
(movsfcc, movdfcc): Likewise.
Robin Dapp [Fri, 7 Nov 2025 14:54:52 +0000 (15:54 +0100)]
vect: Do not set range for step != 1 [PR121985].
In PR120922 we first disabled setting a range on niters_vector for
partial vectorization and later introduced a ceiling division instead.
In PR121985 we ran into this again where a bogus range caused wrong code
later. On top I saw several instances of this issue on a local branch
that enables more VLS length-controlled loops.
I believe we must not set niter_vector's range to TYPE_MAX / VF, no
matter the rounding due to the way niters_vector is used. It's not
really identical to the number of vector iterations but the actual
number the loop will iterate is niters_vector / step where step = VF
for partial vectors.
Thus, only set the range to TYPE_MAX / VF if step == 1.
gcc/ChangeLog:
PR middle-end/121985
* tree-vect-loop-manip.cc (vect_gen_vector_loop_niters): Only
set niter_vector's range if step == 1.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr121985.c: New test.
Robin Dapp [Fri, 7 Nov 2025 09:21:36 +0000 (10:21 +0100)]
optabs: Do not pun modes smaller than QImode.
In can_vec_perm_const_p if we cannot directly permute a vector mode we
try to pun it with a byte mode. qimode_for_vec_perm checks gets the
mode size and uses that as number of elements for the new QImode vector.
This doesn't work for RVV mask vectors, though. First, their
precision might be smaller than a byte and second, there is no
way to easily pun them. The most common way would be a vector select
from {0, 0, ...} and {1, 1, ...} vectors. Therefore this patch checks
if the perm's innermode precision is a multiple of QImode's precision.
Bootstrapped and regtested on x86 and power10. Regtested on aarch64 and
riscv64.
gcc/ChangeLog:
* optabs-query.cc (qimode_for_vec_perm): Check if QImode's
precision divides the inner mode's precision.
Robin Dapp [Fri, 7 Nov 2025 16:18:02 +0000 (17:18 +0100)]
vect: Give up if there is no offset_vectype.
vect_gather_scatter_fn_p currently ICEs if offset_vectype is NULL.
This is an oversight in the patches that relax gather/scatter detection.
Catch this.
gcc/ChangeLog:
* tree-vect-data-refs.cc (vect_gather_scatter_fn_p): Bail if
offset_vectype is NULL.
Robin Dapp [Thu, 9 Oct 2025 15:25:59 +0000 (17:25 +0200)]
vect: Reduce group size of consecutive strided accesses.
Consecutive load permutations like {0, 1, 2, 3} or {4, 5, 6, 7} in a
group of 8 only read a part of the group, leaving a gap.
For strided accesses we can elide the permutation and, instead of
accessing the whole group, use the number of SLP lanes. This
effectively increases the vector size as we don't load gaps. On top we
do not need to emit the permutes at all.
gcc/ChangeLog:
* tree-vect-slp.cc (vect_load_perm_consecutive_p): New function.
(vect_lower_load_permutations): Use.
(vect_optimize_slp_pass::remove_redundant_permutations): Use.
* tree-vect-stmts.cc (has_consecutive_load_permutation): New
function that uses vect_load_perm_consecutive_p.
(get_load_store_type): Use.
(vectorizable_load): Reduce group size.
* tree-vectorizer.h (struct vect_load_store_data): Add
subchain_p.
(vect_load_perm_consecutive_p): Declare.
Jakub Jelinek [Mon, 10 Nov 2025 11:52:45 +0000 (12:52 +0100)]
c++: Implement C++26 P3920R0 - Wording for NB comment resolution on trivial relocation
Trivial relocation was voted out of C++26, the following patch
removes it (note, the libstdc++ part was still waiting for patch review
and so doesn't need to be removed).
This isn't a mere revert of r16-2206; I've kept -Wc++26-compat option,
from earlier patches the non-terminal stays to be class-property-specifier,
and I had to partially revert also various follow-up changes, e.g. for
modules to handle the new flags and test them, for -Wkeyword-macro
etc. to diagnose the conditional keywords or the feature test macro
etc.
Jakub Jelinek [Mon, 10 Nov 2025 10:36:42 +0000 (11:36 +0100)]
c++: Diagnose #define/#undef indeterminate
While working on CWG3053 I've noticed I forgot to enable diagnostics
on #define indeterminate or #undef indeterminate now that it is handled
as valid C++26 attribute.
2025-11-10 Jakub Jelinek <jakub@redhat.com>
gcc/cp/
* lex.cc (cxx_init): For C++26 call cpp_warn on "indeterminate".
gcc/testsuite/
* g++.dg/warn/Wkeyword-macro-1.C: Expect diagnostics on define/undef
of indeterminate.
* g++.dg/warn/Wkeyword-macro-2.C: Likewise.
* g++.dg/warn/Wkeyword-macro-4.C: Likewise.
* g++.dg/warn/Wkeyword-macro-5.C: Likewise.
* g++.dg/warn/Wkeyword-macro-7.C: Likewise.
* g++.dg/warn/Wkeyword-macro-8.C: Likewise.
Jakub Jelinek [Mon, 10 Nov 2025 10:34:20 +0000 (11:34 +0100)]
c++, libcpp: Implement CWG3053
The following patch implements CWG3053 approved in Kona, where it is now
valid not just to #define likely(a) or #define unlikely(a, b, c) but also
to #undef likely or #undef unlikely.
2025-11-10 Jakub Jelinek <jakub@redhat.com>
libcpp/
* directives.cc: Implement CWG3053.
(do_undef): Don't pedwarn or warn about #undef likely or #undef
unlikely.
gcc/testsuite/
* g++.dg/warn/Wkeyword-macro-4.C: Don't diagnose for #undef likely
or #undef unlikely.
* g++.dg/warn/Wkeyword-macro-5.C: Likewise.
* g++.dg/warn/Wkeyword-macro-9.C: Likewise.
* g++.dg/warn/Wkeyword-macro-8.C: Likewise.
* g++.dg/warn/Wkeyword-macro-10.C: Likewise.
Lewis Hyatt [Wed, 30 Jul 2025 23:20:55 +0000 (19:20 -0400)]
libcpp: Improve locations for macros defined prior to PCH include [PR105608]
It is permissible to define macros prior to including a PCH, as long as
these definitions are disjoint from or identical to the macros in the
PCH. The PCH loading process replaces all libcpp data structures with those
from the PCH, so it is necessary to remember the extra macros separately and
then restore them after loading the PCH, which all is handled by
cpp_save_state() and cpp_read_state() in libcpp/pch.cc. The restoration
process consists of pushing a buffer containing the macro definition and
then lexing it from there, similar to how a command-line -D option is
processed. The current implementation does not attempt to set up the
line_map for this process, and so the locations assigned to the macros are
often not meaningful. (Similar to what happened in the past with lexing the
tokens out of a _Pragma string, lexing out of a buffer rather than a file
produces "sorta" reasonable locations that are often close enough, but not
reliably correct.)
Fix that up by remembering enough additional information (more or less, an
expanded_location for each macro definition) to produce a reasonable
location for the newly restored macros.
One issue that came up is the treatment of command-line-defined macros. From
the perspective of the generic line_map data structures, the command-line
location is not distinguishable from other locations; it's just an ordinary
location created by the front ends with a fake file name by convention. (At
the moment, it is always the string `<command-line>', subject to
translation.) Since libcpp needs to assign macros to that location, it
needs to know what location to use, so I added a new member
line_maps::cmdline_location for the front ends to set, similar to how
line_maps::builtin_location is handled.
This revealed a small issue, in c-opts.cc we have:
/* All command line defines must have the same location. */
cpp_force_token_locations (parse_in, line_table->highest_line);
But contrary to the comment, all command line defines don't actually end up
with the same location anymore. This is because libcpp/lex.cc has been
expanded (r6-4873) to include range information on the returned
locations. That logic has never been respecting the request of
cpp_force_token_locations. I believe this was not intentional, and so I have
corrected that here. Prior to this patch, the range logic has been leading
to command-line macros all having similar locations in the same line map (or
ad-hoc locations based from there for sufficiently long tokens); with this
change, they all have exactly the same location and that location is
recorded in line_maps::cmdline_location.
With that change, then it works fine for pch.cc to restore macros whether
they came from the command-line or from the main file.
gcc/c-family/ChangeLog:
PR preprocessor/105608
* c-opts.cc (c_finish_options): Set new member
line_table->cmdline_location.
* c-pch.cc (c_common_read_pch): Adapt linemap usage to changes in
libcpp pch.cc; it is now possible that the linemap is in a different
file after returning from cpp_read_state().
libcpp/ChangeLog:
PR preprocessor/105608
* include/line-map.h: Add new member CMDLINE_LOCATION.
* lex.cc (get_location_for_byte_range_in_cur_line): Do not expand
the token location to include range information if token location
override was requested.
(warn_about_normalization): Likewise.
(_cpp_lex_direct): Likewise.
* pch.cc (struct saved_macro): New local struct.
(struct save_macro_data): Change DEFNS vector to hold saved_macro
rather than uchar*.
(save_macros): Adapt to remember the location information for each
saved macro in addition to the definition.
(cpp_prepare_state): Likewise.
(cpp_read_state): Use the saved location information to generate
proper locations for the restored macros.
gcc/testsuite/ChangeLog:
PR preprocessor/105608
* g++.dg/pch/line-map-3.C: Remove xfails.
* g++.dg/pch/line-map-4.C: New test.
* g++.dg/pch/line-map-4.Hs: New test.
Mark Wielaard [Sun, 9 Nov 2025 21:12:19 +0000 (22:12 +0100)]
Regenerate libgfortran Makefile.in and aclocal.m4
Commit a1fe2cfa8965 ("fortran: [PR121628]") regenerated libgfortran
Makefile.an and aclocal.m4 files with automake 1.15 instead of 1.15.1.
Run autoreconf version 2.69 with automake 1.15.1 inside libgfortran.
Eric Botcazou [Sat, 8 Nov 2025 18:15:46 +0000 (19:15 +0100)]
Ada: Fix bogus error on limited with clause and private parent package
The implementation of the 10.1.2(8/2-11/2) subclauses that establish rules
for the legality of "with" clauses of private child units is done separately
for regular "with" clauses (in Check_Private_Child_Unit) and for limited
"with" clauses (in Check_Private_Limited_Withed_Unit). The testcase, which
contains the regular and the "limited" version of the same pattern, exhibits
a disagreement between them; the former implementation is correct and the
latter is wrong in this case.
The patch fixes the problem and also cleans up the latter implementation by
aligning it with the former as much as possible.
gcc/ada/
PR ada/34374
* sem_ch10.adb (Check_Private_Limited_Withed_Unit): Use a separate
variable for the private child unit, streamline the loop locating
the nearest private ancestor, fix a too early termination of the
loop traversing the ancestor of the current unit, and use the same
privacy test as Check_Private_Child_Unit.
Philipp Tomsich [Sat, 8 Nov 2025 16:28:07 +0000 (09:28 -0700)]
[RISC-V] Add testcase for shifted truthvalue
I was doing some cleanup on our internal tree and noticed a pattern that I
didn't think was actually useful in practice. Thankfully the internal commit
included a testcase clearly targeting that pattern.
I'm upstreaming the testcase, but not the unnecessary pattern.
gcc/testsuite
* gcc.target/riscv/snez.c: New test.
Avinash Jayakar [Sat, 8 Nov 2025 04:27:59 +0000 (09:57 +0530)]
isel: Check bounds before converting VIEW_CONVERT to VEC_SET.
The function gimple_expand_vec_set_expr in the isel pass, converted
VIEW_CONVERT_EXPR to VEC_SET_EXPR without checking the bounds on the index,
which cause ICE on targets that supported VEC_SET_EXPR like x86 and powerpc.
This patch adds a bound check on the index operand and rejects the conversion
if index is out of bound.
Lulu Cheng [Mon, 3 Nov 2025 09:53:52 +0000 (17:53 +0800)]
LoongArch: Fix PR122097 (2).
r16-4703 does not completely fix PR122097. Floating-point vectors
were not processed in the function loongarch_const_vector_same_bytes_p.
This patch will completely resolve this issue.
PR target/122097
gcc/ChangeLog:
* config/loongarch/loongarch.cc
(loongarch_const_vector_same_bytes_p): Add processing for
floating-point vector data.
projects / thirdparty / gcc.git / log
