While investigating possible race conditions in the GCC testsuites
caused by bufferization issues, I wanted to investigate workarounds
similar to GDB's READ1 [1], and I noticed it was not always possible
to override EXPECT when running 'make check'.
This patch adds the missing support in various Makefiles.
I was not able to test the patch for all the libraries updated here,
but I confirmed it works as intended/needed for libstdc++.
libatomic, libitm, libgomp already work as intended because their
Makefiles do not have:
MAKEOVERRIDES=
Tested on (native) aarch64-linux-gnu, confirmed the patch introduces
the behaviour I want in gcc, g++, gfortran and libstdc++.
I updated (but could not test) libgm2, libphobos, libquadmath and
libssp for consistency since their Makefiles have MAKEOVERRIDES=
libffi, libgo, libsanitizer seem to need a similar update, but they
are imported from their respective upstream repo, so should not be
patched here.
[1] https://github.com/bminor/binutils-gdb/blob/master/gdb/testsuite/README#L269
2023-12-21 Christophe Lyon <christophe.lyon@linaro.org>
gcc/
* Makefile.in: Allow overriding EXEPCT.
libgm2/
* Makefile.am: Allow overriding EXEPCT.
* Makefile.in: Regenerate.
libphobos/
* Makefile.am: Allow overriding EXEPCT.
* Makefile.in: Regenerate.
libquadmath/
* Makefile.am: Allow overriding EXEPCT.
* Makefile.in: Regenerate.
libssp/
* Makefile.am: Allow overriding EXEPCT.
* Makefile.in: Regenerate.
libstdc++-v3/
* Makefile.am: Allow overriding EXEPCT.
* Makefile.in: Regenerate.
This patch removes the testsuite_tr1.h dependency from g++.dg/ext/is_*.C
tests since the header is supposed to be used only by libstdc++, not
front-end. This also includes test code consistency fixes.
For the record this fixes the test failures reported at
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641058.html
gcc/testsuite/ChangeLog:
* g++.dg/ext/is_array.C: Remove testsuite_tr1.h. Add necessary
definitions accordingly. Tweak macros for consistency across
test codes.
* g++.dg/ext/is_bounded_array.C: Likewise.
* g++.dg/ext/is_function.C: Likewise.
* g++.dg/ext/is_member_function_pointer.C: Likewise.
* g++.dg/ext/is_member_object_pointer.C: Likewise.
* g++.dg/ext/is_member_pointer.C: Likewise.
* g++.dg/ext/is_object.C: Likewise.
* g++.dg/ext/is_reference.C: Likewise.
* g++.dg/ext/is_scoped_enum.C: Likewise.
Signed-off-by: Ken Matsui <kmatsui@gcc.gnu.org>
Reviewed-by: Patrick Palka <ppalka@redhat.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
As with 37722, we don't clean up the exception object if a computed goto
leaves a catch block, but we can warn about that.
PR c++/81438
gcc/cp/ChangeLog:
* decl.cc (poplevel_named_label_1): Handle leaving catch.
(check_previous_goto_1): Likewise.
(check_goto_1): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/ext/label15.C: Require indirect_jumps.
* g++.dg/ext/label16.C: New test.
This testcase was failing on uses of int8_t, int64_t, etc without
including <stdint.h>.
gcc/testsuite/ChangeLog
* g++.dg/analyzer/placement-new-size.C: Include <stdint.h>. Also
add missing newline to end of file.
We were getting sizeof... mangling wrong when the argument after
substitution was a pack expansion that is not a simple T..., such as
list<T>... in variadic-mangle4.C or (A+1)... in variadic-mangle5.C. In the
former case we ICEd; in the latter case we wrongly mangled it as sZ
<expression>.
PR c++/95298
gcc/cp/ChangeLog:
* mangle.cc (write_expression): Handle v18 sizeof... bug.
* pt.cc (tsubst_pack_expansion): Keep TREE_VEC for sizeof...
(tsubst_expr): Don't strip TREE_VEC here.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/variadic-mangle2.C: Add non-member.
* g++.dg/cpp0x/variadic-mangle4.C: New test.
* g++.dg/cpp0x/variadic-mangle5.C: New test.
* g++.dg/cpp0x/variadic-mangle5a.C: New test.
This adds the documentation for cond_copysign and cond_len_copysign optabs.
Also reorders the optabs.def to be in the similar order as how the internal
function was done.
gcc/ChangeLog:
PR middle-end/112951
* doc/md.texi (cond_copysign): Document.
(cond_len_copysign): Likewise.
* optabs.def: Reorder cond_copysign to be before
cond_fmin. Likewise for cond_len_copysign.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Since r14-4977-g0f2e2080685e75 we now issue a -Wparentheses warning for
extern std::vector<bool> v;
bool b = v[0] = true; // warning: suggest parentheses around assignment used as truth value [-Wparentheses]
I intended for that commit to just allow the existing diagnostics to
happen in a template context as well, but the refactoring of
is_assignment_op_expr_p caused us for this -Wparentheses warning from
convert_for_assignment to now consider user-defined operator= expressions
instead of just built-in operator=. And since std::vector<bool> is really
a bitset, whose operator[] returns a class type with such a user-defined
operator= (taking bool), we now warn here when we didn't use to.
That we now accept user-defined operator= expressions is generally good,
but arguably "boolish" class types should be treated like ordinary bool
as far as the warning is concerned. To that end this patch suppresses
the warning for such types, specifically when the class type can be
implicitly converted to and assigned from bool. This criterion captures
the std::vector<bool>::reference of libstdc++ at least.
gcc/cp/ChangeLog:
* cp-tree.h (maybe_warn_unparenthesized_assignment): Add
'nested_p' bool parameter.
* semantics.cc (boolish_class_type_p_cache): Define.
(boolish_class_type_p): Define.
(maybe_warn_unparenthesized_assignment): Add 'nested_p'
bool parameter. Suppress the warning for nested assignments
to bool and bool-like class types.
(maybe_convert_cond): Pass nested_p=false to
maybe_warn_unparenthesized_assignment.
* typeck.cc (convert_for_assignment): Pass nested_p=true to
maybe_warn_unparenthesized_assignment. Remove now redundant
check for 'rhs' having bool type.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wparentheses-34.C: New test.
The deprecated and unavailable attributes weren't working when used on
a template redeclaration ultimately because we weren't merging the
corresponding tree flags in duplicate_decls.
PR c++/84542
gcc/cp/ChangeLog:
* decl.cc (merge_attribute_bits): Merge TREE_DEPRECATED
and TREE_UNAVAILABLE.
gcc/testsuite/ChangeLog:
* g++.dg/ext/attr-deprecated-2.C: No longer XFAIL.
* g++.dg/ext/attr-unavailable-12.C: New test.
When constraining the visibility of an instantiation, we weren't
properly considering the visibility of PTRMEM_CST and TEMPLATE_DECL
template arguments.
This patch fixes this. It turns out we don't maintain the relevant
visibility flags for alias templates (e.g. TREE_PUBLIC is never set),
so continue to ignore alias template template arguments for now.
PR c++/70413
PR c++/107906
gcc/cp/ChangeLog:
* decl2.cc (min_vis_expr_r): Handle PTRMEM_CST and TEMPLATE_DECL
other than those for alias templates.
gcc/testsuite/ChangeLog:
* g++.dg/template/linkage2.C: New test.
* g++.dg/template/linkage3.C: New test.
* g++.dg/template/linkage4.C: New test.
* g++.dg/template/linkage4a.C: New test.
This patch fixes an issue introduced by:
commit ea4a3d08f1
Author: Andre Vieira <andre.simoesdiasvieira@arm.com>
Date: Wed Nov 1 17:02:41 2023 +0000
omp: Reorder call for TARGET_SIMD_CLONE_ADJUST
The problem was that after this patch we no longer added multiple
arguments for vector arguments where the veclen was lower than the simdlen.
Bootstrapped and regression tested on x86_64-pc-linux-gnu and
aarch64-unknown-linux-gnu.
gcc/ChangeLog:
PR middle-end/113040
* omp-simd-clone.cc (simd_clone_adjust_argument_types): Add multiple
vector arguments where simdlen is larger than veclen.
The move to the output operand should use high register input operand.
PR target/113044
gcc/ChangeLog:
* config/i386/i386.md (*ashlqi_ext<mode>_1): Move from the
high register of the input operand.
(*<insn>qi_ext<mode>_1): Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr113044.c: New test.
This patch has been separated out from the C++ "declare mapper"
support patch. It contains just the gimplify.cc rearrangement
work, mostly moving gimplification from gimplify_scan_omp_clauses
to gimplify_adjust_omp_clauses for map clauses.
The motivation for doing this was that we don't know if we need to
instantiate mappers implicitly until the body of an offload region has
been scanned, i.e. in gimplify_adjust_omp_clauses, but we also need the
un-gimplified form of clauses to sort by base-pointer dependencies after
mapper instantiation has taken place.
The patch also reimplements the "present" clause sorting code to avoid
another sorting pass on mapping nodes.
This version of the patch is based on the version posted for og13, and
additionally incorporates a follow-on fix for DECL_VALUE_EXPR handling
in gimplify_adjust_omp_clauses:
"OpenMP/OpenACC: Reorganise OMP map clause handling in gimplify.cc"
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622223.html
Parts of:
"OpenMP: OpenMP 5.2 semantics for pointers with unmapped target"
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623351.html
2023-12-16 Julian Brown <julian@codesourcery.com>
gcc/
* gimplify.cc (omp_segregate_mapping_groups): Handle "present" groups.
(gimplify_scan_omp_clauses): Use mapping group functionality to
iterate through mapping nodes. Remove most gimplification of
OMP_CLAUSE_MAP nodes from here, but still populate ctx->variables
splay tree.
(gimplify_adjust_omp_clauses): Move most gimplification of
OMP_CLAUSE_MAP nodes here.
libgomp/
* testsuite/libgomp.fortran/target-enter-data-6.f90: Remove XFAIL.
As the PR shows, there was nothing to prevent the ldp/stp pass from
trying to move throwing insns, which lead to an RTL verification
failure.
This patch fixes that.
gcc/ChangeLog:
PR target/113093
* config/aarch64/aarch64-ldp-fusion.cc (latest_hazard_before):
If the insn is throwing, record the previous insn as a hazard to
prevent moving it from the end of the BB.
gcc/testsuite/ChangeLog:
PR target/113093
* gcc.dg/pr113093.c: New test.
This fixes one warning and works around another one where we allocate less than
what we cast to.
2023-12-21 Jakub Jelinek <jakub@redhat.com>
* gimple-fold.cc (maybe_fold_comparisons_from_match_pd):
Use unsigned char buffers for lhs1 and lhs2 instead of allocating
them through XALLOCA.
* collect2.cc (maybe_run_lto_and_relink): Swap xcalloc arguments.
The testcase constructs a sequence of insns that are fully dead
and yet (due to forced options) are not removed as such. This
triggered a case where we would emit a meaningless reload for a
to-be-deleted insn.
We can't delete the insns first because that might disrupt the
iteration ranges. So this patch turns them into notes before
the walk and then continues to delete them properly afterwards.
gcc/
PR target/113094
* config/aarch64/aarch64-early-ra.cc (apply_allocation): Stub
out instructions that are going to be deleted before iterating
over the rest.
gcc/testsuite/
PR target/113094
* gcc.target/aarch64/pr113094.c: New test.
As the PR notes, there was a cut-&-pasto in find_strided_accesses.
I've not been able to find a testcase that shows the problem.
gcc/
PR target/112948
* config/aarch64/aarch64-early-ra.cc (find_strided_accesses): Fix
cut-&-pasto.
The following patch enables the -Walloc-size and -Wcalloc-transposed-args
warnings for C++ as well.
Tracking just 6 arguments for SIZEOF_EXPR for the calloc purposes
is because I see alloc_size 1,2, 2,3 and 3,4 pairs used in the wild,
so we need at least 5 to cover that rather than 3, and don't want to waste
too much compile time/memory for that.
2023-12-21 Jakub Jelinek <jakub@redhat.com>
gcc/c-family/
* c.opt (Walloc-size): Enable also for C++ and ObjC++.
gcc/cp/
* cp-gimplify.cc (cp_genericize_r): If warn_alloc_size, call
warn_for_alloc_size for -Walloc-size diagnostics.
* semantics.cc (finish_call_expr): If warn_calloc_transposed_args,
call warn_for_calloc for -Wcalloc-transposed-args diagnostics.
gcc/testsuite/
* g++.dg/warn/Walloc-size-1.C: New test.
* g++.dg/warn/Wcalloc-transposed-args-1.C: New test.
libubsan still doesn't support bitints, so ubsan contains a workaround and
emits value 0 and TK_Unknown kind for those. If shift second operand has
the large/huge _BitInt type, this results in internal errors in libubsan
though, so the following patch provides a temporary workaround for that
- in the rare case where the last operand has _BitInt type wider than
__int128 (or long long on 32-bit arches), it will pretend the shift count
has that type saturated to its range. IMHO better than crashing in
the library. If the value fits into the __int128 (or long long) range,
it will be printed correctly (just print that it has __int128/long long
type rather than say _BitInt(255)), if it doesn't, user will at least
know that it is a very large negative or very large positive value.
2023-12-21 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/113092
* c-ubsan.cc (ubsan_instrument_shift): Workaround for missing
ubsan _BitInt support for the shift count.
* gcc.dg/ubsan/bitint-4.c: New test.
Multiplication/division/modulo/float operands are handled by libgcc calls
and so need to be passed as array of limbs with precision argument,
using handle_operand_addr. That code can't deal with more than one cast,
so the following patch avoids merging those cases.
.MUL_OVERFLOW calls use the same code, but we don't actually try to merge
the operands in that case already.
2023-12-21 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/112941
* gimple-lower-bitint.cc (gimple_lower_bitint): Disallow merging
a cast with multiplication, division or conversion to floating point
if rhs1 of the cast is result of another single use cast in the same
bb.
* gcc.dg/bitint-56.c: New test.
* gcc.dg/bitint-57.c: New test.
gcc/ChangeLog:
* doc/extend.texi:According to the documents submitted earlier,
Two problems with function return types and using the actual types
of parameters instead of variable names were found and fixed.
On LoongArch architecture, using the latest gcc14 in regression test,
it is found that the vector test cases in vector directory appear FAIL
entries with unmatched pointer types. In order to solve this kind of
problem, the type of the variable in the check result is modified with
the parameter type defined in the vector builtin function.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/vector/simd_correctness_check.h:The variable
types in the check results are modified in conjunction with the
parameter types defined in the vector builtin function.
When I attempt to enable vect_usad_char effective target for LoongArch, slp-reduc-sad.c
and vect-reduc-sad*.c tests fail. These tests fail because the sad pattern generates bad
code. This patch to fixed them, for sad patterns, use zero expansion instead of sign
expansion for reduction.
Currently, we are fixing failed vectorized tests, and in the future, we will
enable more tests of "vect" for LoongArch.
gcc/ChangeLog:
* config/loongarch/lasx.md: Use zero expansion instruction.
* config/loongarch/lsx.md: Ditto.
Tell the backend which types are equivalent by setting
TYPE_CANONICAL to one struct in the set of equivalent
structs. Structs are considered equivalent by ignoring
all sizes of arrays nested in types below field level.
The following two structs are incompatible and lvalues
with these types can be assumed not to alias:
struct foo { int a[3]; };
struct foo { int a[4]; };
The following two structs are also incompatible, but
will get the same TYPE_CANONICAL and it is then not
exploited that lvalues with those types can not alias:
struct bar { int (*p)[3]; };
struct bar { int (*p)[4]; };
The reason is that both are compatible to
struct bar { int (*p)[]; };
and therefore are in the same equivalence class. For
the same reason all enums with the same underyling type
are in the same equivalence class. Tests are added
for the expected aliasing behavior with optimization.
gcc/c:
* c-decl.cc (c_struct_hasher): Hash stable for struct
types.
(c_struct_hasher::hash, c_struct_hasher::equal): New
functions.
(finish_struct): Set TYPE_CANONICAL to first struct in
equivalence class.
* c-objc-common.cc (c_get_alias_set): Let structs or
unions with variable size alias anything.
* c-tree.h (comptypes_equiv): New prototype.
* c-typeck.cc (comptypes_equiv): New function.
(comptypes_internal): Implement equivalence mode.
(tagged_types_tu_compatible): Implement equivalence mode.
gcc/testsuite:
* gcc.dg/c23-tag-2.c: Activate.
* gcc.dg/c23-tag-5.c: Activate.
* gcc.dg/c23-tag-alias-1.c: New test.
* gcc.dg/c23-tag-alias-2.c: New test.
* gcc.dg/c23-tag-alias-3.c: New test.
* gcc.dg/c23-tag-alias-4.c: New test.
* gcc.dg/c23-tag-alias-5.c: New test.
* gcc.dg/gnu23-tag-alias-1.c: New test.
* gcc.dg/gnu23-tag-alias-2.c: New test.
* gcc.dg/gnu23-tag-alias-3.c: New test.
* gcc.dg/gnu23-tag-alias-4.c: New test.
* gcc.dg/gnu23-tag-alias-5.c: New test.
* gcc.dg/gnu23-tag-alias-6.c: New test.
* gcc.dg/gnu23-tag-alias-7.c: New test.
Allow redefinition of enum types and enumerators. Diagnose
nested redefinitions including redefinitions in the enum
specifier for enum types with fixed underlying type.
gcc/c:
* c-tree.h (c_parser_enum_specifier): Add parameter.
* c-decl.cc (start_enum): Allow redefinition.
(finish_enum): Diagnose conflicts.
(build_enumerator): Set context.
(diagnose_mismatched_decls): Diagnose conflicting enumerators.
(push_decl): Preserve context for enumerators.
* c-typeck.cc (tagged_types_tu_compatible_p): Adapt.
* c-parser.cc (c_parser_enum_specifier): Remember when
seen is from an enum type which is not yet defined.
gcc/testsuite:
* gcc.dg/c23-tag-enum-1.c: New test.
* gcc.dg/c23-tag-enum-2.c: New test.
* gcc.dg/c23-tag-enum-3.c: New test.
* gcc.dg/c23-tag-enum-4.c: New test.
* gcc.dg/c23-tag-enum-5.c: New test.
* gcc.dg/gnu23-tag-enum-1.c: Mew test.
When fixing the PR, I failed to remove the comment that raised the
very concern that the PR confirmed, and that the earlier patch for the
PR fixed.
for gcc/ChangeLog
PR target/112778
* builtins.cc (try_store_by_multiple_pieces): Drop obsolete
comment.
PR112995 exposed one issue in current try_replace_dest_reg
that the result rtx insn after replace_dest_with_reg_in_expr
is probably unable to match any constraints. Although there
are some checks on the changes onto dest or src of orig_insn,
none is performed on the EXPR_INSN_RTX.
Initially we have:
(insn 31 6 10 2 (set (reg/v:SI 9 9 [orig:119 c ] [119])
(reg/v:SI 64 0 [orig:119 c ] [119]))
"test.i":5:5 555 {*movsi_internal1} ... )
...
(insn 25 10 27 2 (set (reg:DI 64 0 [135])
(sign_extend:DI
(reg/v:SI 9 9 [orig:119 c ] [119])))
"test.i":6:5 31 {extendsidi2} ...)
with moving up, we have:
(insn 46 0 0 (set (reg:DI 64 0 [135])
(sign_extend:DI
(reg/v:SI 64 0 [orig:119 c ] [119])))
31 {extendsidi2} ...)
in try_replace_dest_reg, we updated the above EXPR_INSN_RTX to:
(insn 48 0 0 (set (reg:DI 32 0)
(sign_extend:DI
(reg/v:SI 64 0 [orig:119 c ] [119])))
31 {extendsidi2} ...)
The dest (reg 64) is a VR (also VSX REG), the updating makes
it become to (reg 32) which is a FPR (also VSX REG), we have
an alternative to match "VR,VR" but no one to match "FPR/VSX,
VR/VSX", so it fails with ICE.
This patch is to add the check before actually replacing dest
in expr with reg.
PR rtl-optimization/112995
gcc/ChangeLog:
* sel-sched.cc (try_replace_dest_reg): Check the validity of the
replaced insn before actually replacing dest in expr.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr112995.c: New test.
When compare_tests compares both C and C++ tests in c-c++-common, they
get the same identifier, so expected differences in results across
languages become undesirably noisy.
This patch adds tool identifiers to tests, so that runs by different
tools are not confused by the compare logic.
It also fixes a bug in reporting differences, that would attempt to
print an undefined fname (the definitions are in subshell loops), and
adjusts the target insertion to match tabs in addition to blanks after
colons.
for contrib/ChangeLog
* compare_tests: Add tool to test lines. Match tabs besides
blanks to insert tool and target. Don't print undefined fname.
Currently the debug counter sched_block doesn't work well
since we create dependencies for some insns and those
dependencies are expected to be resolved during scheduling
insns but they can get skipped once we are skipping some
block while respecting sched_block debug counter.
For example, for the below test case:
--
int a, b, c, e, f;
float d;
void
g ()
{
float h, i[1];
for (; f;)
if (c)
{
d *e;
if (b)
{
float *j = i;
j[0] = 0;
}
h = d;
}
if (h)
a = i[0];
}
--
ICE occurs with option "-O2 -fdbg-cnt=sched_block:1".
As the discussion in [1], it seems that we think this debug
counter is useless and can be removed. It's also implied
that if it's useful and used often, the above issue should
have been cared about and resolved earlier. So this patch
is to remove this debug counter.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635852.html
gcc/ChangeLog:
* dbgcnt.def (sched_block): Remove.
* sched-rgn.cc (schedule_region): Remove the support of debug count
sched_block.
PR37722 complains that a computed goto doesn't destroy objects that go out
of scope. In the PR we agreed that it never will, but we can warn about
it.
PR c++/37722
gcc/ChangeLog:
* doc/extend.texi: Document that computed goto does not
call destructors.
gcc/cp/ChangeLog:
* decl.cc (identify_goto): Adjust for computed goto.
(struct named_label_use_entry): Add computed_goto field.
(poplevel_named_label_1): Add to computed_goto vec.
(check_previous_goto_1): Dump computed_goto vec.
(check_goto_1): Split out from check_goto.
(check_goto): Check all addressable labels for computed goto.
(struct named_label_entry): Add addressed field.
(mark_label_addressed): New.
* parser.cc (cp_parser_unary_expression): Call it.
* cp-tree.h (mark_label_addressed): Declare it.
gcc/testsuite/ChangeLog:
* g++.dg/ext/label15.C: New test.
* g++.dg/torture/pr42739.C: Expect warning.
-Werror=foo implying -Wfoo wasn't working for -Wdeprecated-copy-dtor,
because it is specified as the value 2 of warn_deprecated_copy, which shows
up as CLVC_EQUAL, which is not one of the three var_types handled by
control_warning_option. It seems to me that we can just unconditionally
handle_generated_option, and only have special argument handling for those
types.
PR c++/106213
gcc/ChangeLog:
* opts-common.cc (control_warning_option): Call
handle_generated_option for all cl_var_types.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/depr-copy5.C: New test.
I thought it could be easier to use check_GNU_style.py. With this alias,
'git gcc-style' will take a git revision as argument instead of a file, or
check HEAD if no argument is given.
contrib/ChangeLog:
* gcc-git-customization.sh: Add git gcc-style alias.
While trying to fix bugs of PR113097, notice this following situation we
generate redundant vsetvli
_255 = SELECT_VL (3, POLY_INT_CST [4, 4]);
COND_LEN (..., _255)
Before this patch:
vsetivli a5, 3...
...
vadd.vv (use a5)
After this patch:
...
vadd.vv (use AVL = 3)
The reason we can do this is because known_ge (3, [4,4]) is true.
It's safe to apply such optimization
Tested on both RV32 and RV64 full coverage testing, no regression.
PR target/113087
gcc/ChangeLog:
* config/riscv/riscv-v.cc (expand_select_vl): Optimize SELECT_VL.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr113087-2.c: New test.
This patch fixes bugs in the fusion of this following case:
li a5,-1
vmv.s.x v0,a5 -> demand any non-zero AVL
vsetvli a5, ...
Incorrect fusion after VSETVL PASS:
li a5,-1
vsetvli a5...
vmv.s.x v0, a5 --> a5 is modified as incorrect value.
We disallow this incorrect fusion above.
Full coverage testing of RV64 and RV32 no regression.
PR target/113087
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc: Disallow fusion when VL modification pollutes non AVL use.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr113087-1.c: New test.
This patch works around behaviour of the 2D and 3D memcpy operations in
the CUDA driver runtime. Particularly in Fortran, the "base pointer"
of an array (used for either source or destination of a host/device copy)
may lie outside of data that is actually stored on the device. The fix
is to make sure that we use the first element of data to be transferred
instead, and adjust parameters accordingly.
2023-10-02 Julian Brown <julian@codesourcery.com>
libgomp/
* plugin/plugin-nvptx.c (GOMP_OFFLOAD_memcpy2d): Adjust parameters to
avoid out-of-bounds array checks in CUDA runtime.
(GOMP_OFFLOAD_memcpy3d): Likewise.
* testsuite/libgomp.c-c++-common/memcpyxd-bias-1.c: New test.
gcc/ChangeLog:
* doc/invoke.texi: Document the new file extensions
gcc/fortran/ChangeLog:
PR fortran/81615
* lang-specs.h (F951_CPP_OPTIONS): Do not hardcode ".f90" extension
(F951_CPP_EXTENSION): Use .fi/.fii for fixed/free form sources
* options.cc (form_from_filename): Handle the new extensions
Signed-off-by: Rimvydas Jasinskas <rimvydas.jas@gmail.com>
If cse sees:
(set (reg R) (const_vector [A B ...]))
it creates fake sets of the form:
(set R[0] A)
(set R[1] B)
...
(with R[n] replaced by appropriate rtl) and then adds them to the tables
in the same way as for normal sets. This allows a sequence like:
(set (reg R2) A)
...(reg R2)...
to try to use R[0] instead of (reg R2).
But the pass was taking the analogy too far, and was trying to simplify
these fake sets based on costs. That is, if there was an earlier:
(set (reg T) A)
the pass would go to considerable effort trying to work out whether:
(set R[0] A)
or:
(set R[0] (reg T))
was more profitable. This included running validate*_change on the sets,
which has no meaning given that the sets are not part of the insn.
In this example, the equivalence A == T is already known, and the
purpose of the fake sets is to add A == T == R[0]. We can do that
just as easily (or, as the PR shows, more easily) if we keep the
original form of the fake set, with A instead of T.
The problem in the PR occurred if we had:
(1) something that establishes an equivalence between a vector V1 of
M-bit scalar integers and a hard register H
(2) something that establishes an equivalence between a vector V2 of
N-bit scalar integers, where N<M and where V2 contains at least 2
instances of V1[0]
(1) established an equivalence between V1[0] and H in M bits.
(2) then triggered a search for an equivalence of V1[0] in N bits.
This included:
/* See if we have a CONST_INT that is already in a register in a
wider mode. */
which (correctly) found that the low N bits of H contain the right value.
But because it came from a wider mode, this equivalence between N-bit H
and N-bit V1[0] was not yet in the hash table. It therefore survived
the purge in:
/* At this point, ELT, if nonzero, points to a class of expressions
equivalent to the source of this SET and SRC, SRC_EQV, SRC_FOLDED,
and SRC_RELATED, if nonzero, each contain additional equivalent
expressions. Prune these latter expressions by deleting expressions
already in the equivalence class.
And since more than 1 set found the same N-bit equivalence between
H and V1[0], the pass tried to add it more than once.
Things were already wrong at this stage, but an ICE was only triggered
later when trying to merge this N-bit equivalence with another one.
We could avoid the double registration by adding:
for (elt = classp; elt; elt = elt->next_same_value)
if (rtx_equal_p (elt->exp, x))
return elt;
to insert_with_costs, or by making cse_insn check whether previous
sets have recorded the same equivalence. The latter seems more
appealing from a compile-time perspective. But in this case,
doing that would be adding yet more spurious work to the handling
of fake sets.
The handling of fake sets therefore seems like the more fundamental bug.
While there, the patch also makes sure that we don't apply REG_EQUAL
notes to these fake sets. They only describe the "real" (first) set.
gcc/
PR rtl-optimization/111702
* cse.cc (set::mode): Move earlier.
(set::src_in_memory, set::src_volatile): Convert to bitfields.
(set::is_fake_set): New member variable.
(add_to_set): Add an is_fake_set parameter.
(find_sets_in_insn): Update calls accordingly.
(cse_insn): Do not apply REG_EQUAL notes to fake sets. Do not
try to optimize them either, or validate changes to them.
gcc/testsuite/
PR rtl-optimization/111702
* gcc.dg/rtl/aarch64/pr111702.c: New test.
maybe_splice_retval_cleanup assumed that the function body can't be empty if
there's a throwing cleanup, but when I added cleanups to try blocks in
r12-6333-gb10e031458d541 I didn't adjust that assumption.
PR c++/113088
PR c++/33799
gcc/cp/ChangeLog:
* except.cc (maybe_splice_retval_cleanup): Handle an empty block.
gcc/testsuite/ChangeLog:
* g++.dg/eh/return2.C: New test.
Normally we handle xvalue array subscripting with ARRAY_REF, but in this
case we weren't doing that because the operands were reversed. Handle that
case better.
PR c++/103185
gcc/cp/ChangeLog:
* typeck.cc (cp_build_array_ref): Handle swapped operands.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/array-prvalue2.C: New test.
* g++.dg/cpp1z/eval-order3.C: Test swapped operands.
