Iain Sandoe [Wed, 23 Dec 2020 17:16:08 +0000 (17:16 +0000)]
Darwin : Adjust handling of MACOSX_DEPLOYMENT_TARGET for macOS 11.
The shift to macOS version 11 also means that '11' without any
following '.x' is accepted as a valid version number. This adjusts
the validation code to accept this and map it to 11.0.0 which
matches what the clang toolchain appears to do.
gcc/ChangeLog:
* config/darwin-driver.c (validate_macosx_version_min): Allow
MACOSX_DEPLOYMENT_TARGET=11.
(darwin_default_min_version): Adjust warning spelling to avoid
an apostrophe.
Iain Sandoe [Sat, 19 Dec 2020 13:05:34 +0000 (13:05 +0000)]
Darwin : Update the kernel version to macOS version mapping.
With the change to macOS 11 and Darwin20, the algorithm for mapping
kernel version to macOS version has changed.
We now have darwin 20.X.Y => macOS 11.(X > 0 ? X - 1 : 0).??.
It currently unclear if the Y will be mapped to macOS patch version
and, if so, whether it will be one-based or 0-based.
Likewise, it's unknown if Darwin 21 will map to macOS 12, so these
entries are unchanged for the present.
gcc/ChangeLog:
* config/darwin-driver.c (darwin_find_version_from_kernel):
Compute the minor OS version from the minor kernel version.
As per Nigel Tufnel's assertion "... this one goes to 11".
The various parts of the code that deal with mapping Darwin versions
to macOS (X) versions need updating to deal with a major version of
11.
So now we have, for example:
Darwin 4 => macOS (X) 10.0
…
Darwin 14 => macOS (X) 10.10
...
Darwin 19 => macOS (X) 10.15
Darwin 20 => macOS 11.0
Because of the historical duplication of the "10" in macOSX 10.xx and
the number of tools that expect this, it is likely that system tools will
allow macos11.0 and/or macosx11.0 (despite that the latter makes little
sense).
Update the link test to cover Catalina (Darwin19/10.15) and
Big Sur (Darwin20/11.0).
gcc/ChangeLog:
* config/darwin-c.c: Allow for Darwin20 to correspond to macOS 11.
* config/darwin-driver.c: Likewise.
gcc/testsuite/ChangeLog:
* gcc.dg/darwin-minversion-link.c: Allow for Darwin19 (macOS 10.15)
and Darwin20 (macOS 11.0).
aarch64 : Fix a forward declaration signature to match the implementation.
The argument types given in the forward declaration for
aarch64_get_extension_string_for_isa_flags do not match those given in the
prototype. This leads to a build fail when 'unsigned long' is not a 64b
type.
Uros Bizjak [Mon, 28 Dec 2020 20:35:08 +0000 (21:35 +0100)]
i386: Fix __builtin_rint with FE_DOWNWARD rounding direction [PR96793]
x86_expand_rint 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-28 Uroš Bizjak <ubizjak@gmail.com>
gcc/
PR target/96793
* config/i386/i386-expand.c (ix86_expand_rint):
Remove the sign of the intermediate value for flag_rounding_math.
gcc/testsuite/
PR target/96793
* gcc.target/i386/pr96793-2.c: New test.
Paul Thomas [Thu, 20 Aug 2020 17:17:59 +0000 (18:17 +0100)]
This patch fixes PRs 96100 and 96101.
2020-08-20 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/96100
PR fortran/96101
* trans-array.c (get_array_charlen): Tidy up the evaluation of
the string length for array constructors. Avoid trailing array
references. Ensure string lengths of deferred length components
are set. For parentheses operator apply string length to both
the primary expression and the enclosed expression.
gcc/testsuite/
PR fortran/96100
PR fortran/96101
* gfortran.dg/char_length_23.f90: New test.
Paul Thomas [Sun, 2 Aug 2020 09:57:59 +0000 (10:57 +0100)]
This patch fixes PR96320. See the explanatory comment in the testcase.
2020-08-01 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR target/96320
* interface.c (gfc_check_dummy_characteristics): If a module
procedure arrives with assumed shape in the interface and
deferred shape in the procedure itself, update the latter and
copy the lower bounds.
gcc/testsuite/
PR target/96320
* gfortran.dg/module_procedure_4.f90 : New test.
Piotr Kubaj [Wed, 16 Dec 2020 22:26:18 +0000 (22:26 +0000)]
rs6000: Add support for powerpc64le-unknown-freebsd
This implements support for powerpc64le architecture on FreeBSD. Since
we don't have powerpcle (32-bit), I did not add support for powerpcle
here. This remains to be changed if there is powerpcle support in the
future.
Harald Anlauf [Fri, 25 Dec 2020 14:40:39 +0000 (15:40 +0100)]
PR fortran/93685 - ICE in gfc_constructor_append_expr, at fortran/constructor.c:135
Fix handling of F2018 enhancements to DATA statements that allows
initialization of pointer components to derived types, and adjust error
handling for the CHARACTER case.
gcc/fortran/ChangeLog:
* data.c (gfc_assign_data_value): Restrict use of
create_character_initializer to constant initializers.
* trans-expr.c (gfc_conv_initializer): Ensure that character
initializer is constant, otherwise fall through to get the same
error handling as for non-character cases.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr93685_1.f90: New test.
* gfortran.dg/pr93685_2.f90: New test.
Iain Sandoe [Sat, 21 Nov 2020 09:06:03 +0000 (09:06 +0000)]
Darwin, libgfortran : Do not use environ directly from the library.
On macOS / Darwin, the environ variable can be used directly in the
code of an executable, but cannot be used in the code of a shared
library (i.e. libgfortran.dylib), in this case.
In such cases, the function _NSGetEnviron should be called to get
the address of 'environ'.
libgfortran/ChangeLog:
* intrinsics/execute_command_line.c (environ): Use
_NSGetEnviron to get the environment pointer on Darwin.
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.
git://gcc.gnu.org / gcc.git / log