1. 09 Feb, 2020 1 commit
  2. 08 Feb, 2020 10 commits
    • aarch64: fix strict alignment for vector load/stores (PR 91927) · c2a4bf2d
      Hi,
        The problem here is that the vector mode version of movmisalign<mode>
      was only conditionalized on if SIMD was enabled instead of being
      also conditionalized on STRICT_ALIGNMENT too.
      
      Applied as pre-approved in the bug report by Richard Sandiford
      after a bootstrap/test on aarch64-linux-gnu.
      
      Thanks,
      Andrew Pinski
      
      ChangeLog:
      PR target/91927
      * config/aarch64/aarch64-simd.md (movmisalign<mode>): Check
      STRICT_ALIGNMENT also.
      
      testsuite/ChangeLog:
      PR target/91927
      * gcc.target/aarch64/pr91927.c: New testcase.
      Andrew Pinski committed
    • rs6000: Fix testsuite fallout from previous fix. [PR93136] · 4b39d801
      The fix for PR target/92923 exposed some test cases with fragile
      scan-assembler-times counting.  Split the test cases into smaller
      functions, which allows less chance of optimizations causing slight
      instruction count numbers.
      
      gcc/testsuite/
      	PR target/93136
      	* gcc.dg/vmx/ops.c: Add -flax-vector-conversions to dg-options.
      	* gcc.target/powerpc/vsx-vector-6.h: Split tests into smaller functions.
      	* gcc.target/powerpc/vsx-vector-6.p7.c: Adjust scan-assembler-times
      	regex directives.  Adjust expected instruction counts.
      	* gcc.target/powerpc/vsx-vector-6.p8.c: Likewise.
      	* gcc.target/powerpc/vsx-vector-6.p9.c: Likewise.
      Peter Bergner committed
    • RISC-V: Improve caller-save code generation. · b780f68e
      Avoid paradoxical subregs when caller save.  This reduces stack frame size
      due to smaller loads and stores, and more frequent rematerialization.
      
      	PR target/93532
      	* config/riscv/riscv.h (HARD_REGNO_CALLER_SAVE_MODE): Define.
      Jim Wilson committed
    • c++: Use constexpr to avoid wrong -Wsign-compare (PR90691). · aaa26bf4
      We would like to do constexpr evaluation to avoid false positives on
      warnings, but constexpr evaluation can involve function body copying that
      changes DECL_UID, which breaks -fcompare-debug.  So let's remember
      that we need to avoid that.
      
      	PR c++/90691
      	* expr.c (fold_for_warn): Call maybe_constant_value.
      	* constexpr.c (struct constexpr_ctx): Add uid_sensitive field.
      	(maybe_constant_value): Add uid_sensitive parm.
      	(get_fundef_copy): Don't copy if it's true.
      	(cxx_eval_call_expression): Don't instantiate if it's true.
      	(cxx_eval_outermost_constant_expr): Likewise.
      Jason Merrill committed
    • c++: Preserve location in maybe_constant_value. · 173c8def
      If cxx_eval_outermost_constant_expr doesn't change the argument, we really
      shouldn't unshare it when we try to fold it again.
      
      	PR c++/92852
      	* constexpr.c (maybe_constant_value): Don't unshare if the cached
      	value is the same as the argument.
      Jason Merrill committed
    • c++: Fix -Wreturn-local-addr location. · 61f5369f
      	* typeck.c (maybe_warn_about_returning_address_of_local): Add
      	location parameter.
      Jason Merrill committed
    • c++: Fix TREE_SIDE_EFFECTS after digest_init. · c151a342
      	* typeck2.c (process_init_constructor): Also clear TREE_SIDE_EFFECTS
      	if appropriate.
      Jason Merrill committed
    • c++: Handle CONSTRUCTORs without indexes in find_array_ctor_elt [PR93549] · c7c09af8
      My change
      * typeck2.c (store_init_value): Don't call cp_fully_fold_init on
      initializers of automatic non-constexpr variables in constexpr
      functions.
      -  value = cp_fully_fold_init (value);
      +  /* Don't fold initializers of automatic variables in constexpr functions,
      +     that might fold away something that needs to be diagnosed at constexpr
      +     evaluation time.  */
      +  if (!current_function_decl
      +      || !DECL_DECLARED_CONSTEXPR_P (current_function_decl)
      +      || TREE_STATIC (decl))
      +    value = cp_fully_fold_init (value);
      from the constexpr new change apparently broke the following testcase.
      When handling COND_EXPR, we build_vector_from_val, however as the argument we
      pass to it is not an INTEGER_CST/REAL_CST, but that wrapped in a
      NON_LVALUE_EXPR location wrapper, we end up with a CONSTRUCTOR and as it is
      middle-end that builds it, it doesn't bother with indexes.  The
      cp_fully_fold_init call used to fold it into VECTOR_CST in the past, but as
      we intentionally don't invoke it anymore as it might fold away something
      that needs to be diagnosed during constexpr evaluation, we end up evaluating
      ARRAY_REF into the index-less CONSTRUCTOR.  The following patch fixes the
      ICE by teaching find_array_ctor_elt to handle CONSTRUCTORs without indexes
      (that itself could be still very efficient) and CONSTRUCTORs with some
      indexes present and others missing (the rules are that if the index on the
      first element is missing, then it is the array's lowest index (in C/C++ 0)
      and if other indexes are missing, they are the index of the previous element
      + 1).
      
      Here is a new version, which assumes CONSTRUCTORs with all or none indexes
      and for CONSTRUCTORs without indexes performs the verification for
      flag_checking directly in find_array_ctor_elt.  For CONSTRUCTORs with
      indexes, it doesn't do the verification of all elts, because some CONSTRUCTORs
      can be large, and it "verifies" only what it really needs - if all elts
      touched during the binary search have indexes, that is actually all we care
      about because we are sure we found the right elt.  It is just if we see a
      missing index we need assurance that all are missing to be able to directly
      access it.
      
      The assumption then simplifies the patch, for no index CONSTRUCTORs we can
      use direct access like for CONSTRUCTORs where last elt index is equal to the
      elt position.  If we append right after the last elt, we just should clear
      the index so that we don't violate the assumption, and if we need a gap
      between the elts and the elt to be added, we need to add indexes.
      
      2020-02-08  Jakub Jelinek  <jakub@redhat.com>
      
      	PR c++/93549
      	* constexpr.c (find_array_ctor_elt): If last element has no index,
      	for flag_checking verify all elts have no index.  If i is within the
      	elts, return it directly, if it is right after the last elt, append
      	if NULL index, otherwise force indexes on all elts.
      	(cxx_eval_store_expression): Allow cep->index to be NULL.
      
      	* g++.dg/ext/constexpr-pr93549.C: New test.
      Jakub Jelinek committed
    • i386: Make xmm16-xmm31 call used even in ms ABI [PR65782] · 79ab8c43
      On Tue, Feb 04, 2020 at 11:16:06AM +0100, Uros Bizjak wrote:
      > I guess that Comment #9 patch form the PR should be trivially correct,
      > but althouhg it looks obvious, I don't want to propose the patch since
      > I have no means of testing it.
      
      I don't have means of testing it either.
      https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=vs-2019
      is quite explicit that [xyz]mm16-31 are call clobbered and only xmm6-15 (low
      128-bits only) are call preserved.
      
      We are talking e.g. about
      /* { dg-options "-O2 -mabi=ms -mavx512vl" } */
      
      typedef double V __attribute__((vector_size (16)));
      void foo (void);
      V bar (void);
      void baz (V);
      void
      qux (void)
      {
        V c;
        {
          register V a __asm ("xmm18");
          V b = bar ();
          asm ("" : "=x" (a) : "0" (b));
          c = a;
        }
        foo ();
        {
          register V d __asm ("xmm18");
          V e;
          d = c;
          asm ("" : "=x" (e) : "0" (d));
          baz (e);
        }
      }
      where according to the MSDN doc gcc incorrectly holds the c value
      in xmm18 register across the foo call; if foo is compiled by some Microsoft
      compiler (or LLVM), then it could clobber %xmm18.
      If all xmm18 occurrences are changed to say xmm15, then it is valid to hold
      the 128-bit value across the foo call (though, surprisingly, LLVM saves it
      into stack anyway).
      
      The other parts are I guess mainly about SEH.  Consider e.g.
      void
      foo (void)
      {
        register double x __asm ("xmm14");
        register double y __asm ("xmm18");
        asm ("" : "=x" (x));
        asm ("" : "=v" (y));
        x += y;
        y += x;
        asm ("" : : "x" (x));
        asm ("" : : "v" (y));
      }
      looking at cross-compiler output, with -O2 -mavx512f this emits
      	.file	"abcdeq.c"
      	.text
      	.align 16
      	.globl	foo
      	.def	foo;	.scl	2;	.type	32;	.endef
      	.seh_proc	foo
      foo:
      	subq	$40, %rsp
      	.seh_stackalloc	40
      	vmovaps %xmm14,	(%rsp)
      	.seh_savexmm	%xmm14, 0
      	vmovaps %xmm18,	16(%rsp)
      	.seh_savexmm	%xmm18, 16
      	.seh_endprologue
      	vaddsd	%xmm18, %xmm14, %xmm14
      	vaddsd	%xmm18, %xmm14, %xmm18
      	vmovaps	(%rsp), %xmm14
      	vmovaps	16(%rsp), %xmm18
      	addq	$40, %rsp
      	ret
      	.seh_endproc
      	.ident	"GCC: (GNU) 10.0.1 20200207 (experimental)"
      Does whatever assembler mingw64 uses even assemble this (I mean the
      .seh_savexmm %xmm16, 16 could be problematic)?
      I can find e.g.
      https://stackoverflow.com/questions/43152633/invalid-register-for-seh-savexmm-in-cygwin/43210527
      which then links to
      https://gcc.gnu.org/PR65782
      
      2020-02-08  Uroš Bizjak  <ubizjak@gmail.com>
      	    Jakub Jelinek  <jakub@redhat.com>
      
      	PR target/65782
      	* config/i386/i386.h (CALL_USED_REGISTERS): Make
      	xmm16-xmm31 call-used even in 64-bit ms-abi.
      
      	* gcc.target/i386/pr65782.c: New test.
      
      Co-authored-by: Uroš Bizjak <ubizjak@gmail.com>
      Jakub Jelinek committed
    • Daily bump. · 561d91dc
      GCC Administrator committed
  3. 07 Feb, 2020 26 commits
    • Regenerate .pot files. · 8633545d
      gcc/po:
      	* gcc.pot: Regenerate.
      
      libcpp/po:
      	* cpplib.pot: Regenerate.
      Joseph Myers committed
    • c++: Fix paren init of aggregates in unevaluated context [PR92947] · ac6eaa55
      When I implemented C++20 parenthesized initialization of aggregates
      I introduced this bogus cp_unevaluated_operand check, thus disabling
      this feature in unevaluated context.  Oop.
      
      Removing the check turned up another bug: I wasn't checking the
      return value of digest_init.  So when constructible_expr called
      build_new_method_call_1 to see if we can construct one type from
      another, it got back a bogus INIT_EXPR that looked something like
      *(struct T &) 1 = <<< error >>>.  But that isn't the error_mark_node,
      so constructible_expr thought we had been successful in creating the
      ctor call, and it gave the wrong answer.  Covered by paren-init17.C.
      
      	PR c++/92947 - Paren init of aggregates in unevaluated context.
      	* call.c (build_new_method_call_1): Don't check
      	cp_unevaluated_operand.  Check the return value of digest_init.
      
      	* g++.dg/cpp2a/paren-init21.C: New test.
      Marek Polacek committed
    • c++: Fix use of local in constexpr if. · 1e042b39
      extract_local_specs wasn't finding the mention of 'an' as a template
      argument because we weren't walking into template arguments.  So here I
      changed cp_walk_subtrees to do so--only walking into template arguments in
      the spelling of the type or expression, not any hidden behind typedefs.  The
      change to use typedef_variant_p avoids looking through typedefs spelled with
      'typedef' as well as those spelled with 'using'.  And then I removed some
      now-redundant code for walking into template arguments in a couple of
      walk_tree callbacks.
      
      	PR c++/92654
      	* tree.c (cp_walk_subtrees): Walk into type template arguments.
      	* cp-tree.h (TYPE_TEMPLATE_INFO_MAYBE_ALIAS): Use typedef_variant_p
      	instead of TYPE_ALIAS_P.
      	* pt.c (push_template_decl_real): Likewise.
      	(find_parameter_packs_r): Likewise.  Remove dead code.
      	* error.c (find_typenames_r): Remove dead code.
      Jason Merrill committed
    • libstdc++: Implement P1878R1 "Constraining Readable Types" · c8dd2446
      	* include/bits/iterator_concepts.h (iter_difference_t, iter_value_t):
      	Use remove_cvref_t.
      	(readable_traits): Rename to indirectly_readable_traits.
      	(readable): Rename to indirectly_readable.
      	(writable): Rename to indirectly_writable.
      	(__detail::__iter_exchange_move): Do not use remove_reference_t.
      	(indirectly_swappable): Adjust requires expression parameter types.
      	expression.
      	* include/bits/ranges_algo.h (ranges::transform, ranges::replace)
      	(ranges::replace_if, ranges::generate_n, ranges::generate)
      	(ranges::remove): Use new name for writable.
      	* include/bits/stl_iterator.h (__detail::__common_iter_has_arrow):
      	Use new name for readable.
      	* include/ext/pointer.h (readable_traits<_Pointer_adapter<P>>): Use
      	new name for readable_traits.
      	* testsuite/24_iterators/associated_types/readable.traits.cc: Likewise.
      	* testsuite/24_iterators/indirect_callable/projected.cc: Adjust for
      	new definition of indirectly_readable.
      Jonathan Wakely committed
    • libstdc++: Fix bug in iterator_traits<common_iterator<S,I>> · d222d8ec
      The wrong type was being used in the __common_iter_has_arrow constraint,
      creating a circular dependency where the iterator_traits specialization
      was needed before it was complete. The correct parameter for the
      __common_iter_has_arrow concept is the first template argument of  the
      common_iterator, not the common_iterator itself.
      
      	* include/bits/stl_iterator.h (__detail::__common_iter_ptr): Change
      	to take parameters of common_iterator, instead of the common_iterator
      	type itself. Fix argument for __common_iter_has_arrow constraint.
      	(iterator_traits<common_iterator<I, S>>::pointer): Adjust.
      Jonathan Wakely committed
    • [PATCH] add -mvsx to pr92923-1.c test requiring vsx · 6fa476f6
          [testsuite]
      	  * gcc.target/powerpc/pr92923-1.c: Add -mvsx.
      Will Schmidt committed
    • libstdc++ Fix missing return in istream_view iterator · 572992c8
      	* include/std/ranges (iota_view): Add braces to prevent -Wempty-body
      	warning.
      	(basic_istream_view::_Iterator::operator++()): Add missing return.
      Jonathan Wakely committed
    • aarch64: ACLE I8MM multiply-accumulate intrinsics · 40f64837
      This patch adds intrinsics for 8-bit integer matrix multiply-accumulate
      operations including vmmlaq_s32, vmmlaq_u32, and vusmmlaq_s32.
      
      gcc/ChangeLog:
      
      2020-02-07  Dennis Zhang  <dennis.zhang@arm.com>
      
      	* config/aarch64/aarch64-simd-builtins.def (simd_smmla): New entry.
      	(simd_ummla, simd_usmmla): Likewise.
      	* config/aarch64/aarch64-simd.md (aarch64_simd_<sur>mmlav16qi): New.
      	* config/aarch64/arm_neon.h (vmmlaq_s32, vmmlaq_u32): New.
      	(vusmmlaq_s32): New.
      
      gcc/testsuite/ChangeLog:
      
      2020-02-07  Dennis Zhang  <dennis.zhang@arm.com>
      
      	* gcc.target/aarch64/simd/vmmla.c: New test.
      Dennis Zhang committed
    • libstdc++: Add [range.istream] · b7903d9f
      This patch adds ranges::basic_istream_view and ranges::istream_view.  This seems
      to be the last missing part of the ranges header.
      
      libstdc++-v3/ChangeLog:
      
      	* include/std/ranges (ranges::__detail::__stream_extractable,
      	ranges::basic_istream_view, ranges::istream_view): Define.
      	* testsuite/std/ranges/istream_view: New test.
      Patrick Palka committed
    • libstdc++: Implement C++20 range adaptors · cba9ef06
      This patch implements [range.adaptors].  It also includes the changes from P3280
      and P3278 and P3323, without which many standard examples won't work.
      
      The implementation is mostly dictated by the spec and there was not much room
      for implementation discretion.  The most interesting part that was not specified
      by the spec is the design of the range adaptors and range adaptor closures,
      which I tried to design in a way that minimizes boilerplate and statefulness (so
      that e.g. the composition of two stateless closures is stateless).
      
      What is left unimplemented is caching of calls to begin() in filter_view,
      drop_view and reverse_view, which is required to guarantee that begin() has
      amortized constant time complexity.  I can implement this in a subsequent patch.
      
      "Interesting" parts of the patch are marked with XXX comments.
      
      libstdc++-v3/ChangeLog:
      
      	Implement C++20 range adaptors
      	* include/std/ranges: Include <bits/refwrap.h> and <tuple>.
      	(subrange::_S_store_size): Mark as const instead of constexpr to
      	avoid what seems to be a bug in GCC.
      	(__detail::__box): Give it defaulted copy and move constructors.
      	(views::_Single::operator()): Mark constexpr.
      	(views::_Iota::operator()): Mark constexpr.
      	(__detail::Empty): Define.
      	(views::_RangeAdaptor, views::_RangeAdaptorClosure, ref_view, all_view,
      	views::all, filter_view, views::filter, transform_view,
      	views::transform, take_view, views::take, take_while_view,
      	views::take_while, drop_view, views::drop, join_view, views::join,
      	__detail::require_constant, __detail::tiny_range, split_view,
      	views::split, views::_Counted, views::counted, common_view,
      	views::common, reverse_view, views::reverse,
      	views::__detail::__is_reversible_subrange,
      	views::__detail::__is_reverse_view, reverse_view, views::reverse,
      	__detail::__has_tuple_element, elements_view, views::elements,
      	views::keys, views::values): Define.
      	* testsuite/std/ranges/adaptors/all.cc: New test.
      	* testsuite/std/ranges/adaptors/common.cc: Likewise.
      	* testsuite/std/ranges/adaptors/counted.cc: Likewise.
      	* testsuite/std/ranges/adaptors/drop.cc: Likewise.
      	* testsuite/std/ranges/adaptors/drop_while.cc: Likewise.
      	* testsuite/std/ranges/adaptors/elements.cc: Likewise.
      	* testsuite/std/ranges/adaptors/filter.cc: Likewise.
      	* testsuite/std/ranges/adaptors/join.cc: Likewise.
      	* testsuite/std/ranges/adaptors/reverse.cc: Likewise.
      	* testsuite/std/ranges/adaptors/split.cc: Likewise.
      	* testsuite/std/ranges/adaptors/take.cc: Likewise.
      	* testsuite/std/ranges/adaptors/take_while.cc: Likewise.
      	* testsuite/std/ranges/adaptors/transform.cc: Likewise.
      Patrick Palka committed
    • libstdc++: Optimize C++20 comparison category types · 0d57370c
      This reduces the size and alignment of all three comparison category
      types to a single byte. The partial_ordering::_M_is_ordered flag is
      replaced by the value 0x02 in the _M_value member.
      
      This also optimizes conversion and comparison operators to avoid
      conditional branches where possible, by comparing _M_value to constants
      or using bitwise operations to correctly handle the unordered state.
      
      	* libsupc++/compare (__cmp_cat::type): Define typedef for underlying
      	type of enumerations and comparison category types.
      	(__cmp_cat::_Ord, __cmp_cat::_Ncmp): Add underlying type.
      	(__cmp_cat::_Ncmp::unordered): Change value to 2.
      	(partial_ordering::_M_value, weak_ordering::_M_value)
      	(strong_ordering::_M_value): Change type to __cmp_cat::type.
      	(partial_ordering::_M_is_ordered): Remove data member.
      	(partial_ordering): Use second bit of _M_value for unordered. Adjust
      	comparison operators.
      	(weak_ordering::operator partial_ordering): Simplify to remove
      	branches.
      	(operator<=>(unspecified, weak_ordering)): Likewise.
      	(strong_ordering::operator partial_ordering): Likewise.
      	(strong_ordering::operator weak_ordering): Likewise.
      	(operator<=>(unspecified, strong_ordering)): Likewise.
      	* testsuite/18_support/comparisons/categories/partialord.cc: New test.
      	* testsuite/18_support/comparisons/categories/strongord.cc: New test.
      	* testsuite/18_support/comparisons/categories/weakord.cc: New test.
      Jonathan Wakely committed
    • c++: Fix ICE on nonsense requires-clause. · 82aee6dd
      Here we were swallowing all the syntax errors by parsing tentatively, and
      returning error_mark_node without ever actually giving an error.  Fixed by
      using save_tokens/rollback_tokens instead.
      
      	PR c++/92517
      	* parser.c (cp_parser_constraint_primary_expression): Do the main
      	parse non-tentatively.
      Jason Merrill committed
    • middle-end/93519 - avoid folding stmts in obviously unreachable code · 3c7a03bc
      The inliner folds stmts delayed, the following arranges things so
      to not fold stmts that are obviously not reachable to avoid warnings
      from those code regions.
      
      2020-02-07  Richard Biener  <rguenther@suse.de>
      
      	PR middle-end/93519
      	* tree-inline.c (fold_marked_statements): Do a PRE walk,
      	skipping unreachable regions.
      	(optimize_inline_calls): Skip folding stmts when we didn't
      	inline.
      
      	* gcc.dg/Wrestrict-21.c: New testcase.
      Richard Biener committed
    • libstdc++: Enable three-way comparison for iota_view iterators · 5713834e
      The declaration of operator<=> was disabled due to a typo in the macro.
      The declaration was also ill-formed when three_way_comparable<_Winc> is
      not satisfied, which is a defect in the C++20 draft.
      
      	* include/std/ranges (iota_view::_Iterator): Fix typo in name of
      	__cpp_lib_three_way_comparison macro and use deduced return type for
      	operator<=>.
      	* testsuite/std/ranges/iota/iterator.cc: New test.
      Jonathan Wakely committed
    • x86-64: Pass aggregates with only float/double in GPRs for MS_ABI · ea5ca698
      MS_ABI requires passing aggregates with only float/double in integer
      registers as shown in the output from MSVC v19.10 at:
      
      https://godbolt.org/z/2NPygd
      
      This patch fixed:
      
      FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=54 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 -DABI_NUM=FFI_GNUW64 -DABI_ATTR=MSABI execution test
      FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=54 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -DABI_NUM=FFI_GNUW64 -DABI_ATTR=MSABI execution test
      FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 -DABI_NUM=FFI_GNUW64 -DABI_ATTR=MSABI execution test
      FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -DABI_NUM=FFI_GNUW64 -DABI_ATTR=MSABI execution test
      FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 -DABI_NUM=FFI_GNUW64 -DABI_ATTR=MSABI execution test
      FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -DABI_NUM=FFI_GNUW64 -DABI_ATTR=MSABI execution test
      
      in libffi testsuite.
      
      gcc/
      
      	PR target/85667
      	* config/i386/i386.c (function_arg_ms_64): Add a type argument.
      	Don't return aggregates with only SFmode and DFmode in SSE
      	register.
      	(ix86_function_arg): Pass arg.type to function_arg_ms_64.
      
      gcc/testsuite/
      
      	PR target/85667
      	* gcc.target/i386/pr85667-10.c: New test.
      	* gcc.target/i386/pr85667-7.c: Likewise.
      	* gcc.target/i386/pr85667-8.c: Likewise.
      	* gcc.target/i386/pr85667-9.c: Likewise.
      H.J. Lu committed
    • powerpc: Fix -fstack-clash-protection -mprefixed-addr ICE [PR93122] · c006911d
      As mentioned in the PR, the following testcase ICEs because rs, while valid
      add_operand is not valid add_cint_operand and so gen_add3_insn fails,
      because it doesn't meet the expander predicates.
      
      Here is what I meant as the alternative, i.e. don't check any predicates,
      just gen_add3_insn, if that fails, force rs into register and retry.
      And, add REG_FRAME_RELATED_EXPR note always when we haven't emitted a single
      insn that has rtl exactly matching what we'd add the REG_FRAME_RELATED_EXPR
      with (in that case, dwarf2cfi.c is able to figure it out by itself, no need
      to waste compile time memory).
      
      2020-02-07  Jakub Jelinek  <jakub@redhat.com>
      
      	PR target/93122
      	* config/rs6000/rs6000-logue.c
      	(rs6000_emit_probe_stack_range_stack_clash): Always use gen_add3_insn,
      	if it fails, move rs into end_addr and retry.  Add
      	REG_FRAME_RELATED_EXPR note whenever it returns more than one insn or
      	the insn pattern doesn't describe well what exactly happens to
      	dwarf2cfi.c.
      
      	* gcc.target/powerpc/pr93122.c: New test.
      Jakub Jelinek committed
    • Add testcase of PR c++/89404, already fixed in trunk. · c58e6cc3
      	PR c++/89404
      	* g++.dg/ext/vla21.C: New.
      Paolo Carlini committed
    • arm: Fix up arm installed unwind.h for use in pedantic modes [PR93615] · 811a475e
      As the following testcase shows, unwind.h on ARM can't be (starting with GCC
      10) compiled with -std=c* modes, only -std=gnu* modes.
      The problem is it uses asm keyword, which isn't a keyword in those modes
      (system headers vs. non-system ones don't make a difference here).
      glibc and other installed headers use __asm or __asm__ keywords instead that
      work fine in both standard and gnu modes.
      
      While there, as it is an installed header, I think it is also wrong to
      completely ignore any identifier namespace rules.
      The generic unwind.h defines just _Unwind* namespace identifiers plus
      _sleb128_t/_uleb128_t (but e.g. unlike libstdc++/glibc headers doesn't
      uglify operand names), the ARM unwind.h is much worse here.  I've just
      changed the gnu_Unwind_Find_got function at least not be in user identifier
      namespace, but perhaps it would be good to go further and rename e.g.
      or e.g.
        typedef _Unwind_Reason_Code (*personality_routine) (_Unwind_State,
            _Unwind_Control_Block *, _Unwind_Context *);
      in unwind-arm-common.h.
      
      2020-02-07  Jakub Jelinek  <jakub@redhat.com>
      
      	PR target/93615
      	* config/arm/unwind-arm.h (gnu_Unwind_Find_got): Rename to ...
      	(_Unwind_gnu_Find_got): ... this.  Use __asm instead of asm.  Remove
      	trailing :s in asm.  Formatting fixes.
      	(_Unwind_decode_typeinfo_ptr): Adjust caller.
      
      	* gcc.dg/pr93615.c: New test.
      Jakub Jelinek committed
    • i386: Better patch to improve avx* vector concatenation [PR93594] · f82617f2
      After thinking some more on this, we can do better; rather than having to
      add a new prereload splitter pattern to catch all other cases where it might
      be beneficial to fold first part of an UNSPEC_CAST back to the unspec
      operand, this patch reverts the *.md changes I've made yesterday and instead
      tweaks the patterns, so that simplify-rtx.c can optimize those on its own.
      Instead of the whole SET_SRC being an UNSPEC through which simplify-rtx.c
      obviously can't optimize anything, this represents those patterns through a
      VEC_CONCAT (or two nested ones for the 128-bit -> 512-bit casts) with the
      operand as the low part of it and UNSPEC representing just the high part of
      it (the undefined, to be ignored, bits).  While richi suggested using
      already in GIMPLE for those using a SSA_NAME default definition (i.e.
      clearly uninitialized use), I'd say that uninit pass would warn about those,
      but more importantly, in RTL it would probably force zero initialization of
      that or use or an uninitialized pseudo, all of which is hard to match in an
      pattern, so I think an UNSPEC is better for that.
      
      2020-02-07  Jakub Jelinek  <jakub@redhat.com>
      
      	PR target/93594
      	* config/i386/predicates.md (avx_identity_operand): Remove.
      	* config/i386/sse.md (*avx_vec_concat<mode>_1): Remove.
      	(avx_<castmode><avxsizesuffix>_<castmode>,
      	avx512f_<castmode><avxsizesuffix>_256<castmode>): Change patterns to
      	a VEC_CONCAT of the operand and UNSPEC_CAST.
      	(avx512f_<castmode><avxsizesuffix>_<castmode>): Change pattern to
      	a VEC_CONCAT of VEC_CONCAT of the operand and UNSPEC_CAST with
      	UNSPEC_CAST.
      Jakub Jelinek committed
    • i386: Fix splitters that call extract_insn_cached [PR93611] · e7bec5d5
      The following testcase ICEs.  The generated split_insns starts
      with recog_data.insn = NULL and then tries to put various operands into
      recog_data.operand array and checks various splitter conditions.
      The problem is that some atom related tuning splitters indirectly call
      extract_insn_cached on the insn they are used in.  This can change
      recog_data.operand, but most likely it will just keep it as is, but
      sets recog_data.insn to the current instruction.  If that splitter doesn't
      match, we continue trying some other split conditions and modify
      recog_data.operand array again.  If even that doesn't find any usable
      splitter, we punt, but at that point recog_data.insn says that recog_data
      is valid for that particular instruction, even when recog_data.operand array
      can be anything.
      The safest thing would be to copy whole recog_data to a temporary object
      before doing the calls that can call extract_insn_cached and restore it
      afterwards, but it would be also very costly, recog_data has 1280 bytes.
      So, this patch just makes sure to clear recog_data.insn if it has changed
      during the extract_insn_cached call, which means if we extract_insn_cached
      later, we'll extract it properly, while if we call it say from some other
      context than splitter conditions, the insn is already cached, we don't reset
      the cache.
      
      2020-02-07  Jakub Jelinek  <jakub@redhat.com>
      
      	PR target/93611
      	* config/i386/i386.c (ix86_lea_outperforms): Make sure to clear
      	recog_data.insn if distance_non_agu_define changed it.
      
      	* gcc.target/i386/pr93611.c: New test.
      Jakub Jelinek committed
    • libstdc++: Implement C++20 constrained algorithms · bc464641
      This patch implements the C++20 ranges overloads for the algorithms in
      [algorithms].  Most of the algorithms were reimplemented, with each of their
      implementations very closely following the existing implementation in
      bits/stl_algo.h and bits/stl_algobase.h.  The reason for reimplementing most of
      the algorithms instead of forwarding to their STL-style overload is because
      forwarding cannot be conformantly and efficiently performed for algorithms that
      operate on non-random-access iterators.  But algorithms that operate on random
      access iterators can safely and efficiently be forwarded to the STL-style
      implementation, and this patch does so for push_heap, pop_heap, make_heap,
      sort_heap, sort, stable_sort, nth_element, inplace_merge and stable_partition.
      
      What's missing from this patch is debug-iterator and container specializations
      that are present for some of the STL-style algorithms that need to be ported
      over to the ranges algos.  I marked them missing at TODO comments.  There are
      also some other minor outstanding TODOs.
      
      The code that could use the most thorough review is ranges::__copy_or_move,
      ranges::__copy_or_move_backward, ranges::__equal and
      ranges::__lexicographical_compare.  In the tests, I tried to test the interface
      of each new overload, as well as the correctness of the new implementation.
      
      libstdc++-v3/ChangeLog:
      
      	Implement C++20 constrained algorithms
      	* include/Makefile.am: Add new header.
      	* include/Makefile.in: Regenerate.
      	* include/std/algorithm: Include <bits/ranges_algo.h>.
      	* include/bits/ranges_algo.h: New file.
      	* testsuite/25_algorithms/adjacent_find/constrained.cc: New test.
      	* testsuite/25_algorithms/all_of/constrained.cc: New test.
      	* testsuite/25_algorithms/any_of/constrained.cc: New test.
      	* testsuite/25_algorithms/binary_search/constrained.cc: New test.
      	* testsuite/25_algorithms/copy/constrained.cc: New test.
      	* testsuite/25_algorithms/copy_backward/constrained.cc: New test.
      	* testsuite/25_algorithms/copy_if/constrained.cc: New test.
      	* testsuite/25_algorithms/copy_n/constrained.cc: New test.
      	* testsuite/25_algorithms/count/constrained.cc: New test.
      	* testsuite/25_algorithms/count_if/constrained.cc: New test.
      	* testsuite/25_algorithms/equal/constrained.cc: New test.
      	* testsuite/25_algorithms/equal_range/constrained.cc: New test.
      	* testsuite/25_algorithms/fill/constrained.cc: New test.
      	* testsuite/25_algorithms/fill_n/constrained.cc: New test.
      	* testsuite/25_algorithms/find/constrained.cc: New test.
      	* testsuite/25_algorithms/find_end/constrained.cc: New test.
      	* testsuite/25_algorithms/find_first_of/constrained.cc: New test.
      	* testsuite/25_algorithms/find_if/constrained.cc: New test.
      	* testsuite/25_algorithms/find_if_not/constrained.cc: New test.
      	* testsuite/25_algorithms/for_each/constrained.cc: New test.
      	* testsuite/25_algorithms/generate/constrained.cc: New test.
      	* testsuite/25_algorithms/generate_n/constrained.cc: New test.
      	* testsuite/25_algorithms/heap/constrained.cc: New test.
      	* testsuite/25_algorithms/includes/constrained.cc: New test.
      	* testsuite/25_algorithms/inplace_merge/constrained.cc: New test.
      	* testsuite/25_algorithms/is_partitioned/constrained.cc: New test.
      	* testsuite/25_algorithms/is_permutation/constrained.cc: New test.
      	* testsuite/25_algorithms/is_sorted/constrained.cc: New test.
      	* testsuite/25_algorithms/is_sorted_until/constrained.cc: New test.
      	* testsuite/25_algorithms/lexicographical_compare/constrained.cc: New
      	test.
      	* testsuite/25_algorithms/lower_bound/constrained.cc: New test.
      	* testsuite/25_algorithms/max/constrained.cc: New test.
      	* testsuite/25_algorithms/max_element/constrained.cc: New test.
      	* testsuite/25_algorithms/merge/constrained.cc: New test.
      	* testsuite/25_algorithms/min/constrained.cc: New test.
      	* testsuite/25_algorithms/min_element/constrained.cc: New test.
      	* testsuite/25_algorithms/minmax/constrained.cc: New test.
      	* testsuite/25_algorithms/minmax_element/constrained.cc: New test.
      	* testsuite/25_algorithms/mismatch/constrained.cc: New test.
      	* testsuite/25_algorithms/move/constrained.cc: New test.
      	* testsuite/25_algorithms/move_backward/constrained.cc: New test.
      	* testsuite/25_algorithms/next_permutation/constrained.cc: New test.
      	* testsuite/25_algorithms/none_of/constrained.cc: New test.
      	* testsuite/25_algorithms/nth_element/constrained.cc: New test.
      	* testsuite/25_algorithms/partial_sort/constrained.cc: New test.
      	* testsuite/25_algorithms/partial_sort_copy/constrained.cc: New test.
      	* testsuite/25_algorithms/partition/constrained.cc: New test.
      	* testsuite/25_algorithms/partition_copy/constrained.cc: New test.
      	* testsuite/25_algorithms/partition_point/constrained.cc: New test.
      	* testsuite/25_algorithms/prev_permutation/constrained.cc: New test.
      	* testsuite/25_algorithms/remove/constrained.cc: New test.
      	* testsuite/25_algorithms/remove_copy/constrained.cc: New test.
      	* testsuite/25_algorithms/remove_copy_if/constrained.cc: New test.
      	* testsuite/25_algorithms/remove_if/constrained.cc: New test.
      	* testsuite/25_algorithms/replace/constrained.cc: New test.
      	* testsuite/25_algorithms/replace_copy/constrained.cc: New test.
      	* testsuite/25_algorithms/replace_copy_if/constrained.cc: New test.
      	* testsuite/25_algorithms/replace_if/constrained.cc: New test.
      	* testsuite/25_algorithms/reverse/constrained.cc: New test.
      	* testsuite/25_algorithms/reverse_copy/constrained.cc: New test.
      	* testsuite/25_algorithms/rotate/constrained.cc: New test.
      	* testsuite/25_algorithms/rotate_copy/constrained.cc: New test.
      	* testsuite/25_algorithms/search/constrained.cc: New test.
      	* testsuite/25_algorithms/search_n/constrained.cc: New test.
      	* testsuite/25_algorithms/set_difference/constrained.cc: New test.
      	* testsuite/25_algorithms/set_intersection/constrained.cc: New test.
      	* testsuite/25_algorithms/set_symmetric_difference/constrained.cc: New
      	test.
      	* testsuite/25_algorithms/set_union/constrained.cc: New test.
      	* testsuite/25_algorithms/shuffle/constrained.cc: New test.
      	* testsuite/25_algorithms/sort/constrained.cc: New test.
      	* testsuite/25_algorithms/stable_partition/constrained.cc: New test.
      	* testsuite/25_algorithms/stable_sort/constrained.cc: New test.
      	* testsuite/25_algorithms/swap_ranges/constrained.cc: New test.
      	* testsuite/25_algorithms/transform/constrained.cc: New test.
      	* testsuite/25_algorithms/unique/constrained.cc: New test.
      	* testsuite/25_algorithms/unique_copy/constrained.cc: New test.
      	* testsuite/25_algorithms/upper_bound/constrained.cc: New test.
      Patrick Palka committed
    • analyzer: fix reproducer for PR 93375 · 13f5b93e
      Reproducing the ICE in PR analyzer/93375 required some kind of
      analyzer diagnostic occurring after a call with fewer arguments
      than required by the callee.
      
      The testcase used __builtin_memcpy with a NULL argument for this.
      
      On x86_64-pc-linux-gnu this happened to be already optimized into:
        _4 = MEM <unsigned int> [(char * {ref-all})0B];
        MEM <unsigned int> [(char * {ref-all})rl_1] = _4;
      by the time of the analyzer pass, leading to the diagnostic in question
      being:
        warning: dereference of NULL ‘rl’ [CWE-690] [-Wanalyzer-null-dereference]
      
      On other targets e.g. arm-unknown-linux-gnueabi, the builtin isn't
      optimized at the time of the analyzer pass, leading to this diagnostic
      instead:
        warning: use of NULL ‘rl’ where non-null expected [CWE-690] [-Wanalyzer-null-argument]
        <built-in>: note: argument 1 of ‘__builtin_memcpy’ must be non-null
      
      This patch fixes the test case by using a custom function marked as
      nonnull.  I manually verified that it still reproduces the ICE if the
      patch for the PR is reverted.
      
      gcc/testsuite/ChangeLog:
      	PR analyzer/93375
      	* gcc.dg/analyzer/pr93375.c: Rework test case to avoid per-target
      	differences in how __builtin_memcpy has been optimized at the time
      	the analyzer runs.
      David Malcolm committed
    • Daily bump. · e032e7a9
      GCC Administrator committed
  4. 06 Feb, 2020 3 commits
    • Fix PR 93569. · a66219dc
      2020-02-06  Michael Meissner  <meissner@linux.ibm.com>
      
      	PR target/93569
      	* config/rs6000/rs6000.c (reg_to_non_prefixed): Before ISA 3.0
      	we only had X-FORM (reg+reg) addressing for vectors.  Also before
      	ISA 3.0, we only had X-FORM addressing for scalars in the
      	traditional Altivec registers.
      Michael Meissner committed
    • PR93561 -- [bounds checking] memory overflow for spill_for · d26f37a1
      2020-02-06  <zhongyunde@huawei.com>
        	    Vladimir Makarov  <vmakarov@redhat.com>
      
      	PR rtl-optimization/93561
      	* lra-assigns.c (spill_for): Check that tested hard regno is not out of
      	hard register range.
      Vladimir N. Makarov committed
    • analyzer: round-trip pointer-equality through intptr_t · cb273d81
      When investigating how the analyzer handles malloc/free of Cray pointers
      in gfortran I noticed that that analyzer was losing information on
      pointers that were cast to an integer type, and then back to a pointer
      type again.
      
      The root cause is that region_model::maybe_cast_1 was only preserving
      the region_svalue-ness of the result if both types were pointers,
      instead returning an unknown_svalue for a pointer-to-int cast.
      
      This patch updates the above code so that it attempts to use a
      region_svalue if *either* type is a pointer
      
      Doing so allows the analyzer to recognize that the same underlying
      region is in use through various casts through integer types.
      
      gcc/analyzer/ChangeLog:
      	* region-model.cc (region_model::maybe_cast_1): Attempt to provide
      	a region_svalue if either type is a pointer, rather than if both
      	types are pointers.
      
      gcc/testsuite/ChangeLog:
      	* gcc.dg/analyzer/torture/intptr_t.c: New test.
      David Malcolm committed