Fortran version of commit r15-6178-g2cbb2408a830a6 for C/C++.
However, the has_device_addr clause on dispatch only becomes really
useful (for C++ and Fortran) once the 'need_device_addr' modifier
to declare variant's 'adjust_args' clause is supported (i.e. with
a future commit).
gcc/fortran/ChangeLog:
* openmp.cc (OMP_DISPATCH_CLAUSES): Add OMP_CLAUSE_HAS_DEVICE_ADDR.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/adjust-args-10.f90: New test.
This patch adds support for the `dispatch` construct and the `adjust_args`
clause to the Fortran front-end.
Handling of `adjust_args` across translation units is missing due to PR115271.
Minor modifications to the C++ FE and the ME are also folded into this patch as
a side effect of the Fortran work.
gcc/c-family/ChangeLog:
* c-attribs.cc: (c_common_gnu_attributes): Rename "omp declare variant
variant adjust_args" into "omp declare variant variant args" to also
accommodate append_args.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_omp_dispatch): Handle INDIRECT_REF.
gcc/fortran/ChangeLog:
* dump-parse-tree.cc (show_omp_clauses): Handle novariants and nocontext
clauses.
(show_omp_node): Handle EXEC_OMP_DISPATCH.
(show_code_node): Likewise.
* frontend-passes.cc (gfc_code_walker): Handle novariants and nocontext.
* gfortran.h (enum gfc_statement): Add ST_OMP_DISPATCH.
(symbol_attribute): Add omp_declare_variant_need_device_ptr.
(gfc_omp_clauses): Add novariants and nocontext.
(gfc_omp_declare_variant): Add need_device_ptr_arg_list.
(enum gfc_exec_op): Add EXEC_OMP_DISPATCH.
* match.h (gfc_match_omp_dispatch): Declare.
* openmp.cc (gfc_free_omp_clauses): Free novariants and nocontext
clauses.
(gfc_free_omp_declare_variant_list): Free need_device_ptr_arg_list
namelist.
(enum omp_mask2): Add OMP_CLAUSE_NOVARIANTS and OMP_CLAUSE_NOCONTEXT.
(gfc_match_omp_clauses): Handle OMP_CLAUSE_NOVARIANTS and
OMP_CLAUSE_NOCONTEXT.
(OMP_DISPATCH_CLAUSES): Define.
(gfc_match_omp_dispatch): New function.
(gfc_match_omp_declare_variant): Parse adjust_args.
(resolve_omp_clauses): Handle adjust_args, novariants and nocontext.
Adjust handling of OMP_LIST_IS_DEVICE_PTR.
(icode_code_error_callback): Handle EXEC_OMP_DISPATCH.
(omp_code_to_statement): Likewise.
(resolve_omp_dispatch): New function.
(gfc_resolve_omp_directive): Handle EXEC_OMP_DISPATCH.
* parse.cc (decode_omp_directive): Match dispatch.
(next_statement): Handle ST_OMP_DISPATCH.
(gfc_ascii_statement): Likewise.
(parse_omp_dispatch): New function.
(parse_executable): Handle ST_OMP_DISPATCH.
* resolve.cc (gfc_resolve_blocks): Handle EXEC_OMP_DISPATCH.
* st.cc (gfc_free_statement): Likewise.
* trans-decl.cc (create_function_arglist): Declare.
(gfc_get_extern_function_decl): Call it.
* trans-openmp.cc (gfc_trans_omp_clauses): Handle novariants and
nocontext.
(replace_omp_dispatch_call): New function.
(gfc_trans_omp_dispatch): New function.
(gfc_trans_omp_directive): Handle EXEC_OMP_DISPATCH.
(gfc_trans_omp_declare_variant): Handle adjust_args.
* trans.cc (trans_code): Handle EXEC_OMP_DISPATCH:.
gcc/ChangeLog:
* gimplify.cc (gimplify_call_expr): Fix handling of need_device_ptr for
type(c_ptr). Fix handling of nested function calls in a dispatch region.
(find_ifn_gomp_dispatch): Return the IFN without stripping it.
(gimplify_omp_dispatch): Keep IFN_GOMP_DISPATCH until
gimplify_call_expr.
libgomp/ChangeLog:
* testsuite/libgomp.fortran/declare-variant-2-aux.f90: New test.
* testsuite/libgomp.fortran/declare-variant-2.f90: New test (xfail).
* testsuite/libgomp.fortran/dispatch-1.f90: New test.
* testsuite/libgomp.fortran/dispatch-2.f90: New test.
* testsuite/libgomp.fortran/dispatch-3.f90: New test.
gcc/testsuite/ChangeLog:
* g++.dg/gomp/dispatch-3.C: Update scan dumps.
* gfortran.dg/gomp/declare-variant-2.f90: Update dg-error.
* gfortran.dg/gomp/adjust-args-1.f90: New test.
* gfortran.dg/gomp/adjust-args-2.f90: New test.
* gfortran.dg/gomp/adjust-args-2a.f90: New test.
* gfortran.dg/gomp/adjust-args-3.f90: New test.
* gfortran.dg/gomp/adjust-args-4.f90: New test.
* gfortran.dg/gomp/adjust-args-5.f90: New test.
* gfortran.dg/gomp/adjust-args-6.f90: New test.
* gfortran.dg/gomp/adjust-args-7.f90: New test.
* gfortran.dg/gomp/adjust-args-8.f90: New test.
* gfortran.dg/gomp/adjust-args-9.f90: New test.
* gfortran.dg/gomp/dispatch-1.f90: New test.
* gfortran.dg/gomp/dispatch-2.f90: New test.
* gfortran.dg/gomp/dispatch-3.f90: New test.
* gfortran.dg/gomp/dispatch-4.f90: New test.
* gfortran.dg/gomp/dispatch-5.f90: New test.
* gfortran.dg/gomp/dispatch-6.f90: New test.
* gfortran.dg/gomp/dispatch-7.f90: New test.
* gfortran.dg/gomp/dispatch-8.f90: New test.
* gfortran.dg/gomp/dispatch-9.f90: New test.
* gfortran.dg/gomp/dispatch-9a.f90: New test.
* gfortran.dg/gomp/dispatch-10.f90: New test.
Changed in v2:
- distinguish between "bool" and "_Bool" when determining
standard version
This patch attempts to provide better error messages for
code compiled with C23 that hasn't been updated for
"bool", "true", and "false" becoming keywords.
Specifically:
(1) with "typedef int bool;" previously we emitted:
t1.c:7:13: error: two or more data types in declaration specifiers
7 | typedef int bool;
| ^~~~
t1.c:7:1: warning: useless type name in empty declaration
7 | typedef int bool;
| ^~~~~~~
whereas with this patch we emit:
t1.c:7:13: error: 'bool' cannot be defined via 'typedef'
7 | typedef int bool;
| ^~~~
t1.c:7:13: note: 'bool' is a keyword with '-std=c23' onwards
t1.c:7:1: warning: useless type name in empty declaration
7 | typedef int bool;
| ^~~~~~~
(2) with "int bool;" previously we emitted:
t2.c:7:5: error: two or more data types in declaration specifiers
7 | int bool;
| ^~~~
t2.c:7:1: warning: useless type name in empty declaration
7 | int bool;
| ^~~
whereas with this patch we emit:
t2.c:7:5: error: 'bool' cannot be used here
7 | int bool;
| ^~~~
t2.c:7:5: note: 'bool' is a keyword with '-std=c23' onwards
t2.c:7:1: warning: useless type name in empty declaration
7 | int bool;
| ^~~
(3) with "typedef enum { false = 0, true = 1 } _Bool;" previously we
emitted:
t3.c:7:16: error: expected identifier before 'false'
7 | typedef enum { false = 0, true = 1 } _Bool;
| ^~~~~
t3.c:7:38: error: expected ';', identifier or '(' before '_Bool'
7 | typedef enum { false = 0, true = 1 } _Bool;
| ^~~~~
t3.c:7:38: warning: useless type name in empty declaration
whereas with this patch we emit:
t3.c:7:16: error: cannot use keyword 'false' as enumeration constant
7 | typedef enum { false = 0, true = 1 } _Bool;
| ^~~~~
t3.c:7:16: note: 'false' is a keyword with '-std=c23' onwards
t3.c:7:38: error: expected ';', identifier or '(' before '_Bool'
7 | typedef enum { false = 0, true = 1 } _Bool;
| ^~~~~
t3.c:7:38: warning: useless type name in empty declaration
gcc/c/ChangeLog:
PR c/117629
* c-decl.cc (declspecs_add_type): Special-case attempts to use
bool as a typedef name or declaration name.
* c-errors.cc (get_std_for_keyword): New.
(add_note_about_new_keyword): New.
* c-parser.cc (report_bad_enum_name): New, split out from...
(c_parser_enum_specifier): ...here, adding handling for RID_FALSE
and RID_TRUE.
* c-tree.h (add_note_about_new_keyword): New decl.
gcc/testsuite/ChangeLog:
PR c/117629
* gcc.dg/auto-type-2.c: Update expected output with _Bool.
* gcc.dg/c23-bool-errors-1.c: New test.
* gcc.dg/c23-bool-errors-2.c: New test.
* gcc.dg/c23-bool-errors-3.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
The test was failing on x86 because longdouble128 only checks sizeof,
rather than a full 128-bit payload. Using _Float128 is more portable
and still exposes the original bug.
gcc/testsuite/
PR target/118184
* gcc.dg/torture/pr118184.c: Use _Float128 instead of long double.
PRE applies GENERIC folding to some component ref components which
might result in invalid GIMPLE, like a VIEW_CONVERT_EXPR wrapping
a REALPART_EXPR as in the PR. The following removes all GENERIC
folding in the code re-constructing a GENERIC component-ref from
the PRE VN IL.
PR tree-optimization/118171
* tree-ssa-pre.cc (create_component_ref_by_pieces_1): Do not
fold any component ref parts.
* gcc.dg/torture/pr118171.c: New testcase.
REGMODE_NATURAL_SIZE is set to 64 bits for everything except
VLA SVE modes. This means that it's possible to modify (say)
the highpart of a TI pseudo or a V2DI pseudo independently
of the lowpart. Modifying such highparts requires a reload
if the highpart ends up in the upper 64 bits of an FPR,
since RTL semantics do not allow the highpart of a single
hard register to be modified independently of the lowpart.
early-ra missed a check for this case, which meant that it
effectively treated an assignment to (subreg:DI (reg:TI R) 0)
as an assignment to the whole of R.
gcc/
PR target/118184
* config/aarch64/aarch64-early-ra.cc (allocno_assignment_is_rmw):
New function.
(early_ra::record_insn_defs): Mark the live range information as
untrustworthy if an assignment would change part of an allocno
but preserve the rest.
gcc/testsuite/
* gcc.dg/torture/pr118184.c: New test.
In order to stress test RAW_DATA_CST handling, I've tested trunk gcc with
r15-6339 reapplied and a hack where I've changed
const unsigned int raw_data_min_len = 128;
to
const unsigned int raw_data_min_len = 2;
in cp_lexer_new_main and 64 to 4 several times in c_parser_initval
and c_maybe_optimize_large_byte_initializer, so that RAW_DATA_CST doesn't
trigger just on very large initializers, but even quite small ones.
One of the regressions (will work on the others next) was that pr90838.c
testcase regressed, check_ctz_array needs to handle RAW_DATA_CST, otherwise
on larger initializers or if those come from #embed just won't trigger.
The new testcase shows when it doesn't trigger anymore (regression from 14).
The patch just handles RAW_DATA_CST in the CONSTRUCTOR_ELTS the same as is
it was a series of INTEGER_CSTs.
2025-01-02 Jakub Jelinek <jakub@redhat.com>
* tree-ssa-forwprop.cc (check_ctz_array): Handle also RAW_DATA_CST
in the CONSTRUCTOR_ELTS.
* gcc.dg/pr90838-2.c: New test.
libgdiagnostics/conf.py breaks update-copyright.py --this-year,
which only accepts copyright year in u'' literals in python files,
not in ''.
2025-01-02 Jakub Jelinek <jakub@redhat.com>
* doc/libgdiagnostics/conf.py: Use u'' instead of '' in
project and copyright initialization.
When running update-copyright.py --this-year, I've encountered various
failures, this patch works around those.
2025-01-02 Jakub Jelinek <jakub@redhat.com>
* update-copyright.py (GCCFilter): Ignore gen-evolution.awk and
gen-cxxapi-file.py.
(TestsuiteFilter): Ignore spec-example-4.sarif.
(LibCppFilter): Ignore uname2c.h.
The optimization example is as follows.
From:
if (condition)
dest += 1 << 16;
To:
dest += (condition ? 1 : 0) << 16;
It does not use maskeqz and masknez, thus reducing the number of
instructions.
gcc/ChangeLog:
* config/loongarch/loongarch.cc
(loongarch_expand_conditional_move): Add some optimization
implementations based on noce_try_cmove_arith.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/conditional-move-opt-1.c: New test.
* gcc.target/loongarch/conditional-move-opt-2.c: New test.
For some instruction patterns with commutative operands,
the order of operands needs to be adjusted to match the rules.
gcc/ChangeLog:
* config/loongarch/loongarch.md
(bytepick_d_<bytepick_imm>_rev): New combiner.
(bstrpick_alsl_paired): Reorder input operands.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/bstrpick_alsl_paired.c: New test.
* gcc.target/loongarch/bytepick_combine.c: New test.
There are two aspects that affect the matching of instruction templates:
1. vec_duplicate is redundant in the following operations.
set (match_operand:V4DI ...)
(vec_duplicate:V4DI (vec_select:V4DI ...))
2. The range of values for testing predicate const_8_to_15_operand and
const_16_to_31_operand should be [8, 15] and [16, 31] respectively.
However, there is currently no suitable testcase to verify.
gcc/ChangeLog:
* config/loongarch/lasx.md: Remove useless vec_select.
* config/loongarch/predicates.md: Correct error predicate.
The xvexth related instructions operate SEPARATELY according to
the high and low 128 bits, and sign/zero extend the upper half
of every 128 bits in src to the corresponding 128 bits in dest.
For xvexth.d.w, the rule for the first element of dest should be:
dest.D[0] = sign_extend (src.W[2] ,64);
instead of:
dest.D[0] = sign_extend (src.W[4] ,64);
gcc/ChangeLog:
* config/loongarch/lasx.md: Fix selector index.
The following avoids applying TER to direct internal functions that
are tailcall since the involved expansion code path doesn't honor
TER constraints.
PR middle-end/118174
* tree-outof-ssa.cc (ssa_is_replaceable_p): Exclude tailcalls.
* gcc.dg/torture/pr118174.c: New testcase.
In English usage, "that" introduces a restrictive clause while "which"
introduces a non-restrictive or descriptive clause. "That" is almost
never preceded by a comma while "which" often is. The Fortran manual
had many instances where these uses were reversed, or where a comma
was used with "that"; this patch fixes them. In some cases I have
substituted less convoluted wording instead.
gcc/fortran/ChangeLog
* gfortran.texi: Clean up that/which usage throughout the file.
* intrinsic.texi: Likewise.
* invoke.texi: Likewise.
Continuing a series of patches to tidy the Fortran manual, this
installment fixes problems with inappropriate use of future tense and
adds some missing markup I noticed in passing.
gcc/fortran/ChangeLog
* intrinsic.texi: Grammar and markup fixes throughout
the file.
Per comments in invoke.texi, target option groups in the Option
Summary section are supposed to be alphabetized and in the same order
as the documentation sections they refer to. "M32C Options" was
misordered in the Option Summary. "Cygwin and MinGW Options" was
ordered incorrectly in both places, which also caused Texinfo
diagnostics because the ordering in the menu (which was correctly
alphabetized) didn't match the node order.
I also added a reference to the appropriate section to each entry in
the Option Summary so that you can go directly to the detailed
description for that set of target options. I'm not real happy with
the formatting of the tables in that section but the experiments I
tried all looked worse. :-(
gcc/ChangeLog
* doc/invoke.texi (Option Summary): Put "M32C Options" and
"Cygwin and MinGW Options" in alphabetical order. Add
cross-references.
(Cygwin and MinGW Options): Likewise move the section to its
correct alphabetical location.
* config/lynx.opt.urls: Regenerated.
* config/mingw/cygming.opt.urls: Regenerated.
In order to support vectorization of loops with multiple exits, this
patch adds the implementation of the conditional branch optab for
LoongArch LSX/LASX instructions.
This patch causes the gen-vect-{2,25}.c tests to fail. This is because
the support for vectorizing loops with multiple exits has vectorized
the loop checking the results. The failure is due to an issue in the
test case's own implementation.
gcc/ChangeLog:
* config/loongarch/simd.md (cbranch<mode>4): New expander.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp (check_effective_target_vect_early_break_hw,
check_effective_target_vect_early_break): Support LoongArch LSX.
* gcc.target/loongarch/vector/lasx/lasx-vseteqz.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vseteqz.c: New test.
Co-authored-by: Deng Jianbo <dengjianbo@loongson.cn>
optimize_constant_pool hashes vector masks by native_encode_rtx and
merges identically hashed values in the constant pool. Afterwards the
optimized values are written in output_constant_pool_2.
However, native_encode_rtx and output_constant_pool_2 disagree in their
encoding of vector masks: native_encode_rtx does not pad with zeroes
while output_constant_pool_2 implicitly does.
In RVV's shuffle-evenodd-run.c there are two masks
(a) "0101" for V4BI
(b) "01010101" for V8BI and
that have the same representation/encoding ("1010101") in native_encode_rtx.
output_constant_pool_2 uses "101" for (a) and "1010101" for (b).
Now, optimize_constant_pool might happen to merge both masks using
(a) as representative. Then, output_constant_pool_2 will output "1010"
which is only valid for the second mask as the implicit zero padding
doesn't agree with (b).
(b)'s "1010101" works for both masks as a V4BI load will ignore the last four
padding bits.
This patch makes output_constant_pool_2 use native_encode_rtx so both
functions will agree on an encoding and output the correct constant.
PR target/118036
gcc/ChangeLog:
* varasm.cc (output_constant_pool_2): Use native_encode_rtx for
building the memory image of a const vector mask.
Several months ago changes were made to the vectorizer which mucked up several
of the scan tests. All but one of the cases in pr115375 have since been fixed.
The remaining failure seems to be primarily a debugging dump issue -- we're
still selecting the same lmul values. This patch adjusts the dump scan
appropriately.
PR target/115375
gcc/testsuite
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-9.c: Adjust expected
output.
This is a minor testsuite adjustment
attr-complex-method-2.c selects between two scan-tree-dump clauses based on
avr, !avr. But what they really should be checking is "large_double" that way
it works for avr, h8, rl78 and any other target which makes doubles the same
size as floats.
attr-complex-method.c should be doing the same thing.
After this change avr passes attr-complex-method.c and the rl78 and h8 ports
will pass both tests. Other targets in my tester are unaffected.
PR testsuite/114182
gcc/testsuite/
* gcc.c-torture/compile/attr-complex-method.c: Use
"large_double" to select between scan outputs.
* gcc.c-torture/compile/attr-complex-method-2.c: Similarly.
This is a fix for a bug Andrew P filed a while back where essentially a poorly
crafted asm statement could trigger a ICE during assembly output. Various
cases will use INTVAL (op) without verifying the operand is a CONST_INT node
first.
The usual way to handle this is via output_operand_lossage, which this patch
implements.
I focused primarily on the CONST_INT cases, there could well be other problems
in this space, if so they should get distinct bugs with testcases.
Tested in my tester on rv32 and rv64. Waiting for pre-commit testing before
moving forward.
PR target/106544
gcc/
* config/riscv/riscv.cc (riscv_print_operand): Issue an error for
invalid operands rather than invalidly accessing INTVAL of an
object that is not a CONST_INT. Fix one error string for 'N'.
gcc/testsuite
* gcc.target/riscv/pr106544.c: New test.
Fortran 2023 has added the new intrinsic function F_C_STRING to
convert fortran strings of default character kind to a null
terminated C string.
Contributions from Steve Kargl, Harald Anlauf, FX Coudert, Mikael Morin,
and Jerry DeLisle.
PR fortran/117643
gcc/fortran/ChangeLog:
* check.cc (gfc_check_f_c_string): Check arguments of f_c_string().
* gfortran.h (enum gfc_isym_id): New symbol GFC_ISYM_F_C_STRING.
* intrinsic.cc (add_functions): Add the ISO C Binding routine f_c_string().
Wrap nearby long line to less than 80 characters.
* intrinsic.h (gfc_check_f_c_string): Prototype for gfc_check_f_c_string().
* iso-c-binding.def (NAMED_FUNCTION): Declare for ISO C Binding
routine f_c_string().
* primary.cc (gfc_match_rvalue): Fix comment that has been untrue since 2011.
Add ISOCBINDING_F_C_STRING to conditional.
* trans-intrinsic.cc (conv_trim): Specialized version of trim() for
f_c_string().
(gfc_conv_intrinsic_function): Use GFC_ISYM_F_C_STRING to trigger in-lining.
gcc/testsuite/ChangeLog:
* gfortran.dg/f_c_string1.f90: New test.
* gfortran.dg/f_c_string2.f90: New test.
The new pattern to optimize certain code sequences on RISC-V played things a
bit fast and loose with modes -- some operands were using the ALLI iterator
while the scratch used X and the split codegen used X.
Naturally under the "right" circumstances this would trigger an ICE due to
mismatched modes. This patch uses X consistently in that pattern. It also
fixes some formatting nits.
Tested in my tester, but waiting on the pre-commit verdict before moving
forward.
PR target/118122
gcc/
* config/riscv/riscv.md (lui_constraint<X:mode>_and_to_or): Use
X iterator rather than ANYI consistently. Fix formatting.
gcc/testsuite
* gcc.target/riscv/pr118122.c: New test.
This patch adds mf8 variants of what I'll loosely call the existing
"data movement" intrinsics, including the recent FEAT_LUT ones.
I think this completes the FP8 intrinsic definitions.
The new intrinsics are defined entirely in the compiler. This should
make it easy to move the existing non-mf8 variants into the compiler
as well, but that's too invasive for stage 3 and so is left to GCC 16.
I wondered about trying to reduce the cut-&-paste in the .def file,
but in the end decided against it. I have a plan for specifying this
information in a different format, but again that would need to wait
until GCC 16.
The patch includes some support for gimple folding. I initially
tested the patch without it, so that all the rtl expansion code
was exercised.
vlut.c fails for all types with big-endian ILP32, but that's
for a later patch.
gcc/
* config/aarch64/aarch64.md (UNSPEC_BSL, UNSPEC_COMBINE, UNSPEC_DUP)
(UNSPEC_DUP_LANE, UNSPEC_GET_LANE, UNSPEC_LD1_DUP, UNSPEC_LD1x2)
(UNSPEC_LD1x3, UNSPEC_LD1x4, UNSPEC_SET_LANE, UNSPEC_ST1_LANE)
(USNEPC_ST1x2, UNSPEC_ST1x3, UNSPEC_ST1x4, UNSPEC_VCREATE)
(UNSPEC_VEC_COPY): New unspecs.
* config/aarch64/iterators.md (UNSPEC_TBL): Likewise.
* config/aarch64/aarch64-simd-pragma-builtins.def: Add definitions
of the mf8 data movement intrinsics.
* config/aarch64/aarch64-protos.h
(aarch64_advsimd_vector_array_mode): Declare.
* config/aarch64/aarch64.cc
(aarch64_advsimd_vector_array_mode): Make public.
* config/aarch64/aarch64-builtins.h (qualifier_const_pointer): New
aarch64_type_qualifiers member.
* config/aarch64/aarch64-builtins.cc (AARCH64_SIMD_VGET_LOW_BUILTINS)
(AARCH64_SIMD_VGET_HIGH_BUILTINS): Add mf8 variants.
(aarch64_int_or_fp_type): Handle qualifier_modal_float.
(aarch64_num_lanes): New function.
(binary_two_lanes, load, load_lane, store, store_lane): New signatures.
(unary_lane): Likewise.
(simd_type::nunits): New member function.
(simd_types): Add pointer types.
(aarch64_fntype): Handle the new signatures.
(require_immediate_lane_index): Use aarch64_num_lanes.
(aarch64_pragma_builtins_checker::check): Handle the new intrinsics.
(aarch64_convert_address): (aarch64_dereference_pointer):
(aarch64_canonicalize_lane, aarch64_convert_to_lane_mask)
(aarch64_pack_into_v128s, aarch64_expand_permute_pair)
(aarch64_expand_tbl_tbx): New functions.
(aarch64_expand_pragma_builtin): Handle the new intrinsics.
(aarch64_force_gimple_val, aarch64_copy_vops, aarch64_fold_to_val)
(aarch64_dereference, aarch64_get_lane_bit_index, aarch64_get_lane)
(aarch64_set_lane, aarch64_fold_combine, aarch64_fold_load)
(aarch64_fold_store, aarch64_ext_index, aarch64_rev_index)
(aarch64_trn_index, aarch64_uzp_index, aarch64_zip_index)
(aarch64_fold_permute): New functions, some split out from
aarch64_general_gimple_fold_builtin.
(aarch64_gimple_fold_pragma_builtin): New function.
(aarch64_general_gimple_fold_builtin): Use the new functions above.
* config/aarch64/aarch64-simd.md (aarch64_dup_lane<mode>)
(aarch64_dup_lane_<vswap_width_name><mode>): Add "@" to name.
(aarch64_simd_vec_set<mode>): Likewise.
(*aarch64_simd_vec_copy_lane_<vswap_width_name><mode>): Likewise.
(aarch64_simd_bsl<mode>): Likewise.
(aarch64_combine<mode>): Likewise.
(aarch64_cm<optab><mode><vczle><vczbe>): Likewise.
(aarch64_simd_ld2r<vstruct_elt>): Likewise.
(aarch64_vec_load_lanes<mode>_lane<vstruct_elt>): Likewise.
(aarch64_simd_ld3r<vstruct_elt>): Likewise.
(aarch64_simd_ld4r<vstruct_elt>): Likewise.
(aarch64_ld1x3<vstruct_elt>): Likewise.
(aarch64_ld1x4<vstruct_elt>): Likewise.
(aarch64_st1x2<vstruct_elt>): Likewise.
(aarch64_st1x3<vstruct_elt>): Likewise.
(aarch64_st1x4<vstruct_elt>): Likewise.
(aarch64_ld<nregs><vstruct_elt>): Likewise.
(aarch64_ld1<VALL_F16: Likewise.mode>): Likewise.
(aarch64_ld1x2<vstruct_elt>): Likewise.
(aarch64_ld<nregs>_lane<vstruct_elt>): Likewise.
(aarch64_<PERMUTE: Likewise.perm_insn><mode><vczle><vczbe>): Likewise.
(aarch64_ext<mode>): Likewise.
(aarch64_rev<REVERSE: Likewise.rev_op><mode><vczle><vczbe>): Likewise.
(aarch64_st<nregs><vstruct_elt>): Likewise.
(aarch64_st<nregs>_lane<vstruct_elt>): Likewise.
(aarch64_st1<VALL_F16: Likewise.mode>): Likewise.
gcc/testsuite/
* gcc.target/aarch64/advsimd-intrinsics/arm-neon-ref.h: Add mfloat8
support.
* gcc.target/aarch64/advsimd-intrinsics/compute-ref-data.h: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vbsl.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcombine.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vcreate.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vdup-vmov.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vdup_lane.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vext.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vget_high.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vld1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vld1_dup.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vld1_lane.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vld1x2.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vld1x3.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vld1x4.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vldX.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vldX_dup.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vldX_lane.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vrev.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vset_lane.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vshuffle.inc: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vst1_lane.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vst1x2.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vst1x3.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vst1x4.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vstX_lane.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vtbX.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vtrn.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vtrn_half.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vuzp.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vuzp_half.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vzip.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vzip_half.c: Likewise.
* gcc.target/aarch64/simd/lut.c: Likewise.
* gcc.target/aarch64/vdup_lane_1.c: Likewise.
* gcc.target/aarch64/vdup_lane_2.c: Likewise.
* gcc.target/aarch64/vdup_n_1.c: Likewise.
* gcc.target/aarch64/vect_copy_lane_1.c: Likewise.
* gcc.target/aarch64/simd/mf8_data_1.c: New test.
* gcc.target/aarch64/simd/mf8_data_2.c: Likewise.
Co-authored-by: Saurabh Jha <saurabh.jha@arm.com>
The intrinsic type suffix for modal floating-point types is _mf8,
so it's more convenient if we use that for the simd_types as well.
gcc/
* config/aarch64/aarch64-builtins.cc (simd_types::f8): Rename to...
(simd_types::mf8): ...this.
* config/aarch64/aarch64-simd-pragma-builtins.def: Update accordingly.
This patch tries to regularise the definitions of the new pragma
simd types. Not all of the new types are currently used, but they
will be by later patches.
gcc/
* config/aarch64/aarch64-builtins.cc (simd_types): Use one macro
invocation for each element type.
In a later patch, I need to add "@" to a pattern that uses subst
attributes. This combination is problematic for two reasons:
(1) define_substs are applied and filtered at a later stage than the
handling of "@" patterns, so that the handling of "@" patterns
doesn't know which subst variants are valid and which will later be
dropped. Just adding a "@" therefore triggers a build error due to
references to non-existent patterns.
(2) Currently, the code will treat a single "@" pattern as contributing
to a single set of overloaded functions. These overloaded functions
will have an integer argument for every subst attribute. For example,
the vczle and vczbe in:
"@aarch64_rev<REVERSE:rev_op><mode><vczle><vczbe>"
are subst attributes, and so currently we'd try to generate a
single set of overloads that take four arguments: one for rev_op,
one for the mode, one for vczle, and one for vczbe. The gen_*
and maybe_gen_* functions will also have one rtx argument for
each operand in the original pattern.
This model doesn't really make sense for define_substs, since
define_substs are allowed to add extra operands to an instruction.
The number of rtx operands to the generators would then be
incorrect.
I think a more sensible way of handling define_substs would be to
apply them first (and thus expand things like <vczle> and <vczbe>
above) and then apply "@". However, that's a relatively invasive
change and not suitable for stage 3.
This patch instead skips over subst attributes and restricts "@"
overload handling to the cases where no define_subst is applied.
I looked through all uses of "@" names in target code and there
seemed to be only one current use of "@" with define_substs,
in x86 vector code. The current behaviour seemed to be unwanted there,
and the x86 code was having to work around it.
gcc/
* read-rtl.cc (md_reader::handle_overloaded_name): Don't add
arguments for uses of subst attributes.
(apply_iterators): Only add instructions to an overloaded helper
if they use the default subst iterator values.
* doc/md.texi: Update documentation accordingly.
* config/i386/i386-expand.cc (expand_vec_perm_broadcast_1): Update
accordingly.
During the initialization of the base register for the zero-offset
store, in the case that we are eliminating the load, we used a
paradoxical subreg assuming that we don't care about the higher bits
of the register. This led to writing wrong values when we were not
updating the whole register.
This patch fixes the issue by zero-extending the value stored in the
base register instead of using a paradoxical subreg.
Bootstrapped/regtested on x86 and AArch64.
PR rtl-optimization/117835
PR rtl-optimization/117872
gcc/ChangeLog:
* avoid-store-forwarding.cc
(store_forwarding_analyzer::process_store_forwarding):
Zero-extend the value stored in the base register instead of
using a paradoxical subreg.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr117835.c: New test.
This commit fixes a MMIX C23 (...)-handling bug; failing
gcc.dg/c23-stdarg-[46789].c execution tests. But, this
isn't about a missing "|| arg.type != NULL_TREE" in the
PORT_setup_incoming_varargs function like most other
PR114175 port bugs exposed by the gcc.dg/c23-stdarg-6.c
.. -9.c tests; the MMIX port passes struct-return-values in
a register. But, the bug is somewhat similar.
This bug seems like it was added already in
r13-3549-g4fe34cdcc80ac2, by incorrectly handling
TYPE_NO_NAMED_ARGS_STDARG_P-functions ((...)-functions);
counting them as having one parameter instead of none. That
"+ 1" below is a kind-of hidden function_arg_advance call,
which shouldn't happen for (...)-functions.
PR target/117618
* config/mmix/mmix.cc (mmix_setup_incoming_varargs):
Correct handling of C23 (...)-functions.
Prior to r15-6001, reduction_phi() could be called with the PHI parameter
not actually being a gphi*. The search through reduction_list would fail and
return NULL. r15-6001 added a requirement that PHI actually be a gphi*, but
did not add a check for this. The PR shows an example where the check is
needed; fix by explicitly returning NULL in this case.
gcc/ChangeLog:
PR tree-optimization/118205
* tree-parloops.cc (reduction_phi): Return NULL if PHI parameter is
not a phi node.
gcc/testsuite/ChangeLog:
PR tree-optimization/118205
* c-c++-common/pr118205.c: New test.
