Roman Zhuykov [Thu, 24 Dec 2020 16:43:40 +0000 (19:43 +0300)]
modulo-sched: Carefully process loop counter initialization [PR97421]
Do not allow direct adjustment of pre-header initialization instruction for
count register if is read in some instruction below in that basic block.
gcc/ChangeLog:
PR rtl-optimization/97421
* modulo-sched.c (generate_prolog_epilog): Remove forward
declaration, adjust last argument name and type.
(const_iteration_count): Add bool pointer parameter to return
whether count register is read in pre-header after its
initialization.
(sms_schedule): Fix count register initialization adjustment
procedure according to what const_iteration_count said.
gcc/testsuite/ChangeLog:
PR rtl-optimization/97421
* gcc.c-torture/execute/pr97421-1.c: New test.
* gcc.c-torture/execute/pr97421-2.c: New test.
* gcc.c-torture/execute/pr97421-3.c: New test.
Jason Merrill [Tue, 22 Dec 2020 21:40:37 +0000 (16:40 -0500)]
c++: Fix constexpr array ICE [PR98332]
The element initializer was non-constant, so its CONSTRUCTOR element ended
up NULL, so unshare_constructor crashed trying to look at it. This patch
fixes this in two places: First, by returning when we see a non-constant
initializer; second, by not crashing on NULL.
gcc/cp/ChangeLog:
PR c++/98332
* constexpr.c (unshare_constructor): Check for NULL.
(cxx_eval_vec_init_1): Always exit early if non-constant.
gcc/testsuite/ChangeLog:
PR c++/98332
* g++.dg/cpp0x/constexpr-overflow3.C: New test.
Jason Merrill [Wed, 12 Aug 2020 09:45:02 +0000 (05:45 -0400)]
c++: Copy elision and [[no_unique_address]]. [PR93711]
We don't elide a copy from a function returning a class by value into a base
because that can overwrite data laid out in the tail padding of the base
class; we need to handle [[no_unique_address]] fields the same way, or we
ICE when the middle-end wants to create a temporary object of a
TYPE_NEEDS_CONSTRUCTING type.
This means that we can't always express initialization of a field with
INIT_EXPR from a TARGET_EXPR the way we usually do, so I needed
to change several places that were assuming that was sufficient.
This also fixes 90254, the same problem with C++17 aggregate initialization
of a base.
Uros Bizjak [Wed, 23 Dec 2020 17:32:28 +0000 (18:32 +0100)]
i386: Fix __builtin_trunc with FE_DOWNWARD rounding direction [PR96793]
x86_expand_truncdf_32 expander uses x86_sse_copysign_to_positive, which
is unable to change the sign from - to +. When FE_DOWNWARD rounding
direction is in effect, the expanded sequence that involves subtraction
can trigger x - x = -0.0 special rule. x86_sse_copysign_to_positive
fails to change the sign of the intermediate value, assumed to always
be positive, back to positive.
The patch adds one extra fabs that strips the sign from the intermediate
value when flag_rounding_math is in effect.
2020-12-23 Uroš Bizjak <ubizjak@gmail.com>
gcc/
PR target/96793
* config/i386/i386-expand.c (ix86_expand_truncdf_32):
Remove the sign of the intermediate value for flag_rounding_math.
gcc/testsuite/
PR target/96793
* gcc.target/i386/pr96793-1.c: New test.
Uros Bizjak [Tue, 22 Dec 2020 20:11:51 +0000 (21:11 +0100)]
i386: Fix __builtin_floor with FE_DOWNWARD rounding direction [PR96793]
x86_expand_floorceil expander uses x86_sse_copysign_to_positive, which
is unable to change the sign from - to +. When FE_DOWNWARD rounding
direction is in effect, the expanded sequence that involves subtraction
can trigger x - x = -0.0 special rule. x86_sse_copysign_to_positive
fails to change the sign of the intermediate value, assumed to always
be positive, back to positive.
The patch adds one extra fabs that strips the sign from the intermediate
value when flag_rounding_math is in effect.
2020-12-22 Uroš Bizjak <ubizjak@gmail.com>
gcc/
PR target/96793
* config/i386/i386-expand.c (ix86_expand_floorceil):
Remove the sign of the intermediate value for flag_rounding_math.
(ix86_expand_floorceildf_32): Ditto.
gcc/testsuite/
PR target/96793
* gcc.target/i386/pr96793.c: New test.
Nathan Sidwell [Wed, 16 Dec 2020 19:49:41 +0000 (11:49 -0800)]
c++: Fix template parm ICE [PR 98297]
I think this is nonsense code, we seem to be naming an instantiation
of a template template parm. But this fixes the ICE. Perhaps we
should diagnose the issue earlier?
gcc/cp/
* parser.c (cp_parser_elaborated_type_specifier): Test
BOUND_TEMPLATE_TEMPLATE_PARM before checking for instantiation.
gcc/testsuite/
* g++.dg/template/pr98297.C: New.
Iain Buclaw [Tue, 15 Dec 2020 09:36:00 +0000 (10:36 +0100)]
d: Fix ICE in gimplify_expr, at gimplify.c (PR98277)
The DMD front-end shouldn't, but can sometimes leak manifest constants
in the AST passed to the code generator. To prevent this being an
issue, the setting of DECL_INITIAL has been moved to the point where the
CONST_DECL is used, rather than in the declaration handler.
gcc/d/ChangeLog:
PR d/98277
* decl.cc (DeclVisitor::visit (VarDeclaration *)): Move setting of
DECL_INITIAL for manifest constants to ...
(get_symbol_decl): ... here.
Wilco Dijkstra [Thu, 3 Dec 2020 18:40:34 +0000 (18:40 +0000)]
AArch64: Add support for --with-tune
Add support for --with-tune. Like --with-cpu and --with-arch, the argument is
validated and transformed into a -mtune option to be processed like any other
command-line option. --with-tune has no effect if a -mcpu or -mtune option
is used. The validating code didn't allow --with-cpu=native, so explicitly
allow that.
Co-authored-by: Delia Burduv <delia.burduv@arm.com>
Bootstrap OK, regress pass, OK to commit?
Dennis Zhang [Fri, 11 Dec 2020 16:18:05 +0000 (16:18 +0000)]
aarch64: intrinsics to extract half of bf16 vector
This patch implements ACLE intrinsics vget_low_bf16 and vget_high_bf16
to extract lower or higher half from a bfloat16x8 vector. The
vget_high_bf16 is done by 'dup' instruction. The vget_low_bf16 is just
to return the lower half of a vector register. Tests include both big-
and little-endian cases.
gcc/ChangeLog:
* config/aarch64/aarch64-simd-builtins.def (vget_lo_half): New entry.
(vget_hi_half): Likewise.
* config/aarch64/aarch64-simd.md (aarch64_vget_lo_halfv8bf): New entry.
(aarch64_vget_hi_halfv8bf): Likewise.
* config/aarch64/arm_neon.h (vget_low_bf16): New intrinsic.
(vget_high_bf16): Likewise.
gcc/testsuite/ChangeLog
* gcc.target/aarch64/advsimd-intrinsics/bf16_get.c: New test.
2020-10-29 Andrea Corallo <andrea.corallo@arm.com>
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_bf16_indices_1.c:
Run it also for the arm backend.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_bf16_indices_1.c:
Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_bf16_indices_1.c:
Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_bf16_indices_1.c:
Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vld4_lane_bf16_indices_1.c:
Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vld4q_lane_bf16_indices_1.c:
Likewise.
* gcc.target/arm/simd/vldn_lane_bf16_1.c: New test.
Ed Schonberg [Thu, 10 Dec 2020 21:26:57 +0000 (22:26 +0100)]
Fix PR ada/98230
It's a rather curious malfunction of the 'Mod attribute applied to the
variable of a loop whose upper bound is dynamic.
gcc/ada/ChangeLog:
PR ada/98230
* exp_attr.adb (Expand_N_Attribute_Reference, case Mod): Use base
type of argument to obtain static bound and required size.
gcc/testsuite/ChangeLog:
* gnat.dg/modular6.adb: New test.
Patrick Palka [Thu, 30 Jul 2020 02:06:44 +0000 (22:06 -0400)]
c++: overload sets and placeholder return type [PR64194]
In the testcase below, template argument deduction for the call
g(id<int>) goes wrong because the functions in the overload set id<int>
each have a yet-undeduced auto return type, and this undeduced return
type makes try_one_overload fail to match up any of the overloads with
g's parameter type, leading to g's template argument going undeduced and
to the overload set going unresolved.
This patch fixes this issue by performing return type deduction via
instantiation before doing try_one_overload, in a manner similar to what
resolve_address_of_overloaded_function does.
gcc/cp/ChangeLog:
PR c++/64194
* pt.c (resolve_overloaded_unification): If the function
template specialization has a placeholder return type,
then instantiate it before attempting unification.
gcc/testsuite/ChangeLog:
PR c++/64194
* g++.dg/cpp1y/auto-fn60.C: New test.
Kewen Lin [Wed, 19 Aug 2020 02:37:39 +0000 (21:37 -0500)]
options: Make --help= see overridden values
Options "-Q --help=params" don't show the final values after
target option overriding, instead it emits the default values
in params.opt (without any explicit param settings).
This patch makes it see overridden values.
gcc/ChangeLog:
* opts-global.c (decode_options): Call target_option_override_hook
before it prints for --help=*.
Jason Merrill [Wed, 25 Nov 2020 22:05:24 +0000 (17:05 -0500)]
c++: Fix deduction from auto template parameter [PR93083]
The check in do_class_deduction to handle passing one class placeholder
template parm as an argument for itself needed to be extended to also handle
equivalent parms from other templates.
Eric Botcazou [Mon, 7 Dec 2020 09:48:06 +0000 (10:48 +0100)]
Fix internal error on library-level type extended locally
The compiler aborts on the local extension of a tagged type declared
at library level, with a progenitor given by an interface type having
a primitive that is a homograph of a primitive of the tagged type.
gcc/ada/ChangeLog:
* gcc-interface/trans.c (maybe_make_gnu_thunk): Return false if the
target is local and thunk and target do not have the same context.
doc/implement-c.texi: About same-as-scalar-type volatile aggregate accesses, PR94600
We say very little about reads and writes to aggregate /
compound objects, just scalar objects (i.e. assignments don't
cause reads). Let's lets say something safe about aggregate
objects, but only for those that are the same size as a scalar
type.
There's an equal-sounding section (Volatiles) in extend.texi,
but this seems a more appropriate place, as specifying the
behavior of a standard qualifier.
gcc:
2020-12-04 Hans-Peter Nilsson <hp@axis.com>
Martin Sebor <msebor@redhat.com>
PR middle-end/94600
* doc/implement-c.texi (Qualifiers implementation): Add blurb
about access to the whole of a volatile aggregate object, only for
same-size as a scalar object.
Eric Botcazou [Fri, 4 Dec 2020 09:04:56 +0000 (10:04 +0100)]
Fix checking failure in IPA-SRA
This is a regression present on the mainline and 10 branch: on the one
hand, IPA-SRA does *not* disqualify accesses with zero size but, on the
other hand, it checks that accesses present in the tree have a (strictly)
positive size, thus trivially yielding an ICE in some cases.
gcc/ChangeLog:
* ipa-sra.c (verify_access_tree_1): Relax assertion on the size.
gcc/testsuite/ChangeLog:
* gnat.dg/opt91.ads, gnat.dg/opt91.adb: New test.
* gnat.dg/opt91_pkg.ads, gnat.dg/opt91_pkg.adb: New helper.
Uros Bizjak [Thu, 3 Dec 2020 16:49:42 +0000 (17:49 +0100)]
i386: Fix up ix86_md_asm_adjust for TImode [PR98086]
ix86_md_asm_adjust assumes that dest_mode can be only [QHSD]Imode
and nothing else. The patch rewrites zero-extension part to use
convert_to_mode to handle TImode and hypothetically even wider modes.
2020-12-03 Uroš Bizjak <ubizjak@gmail.com>
Jakub Jelinek <jakub@redhat.com>
gcc/
PR target/98086
* config/i386/i386.c (ix86_md_asm_adjustmd): Rewrite
zero-extension part to use convert_to_mode.
gcc/testsuite/
PR target/98086
* gcc.target/i386/pr98086.c: New test.
expr: Fix REDUCE_BIT_FIELD for constants [PR95694, PR96151]
This is yet another PR caused by constant integer rtxes not storing
a mode. We were calling REDUCE_BIT_FIELD on a constant integer that
didn't fit in poly_int64, and then tripped the as_a<scalar_int_mode>
assert on VOIDmode.
AFAICT REDUCE_BIT_FIELD is always passed rtxes that have TYPE_MODE
(rather than some other mode) and it just fills in the redundant
sign bits of that TYPE_MODE value. So it should be safe to get
the mode from the type instead of the rtx. The patch does that
and asserts that the modes agree, where information is available.
That on its own is enough to fix the bug, but we might as well
extend the folding case to all constant integers, not just those
that fit poly_int64.
gcc/
PR middle-end/95694
* expr.c (expand_expr_real_2): Get the mode from the type rather
than the rtx, and assert that it is consistent with the mode of
the rtx (where known). Optimize all constant integers, not just
those that can be represented in poly_int64.
gcc/testsuite/
PR middle-end/95694
* gcc.dg/pr95694.c: New test.
where the VQ coefficient is unsigned but is effectively acting
as a negative number. We wrongly give the POLY_INT_CST the range:
[9, INT_MAX]
and things go downhill from there: later iterations of the unrolled
epilogue are wrongly removed as dead.
I guess this is the final nail in the coffin for doing VRP on
POLY_INT_CSTs. For other similarly exotic testcases we could have
overflow for any coefficient, not just those that could be treated
as contextually negative.
Testing TYPE_OVERFLOW_UNDEFINED doesn't seem like an option because we
couldn't handle warn_strict_overflow properly. At this stage we're
just recording a range that might or might not lead to strict-overflow
assumptions later.
It still feels like we should be able to do something here, but for
now removing the code seems safest. It's also telling that there
are no testsuite failures on SVE from doing this.
In r11-2922, Przemek fixed a post-RA instruction match failure
caused by the SVE FP subtraction patterns.. This patch applies
the same fix to the other patterns.
To recap, the issue is around the handling of predication.
We want to do two things:
- Optimise cases in which a predicate is known to be all-true.
- Differentiate cases in which the predicate on an _x ACLE function has
to be kept as-is from cases in which we can make more lanes active.
The former is true by default, the latter is true for certain
combinations of flags in the -ffast-math group.
This is handled by a boolean flag in the unspecs to say whether the
predicate is “strict” or “relaxed”. When combining multiple strict
operations, the predicates used in the operations generally need to
match. When combining multiple relaxed operations, we can ignore the
predicates on nested operations and just use the predicate on the
“outermost” operation.
Originally I'd tried to reduce combinatorial explosion by using
aarch64_sve_pred_dominates_p. This required matching predicates
for strict operations but allowed more combinations for relaxed
operations.
The problem (as I should have remembered) is that C conditions on
insn patterns can't reliably enforce matching operands. If the
same register is used in two different input operands, the RA is
allowed to use different hard registers for those input operands
(and sometimes it has to). So operands that match before RA
might not match afterwards. The only sure way to force a match
is via match_dup.
This patch splits the cases into two. I cry bitter tears at having
to do this, but I think it's the only backportable fix. There might
be some way of using define_subst to generate the cond_* patterns from
the pred_* patterns, with some alternatives strategically disabled in
each case, but that's future work and might not be an improvement.
Since so many patterns now do this, I moved the comments from the
subtraction pattern to a new banner comment at the head of the file.
aarch64: Avoid false dependencies for SVE unary operations
For calls like:
z0 = svabs_s8_x (p0, z1)
we previously generated:
abs z0.b, p0/m, z1.b
However, this creates a false dependency on z0 (the merge input).
This can lead to strange results in some cases, e.g. serialising
the operation behind arbitrary earlier operations, or preventing
two iterations of a loop from being executed in parallel.
This patch therefore ties the input to the output, using a MOVPRFX
if necessary and possible. (The SVE2 unary long instructions do
not support MOVPRFX.)
When testing the patch, I hit a bug in the big-endian SVE move
optimisation in aarch64_maybe_expand_sve_subreg_move. I don't
have an indepenedent testcase for it, so I didn't split it out
into a separate patch.
gcc/
* config/aarch64/aarch64.c (aarch64_maybe_expand_sve_subreg_move):
Do not optimize LRA subregs.
* config/aarch64/aarch64-sve.md
(@aarch64_pred_<SVE_INT_UNARY:optab><mode>): Tie the input to the
output.
(@aarch64_sve_revbhw_<SVE_ALL:mode><PRED_HSD:mode>): Likewise.
(*<ANY_EXTEND:optab><SVE_PARTIAL_I:mode><SVE_HSDI:mode>2): Likewise.
(@aarch64_pred_sxt<SVE_FULL_HSDI:mode><SVE_PARTIAL_I:mode>): Likewise.
(*cnot<mode>): Likewise.
(@aarch64_pred_<SVE_COND_FP_UNARY:optab><mode>): Likewise.
(@aarch64_sve_<optab>_nontrunc<SVE_FULL_F:mode><SVE_FULL_HSDI:mode>):
Likewise.
(@aarch64_sve_<optab>_trunc<VNx2DF_ONLY:mode><VNx4SI_ONLY:mode>):
Likewise.
(@aarch64_sve_<optab>_nonextend<SVE_FULL_HSDI:mode><SVE_FULL_F:mode>):
Likewise.
(@aarch64_sve_<optab>_extend<VNx4SI_ONLY:mode><VNx2DF_ONLY:mode>):
Likewise.
(@aarch64_sve_<optab>_trunc<SVE_FULL_SDF:mode><SVE_FULL_HSF:mode>):
Likewise.
(@aarch64_sve_<optab>_trunc<VNx4SF_ONLY:mode><VNx8BF_ONLY:mode>):
Likewise.
(@aarch64_sve_<optab>_nontrunc<SVE_FULL_HSF:mode><SVE_FULL_SDF:mode>):
Likewise.
* config/aarch64/aarch64-sve2.md
(@aarch64_pred_<SVE2_COND_FP_UNARY_LONG:sve_fp_op><mode>): Likewise.
(@aarch64_pred_<SVE2_COND_FP_UNARY_NARROWB:sve_fp_op><mode>): Likewise.
(@aarch64_pred_<SVE2_U32_UNARY:sve_int_op><mode>): Likewise.
(@aarch64_pred_<SVE2_COND_INT_UNARY_FP:sve_fp_op><mode>): Likewise.
dse: Cope with bigger-than-integer modes [PR98037]
dse.c:find_shift_sequence tries to represent a store and load
back as a shift right followed by a truncation. It therefore
needs to find an integer mode in which to do the shift right.
The loop it uses has the form:
which implicitly assumes that read_mode has an equivalent integer mode.
As shown in the testcase, not all modes have such an integer mode.
This patch just makes the code start from the smallest integer mode and
skip modes that are too small. The loop already breaks at the first
mode wider than word_mode.
gcc/
PR rtl-optimization/98037
* dse.c (find_shift_sequence): Iterate over all integers and
skip modes that are too small.
gcc/testsuite/
PR rtl-optimization/98037
* gcc.target/aarch64/sve/acle/general/pr98037.c: New test.
Richard Biener [Wed, 26 Aug 2020 13:12:17 +0000 (15:12 +0200)]
tree-optimization/96698 - fix ICE when vectorizing nested cycles
This fixes vectorized PHI latch edge updating and delay it until
all of the loop is code generated to deal with the case that the
latch def is a PHI in the same block.
2020-08-26 Richard Biener <rguenther@suse.de>
PR tree-optimization/96698
* tree-vectorizer.h (loop_vec_info::reduc_latch_defs): New.
(loop_vec_info::reduc_latch_slp_defs): Likewise.
* tree-vect-stmts.c (vect_transform_stmt): Only record
stmts to update PHI latches from, perform the update ...
* tree-vect-loop.c (vect_transform_loop): ... here after
vectorizing those PHIs.
(info_for_reduction): Properly handle non-reduction PHIs.
Patrick Palka [Mon, 12 Oct 2020 17:46:21 +0000 (13:46 -0400)]
libstdc++: Apply proposed resolution for LWG 3449 [PR95322]
Now that the frontend bug PR96805 is fixed, we can cleanly apply the
proposed resolution for this issue.
This slightly deviates from the proposed resolution by declaring _CI a
member of take_view instead of take_view::_Sentinel, since it doesn't
depend on anything within _Sentinel anymore.
libstdc++-v3/ChangeLog:
PR libstdc++/95322
* include/std/ranges (take_view::_CI): Define this alias
template as per LWG 3449 and remove ...
(take_view::_Sentinel::_CI): ... this type alias.
(take_view::_Sentinel::operator==): Adjust use of _CI
accordingly. Define a second overload that accepts an iterator
of the opposite constness as per LWG 3449.
(take_while_view::_Sentinel::operator==): Likewise.
* testsuite/std/ranges/adaptors/95322.cc: Add tests for LWG 3449.
Richard Biener [Mon, 9 Nov 2020 14:19:56 +0000 (15:19 +0100)]
tree-optimization/97760 - reduction paths with unhandled live stmt
This makes sure we reject reduction paths with a live stmt that
is not the last one altering the value. This is because we do not
handle this in the epilogue unless there's a scalar epilogue loop.
2020-11-09 Richard Biener <rguenther@suse.de>
PR tree-optimization/97760
* tree-vect-loop.c (check_reduction_path): Reject
reduction paths we do not handle in epilogue generation.
Richard Biener [Mon, 26 Oct 2020 09:08:38 +0000 (10:08 +0100)]
tree-optimization/97539 - reset out-of-loop debug uses before peeling
This makes sure to reset out-of-loop debug uses before vectorizer
loop peeling as we cannot make sure to retain the use-def dominance
relationship when there are no LC SSA nodes.
Richard Biener [Thu, 26 Nov 2020 09:07:06 +0000 (10:07 +0100)]
testsuite/98002 - fix gcc.dg/strncmp-2.c
This makes sure not to free() memory we have mprotected to PROT_NONE
by calling mprotect again with PROT_READ|PROT_WRITE. This avoids
crashing the allocator when in debug mode.
2020-11-16 Richard Biener <rguenther@suse.de>
PR testsuite/98002
* gcc.dg/strncmp-2.c: Call mprotect again before free.
[Obvious] arm: Fix test from failing on some targets [PR91816]
This recently submitted test was found to fail on some Cortex-M
targets. This was because codegen on these CPUs would emit a ldr
instead of a movw/movt pair, resulting in an overall smaller test
(i.e. the branch wasn't as far) and the behaviour being tested
for not being triggered.
This commit doubles the size of the test to account for this.
Eric Botcazou [Sat, 28 Nov 2020 11:54:48 +0000 (12:54 +0100)]
Fix PR target/97939
The little dance around 4096 that add/sub instructions do on the SPARC
needs to be taken into account for the overflow arithmetic operations.
It cannot be done for unsigned overflow, but it can be done for signed
overflow.
gcc/ChangeLog:
PR target/97939
* config/sparc/predicates.md (arith_double_add_operand): Comment.
* config/sparc/sparc.md (uaddvdi4): Use arith_double_operand.
(addvdi4): Use arith_double_add_operand.
(addsi3): Remove useless attributes.
(addvsi4): Use arith_add_operand.
(*cmp_ccv_plus): Likewise and add second alternative accordingly.
(*cmp_ccxv_plus): Likewise.
(*cmp_ccv_plus_set): Likewise.
(*cmp_ccxv_plus_set): Likewise.
(*cmp_ccv_plus_sltu_set): Likewise.
(usubvdi4): Use arith_double_operand.
(subvdi4): Use arith_double_add_operand.
(subsi3): Remove useless attributes.
(subvsi4): Use arith_add_operand.
(*cmp_ccv_minus): Likewise and add second alternative accordingly.
(*cmp_ccxv_minus): Likewise.
(*cmp_ccv_minus_set): Likewise.
(*cmp_ccxv_minus_set): Likewise.
(*cmp_ccv_minus_sltu_set): Likewise.
(negsi2): Use register_operand.
(unegvsi3): Likewise.
(negvsi3) Likewise.
(*cmp_ccnz_neg): Likewise.
(*cmp_ccxnz_neg): Likewise.
(*cmp_ccnz_neg_set): Likewise.
(*cmp_ccxnz_neg_set): Likewise.
(*cmp_ccc_neg_set): Likewise.
(*cmp_ccxc_neg_set): Likewise.
(*cmp_ccc_neg_sltu_set): Likewise.
(*cmp_ccv_neg): Likewise.
(*cmp_ccxv_neg): Likewise.
(*cmp_ccv_neg_set): Likewise.
(*cmp_ccxv_neg_set): Likewise.
(*cmp_ccv_neg_sltu_set): Likewise.
gcc/testsuite/ChangeLog:
* gcc.target/sparc/overflow-6.c: New test.
Eric Botcazou [Thu, 26 Nov 2020 15:38:35 +0000 (16:38 +0100)]
Fix PR target/96607
After 15 years trying to find out what can go into the delay slot of
the call to __tls_get_addr with the Solaris linker, it's now time to
concede defeat and consider it as not to be filled.
gcc/ChangeLog:
PR target/96607
* config/sparc/sparc-protos.h (eligible_for_call_delay): Delete.
* config/sparc/sparc.c (eligible_for_call_delay): Likewise.
* config/sparc/sparc.md (in_call_delay): Likewise.
(tls_delay_slot): New attribute.
(define_delay [call]): Use in_branch_delay.
(tgd_call<P:mode>): Set type to call_no_delay_slot when
tls_delay_slot is false.
(tldm_call<P:mode>): Likewise.
Kyrylo Tkachov [Fri, 27 Nov 2020 09:19:33 +0000 (09:19 +0000)]
aarch64: Introduce --param=aarch64-autovec-preference to select autovec preference in backend
This is a patch that introduces the aarch64-autovec-preference that can
take values from 0 - 4, 0 being the default.
It can be used to override the autovectorisation preferences in the
backend:
0 - use default scheme
1 - only use Advanced SIMD
2 - only use SVE
3 - use Advanced SIMD and SVE, prefer Advanced SIMD in the event of a
tie (as determined by costs)
4 - use Advanced SIMD and SVE, prefer SVE in the event of a tie (as
determined by costs)
It can valuable for experimentation when comparing SVE and Advanced SIMD
autovectorisation strategies.
It achieves this adjusting the order of the interleaved SVE and Advanced
SIMD modes in aarch64_autovectorize_vector_modes.
It also adjusts aarch64_preferred_simd_mode to use the new comparison
function to pick Advanced SIMD or SVE to start with.
Bootstrapped and tested on aarch64-none-linux-gnu.
gcc/
* config/aarch64/aarch64.opt
(-param=aarch64-autovec-preference): Define.
* config/aarch64/aarch64.c (aarch64_override_options_internal):
Set aarch64_sve_compare_costs to 0 when preferring only Advanced
SIMD.
(aarch64_cmp_autovec_modes): Define.
(aarch64_preferred_simd_mode): Adjust to use the above.
(aarch64_autovectorize_vector_modes): Likewise.
* doc/invoke.texi: Document aarch64-autovec-preference param.
Thomas Schwinge [Wed, 25 Nov 2020 19:36:55 +0000 (20:36 +0100)]
Don't create location wrapper nodes within OpenACC clauses
This fixes a GCC 11, 10, 9 regression introduced by commit dfd7fdca2ac17d8b823a16700525824ca312ade0 (Subversion r267272) "C++: more
location wrapper nodes (PR c++/43064, PR c++/43486)". But: this isn't
intending to blame David, because back then, the problem hasn't been visible in
the testsuite (or else I'm sure would've been addressed right away) because of
our all dear friend: missing testsuite coverage. Thus, for GCC 8, I'm likewise
enhancing the testsuite, without the C++ front end code changes.
I actually had presumed that there may be an issue for OpenACC:
<http://mid.mail-archive.com/874lb9qr2u.fsf@euler.schwinge.homeip.net>, so here
we are, two years (and many "wasted" hours...) later...
Jonathan Wakely [Wed, 25 Nov 2020 17:18:44 +0000 (17:18 +0000)]
libstdc++: Fix missing subsumption in std::iterator_traits [PR 97935]
libstdc++-v3/ChangeLog:
PR libstdc++/97935
* include/bits/iterator_concepts.h (__detail::__iter_without_category):
New helper concept.
(__iterator_traits::__cat): Use __detail::__iter_without_category.
* testsuite/24_iterators/associated_types/iterator.traits.cc: New test.
Jonathan Wakely [Thu, 4 Jun 2020 22:20:49 +0000 (23:20 +0100)]
libstdc++: Remove workarounds for constrained nested class templates
With PR c++/92078 and PR c++/92103 both fixed, nested class templates
can now be constrained. That means a number of namespace-scope helpers
can be moved to the class scope, so they're only visible where they're
needed.
* include/bits/iterator_concepts.h (__detail::__ptr, __detail::__ref)
(__detail::__cat, __detail::__diff): Move to class scope in the
relevant __iterator_traits specializations.
(__iterator_traits<>): Use nested class templates instead of ones from
namespace __detail.
* include/bits/stl_iterator.h (__detail::__common_iter_ptr): Move to
class scope in iterator_traits<common_iterator<I, S>>.
(iterator_traits<common_iterator<I, S>>): Use nested class template
instead of __detail::__common_iter_ptr.
Jakub Jelinek [Tue, 24 Nov 2020 08:04:28 +0000 (09:04 +0100)]
openmp: Fix C ICE on OpenMP atomics
c_parser_binary_expression was using build2 to create a temporary holder
for binary expression that c_parser_atomic and c_finish_omp_atomic can then
handle. The latter performs then all the needed checking.
Unfortunately, build2 performs some checking too, e.g. PLUS_EXPR vs.
POINTER_PLUS_EXPR or matching types of the arguments, nothing we can guarantee
at the parsing time. So we need something like C++ build_min_nt*. This
patch implements that inline.
2020-11-24 Jakub Jelinek <jakub@redhat.com>
PR c/97958
* c-parser.c (c_parser_binary_expression): For omp atomic binary
expressions, use make_node instead of build2 to avoid checking build2
performs.
Jakub Jelinek [Fri, 20 Nov 2020 11:26:58 +0000 (12:26 +0100)]
arm: Fix up neon_vector_mem_operand [PR97528]
The documentation for POST_MODIFY says:
Currently, the compiler can only handle second operands of the
form (plus (reg) (reg)) and (plus (reg) (const_int)), where
the first operand of the PLUS has to be the same register as
the first operand of the *_MODIFY.
The following testcase ICEs, because combine just attempts to simplify
things and ends up with
(post_modify (reg1) (plus (mult (reg2) (const_int 4)) (reg1))
but the target predicates accept it, because they only verify
that POST_MODIFY's second operand is PLUS and the second operand
of the PLUS is a REG.
The following patch fixes this by performing further verification that
the POST_MODIFY is in the form it should be.
2020-11-20 Jakub Jelinek <jakub@redhat.com>
PR target/97528
* config/arm/arm.c (neon_vector_mem_operand): For POST_MODIFY, require
first POST_MODIFY operand is a REG and is equal to the first operand
of PLUS.
Jakub Jelinek [Sat, 14 Nov 2020 08:14:19 +0000 (09:14 +0100)]
dwarf2: Emit DW_TAG_unspecified_parameters even in late DWARF [PR97599]
Aldy's PR71855 fix avoided emitting multiple redundant
DW_TAG_unspecified_parameters sub-DIEs of a single DIE by restricting
it to early dwarf only. That unfortunately means if we need to emit
another DIE for the function (whether it is for LTO, or e.g. because of
IPA cloning), we don't emit DW_TAG_unspecified_parameters, it remains
solely in the DW_AT_abstract_origin's referenced DIE.
But DWARF consumers don't really use DW_TAG_unspecified_parameters
from there, like we duplicate DW_TAG_formal_parameter sub-DIEs even in the
clones because either they have some more specific location, or e.g.
a function clone could have fewer or different argument types etc.,
they need to assume that originally stdarg function isn't later stdarg etc.
Unfortunately, while for DW_TAG_formal_parameter sub-DIEs, we can use the
hash tabs to look the PARM_DECLs if we already have the DIEs, for
DW_TAG_unspecified_parameters we don't have an easy way to look it up.
The following patch handles it by trying to figure out if we are creating a
fresh new DIE (in that case we add DW_TAG_unspecified_parameters if it is
stdarg), or if gen_subprogram_die is called again on an pre-existing DIE
to fill in some further details (then it will not touch it).
Except for lto, subr_die != old_die would be good enough, but unfortunately
for LTO the new DIE that will refer to early dwarf created DIE is created
on the fly during lookup_decl_die. So the patch tracks if the DIE has
no children before any children are added to it.
2020-11-14 Jakub Jelinek <jakub@redhat.com>
PR debug/97599
* dwarf2out.c (gen_subprogram_die): Call
gen_unspecified_parameters_die even if not early dwarf, but only
if subr_die is a newly created DIE.
projects / thirdparty / gcc.git / log
