Come back to review the codes of gather/scatter, notice gather_scatter_valid_offset_mode_p looks odd.
gather_scatter_valid_offset_mode_p is supposed to block vluxei64/vsuxei64 in RV32 system.
However, it failed to do that since it is passing data_mode instead of index mode:
riscv_vector::gather_scatter_valid_offset_mode_p (<RATIO2:MODE>mode)
It should be RATIO2I instead of RATIO2.
So we have this following iterators which already can block the this situation:
(define_mode_iterator RATIO8I [
RVVM1QI
RVVM2HI
RVVM4SI
(RVVM8DI "TARGET_VECTOR_ELEN_64 && TARGET_64BIT")
])
We can see TARGET_64BIT to block EEW64 index mode on RV32 system.
So, gather_scatter_valid_offset_mode_p is no longer needed.
After remove it, I find due to incorrect gather_scatter_valid_offset_mode_p.
We failed to vectorize such case in RV32 in the past:
void __attribute__ ((noinline, noclone)) \
f_##DATA_TYPE (DATA_TYPE *restrict dest, DATA_TYPE *restrict src, \
INDEX##BITS *restrict indices, INDEX##BITS *restrict cond) \
{ \
for (int i = 0; i < 128; ++i) \
if (cond[i]) \
dest[i] += src[indices[i]]; \
}
T (int64_t, 8)
TEST_ALL (TEST_LOOP)
https://godbolt.org/z/T3ara3fM3
Checked compiler explorer, we can see GCC failed to vectorize it but Clang can vectorize it.
So adapt the tests checking vectorization cases from 8 -> 11.
Confirm we have same behavior as Clang now.
Tested on zvl128/zvl256/zvl512/zvl1024 no regression.
Note this is not an optimization patch, it's buggy codes fix patch.
gcc/ChangeLog:
* config/riscv/autovec.md
(mask_len_gather_load<RATIO1:mode><RATIO1:mode>):
Remove gather_scatter_valid_offset_mode_p.
(mask_len_gather_load<mode><mode>): Ditto.
(mask_len_scatter_store<RATIO1:mode><RATIO1:mode>): Ditto.
(mask_len_scatter_store<mode><mode>): Ditto.
* config/riscv/predicates.md (const_1_or_8_operand): New predicate.
(vector_gs_scale_operand_64): Remove.
* config/riscv/riscv-protos.h (gather_scatter_valid_offset_mode_p): Remove.
* config/riscv/riscv-v.cc (expand_gather_scatter): Refine code.
(gather_scatter_valid_offset_mode_p): Remove.
* config/riscv/vector-iterators.md: Fix iterator bugs.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-1.c: Adapt test.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-10.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-11.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-4.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-5.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-6.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-7.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-8.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_32-9.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-10.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-4.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-5.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-6.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-7.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-8.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_scatter_store_32-9.c: Ditto.
Along with RV32E, RV64E is ratified. Though ILP32E and LP64E ABIs are
still draft, it's worth supporting it.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_ext_version_table): Set version to ratified 2.0.
(riscv_subset_list::parse_std_ext): Allow RV64E.
* config.gcc: Parse base ISA 'rv64e' and ABI 'lp64e'.
* config/riscv/arch-canonicalize: Parse base ISA 'rv64e'.
* config/riscv/riscv-c.cc (riscv_cpu_cpp_builtins):
Define different macro per XLEN. Add handling for ABI_LP64E.
* config/riscv/riscv-d.cc (riscv_d_handle_target_float_abi):
Add handling for ABI_LP64E.
* config/riscv/riscv-opts.h (enum riscv_abi_type): Add ABI_LP64E.
* config/riscv/riscv.cc (riscv_option_override): Enhance error
handling to support RV64E and LP64E.
(riscv_conditional_register_usage): Change "RV32E" in a comment
to "RV32E/RV64E".
* config/riscv/riscv.h
(UNITS_PER_FP_ARG): Add handling for ABI_LP64E.
(STACK_BOUNDARY): Ditto.
(ABI_STACK_BOUNDARY): Ditto.
(MAX_ARGS_IN_REGISTERS): Ditto.
(ABI_SPEC): Add support for "lp64e".
* config/riscv/riscv.opt: Parse -mabi=lp64e as ABI_LP64E.
* doc/invoke.texi: Add documentation of the LP64E ABI.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/predef-1.c: Test for __riscv_64e.
* gcc.target/riscv/predef-2.c: Ditto.
* gcc.target/riscv/predef-3.c: Ditto.
* gcc.target/riscv/predef-4.c: Ditto.
* gcc.target/riscv/predef-5.c: Ditto.
* gcc.target/riscv/predef-6.c: Ditto.
* gcc.target/riscv/predef-7.c: Ditto.
* gcc.target/riscv/predef-8.c: Ditto.
* gcc.target/riscv/predef-9.c: New test for RV64E and LP64E,
based on predef-7.c.
For the following immediate load operation in gcc/testsuite/gcc.target/loongarch/imm-load1.c:
long long r = 0x0101010101010101;
Before this patch:
lu12i.w $r15,16842752>>12
ori $r15,$r15,257
lu32i.d $r15,0x1010100000000>>32
lu52i.d $r15,$r15,0x100000000000000>>52
After this patch:
lu12i.w $r15,16842752>>12
ori $r15,$r15,257
bstrins.d $r15,$r15,63,32
gcc/ChangeLog:
* config/loongarch/loongarch.cc
(enum loongarch_load_imm_method): Add new method.
(loongarch_build_integer): Add relevant implementations for
new method.
(loongarch_move_integer): Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/imm-load1.c: Change old check.
The xfail for "*-*-*" here, set in r14-4089-gd45ddc2c04e471
"tree-optimization/111294 - backwards threader PHI costing"
was somewhat too general and made this test XPASS for a
number of targets. The common factor for those targets is
that they either explicitly or by default define
LOGICAL_OP_NON_SHORT_CIRCUIT as 0 (see fold-const.cc).
Instead of changing *-*-* to a seemingly random set of
xfailed targets or inventing a new testsuite
effective-target predicate for logical-op-short-circuited
targets or the opposite, let's just force a setting that
removes the need for the xfail for all targets, by
overriding with --param=logical-op-non-short-circuit=0.
* gcc.dg/uninit-pred-9_b.c: Remove xfail for line 20. Pass
--param=logical-op-non-short-circuit=0. Comment why.
In a recent all-target test-round investigating XPASSes for
this file, I noticed this line XPASSing for MMIX. From the
commit history it's obvious it was left out from related
target-xfail tweaks, now the last target xfailing a bogus
warning for this line.
* gcc.dg/uninit-pred-9_b.c: Remove xfail for MMIX from line 23.
gcc/fortran/ChangeLog:
PR fortran/111880
* resolve.cc (resolve_common_vars): Do not call gfc_add_in_common
for symbols that are USE associated or used in a submodule.
gcc/testsuite/ChangeLog:
PR fortran/111880
* gfortran.dg/pr111880.f90: New test.
Avoid using 'network sort' (a misnomer) in sort.cc, the correct term is
'sorting networks'.
gcc/ChangeLog:
* sort.cc: Use 'sorting networks' in comments.
2023-11-26 John David Anglin <danglin@gcc.gnu.org>
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/fd-glibc-datagram-client.c: Skip on hppa*-*-hpux*.
* gcc.dg/analyzer/fd-glibc-datagram-socket.c: Likewise.
2023-11-23 John David Anglin <danglin@gcc.gnu.org>
gcc/testsuite/ChangeLog:
* g++.dg/modules/bad-mapper-1.C: Add hppa*-*-hpux* to dg-error
"this-will-not-work" targets.
The new test at gcc.target/i386/cf_check-6.c fails on darwin with:
Excess errors:
cc1: warning: '-fhardened' not supported for this target
gcc/testsuite/ChangeLog:
* gcc.target/i386/cf_check-6.c: Only run on Linux.
The new test at gcc.target/i386/pr112686.c fails on darwin with:
Excess errors:
cc1: error: '-fsplit-stack' currently only supported on GNU/Linux
cc1: error: '-fsplit-stack' is not supported by this compiler configuration
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr112686.c: Add a requirement for split_stack.
Re-check again RVV ISA, I find that we can't allow AVL propagation not only
for vrgather, but also slidedown instructions.
Committed.
PR target/112599
gcc/ChangeLog:
* config/riscv/riscv-avlprop.cc (avl_can_be_propagated_p): Add slidedown.
(vlmax_ta_p): Ditto.
(pass_avlprop::get_vlmax_ta_preferred_avl): Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/vf_avl-1.c: Adapt test.
* gcc.target/riscv/rvv/autovec/pr112599-3.c: New test.
r14-5628-g53ba8d669550d3 added noipa to f1 but `-fno-ipa-vrp` should have been used
instead. The testcase is testing about the clone of f1 so turning off
IPA VRP is the correct approach here rather than turning off of IPA on the function.
gcc/testsuite/ChangeLog:
PR testsuite/112691
* gcc.dg/vla-1.c: Add -fno-ipa-vrp.
Remove noipa from f1.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Just like the patch against gcc.target/aarch64/movk.c, the issue here
is the two functions, foo32 and foo64 needed to mark as noipa so that
IPA-VRP cannot propagate the return value.
gcc/testsuite/ChangeLog:
PR testsuite/112688
* gcc.target/aarch64/simd/vmulx.x (foo32): Mark as noipa rather
than noinline.
(foo4): Likewise.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Since contracts-tmpl-spec2.C is just testing contracts, I thought it would be better
to just add `-fsigned-char` to the options rather than change the testcase to support
both cases.
Committed after testing on aarch64-linux-gnu.
gcc/testsuite/ChangeLog:
PR testsuite/108321
* g++.dg/contracts/contracts-tmpl-spec2.C: Add -fsigned-char
to options.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
The problem here is dummy_number_generator returns a constant which IPA VRP is now able
propagate that so we need to mark the funciton as noipa to stop that.
gcc/testsuite/ChangeLog:
PR testsuite/112688
* gcc.target/aarch64/movk.c: Add noipa on dummy_number_generator
and remove -fno-inline option.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
FreeBSD 6 and 7 have been end of life for years as have been GCC 4.x
releases, so no point in detailing specifics of changes around those.
gcc:
PR target/69374
* doc/install.texi (Specific) <*-*-freebsd*>: Remove older
contents referencing GCC 4.x.
The following testcase is miscompiled in GCC 14 because the
*jcc_bt<mode>_mask and *jcc_bt<SWI48:mode>_mask_1 patterns have just
one argument in (match_operator 0 "bt_comparison_operator" [...])
but as bt_comparison_operator is eq,ne, we need two.
The md readers don't warn about it, after all, some checks can
be done in the predicate rather than specified explicitly, and the
behavior is that anything is accepted as the second argument.
I went through all other i386.md match_operator uses and all others
looked right (extract_operator using 3 operands, all others 2).
I think we'll want to fix this at different spots in older releases
because I think the bug was introduced already in 2008, though most
likely just latent.
2023-11-25 Jakub Jelinek <jakub@redhat.com>
PR target/111408
* config/i386/i386.md (*jcc_bt<mode>_mask,
*jcc_bt<SWI48:mode>_mask_1): Add (const_int 0) as expected
second operand of bt_comparison_operator.
* gcc.c-torture/execute/pr111408.c: New test.
The aarch64_simd_stp<mode> pattern uses w constraint in one alternative and
r in another, but for the latter incorrectly uses <vw> iterator in %<vw>1 which
expands to %d1 for V2DF and %s1 for V2SF and V4SF (this one not relevant to
the pattern) and %w1 for others, so it ICEs if the alternative is selected
during final. Compared to this, <vwcore> macro has the same values for all
modes but uses w for V2DF and V2SF.
2023-11-24 Andrew Pinski <pinskia@gmail.com>
Jakub Jelinek <jakub@redhat.com>
PR target/109977
* config/aarch64/aarch64-simd.md (aarch64_simd_stp<mode>): Use <vwcore>
rather than %<vw> for alternative with r constraint on input operand.
* gcc.dg/pr109977.c: New test.
Currently only functions are directly checked for validity when
exporting via a using-declaration. This patch also checks exporting
non-external names of variables, types, and enumerators. This also
prevents ICEs with `export using enum` for internal-linkage enums.
While we're at it this patch also improves the error messages for these
cases to provide more context about what went wrong.
gcc/cp/ChangeLog:
* name-lookup.cc (check_can_export_using_decl): New.
(do_nonmember_using_decl): Use above to check if names can be
exported.
gcc/testsuite/ChangeLog:
* g++.dg/modules/using-10.C: New test.
* g++.dg/modules/using-enum-2.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
A typedef doesn't create a new entity, and thus should be allowed to be
exported even if it has been previously declared un-exported. See the
example in [module.interface] p6:
export module M;
struct S { int n; };
typedef S S;
export typedef S S; // OK, does not redeclare an entity
PR c++/102341
gcc/cp/ChangeLog:
* decl.cc (duplicate_decls): Allow exporting a redeclaration of
a typedef.
gcc/testsuite/ChangeLog:
* g++.dg/modules/export-1.C: Adjust test.
* g++.dg/modules/export-2_a.C: New test.
* g++.dg/modules/export-2_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Since r14-2893, the frontend parser object needs to exist when running in
preprocess-only mode, because pragma_lex() is now called in that mode and
needs to make use of it. This is handled by calling c_init_preprocess() at
startup. If -fpch-preprocess is in effect (commonly, because of
-save-temps), a PCH file may be loaded during preprocessing, in which
case the parser will be destroyed, causing the issue noted in the
PR. Resolve it by reinitializing the frontend parser after loading the PCH.
gcc/c-family/ChangeLog:
PR pch/112319
* c-ppoutput.cc (cb_read_pch): Reinitialize the frontend parser
after loading a PCH.
gcc/testsuite/ChangeLog:
PR pch/112319
* g++.dg/pch/pr112319.C: New test.
* g++.dg/pch/pr112319.Hs: New test.
* gcc.dg/pch/pr112319.c: New test.
* gcc.dg/pch/pr112319.hs: New test.
64-bit Linux target has relocation issue and can't use 14-bit offsets.
2023-11-22 John David Anglin <danglin@gcc.gnu.org>
gcc/ChangeLog:
* config/pa/pa.cc (pa_emit_move_sequence): Use INT14_OK_STRICT
in a couple of places.
__relocate_a_1 is used to copy data after vector reizing. This can be done by memcpy
rather than memmove.
libstdc++-v3/ChangeLog:
PR middle-end/109849
* include/bits/stl_uninitialized.h (__relocate_a_1): Use memcpy instead
of memmove.
PR109849 shows that a loop that heavily pushes and pops from a stack
implemented by a C++ std::vec results in slow code, mainly because the
vector structure is not split by SRA and so we end up in many loads
and stores into it. This is because it is passed by reference
to (re)allocation methods and so needs to live in memory, even though
it does not escape from them and so we could SRA it if we
re-constructed it before the call and then separated it to distinct
replacements afterwards.
This patch does exactly that, first relaxing the selection of
candidates to also include those which are addressable but do not
escape and then adding code to deal with the calls. The
micro-benchmark that is also the (scan-dump) testcase in this patch
runs twice as fast with it than with current trunk. Honza measured
its effect on the libjxl benchmark and it almost closes the
performance gap between Clang and GCC while not requiring excessive
inlining and thus code growth.
The patch disallows creation of replacements for such aggregates which
are also accessed with a precision smaller than their size because I
have observed that this led to excessive zero-extending of data
leading to slow-downs of perlbench (on some CPUs). Apart from this
case I have not noticed any regressions, at least not so far.
Gimple call argument flags can tell if an argument is unused (and then
we do not need to generate any statements for it) or if it is not
written to and then we do not need to generate statements loading
replacements from the original aggregate after the call statement.
Unfortunately, we cannot symmetrically use flags that an aggregate is
not read because to avoid re-constructing the aggregate before the
call because flags don't tell which what parts of aggregates were not
written to, so we load all replacements, and so all need to have the
correct value before the call.
This version of the patch also takes care to avoid attempts to modify
abnormal edges, something which was missing in the previosu version.
gcc/ChangeLog:
2023-11-23 Martin Jambor <mjambor@suse.cz>
PR middle-end/109849
* tree-sra.cc (passed_by_ref_in_call): New.
(sra_initialize): Allocate passed_by_ref_in_call.
(sra_deinitialize): Free passed_by_ref_in_call.
(create_access): Add decl pool candidates only if they are not
already candidates.
(build_access_from_expr_1): Bail out on ADDR_EXPRs.
(build_access_from_call_arg): New function.
(asm_visit_addr): Rename to scan_visit_addr, change the
disqualification dump message.
(scan_function): Check taken addresses for all non-call statements,
including phi nodes. Process all call arguments, including the static
chain, build_access_from_call_arg.
(maybe_add_sra_candidate): Relax need_to_live_in_memory check to allow
non-escaped local variables.
(sort_and_splice_var_accesses): Disallow smaller-than-precision
replacements for aggregates passed by reference to functions.
(sra_modify_expr): Use a separate stmt iterator for adding satements
before the processed statement and after it.
(enum out_edge_check): New type.
(abnormal_edge_after_stmt_p): New function.
(sra_modify_call_arg): New function.
(sra_modify_assign): Adjust calls to sra_modify_expr.
(sra_modify_function_body): Likewise, use sra_modify_call_arg to
process call arguments, including the static chain.
gcc/testsuite/ChangeLog:
2023-11-23 Martin Jambor <mjambor@suse.cz>
PR middle-end/109849
* g++.dg/tree-ssa/pr109849.C: New test.
* g++.dg/tree-ssa/sra-eh-1.C: Likewise.
* gcc.dg/tree-ssa/pr109849.c: Likewise.
* gcc.dg/tree-ssa/sra-longjmp-1.c: Likewise.
* gfortran.dg/pr43984.f90: Added -fno-tree-sra to dg-options.
For -mcmodel=large, we have to load function address to a register.
PR target/112686
gcc/ChangeLog:
* config/i386/i386.cc (ix86_expand_split_stack_prologue): Load
function address to a register for ix86_cmodel == CM_LARGE.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr112686.c: New test.
The new warning has two purposes: First, it makes clearer to the
user that it is about OpenMP and, secondly and more importantly,
it permits to use -Wno-openmp.
The newly added -Wopenmp is enabled by default and replaces the
'0' (always warning) in several OpenMP-related warning calls.
For code shared with OpenACC, it only uses OPT_Wopenmp for
'flag_openmp | flag_openmp_simd'.
gcc/c-family/ChangeLog:
* c.opt (Wopenmp): Add, enable by default.
gcc/c/ChangeLog:
* c-parser.cc (c_parser_omp_clause_num_threads,
c_parser_omp_clause_num_tasks, c_parser_omp_clause_grainsize,
c_parser_omp_clause_priority, c_parser_omp_clause_schedule,
c_parser_omp_clause_num_teams, c_parser_omp_clause_thread_limit,
c_parser_omp_clause_dist_schedule, c_parser_omp_depobj,
c_parser_omp_scan_loop_body, c_parser_omp_assumption_clauses):
Add OPT_Wopenmp to warning_at.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_omp_clause_dist_schedule,
cp_parser_omp_scan_loop_body, cp_parser_omp_assumption_clauses,
cp_parser_omp_depobj): Add OPT_Wopenmp to warning_at.
* semantics.cc (finish_omp_clauses): Likewise.
gcc/ChangeLog:
* doc/invoke.texi (-Wopenmp): Add.
* gimplify.cc (gimplify_omp_for): Add OPT_Wopenmp to warning_at.
* omp-expand.cc (expand_omp_ordered_sink): Likewise.
* omp-general.cc (omp_check_context_selector): Likewise.
* omp-low.cc (scan_omp_for, check_omp_nesting_restrictions,
lower_omp_ordered_clauses): Likewise.
* omp-simd-clone.cc (simd_clone_clauses_extract): Likewise.
gcc/fortran/ChangeLog:
* lang.opt (Wopenmp): Add, enabled by dafault and documented in C.
* openmp.cc (gfc_match_omp_declare_target, resolve_positive_int_expr,
resolve_nonnegative_int_expr, resolve_omp_clauses,
gfc_resolve_omp_do_blocks): Use OPT_Wopenmp with gfc_warning{,_now}.
Prior to Armv6 there was no architected method to synchronize data
across processors. Armv6 saw the first introduction of
multi-processor support, using a CP15 operation; but this was
deprecated in Armv7 and is not supported on m-profile devices of any
form. Armv7 (and armv6-m) and later support data synchronization via
the DMB instruction.
This all leads to difficulties when linking programs as the user
generally needs to know which synchronization method is needed, but
there seems no easy way around this, when there are no OS-related
primitives available.
I've addressed this by adding multiple variants of __sync_synchronize
to libgcc, one for each of the above use cases. I've named these
__sync_synchronize_none, __sync_synchronize_cp15dmb and
__sync_synchronize_dmb. I've also added three specs files that can be
used to direct the linker to pick the appropriate implementation.
Using specs fragments for this is preferable to directing the user to
directly use --defsym as the latter has to be placed at the correct
position on the command line to be effective and the spec rule ensures
this automatically.
I've also added a default implementation of __sync_synchronize. The
default implementation will use DMB if that is available in the target
ISA, or fall back to a nul-implementation if it isn't. In the latter
case it will cause the linker (GNU LD) to emit a warning that
specifies how to pick a specific implementation. I've chosen not to
permit this default to use the CP15 solution as that has been
deprecated.
libgcc:
* config.host (arm*-*-eabi* | arm*-*-rtems*):
Add arm/t-sync to the makefile rules.
* config/arm/lib1funcs.S (__sync_synchronize_none)
(__sync_synchronize_cp15dmb, __sync_synchronize_dmb)
(__sync_synchronize): New functions.
* config/arm/t-sync: New file.
* config/arm/sync-none.specs: Likewise.
* config/arm/sync-dmb.specs: Likewise.
* config/arm/sync-cp15dmb.specs: Likewise.
Since OpenMP 5.2, the destroy clause takes an depend argument as argument;
for the depobj directive, it the new argument is optional but, if present,
it must be identical to the directive's argument.
gcc/c/ChangeLog:
* c-parser.cc (c_parser_omp_depobj): Accept optionally an argument
to the destroy clause.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_omp_depobj): Accept optionally an argument
to the destroy clause.
gcc/fortran/ChangeLog:
* openmp.cc (gfc_match_omp_depobj): Accept optionally an argument
to the destroy clause.
libgomp/ChangeLog:
* libgomp.texi (5.2 Impl. Status): An argument to the destroy clause
is now supported.
gcc/testsuite/ChangeLog:
* c-c++-common/gomp/depobj-3.c: New test.
* gfortran.dg/gomp/depobj-3.f90: New test.
By [basic.link] p3.2.1, a non-template non-volatile const-qualified
variable is not necessarily internal linkage in a module declaration,
and rather may have module linkage (or external linkage if it is
exported, see p4.8).
PR c++/99232
gcc/cp/ChangeLog:
* decl.cc (grokvardecl): Don't mark variables attached to
modules as internal.
gcc/testsuite/ChangeLog:
* g++.dg/modules/pr99232_a.C: New test.
* g++.dg/modules/pr99232_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
This patches 200+ ICEs exposed by testing with rv64gc_zve64d.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112694
The rootcause is we disallow poly (1,1) size vectorization in preferred_simd_mode.
with this following code:
- if (TARGET_MIN_VLEN < 128 && TARGET_MAX_LMUL < RVV_M2)
- return word_mode;
However, we allow poly (1,1) size in hook:
TARGET_VECTORIZE_RELATED_MODE
TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES
And also enables it in all vectorization patterns.
I was adding this into preferred_simd_mode because poly (1,1) size mode will cause
ICE in can_duplicate_and_interleave_p.
So, the alternative approach we need to block poly (1,1) size in both TARGET_VECTORIZE_RELATED_MODE
and TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES hooks and all vectorization patterns.
which is ugly approach and too much codes change.
Now, after investivation, I find it's nice that loop vectorizer can automatically block poly (1,1)
size vector in interleave vectorization with this commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=730909fa858bd691095bc23655077aa13b7941a9
So, we don't need to worry about ICE in interleave vectorization and allow poly (1,1) size vector
in vectorization which fixes 200+ ICEs in zve64d march.
PR target/112694
gcc/ChangeLog:
* config/riscv/riscv-v.cc (preferred_simd_mode): Allow poly_int (1,1) vectors.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr112694-1.c: New test.
Our system.h and configure.ac try to accommodate valgrind-3.1, but it is
more than 15 years old at this point. As Valgrind-based checking is a
developer-oriented feature, drop the compatibility stuff and streamline
the detection.
gcc/ChangeLog:
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Delete manual checks for old Valgrind headers.
* system.h (VALGRIND_MAKE_MEM_NOACCESS): Delete.
(VALGRIND_MAKE_MEM_DEFINED): Delete.
(VALGRIND_MAKE_MEM_UNDEFINED): Delete.
(VALGRIND_MALLOCLIKE_BLOCK): Delete.
(VALGRIND_FREELIKE_BLOCK): Delete.
When top-level configure has either --enable-checking=valgrind or
--enable-valgrind-annotations, we want to activate a couple of workarounds
in libcpp. They do not use anything from the Valgrind API, so just
delete all detection.
libcpp/ChangeLog:
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac (ENABLE_VALGRIND_CHECKING): Delete.
(ENABLE_VALGRIND_ANNOTATIONS): Rename to
ENABLE_VALGRIND_WORKAROUNDS. Delete Valgrind header checks.
* lex.cc (new_buff): Adjust for renaming.
(_cpp_free_buff): Ditto.
The following testcase ICEs, because cbranchv16qi4 expansion calls
ix86_expand_branch with op1 being a pre-AVX unaligned memory and
ix86_expand_branch emits a xorv16qi3 instruction without making sure
the operand predicates are satisfied.
While I could manually check if the argument (or both?) doesn't
match vector_operand predicate (apparently this one or bcst_vector_operand
is used in all integral 16+ bytes *xorv*3 instructions) force it into a
register, but as all gen_xorv*3 expanders call
ix86_expand_vector_logical_operator, it seems easier to just call that
function which ensures the right thing happens. Calling the individual
gen_xorv*3 functions would mean ugly switch on the modes and using high
level expand_simple_binop here seems too high level to me.
2023-11-24 Jakub Jelinek <jakub@redhat.com>
PR target/112681
* config/i386/i386-expand.cc (ix86_expand_branch): Use
ix86_expand_vector_logical_operator to expand vector XOR rather than
gen_rtx_SET on gen_rtx_XOR.
* gcc.target/i386/sse4-pr112681.c: New test.
This adds some helpers to access-utils.h for removing accesses from an
access_array. This is needed by the upcoming aarch64 load/store pair
fusion pass.
gcc/ChangeLog:
* rtl-ssa/access-utils.h (filter_accesses): New.
(remove_regno_access): New.
(check_remove_regno_access): New.
* rtl-ssa/accesses.cc (rtl_ssa::remove_note_accesses_base): Use
new filter_accesses helper.
The upcoming aarch64 load pair pass needs to form store pairs, and can
re-order stores over loads when alias analysis determines this is safe.
In the case that both mem defs have uses in the RTL-SSA IR, and both
stores require re-ordering over their uses, we represent that as
(tentative) deletion of the original store insns and creation of a new
insn, to prevent requiring repeated re-parenting of uses during the
pass. We then update all mem uses that require re-parenting in one go
at the end of the pass.
To support this, RTL-SSA needs to handle inserting new insns (rather
than just changing existing ones), so this patch adds support for that.
New insns (and new accesses) are temporaries, allocated above a temporary
obstack_watermark, such that the user can easily back out of a change without
awkward bookkeeping.
gcc/ChangeLog:
* rtl-ssa/accesses.cc (function_info::create_set): New.
* rtl-ssa/accesses.h (access_info::is_temporary): New.
* rtl-ssa/changes.cc (move_insn): Handle new (temporary) insns.
(function_info::finalize_new_accesses): Handle new/temporary
user-created accesses.
(function_info::apply_changes_to_insn): Ensure m_is_temp flag
on new insns gets cleared.
(function_info::change_insns): Handle new/temporary insns.
(function_info::create_insn): New.
* rtl-ssa/changes.h (class insn_change): Make function_info a
friend class.
* rtl-ssa/functions.h (function_info): Declare new entry points:
create_set, create_insn. Declare new change_alloc helper.
* rtl-ssa/insns.cc (insn_info::print_full): Identify temporary insns in
dump.
* rtl-ssa/insns.h (insn_info): Add new m_is_temp flag and accompanying
is_temporary accessor.
* rtl-ssa/internals.inl (insn_info::insn_info): Initialize m_is_temp to
false.
* rtl-ssa/member-fns.inl (function_info::change_alloc): New.
* rtl-ssa/movement.h (restrict_movement_for_defs_ignoring): Add
handling for temporary defs.
The following testcase is lowered by the bitint lowering pass, then
vectorizer vectorizes one of the loops in it, so we have
vect__18.6_34 = VIEW_CONVERT_EXPR<vector(4) unsigned long>(x_35(D));
_8 = BIT_FIELD_REF <vect__18.6_34, 64, 0>;
...
_18 = BIT_FIELD_REF <vect__18.6_34, 64, 64>;
etc. where x_35(D) is _BitInt(256) argument. That is valid BIT_FIELD_REF,
the first argument is a vector and it extracts the vector elements from it.
Then comes forwprop4 and simplifies that using match.pd into
_8 = (unsigned long) x_35(D);
...
_18 = BIT_FIELD_REF <x_35(D), 64, 64>;
and tree-cfg verification ICEs on the latter (though, even the first cast
is kind of undesirable after bitint lowering, we want large/huge bitints
lowered). The ICE is because if BIT_FIELD_REFs first argument has
INTEGRAL_TYPE_P, we require type_has_mode_precision_p, but that is not the
case of _BitInt(256), it has BLKmode.
The following patch fixes it by doing the BIT_FIELD_REF with VCE to
BIT_FIELD_REF simplification only if the result is valid.
2023-11-24 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/112673
* match.pd (bit_field_ref (vce @0) -> bit_field_ref @0): Only simplify
if either @0 doesn't have scalar integral type or if it has mode
precision.
* gcc.dg/pr112673.c: New test.
The bitint lowering pass only does something if it sees BITINT_TYPE (medium,
large, huge) SSA_NAMEs. In the past I've already ran into one special case
where the above doesn't work well, if there is a store of medium/large/huge
BITINT_TYPE INTEGER_CST into memory, there might not be any BITINT_TYPE
SSA_NAMEs in the function, yet we need to lower. This has been solved by
also checking for SSA_NAME_IS_VIRTUAL_OPERAND if at the vdef there isn't
such a store (the whole intent is make the pass as cheap as possible in the
currently very likely case that the IL doesn't have any BITINT_TYPEs at
all).
And the following testcase shows a similar problem. With -frounding-math
we don't fold some of FLOAT_EXPRs with INTEGER_CST operands, and if those
INTEGER_CSTs are medium/large/huge BITINT_TYPEs, we need to either cast
the INTEGER_CST to corresponding INTEGER_TYPE (for medium) or lower to
internal fn call which is later turned into libgcc call (for large/huge).
The following patch does that, but of course admittedly this discovery
of stores and FLOAT_EXPRs means we already look through quite a few
SSA_NAME_DEF_STMTs even when BITINT_TYPEs never appear.
2023-11-23 Jakub Jelinek <jakub@redhat.com>
PR middle-end/112679
* gimple-lower-bitint.cc (gimple_lower_bitint): Also stop first loop on
floating point SSA_NAME set in FLOAT_EXPR assignment from BITINT_TYPE
INTEGER_CST. Set has_large_huge for those if that BITINT_TYPE is large
or huge. Set kind to such FLOAT_EXPR assignment rhs1 BITINT_TYPE's kind.
* gcc.dg/bitint-42.c: New test.
