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.
So for this bug we have what appears to me to just be a bogus pattern.
Essentially the pattern tries to detect cases where we have an SI mode value
and we can use the Zbs instructions to manipulate a bit. Conceptually that's
great.
The problem is the pattern assumes that SI objects are sign extended. It uses a
test to try and filter out a problematical case (subregs), but that simply
won't work with late-combine since the subreg will be stripped away and we have
no way of knowing if the SI value was already sign extended to 64 bits or not.
You might think we could look for a way to salvage the pattern and make it only
usable prior to register allocation. I pondered that extensively, but
ultimately concluded that with the introduction of ext-dce it wasn't safe.
So this just removes the problematical pattern. Thankfully there aren't any
regressions in the testsuite. Even the test designed to test this pattern's
applicability still generates the desired code.
Changes since v1:
- Adjust testcase so that it works for rv32 and rv64.
- Adjust PR number in subject line.
PR target/116715
gcc/
* config/riscv/bitmanip.md: Drop bogus pattern.
gcc/testsuite
* gcc.target/riscv/pr116715.c: New test.
So this BZ is a case where we incorrectly indicated that the operand array was
suitable for the t-head load/store pair instructions.
In particular there's a test which checks alignment, but that happens *before*
we know if the operands are going to be reversed. So the routine reported the
operands are suitable.
At a later point the operands have been reversed into the proper order and we
realize the alignment test should have failed, resulting in the unrecognized
insn.
This fixes the code by moving the reversal check earlier and actually swapping
the local variables with the operands. That in turn allows for simpler testing
of alignments, ordering, etc.
I've tested this on rv32 and rv64 in my tester. I don't offhand know if the
patch from Filip that's been causing headaches for the RISC-V port has been
reverted/fixed. So there's a nonzero chance the pre-commit CI tester will
fail. I'll keep an eye on it and act appropriately.
PR target/116720
gcc/
* config/riscv/thead.cc (th_mempair_operands_p): Test for
aligned memory after swapping operands. Simplify test for
first memory access as well.
gcc/testsuite/
* gcc.target/riscv/pr116720.c: New test.
Commit 544be2beb1 in 2019 remove Profile Mode and associated docs
including the XML version of profile_mode_diagnostics.html. Somehow
the latter survived until now. Simply delete it as well.
libstdc++-v3:
* doc/html/manual/profile_mode_diagnostics.html: Delete.
These two long-running tests happened to fail for me when
run in parallel (nprocs - 1) compared to a serial run, for
target mmix on my laptop. The runtime is 3m40s for 3.cc
before this change, and 0.9s afterwards.
* testsuite/std/time/year_month_day/3.cc (test01): Add ifdeffery to
limit the tested dates. For simulators, pass start and end dates
limiting the tested range to 100000 days, centered on days (0).
* testsuite/std/time/year_month_day/4.cc: Ditto.
Depending on the libc and filesystem, in cases where posix_fallocate
cannot do an efficient preallocation it may return EINVAL. In such a
case we should fall back to ftruncate instead.
Apparently, depending on the system the use of posix_fallocate can have
a noticeable speedup over ftruncate in general (depending on the system)
so it probably isn't worth it to use ftruncate in all cases.
PR c++/100358
PR c++/115008
gcc/cp/ChangeLog:
* module.cc (elf_out::create_mapping): Fallback to ftruncate if
posix_fallocate fails.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
I noticed that in a couple of places we sometimes treat any TYPE_DECL of
lambda type as defining a lambda, which isn't always true since C++20:
in `using T = decltype([]{})`, T is not a lambda-declaration.
PR c++/106221
PR c++/110680
gcc/cp/ChangeLog:
* pt.cc (check_default_tmpl_args): Check this is actually a
lambda declaration and not just a typedef.
(push_template_decl): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-uneval19.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
The following testcases ICE because fold_array_ctor_reference in the
RAW_DATA_CST handling just return build_int_cst without actually checking
that if type is non-NULL, TREE_TYPE (val) is uselessly convertible to it.
By falling through the code after it without *suboff += we get everything
we need, the two if conditionals will never be true (we've already
checked that size == BITS_PER_UNIT and so can't be 0, and val will be
INTEGER_CST), but it will do the important fold_ctor_reference call
which will deal with type incompatibilities.
2024-12-28 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/118207
* gimple-fold.cc (fold_array_ctor_reference): For RAW_DATA_CST,
just set val to build_int_cst and fall through to the normal
element handling code instead of returning build_int_cst right away.
* gcc.dg/pr118207.c: New test.
The test used #include "<generator>", so FAILed everywhere with
fatal error: <generator>: No such file or directory
2024-12-28 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/118196
* testsuite/24_iterators/range_generators/pr118196.cc: Include
<generator> rather than "<generator>".
This overload requires
constructible_from<remove_cvref_t<yielded>,
const remove_reference_t<yielded>&>
... but then tries to construct remove_cvref_t<yielded> implicitly,
which means it imposes an additional constraint not in the standard.
libstdc++-v3/ChangeLog:
PR libstdc++/118022
* include/std/generator
(_Promise_erased::yield_value(const _Yielded_deref&)): Don't
implicit-constuct _Yielded_decvref.
* testsuite/24_iterators/range_generators/pr118022.cc: New test.
We can't vectorize the code into instructions like vslti.w that compare
with immediate_operand, because we miss immediate_operand support for
integer comparisons.
gcc/ChangeLog:
* config/loongarch/lasx.md (vec_cmp<mode><mode256_i>): Remove.
(vec_cmpu<ILASX:mode><mode256_i>): Remove.
* config/loongarch/loongarch.cc (loongarch_expand_lsx_cmp):
Ensure vector comparison instructions support CMP_OP1.
* config/loongarch/lsx.md (vec_cmp<mode><mode_i>): Remove.
(vec_cmpu<ILSX:mode><mode_i>): Remove.
* config/loongarch/simd.md (ALLVEC, allmode_i): New mode iterators.
(vec_cmp<mode><allmode_i>): New define_expand.
(vec_cmpu<mode><allmode_i>): Likewise.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/vector/lasx/lasx-vcond-3.c: New test.
2024-12-26 John David Anglin <danglin@gcc.gnu.org>
gcc/ChangeLog:
PR target/118050
* timevar.cc (get_time): Only use CLOCK_MONOTONIC if
'_POSIX_TIMERS > 0 && defined(_POSIX_MONOTONIC_CLOCK)'.
Otherise, use CLOCK_REALTIME.
We hardly ever emit code using machine instructions for aligned memory
accesses for block move and clear operation and the reason for this
appears to be that suboptimal alignment is often passed by the caller
and then we only try to find a better alignment by checking pseudo
register pointer alignment information, and from observation it's most
often only set for stack frame references.
This code originates from before Tree SSA days and we can do better
nowadays, by looking up the original tree node associated with a MEM
RTL, so implement this approach, factoring out repeating code from
`alpha_expand_block_move' and `alpha_expand_block_clear' to a new
function.
In some cases howewer tree information is not available while pointer
alignment is, such as with the case concerned with PR target/115459,
where we have:
(gdb) pr orig_src
(mem:BLK (plus:DI (reg/f:DI 65 virtual-stack-vars [ lock.206_2 ])
(const_int 8368 [0x20b0])) [8 S18 A8])
(gdb) pr orig_dst
(mem/j/c:BLK (plus:DI (reg/f:DI 65 virtual-stack-vars [ lock.206_2 ])
(const_int 8208 [0x2010])) [8 MEM[(struct gnat__debug_pools__print_info_stdout__internal__L_18__B1182b__S1183b___PAD *)_339].F[1 ...]{lb: 1 sz: 1}+0 S18 A128])
(gdb)
showing no tree information and the alignment of 8 only for `orig_src',
while indeed REGNO_POINTER_ALIGN returns 128 for pseudo 65. So retain
the old approach and return the largest alignment determined and its
associated offset.
Add test cases accordingly and remove XFAILs from memclr-a2-o1-c9-ptr.c
now that it does get aligned code produced now.
gcc/
* config/alpha/alpha.cc
(alpha_get_mem_rtx_alignment_and_offset): New function.
(alpha_expand_block_move, alpha_expand_block_clear): Use it for
alignment retrieval.
gcc/testsuite/
* gcc.target/alpha/memclr-a2-o1-c9-ptr.c: Remove XFAILs.
* gcc.target/alpha/memcpy-di-aligned.c: New file.
* gcc.target/alpha/memcpy-di-unaligned.c: New file.
* gcc.target/alpha/memcpy-di-unaligned-dst.c: New file.
* gcc.target/alpha/memcpy-di-unaligned-src.c: New file.
Correct the offset adjustment made in the multi-word unaligned access
helpers such that it is actually used by the unaligned load and store
instructions, fixing a bug introduced with commit 1eb356b98d ("alpha
gprel optimizations")[1] back in 2001, which replaced address changes
made directly according to the argument of the MEM expression passed
with one made according to an address previously extracted from said MEM
expression. The address is however incorrectly extracted from said MEM
before an adjustment has been made to it for the offset supplied.
This bug is usually covered by the fact that our block move and clear
operations are hardly ever provided with correct block alignment data
and we also usually fail to fetch that information from the MEM supplied
(although PR target/115459 shows it does happen sometimes). Instead the
bit alignment of 8 is usually conservatively used, meaning that a zero
offset is passed to `alpha_expand_unaligned_store_words' and then code
has been written such that neither `alpha_expand_unaligned_load_words'
nor `alpha_expand_unaligned_store_words' cannot ever be called with
nonzero offset from `alpha_expand_block_move'.
The only situation where `alpha_expand_unaligned_store_words' can be
called with nonzero offset is from `alpha_expand_block_clear' with a BWX
target for a misaligned block that has been embedded in a data object of
a higher alignment such that there is a small unaligned prefix our code
decides to handle so as to align further stores.
For instance it happens when a block clear is called for a block of 9
bytes embedded at offset 1 in a structure aligned to a 2-byte word, as
illustrated by the test case included. Now this test case does not work
without the change that comes next applied, because the backend cannot
see the word alignment of the struct and uses the bit alignment of 8
instead.
Should this change be swapped with the next one incorrect code such as:
stb $31,1($16)
lda $3,1($16)
ldq_u $2,8($16)
ldq_u $1,1($16)
mskqh $2,$3,$2
stq_u $2,8($16)
mskql $1,$3,$1
stq_u $1,1($16)
would be produced, where the unadjusted offsets of 1/8 can be seen with
the LDQ_U/STQ_U operations along with byte masks calculated accordingly
rather than the expected offsets of 2/9. As a result the byte at the
offset of 9 fails to get cleared. In these circumstances this would
also show as execution failures with the memclr.c test:
FAIL: gcc.c-torture/execute/memclr.c -O1 execution test
FAIL: gcc.c-torture/execute/memclr.c -Os execution test
-- not at `-O0' though, as the higher alignment cannot be retrieved in
that case, and then not at `-O2' or higher optimization levels either,
because then we choose to open-code this block clear instead:
ldbu $1,0($16)
stw $31,8($16)
stq $1,0($16)
avoiding the bug in `alpha_expand_unaligned_store_words'.
I am leaving the pattern match test case XFAIL-ed here for documentation
purposes and it will be un-XFAIL-ed along with the fix to retrieve the
correct alignment. The run test is of course never expected to fail.
References:
[1] <https://inbox.sourceware.org/gcc-patches/20010909020708.A29152@twiddle.net/>
gcc/
* config/alpha/alpha.cc (alpha_expand_unaligned_load_words):
Move address extraction until after the MEM referred has been
adjusted for the offset supplied.
(alpha_expand_unaligned_store_words): Likewise.
gcc/testsuite/
* gcc.target/alpha/memclr-a2-o1-c9-ptr.c: New file.
* gcc.target/alpha/memclr-a2-o1-c9-run.c: New file.
By inference it appears to me that the same fix for PR target/115459
needs to be applied to the block clear operation that has been done for
block move, as implemented by commit ccfe715180 ("[alpha] adjust MEM
alignment for block move [PR115459]").
gcc/
PR target/115459
* config/alpha/alpha.cc (alpha_expand_block_clear): Adjust MEM
to match inferred alignment.
Remove code duplication in the part of `alpha_expand_block_clear' that
handles any aligned trailing part of the block, observing that the two
legs of code only differ by the machine mode and that we already take
the same approach with handling any unaligned prefix earlier on. No
functional change, just code shuffling.
gcc/
* config/alpha/alpha.cc (alpha_expand_block_clear): Fold two
legs of a conditional together.
Eliminate a redundant bitwise inclusive OR operation on the insertion of
constant zero into a bit-field, improving code produced at `-O2' from an
output sequence such as:
mov $31,$3 # Redundant!
ldq_u $1,7($16)
insqh $3,$16,$3 # Redundant!
ldq_u $2,0($16)
mskqh $1,$16,$1
mskql $2,$16,$2
bis $1,$3,$1 # Redundant!
stq_u $1,7($16)
stq_u $2,0($16)
ret $31,($26),1
to:
ldq_u $2,7($16)
ldq_u $1,0($16)
mskqh $2,$16,$2
stq_u $2,7($16)
mskql $1,$16,$1
stq_u $1,0($16)
ret $31,($26),1
for a quadword unaligned store operation. As shown in the example this
only triggers for the high-part store (and therefore only for 2-byte,
4-byte, and 8-byte stores), because `insXl' insns are fully expressed in
terms of RTL and therefore the insertion of zero is eliminated in later
RTL passes, however corresponding `insXh' insns are unspecs only, making
them impossible to see through.
We can get this optimal right from expand though, given that our handler
for "insvmisaligndi", i.e. `alpha_expand_unaligned_store', has explicit
provisions for `const0_rtx' source.
gcc/
* config/alpha/alpha.md (insvmisaligndi): Use "reg_or_0_operand"
rather than "register_operand" for operand 3.
gcc/testsuite/
* gcc.target/alpha/stlx0.c: New file.
* gcc.target/alpha/stqx0.c: New file.
* gcc.target/alpha/stwx0.c: New file.
* gcc.target/alpha/stwx0-bwx.c: New file.
Expand coverage for unaligned memory stores, for the "insvmisalignM"
patterns, for 2-byte, 4-byte, and 8-byte scalars, across byte alignments
of 1, 2, 4 and byte misalignments within from 0 up to 7 (there's some
redundancy there for the sake of simplicity of the test case), making
sure all data is written and no data is changed outside the area meant
to be written.
The test case has turned invaluable in verifying changes to the Alpha
backend, but functionality covered is generic, so I have concluded this
test qualifies for generic verification and does not have to be limited
to the Alpha-specific subset of the testsuite.
gcc/testsuite/
* gcc.c-torture/execute/misalign.c: New file.
Expand coverage for `__builtin_memset' for the special case of clearing
a block, primarily for "setmemM" block set pattern, though with smaller
sizes open-coded sequences may be produced instead.
This verifies block sizes in bytes from 1 to 64 across byte alignments
of 1, 2, 4, 8 and byte misalignments within from 0 up to 7 (there's some
redundancy there for the sake of simplicity of the test case), making
sure all the intended area is cleared and no data is changed outside it.
These choice of the ranges for the parameters has come from the Alpha
backend, whose "setmemM" pattern has various corner cases related to
base alignment and the misalignment within.
The test case has turned invaluable in verifying changes to the Alpha
backend, but functionality covered is generic, so I have concluded this
test qualifies for generic verification and does not have to be limited
to the Alpha-specific subset of the testsuite.
Just as with `__builtin_memcpy' tests this code turned out to require
quite a lot of time to compile, although a bit less than the former.
Example compilation times with reasonably fast POWER9@2.166GHz at `-O2'
optimization and GCC built at `-O2' for various targets:
mips-linux-gnu: 19s
vax-netbsdelf: 27s
alphaev56-linux-gnu: 30s
alpha-linux-gnu: 31s
powerpc64le-linux-gnu: 47s
With GCC built at `-O0':
alphaev56-linux-gnu: 2m59s
alpha-linux-gnu: 3m06s
I have therefore set the timeout factor accordingly so as to take slower
test hosts into account.
gcc/testsuite/
* gcc.c-torture/execute/memclr.c: New file.
Use `gcc-dg-runtest' test driver rather than `dg-runtest' to run the
Alpha testsuite as several targets already do. Add `-Og -g' and `-Oz'
as well via ADDITIONAL_TORTURE_OPTIONS to expand coverage. Adjust test
options across individual test cases accordingly where required.
Discard base-2.c, cix-2.c, and max-2.c test cases as they merely are
optimization variants of base-1.c, cix-1.c, and max-1.c respectively,
run at `-O2' rather than the default level (`-O0'), now covered by the
framework with the latter ones in a generic way.
Old test results:
=== gcc Summary ===
# of expected passes 44
vs new ones:
=== gcc Summary ===
# of expected passes 364
# of unsupported tests 5
gcc/testsuite/
* gcc.target/alpha/alpha.exp: Use `gcc-dg-runtest' rather than
`dg-runtest'. Add `-Og -g' and `-Oz' variants via
ADDITIONAL_TORTURE_OPTIONS.
* gcc.target/alpha/20000715-1.c: Adjust test options
accordingly.
* gcc.target/alpha/20011018-1.c: Likewise.
* gcc.target/alpha/980217-1.c: Likewise.
* gcc.target/alpha/asm-1.c: Likewise.
* gcc.target/alpha/pr105209.c: Likewise.
* gcc.target/alpha/pr106966.c: Likewise.
* gcc.target/alpha/pr115297.c: Likewise.
* gcc.target/alpha/pr115526.c: Likewise.
* gcc.target/alpha/pr19518.c: Likewise.
* gcc.target/alpha/pr22093.c: Likewise.
* gcc.target/alpha/pr24178.c: Likewise.
* gcc.target/alpha/pr39740.c: Likewise.
* gcc.target/alpha/pr42113.c: Likewise.
* gcc.target/alpha/pr42269-1.c: Likewise.
* gcc.target/alpha/pr42448-1.c: Likewise.
* gcc.target/alpha/pr42448-2.c: Likewise.
* gcc.target/alpha/pr42774.c: Likewise.
* gcc.target/alpha/pr61586.c: Likewise.
* gcc.target/alpha/pr66140.c: Likewise.
* gcc.target/alpha/pr83628-1.c: Likewise.
* gcc.target/alpha/pr83628-2.c: Likewise.
* gcc.target/alpha/pr83628-3.c: Likewise.
* gcc.target/alpha/pr86984.c: Likewise.
* gcc.target/alpha/sqrt.c: Likewise.
* gcc.target/alpha/base-2.c: Remove file.
* gcc.target/alpha/cix-2.c: Remove file.
* gcc.target/alpha/max-2.c: Remove file.
The hook changes the allocno class to either FP_REGS or GR_REGS depending on
the mode of the register. This results in better register allocation overall,
fewer spills and reduced codesize - particularly in SPEC2017 lbm.
gcc/ChangeLog:
* config/loongarch/loongarch.cc
(loongarch_ira_change_pseudo_allocno_class): New function.
(TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS): Define macro.
It seems that tokens_buff_new() has always been allocating the virtual
location buffer 4 times larger than intended, and now that location_t is
64-bit, it is 8 times larger. Fixed.
libcpp/ChangeLog:
* macro.cc (tokens_buff_new): Fix length argument to XNEWVEC.
Running tests in parallel on my 4.5y+ old laptop made this
test time out: the test itself runs in 9m20s, the timeout
being 10 minutes with the 2x factor. That's a bit too close.
This commit does to the base test a similar change as was
done for gcc.dg/torture/inline-mem-cpy-1.c in commit
r14-8188-g6eca0d23b7ea84; or IOW cut it down a factor of 7
(r14-8188 was by a factor of 11).
* gcc.dg/memcmp-1.c: Pass -DRUN_FRACTION=7 when testing in a simulator.
Without this, after r15-6415-g586477d67bf2e3, you'll see,
for targets where int32_t is a typedef of long int (beware
of artificially broken lines):
/x/gcc/libgfortran/caf/single.c: In function '_gfortran_caf_get_by_ct':
/x/gcc/libgfortran/caf/single.c:2943:56: error: passing argument 2 of '\
(accessor_hash_table + (sizetype)((unsigned int)getter_index * 12))->ac\
cessor' from incompatible pointer type [-Wincompatible-pointer-types]
2943 | accessor_hash_table[getter_index].accessor (dst_ptr, &free_bu\
ffer, src_ptr,
| ^~~~~~~~\
~~~~
| |
| int *
/x/gcc/libgfortran/caf/single.c:2943:56: note: expected 'int32_t *' {ak\
a 'long int *'} but argument is of type 'int *'
libgfortran:
* caf/single.c (_gfortran_caf_get_by_ct): Correct type of free_buffer
to int32_t.
Commit r15-6408 overlooked the case of passing NULL without MOLD argument
to a derived type pointer dummy argument without specified intent. Since
it is prohibited to modify the dummy argument, we treat it as if intent(in)
were specified and suppress copying back of the pointer address.
PR fortran/118179
gcc/fortran/ChangeLog:
* trans-expr.cc (conv_null_actual): Suppress copying back of
pointer address for unspecified intent.
gcc/testsuite/ChangeLog:
* gfortran.dg/null_actual_7.f90: Extend testcase to also cover
scalar variants with pointer or allocatable dummy with or without
specified intent.
'make tags' currently fails for libcc1 with this:
*** No rule to make target `marshall-c.hh', needed by `tags-am'. Stop.
The problem is that while marshall-c.hh has been removed via
r12-454-g25d1a6ecdc443f, it's still part of the libcc1_la_SOURCES
variable, hence the 'tags' target has a dependency on it.
This patch simply removes the marshall_c_source variable, that should be
empty.
libcc1/ChangeLog:
* Makefile.am: Remove reference to deleted marshall-c.h.
* Makefile.in: Regenerate.
