finish_bitfield_representative has an early out if the field after a
bitfield has error_mark_node type, but that early out leads to TREE_TYPE
of the DECL_BIT_FIELD_REPRESENTATIVE being NULL, which breaks assumptions
on code that uses the DECL_BIT_FIELD_REPRESENTATIVE during error-recovery.
The following patch instead sets TREE_TYPE of the representative to
error_mark_node, something the users can deal with better. At this point
the representative can be set as DECL_BIT_FIELD_REPRESENTATIVE for multiple
bitfields, so making sure that we clear the DECL_BIT_FIELD_REPRESENTATIVE
instead would be harder (but doable, e.g. with the error_mark_node TREE_TYPE
set by this patch set some flag in the caller and if the flag is there, walk
all the fields once again and clear all DECL_BIT_FIELD_REPRESENTATIVE that
have error_mark_node TREE_TYPE).
2021-06-24 Jakub Jelinek <jakub@redhat.com>
PR middle-end/101172
* stor-layout.c (finish_bitfield_representative): If nextf has
error_mark_node type, set repr type to error_mark_node too.
* gcc.dg/pr101172.c: New test.
(cherry picked from commit 65371066d8967560e3508af4a804e0ddb90acee7)
This is the alias CTAD version of the CTAD bug PR93248, and the fix is
the same: clear cp_unevaluated_operand so that the entire chain of
DECL_ARGUMENTS gets substituted.
PR c++/101233
gcc/cp/ChangeLog:
* pt.c (alias_ctad_tweaks): Clear cp_unevaluated_operand for
substituting DECL_ARGUMENTS.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/class-deduction-alias10.C: New test.
(cherry picked from commit a8b3861496bffae8b813ea196c1c5b27f79fbe69)
This PR is about CTAD but the underlying problems are more general;
CTAD is a good trigger for them because of the necessary substitution
into constraints that deduction guide generation entails.
In the testcase below, when generating the implicit deduction guide for
the constrained constructor template for A, we substitute the generic
flattening map 'tsubst_args' into the constructor's constraints. During
this substitution, tsubst_pack_expansion returns a rebuilt pack
expansion for sizeof...(xs), but doesn't carry over the
PACK_EXPANSION_LOCAL_P (and PACK_EXPANSION_SIZEOF_P) flag from the
original tree to the rebuilt one. The flag is otherwise unset on the
original tree but gets set for the rebuilt tree from make_pack_expansion
since at_function_scope_p() is true (we're inside main). This leads to
a crash during satisfaction when substituting into the pack expansion
because we don't have local_specializations set up (and it'd be set up
for us if PACK_EXPANSION_LOCAL_P is unset)
Similarly, tsubst_constraint needs to set cp_unevaluated so that the
substitution performed therein doesn't rely on local_specializations.
This avoids a crash during CTAD for C below.
gcc/cp/ChangeLog:
PR c++/100138
* constraint.cc (tsubst_constraint): Set up cp_unevaluated.
(satisfy_atom): Set up iloc_sentinel before calling
cxx_constant_value.
* pt.c (tsubst_pack_expansion): When returning a rebuilt pack
expansion, carry over PACK_EXPANSION_LOCAL_P and
PACK_EXPANSION_SIZEOF_P from the original pack expansion.
gcc/testsuite/ChangeLog:
PR c++/100138
* g++.dg/cpp2a/concepts-ctad4.C: New test.
(cherry picked from commit e7a9f085ffd34b0d7bc4b803c182b41494f609aa)
By changing __cust_access::__decay_copy from a function template to a
function object we avoid ADL. That means it's fine to call it
unqualified (the compiler won't waste time doing ADL in associated
namespaces, and won't try to complete associated types).
This also makes some other minor simplications to other concepts for the
[range.access] CPOs.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* include/bits/iterator_concepts.h (__cust_access::__decay_copy):
Replace with function object.
(__cust_access::__member_begin, ___cust_access::_adl_begin): Use
__decay_copy unqualified.
* include/bits/ranges_base.h (__member_end, __adl_end):
Likewise. Use __range_iter_t for type of ranges::begin.
(__member_rend): Use correct value category for rbegin argument.
(__member_data): Use __decay_copy unqualified.
(__begin_data): Use __range_iter_t for type of ranges::begin.
(cherry picked from commit cb326a6442f09cb36b05ce556fc91e10bfeb0cf6)
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* include/experimental/simd: Do not define anything pre-C++17.
(cherry picked from commit 36adced3b6b7cae17d7b42e4573bd0f4194b1f70)
Add red_zone_used to machine_function to track if red zone is used.
When expanding function prologue, set red_zone_used to true if red
zone is used.
gcc/
PR target/101023
* config/i386/i386.c (ix86_expand_prologue): Set red_zone_used
to true if red zone is used.
(ix86_output_indirect_jmp): Replace ix86_red_zone_size with
ix86_red_zone_used.
* config/i386/i386.h (machine_function): Add red_zone_used.
(ix86_red_zone_size): Removed.
(ix86_red_zone_used): New.
* config/i386/i386.md (peephole2 patterns): Replace
ix86_red_zone_size with ix86_red_zone_used.
gcc/testsuite/
PR target/101023
* g++.target/i386/pr101023a.C: New test.
* g++.target/i386/pr101023b.C: Likewise.
(cherry picked from commit 3f04e3782536ad2f9cfbb8cfe6630e9f9dd8af4c)
UINTR is available only in 64-bit mode. Since the codegen target is
unknown when the the gcc driver is processing -march=native, to properly
handle UINTR for -march=native:
1. Pass "arch [32|64]" and "tune [32|64]" to host_detect_local_cpu to
indicate 32-bit and 64-bit codegen.
2. Change ix86_option_override_internal to enable UINTR only in 64-bit
mode for -march=CPU when PTA_CPU includes PTA_UINTR.
gcc/
PR target/101395
* config/i386/driver-i386.c (host_detect_local_cpu): Check
"arch [32|64]" and "tune [32|64]" for 32-bit and 64-bit codegen.
Enable UINTR only for 64-bit codegen.
* config/i386/i386-options.c
(ix86_option_override_internal::DEF_PTA): Skip PTA_UINTR if not
in 64-bit mode.
* config/i386/i386.h (ARCH_ARG): New.
(CC1_CPU_SPEC): Pass "[arch|tune] 32" for 32-bit codegen and
"[arch|tune] 64" for 64-bit codegen.
gcc/testsuite/
PR target/101395
* gcc.target/i386/pr101395-1.c: New test.
* gcc.target/i386/pr101395-2.c: Likewise.
* gcc.target/i386/pr101395-3.c: Likewise.
(cherry picked from commit cc11b924bfe7752edbba052ca71653f46a60887a)
The driver amends assembler options with for example --gdwarf-5
when debugging is enabled but the check for that does not consider
the effect of -gtoggle which is not handled in the common option
machinery. The following alters debug_info_level according to
-gtoggle mimicing what process_options later does in the compiler.
This in particular avoids changing of the cc1-checksum with every
bootstrap (debug) cycle as we compute that from stage2 where we
use -g -gtoggle but with --gdwarf-5 and no debug info from the
compiler the assembler will fill the line table with the temporary
assembler file names.
2021-07-09 Richard Biener <rguenther@suse.de>
PR driver/101383
* gcc.c (process_command): Process -gtoggle like process_options
would after parsing options.
(cherry picked from commit 4f3b383cf8825197e714a4a21852eca071f8e67e)
Signed 1 bit values have a range of [-1, 0] but neither (0 - 1) nor (-1 + 1)
can be represented. For signed values, add or subtract -1 as appropriate.
PR tree-optimization/101223
gcc/
* range-op.cc (build_lt): Add -1 for signed values.
(built_gt): Subtract -1 for signed values.
gcc/testsuite/
* gcc.dg/pr101223.c: New.
(cherry picked from commit 84f7bab89279ca1234fef88929c74caeda8cb55e)
If the on-entry cache cannot properly represent a range, do not continue
trying to propagate it.
PR tree-optimization/101148
PR tree-optimization/101014
* gimple-range-cache.cc (ranger_cache::ranger_cache): Adjust.
(ranger_cache::~ranger_cache): Adjust.
(ranger_cache::block_range): Check if propagation disallowed.
(ranger_cache::propagate_cache): Disallow propagation if new value
can't be stored properly.
* gimple-range-cache.h (ranger_cache::m_propfail): New member.
Although PR 100781 is not an issue in GCC11, its possible that a similar
situation may arise. The identical fix cannot be easily introduced.
With EVRP always running in hybrid mode, there is no need for ranger to
spawn a lookup for a debug statement in this release.
* gimple-range.cc (gimple_ranger::range_of_expr): Treat debug statments
as contextless queries to avoid additional lookups.
Use a sparse representation for the on entry cache, and utilize it when
the number of basic blocks in the function exceeds param_evrp_sparse_threshold.
PR tree-optimization/100299
* gimple-range-cache.cc (class sbr_sparse_bitmap): New.
(sbr_sparse_bitmap::sbr_sparse_bitmap): New.
(sbr_sparse_bitmap::bitmap_set_quad): New.
(sbr_sparse_bitmap::bitmap_get_quad): New.
(sbr_sparse_bitmap::set_bb_range): New.
(sbr_sparse_bitmap::get_bb_range): New.
(sbr_sparse_bitmap::bb_range_p): New.
(block_range_cache::block_range_cache): initialize bitmap obstack.
(block_range_cache::~block_range_cache): Destruct obstack.
(block_range_cache::set_bb_range): Decide when to utilze the
sparse on entry cache.
* gimple-range-cache.h (block_range_cache): Add bitmap obstack.
* params.opt (-param=evrp-sparse-threshold): New.
(cherry picked from commit 9858cd1a6827ee7a928318acb5e86389f79b4012)
Provide set/get routines to allow sparse bitmaps to be treated as an array
of multiple bit values. Only chunk sizes that are powers of 2 are supported.
* bitmap.c (bitmap_set_aligned_chunk): New.
(bitmap_get_aligned_chunk): New.
(test_aligned_chunk): New.
(bitmap_c_tests): Call test_aligned_chunk.
* bitmap.h (bitmap_set_aligned_chunk, bitmap_get_aligned_chunk): New.
(cherry picked from commit 5ad089a3c946aec655436fa3b0b50d6574b78197)
This patch adds support for the VDIVSQ, VDIVUQ, VMODSQ, and VMODUQ
instructions to do 128-bit arithmetic.
Backported from master: 2021-07-07 Michael Meissner <meissner@linux.ibm.com>
2021-07-14 Michael Meissner <meissner@linux.ibm.com>
gcc/
PR target/100809
* config/rs6000/rs6000.md (udivti3): New insn.
(divti3): New insn.
(umodti3): New insn.
(modti3): New insn.
gcc/testsuite/
PR target/100809
* gcc.target/powerpc/p10-vdivq-vmodq.c: New test.
Odd-numbered indices describing argument access sizes in the fnspec
string can only hold 't' or a digit, as tested in the beginning of the
case. When checking that the size-supplying argument does not have
additional information associated with it, the test that excludes the
't' possibility looks for it at the even position in the fnspec
string. Oops.
This might yield false positives and negatives if a function has a
fnspec in which an argument uses a 't' access-size, and ('t' - '1')
happens to be the index of an argument described in an fnspec string.
Assuming ASCII encoding, it would take a function with at least 68
arguments described in fnspec. Still, probably worth fixing.
for gcc/ChangeLog
* tree-ssa-alias.c (attr_fnspec::verify): Fix index in
non-'t'-sized arg check.
(cherry picked from commit a7098d6ef4e4e799dab8ef925c62b199d707694b)
The use of npos triggers a diagnostic as described in PR c++/101361.
This change replaces the use of npos with the exact length, which is
already known. We can further simplify it by inlining the effects of
compare and substr, avoiding the redundant range checks in the latter.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
PR c++/101361
* include/std/string_view (ends_with): Use traits_type::compare
directly.
(cherry picked from commit 4d3eaeb4f505b0838c673ee28e7dba8687fc8272)
When I added the new C++23 constructor I added a conditional include of
<bits/ranges_base.h>, which was already being included unconditionally.
This removes the unconditional include but changes the condition for the
other one, so it's used for C++20 as well.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* include/std/string_view: Only include <bits/ranges_base.h>
once, and only for C++20 and later.
(cherry picked from commit bd1eb556b910fd4853ea83291e495d40adbcdf81)
The std::as_writable_bytes function should be constrained to only accept
writable spans. Currently it can be called but then gives an error in
the function body.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
PR libstdc++/101411
* include/std/span (as_writable_bytes): Add requires-clause.
* testsuite/23_containers/span/101411.cc: New test.
(cherry picked from commit 9d4393af9d2b37b78eb5b1f84f5d4da3a6f7fba6)
Still put general regs as first alloca order.
gcc/ChangeLog:
PR target/101185
* config/i386/i386.c (x86_order_regs_for_local_alloc):
Revert r12-1669.
gcc/testsuite/ChangeLog
PR target/101185
* gcc.target/i386/bitwise_mask_op-3.c: Add xfail to
temporarily avoid regression, eventually xfail should be
removed.
The avx512 supports bitwise operations with mask registers, but the
throughput of those instructions is much lower than that of the
corresponding gpr version, so we would additionally disparages
slightly the mask register alternative for bitwise operations in the
LRA.
Also when allocano cost of GENERAL_REGS is same as MASK_REGS, allocate
MASK_REGS first since it has already been disparaged.
gcc/ChangeLog:
PR target/101142
* config/i386/i386.md: (*anddi_1): Disparage slightly the mask
register alternative.
(*and<mode>_1): Ditto.
(*andqi_1): Ditto.
(*andn<mode>_1): Ditto.
(*<code><mode>_1): Ditto.
(*<code>qi_1): Ditto.
(*one_cmpl<mode>2_1): Ditto.
(*one_cmplsi2_1_zext): Ditto.
(*one_cmplqi2_1): Ditto.
* config/i386/i386.c (x86_order_regs_for_local_alloc): Change
the order of mask registers to be before general registers.
gcc/testsuite/ChangeLog:
PR target/101142
* gcc.target/i386/spill_to_mask-1.c: Adjust testcase.
* gcc.target/i386/spill_to_mask-2.c: Adjust testcase.
* gcc.target/i386/spill_to_mask-3.c: Adjust testcase.
* gcc.target/i386/spill_to_mask-4.c: Adjust testcase.
The following fixes the IV adjustment for the gap in a negative
stride SLP vectorization. The adjustment was in the wrong direction,
now fixes as in the patch.
2021-07-14 Richard Biener <rguenther@suse.de>
PR tree-optimization/101445
* tree-vect-stmts.c (vectorizable_load): Do the gap adjustment
of the IV in the correct direction for negative stride
accesses.
* gcc.dg/vect/pr101445.c: New testcase.
(cherry picked from commit a967a3efd39280fe3f5774e45490e991f8e99059)
Here we're crashing ultimately because the mechanism for delaying
substitution into a requires-expression (and constexpr if and pack
expansions) doesn't expect to see dependent args. But we end up
capturing dependent args here during substitution into the default
template argument as part of coerce_template_parms for the dependent
specialization p<T>.
This patch enables the commented out code in add_extra_args for handling
this situation. This isn't needed for pack expansions (as the
accompanying comment points out), and it doesn't seem strictly necessary
for constexpr if either, but for requires-expressions delaying even
dependent substitution is important for ensuring we don't evaluate
requirements out of order.
It turns out we also need to make a copy of the arguments when capturing
them so that coerce_template_parms doesn't later add to them and form an
unexpected cycle (REQUIRES_EXPR_EXTRA_ARGS (t) would indirectly point to t).
We also need to make tsubst_template_args handle missing template
arguments, since the arguments we capture from coerce_template_parms
and are incomplete at that point.
PR c++/101181
gcc/cp/ChangeLog:
* constraint.cc (tsubst_requires_expr): Pass complain/in_decl to
add_extra_args.
* cp-tree.h (add_extra_args): Add complain/in_decl parameters.
* pt.c (build_extra_args): Make a copy of args.
(add_extra_args): Add complain/in_decl parameters. Enable the
code for handling the case where the extra arguments are
dependent.
(tsubst_pack_expansion): Pass complain/in_decl to
add_extra_args.
(tsubst_template_args): Handle missing template arguments.
(tsubst_expr) <case IF_STMT>: Pass complain/in_decl to
add_extra_args.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-requires26.C: New test.
* g++.dg/cpp2a/lambda-uneval16.C: New test.
(cherry picked from commit 2c699fd29829cd6115f78238dab7cab74f0a5009)
r12-1989 fixed the testcase in the PR, but unfortunately the fix is
buggy: it breaks the case where the common template between the
TEMPLATE_DECL t and ctx_parms is the innermost template (as in
concepts-memtmpl5.C below). This can be fixed by instead passing the
TREE_TYPE of ctmpl to common_enclosing_class when ctmpl is a class
template.
But even after that's fixed, the analogous case where the innermost
template is a partial specialization is still broken (as in
concepts-memtmpl5a.C below), because ctmpl is always a primary template.
So this patch instead takes a diferent approach that doesn't rely on
ctx_parms at all: when looking for the template parameters of a
TEMPLATE_DECL that are shared with the current template context, just
walk its DECL_CONTEXT. As long as the template is not overly general
(e.g. we didn't pass it through most_general_template), this should give
us exactly what we want, since if a TEMPLATE_DECL can be referred to
from some template context then the template parameters it uses must all
be in-scope and contained in its DECL_CONTEXT. This effectively makes
us treat TEMPLATE_DECLs more similarly to other _DECLs (whose DECL_CONTEXT
we also walk).
PR c++/101247
gcc/cp/ChangeLog:
* pt.c (any_template_parm_r) <case TEMPLATE_DECL>: Just walk the
DECL_CONTEXT.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-memtmpl4.C: Uncomment the commented out
example, which we now handle correctly.
* g++.dg/cpp2a/concepts-memtmpl5.C: New test.
* g++.dg/cpp2a/concepts-memtmpl5a.C: New test.
(cherry picked from commit f53e66019df819f55d424cc56f8b0ea81c074b55)
Here any_template_parm_r is failing to mark the template parameters
implicitly used by the unqualified use of 'd' inside the constraint
because the code to do so assumes each level of a template parameter
list points to the corresponding primary template, but here the
parameter level for A in the out-of-line definition of A::B does not
(nor do the parameter levels for A and C in the definition of A::C),
which causes us to overlook the sharing.
So it seems we can't in general depend on the TREE_TYPE of a template
parameter level being non-empty here. This patch partially fixes this
by rewriting the relevant part of any_template_parm_r to not depend on
the TREE_TYPE of outer levels. We still depend on the innermost level
to point to the innermost primary template, so we still crash on the
commented out line in the below testcase.
PR c++/101247
gcc/cp/ChangeLog:
* pt.c (any_template_parm_r) <case TEMPLATE_DECL>: Rewrite to
use common_enclosing_class and to not depend on the TREE_TYPE
of outer levels pointing to the corresponding primary template.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-memtmpl4.C: New test.
(cherry picked from commit e3528ce197f8886869f95e8a8f901861a319851c)
Here the initializer for x is represented as an empty CONSTRUCTOR due to
its empty element type. So during constexpr evaluation of the ARRAY_REF
x[0], we end up trying to value initialize the omitted element at index 0,
which fails because the element type is not default constructible.
This patch makes cxx_eval_array_reference specifically handle the case
where the element type is an empty type.
PR c++/101194
gcc/cp/ChangeLog:
* constexpr.c (cxx_eval_array_reference): When the element type
is an empty type and the corresponding element is omitted, just
return an empty CONSTRUCTOR instead of attempting value
initialization.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-empty16.C: New test.
(cherry picked from commit a688c284dd3848b6c4ea553035f0f9769fb4fbc9)
During alias CTAD, we're accidentally ignoring the aggregate deduction
candidate for the underlying template because this guide is added
separately via maybe_aggr_guide (which doesn't yet handle alias
templates) instead of via deduction_guides_for (which does). This patch
makes maybe_aggr_guide handle alias templates in a manner similar to
deduction_guides_for.
PR c++/98832
gcc/cp/ChangeLog:
* pt.c (maybe_aggr_guide): Handle alias templates appropriately.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/class-deduction-alias9.C: New test.
(cherry picked from commit c761be53f6b62e22ac5de18c4aaf88648f64f5b7)
Here we're crashing because cp_fold_function walks into the (templated)
requirements of a requires-expression outside a template, but the
folding routines aren't prepared to handle templated trees. This patch
fixes this by making cp_fold use evaluate_requires_expr to fold a
requires-expression as a whole, which also means we no longer need to
explicitly do so during gimplification. (Note that we delay folding
of such requires-expressions for sake of better diagnostics when one is
used as the condition of a failed static_assert.)
PR c++/101182
gcc/cp/ChangeLog:
* constraint.cc (evaluate_requires_expr): Adjust function comment.
* cp-gimplify.c (cp_genericize_r) <case REQUIRES_EXPR>: Move to ...
(cp_fold) <case REQUIRES_EXPR>: ... here.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-requires25.C: New test.
(cherry picked from commit c06493dc30afbf65b14d783c7cd53f20877ef577)
This rewrites ranges::minmax and ranges::minmax_element so that it
performs at most 3*N/2 many comparisons, as required by the standard.
In passing, this also fixes PR100387 by avoiding a premature std::move
in ranges::minmax and in std::shift_right.
PR libstdc++/100387
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__minmax_fn::operator()): Rewrite
to limit comparison complexity to 3*N/2.
(__minmax_element_fn::operator()): Likewise.
(shift_right): Avoid premature std::move of __result.
* testsuite/25_algorithms/minmax/constrained.cc (test04, test05):
New tests.
* testsuite/25_algorithms/minmax_element/constrained.cc (test02):
Likewise.
(cherry picked from commit cc9c94d43dcfa98436152af9c00f011e9dab25f6)
Here, when resolving the destructor named by Inner<int>::~Inner<int>
(which is valid until C++20) we end up in cp_parser_lookup_name called
indirectly from cp_parser_template_id to look up the name Inner from
the scope Inner<int>. The lookup naturally finds the injected-class-name,
and because the flag is_template is true, we adjust this lookup result
to the TEMPLATE_DECL Inner. We then check access of this adjusted
lookup result. But this access check fails because the lookup scope is
Inner<int> and the context_for_name_lookup for the TEMPLATE_DECL is
Outer (whereas for the injected-class-name it's also Inner<int>).
The simplest fix seems to be to check access of the original lookup
result (the injected-class-name) instead of the adjusted result (the
TEMPLATE_DECL). So this patch moves the access check in
cp_parser_lookup_name to before the injected-class-name adjustment.
PR c++/100918
gcc/cp/ChangeLog:
* parser.c (cp_parser_lookup_name): Check access of the lookup
result before we potentially adjust an injected-class-name to
its TEMPLATE_DECL.
gcc/testsuite/ChangeLog:
* g++.dg/template/access38.C: New test.
(cherry picked from commit 6cb35b606c39d5f21f3298c77bfbcaaef3fbc872)
Here, in C++17 mode, convert_nontype_argument_function is rejecting
binding a non-noexcept function reference template parameter to a
noexcept function (encoded as the template argument '*(int (&) (int)) &f').
The first roadblock to making this work is that the argument is wrapped
an an implicit INDIRECT_REF, so we need to unwrap it before calling
strip_fnptr_conv.
The second roadblock is that the NOP_EXPR cast converts from a function
pointer type to a reference type while simultaneously removing the
noexcept qualification, and fnptr_conv_p doesn't consider this cast to
be a function pointer conversion. This patch fixes this by making
fnptr_conv_p treat REFERENCE_TYPEs and POINTER_TYPEs interchangeably.
Finally, in passing, this patch also simplifies noexcept_conv_p by
removing a bunch of redundant checks already performed by its only
caller fnptr_conv_p.
PR c++/97420
gcc/cp/ChangeLog:
* cvt.c (noexcept_conv_p): Remove redundant checks and simplify.
(fnptr_conv_p): Don't call non_reference. Use INDIRECT_TYPE_P
instead of TYPE_PTR_P.
* pt.c (convert_nontype_argument_function): Look through
implicit INDIRECT_REFs before calling strip_fnptr_conv.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept68.C: New test.
(cherry picked from commit b4329e3dd6fb7c78948fcf9d2f5b9d873deec284)
This fixes the vectorizer loop versioning code failing to clear
niter related info on the scalar loop as it assumed get_loop_copy
would work even for the outermost loop. The patch makes that
assumption hold by adjusting the loop versioning code.
2021-07-05 Richard Biener <rguenther@suse.de>
PR middle-end/101291
* cfgloopmanip.c (loop_version): Set the loop copy of the
versioned loop to the new loop.
(cherry picked from commit 38872c6c0db1b10b17d3913b277c499913208d0b)
This avoids adding a copy from an abnormal picked up from PHI
translation much like we'd avoid inserting the translated
expression on pred edges.
2021-07-12 Richard Biener <rguenther@suse.de>
PR tree-optimization/101394
* tree-ssa-pre.c (do_pre_regular_insertion): Avoid inserting
copies from abnormals for a full redundancy.
* gcc.dg/torture/pr101394.c: New testcase.
(cherry picked from commit 92343e0ba4d47f21ae20ffcb83d736bdbc15dae0)
This adjusts gimple_could_trap_p to not consider internal function
calls to trap compared to indirect calls or calls to weak functions.
2021-07-12 Richard Biener <rguenther@suse.de>
PR middle-end/101423
* gimple.c (gimple_could_trap_p_1): Internal function calls
do not trap.
* tree-eh.c (tree_could_trap_p): Likewise.
(cherry picked from commit 123d0a597beb6d9865f808bf15b0d67f2a8fd5b2)
This avoids placing possibly trapping vectorized operations where
the corresponding scalar operation was possibly not executed.
2021-01-07 Richard Biener <rguenther@suse.de>
PR tree-optimization/100778
* tree-vect-slp.c (vect_schedule_slp_node): Do not place trapping
vectorized ops ahead of their scalar BB.
* gcc.dg/torture/pr100778.c: New testcase.
(cherry picked from commit a3aaba68405751bae3f630669515b7ecdf77efa6)
This avoids vectorizing a possibly trapping operation when lanes
are handled in different BBs. I spotted this when working on the
originally reported issue in PR100778.
2021-05-28 Richard Biener <rguenther@suse.de>
PR tree-optimization/100778
* tree-vect-slp.c (vect_build_slp_tree_1): Prevent possibly
trapping ops in different BBs.
* gcc.dg/vect/bb-slp-pr100778-1.c: New testcase.
(cherry picked from commit f7a07f5a5d8065e7f11133dd1f4ad3510ab2195b)
duplicate_decls was not recognizing the explicit specialization as matching
the implicit specialization of g<Y> because
function_requirements_equivalent_p was seeing the C constraint on the
implicit one and not on the explicit.
PR c++/101098
gcc/cp/ChangeLog:
* decl.c (function_requirements_equivalent_p): Only compare
trailing requirements on a specialization.
gcc/testsuite/ChangeLog:
* g++.dg/concepts/explicit-spec1.C: New test.
