Jason Merrill [Thu, 4 May 2023 22:37:19 +0000 (18:37 -0400)]
Revert "c++: restore instantiate_decl assert"
In the testcase the assert fails because we use one member function from
another while we're in the middle of instantiating them all, which is
perfectly fine. It seems complicated to detect this situation, so let's
remove the assert again.
Uros Bizjak [Thu, 4 May 2023 18:26:12 +0000 (20:26 +0200)]
i386: Tighten ashift to lea splitter operand predicates [PR109733]
The predicates of ashift to lea post-reload splitter were too broad
so the splitter tried to convert the mask shift instruction. Tighten
operand predicates to match only general registers.
gcc/ChangeLog:
PR target/109733
* config/i386/predicates.md (index_reg_operand): New predicate.
* config/i386/i386.md (ashift to lea spliter): Use
general_reg_operand and index_reg_operand predicates.
Gaius Mulley [Thu, 4 May 2023 17:15:59 +0000 (18:15 +0100)]
PR modula2/109729 cannot use a CHAR type as a FOR loop iterator
This patch introduces a new quadruple ArithAddOp which is used in
the construction of FOR loop to ensure that when constant folding
is applied it does not concatenate two constant char operands into
a string constant. Overloading only occurs with constant operands.
gcc/m2/ChangeLog:
PR modula2/109729
* gm2-compiler/M2GenGCC.mod (CodeStatement): Detect
ArithAddOp and call CodeAddChecked.
(ResolveConstantExpressions): Detect ArithAddOp and call
FoldArithAdd.
(FoldArithAdd): New procedure.
(FoldAdd): Refactor to use FoldArithAdd.
* gm2-compiler/M2Quads.def (QuadOperator): Add ArithAddOp.
* gm2-compiler/M2Quads.mod: Remove commented imports.
(QuadFrame): Changed comments to use GNU coding standards.
(ArithPlusTok): New global variable.
(BuildForToByDo): Use ArithPlusTok instead of PlusTok.
(MakeOp): Detect ArithPlusTok and return ArithAddOp.
(WriteQuad): Add ArithAddOp clause.
(WriteOperator): Add ArithAddOp clause.
(Init): Initialize ArithPlusTok.
gcc/testsuite/ChangeLog:
PR modula2/109729
* gm2/pim/run/pass/ForChar.mod: New test.
Kyrylo Tkachov [Thu, 4 May 2023 14:22:04 +0000 (15:22 +0100)]
[2/2] aarch64: Reimplement (R){ADD,SUB}HN2 patterns with standard RTL codes
Similar to the previous patch, this one converts the high-half versions of the patterns.
With this patch we can remove the UNSPEC_* codes involved entirely.
Bootstrapped and tested on aarch64-none-linux-gnu. Also tested on aarch64_be-none-elf.
gcc/ChangeLog:
* config/aarch64/aarch64-simd.md (aarch64_<sur><addsub>hn2<mode>_insn_le):
Rename and reimplement with RTL codes to...
(aarch64_<optab>hn2<mode>_insn_le): .. This.
(aarch64_r<optab>hn2<mode>_insn_le): New pattern.
(aarch64_<sur><addsub>hn2<mode>_insn_be): Rename and reimplement with RTL
codes to...
(aarch64_<optab>hn2<mode>_insn_be): ... This.
(aarch64_r<optab>hn2<mode>_insn_be): New pattern.
(aarch64_<sur><addsub>hn2<mode>): Rename and adjust expander to...
(aarch64_<optab>hn2<mode>): ... This.
(aarch64_r<optab>hn2<mode>): New expander.
* config/aarch64/iterators.md (UNSPEC_ADDHN, UNSPEC_RADDHN,
UNSPEC_SUBHN, UNSPEC_RSUBHN): Delete unspecs.
(ADDSUBHN): Delete.
(sur): Remove handling of the above.
(addsub): Likewise.
Kyrylo Tkachov [Thu, 4 May 2023 14:19:52 +0000 (15:19 +0100)]
[1/2] aarch64: Reimplement (R){ADD,SUB}HN intrinsics with RTL codes
We can implement the halving-narrowing add/sub patterns with standard RTL codes as well rather than relying on unspecs.
This patch handles the low-part ones and the second patch does the high-part ones and removes the unspecs themselves.
The operation ADDHN on V4SI, for example, is represented as (truncate:V4HI ((src1:V4SI + src2:V4SI) >> 16))
and RADDHN as (truncate:V4HI ((src1:V4SI + src2:V4SI + (1 << 15)) >> 16)).
Taking this opportunity I specified the patterns returning the narrow mode and annotated them with the
<vczle><vczbe> define_subst rules to get the vec_concat-zero meta-patterns too. This allows us to simplify
the expanders somewhat too. Tests are added to check that the combinations work.
Bootstrapped and tested on aarch64-none-linux-gnu. Also tested on aarch64_be-none-elf.
gcc/ChangeLog:
* config/aarch64/aarch64-simd.md (aarch64_<sur><addsub>hn<mode>_insn_le):
Delete.
(aarch64_<optab>hn<mode>_insn<vczle><vczbe>): New define_insn.
(aarch64_<sur><addsub>hn<mode>_insn_be): Delete.
(aarch64_r<optab>hn<mode>_insn<vczle><vczbe>): New define_insn.
(aarch64_<sur><addsub>hn<mode>): Delete.
(aarch64_<optab>hn<mode>): New define_expand.
(aarch64_r<optab>hn<mode>): Likewise.
* config/aarch64/predicates.md (aarch64_simd_raddsubhn_imm_vec):
New predicate.
into the proper location for OpenACC testing (thanks to Thomas for
spotting my mistake!), and also fixes a few additional problems --
missing diagnostics for non-pointer attaches, and a case where a pointer
was incorrectly dereferenced. Tests are also adjusted for vector-length
warnings on nvidia accelerators.
2023-04-29 Julian Brown <julian@codesourcery.com>
PR fortran/109622
gcc/fortran/
* openmp.cc (resolve_omp_clauses): Add diagnostic for
non-pointer/non-allocatable attach/detach.
* trans-openmp.cc (gfc_trans_omp_clauses): Remove dereference for
pointer-to-scalar derived type component attach/detach. Fix
attach/detach handling for descriptors.
gcc/testsuite/
* gfortran.dg/goacc/pr109622-5.f90: New test.
* gfortran.dg/goacc/pr109622-6.f90: New test.
Andrew Pinski [Fri, 28 Apr 2023 23:21:50 +0000 (16:21 -0700)]
PHIOPT: Improve replace_phi_edge_with_variable for diamond shapped bb
While looking at differences between what minmax_replacement
and match_simplify_replacement does. I noticed that they sometimes
chose different edges to remove. I decided we should be able to do
better and be able to remove both empty basic blocks in the
case of match_simplify_replacement as that moves the statements.
This also updates the testcases as now match_simplify_replacement
will remove the unused MIN/MAX_EXPR and they were checking for
those.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* tree-ssa-phiopt.cc (replace_phi_edge_with_variable): Handle
diamond form bb with forwarder only empty blocks better.
Andrew Pinski [Tue, 2 May 2023 23:04:00 +0000 (16:04 -0700)]
Move copy_phi_arg_into_existing_phi to common location and use it
While improving replace_phi_edge_with_variable for the diamond formed bb
case, I need a way to copy phi entries from one edge to another as I am
removing a forwarding bb inbetween. I was pointed out that jump threading
code had copy_phi_arg_into_existing_phi which I can use.
I also noticed that both gimple_duplicate_sese_tail and
remove_forwarder_block have similar code so it makes sense to use that function
in those two locations too.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* tree-ssa-threadupdate.cc (copy_phi_arg_into_existing_phi): Move to ...
* tree-cfg.cc (copy_phi_arg_into_existing_phi): Here and remove static.
(gimple_duplicate_sese_tail): Use copy_phi_arg_into_existing_phi instead
of an inline version of it.
* tree-cfgcleanup.cc (remove_forwarder_block): Likewise.
* tree-cfg.h (copy_phi_arg_into_existing_phi): New declaration.
When I added the dce_ssa_names argument, I didn't realize bitmap was a
pointer so I used the default argument value as auto_bitmap(). But
instead we could just use nullptr and check if it was a nullptr
before calling simple_dce_from_worklist.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* tree-ssa-phiopt.cc (replace_phi_edge_with_variable): Change
the default argument value for dce_ssa_names to nullptr.
Check to make sure dce_ssa_names is a non-nullptr before
calling simple_dce_from_worklist.
Richard Biener [Thu, 4 May 2023 08:06:47 +0000 (10:06 +0200)]
tree-optimization/109721 - emulated vectors
When fixing PR109672 I noticed we let SImode AND through when
target_support_p even though it isn't word_mode and I didn't want to
change that but had to catch the case where SImode PLUS is supported
but emulated vectors rely on it being word_mode. The following
makes sure to preserve the word_mode check when !target_support_p
to avoid excessive lowering later even for bit operations.
PR tree-optimization/109721
* tree-vect-stmts.cc (vectorizable_operation): Make sure
to test word_mode for all !target_support_p operations.
Kyrylo Tkachov [Thu, 4 May 2023 08:42:37 +0000 (09:42 +0100)]
aarch64: PR target/99195 annotate simple ternary ops for vec-concat with zero
We're now moving onto various simple ternary instructions, including some lane forms.
These include intrinsics that map down to mla, mls, fma, aba, bsl instructions.
Tests are added for lane 0 and lane 1 as for some of these instructions the lane 0 variants
use separate simpler patterns that need a separate annotation.
Bootstrapped and tested on aarch64-none-linux-gnu.
Kyrylo Tkachov [Thu, 4 May 2023 08:41:46 +0000 (09:41 +0100)]
aarch64: PR target/99195 annotate more simple binary ops for vec-concat with zero
More pattern annotations and tests to eliminate redundant vec-concat with zero instructions.
These are for the abd family of instructions and the pairwise floating-point max/min and fadd
operations too.
Bootstrapped and tested on aarch64-none-linux-gnu.
PR target/99195
* gcc.target/aarch64/simd/pr99195_1.c: Add testing for more binary ops.
* gcc.target/aarch64/simd/pr99195_2.c: Add testing for more binary ops.
Jakub Jelinek [Thu, 4 May 2023 07:36:05 +0000 (09:36 +0200)]
i386: Fix up handling of debug insns in STV [PR109676]
The following testcase ICEs because STV replaces there
(debug_insn 114 47 51 8 (var_location:TI D#3 (reg:TI 91 [ p ])) -1
(nil))
with
(debug_insn 114 47 51 8 (var_location:TI D#3 (reg:V1TI 91 [ p ])) -1
(nil))
which is invalid because of the mode mismatch.
STV has fix_debug_reg_uses function which is supposed to fix this up
and adjust such debug insns into
(debug_insn 114 47 51 8 (var_location:TI D#3 (subreg:TI (reg:V1TI 91 [ p ]) 0)) -1
(nil))
but it doesn't trigger here.
The IL before stv1 has:
(debug_insn 114 47 51 8 (var_location:TI D#3 (reg:TI 91 [ p ])) -1
(nil))
...
(insn 63 62 64 8 (set (mem/c:TI (reg/f:DI 89 [ .result_ptr ]) [0 <retval>.mStorage+0 S16 A32])
(reg:TI 91 [ p ])) "pr109676.C":4:48 87 {*movti_internal}
(expr_list:REG_DEAD (reg:TI 91 [ p ])
(nil)))
in bb 8 and
(insn 97 96 98 9 (set (reg:TI 91 [ p ])
(mem/c:TI (plus:DI (reg/f:DI 19 frame)
(const_int -32 [0xffffffffffffffe0])) [0 p+0 S16 A128])) "pr109676.C":26:12 87 {*movti_internal}
(nil))
(insn 98 97 99 9 (set (mem/c:TI (plus:DI (reg/f:DI 19 frame)
(const_int -64 [0xffffffffffffffc0])) [0 tmp+0 S16 A128])
(reg:TI 91 [ p ])) "pr109676.C":26:12 87 {*movti_internal}
(nil))
in bb9.
PUT_MODE on a REG is done in two spots in timode_scalar_chain::convert_insn,
one is:
switch (GET_CODE (dst))
{
case REG:
if (GET_MODE (dst) == TImode)
{
PUT_MODE (dst, V1TImode);
fix_debug_reg_uses (dst);
}
if (GET_MODE (dst) == V1TImode)
when seeing the REG in SET_DEST and another one the hunk the patch adjusts.
Because bb 8 comes first in the order the pass walks the bbs, we first
notice the TImode pseudo on insn 63 where it is SET_SRC, use PUT_MODE there
unconditionally, so for a shared REG it changes all other uses in the IL,
and then don't call fix_debug_reg_uses because DF_REG_DEF_CHAIN (REGNO (src))
is non-NULL - the REG is set in insn 97 but we haven't processed it yet.
Later on we process insn 97, but because the REG in SET_DEST already has
V1TImode, we don't do anything, even when the src handling code earlier
relied on it being done.
The following patch fixes this by using similar code for both dst and src,
in particular calling fix_debug_reg_uses once when we actually change REG
mode from TImode to V1TImode, and not later on.
2023-05-04 Jakub Jelinek <jakub@redhat.com>
PR debug/109676
* config/i386/i386-features.cc (timode_scalar_chain::convert_insn):
If src is REG, change its mode to V1TImode and call fix_debug_reg_uses
for it only if it still has TImode. Don't decide whether to call
fix_debug_reg_uses based on whether SRC is ever set or not.
CRIS: peephole2 an "and" with a contiguous "one-sided" sequences of 1s
This kind of transformation seems pretty generic and might be a
candidate for adding to the middle-end, perhaps as part of combine.
I noticed these happened more often for LRA, which is the reason I
went on this track of low-hanging-fruit-microoptimizations that are
such an itch when noticing them, inspecting generated code for libgcc.
Unfortunately, this one improves coremark only by a few cycles at the
beginning or end (<0.0005%) for cris-elf -march=v10. The size of the
coremark code is down by 0.4% (0.22% pre-lra).
Using an iterator from the start because other binary operations will
be added and their define_peephole2's would look exactly the same for
the .md part.
Some existing and-peephole2-related tests suffered, because many of
them were using patterns with only contiguous 1:s in them: adjusted.
Also, spotted and fixed, by adding a space, some
scan-assembler-strings that were prone to spurious identifier or file
name matches.
gcc:
* config/cris/cris.cc (cris_split_constant): New function.
* config/cris/cris.md (splitop): New iterator.
(opsplit1): New define_peephole2.
* config/cris/cris-protos.h (cris_split_constant): Declare.
(cris_splittable_constant_p): New macro.
gcc/testsuite:
* gcc.target/cris/peep2-andsplit1.c: New test.
* gcc.target/cris/peep2-andu1.c, gcc.target/cris/peep2-andu2.c,
gcc.target/cris/peep2-xsrand.c, gcc.target/cris/peep2-xsrand2.c:
Adjust values to avoid interference with "opsplit1" with AND. Add
whitespace to match-strings that may be confused with identifiers
or file names.
This has no effect on arith-rand-ll (which suffers badly from LRA) and
marginal effects (0.01% improvement) on coremark, but the size of
coremark shrinks by 0.2%. An earlier version was tested with a tree
around 2023-03 which showed (marginally) that ALL_REGS is preferable
to GENERAL_REGS.
* config/cris/cris.cc (TARGET_SPILL_CLASS): Define
to ALL_REGS.
Gaius Mulley [Thu, 4 May 2023 00:37:05 +0000 (01:37 +0100)]
PR modula2/109675 implementation of writeAddress is non portable
The implementation of gcc/m2/gm2-libs/DynamicStrings.mod:writeAddress
is non portable as it casts a void * into an unsigned long int. This
procedure has been re-implemented to use snprintf. As it is a library
the support tools 'mc' and 'pge' have been rebuilt. There have been
linking changes in the library and the underlying boolean type is now
bool since the last rebuild hence the size of the patch.
This shows no difference neither in arith-rand-ll nor coremark
numbers. Comparing libgcc and newlib libc before/after, the only
difference can be seen in a few functions where it's mostly neutral
(newlib's _svfprintf_r et al) and one function (__gdtoa), which
improves ever so slightly (four bytes less; one load less, but one
instruction reading from memory instead of a register).
* config/cris/cris.cc (cris_side_effect_mode_ok): Use
lra_in_progress, not reload_in_progress.
* config/cris/cris.md ("movdi", "*addi_reload"): Ditto.
* config/cris/constraints.md ("Q"): Ditto.
Jakub Jelinek [Wed, 3 May 2023 20:32:50 +0000 (22:32 +0200)]
libstdc++: Fix up abi.exp FAILs on powerpc64le-linux
This is an ABI problem on powerpc64le-linux, introduced in 13.1.
When libstdc++ is configured against old glibc, the
_ZSt10from_charsPKcS0_RDF128_St12chars_format@@GLIBCXX_3.4.31
_ZSt8to_charsPcS_DF128_@@GLIBCXX_3.4.31
_ZSt8to_charsPcS_DF128_St12chars_format@@GLIBCXX_3.4.31
_ZSt8to_charsPcS_DF128_St12chars_formati@@GLIBCXX_3.4.31
symbols are exported from the library, while when it is configured against
new enough glibc, those symbols aren't exported and we export instead
_ZSt10from_charsPKcS0_Ru9__ieee128St12chars_format@@GLIBCXX_IEEE128_3.4.29
_ZSt8to_charsPcS_u9__ieee128@@GLIBCXX_IEEE128_3.4.29
_ZSt8to_charsPcS_u9__ieee128St12chars_format@@GLIBCXX_IEEE128_3.4.29
_ZSt8to_charsPcS_u9__ieee128St12chars_formati@@GLIBCXX_IEEE128_3.4.29
together with various other @@GLIBCXX_IEEE128_3.4.{29,30,31} and
@@CXXABI_IEEE128_1.3.13 symbols. The idea was that those *IEEE128* symbol
versions (similarly to *LDBL* symbol versions) are optional (but if it
appears, all symbols from it up to the version of the library appears),
but the base appears always.
My _Float128 from_chars/to_chars changes unfortunately broke this.
I believe nothing really uses those symbols if libstdc++ has been
configured against old glibc, so if 13.1 wasn't already released, it might
be best to make sure they aren't exported on powerpc64le-linux.
But as they were exported, I think the best resolution for this ABI
difference is to add those 4 symbols as aliases to the
GLIBCXX_IEEE128_3.4.29 *u9__ieee128* symbols, which the following patch
does.
2023-05-03 Jakub Jelinek <jakub@redhat.com>
* src/c++17/floating_from_chars.cc
(_ZSt10from_charsPKcS0_RDF128_St12chars_format): New alias to
_ZSt10from_charsPKcS0_Ru9__ieee128St12chars_format.
* src/c++17/floating_to_chars.cc (_ZSt8to_charsPcS_DF128_): New alias to
_ZSt8to_charsPcS_u9__ieee128.
(_ZSt8to_charsPcS_DF128_St12chars_format): New alias to
_ZSt8to_charsPcS_u9__ieee128St12chars_format.
(_ZSt8to_charsPcS_DF128_St12chars_formati): New alias to
_ZSt8to_charsPcS_u9__ieee128St12chars_formati.
* config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: Updated.
Jakub Jelinek [Wed, 3 May 2023 20:31:40 +0000 (22:31 +0200)]
libstdc++: Fix up abi.exp FAILs on powerpc64-linux
As discussed on IRC, my _Float128/_Float64x support changes broke
abi.exp testing on powerpc64-linux.
The
_ZTIDF128_@@CXXABI_1.3.14
_ZTIDF64x@@CXXABI_1.3.14
_ZTIPDF128_@@CXXABI_1.3.14
_ZTIPDF64x@@CXXABI_1.3.14
_ZTIPKDF128_@@CXXABI_1.3.14
_ZTIPKDF64x@@CXXABI_1.3.14
symbols only appear on powerpc64le-linux (both when building against
very old glibcs as well as contemporary glibcs), while they don't
appear on powerpc64-linux, because the latter never has _Float128 or
_Float64x support.
But we were using the same baseline_symbols.txt file for both
powerpc64-linux and powerpc64le-linux, even when it contained quite a lot
of stuff specific to the latter; but that was just the IEEE128 related
stuff that appears only when configured against not very old glibc.
The following patch keeps those exports as is and just splits the
config/abi/post/ files, copies the current one to powerpc64le-linux
unmodified and removes the above mentioned symbols plus all
GLIBCXX_IEEE128_3.4.{29,30,31} and CXXABI_IEEE128_1.3.13 symbols
from the powerpc64-linux version.
2023-05-03 Jakub Jelinek <jakub@redhat.com>
* configure.host (abi_baseline_pair): Use powerpc64le-linux-gnu
rather than powerpc64-linux-gnu for powerpc64le*-linux*.
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Remove
_ZTI*DF128_, _ZTI*DF64x symbols and symbols in
GLIBCXX_IEEE128_3.4.{29,30,31} and CXXABI_IEEE128_1.3.13 symbol
versions.
* config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: New
file.
Jason Merrill [Wed, 3 May 2023 17:32:55 +0000 (13:32 -0400)]
c++: over-eager friend matching [PR109649]
A bug in the simplification I did around 91618; at this point X<int>::f has
DECL_IMPLICIT_INSTANTIATION set, but we've already identified what template
it corresponds to, so we don't want to call check_explicit_specialization.
To distinguish this case we need to look at DECL_TI_TEMPLATE. grokfndecl
has for a long time set it to the OVERLOAD in this case, while the new cases
I added for 91618 were leaving DECL_TEMPLATE_INFO null; let's adjust them to
match.
PR c++/91618
PR c++/109649
gcc/cp/ChangeLog:
* friend.cc (do_friend): Don't call check_explicit_specialization if
DECL_TEMPLATE_INFO is already set.
* decl2.cc (check_classfn): Set DECL_TEMPLATE_INFO.
* name-lookup.cc (set_decl_namespace): Likewise.
Andrew Pinski [Tue, 2 May 2023 07:08:19 +0000 (00:08 -0700)]
Add stats to simple_dce_from_worklist
While looking to move substitute_and_fold_engine
over to use simple_dce_from_worklist, I noticed
that we don't record the stats of the removed stmts/phis.
So this does that.
OK? Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* tree-ssa-dce.cc (simple_dce_from_worklist): Record
stats on removed number of statements and phis.
Aldy Hernandez [Wed, 3 May 2023 15:29:24 +0000 (17:29 +0200)]
Allow varying ranges of unknown types in irange::verify_range [PR109711]
The old legacy code allowed building ranges of unknown types so passes
like IPA could build and propagate VARYING. For now it's easiest to
allow the old behavior, it's not like you can do anything with these
ranges except build them and copy them.
Eventually we should convert all users of set_varying() to use
supported types. I will address this in my upcoming IPA work.
PR tree-optimization/109711
gcc/ChangeLog:
* value-range.cc (irange::verify_range): Allow types of
error_mark_node.
do not tailcall __sanitizer_cov_trace_pc [PR90746]
When instrumentation is requested via -fsanitize-coverage=trace-pc, GCC
emits calls of __sanitizer_cov_trace_pc callback in each basic block.
This callback is supposed to be implemented by the user, and should be
able to identify the containing basic block by inspecting its return
address. Tailcalling the callback prevents that, so disallow it.
gcc/ChangeLog:
PR sanitizer/90746
* calls.cc (can_implement_as_sibling_call_p): Reject calls
to __sanitizer_cov_trace_pc.
gcc/testsuite/ChangeLog:
PR sanitizer/90746
* gcc.dg/sancov/basic0.c: Verify absence of tailcall.
aarch64: Fix ABI handling of aligned enums [PR109661]
aarch64_function_arg_alignment has traditionally taken the alignment
of a scalar type T from TYPE_ALIGN (TYPE_MAIN_VARIANT (T)). This is
supposed to discard any user alignment and give the alignment of the
underlying fundamental type.
PR109661 shows that this did the wrong thing for enums with
a defined underlying type, because:
(1) The enum itself could be aligned, using attributes.
(2) The enum would pick up any user alignment on the underlying type.
We get the right behaviour if we look at the TYPE_MAIN_VARIANT
of the underlying type instead.
As always, this affects register and stack arguments differently,
because:
(a) The code that handles register arguments only considers the
alignment of types that occupy two registers, whereas the
stack alignment is applied regardless of size.
(b) The code that handles register arguments tests the alignment
for equality with 16 bytes, so that (unexpected) greater alignments
are ignored. The code that handles stack arguments instead caps the
alignment to 16 bytes.
There is now (since GCC 13) an assert to trap the difference between
(a) and (b), which is how the new incompatiblity showed up.
Clang alredy handled the testcases correctly, so this patch aligns
the GCC behaviour with the Clang behaviour.
I'm planning to remove the asserts on the branches, since we don't
want to change the ABI there.
gcc/
PR target/109661
* config/aarch64/aarch64.cc (aarch64_function_arg_alignment): Add
a new ABI break parameter for GCC 14. Set it to the alignment
of enums that have an underlying type. Take the true alignment
of such enums from the TYPE_ALIGN of the underlying type's
TYPE_MAIN_VARIANT.
(aarch64_function_arg_boundary): Update accordingly.
(aarch64_layout_arg, aarch64_gimplify_va_arg_expr): Likewise.
Warn about ABI differences.
aarch64_function_arg_alignment has two related abi_break
parameters: abi_break for a change in GCC 9, and abi_break_packed
for a related follow-on change in GCC 13. In a sense, abi_break_packed
is a "subfix" of abi_break.
PR109661 now requires a third ABI break that is independent
of the other two. Having abi_break for the GCC 9 break and
abi_break_<something> for the GCC 13 and GCC 14 breaks might
give the impression that they're all related, and that the GCC 14
fix (like the GCC 13 fix) is a "subfix" of the GCC 9 one.
It therefore seemed like a good idea to rename the existing
variables first.
It would be difficult to choose names that describe briefly and
precisely what went wrong in each case. The next best thing
seemed to be to name them after the relevant GCC version.
(Of course, this might break down in future if we need two
independent fixes in the same version. Let's hope not.)
I wondered about putting all the variables in a structure,
but one advantage of using independent variables is that it's
harder to forget to update a caller. Maybe a fourth parameter
would be a tipping point.
gcc/
PR target/109661
* config/aarch64/aarch64.cc (aarch64_function_arg_alignment): Rename
ABI break variables to abi_break_gcc_9 and abi_break_gcc_13.
(aarch64_layout_arg, aarch64_function_arg_boundary): Likewise.
(aarch64_gimplify_va_arg_expr): Likewise.
Christophe Lyon [Tue, 7 Feb 2023 19:26:29 +0000 (19:26 +0000)]
arm: [MVE intrinsics] factorize several binary operations
Factorize vabdq, vhaddq, vhsubq, vmulhq, vqaddq_u, vqdmulhq,
vqrdmulhq, vqrshlq, vqshlq, vqsubq_u, vrhaddq, vrmulhq, vrshlq
so that they use the same pattern.
Christophe Lyon [Tue, 7 Feb 2023 19:15:45 +0000 (19:15 +0000)]
arm: [MVE intrinsics] factorize several binary _m_n operations
Factorize vhaddq_m_n, vhsubq_m_n, vmlaq_m_n, vmlasq_m_n, vqaddq_m_n,
vqdmlahq_m_n, vqdmlashq_m_n, vqdmulhq_m_n, vqrdmlahq_m_n,
vqrdmlashq_m_n, vqrdmulhq_m_n, vqsubq_m_n
so that they use the same pattern.
Christophe Lyon [Wed, 15 Feb 2023 14:38:49 +0000 (14:38 +0000)]
arm: [MVE intrinsics] factorize several binary_m operations
Factorize m-predicated versions of vabdq, vhaddq, vhsubq, vmaxq,
vminq, vmulhq, vqaddq, vqdmladhq, vqdmladhxq, vqdmlsdhq, vqdmlsdhxq,
vqdmulhq, vqrdmladhq, vqrdmladhxq, vqrdmlsdhq, vqrdmlsdhxq, vqrdmulhq,
vqrshlq, vqshlq, vqsubq, vrhaddq, vrmulhq, vrshlq, vshlq
so that they use the same pattern.
Christophe Lyon [Mon, 20 Feb 2023 14:04:29 +0000 (14:04 +0000)]
arm: [MVE intrinsics] add binary_orrq shape
patch adds the binary_orrq shape description.
MODE_n intrinsics use a set of predicates (preds_m_or_none) different
the MODE_none ones, so we explicitly reference preds_m_or_none from
the shape, thus we need to make it a global array.
In order to avoid using a huge switch when generating all the
intrinsics (e.g. mve_vaddq_n_sv4si, ...), we want to generate a single
function taking the builtin code as parameter (e.g. mve_q_n (VADDQ_S,
....)
This is achieved by using the new mve_insn iterator.
Having done that, it becomes easier to share similar patterns, to
avoid useless/error-prone code duplication.
Christophe Lyon [Thu, 11 Aug 2022 16:15:03 +0000 (16:15 +0000)]
arm: [MVE intrinsics] Rework vuninitialized
Implement vuninitialized using the new MVE builtins framework.
We need to keep the overloaded __arm_vuninitializedq definitions
because their resolution depends on the result type only, which is not
currently supported by the resolver.
gcc/testsuite/
* g++.target/arm/mve.exp: Add general-c++ and general directories.
* g++.target/arm/mve/general-c++/nomve_fp_1.c: New test.
* g++.target/arm/mve/general-c++/vreinterpretq_1.C: New test.
* gcc.target/arm/mve/general-c/nomve_fp_1.c: New test.
* gcc.target/arm/mve/general-c/vreinterpretq_1.c: New test.
This patch introduces the new MVE intrinsics framework, heavily
inspired by the SVE one in the aarch64 port.
Like the MVE intrinsic types implementation, the intrinsics framework
defines functions via a new pragma in arm_mve.h. A boolean parameter
is used to pass true when __ARM_MVE_PRESERVE_USER_NAMESPACE is
defined, and false when it is not, allowing for non-prefixed intrinsic
functions to be conditionally defined.
Future patches will build on this framework by adding new intrinsic
functions and adding the features needed to support them.
Differences compared to the aarch64/SVE port include:
- when present, the predicate argument is the last one with MVE (the
first one with SVE)
- when using merging predicates ("_m" suffix), the "inactive" argument
(if any) is inserted in the first position
- when using merging predicates ("_m" suffix), some function do not
have the "inactive" argument, so we maintain an exception-list
- MVE intrinsics dealing with floating-point require the FP extension,
while SVE may support different extensions
- regarding global state, MVE does not have any prefetch intrinsic, so
we do not need a flag for this
- intrinsic names can be prefixed with "__arm", depending on whether
preserve_user_namespace is true or false
- parse_signature: the maximum number of arguments is now a parameter,
this helps detecting an overflow with a new assert.
- suffixes and overloading can be controlled using
explicit_mode_suffix_p and skip_overload_p in addition to
explicit_type_suffix_p
At this implemtation stage, there are some limitations compared
to aarch64/SVE, which are removed later in the series:
- "offset" mode is not supported yet
- gimple folding is not implemented
arm: move builtin function codes into general numberspace
This patch introduces a separate numberspace for general arm builtin
function codes. The intent of this patch is to separate the space of
function codes that may be assigned to general builtins and future
MVE intrinsic functions by using the first bit of each function code
to differentiate them. This is identical to how SVE intrinsic functions
are currently differentiated from general aarch64 builtins.
Future intrinsics implementations may also make use of numberspacing by
changing the values of ARM_BUILTIN_SHIFT and ARM_BUILTIN_CLASS, and
adding themselves to the arm_builtin_class enum.
* config/arm/arm-builtins.cc (arm_general_add_builtin_function):
New function.
(arm_init_builtin): Use arm_general_add_builtin_function instead
of arm_add_builtin_function.
(arm_init_acle_builtins): Likewise.
(arm_init_mve_builtins): Likewise.
(arm_init_crypto_builtins): Likewise.
(arm_init_builtins): Likewise.
(arm_general_builtin_decl): New function.
(arm_builtin_decl): Defer to numberspace-specialized functions.
(arm_expand_builtin_args): Rename into arm_general_expand_builtin_args.
(arm_expand_builtin_1): Rename into arm_general_expand_builtin_1 and ...
(arm_general_expand_builtin_1): ... specialize for general builtins.
(arm_expand_acle_builtin): Use arm_general_expand_builtin
instead of arm_expand_builtin.
(arm_expand_mve_builtin): Likewise.
(arm_expand_neon_builtin): Likewise.
(arm_expand_vfp_builtin): Likewise.
(arm_general_expand_builtin): New function.
(arm_expand_builtin): Specialize for general builtins.
(arm_general_check_builtin_call): New function.
(arm_check_builtin_call): Specialize for general builtins.
(arm_describe_resolver): Validate numberspace.
(arm_cde_end_args): Likewise.
* config/arm/arm-protos.h (enum arm_builtin_class): New enum.
(ARM_BUILTIN_SHIFT, ARM_BUILTIN_CLASS): New constants.
Martin Liska [Wed, 3 May 2023 14:35:26 +0000 (16:35 +0200)]
riscv: fix error: control reaches end of non-void function
Fixes:
gcc/config/riscv/sync.md:66:1: error: control reaches end of non-void function [-Werror=return-type]
66 | [(set (attr "length") (const_int 4))])
| ^
PR target/109713
gcc/ChangeLog:
* config/riscv/sync.md: Add gcc_unreachable to a switch.
Richard Biener [Wed, 3 May 2023 11:24:45 +0000 (13:24 +0200)]
More last_stmt removal
This is the last set of changes removing calls to last_stmt in favor of
*gsi_last_bb where this is obviously correct. As with the last changes
I tried to cleanup the code as far as dependences are concerned.
Kefu Chai [Mon, 1 May 2023 20:24:26 +0000 (21:24 +0100)]
libstdc++: Set _M_string_length before calling _M_dispose() [PR109703]
This always sets _M_string_length in the constructor for ranges of input
iterators, such as stream iterators.
We copy from the source range to the local buffer, and then repeatedly
reallocate a larger one if necessary. When disposing the old buffer,
_M_is_local() is used to tell if the buffer is the local one or not (and
so must be deallocated). In addition to comparing the buffer address
with the local buffer, _M_is_local() has an optimization hint so that
the compiler knows that for a string using the local buffer, there is an
invariant that _M_string_length <= _S_local_capacity (added for PR109299
via r13-6915-gbf78b43873b0b7). But we failed to set _M_string_length in
the constructor taking a pair of iterators, so the invariant might not
hold, and __builtin_unreachable() is reached. This causes UBsan errors,
and potentially misoptimization.
To ensure the invariant holds, _M_string_length is initialized to zero
before doing anything else, so that _M_is_local() doesn't see an
uninitialized value.
This issue only surfaces when constructing a string with a range of
input iterator, and the uninitialized _M_string_length happens to be
greater than _S_local_capacity, i.e., 15 for the std::string
specialization.
Andreas Schwab [Sat, 23 Apr 2022 13:48:42 +0000 (15:48 +0200)]
riscv/linux: Don't add -latomic with -pthread
Now that we have support for inline subword atomic operations, it is no
longer necessary to link against libatomic. This also fixes testsuite
failures because the framework does not properly set up the linker flags
for finding libatomic.
The use of atomic operations is also independent of the use of libpthread.
* gcc.target/riscv/rvv/base/abi-10.c: New test.
* gcc.target/riscv/rvv/base/abi-11.c: New test.
* gcc.target/riscv/rvv/base/abi-12.c: New test.
* gcc.target/riscv/rvv/base/abi-13.c: New test.
* gcc.target/riscv/rvv/base/abi-14.c: New test.
* gcc.target/riscv/rvv/base/abi-15.c: New test.
* gcc.target/riscv/rvv/base/abi-16.c: New test.
* gcc.target/riscv/rvv/base/abi-8.c: New test.
* gcc.target/riscv/rvv/base/abi-9.c: New test.
* gcc.target/riscv/rvv/base/tuple-1.c: New test.
* gcc.target/riscv/rvv/base/tuple-10.c: New test.
* gcc.target/riscv/rvv/base/tuple-11.c: New test.
* gcc.target/riscv/rvv/base/tuple-12.c: New test.
* gcc.target/riscv/rvv/base/tuple-13.c: New test.
* gcc.target/riscv/rvv/base/tuple-14.c: New test.
* gcc.target/riscv/rvv/base/tuple-15.c: New test.
* gcc.target/riscv/rvv/base/tuple-16.c: New test.
* gcc.target/riscv/rvv/base/tuple-17.c: New test.
* gcc.target/riscv/rvv/base/tuple-18.c: New test.
* gcc.target/riscv/rvv/base/tuple-19.c: New test.
* gcc.target/riscv/rvv/base/tuple-2.c: New test.
* gcc.target/riscv/rvv/base/tuple-20.c: New test.
* gcc.target/riscv/rvv/base/tuple-21.c: New test.
* gcc.target/riscv/rvv/base/tuple-22.c: New test.
* gcc.target/riscv/rvv/base/tuple-23.c: New test.
* gcc.target/riscv/rvv/base/tuple-24.c: New test.
* gcc.target/riscv/rvv/base/tuple-25.c: New test.
* gcc.target/riscv/rvv/base/tuple-26.c: New test.
* gcc.target/riscv/rvv/base/tuple-27.c: New test.
* gcc.target/riscv/rvv/base/tuple-3.c: New test.
* gcc.target/riscv/rvv/base/tuple-4.c: New test.
* gcc.target/riscv/rvv/base/tuple-5.c: New test.
* gcc.target/riscv/rvv/base/tuple-6.c: New test.
* gcc.target/riscv/rvv/base/tuple-7.c: New test.
* gcc.target/riscv/rvv/base/tuple-8.c: New test.
* gcc.target/riscv/rvv/base/tuple-9.c: New test.
* gcc.target/riscv/rvv/base/user-10.c: New test.
* gcc.target/riscv/rvv/base/user-11.c: New test.
* gcc.target/riscv/rvv/base/user-12.c: New test.
* gcc.target/riscv/rvv/base/user-13.c: New test.
* gcc.target/riscv/rvv/base/user-14.c: New test.
* gcc.target/riscv/rvv/base/user-15.c: New test.
* gcc.target/riscv/rvv/base/user-7.c: New test.
* gcc.target/riscv/rvv/base/user-8.c: New test.
* gcc.target/riscv/rvv/base/user-9.c: New test.
Richard Biener [Fri, 3 Feb 2023 10:11:15 +0000 (11:11 +0100)]
Speedup cse_insn
When cse_insn prunes src{,_folded,_eqv_here,_related} with the
equivalence set in the *_same_value chain it also searches for
an equivalence to the destination of the instruction with
/* This is the same as the destination of the insns, we want
to prefer it. Copy it to src_related. The code below will
then give it a negative cost. */
if (GET_CODE (dest) == code && rtx_equal_p (p->exp, dest))
src_related = p->exp;
this picks up the last such equivalence and in particular any
later duplicate will be pruned by the preceeding
first. This wastes cycles doing extra rtx_equal_p checks. The
following instead searches for the first destination equivalence
separately in this loop and delays using src_related for it until
we are about to process that, avoiding another redundant rtx_equal_p
check.
I've came here because of a testcase with very large equivalence
lists and compile-time of cse_insn. The patch below doesn't speed
it up significantly since there's no equivalence on the destination.
In theory this opens the possibility to track dest_related
separately, avoiding the implicit pruning of any previous
value in src_related. As is the change should be a no-op for
code generation.
* cse.cc (cse_insn): Track an equivalence to the destination
separately and delay using src_related for it.
Richard Biener [Fri, 3 Feb 2023 11:11:41 +0000 (12:11 +0100)]
Improve RTL CSE hash table hash usage
The RTL CSE hash table has a fixed number of buckets (32) each
with a linked list of entries with the same hash value. The
actual hash values are computed using hash_rtx which uses adds
for mixing and adds the rtx CODE as CODE << 7 (apart from some
exceptions such as MEM). The unsigned int typed hash value
is then simply truncated for the actual lookup into the fixed
size table which means that usually CODE is simply lost.
The following improves this truncation by first mixing in more
bits using xor. It does not change the actual hash function
since that's used outside of CSE as well.
An alternative would be to bump the fixed number of buckets,
say to 256 which would retain the LSB of CODE or to 8192 which
can capture all 6 bits required for the last CODE.
As the comment in CSE says, there's invalidate_memory and
flush_hash_table done possibly frequently and those at least
need to walk all slots, so when the hash table is mostly empty
enlarging it will be a loss. Still there should be more
regular lookups by hash, so less collisions should pay off
as well.
Without enlarging the table a better hash function is unlikely
going to make a big difference, simple statistics on the
number of collisions at insertion time shows a reduction of
around 10%. Bumping HASH_SHIFT by 1 improves that to 30%
at the expense of reducing the average table fill by 10%
(all of this stats from looking just at fold-const.i at -O2).
Increasing HASH_SHIFT more leaves the table even more sparse
likely showing that hash_rtx uses add for mixing which is
quite bad. Bumping HASH_SHIFT by 2 removes 90% of all
collisions.
Experimenting with using inchash instead of adds for the
mixing does not improve things when looking at the HASH_SHIFT
bumped by 2 numbers.
* cse.cc (HASH): Turn into inline function and mix
in another HASH_SHIFT bits.
(SAFE_HASH): Likewise.
Kyrylo Tkachov [Wed, 3 May 2023 10:17:28 +0000 (11:17 +0100)]
aarch64: PR target/99195 annotate HADDSUB patterns for vec-concat with zero
Further straightforward patch for the various halving intrinsics with or without rounding, plus tests.
Bootstrapped and tested on aarch64-none-linux-gnu and aarch64_be-none-elf.
Kyrylo Tkachov [Wed, 3 May 2023 10:15:34 +0000 (11:15 +0100)]
aarch64: PR target/99195 annotate simple floating-point patterns for vec-concat with zero
Continuing the, almost mechanical, series this patch adds annotation for some of the simple
floating-point patterns we have, and adds testing to ensure that redundant zeroing instructions
are eliminated.
Bootstrapped and tested on aarch64-none-linux-gnu and also aarch64_be-none-elf.
PR target/99195
* gcc.target/aarch64/simd/pr99195_1.c: Add testing for some unary
and binary floating-point ops.
* gcc.target/aarch64/simd/pr99195_2.c: New test.
Jakub Jelinek [Wed, 3 May 2023 08:38:04 +0000 (10:38 +0200)]
c++: Fix up VEC_INIT_EXPR gimplification after r12-7069
During patch backporting, I've noticed that while most cp_walk_tree calls
with cp_fold_r callback callers were changed from &pset to cp_fold_data
&data, the VEC_INIT_EXPR gimplifications has not, so it still passes just
address of a hash_set<tree> and so if during the folding we ever touch
data->flags, we use uninitialized data there.
The following patch changes it to do the same thing as cp_fold_function
because the VEC_INIT_EXPR gimplifications will happen on function bodies
only.
2023-05-03 Jakub Jelinek <jakub@redhat.com>
* cp-gimplify.cc (cp_fold_data): Move definition earlier.
(cp_gimplify_expr): Pass address of ff_genericize | ff_mce_false
constructed data rather than &pset to cp_walk_tree with cp_fold_r.
Jason Merrill [Tue, 14 Mar 2023 19:16:46 +0000 (15:16 -0400)]
c++: fix TTP level reduction cache
We try to cache the result of reduce_template_parm_level so that when we
reduce the same parm multiple times we get the same result, but this wasn't
working for template template parms because in that case TYPE is a
TEMPLATE_TEMPLATE_PARM, and so same_type_p was false because of the same
level mismatch that we're trying to adjust for. So in that case compare the
template parms of the template template parms instead.
The result can be seen in nontype12.C, where we previously gave three
duplicate errors on line 7 and now give only one because subsequent
substitutions use the cache.
gcc/cp/ChangeLog:
* pt.cc (reduce_template_parm_level): Fix comparison of
template template parm to cached version.
gcc/testsuite/ChangeLog:
* g++.dg/template/nontype12.C: Check for duplicate error.
Jason Merrill [Tue, 2 May 2023 18:54:46 +0000 (14:54 -0400)]
c++: simplify member template substitution
I noticed that for member class templates of a class template we were
unnecessarily substituting both the template and its type. Avoiding that
duplication speeds compilation of this silly testcase from ~12s to ~9s on my
laptop. It's unlikely to make a difference on any real code, but the
simplification is also nice.
We still need to clear CLASSTYPE_USE_TEMPLATE on the partial instantiation
of the template class, but it makes more sense to do that in
tsubst_template_decl anyway.
Andrew Pinski [Fri, 28 Apr 2023 20:06:51 +0000 (13:06 -0700)]
PHIOPT: small refactoring of match_simplify_replacement.
When I added diamond shaped form bb to match_simplify_replacement,
I copied the code to move the statement rather than factoring it
out to a new function. This does the refactoring to a new function
to avoid the duplicated code. It will make adding support for having
two statements to move easier (the second statement will only be a
conversion).
OK? Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* tree-ssa-phiopt.cc (move_stmt): New function.
(match_simplify_replacement): Use move_stmt instead
of the inlined version.
Jason Merrill [Tue, 21 Mar 2023 15:12:42 +0000 (11:12 -0400)]
c++: less invalidate_class_lookup_cache
In the testcase below, we push_to_top_level to instantiate f and g, and they
can both use the previous_class_level cache from instantiating A<int>.
Wiping the cache in pop_from_top_level is not helpful; we'll do that in
pushclass if needed.
template <class T> struct A
{
int i;
void f() { i = 42; }
void g() { i = 24; }
};
Jason Merrill [Tue, 2 May 2023 01:03:45 +0000 (21:03 -0400)]
c++: look for empty base at specific offset [PR109678]
While looking at the empty base handling for 109678, it occurred to me that
we ought to be able to look for an empty base at a specific offset, not just
in general.
PR c++/109678
gcc/cp/ChangeLog:
* cp-tree.h (lookup_base): Add offset parm.
* constexpr.cc (cxx_fold_indirect_ref_1): Pass it.
* search.cc (struct lookup_base_data_s): Add offset.
(dfs_lookup_base): Handle it.
(lookup_base): Pass it.
Jason Merrill [Mon, 1 May 2023 21:41:44 +0000 (17:41 -0400)]
c++: std::variant slow to compile [PR109678]
Here, when dealing with a class with a complex subobject structure, we would
try and fail to find the relevant FIELD_DECL for an empty base before giving
up. And we would do this at each level, in a combinatorially problematic
way. Instead, we should check for an empty base first.
PR c++/109678
gcc/cp/ChangeLog:
* constexpr.cc (cxx_fold_indirect_ref_1): Handle empty base first.
Patrick O'Neill [Fri, 7 Apr 2023 20:13:21 +0000 (13:13 -0700)]
RISC-V: Table A.6 conformance tests
These tests cover basic cases to ensure the atomic mappings follow the
strengthened Table A.6 mappings that are compatible with Table A.7.
2023-04-27 Patrick O'Neill <patrick@rivosinc.com>
gcc/testsuite/ChangeLog:
* gcc.target/riscv/amo-table-a-6-amo-add-1.c: New test.
* gcc.target/riscv/amo-table-a-6-amo-add-2.c: New test.
* gcc.target/riscv/amo-table-a-6-amo-add-3.c: New test.
* gcc.target/riscv/amo-table-a-6-amo-add-4.c: New test.
* gcc.target/riscv/amo-table-a-6-amo-add-5.c: New test.
* gcc.target/riscv/amo-table-a-6-compare-exchange-1.c: New test.
* gcc.target/riscv/amo-table-a-6-compare-exchange-2.c: New test.
* gcc.target/riscv/amo-table-a-6-compare-exchange-3.c: New test.
* gcc.target/riscv/amo-table-a-6-compare-exchange-4.c: New test.
* gcc.target/riscv/amo-table-a-6-compare-exchange-5.c: New test.
* gcc.target/riscv/amo-table-a-6-compare-exchange-6.c: New test.
* gcc.target/riscv/amo-table-a-6-compare-exchange-7.c: New test.
* gcc.target/riscv/amo-table-a-6-fence-1.c: New test.
* gcc.target/riscv/amo-table-a-6-fence-2.c: New test.
* gcc.target/riscv/amo-table-a-6-fence-3.c: New test.
* gcc.target/riscv/amo-table-a-6-fence-4.c: New test.
* gcc.target/riscv/amo-table-a-6-fence-5.c: New test.
* gcc.target/riscv/amo-table-a-6-load-1.c: New test.
* gcc.target/riscv/amo-table-a-6-load-2.c: New test.
* gcc.target/riscv/amo-table-a-6-load-3.c: New test.
* gcc.target/riscv/amo-table-a-6-store-1.c: New test.
* gcc.target/riscv/amo-table-a-6-store-2.c: New test.
* gcc.target/riscv/amo-table-a-6-store-compat-3.c: New test.
* gcc.target/riscv/amo-table-a-6-subword-amo-add-1.c: New test.
* gcc.target/riscv/amo-table-a-6-subword-amo-add-2.c: New test.
* gcc.target/riscv/amo-table-a-6-subword-amo-add-3.c: New test.
* gcc.target/riscv/amo-table-a-6-subword-amo-add-4.c: New test.
* gcc.target/riscv/amo-table-a-6-subword-amo-add-5.c: New test.
Signed-off-by: Patrick O'Neill <patrick@rivosinc.com>
Patrick O'Neill [Wed, 5 Apr 2023 16:49:20 +0000 (09:49 -0700)]
RISC-V: Weaken LR/SC pairs
Introduce the %I and %J flags for setting the .aqrl bits on LR/SC pairs
as needed.
Atomic compare and exchange ops provide success and failure memory
models. C++17 and later place no restrictions on the relative strength
of each model, so ensure we cover both by using a model that enforces
the ordering of both given models.
This change brings LR/SC ops in line with table A.6 of the ISA manual.
2023-04-27 Patrick O'Neill <patrick@rivosinc.com>
gcc/ChangeLog:
* config/riscv/riscv-protos.h (riscv_union_memmodels): Expose
riscv_union_memmodels function to sync.md.
* config/riscv/riscv.cc (riscv_union_memmodels): Add function to
get the union of two memmodels in sync.md.
(riscv_print_operand): Add %I and %J flags that output the
optimal LR/SC flag bits for a given memory model.
* config/riscv/sync.md: Remove static .aqrl bits on LR op/.rl
bits on SC op and replace with optimized %I, %J flags.
Signed-off-by: Patrick O'Neill <patrick@rivosinc.com>
Patrick O'Neill [Wed, 5 Apr 2023 16:56:33 +0000 (09:56 -0700)]
RISC-V: Strengthen atomic stores
This change makes atomic stores strictly stronger than table A.6 of the
ISA manual. This mapping makes the overall patchset compatible with
table A.7 as well.
2023-04-27 Patrick O'Neill <patrick@rivosinc.com>
PR target/89835
gcc/ChangeLog:
* config/riscv/sync.md (atomic_store<mode>): Use simple store
instruction in combination with fence(s).
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr89835.c: New test.
Signed-off-by: Patrick O'Neill <patrick@rivosinc.com>
Patrick O'Neill [Fri, 28 Apr 2023 23:40:27 +0000 (16:40 -0700)]
RISC-V: Name newly added flags in changelog
This patch fixes the changelog to explicitly name the added command line
flags introduced in this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616807.html
2023-05-01 Patrick O'Neill <patrick@rivosinc.com>
Signed-off-by: Patrick O'Neill <patrick@rivosinc.com>
Yanzhang Wang [Wed, 26 Apr 2023 13:06:02 +0000 (21:06 +0800)]
RISC-V: ICE for vlmul_ext_v intrinsic API
PR target/109617
gcc/ChangeLog:
* config/riscv/vector-iterators.md: Support VNx2HI and VNX4DI when MIN_VLEN >= 128.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/vlmul_ext-1.c: New test.
Signed-off-by: Yanzhang Wang <yanzhang.wang@intel.com> Co-authored-by: Pan Li <pan2.li@intel.com> Signed-off-by: Yanzhang Wang <yanzhang.wang@intel.com>
Romain Naour [Tue, 2 May 2023 12:21:55 +0000 (14:21 +0200)]
RISC-V: fix build issue with gcc 4.9.x
GCC should still build with GCC 4.8.3 or newer [1]
using C++03 by default. But a recent change in
RISC-V port introduced a C++11 feature "std::log2" [2].
Use log2 from the C header, without the namespace [3].
Richard Biener [Tue, 2 May 2023 08:34:48 +0000 (10:34 +0200)]
tree-optimization/109672 - properly check emulated plus during vect
The following refactors the check for emulated vector support for
the cases of plus, minus and negate. In the PR we end up with
a SImode plus, supported by the target but emulated and in this
context fail to verify we are dealing with exactly word_mode.
PR tree-optimization/109672
* tree-vect-stmts.cc (vectorizable_operation): For plus,
minus and negate always check the vector mode is word mode.
Richard Biener [Tue, 2 May 2023 09:51:51 +0000 (11:51 +0200)]
[i386] Fix testcases for emulated scatter
The following adjusts testcases where the pr88531 fail with -m32
because we do not consider MMX size vectorization there and the
pr89618 runs into load/store cost differences with -m32.
Jakub Jelinek [Tue, 2 May 2023 08:58:19 +0000 (10:58 +0200)]
ibstdc++: Shut up -Wattribute-alias warning [PR109694]
I've followed what other files do, using attribute alias with not really
matching function type (after all, it isn't really possible when it is a
constructor), but seems I've missed it warns:
../../../../../libstdc++-v3/src/c++98/ios_init.cc:203:8: warning: ‘void std::ios_base_library_init()’ alias between functions of incompatible types ‘void()’ and ‘void
+(std::ios_base::Init::)()’ [-Wattribute-alias=]
203 | void ios_base_library_init (void)
| ^~~~~~~~~~~~~~~~~~~~~
../../../../../libstdc++-v3/src/c++98/ios_init.cc:78:3: note: aliased declaration here
78 | ios_base::Init::Init()
| ^~~~~~~~
The PR talks about clang++ warning there (which I think isn't really
supported, libstdc++ sources ought to be built by GCC), but it warns
when built with GCC too.
The following patch fixes it by doing what other libstdc++ sources do in
those cases.
projects / thirdparty / gcc.git / log
