- 09 Feb, 2020 1 commit
-
-
GCC Administrator committed
-
- 08 Feb, 2020 10 commits
-
-
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 -
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 -
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 -
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 -
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 -
* typeck.c (maybe_warn_about_returning_address_of_local): Add location parameter.
Jason Merrill committed -
* typeck2.c (process_init_constructor): Also clear TREE_SIDE_EFFECTS if appropriate.
Jason Merrill committed -
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 -
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 -
GCC Administrator committed
-
- 07 Feb, 2020 26 commits
-
-
gcc/po: * gcc.pot: Regenerate. libcpp/po: * cpplib.pot: Regenerate.
Joseph Myers committed -
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 -
Jason Merrill committed
-
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 -
* 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 -
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 -
[testsuite] * gcc.target/powerpc/pr92923-1.c: Add -mvsx.
Will Schmidt committed -
* include/std/ranges (iota_view): Add braces to prevent -Wempty-body warning. (basic_istream_view::_Iterator::operator++()): Add missing return.
Jonathan Wakely committed -
Patrick Palka committed
-
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 -
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 -
Patrick Palka committed
-
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 -
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 -
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 -
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 -
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 -
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 -
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 -
PR c++/89404 * g++.dg/ext/vla21.C: New.
Paolo Carlini committed -
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 -
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 -
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 -
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 -
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 -
GCC Administrator committed
-
- 06 Feb, 2020 3 commits
-
-
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 -
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 -
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
-