Nathaniel Shead [Fri, 15 Dec 2023 23:59:03 +0000 (10:59 +1100)]
c++: Fix unchecked use of CLASSTYPE_AS_BASE [PR113031]
My previous commit (naively) assumed that a TREE_CODE of RECORD_TYPE or
UNION_TYPE was sufficient for optype to be considered a "class type".
However, this does not account for e.g. template type parameters of
record or union type. This patch corrects to check for CLASS_TYPE_P
before checking for as-base conversion.
PR c++/113031
gcc/cp/ChangeLog:
* constexpr.cc (cxx_fold_indirect_ref_1): Check for CLASS_TYPE
before using CLASSTYPE_AS_BASE.
Andrew Carlotti [Wed, 20 Sep 2023 11:24:31 +0000 (12:24 +0100)]
[aarch64] Add function multiversioning support
This adds initial support for function multiversioning on aarch64 using
the target_version and target_clones attributes. This loosely follows
the Beta specification in the ACLE [1], although with some differences
that still need to be resolved (possibly as follow-up patches).
Existing function multiversioning implementations are broken in various
ways when used across translation units. This includes placing
resolvers in the wrong translation units, and using symbol mangling that
callers to unintentionally bypass the resolver in some circumstances.
Fixing these issues for aarch64 will require modifications to our ACLE
specification. It will also require further adjustments to existing
middle end code, to facilitate different mangling and resolver
placement while preserving existing target behaviours.
The list of function multiversioning features specified in the ACLE is
also inconsistent with the list of features supported in target option
extensions. I intend to resolve some or all of these inconsistencies at
a later stage.
The target_version attribute is currently only supported in C++, since
this is the only frontend with existing support for multiversioning
using the target attribute. On the other hand, this patch happens to
enable multiversioning with the target_clones attribute in Ada and D, as
well as the entire C family, using their existing frontend support.
This patch also does not support the following aspects of the Beta
specification:
- The target_clones attribute should allow an implicit unlisted
"default" version.
- There should be an option to disable function multiversioning at
compile time.
- Unrecognised target names in a target_clones attribute should be
ignored (with an optional warning). This current patch raises an
error instead.
Andrew Carlotti [Tue, 19 Sep 2023 18:13:22 +0000 (19:13 +0100)]
Add support for target_version attribute
This patch adds support for the "target_version" attribute to the middle
end and the C++ frontend, which will be used to implement function
multiversioning in the aarch64 backend.
On targets that don't use the "target" attribute for multiversioning,
there is no conflict between the "target" and "target_clones"
attributes. This patch therefore makes the mutual exclusion in
C-family, D and Ada conditonal upon the value of the
expanded_clones_attribute target hook.
The "target_version" attribute is only added to C++ in this patch,
because this is currently the only frontend which supports
multiversioning using the "target" attribute. Support for the
"target_version" attribute will be extended to C at a later date.
Targets that currently use the "target" attribute for function
multiversioning (i.e. i386 and rs6000) are not affected by this patch.
gcc/ChangeLog:
* attribs.cc (decl_attributes): Pass attribute name to target.
(is_function_default_version): Update comment to specify
incompatibility with target_version attributes.
* cgraphclones.cc (cgraph_node::create_version_clone_with_body):
Call valid_version_attribute_p for target_version attributes.
* defaults.h (TARGET_HAS_FMV_TARGET_ATTRIBUTE): New macro.
* target.def (valid_version_attribute_p): New hook.
* doc/tm.texi.in: Add new hook.
* doc/tm.texi: Regenerate.
* multiple_target.cc (create_dispatcher_calls): Remove redundant
is_function_default_version check.
(expand_target_clones): Use target macro to pick attribute name.
* targhooks.cc (default_target_option_valid_version_attribute_p):
New.
* targhooks.h (default_target_option_valid_version_attribute_p):
New.
* tree.h (DECL_FUNCTION_VERSIONED): Update comment to include
target_version attributes.
Andrew Carlotti [Mon, 6 Nov 2023 16:20:47 +0000 (16:20 +0000)]
ada: Improve attribute exclusion handling
Change the handling of some attribute mutual exclusions to use the
generic attribute exclusion lists, and fix some asymmetric exclusions by
adding the exclusions for always_inline after noinline or target_clones.
Aside from the new always_inline exclusions, the only change is
functionality is the choice of warning message displayed. All warnings
about attribute mutual exclusions now use the same message.
Andrew Carlotti [Mon, 6 Nov 2023 16:10:55 +0000 (16:10 +0000)]
c-family: Simplify attribute exclusion handling
This patch changes the handling of mutual exclusions involving the
target and target_clones attributes to use the generic attribute
exclusion lists. Additionally, the duplicate handling for the
always_inline and noinline attribute exclusion is removed.
The only change in functionality is the choice of warning message
displayed - due to either a change in the wording for mutual exclusion
warnings, or a change in the order in which different checks occur.
Andrew Carlotti [Wed, 20 Sep 2023 11:22:09 +0000 (12:22 +0100)]
aarch64: Add cpu feature detection to libgcc
This is added to enable function multiversioning, but can also be used
directly. The interface is chosen to match that used in LLVM's
compiler-rt, to facilitate cross-compiler compatibility.
The content of the patch is derived almost entirely from Pavel's prior
contributions to compiler-rt/lib/builtins/cpu_model.c. I have made minor
changes to align more closely with GCC coding style, and to exclude any code
from other LLVM contributors, and am adding this to GCC with Pavel's approval.
libgcc/ChangeLog:
* config/aarch64/t-aarch64: Include cpuinfo.c
* config/aarch64/cpuinfo.c: New file
(__init_cpu_features_constructor) New.
(__init_cpu_features_resolver) New.
(__init_cpu_features) New.
Andrew Carlotti [Fri, 24 Nov 2023 17:31:51 +0000 (17:31 +0000)]
aarch64: Fix +nopredres, +nols64 and +nomops
For native cpu feature detection, certain features have no entry in
/proc/cpuinfo, so have to be assumed to be present whenever the detected
cpu is supposed to support that feature.
However, the logic for this was mistakenly implemented by excluding
these features from part of aarch64_get_extension_string_for_isa_flags.
This function is also used elsewhere when canonicalising explicit
feature sets, which may require removing features that are normally
implied by the specified architecture version.
This change reenables generation of +nopredres, +nols64 and +nomops
during canonicalisation, by relocating the misplaced native cpu
detection logic.
gcc/ChangeLog:
* common/config/aarch64/aarch64-common.cc
(struct aarch64_option_extension): Remove unused field.
(all_extensions): Ditto.
(aarch64_get_extension_string_for_isa_flags): Remove filtering
of features without native detection.
* config/aarch64/driver-aarch64.cc (host_detect_local_cpu):
Explicitly add expected features that lack cpuinfo detection.
Andrew Carlotti [Fri, 24 Nov 2023 17:06:07 +0000 (17:06 +0000)]
aarch64: Fix +nocrypto handling
Additionally, replace all checks for the AARCH64_FL_CRYPTO bit with
checks for (AARCH64_FL_AES | AARCH64_FL_SHA2) instead. The value of the
AARCH64_FL_CRYPTO bit within isa_flags is now ignored, but it is
retained because removing it would make processing the data in
option-extensions.def significantly more complex.
This bug should have been picked up by an existing test, but a missing
newline meant that the pattern incorrectly allowed "+crypto+nocrypto".
gcc/ChangeLog:
* common/config/aarch64/aarch64-common.cc
(aarch64_get_extension_string_for_isa_flags): Fix generation of
the "+nocrypto" extension.
* config/aarch64/aarch64.h (AARCH64_ISA_CRYPTO): Remove.
(TARGET_CRYPTO): Remove.
* config/aarch64/aarch64-c.cc (aarch64_update_cpp_builtins):
Don't use TARGET_CRYPTO.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/options_set_4.c: Add terminating newline.
* gcc.target/aarch64/options_set_27.c: New test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/cv-elw-elw-compile-1.c: Create test for cv.elw.
* lib/target-supports.exp: Add proc for the XCVelw extension.
Patrick O'Neill [Fri, 15 Dec 2023 21:47:19 +0000 (14:47 -0700)]
[PATCH] RISC-V: Add -fno-vect-cost-model to pr112773 testcase
The testcase for pr112773 started passing after r14-6472-g8501edba91e
which was before the actual fix. This patch adds -fno-vect-cost-model
which prevents the testcase from passing due to the vls change.
Jeff Law [Fri, 15 Dec 2023 21:19:25 +0000 (14:19 -0700)]
Re: [PATCH] RISC-V: fix scalar crypto patterns
A handful of the scalar crypto instructions are supposed to take a
constant integer argument 0..3 inclusive and one should accept 0..10.
A suitable constraint was created and used for this purpose (D03 and DsA),
but the operand's predicate is "register_operand". That's just wrong.
This patch adds a new predicates "const_0_3_operand" and "const_0_10_operand"
and fixes the relevant insns to use the appropriate predicate. It drops the
now unnecessary constraints.
The testsuite was broken in a way that made it consistent with the
compiler, so the tests passed, when they really should have been issuing
errors all along.
This patch adjusts the existing tests so that they all expect a
diagnostic on the invalid operand usage (including out of range
constants). It adds new tests with proper constants, testing the
extremes of valid values.
PR target/110201
gcc/
* config/riscv/constraints.md (D03, DsA): Remove unused constraints.
* config/riscv/predicates.md (const_0_3_operand): New predicate.
(const_0_10_operand): Likewise.
* config/riscv/crypto.md (riscv_aes32dsi): Use new predicate. Drop
unnecessary constraint.
(riscv_aes32dsmi, riscv_aes64im, riscv_aes32esi): Likewise.
(riscv_aes32esmi, *riscv_<sm4_op>_si): Likewise.
(riscv_<sm4_op>_di_extend, riscv_<sm4_op>_si): Likewise.
The pass is local (only considers a BB at a time). In theory, it should
be possible to extend it to run over EBBs, at least in the case of pure
(MEM_READONLY_P) loads, but this is left for future work.
The pass works by identifying two kinds of bases: tree decls obtained
via MEM_EXPR, and RTL register bases in the form of RTL-SSA def_infos.
If a candidate memory access has a MEM_EXPR base, then we track it via
this base, and otherwise if it is of a simple reg + <imm> form, we track
it via the RTL-SSA def_info for the register.
For each BB, for a given kind of base, we build up a hash table mapping
the base to an access_group. The access_group data structure holds a
list of accesses at each offset relative to the same base. It uses a
splay tree to support efficient insertion (while walking the bb), and
the nodes are chained using a linked list to support efficient
iteration (while doing the transformation).
For each base, we then iterate over the access_group to identify
adjacent accesses, and try to form load/store pairs for those insns that
access adjacent memory.
The pass is currently run twice, both before and after register
allocation. The first copy of the pass is run late in the pre-RA RTL
pipeline, immediately after sched1, since it was found that sched1 was
increasing register pressure when the pass was run before. The second
copy of the pass runs immediately before peephole2, so as to get any
opportunities that the existing ldp/stp peepholes can handle.
There are some cases that we punt on before RA, e.g.
accesses relative to eliminable regs (such as the soft frame pointer).
We do this since we can't know the elimination offset before RA, and we
want to avoid the RA reloading the offset (due to being out of ldp/stp
immediate range) as this can generate worse code.
The post-RA copy of the pass is there to pick up the crumbs that were
left behind / things we punted on in the pre-RA pass. Among other
things, it's needed to handle accesses relative to the stack pointer.
It can also handle code that didn't exist at the time the pre-RA pass
was run (spill code, prologue/epilogue code).
This is an initial implementation, and there are (among other possible
improvements) the following notable caveats / missing features that are
left for future work, but could give further improvements:
- Moving accesses between BBs within in an EBB, see above.
- Out-of-range opportunities: currently the pass refuses to form pairs
if there isn't a suitable base register with an immediate in range
for ldp/stp, but it can be profitable to emit anchor addresses in the
case that there are four or more out-of-range nearby accesses that can
be formed into pairs. This is handled by the current ldp/stp
peepholes, so it would be good to support this in the future.
- Discovery: currently we prioritize MEM_EXPR bases over RTL bases, which can
lead to us missing opportunities in the case that two accesses have distinct
MEM_EXPR bases (i.e. different DECLs) but they are still adjacent in memory
(e.g. adjacent variables on the stack). I hope to address this for GCC 15,
hopefully getting to the point where we can remove the ldp/stp peepholes and
scheduling hooks. Furthermore it would be nice to make the pass aware of
section anchors (adding these as a third kind of base) allowing merging
accesses to adjacent variables within the same section.
gcc/ChangeLog:
* config.gcc: Add aarch64-ldp-fusion.o to extra_objs for aarch64.
* config/aarch64/aarch64-passes.def: Add copies of pass_ldp_fusion
before and after RA.
* config/aarch64/aarch64-protos.h (make_pass_ldp_fusion): Declare.
* config/aarch64/aarch64.opt (-mearly-ldp-fusion): New.
(-mlate-ldp-fusion): New.
(--param=aarch64-ldp-alias-check-limit): New.
(--param=aarch64-ldp-writeback): New.
* config/aarch64/t-aarch64: Add rule for aarch64-ldp-fusion.o.
* config/aarch64/aarch64-ldp-fusion.cc: New file.
* doc/invoke.texi (AArch64 Options): Document new
-m{early,late}-ldp-fusion options.
Alex Coplan [Thu, 16 Nov 2023 12:19:45 +0000 (12:19 +0000)]
aarch64: Rewrite non-writeback ldp/stp patterns
This patch overhauls the load/store pair patterns with two main goals:
1. Fixing a correctness issue (the current patterns are not RA-friendly).
2. Allowing more flexibility in which operand modes are supported, and which
combinations of modes are allowed in the two arms of the load/store pair,
while reducing the number of patterns required both in the source and in
the generated code.
The correctness issue (1) is due to the fact that the current patterns have
two independent memory operands tied together only by a predicate on the insns.
Since LRA only looks at the constraints, one of the memory operands can get
reloaded without the other one being changed, leading to the insn becoming
unrecognizable after reload.
We fix this issue by changing the patterns such that they only ever have one
memory operand representing the entire pair. For the store case, we use an
unspec to logically concatenate the register operands before storing them.
For the load case, we use unspecs to extract the "lanes" from the pair mem,
with the second occurrence of the mem matched using a match_dup (such that there
is still really only one memory operand as far as the RA is concerned).
In terms of the modes used for the pair memory operands, we canonicalize
these to V2x4QImode, V2x8QImode, and V2x16QImode. These modes have not
only the correct size but also correct alignment requirement for a
memory operand representing an entire load/store pair. Unlike the other
two, V2x4QImode didn't previously exist, so had to be added with the
patch.
As with the previous patch generalizing the writeback patterns, this
patch aims to be flexible in the combinations of modes supported by the
patterns without requiring a large number of generated patterns by using
distinct mode iterators.
The new scheme means we only need a single (generated) pattern for each
load/store operation of a given operand size. For the 4-byte and 8-byte
operand cases, we use the GPI iterator to synthesize the two patterns.
The 16-byte case is implemented as a separate pattern in the source (due
to only having a single possible alternative).
Since the UNSPEC patterns can't be interpreted by the dwarf2cfi code,
we add REG_CFA_OFFSET notes to the store pair insns emitted by
aarch64_save_callee_saves, so that correct CFI information can still be
generated. Furthermore, we now unconditionally generate these CFA
notes on frame-related insns emitted by aarch64_save_callee_saves.
This is done in case that the load/store pair pass forms these into
pairs, in which case the CFA notes would be needed.
We also adjust the ldp/stp peepholes to generate the new form. This is
done by switching the generation to use the
aarch64_gen_{load,store}_pair interface, making it easier to change the
form in the future if needed. (Likewise, the upcoming aarch64
load/store pair pass also makes use of this interface).
This patch also adds an "ldpstp" attribute to the non-writeback
load/store pair patterns, which is used by the post-RA load/store pair
pass to identify existing patterns and see if they can be promoted to
writeback variants.
One potential concern with using unspecs for the patterns is that it can block
optimization by the generic RTL passes. This patch series tries to mitigate
this in two ways:
1. The pre-RA load/store pair pass runs very late in the pre-RA pipeline.
2. A later patch in the series adjusts the aarch64 mem{cpy,set} expansion to
emit individual loads/stores instead of ldp/stp. These should then be
formed back into load/store pairs much later in the RTL pipeline by the
new load/store pair pass.
gcc/ChangeLog:
* config/aarch64/aarch64-ldpstp.md: Abstract ldp/stp
representation from peepholes, allowing use of new form.
* config/aarch64/aarch64-modes.def (V2x4QImode): Define.
* config/aarch64/aarch64-protos.h
(aarch64_finish_ldpstp_peephole): Declare.
(aarch64_swap_ldrstr_operands): Delete declaration.
(aarch64_gen_load_pair): Adjust parameters.
(aarch64_gen_store_pair): Likewise.
* config/aarch64/aarch64-simd.md (load_pair<DREG:mode><DREG2:mode>):
Delete.
(vec_store_pair<DREG:mode><DREG2:mode>): Delete.
(load_pair<VQ:mode><VQ2:mode>): Delete.
(vec_store_pair<VQ:mode><VQ2:mode>): Delete.
* config/aarch64/aarch64.cc (aarch64_pair_mode_for_mode): New.
(aarch64_gen_store_pair): Adjust to use new unspec form of stp.
Drop second mem from parameters.
(aarch64_gen_load_pair): Likewise.
(aarch64_pair_mem_from_base): New.
(aarch64_save_callee_saves): Emit REG_CFA_OFFSET notes for
frame-related saves. Adjust call to aarch64_gen_store_pair
(aarch64_restore_callee_saves): Adjust calls to
aarch64_gen_load_pair to account for change in interface.
(aarch64_process_components): Likewise.
(aarch64_classify_address): Handle 32-byte pair mems in
LDP_STP_N case.
(aarch64_print_operand): Likewise.
(aarch64_copy_one_block_and_progress_pointers): Adjust calls to
account for change in aarch64_gen_{load,store}_pair interface.
(aarch64_set_one_block_and_progress_pointer): Likewise.
(aarch64_finish_ldpstp_peephole): New.
(aarch64_gen_adjusted_ldpstp): Adjust to use generation helper.
* config/aarch64/aarch64.md (ldpstp): New attribute.
(load_pair_sw_<SX:mode><SX2:mode>): Delete.
(load_pair_dw_<DX:mode><DX2:mode>): Delete.
(load_pair_dw_<TX:mode><TX2:mode>): Delete.
(*load_pair_<ldst_sz>): New.
(*load_pair_16): New.
(store_pair_sw_<SX:mode><SX2:mode>): Delete.
(store_pair_dw_<DX:mode><DX2:mode>): Delete.
(store_pair_dw_<TX:mode><TX2:mode>): Delete.
(*store_pair_<ldst_sz>): New.
(*store_pair_16): New.
(*load_pair_extendsidi2_aarch64): Adjust to use new form.
(*zero_extendsidi2_aarch64): Likewise.
* config/aarch64/iterators.md (VPAIR): New.
* config/aarch64/predicates.md (aarch64_mem_pair_operand): Change to
a special predicate derived from aarch64_mem_pair_operator.
Alex Coplan [Wed, 1 Nov 2023 17:42:34 +0000 (17:42 +0000)]
aarch64: Generalize writeback ldp/stp patterns
Thus far the writeback forms of ldp/stp have been exclusively used in
prologue and epilogue code for saving/restoring of registers to/from the
stack.
As such, forms of ldp/stp that weren't needed for prologue/epilogue code
weren't supported by the aarch64 backend. This patch generalizes the
load/store pair writeback patterns to allow:
- Base registers other than the stack pointer.
- Modes that weren't previously supported.
- Combinations of distinct modes provided they have the same size.
- Pre/post variants that weren't previously needed in prologue/epilogue
code.
We make quite some effort to avoid a combinatorial explosion in the
number of patterns generated (and those in the source) by making
extensive use of special predicates.
An updated version of the upcoming ldp/stp pass can generate the
writeback forms, so this patch is motivated by that.
This patch doesn't add zero-extending or sign-extending forms of the
writeback patterns; that is left for future work.
gcc/ChangeLog:
* config/aarch64/aarch64-protos.h (aarch64_ldpstp_operand_mode_p): Declare.
* config/aarch64/aarch64.cc (aarch64_gen_storewb_pair): Build RTL
directly instead of invoking named pattern.
(aarch64_gen_loadwb_pair): Likewise.
(aarch64_ldpstp_operand_mode_p): New.
* config/aarch64/aarch64.md (loadwb_pair<GPI:mode>_<P:mode>): Replace with
...
(*loadwb_post_pair_<ldst_sz>): ... this. Generalize as described
in cover letter.
(loadwb_pair<GPF:mode>_<P:mode>): Delete (superseded by the
above).
(*loadwb_post_pair_16): New.
(*loadwb_pre_pair_<ldst_sz>): New.
(loadwb_pair<TX:mode>_<P:mode>): Delete.
(*loadwb_pre_pair_16): New.
(storewb_pair<GPI:mode>_<P:mode>): Replace with ...
(*storewb_pre_pair_<ldst_sz>): ... this. Generalize as
described in cover letter.
(*storewb_pre_pair_16): New.
(storewb_pair<GPF:mode>_<P:mode>): Delete.
(*storewb_post_pair_<ldst_sz>): New.
(storewb_pair<TX:mode>_<P:mode>): Delete.
(*storewb_post_pair_16): New.
* config/aarch64/predicates.md (aarch64_mem_pair_operator): New.
(pmode_plus_operator): New.
(aarch64_ldp_reg_operand): New.
(aarch64_stp_reg_operand): New.
Alex Coplan [Tue, 7 Nov 2023 21:25:02 +0000 (21:25 +0000)]
aarch64: Fix up printing of ldp/stp with -msve-vector-bits=128
Later patches allow using SVE modes in ldp/stp with -msve-vector-bits=128,
so we need to make sure that we don't use SVE addressing modes when
printing the address for the ldp/stp.
This patch does that.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_print_address_internal): Handle SVE
modes when printing ldp/stp addresses.
Alex Coplan [Thu, 2 Nov 2023 22:53:44 +0000 (22:53 +0000)]
aarch64: Fix up aarch64_print_operand xzr/wzr case
This adjusts aarch64_print_operand to recognize zero rtxes in modes other than
VOIDmode. This allows us to use xzr/wzr for zero vectors, for example.
We extract the test into a helper function, aarch64_const_zero_rtx_p, since this
predicate is needed by later patches.
gcc/ChangeLog:
* config/aarch64/aarch64-protos.h (aarch64_const_zero_rtx_p): New.
* config/aarch64/aarch64.cc (aarch64_const_zero_rtx_p): New.
Use it ...
(aarch64_print_operand): ... here. Recognize CONST0_RTXes in
modes other than VOIDmode.
Alex Coplan [Wed, 15 Nov 2023 18:12:36 +0000 (18:12 +0000)]
aarch64, testsuite: Allow ldp/stp on SVE regs with -msve-vector-bits=128
Later patches in the series allow ldp and stp to use SVE modes if
-msve-vector-bits=128 is provided. This patch therefore adjusts tests
that pass -msve-vector-bits=128 to allow ldp/stp to save/restore SVE
registers.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/pcs/stack_clash_1_128.c: Allow ldp/stp saves
of SVE registers.
* gcc.target/aarch64/sve/pcs/struct_3_128.c: Likewise.
Alex Coplan [Wed, 15 Nov 2023 10:24:41 +0000 (10:24 +0000)]
aarch64, testsuite: Fix up auto-init-padding tests
The tests currently depend on memcpy lowering forming stps at -O0,
but we no longer want to form stps during memcpy lowering, but instead
in the upcoming load/store pair fusion pass.
This patch therefore tweaks affected tests to enable optimizations
(-O1), and adjusts the tests to avoid parts of the structures being
optimized away where necessary.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/auto-init-padding-1.c: Add -O to options,
adjust test to work with optimizations enabled.
* gcc.target/aarch64/auto-init-padding-2.c: Add -O to options.
* gcc.target/aarch64/auto-init-padding-3.c: Add -O to options,
adjust test to work with optimizations enabled.
* gcc.target/aarch64/auto-init-padding-4.c: Likewise.
* gcc.target/aarch64/auto-init-padding-9.c: Likewise.
Xiao Zeng [Fri, 15 Dec 2023 19:24:53 +0000 (12:24 -0700)]
[PATCH] RISC-V: Add Zvfbfmin extension to the -march= option
This patch would like to add new sub extension (aka Zvfbfmin) to the
-march= option. It introduces a new data type BF16.
Depending on different usage scenarios, the Zvfbfmin extension may
depend on 'V' or 'Zve32f'. This patch only implements dependencies
in scenario of Embedded Processor. In scenario of Application
Processor, it is necessary to explicitly indicate the dependent
'V' extension.
You can locate more information about Zvfbfmin from below spec doc.
* gcc.target/riscv/arch-31.c: New test.
* gcc.target/riscv/arch-32.c: New test.
* gcc.target/riscv/predef-32.c: New test.
* gcc.target/riscv/predef-33.c: New test.
Gaius Mulley [Fri, 15 Dec 2023 15:26:48 +0000 (15:26 +0000)]
PR modula2/112946 ICE assignment of string to enumeration or set
This patch introduces type checking during FoldBecomes and also
adds set/string/enum checking to the type checker. FoldBecomes
has been re-written, tidied up and re-factored.
gcc/m2/ChangeLog:
PR modula2/112946
* gm2-compiler/M2Check.mod (checkConstMeta): New procedure
function.
(checkConstEquivalence): New procedure function.
(doCheckPair): Add call to checkConstEquivalence.
* gm2-compiler/M2GenGCC.mod (ResolveConstantExpressions): Call
FoldBecomes with reduced parameters.
(FoldBecomes): Re-write.
(TryDeclareConst): New procedure.
(RemoveQuads): New procedure.
(DeclaredOperandsBecomes): New procedure function.
(TypeCheckBecomes): New procedure function.
(PerformFoldBecomes): New procedure.
* gm2-compiler/M2Range.mod (FoldAssignment): Call
AssignmentTypeCompatible to check des expr compatibility.
* gm2-compiler/M2SymInit.mod (CheckReadBeforeInitQuad): Remove
parameter lst.
(FilterCheckReadBeforeInitQuad): Remove parameter lst.
(CheckReadBeforeInitFirstBasicBlock): Remove parameter lst.
Call FilterCheckReadBeforeInitQuad without lst.
gcc/testsuite/ChangeLog:
PR modula2/112946
* gm2/iso/fail/badassignment.mod: New test.
* gm2/iso/fail/badexpression.mod: New test.
* gm2/iso/fail/badexpression2.mod: New test.
Patrick Palka [Fri, 15 Dec 2023 15:03:31 +0000 (10:03 -0500)]
c++: section attribute on templates [PR70435, PR88061]
The section attribute currently has no effect on templates because the
call to set_decl_section_name only happens at parse time (on the
dependent decl) and not also at instantiation time. This patch fixes
this by propagating the section name from the template to the
instantiation.
* g++.dg/ext/attr-section1.C: New test.
* g++.dg/ext/attr-section1a.C: New test.
* g++.dg/ext/attr-section2.C: New test.
* g++.dg/ext/attr-section2a.C: New test.
* g++.dg/ext/attr-section2b.C: New test.
Andre Vieira [Fri, 15 Dec 2023 13:48:08 +0000 (13:48 +0000)]
Fix tests for gomp
This is to fix testisms initially introduced by:
commit f5fc001a84a7dbb942a6252b3162dd38b4aae311
Author: Andre Vieira <andre.simoesdiasvieira@arm.com>
Date: Mon Dec 11 14:24:41 2023 +0000
aarch64: enable mixed-types for aarch64 simdclones
Jonathan Wakely [Fri, 15 Dec 2023 12:58:37 +0000 (12:58 +0000)]
libstdc++: Fix std::print test case for Windows
libstdc++-v3/ChangeLog:
* src/c++23/print.cc (__write_to_terminal) [_WIN32]: If handle
does not refer to the console then just write to it using normal
file I/O.
* testsuite/27_io/print/2.cc (as_printed_to_terminal): Print
error message on failure.
(test_utf16_transcoding): Adjust for as_printed_to_terminal
modifying its argument.
Jonathan Wakely [Fri, 15 Dec 2023 12:24:26 +0000 (12:24 +0000)]
libstdc++: Simplify std::vprint_unicode for non-Windows targets
Since we don't need to do anything special to print Unicode on
non-Windows targets, we might as well just use std::vprint_nonunicode to
implement std::vprint_unicode. Removing the duplicated code should
reduce code size in cases where those calls aren't inlined.
Also use an RAII type for the unused case where a non-Windows target
calls __open_terminal(streambuf*) and needs to fclose the result. This
makes the code futureproof in case we ever start using the
__write_terminal function for non-Windows targets.
libstdc++-v3/ChangeLog:
* include/std/ostream (vprint_unicode) [_WIN32]: Use RAII guard.
(vprint_unicode) [!_WIN32]: Just call vprint_nonunicode.
* include/std/print (vprint_unicode) [!_WIN32]: Likewise.
Wilco Dijkstra [Fri, 1 Dec 2023 17:28:57 +0000 (17:28 +0000)]
libatomic: Enable lock-free 128-bit atomics on AArch64
Enable lock-free 128-bit atomics on AArch64. This is backwards compatible with
existing binaries (as for these GCC always calls into libatomic, so all 128-bit
atomic uses in a process are switched), gives better performance than locking
atomics and is what most users expect.
128-bit atomic loads use a load/store exclusive loop if LSE2 is not supported.
This results in an implicit store which is invisible to software as long as the
given address is writeable (which will be true when using atomics in real code).
This doesn't yet change __atomic_is_lock_free eventhough all atomics are finally
lock-free on AArch64.
libatomic:
* config/linux/aarch64/atomic_16.S: Implement lock-free ARMv8.0 atomics.
(libat_exchange_16): Merge RELEASE and ACQ_REL/SEQ_CST cases.
* config/linux/aarch64/host-config.h: Use atomic_16.S for baseline v8.0.
Wilco Dijkstra [Fri, 1 Dec 2023 15:05:53 +0000 (15:05 +0000)]
AArch64: Add inline memmove expansion
Add support for inline memmove expansions. The generated code is identical
as for memcpy, except that all loads are emitted before stores rather than
being interleaved. The maximum size is 256 bytes which requires at most 16
registers.
gcc/ChangeLog:
* config/aarch64/aarch64.opt (aarch64_mops_memmove_size_threshold):
Change default.
* config/aarch64/aarch64.md (cpymemdi): Add a parameter.
(movmemdi): Call aarch64_expand_cpymem.
* config/aarch64/aarch64.cc (aarch64_copy_one_block): Rename function,
simplify, support storing generated loads/stores.
(aarch64_expand_cpymem): Support expansion of memmove.
* config/aarch64/aarch64-protos.h (aarch64_expand_cpymem): Add bool arg.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/memmove.c: Add new test.
* gcc.target/aarch64/memmove2.c: Likewise.
It's obvious we have many index > 255 in shuffle indice. Here we use vmerge optimizaiton which is available but incorrect codgen cause run fail.
The bug codegen:
vsetvli zero,a4,e8,m8,ta,ma
vmsltu.vi v0,v0,0 -> it should be 256 instead of 0, but since it is EEW8 vector, 256 is not a available value that 8bit register can hold it.
vmerge.vvm v8,v8,v16,v0
After this patch:
vmv.v.x v0,a6
vmerge.vvm v8,v8,v16,v0
Jakub Jelinek [Fri, 15 Dec 2023 11:40:51 +0000 (12:40 +0100)]
bitint: Introduce abi_limb_mode
Given what I saw in the aarch64/arm psABIs for BITINT_TYPE, as I said
earlier I'm afraid we need to differentiate between the limb mode/precision
specified in the psABIs (what is used to decide how it is actually passed,
aligned or what size it has) vs. what limb mode/precision should be used
during bitint lowering and in the libgcc bitint APIs.
While in the x86_64 psABI a limb is 64-bit, which is perfect for both,
that is a wordsize which we can perform operations natively in,
e.g. aarch64 wants 128-bit limbs for alignment/sizing purposes, but
on the bitint lowering side I believe it would result in terribly bad code
and on the libgcc side wouldn't work at all (because it relies there on
longlong.h support).
So, the following patch makes it possible for aarch64 to use TImode
as abi_limb_mode for _BitInt(129) and larger, while using DImode as
limb_mode.
2023-12-15 Jakub Jelinek <jakub@redhat.com>
* target.h (struct bitint_info): Add abi_limb_mode member, adjust
comment.
* target.def (bitint_type_info): Mention abi_limb_mode instead of
limb_mode.
* varasm.cc (output_constant): Use abi_limb_mode rather than
limb_mode.
* stor-layout.cc (finish_bitfield_representative): Likewise. Assert
that if precision is smaller or equal to abi_limb_mode precision or
if info.big_endian is different from WORDS_BIG_ENDIAN, info.limb_mode
must be the same as info.abi_limb_mode.
(layout_type): Use abi_limb_mode rather than limb_mode.
* gimple-fold.cc (clear_padding_bitint_needs_padding_p): Likewise.
(clear_padding_type): Likewise.
* config/i386/i386.cc (ix86_bitint_type_info): Also set
info->abi_limb_mode.
* doc/tm.texi: Regenerated.
This patch adds support for non-constant component offsets in "map"
clauses for OpenMP (and the equivalants for OpenACC), which are not able
to be sorted into order at compile time. Normally struct accesses in
such clauses are gathered together and sorted into increasing address
order after a "GOMP_MAP_STRUCT" node: if we have variable indices,
that is no longer possible.
This version of the patch scales back the previously-posted version to
merely add a diagnostic for incorrect usage of component accesses with
variably-indexed arrays of structs: the only permitted variant is where
we have multiple indices that are the same, but we could not prove so
at compile time. Rather than silently producing the wrong result for
cases where the indices are in fact different, we error out (e.g.,
"map(dtarr(i)%arrptr, dtarr(j)%arrptr(4:8))", for different i/j).
For now, multiple *constant* array indices are still supported (see
map-arrayofstruct-1.c). That could perhaps be addressed with a follow-up
patch, if necessary.
This version of the patch renumbers the GOMP_MAP_STRUCT_UNORD kind to
avoid clashing with the OpenACC "non-contiguous" dynamic array support
(though that is not yet applied to mainline).
Alex Coplan [Fri, 15 Dec 2023 09:32:42 +0000 (09:32 +0000)]
aarch64: Handle autoinc addresses in ld1rq splitter [PR112906]
This patch uses the new force_reload_address routine added by the
previous patch to fix PR112906.
gcc/ChangeLog:
PR target/112906
* config/aarch64/aarch64-sve.md (@aarch64_vec_duplicate_vq<mode>_le):
Use force_reload_address to reload addresses that aren't suitable for
ld1rq in the pre-RA splitter.
gcc/testsuite/ChangeLog:
PR target/112906
* gcc.target/aarch64/sve/acle/general/pr112906.c: New test.
Alex Coplan [Fri, 15 Dec 2023 09:31:28 +0000 (09:31 +0000)]
emit-rtl, lra: Move lra's emit_inc to emit-rtl.cc
In PR112906 we ICE because we try to use force_reg to reload an
auto-increment address, but force_reg can't do this.
With the aim of fixing the PR by supporting reloading arbitrary
addresses in pre-RA splitters, this patch generalizes
lra-constraints.cc:emit_inc and makes it available to the rest of the
compiler by moving the generalized version to emit-rtl.cc.
We observe that the separate IN parameter to LRA's emit_inc is
redundant, since the function is static and is only (statically) called
once in lra-constraints.cc, with in == value. As such, we drop the IN
parameter and simplify the code accordingly.
We wrap the emit_inc code in a virtual class to allow LRA to override
how reload pseudos are created, thereby preserving the existing LRA
behaviour as much as possible.
We then add a second (higher-level) routine to emit-rtl.cc,
force_reload_address, which can reload arbitrary addresses. This uses
the generalized emit_inc code to handle the RTX_AUTOINC case. The
second patch in this series uses force_reload_address to fix PR112906.
Since we intend to call address_reload_context::emit_autoinc from within
splitters, and the code lifted from LRA calls recog, we have to avoid
clobbering recog_data. We do this by introducing a new RAII class for
saving/restoring recog_data on the stack.
gcc/ChangeLog:
PR target/112906
* emit-rtl.cc (address_reload_context::emit_autoinc): New.
(force_reload_address): New.
* emit-rtl.h (struct address_reload_context): Declare.
(force_reload_address): Declare.
* lra-constraints.cc (class lra_autoinc_reload_context): New.
(emit_inc): Drop IN parameter, invoke
code moved to emit-rtl.cc:address_reload_context::emit_autoinc.
(curr_insn_transform): Drop redundant IN parameter in call to
emit_inc.
* recog.h (class recog_data_saver): New.
[...]/source-gcc/gcc/testsuite/gcc.dg/pr110279-2.c:11:1: error: unknown type name '__attribute_noinline__'
[...]/source-gcc/gcc/testsuite/gcc.dg/pr110279-2.c:12:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'foo'
We cannot assume 'stdio.h' to define '__attribute_noinline__' -- but then, that
also isn't necessary for this test case (there is nothing to inline into).
Jakub Jelinek [Fri, 15 Dec 2023 09:13:44 +0000 (10:13 +0100)]
match.pd: Optimize sign-extension followed by truncation [PR113024]
While looking at a bitint ICE, I've noticed we don't optimize
in f1 and f5 functions below the 2 casts into just one at GIMPLE,
even when optimize it in convert_to_integer if it appears in the same
stmt. The large match.pd simplification of two conversions in a row
has many complex rules and as the testcase shows, everything else from
the narrowest -> widest -> prec_in_between all integer conversions
is already handled, either because the inside_unsignedp == inter_unsignedp
rule kicks in, or the
&& ((inter_unsignedp && inter_prec > inside_prec)
== (final_unsignedp && final_prec > inter_prec))
one, but there is no reason why sign extension to from narrowest to
widest type followed by truncation to something in between can't be
done just as sign extension from narrowest to the final type. After all,
if the widest type is signed rather than unsigned, regardless of the final
type signedness we already handle it that way.
And since PR93044 we also handle it if the final precision is not wider
than the inside precision.
2023-12-15 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113024
* match.pd (two conversions in a row): Simplify scalar integer
sign-extension followed by truncation.
Jakub Jelinek [Fri, 15 Dec 2023 09:10:58 +0000 (10:10 +0100)]
lower-bitint: Fix .{ADD,SUB,MUL}_OVERFLOW with _BitInt large/huge INTEGER_CST arguments [PR113003]
As shown in the testcase, .{ADD,SUB,MUL}_OVERFLOW calls are another
exception to the middle/large/huge _BitInt discovery through SSA_NAMEs
next to stores of INTEGER_CSTs to memory and their conversions to
floating point.
The calls can have normal COMPLEX_TYPE with INTEGER_TYPE elts return type
(or BITINT_TYPE with small precision) and one of the arguments can be
SSA_NAME with an INTEGER_TYPE or small BITINT_TYPE as well; still, when
there is an INTEGER_CST argument with large/huge BITINT_TYPE, we need to
lower it that way.
2023-12-15 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113003
* gimple-lower-bitint.cc (arith_overflow_arg_kind): New function.
(gimple_lower_bitint): Use it to catch .{ADD,SUB,MUL}_OVERFLOW
calls with large/huge INTEGER_CST arguments.
Hongyu Wang [Mon, 11 Dec 2023 01:15:02 +0000 (09:15 +0800)]
i386: Sync move_max/store_max with prefer-vector-width [PR112824]
Currently move_max follows the tuning feature first, but ideally it
should sync with prefer-vector-width when it is explicitly set to keep
vector move and operation with same vector size.
gcc/ChangeLog:
PR target/112824
* config/i386/i386-options.cc (ix86_option_override_internal):
Sync ix86_move_max/ix86_store_max with prefer_vector_width when
it is explicitly set.
gcc/testsuite/ChangeLog:
PR target/112824
* gcc.target/i386/pieces-memset-45.c: Remove
-mprefer-vector-width=256.
* g++.target/i386/pr112824-1.C: New test.
Haochen Jiang [Wed, 13 Dec 2023 03:23:28 +0000 (11:23 +0800)]
i386: Remove RAO-INT from Grand Ridge
gcc/ChangeLog:
* config/i386/driver-i386.cc (host_detect_local_cpu): Do not
set Grand Ridge depending on RAO-INT.
* config/i386/i386.h: Remove PTA_RAOINT from PTA_GRANDRIDGE.
* doc/invoke.texi: Adjust documentation.
Juzhe-Zhong [Thu, 14 Dec 2023 13:45:59 +0000 (21:45 +0800)]
Middle-end: Do not model address cost for SELECT_VL style vectorization
Follow Richard's suggestions, we should not model address cost in the loop
vectorizer for select_vl or decrement IV since other style vectorization doesn't
do that.
To make cost model comparison apple to apple.
This patch set COST from 2 to 1 which turns out have better codegen
in various codegen for RVV.
Ok for trunk ?
PR target/111153
gcc/ChangeLog:
* tree-vect-loop.cc (vect_estimate_min_profitable_iters):
Remove address cost for select_vl/decrement IV.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/costmodel/riscv/rvv/pr111153.c: Moved to...
* gcc.dg/vect/costmodel/riscv/rvv/pr11153-2.c: ...here.
* gcc.dg/vect/costmodel/riscv/rvv/pr111153-1.c: New test.
This adds the C++23 std::print functions, which use std::format to write
to a FILE stream or std::ostream (defaulting to stdout).
The new extern symbols are in the libstdc++exp.a archive, so we aren't
committing to stable symbols in the DSO yet. There's a UTF-8 validating
and transcoding function added by this change. That can certainly be
optimized, but it's internal to libstdc++exp.a so can be tweaked later
at leisure.
Currently the external symbols work for all targets, but are only
actually used for Windows, where it's necessary to transcode to UTF-16
to write to the console. The standard seems to encourage us to also
diagnose invalid UTF-8 for non-Windows targets when writing to a
terminal (and only when writing to a terminal), but I'm reliably
informed that that wasn't the intent of the wording. Checking for
invalid UTF-8 sequences only needs to happen for Windows, which is good
as checking for a terminal requires a call to isatty, and on Linux that
uses an ioctl syscall, which would make std::print ten times slower!
Testing the std::print behaviour is difficult if it depends on whether
the output stream is connected to a Windows console or not, as we can't
(as far as I know) do that non-interactively in DejaGNU. One of the new
tests uses the internal __write_to_terminal function directly. That
allows us to verify its UTF-8 error handling on POSIX targets, even
though that's not actually used by std::print. For Windows, that
__write_to_terminal function transcodes to UTF-16 but then uses
WriteConsoleW which fails unless it really is writing to the console.
That means the 27_io/print/2.cc test FAILs on Windows. The UTF-16
transcoding has been manually tested using mingw-w64 and Wine, and
appears to work.
libstdc++-v3/ChangeLog:
PR libstdc++/107760
* include/Makefile.am: Add new header.
* include/Makefile.in: Regenerate.
* include/bits/version.def (__cpp_lib_print): Define.
* include/bits/version.h: Regenerate.
* include/std/format (__literal_encoding_is_utf8): New function.
(_Seq_sink::view()): New member function.
* include/std/ostream (vprintf_nonunicode, vprintf_unicode)
(print, println): New functions.
* include/std/print: New file.
* src/c++23/Makefile.am: Add new source file.
* src/c++23/Makefile.in: Regenerate.
* src/c++23/print.cc: New file.
* testsuite/27_io/basic_ostream/print/1.cc: New test.
* testsuite/27_io/print/1.cc: New test.
* testsuite/27_io/print/2.cc: New test.
Jonathan Wakely [Thu, 14 Dec 2023 12:57:53 +0000 (12:57 +0000)]
libstdc++: Tweaks for std::format fast path
Fix an incorrect call to _Sink::_M_reserve() which should have passed
the __n parameter. This was not actually a problem because it was in an
discarded statement, because only the _Seq_sink<basic_string<C>>
specialization was used.
Also add some branch prediction hints, explanatory comments, and debug
mode assertions to _Seq_sink.
libstdc++-v3/ChangeLog:
* include/std/format (_Seq_sink): Fix missing argument in
discarded statement. Add comments, likely/unlikely attributes
and debug assertions as sanity checks.
Jonathan Wakely [Mon, 11 Dec 2023 22:58:46 +0000 (22:58 +0000)]
libstdc++: Add dg-output to two tests
These tests are expected to run interactively, with the output checked
by eye. Nobody ever does that, but we can at least use dg-output to
check that the output is as expected.
libstdc++-v3/ChangeLog:
* testsuite/27_io/objects/char/2.cc: Use dg-output.
* testsuite/27_io/objects/wchar_t/2.cc: Use dg-output.
Jonathan Wakely [Thu, 14 Dec 2023 15:26:42 +0000 (15:26 +0000)]
libstdc++: Fix %S format of duration with floating-point rep
I got the order of arguments to std::format_to wrong. It was in a
discarded statement, for a case which wasn't being tested.
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h (__formatter_chrono::_M_S): Fix order
of arguments to std::format_to.
* testsuite/20_util/duration/io.cc: Test subsecond duration with
floating-point rep.
Marek Polacek [Thu, 14 Dec 2023 17:01:21 +0000 (12:01 -0500)]
c++: fix parsing with auto(x) at block scope [PR112482]
This is sort of like r14-5514, but at block scope. Consider
struct A { A(int, int); };
void
g (int a)
{
A bar(auto(a), 42); // not a fn decl
}
where we emit error: 'auto' parameter not permitted in this context
which is bogus -- bar doesn't declare a function, so the auto is OK,
but we don't know it till we've seen the second argument. The error
comes from grokdeclarator invoked just after we've parsed the auto(a).
A possible approach seems to be to delay the auto parameter checking
and only check once we know we are indeed dealing with a function
declaration. For tparms, we should still emit the error right away.
PR c++/112482
gcc/cp/ChangeLog:
* decl.cc (grokdeclarator): Do not issue the auto parameter error while
tentatively parsing a function parameter.
* parser.cc (cp_parser_parameter_declaration_clause): Check it here.
Andrew Pinski [Wed, 13 Dec 2023 05:55:50 +0000 (21:55 -0800)]
middle-end: Fix up constant handling in emit_conditional_move [PR111260]
After r14-2667-gceae1400cf24f329393e96dd9720, we force a constant to a register
if it is shared with one of the other operands. The problem is used the comparison
mode for the register but that could be different from the operand mode. This
causes some issues on some targets.
To fix it, we need to make sure the mode of the comparison matches the mode
of the other operands, before we can compare the constants (CONST_INT has no
modes so compare_rtx returns true if they have the same value even if the usage
is in a different mode).
Bootstrapped and tested on both aarch64-linux-gnu and x86_64-linux.
PR middle-end/111260
gcc/ChangeLog:
* optabs.cc (emit_conditional_move): Change the modes to be
equal before forcing the constant to a register.
gcc/testsuite/ChangeLog:
* gcc.c-torture/compile/condmove-1.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Marek Polacek [Tue, 5 Dec 2023 20:23:52 +0000 (15:23 -0500)]
c++: fix ICE with sizeof in a template [PR112869]
This test shows that we cannot clear *walk_subtrees in
cp_fold_immediate_r when we're in_immediate_context, because that
checks even e.g. sk_template_parms, and, as the comment says, affects
cp_fold_r as well. Here we had an expression with
Di Zhao [Thu, 14 Dec 2023 19:22:32 +0000 (03:22 +0800)]
Consider fully pipelined FMA in get_reassociation_width
Add a new parameter param_fully_pipelined_fma. If it is non-zero,
reassociation considers the benefit of parallelizing FMA's
multiplication part and addition part, assuming FMUL and FMA use the
same units that can also do FADD.
With the patch and new option, there's ~2% improvement in spec2017
508.namd on AmpereOne. (The other options are "-Ofast -mcpu=ampere1
-flto".)
PR tree-optimization/110279
gcc/ChangeLog:
* doc/invoke.texi: New parameter fully-pipelined-fma.
* params.opt: New parameter fully-pipelined-fma.
* tree-ssa-reassoc.cc (get_mult_latency_consider_fma): Return
the latency of MULT_EXPRs that can't be hidden by the FMAs.
(get_reassociation_width): Search for a smaller width
considering the benefit of fully pipelined FMA.
(rank_ops_for_fma): Return the number of MULT_EXPRs.
(reassociate_bb): Pass the number of MULT_EXPRs to
get_reassociation_width; avoid calling
get_reassociation_width twice.
Jerry DeLisle [Thu, 14 Dec 2023 03:04:50 +0000 (19:04 -0800)]
fortran: Add degree based trig functions for F2023
PR fortran/112873
gcc/fortran/ChangeLog:
* gfortran.texi: Update to reflect the changes.
* intrinsic.cc (add_functions): Update the standard that the
various degree trigonometric functions have been described in.
(gfc_check_intrinsic_standard): Add an error string for F2023.
* intrinsic.texi: Update accordingly.
Robin Dapp [Wed, 13 Dec 2023 15:42:28 +0000 (16:42 +0100)]
expmed: Compare unit_precision for better mode.
In extract_bit_field_1 we try to get a better vector mode before
extracting from it. Better refers to the case when the requested target
mode does not equal the inner mode of the vector to extract from and we
have an equivalent tieable vector mode with a fitting inner mode.
On riscv this triggered an ICE (PR112999) because we would take the
detour of extracting from a mask-mode vector via a vector integer mode.
One element of that mode could be subreg-punned with TImode which, in
turn, would need to be operated on in DImode chunks.
Robin Dapp [Sun, 3 Dec 2023 20:55:16 +0000 (21:55 +0100)]
expmed: Use GET_MODE_PRECISION and expander's output mode.
This changes the vec_extract path of extract_bit_field to use
GET_MODE_PRECISION instead of GET_MODE_BITSIZE and uses
the mode obtained from insn_data[icode].operand[0] as target mode.
Also, it adds a vec_extract<mode>bi expander for riscv that maps
to vec_extract<mode>qi. This fixes an ICE on riscv where we did
not find a vec_extract optab and continued with the generic code
which requires 1-byte alignment that riscv mask modes do not provide.
Apart from that it adds poly_int support to riscv's vec_extract
expander and makes the RVV..BImode -> QImode expander call
emit_vec_extract in order not to duplicate code.
gcc/ChangeLog:
PR target/112773
* config/riscv/autovec.md (vec_extract<mode>bi): New expander
calling vec_extract<mode>qi.
* config/riscv/riscv-protos.h (riscv_legitimize_poly_move):
Export.
(emit_vec_extract): Change argument from poly_int64 to rtx.
* config/riscv/riscv-v.cc (shuffle_extract_and_slide1up_patterns):
Ditto.
* config/riscv/riscv.cc (riscv_legitimize_poly_move): Export.
(riscv_legitimize_move): Use rtx instead of poly_int64.
* expmed.cc (store_bit_field_1): Change BITSIZE to PRECISION.
(extract_bit_field_1): Change BITSIZE to PRECISION and use
return mode from insn_data as target mode.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/partial/pr112773.c: New test.
As it stands, GCC doesn't document any public AArch64-specific operand
modifiers for use in inline asm. This patch fixes that by documenting
an initial set of public AArch64-specific operand modifiers.
Jonathan Wakely [Wed, 6 Dec 2023 13:39:52 +0000 (13:39 +0000)]
libstdc++: Make __gnu_debug::vector usable in constant expressions [PR109536]
This makes constexpr std::vector (mostly) work in Debug Mode. All safe
iterator instrumentation and checking is disabled during constant
evaluation, because it requires mutex locks and calls to non-inline
functions defined in libstdc++.so. It should be OK to disable the safety
checks, because most UB should be detected during constant evaluation
anyway.
We could try to enable the full checking in constexpr, but it would mean
wrapping all the non-inline functions like _M_attach with an inline
_M_constexpr_attach that does the iterator housekeeping inline without
mutex locks when called for constant evaluation, and calls the
non-inline function at runtime. That could be done in future if we find
that we've lost safety or useful checking by disabling the safe
iterators.
There are a few test failures in C++20 mode, which I'm unable to
explain. The _Safe_iterator::operator++() member gives errors for using
non-constexpr functions during constant evaluation, even though those
functions are guarded by std::is_constant_evaluated() checks. The same
code works fine for C++23 and up.
Richard Biener [Thu, 14 Dec 2023 15:00:50 +0000 (16:00 +0100)]
tree-optimization/113018 - ICE with BB reduction vectorization
When BB reduction vectorization picks up a chain with an ASM def
in it and that's inside the vectorized region we fail to get its
LHS. Instead of trying to get the correct def the following
avoids vectorizing such def and instead keeps it as def to add
in the epilog.
PR tree-optimization/113018
* tree-vect-slp.cc (vect_slp_check_for_roots): Only start
SLP discovery from stmts with a LHS.
Patrick Palka [Thu, 14 Dec 2023 15:18:48 +0000 (10:18 -0500)]
c++: Implement P2582R1, CTAD from inherited constructors
This patch implements C++23 class template argument deduction from
inherited constructors, the mechanism for which relies on alias
CTAD which we already fully support. The process for transforming
the return type of an inherited guide is specified in terms of a
partially specialized class template, but this patch implements it in
a simpler way, effectively performing ahead of time deduction instead
of instantiation time deduction. I wasn't able to find an example for
which this implementation strategy makes a difference, but I didn't
look very hard. Support seems good enough to advertise as complete
but there doesn't seem to be a feature-test macro update for this
feature yet. There should be no functional change before C++23 mode.
There's a couple of FIXMEs, one in inherited_ctad_tweaks for recognizing
more forms of inherited constructors, and one in deduction_guides_for for
making the cache aware of base-class dependencies.
gcc/cp/ChangeLog:
* cp-tree.h (type_targs_deducible_from): Adjust return type.
* pt.cc (alias_ctad_tweaks): Also handle C++23 inherited CTAD.
(inherited_ctad_tweaks): Define.
(type_targs_deducible_from): Return the deduced arguments or
NULL_TREE instead of a bool. Handle 'tmpl' being a TREE_LIST
representing a synthetic alias template.
(ctor_deduction_guides_for): Do inherited_ctad_tweaks for each
USING_DECL in C++23 mode.
(deduction_guides_for): Add FIXME for stale cache entries in
light of inherited CTAD.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/class-deduction67.C: Accept in C++23 mode.
* g++.dg/cpp23/class-deduction-inherited1.C: New test.
* g++.dg/cpp23/class-deduction-inherited2.C: New test.
* g++.dg/cpp23/class-deduction-inherited3.C: New test.
* g++.dg/cpp23/class-deduction-inherited4.C: New test.
Richard Biener [Wed, 13 Dec 2023 13:23:31 +0000 (14:23 +0100)]
tree-optimization/112793 - SLP of constant/external code-generated twice
The following makes the attempt at code-generating a constant/external
SLP node twice well-formed as that can happen when partitioning BB
vectorization attempts where we keep constants/externals unpartitioned.
PR tree-optimization/112793
* tree-vect-slp.cc (vect_schedule_slp_node): Already
code-generated constant/external nodes are OK.
David Malcolm [Thu, 14 Dec 2023 14:10:10 +0000 (09:10 -0500)]
analyzer: cleanups [PR112655]
Avoid copying eedges in infinite_loop::infinite_loop.
Use initializer lists in the various places reported in
PR analyzer/112655 (apart from coord_test's ctor, which
would require nontrivial refactoring).
gcc/analyzer/ChangeLog:
PR analyzer/112655
* infinite-loop.cc (infinite_loop::infinite_loop): Pass eedges
via rvalue reference rather than by value.
(starts_infinite_loop_p): Move eedges when constructing an
infinite_loop instance.
* sm-file.cc (fileptr_state_machine::fileptr_state_machine): Use
initializer list for states.
* sm-sensitive.cc
(sensitive_state_machine::sensitive_state_machine): Likewise.
* sm-signal.cc (signal_state_machine::signal_state_machine):
Likewise.
* sm-taint.cc (taint_state_machine::taint_state_machine):
Likewise.
* varargs.cc (va_list_state_machine::va_list_state_machine): Likewise.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
aarch64: Improve handling of accumulators in early-ra
Being very simplistic, early-ra just models an allocno's live range
as a single interval. This doesn't work well for single-register
accumulators that are updated multiple times in a loop, since in
SSA form, each intermediate result will be a separate SSA name and
will remain separate from the accumulator even after out-of-ssa.
This means that in something like:
for (;;)
{
x = x + ...;
x = x + ...;
}
the first definition of x and the second use will be a separate pseudo
from the "main" loop-carried pseudo.
A real RA would fix this by keeping general, segmented live ranges.
But that feels like a slippery slope in this context.
This patch instead looks for sharability at a more local level,
as described in the comments. It's a bit hackish, but hopefully
not too much.
The patch also contains some small tweaks that are needed to make
the new and existing tests pass:
- fix a case where a pseudo that was only moved was wrongly treated
as not an FPR candidate
- fix some bookkeeping related to is_strong_copy_src
- use the number of FPR preferences as a tiebreaker when sorting colors
I fully expect that we'll need to be more aggressive at skipping the
early-ra allocation. For example, it probably makes sense to refuse any
allocation that involves an FPR move. But I'd like to keep collecting
examples of where things go wrong first, so that hopefully we can improve
the cases with strided registers or structures.
gcc/
* config/aarch64/aarch64-early-ra.cc (allocno_info::is_equiv): New
member variable.
(allocno_info::equiv_allocno): Replace with...
(allocno_info::related_allocno): ...this member variable.
(allocno_info::chain_prev): Put into an enum with...
(allocno_info::last_use_point): ...this new member variable.
(color_info::num_fpr_preferences): New member variable.
(early_ra::m_shared_allocnos): Likewise.
(allocno_info::is_shared): New member function.
(allocno_info::is_equiv_to): Likewise.
(early_ra::dump_allocnos): Dump sharing information. Tweak column
widths.
(early_ra::fpr_preference): Check ALLOWS_NONFPR before returning -2.
(early_ra::start_new_region): Handle m_shared_allocnos.
(early_ra::create_allocno_group): Set related_allocno rather than
equiv_allocno.
(early_ra::record_allocno_use): Likewise. Detect multiple calls
for the same program point. Update last_use_point and is_equiv.
Clear is_strong_copy_src rather than is_strong_copy_dest.
(early_ra::record_allocno_def): Use related_allocno rather than
equiv_allocno. Update last_use_point.
(early_ra::valid_equivalence_p): Replace with...
(early_ra::find_related_start): ...this new function.
(early_ra::record_copy): Look for cases where a destination copy chain
can be shared with the source allocno.
(early_ra::find_strided_accesses): Update for equiv_allocno->
related_allocno change. Only call consider_strong_copy_src_chain
at the head of a copy chain.
(early_ra::is_chain_candidate): Skip shared allocnos. Update for
new representation of equivalent allocnos.
(early_ra::chain_allocnos): Update for new representation of
equivalent allocnos.
(early_ra::try_to_chain_allocnos): Likewise.
(early_ra::merge_fpr_info): New function, split out from...
(early_ra::set_single_color_rep): ...here.
(early_ra::form_chains): Handle shared allocnos.
(early_ra::process_copies): Count the number of FPR preferences.
(early_ra::cmp_decreasing_size): Rename to...
(early_ra::cmp_allocation_order): ...this. Sort equal-sized groups
by the number of FPR preferences.
(early_ra::finalize_allocation): Handle shared allocnos.
(early_ra::process_region): Reset chain_prev as well as chain_next.
gcc/testsuite/
* gcc.target/aarch64/sve/accumulators_1.c: New test.
* gcc.target/aarch64/sve/acle/asm/create2_1.c: Allow the moves to
be in any order.
* gcc.target/aarch64/sve/acle/asm/create3_1.c: Likewise.
* gcc.target/aarch64/sve/acle/asm/create4_1.c: Likewise.
Alexandre Oliva [Thu, 14 Dec 2023 13:41:13 +0000 (10:41 -0300)]
strub: handle volatile promoted args in internal strub [PR112938]
When generating code for an internal strub wrapper, don't clear the
DECL_NOT_GIMPLE_REG_P flag of volatile args, and gimplify them both
before and after any conversion.
While at that, move variable TMP into narrower scopes so that it's
more trivial to track where ARG lives.
Jeff Law [Thu, 14 Dec 2023 13:31:49 +0000 (06:31 -0700)]
[committed] Fix m68k testcase for c99
More fallout from the c99 conversion. The m68k specific test pr63347.c calls
exit and abort without a prototype in scope. This patch turns them into
__builtin calls avoiding the error.
Bootstrapped and regression tested on m68k-linux-gnu, pushed to the trunk.
gcc/testsuite
* gcc.target/m68k/pr63347.c: Call __builtin_abort and __builtin_exit
instead of abort and exit.
Thomas Schwinge [Thu, 14 Dec 2023 13:12:45 +0000 (14:12 +0100)]
In 'gcc/gimple-ssa-sccopy.cc', '#define INCLUDE_ALGORITHM' instead of '#include <algorithm>'
... to avoid issues such as:
In file included from [...]/lib/gcc/i686-pc-linux-gnu/5.2.0/include/xmmintrin.h:34:0,
from [...]/lib/gcc/i686-pc-linux-gnu/5.2.0/include/x86intrin.h:31,
from [...]/i686-pc-linux-gnu/include/c++/5.2.0/i686-pc-linux-gnu/64/bits/opt_random.h:33,
from [...]/i686-pc-linux-gnu/include/c++/5.2.0/random:50,
from [...]/i686-pc-linux-gnu/include/c++/5.2.0/bits/stl_algo.h:66,
from [...]/i686-pc-linux-gnu/include/c++/5.2.0/algorithm:62,
from [...]/source-gcc/gcc/gimple-ssa-sccopy.cc:32:
[...]/lib/gcc/i686-pc-linux-gnu/5.2.0/include/mm_malloc.h:42:12: error: attempt to use poisoned "malloc"
return malloc (size);
^
make[2]: *** [Makefile:1197: gimple-ssa-sccopy.o] Error 1
Jakub Jelinek [Thu, 14 Dec 2023 11:06:59 +0000 (12:06 +0100)]
match.pd: Simplify (t * u) / (t * v) [PR112994]
On top of the previously posted patch, this simplifies say (x * 16) / (x * 4)
into 4. Unlike the previous pattern, this is something we didn't fold
previously on GENERIC, so I think it shouldn't be all wrapped with #if
GIMPLE. The question whether there should be fold_overflow_warning for the
TYPE_OVERFLOW_UNDEFINED case remains.
2023-12-14 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/112994
* match.pd ((t * u) / (t * v) -> (u / v)): New simplification.
Jakub Jelinek [Thu, 14 Dec 2023 10:55:49 +0000 (11:55 +0100)]
match.pd: Simplify (t * u) / v -> t * (u / v) [PR112994]
The following testcase is optimized just on GENERIC (using
strict_overflow_p = false;
if (TREE_CODE (arg1) == INTEGER_CST
&& (tem = extract_muldiv (op0, arg1, code, NULL_TREE,
&strict_overflow_p)) != 0)
{
if (strict_overflow_p)
fold_overflow_warning (("assuming signed overflow does not occur "
"when simplifying division"),
WARN_STRICT_OVERFLOW_MISC);
return fold_convert_loc (loc, type, tem);
}
) but not on GIMPLE.
An earlier version of the patch regressed
+FAIL: gcc.dg/Wstrict-overflow-3.c correct warning (test for warnings, line 12)
test, we are indeed assuming that signed overflow does not occur
when simplifying division in there.
This version of the patch (which provides the simplification only
for GIMPLE) fixes that.
And/or we could add the
fold_overflow_warning (("assuming signed overflow does not occur "
"when simplifying division"),
WARN_STRICT_OVERFLOW_MISC);
call into the simplification, but in that case IMHO it should go into
the (t * u) / u -> t simplification as well, there we assume the exact
same thing (of course, in both cases only in the spots where we don't
verify it through ranger that it never overflows).
Guarding the whole simplification to GIMPLE only IMHO makes sense because
the above mentioned folding does it for GENERIC (and extract_muldiv even
handles far more cases, dunno how many from that we should be doing on
GIMPLE in match.pd and what could be done elsewhere; e.g. extract_muldiv
can handle (x * 16 + y * 32) / 8 -> x * 2 + y * 4 etc.).
Dunno about the fold_overflow_warning, I always have doubts about why
such a warning is useful to users.
2023-12-14 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/112994
* match.pd ((t * 2) / 2 -> t): Adjust comment to use u instead of 2.
Punt without range checks if TYPE_OVERFLOW_SANITIZED.
((t * u) / v -> t * (u / v)): New simplification.
Filip Kastl [Thu, 14 Dec 2023 10:29:31 +0000 (11:29 +0100)]
A new copy propagation and PHI elimination pass
This patch adds the strongly-connected copy propagation (SCCOPY) pass.
It is a lightweight GIMPLE copy propagation pass that also removes some
redundant PHI statements. It handles degenerate PHIs, e.g.:
_5 = PHI <_1>;
_6 = PHI <_6, _6, _1, _1>;
_7 = PHI <16, _7>;
// Replaces occurences of _5 and _6 by _1 and _7 by 16
It also handles more complicated situations, e.g.:
_8 = PHI <_9, _10>;
_9 = PHI <_8, _10>;
_10 = PHI <_8, _9, _1>;
// Replaces occurences of _8, _9 and _10 by _1
gcc/ChangeLog:
* Makefile.in: Added sccopy pass.
* passes.def: Added sccopy pass before LTO streaming and before
RTL expansion.
* tree-pass.h (make_pass_sccopy): Added sccopy pass.
* gimple-ssa-sccopy.cc: New file.
Martin Jambor [Thu, 14 Dec 2023 10:09:06 +0000 (11:09 +0100)]
SRA: Relax requirements to use build_reconstructed_reference (PR 111807)
This patch half-reverts 3aaf704bca3e and replaces it with a fix with
relaxed requiremets for invoking build_reconstructed_reference in
build_ref_for_model.
build_ref_for_model/build_ref_for_offset is used in two slightly
different contexts. The first is when we are looking at an assignmernt
like
p->field_A.field_B = s.field_B;
and we have a replacements for e.g. s.field_B.field_C.field_D and we
want to store them directly to p->field_A.field_B.field_C.field_D (as
opposed to going through s or using a MEM_REF based in
p->field_A.field_B). In this case, the offset of the
"model" (s.field_B.field_C.field_D) within this can be different than
offset within the LHS that we want to reach (field_C.field_D within
the "base" p->field_A.field_B). Patch 3aaf704bca3e has caused us to
unnecessarily create MEM_REFs for these situations. These uses of
build_ref_for_model work with the relaxed condition just fine.
The second, problematic, context is when somewhere in the function we
have an assignment
s.field_A = t.field_A.field_B;
and we are creating an access structure to represent s.field_A.field_B
even if it is not actually accessed in the original input. This is
done after scanning the entire function body and we need to construct
a "universal" reference to s.field_A.field_B. In this case the "base"
is "s" and it has to be the DECL itself and not some reference for it
because for arbitrary references we need a GSI pointing to a statement
which we don't have, the reference is supposed to be universal.
But then using build_ref_for_model and within it
build_reconstructed_reference misbihaves if the expression contains
any ARRAY_REFs. In the first case those are fine because as we
eventually reach the aggregate type that matches a real LHS or RHS, we
know we we can just bolt the rest of the references onto it and end up
with the correct overall reference. However when dealing with
s.array[1].field_A = s.array[2].field_B;
we cannot just bolt array[2] reference when we want array[1] but that
is exactly what happens when we use build_reconstructed_reference and
keep it walking all the way to s.
I was consiering making all users of the second kind use directly
build_ref_for_offset instead of build_ref_for_model but the latter
also handles COMPONENT_REFs to bit-fields which the former does not.
THerefore I have deided to use the NULL-ness of GSI as an indicator
how strict we need to be. I have changed the function comment to
reflect that.
I have been able to observe diambiguation improvements with this patch
over currenct master, we do successfuly manage a few more
aliasing_component_refs_p disambiguations when compiling cc1, going
from:
Alias oracle query stats:
refs_may_alias_p: 94354287 disambiguations, 106279231 queries
ref_maybe_used_by_call_p: 1572511 disambiguations, 95618222 queries
call_may_clobber_ref_p: 649273 disambiguations, 659371 queries
stmt_kills_ref_p: 142342 kills, 8407309 queries
nonoverlapping_component_refs_p: 19 disambiguations, 10227 queries
nonoverlapping_refs_since_match_p: 15665 disambiguations, 52585 must overlaps, 68893 queries
aliasing_component_refs_p: 67090 disambiguations, 3081766 queries
TBAA oracle: 22675296 disambiguations 61781978 queries 14045969 are in alias set 0 10997085 queries asked about the same object
153 queries asked about the same alias set
0 access volatile 12485774 are dependent in the DAG 1577701 are aritificially in conflict with void *
Alias oracle query stats:
refs_may_alias_p: 94354083 disambiguations, 106278948 queries
ref_maybe_used_by_call_p: 1572511 disambiguations, 95618018 queries
call_may_clobber_ref_p: 649273 disambiguations, 659371 queries
stmt_kills_ref_p: 142342 kills, 8407310 queries
nonoverlapping_component_refs_p: 19 disambiguations, 10227 queries
nonoverlapping_refs_since_match_p: 15665 disambiguations, 52585 must overlaps, 68893 queries
aliasing_component_refs_p: 67104 disambiguations, 3081781 queries
TBAA oracle: 22676608 disambiguations 61782455 queries 14044948 are in alias set 0 10998619 queries asked about the same object
153 queries asked about the same alias set
0 access volatile 12484882 are dependent in the DAG 1577245 are aritificially in conflict with void *
PR tree-optimization/111807
* tree-sra.cc (build_ref_for_model): Allow offset smaller than
model->offset when gsi is non-NULL. Adjust function comment.
liuhongt [Wed, 13 Dec 2023 03:20:46 +0000 (11:20 +0800)]
Force broadcast constant to mem for vec_dup{v4di,v8si,v4df,v8df} when TARGET_AVX2 is not available.
vpbroadcastd/vpbroadcastq is avaiable under TARGET_AVX2, but
vec_dup{v4di,v8si} pattern is avaiable under AVX with memory operand.
And it will cause LRA/Reload to generate spill and reload if we put
constant in register.
gcc/ChangeLog:
PR target/112992
* config/i386/i386-expand.cc
(ix86_convert_const_wide_int_to_broadcast): Don't convert to
broadcast for vec_dup{v4di,v8si} when TARGET_AVX2 is not
available.
(ix86_broadcast_from_constant): Allow broadcast for V4DI/V8SI
when !TARGET_AVX2 since it will be forced to memory later.
(ix86_expand_vector_move): Force constant to mem for
vec_dup{vssi,v4di} when TARGET_AVX2 is not available.
Jakub Jelinek [Thu, 14 Dec 2023 07:01:04 +0000 (08:01 +0100)]
testsuite: Fix up pr112904.C test [PR112904]
On Fri, Dec 08, 2023 at 03:12:00PM +0800, liuhongt wrote:
> * g++.target/i386/pr112904.C: New test.
The new test FAILs on i686-linux and even on x86_64-linux I think
it doesn't actually test what was reported, unless one performs testing
with -march= for some XOP enabled CPU or -mxop.
The following patch fixes that, tested on x86_64-linux with
make check-g++ RUNTESTFLAGS='--target_board=unix\{-m32,-m32/-mno-sse/-mno-mmx,-m64\} i386.exp=pr112904.C'
2023-12-14 Jakub Jelinek <jakub@redhat.com>
PR target/112904
* g++.target/i386/pr112904.C: Add dg-do compile, dg-options -mxop
and for ia32 also dg-additional-options -mmmx.
Jakub Jelinek [Thu, 14 Dec 2023 06:57:34 +0000 (07:57 +0100)]
c++: Fix tinst_level::to_list [PR112968]
With valgrind checking, there are various errors reported on some C++26
libstdc++ tests, like:
==2009913== Conditional jump or move depends on uninitialised value(s)
==2009913== at 0x914C59: gt_ggc_mx_lang_tree_node(void*) (gt-cp-tree.h:107)
==2009913== by 0x8AB7A5: gt_ggc_mx_tinst_level(void*) (gt-cp-pt.h:32)
==2009913== by 0xB89B25: ggc_mark_root_tab(ggc_root_tab const*) (ggc-common.cc:75)
==2009913== by 0xB89DF4: ggc_mark_roots() (ggc-common.cc:104)
==2009913== by 0x9D6311: ggc_collect(ggc_collect) (ggc-page.cc:2227)
==2009913== by 0xDB70F6: execute_one_pass(opt_pass*) (passes.cc:2738)
==2009913== by 0xDB721F: execute_pass_list_1(opt_pass*) (passes.cc:2755)
==2009913== by 0xDB7258: execute_pass_list(function*, opt_pass*) (passes.cc:2766)
==2009913== by 0xA55525: cgraph_node::analyze() (cgraphunit.cc:695)
==2009913== by 0xA57CC7: analyze_functions(bool) (cgraphunit.cc:1248)
==2009913== by 0xA5890D: symbol_table::finalize_compilation_unit() (cgraphunit.cc:2555)
==2009913== by 0xEB02A1: compile_file() (toplev.cc:473)
I think the problem is in the tinst_level::to_list optimization from 2018.
That function returns a TREE_LIST with TREE_PURPOSE/TREE_VALUE filled in.
Either it freshly allocates using build_tree_list (NULL, NULL); + stores
TREE_PURPOSE/TREE_VALUE, that case is fine (the whole tree_list object
is zeros, except for TREE_CODE set to TREE_LIST and TREE_PURPOSE/TREE_VALUE
modified later; the above also means in particular TREE_TYPE of it is NULL
and TREE_CHAIN is NULL and both are accessible/initialized even in valgrind
annotations.
Or it grabs a TREE_LIST node from a freelist.
If defined(ENABLE_GC_CHECKING), the object is still all zeros except
for TREE_CODE/TREE_PURPOSE/TREE_VALUE like in the fresh allocation case
(but unlike the build_tree_list case in the valgrind annotations
TREE_TYPE and TREE_CHAIN are marked as uninitialized).
If !defined(ENABLE_GC_CHECKING), I believe the actual memory content
is that everything but TREE_CODE/TREE_PURPOSE/TREE_VALUE/TREE_CHAIN is
zeros and TREE_CHAIN is something random (whatever next entry is in the
freelist, nothing overwrote it) and from valgrind POV again,
TREE_TYPE and TREE_CHAIN are marked as uninitialized.
When using the other freelist instantiations (pending_template and
tinst_level) I believe everything is correct, from valgrind POV it marks
the whole pending_template or tinst_level as uninitialized, but the
caller initializes it all).
One way to fix this would be let tinst_level::to_list not store just
TREE_PURPOSE (ret) = tldcl;
TREE_VALUE (ret) = targs;
but also
TREE_TYPE (ret) = NULL_TREE;
TREE_CHAIN (ret) = NULL_TREE;
Though, that seems like wasted effort in the build_tree_list case to me.
So, the following patch instead does that TREE_CHAIN = NULL_TREE store only
in the case where it isn't already done (and likewise for TREE_TYPE just to
be sure) and marks both TREE_CHAIN and TREE_TYPE as initialized (the latter
is at that spot, the former is because we never really touch TREE_TYPE of a
TREE_LIST anywhere and so the NULL gets stored into the freelist and
restored from there (except for ENABLE_GC_CHECKING where it is poisoned
and then cleared again).
2023-12-14 Jakub Jelinek <jakub@redhat.com>
PR c++/112968
* pt.cc (freelist<tree_node>::reinit): Make whole obj->common
defined for valgrind annotations rather than just obj->base,
and do it even for ENABLE_GC_CHECKING. If not ENABLE_GC_CHECKING,
clear TREE_CHAIN (obj) and TREE_TYPE (obj).
Marek Polacek [Wed, 13 Dec 2023 23:25:47 +0000 (18:25 -0500)]
c++: fix cpp0x/constexpr-ex1.C in C++23
Since r14-6505 I see:
FAIL: g++.dg/cpp0x/constexpr-ex1.C -std=c++23 at line 91 (test for errors, line 89)
FAIL: g++.dg/cpp0x/constexpr-ex1.C -std=c++23 (test for excess errors)
FAIL: g++.dg/cpp0x/constexpr-ex1.C -std=c++26 at line 91 (test for errors, line 89)
FAIL: g++.dg/cpp0x/constexpr-ex1.C -std=c++26 (test for excess errors)
and it wasn't fixed by r14-6511. So I'm fixing it with the below.
Richard Ball [Wed, 13 Dec 2023 21:34:57 +0000 (21:34 +0000)]
aarch64: SVE/NEON Bridging intrinsics
ACLE has added intrinsics to bridge between SVE and Neon.
The NEON_SVE Bridge adds intrinsics that allow conversions between NEON and
SVE vectors.
This patch adds support to GCC for the following 3 intrinsics:
svset_neonq, svget_neonq and svdup_neonq
gcc/ChangeLog:
* config.gcc: Adds new header to config.
* config/aarch64/aarch64-builtins.cc (enum aarch64_type_qualifiers):
Moved to header file.
(ENTRY): Likewise.
(enum aarch64_simd_type): Likewise.
(struct aarch64_simd_type_info): Remove static.
(GTY): Likewise.
* config/aarch64/aarch64-c.cc (aarch64_pragma_aarch64):
Defines pragma for arm_neon_sve_bridge.h.
* config/aarch64/aarch64-protos.h:
Add handle_arm_neon_sve_bridge_h
* config/aarch64/aarch64-sve-builtins-base.h: New intrinsics.
* config/aarch64/aarch64-sve-builtins-base.cc
(class svget_neonq_impl): New intrinsic implementation.
(class svset_neonq_impl): Likewise.
(class svdup_neonq_impl): Likewise.
(NEON_SVE_BRIDGE_FUNCTION): New intrinsics.
* config/aarch64/aarch64-sve-builtins-functions.h
(NEON_SVE_BRIDGE_FUNCTION): Defines macro for NEON_SVE_BRIDGE
functions.
* config/aarch64/aarch64-sve-builtins-shapes.h: New shapes.
* config/aarch64/aarch64-sve-builtins-shapes.cc
(parse_element_type): Add NEON element types.
(parse_type): Likewise.
(struct get_neonq_def): Defines function shape for get_neonq.
(struct set_neonq_def): Defines function shape for set_neonq.
(struct dup_neonq_def): Defines function shape for dup_neonq.
* config/aarch64/aarch64-sve-builtins.cc
(DEF_SVE_TYPE_SUFFIX): Changed to be called through
SVE_NEON macro.
(DEF_SVE_NEON_TYPE_SUFFIX): Defines
macro for NEON_SVE_BRIDGE type suffixes.
(DEF_NEON_SVE_FUNCTION): Defines
macro for NEON_SVE_BRIDGE functions.
(function_resolver::infer_neon128_vector_type): Infers type suffix
for overloaded functions.
(handle_arm_neon_sve_bridge_h): Handles #pragma arm_neon_sve_bridge.h.
* config/aarch64/aarch64-sve-builtins.def
(DEF_SVE_NEON_TYPE_SUFFIX): Macro for handling neon_sve type suffixes.
(bf16): Replace entry with neon-sve entry.
(f16): Likewise.
(f32): Likewise.
(f64): Likewise.
(s8): Likewise.
(s16): Likewise.
(s32): Likewise.
(s64): Likewise.
(u8): Likewise.
(u16): Likewise.
(u32): Likewise.
(u64): Likewise.
* config/aarch64/aarch64-sve-builtins.h
(GCC_AARCH64_SVE_BUILTINS_H): Include aarch64-builtins.h.
(ENTRY): Add aarch64_simd_type definiton.
(enum aarch64_simd_type): Add neon information to type_suffix_info.
(struct type_suffix_info): New function.
* config/aarch64/aarch64-sve.md
(@aarch64_sve_get_neonq_<mode>): New intrinsic insn for big endian.
(@aarch64_sve_set_neonq_<mode>): Likewise.
* config/aarch64/iterators.md: Add UNSPEC_SET_NEONQ.
* config/aarch64/aarch64-builtins.h: New file.
* config/aarch64/aarch64-neon-sve-bridge-builtins.def: New file.
* config/aarch64/arm_neon_sve_bridge.h: New file.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/acle/asm/test_sve_acle.h: Add include
arm_neon_sve_bridge header file
* gcc.dg/torture/neon-sve-bridge.c: New test.
* gcc.target/aarch64/sve/acle/asm/dup_neonq_bf16.c: New test.
* gcc.target/aarch64/sve/acle/asm/dup_neonq_f16.c: New test.
* gcc.target/aarch64/sve/acle/asm/dup_neonq_f32.c: New test.
* gcc.target/aarch64/sve/acle/asm/dup_neonq_f64.c: New test.
* gcc.target/aarch64/sve/acle/asm/dup_neonq_s16.c: New test.
* gcc.target/aarch64/sve/acle/asm/dup_neonq_s32.c: New test.
* gcc.target/aarch64/sve/acle/asm/dup_neonq_s64.c: New test.
* gcc.target/aarch64/sve/acle/asm/dup_neonq_s8.c: New test.
* gcc.target/aarch64/sve/acle/asm/dup_neonq_u16.c: New test.
* gcc.target/aarch64/sve/acle/asm/dup_neonq_u32.c: New test.
* gcc.target/aarch64/sve/acle/asm/dup_neonq_u64.c: New test.
* gcc.target/aarch64/sve/acle/asm/dup_neonq_u8.c: New test.
* gcc.target/aarch64/sve/acle/asm/get_neonq_bf16.c: New test.
* gcc.target/aarch64/sve/acle/asm/get_neonq_f16.c: New test.
* gcc.target/aarch64/sve/acle/asm/get_neonq_f32.c: New test.
* gcc.target/aarch64/sve/acle/asm/get_neonq_f64.c: New test.
* gcc.target/aarch64/sve/acle/asm/get_neonq_s16.c: New test.
* gcc.target/aarch64/sve/acle/asm/get_neonq_s32.c: New test.
* gcc.target/aarch64/sve/acle/asm/get_neonq_s64.c: New test.
* gcc.target/aarch64/sve/acle/asm/get_neonq_s8.c: New test.
* gcc.target/aarch64/sve/acle/asm/get_neonq_u16.c: New test.
* gcc.target/aarch64/sve/acle/asm/get_neonq_u32.c: New test.
* gcc.target/aarch64/sve/acle/asm/get_neonq_u64.c: New test.
* gcc.target/aarch64/sve/acle/asm/get_neonq_u8.c: New test.
* gcc.target/aarch64/sve/acle/asm/set_neonq_bf16.c: New test.
* gcc.target/aarch64/sve/acle/asm/set_neonq_f16.c: New test.
* gcc.target/aarch64/sve/acle/asm/set_neonq_f32.c: New test.
* gcc.target/aarch64/sve/acle/asm/set_neonq_f64.c: New test.
* gcc.target/aarch64/sve/acle/asm/set_neonq_s16.c: New test.
* gcc.target/aarch64/sve/acle/asm/set_neonq_s32.c: New test.
* gcc.target/aarch64/sve/acle/asm/set_neonq_s64.c: New test.
* gcc.target/aarch64/sve/acle/asm/set_neonq_s8.c: New test.
* gcc.target/aarch64/sve/acle/asm/set_neonq_u16.c: New test.
* gcc.target/aarch64/sve/acle/asm/set_neonq_u32.c: New test.
* gcc.target/aarch64/sve/acle/asm/set_neonq_u64.c: New test.
* gcc.target/aarch64/sve/acle/asm/set_neonq_u8.c: New test.
* gcc.target/aarch64/sve/acle/general-c/dup_neonq_1.c: New test.
* gcc.target/aarch64/sve/acle/general-c/get_neonq_1.c: New test.
* gcc.target/aarch64/sve/acle/general-c/set_neonq_1.c: New test.
These notes are controlled by a new command line flag
-fdiagnostics-all-candidates which also controls whether we note
ignored candidates more generally.
* call.cc (print_z_candidates): Only print ignored candidates
when -fdiagnostics-all-candidates is set, otherwise suggest
the flag.
(build_over_call): When diagnosing deletedness, note
other candidates only if -fdiagnostics-all-candidates is
set, otherwise suggest the flag.
gcc/testsuite/ChangeLog:
* g++.dg/overload/error6.C: Pass -fdiagnostics-all-candidates.
* g++.dg/cpp0x/deleted16.C: New test.
* g++.dg/cpp0x/deleted16a.C: New test.
* g++.dg/overload/error6a.C: New test.
Patrick Palka [Wed, 13 Dec 2023 21:46:01 +0000 (16:46 -0500)]
c++: remember candidates that we ignored
During overload resolution, we sometimes outright ignore a function in
the overload set and leave no trace of it in the candidates list, for
example when we find a perfect non-template candidate we discard all
function templates, or when the callee is a template-id we discard all
non-template functions. We should still however make note of these
non-viable functions when diagnosing overload resolution failure, but
that's not possible if they're not present in the returned candidates
list.
To that end, this patch reworks add_candidates to add such ignored
functions to the list. The new rr_ignored rejection reason is somewhat
of a catch-all; we could perhaps split it up into more specific rejection
reasons, but I leave that as future work.
gcc/cp/ChangeLog:
* call.cc (enum rejection_reason_code): Add rr_ignored.
(add_ignored_candidate): Define.
(ignored_candidate_p): Define.
(add_template_candidate_real): Do add_ignored_candidate
instead of returning NULL.
(splice_viable): Put ignored (non-viable) candidates last.
(print_z_candidate): Handle ignored candidates.
(build_new_function_call): Refine shortcut that calls
cp_build_function_call_vec now that non-templates can
appear in the candidate list for a template-id call.
(add_candidates): Replace 'bad_fns' overload with 'bad_cands'
candidate list. When not considering a candidate, add it
to the list as an ignored candidate. Add all 'bad_cands'
to the overload set as well.
gcc/testsuite/ChangeLog:
* g++.dg/diagnostic/param-type-mismatch-2.C: Rename template
function test_7 that (maybe accidentally) shares the same name
as its non-template callee.
* g++.dg/overload/error6.C: New test.
Patrick Palka [Wed, 13 Dec 2023 21:45:50 +0000 (16:45 -0500)]
c++: sort candidates according to viability
This patch:
* changes splice_viable to move the non-viable candidates to the end
of the list instead of removing them outright
* makes tourney move the best candidate to the front of the candidate
list
* adjusts print_z_candidates to preserve our behavior of printing only
viable candidates when diagnosing ambiguity
* adds a parameter to print_z_candidates to control this default behavior
(the follow-up patch will want to print all candidates when diagnosing
deletedness)
Thus after this patch we have access to the entire candidate list through
the best viable candidate.
This change also happens to fix diagnostics for the below testcase where
we currently neglect to note the third candidate, since the presence of
the two unordered non-strictly viable candidates causes splice_viable to
prematurely get rid of the non-viable third candidate.
gcc/cp/ChangeLog:
* call.cc: Include "tristate.h".
(splice_viable): Sort the candidate list according to viability.
Don't remove non-viable candidates from the list.
(print_z_candidates): Add defaulted only_viable_p parameter.
By default only print non-viable candidates if there is no
viable candidate.
(tourney): Ignore non-viable candidates. Move the true champ to
the front of the candidates list, and update 'candidates' to
point to the front. Rename champ_compared_to_predecessor to
previous_worse_champ.
Patrick Palka [Wed, 13 Dec 2023 20:55:14 +0000 (15:55 -0500)]
c++: unifying constants vs their type [PR99186, PR104867]
When unifying constants we need to treat constants of different types
but same value as different in light of auto template parameters since
otherwise e.g. A<1> will unify with A<1u> (where A's template-head is
template<auto>). This patch fixes this in a minimal way; it seems we
could get away with just using template_args_equal here, as we do in the
default case, or even just cp_tree_equal since the CONVERT_EXPR_P loop
seems to be dead code, but that's a simplification we could consider
during next stage 1.
PR c++/99186
PR c++/104867
gcc/cp/ChangeLog:
* pt.cc (unify) <case INTEGER_CST>: Compare types as well.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/nontype-auto23.C: New test.
* g++.dg/cpp1z/nontype-auto24.C: New test.
git://gcc.gnu.org / gcc.git / log