gcc/fortran/
* trans-openmp.c (gfc_omp_is_optional_argument,
gfc_omp_check_optional_argument): Handle type(c_ptr),value which uses a
hidden argument for the is-present check.
gcc/
* omp-low.c (lower_omp_target): For use_device_ptr/use_derice_addr
and Fortran's optional arguments, unconditionally add the is-present
condition before the libgomp call.
libgomp/
* testsuite/libgomp.fortran/use_device_ptr-optional-2.f90: Add
'type(c_ptr), value' test case. Conditionally map the per-value
passed arguments.
From-SVN: r279004
This PR shows that we weren't checking for bitwise-identical values
when trying to encode a VECTOR_CST, so -0.0 was treated the same as
0.0 for -fno-signed-zeros. The patch adds a new OEP flag to select
that behaviour.
2019-12-05 Richard Sandiford <richard.sandiford@arm.com>
gcc/
PR middle-end/92768
* tree-core.h (OEP_BITWISE): New flag.
* fold-const.c (operand_compare::operand_equal_p): Handle it.
* tree-vector-builder.h (tree_vector_builder::equal_p): Pass it.
gcc/testsuite/
PR middle-end/92768
* gcc.dg/pr92768.c: New test.
From-SVN: r279002
The previous commit fixed the std::span constructors from const arrays,
revealing a bug in this test.
* testsuite/23_containers/span/lwg3255.cc: Fix test. Constructing a
span of non-const elements should not be possible from a const array
or an array of const elements.
From-SVN: r279001
This also fixes a bug in the implementation of LWG 3255, which causes:
FAIL: 23_containers/span/lwg3255.cc (test for excess errors)
That's because the test was wrong and verified the buggy behaviour. That
will be fixed in the following commit.
2019-12-05 JeanHeyd "ThePhD" Meneide <phdofthehouse@gmail.com>
Implement P1872R0 and P1394R0 for std::span
* include/bits/range_access.h (__adl_begin, __adl_end): Remove.
(sentinel_t, range_value_t, range_reference_t)
(range_rvalue_reference_t, __forwarding_range, disable_sized_range)
(output_range, input_range, forward_range, bidirectional_range)
(random_access_range, contiguous_range, common_range): Move here from
<ranges>, to make this the "ranges lite" internal header.
* include/std/ranges: Move basic aliases and concepts to
<bits/range_access.h>.
* include/std/span: Use concepts and ranges:: calls instead of
enable_if and friends.
* include/std/type_traits: Add __is_array_convertible trait.
From-SVN: r279000
2019-12-05 Richard Biener <rguenther@suse.de>
PR middle-end/92818
* tree-ssa-forwprop.c (simplify_vector_constructor): Improve
heuristics on what don't care element to choose.
* match.pd (VEC_PERM_EXPR -> BIT_INSERT_EXPR): Fix typo.
* gcc.target/i386/pr92818.c: New testcase.
From-SVN: r278998
2019-12-05 Martin Liska <mliska@suse.cz>
PR gcov-profile/91971
* coverage.c (coverage_init): Mangle full path
only when -fprofile-dir is used.
From-SVN: r278990
PR target/92791
* config/i386/i386.md (movstrict<mode>): Move test for
TARGET_PARTIAL_REG_STALL and not optimizing for size from
expander's condition to the body - FAIL; in that case.
From-SVN: r278989
PR fortran/92781
* trans-decl.c (gfc_get_symbol_decl): If sym->backend_decl is
current_function_decl, add length to current rather than parent
function and expect DECL_CONTEXT (length) to be current_function_decl.
* gfortran.dg/pr92781.f90: New test.
From-SVN: r278988
As done for std::pair, this defines operator<=> as a non-member function
template and does not alter operator==, as expected to be proposed as
the resolution to an unpublished LWG issue.
Instead of calling std::lexicographical_compare_three_way the <=>
overload is implemented by hand to take advantage of the fact the
element types and array sizes are known to be the same.
* include/bits/cpp_type_traits.h (__is_byte<char8_t>): Add
specialization.
* include/std/array (operator<=>): Likewise.
* testsuite/23_containers/array/comparison_operators/constexpr.cc:
Test three-way comparisons and arrays of unsigned char.
* testsuite/23_containers/array/tuple_interface/get_neg.cc: Adjust
dg-error line numbers.
From-SVN: r278981
Bug 88827 points out that GCC should not be rejecting C code that
dereferences a pointer to an incomplete type in the case that uses &*
to take the address of the resulting lvalue, because no constraint is
violated in that case (other than for C90 when the incomplete type is
unqualified void, which we already handle correctly) and as the lvalue
never gets converted to an rvalue there is no undefined behavior
either.
This means that the diagnostic for such a dereference is bogus and
should be removed; if the lvalue gets converted to an rvalue, there
should be an appropriate error later for the use of the incomplete
type. In most cases, there is, but bug 36941 points out the lack of a
diagnostic when the incomplete (non-void) type gets cast to void
(where a diagnostic seems appropriate for this undefined behavior as a
matter of quality of implementation).
This patch removes the bogus diagnostic (and C_TYPE_ERROR_REPORTED
which was only used in the code that is removed - only that one, bogus
diagnostic had this duplicate suppression, not any of the other, more
legitimate diagnostics for use of incomplete types) and makes
convert_lvalue_to_rvalue call require_complete_type for arguments not
of void types, so that all relevant code paths (possibly except some
for ObjC) get incomplete types diagnosed. It's possible that this
makes some other checks for incomplete types obsolete, but no attempt
is made to remove any such checks.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
PR c/36941
PR c/88827
gcc/c:
* c-typeck.c (convert_lvalue_to_rvalue): Call
require_complete_type for arguments not of void types.
(build_indirect_ref): Do not diagnose dereferencing pointers to
incomplete types.
* c-tree.h (C_TYPE_ERROR_REPORTED): Remove.
gcc/testsuite:
* gcc.dg/lvalue-9.c, gcc.dg/lvalue-10.c: New tests.
* gcc.dg/array-8.c, gcc.dg/enum-incomplete-1.c,
gcc.dg/enum-incomplete-3.c, gcc.dg/noncompile/incomplete-3.c,
gcc.dg/pr48552-1.c, gcc.dg/pr48552-2.c, gcc.dg/pr63543.c,
gcc.dg/pr69796.c: Update expected diagnostics.
From-SVN: r278976
PR bootstrap/92661
* config/rs6000/rs6000-c.c (struct altivec_builtin_types): Move to
rs6000.h.
(altivec_overloaded_builtins): Move to rs6000-call.c.
* config/rs6000/rs6000.h (struct altivec_builtin_types): Moved from
rs6000-c.c.
* config/rs6000/rs6000-call.c (rs6000_builtin_info): Make static.
(altivec_overloaded_builtins): Moved from rs6000-c.c.
(rs6000_common_init_builtins): Do no define builtins that overload
builtins that have been disabled.
From-SVN: r278973
To enable cores to use the correct max_cond_insns setting, use the core-specific
tuning when a CPU/tune is selected unless -mrestrict-it is explicitly set.
On Cortex-A57 this gives 1.1% performance gain on SPECINT2006 as well as a
0.4% codesize reduction.
gcc/
* config/arm/arm.c (arm_option_override_internal):
Use max_cond_insns from CPU tuning unless -mrestrict-it is used.
From-SVN: r278968
Add support for fused compare with branch. Rename the existing
AARCH64_FUSE_CMP_BRANCH to ALU_BRANCH, and AARCH64_FUSE_ALU_BRANCH
to ALU_CBZ to make it clear what is being fused.
gcc/
* config/aarch64/aarch64.c
(thunderxt88_tunings): Use AARCH64_FUSE_ALU_BRANCH.
(thunderx_tunings): Likewise.
(tsv110_tunings): Use AARCH64_FUSE_ALU_BRANCH and AARCH64_FUSE_ALU_CBZ.
(thunderx2t99_tunings): Likewise.
(aarch_macro_fusion_pair_p): Add support for AARCH64_FUSE_CMP_BRANCH.
* config/aarch64/aarch64-fusion-pairs.def: Add ALU_CBZ fusion.
From-SVN: r278966
2019-12-04 Richard Biener <rguenther@suse.de>
* tree-ssa-sccvn.c (vn_reference_lookup_3): Properly guard
empty CTOR and memset partial-def registering. Take advantage
of fancy offset analysis in memset handling.
From-SVN: r278965
In r278410 I added code to handle VIEW_CONVERT_EXPRs between
variable-length vectors. This included support for decoding
a VECTOR_BOOLEAN_TYPE_P with subbyte elements.
However, it turns out that we were already mishandling such bool vectors
for fixed-length vectors: we treated each element as a stand-alone byte
instead of putting multiple elements into the same byte. I think in
principle this could have been an issue for AVX512 as well.
This patch adds encoding support for boolean vectors and reuses
a version of the new decode support for fixed-length vectors.
2019-12-04 Richard Sandiford <richard.sandiford@arm.com>
gcc/
* fold-const.c (native_encode_vector_part): Handle
VECTOR_BOOLEAN_TYPE_Ps that have subbyte precision.
(native_decode_vector_tree): Delete, moving the bulk of the code to...
(native_interpret_vector_part): ...this new function. Use a pointer
and length instead of a vec<> and start index.
(native_interpret_vector): Use native_interpret_vector_part.
(fold_view_convert_vector_encoding): Likewise.
gcc/testsuite/
* gcc.target/aarch64/sve/acle/general/whilelt_5.c: New test.
From-SVN: r278964
2019-12-04 Richard Biener <rguenther@suse.de>
* tree-ssa-sccvn.c (vn_walk_cb_data::push_partial_def): Handle
non-constant defs in the most trivial way.
(vn_reference_lookup_3): Also push down SSA partial defs.
* gcc.dg/tree-ssa/ssa-fre-84.c: New testcase.
From-SVN: r278963
2019-12-04 Martin Liska <mliska@suse.cz>
* tree-switch-conversion.c (switch_decision_tree::try_switch_expansion):
Initialize count of newly created BB.
From-SVN: r278959
PR tree-optimization/92734
* match.pd ((A +- B) - A -> +- B, (A +- B) -+ B -> A,
A - (A +- B) -> -+ B, A +- (B -+ A) -> +- B): Handle nop_convert.
* gcc.dg/tree-ssa/pr92734-2.c: New test.
From-SVN: r278958
This is the C++ equivalent of r277950. The changes are very similar
to there. Perhaps the only noteworthy thing (that I know of) is that
the patch continues to treat !gnu_vector_type_p vector types as literal
types/potential constexprs. Disabling the GNU vector extensions
shouldn't in itself stop the types from being literal types, since
whatever the target provides instead might be constexpr material.
2019-12-04 Richard Sandiford <richard.sandiford@arm.com>
gcc/cp/
* cp-tree.h (CP_AGGREGATE_TYPE_P): Check for gnu_vector_type_p
instead of VECTOR_TYPE.
* call.c (build_conditional_expr_1): Restrict vector handling
to vectors that satisfy gnu_vector_type_p.
* cvt.c (ocp_convert): Only allow vectors to be converted
to bool if they satisfy gnu_vector_type_p.
(build_expr_type_conversion): Only allow conversions from
vectors if they satisfy gnu_vector_type_p.
* typeck.c (cp_build_binary_op): Only allow binary operators to be
applied to vectors if they satisfy gnu_vector_type_p.
(cp_build_unary_op): Likewise unary operators.
(build_reinterpret_cast_1):
gcc/testsuite/
* g++.target/aarch64/sve/acle/general-c++/gnu_vectors_1.C: New test.
* g++.target/aarch64/sve/acle/general-c++/gnu_vectors_2.C: New test.
From-SVN: r278957
PR fortran/92756
* trans-openmp.c (gfc_trans_omp_teams): Wrap OMP_TEAMS body into a
BIND_EXPR with a forced BLOCK.
* gfortran.dg/gomp/teams1.f90: New test.
* testsuite/libgomp.fortran/teams1.f90: New test.
* testsuite/libgomp.fortran/teams2.f90: New test.
From-SVN: r278956
PR92760 exposed one issue that VECTOR_UNIT_NONE_P (V2DImode) is true on Power7
then we won't return it as preferred_simd_mode but ISA 2.06 (Power7) does
introduce partial support on vector doubleword (very limitted) and more basic
support origins from ISA 2.07 (Power8) though. To make vectorizer still
leverage those few but available V2DImode related instructions, we need to
claim it's available on VSX (Power7 and up).
gcc/ChangeLog
PR target/92760
* gcc/config/rs6000/rs6000.c (rs6000_preferred_simd_mode): Use
VECTOR_MEM_NONE_P instead of VECTOR_UNIT_NONE_P.
From-SVN: r278955
This defines operator<=> as a non-member function template and does not
alter operator==. This contradicts the changes made by P1614R2, which
specify both as hidden friends, but that specification of operator<=> is
broken and the subject of a soon-to-be-published LWG issue.
* include/bits/stl_pair.h [__cpp_lib_three_way_comparison]
(operator<=>): Define for C++20.
* libsupc++/compare (__cmp2way_res_t): Rename to __cmp3way_res_t,
move into __detail namespace. Do not turn argument types into lvalues.
(__cmp3way_helper): Rename to __cmp3way_res_impl, move into __detail
namespace. Constrain with concepts instead of using void_t.
(compare_three_way_result): Adjust name of base class.
(compare_three_way_result_t): Use __cmp3way_res_impl directly.
(__detail::__3way_cmp_with): Add workaround for PR 91073.
(compare_three_way): Use workaround.
(__detail::__synth3way, __detail::__synth3way_t): Define new helpers
implementing synth-three-way and synth-three-way-result semantics.
* testsuite/20_util/pair/comparison_operators/constexpr_c++20.cc: New
test.
From-SVN: r278951
PR bootstrap/92783
* gcc-interface/utils.c (rest_of_record_type_compilation): Move down
the guard for the position of fields in the descriptive type.
From-SVN: r278948
PR c++/91369
* constexpr.c (struct constexpr_global_ctx): Add cleanups member,
initialize it in the ctor.
(cxx_eval_constant_expression) <case TARGET_EXPR>: If TARGET_EXPR_SLOT
is already in the values hash_map, don't evaluate it again. Put
TARGET_EXPR_SLOT into hash_map even if not lval, and push it into
save_exprs too. If there is TARGET_EXPR_CLEANUP and not
CLEANUP_EH_ONLY, push the cleanup to cleanups vector.
<case CLEANUP_POINT_EXPR>: Save outer cleanups, set cleanups to
local auto_vec, after evaluating the body evaluate cleanups and
restore previous cleanups.
<case TRY_CATCH_EXPR>: Don't crash if the first operand is NULL_TREE.
(cxx_eval_outermost_constant_expr): Set cleanups to local auto_vec,
after evaluating the expression evaluate cleanups.
* g++.dg/cpp2a/constexpr-new8.C: New test.
From-SVN: r278945
while looking into Firefox inlining dumps I noticed that we often do not
inline because we think function calls comdat local while the comdat group
itself has been dissolved.
* cgraph.c (cgraph_node::verify_node): Check that calls_comdat_local
is set only for symbol in comdat group.
* symtab.c (symtab_node::dissolve_same_comdat_group_1): Clear it.
From-SVN: r278944
Even EXACT_DIV_EXPR doesn't distribute across addition for wrapping
types, so in general we can't fold EXACT_DIV_EXPRs of POLY_INT_CSTs
at compile time. This was causing an ICE when trying to gimplify the
element size field in an ARRAY_REF.
If the result of that EXACT_DIV_EXPR is an invariant, we don't bother
recording it in the ARRAY_REF and simply read the element size from the
element type. This avoids the overhead of doing:
/* ??? tree_ssa_useless_type_conversion will eliminate casts to
sizetype from another type of the same width and signedness. */
if (TREE_TYPE (aligned_size) != sizetype)
aligned_size = fold_convert_loc (loc, sizetype, aligned_size);
return size_binop_loc (loc, MULT_EXPR, aligned_size,
size_int (TYPE_ALIGN_UNIT (elmt_type)));
each time array_ref_element_size is called.
So rather than read array_ref_element_size, do some arithmetic on it,
and only then check whether the result is an invariant, we might as
well check whether the element size is an invariant to start with.
We're then directly testing whether array_ref_element_size gives
a reusable value.
For consistency, the patch makes the same change for the offset field
in a COMPONENT_REF, although I don't think that can trigger yet.
2019-12-03 Richard Sandiford <richard.sandiford@arm.com>
gcc/
* gimplify.c (gimplify_compound_lval): Don't gimplify and install
an array element size if array_element_size is already an invariant.
Similarly don't gimplify and install a field offset if
component_ref_field_offset is already an invariant.
gcc/testsuite/
* gcc.target/aarch64/sve/acle/general-c/struct_1.c: New test.
From-SVN: r278942
