Jakub Jelinek [Tue, 11 Aug 2020 11:46:14 +0000 (13:46 +0200)]
tree: Fix up get_narrower [PR96549]
My changes to get_narrower to support COMPOUND_EXPRs apparently
used a wrong type for the COMPOUND_EXPRs, while e.g. the rhs
type was unsigned short, the COMPOUND_EXPR got int type as that was the
original type of op. The type of COMPOUND_EXPR should be always the type
of the rhs.
2020-08-11 Jakub Jelinek <jakub@redhat.com>
PR c/96549
* tree.c (get_narrower): Use TREE_TYPE (ret) instead of
TREE_TYPE (win) for COMPOUND_EXPRs.
Jan Hubicka [Tue, 11 Aug 2020 10:02:32 +0000 (12:02 +0200)]
Do not combine PRED_LOOP_GUARD and PRED_LOOP_GUARD_WITH_RECURSION
This patch avoids both PRED_LOOP_GUARD and PRED_LOOP_GUARD_WITH_RECURSION to be
attached to one edge. We have logic that prevents same predictor to apply to
one edge twice, but since we split LOOP_GUARD to two more specialized cases,
this no longer fires.
Double prediction happens in exchange benchmark and leads to unrealistically
low hitrates on some edges which in turn leads to bad IPA profile and misguides
ipa-cp.
Unforutnately it seems that the bad profile also leads to bit better
performance by disabling some of loop stuff, but that really ought to be done
in some meaningful way, not by an accident.
gcc/ChangeLog:
2020-08-11 Jan Hubicka <hubicka@ucw.cz>
* predict.c (not_loop_guard_equal_edge_p): New function.
(maybe_predict_edge): New function.
(predict_paths_for_bb): Use it.
(predict_paths_leading_to_edge): Use it.
gcc/testsuite/ChangeLog:
2020-08-11 Jan Hubicka <hubicka@ucw.cz>
* gcc.dg/ipa/ipa-clone-2.c: Lower threshold from 500 to 400.
Clément Chigot [Fri, 29 May 2020 09:39:42 +0000 (11:39 +0200)]
runtime: revert eqtype for AIX
AIX linker is not able to merge identical type descriptors in a single
symbol if there are coming from different object or shared object files.
This results into several pointers referencing the same type
descriptors.
Thus, eqtype is needed to ensure that these different symbols will be
considered as the same type descriptor.
Roger Sayle [Mon, 10 Aug 2020 20:09:16 +0000 (21:09 +0100)]
i386: Improve code generation of smin(x,0) with -m32.
To make amends for the recent (temporary) testsuite failure
of my new gcc.target/i386/minmax-9.c when compiled with -m32,
this patch improves the -m32 code we generate for the examples
in that test case.
The trick is to expand smin(x,0) as "x < 0 ? x : 0" instead
of the current "x <= 0 ? x : 0", as the former can take
advantage of sign_bit_mask operations.
2020-08-10 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
* config/i386/i386-expand.c (ix86_expand_int_movcc): Expand
signed MIN_EXPR against zero as "x < 0 ? x : 0" instead of
"x <= 0 ? x : 0" to enable sign_bit_compare_p optimizations.
gcc/testsuite/ChangeLog
* gcc.target/i386/minmax-12.c: New test.
Jonathan Wakely [Mon, 10 Aug 2020 17:44:06 +0000 (18:44 +0100)]
libstdc++: Fix compatibility support in unique_ptr pretty printer
The support for the old std::unique_ptr implementation was failing,
because it tried to work on a typedef instead of the underlying type.
The test supposed to verify the support worked wasn't using a typedef,
so didn't notice the problem.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (UniquePointerPrinter.__init__):
Use gdb.Type.strip_typedefs().
* testsuite/libstdc++-prettyprinters/compat.cc: Use a typedef in
the emulated old type.
Jakub Jelinek [Mon, 10 Aug 2020 15:53:46 +0000 (17:53 +0200)]
c++: Fix constexpr evaluation of SPACESHIP_EXPR [PR96497]
The following valid testcase is rejected, because cxx_eval_binary_expression
is called on the SPACESHIP_EXPR with lval = true, as the address of the
spaceship needs to be passed to a method call.
After recursing on the operands and calling genericize_spaceship which turns
it into a TARGET_EXPR with initialization, we call cxx_eval_constant_expression
on it which succeeds, but then we fall through into code that will
VERIFY_CONSTANT (r) which FAILs because it is an address of a variable. Rather
than avoiding that for lval = true and SPACESHIP_EXPR, the patch just tail
calls cxx_eval_constant_expression - I believe that call should perform all
the needed verifications.
2020-08-10 Jakub Jelinek <jakub@redhat.com>
PR c++/96497
* constexpr.c (cxx_eval_binary_expression): For SPACESHIP_EXPR, tail
call cxx_eval_constant_expression after genericize_spaceship to avoid
undesirable further VERIFY_CONSTANT.
Patrick Palka [Mon, 10 Aug 2020 13:33:17 +0000 (09:33 -0400)]
c++: constraints and address of template-id
When resolving the address of a template-id, we need to drop functions
whose associated constraints are not satisfied, as per [over.over]. We
do so in resolve_address_of_overloaded_function, but not in
resolve_overloaded_unification or resolve_nondeduced_context, which
seems like an oversight.
gcc/cp/ChangeLog:
* pt.c (resolve_overloaded_unification): Drop functions with
unsatisfied constraints.
(resolve_nondeduced_context): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-fn5.C: New test.
* g++.dg/concepts/fn8.C: Generalize dg-error directive to accept
"no matching function ..." diagnostic.
* g++.dg/cpp2a/concepts-fn1.C: Likewise.
* g++.dg/cpp2a/concepts-ts2.C: Likewise.
* g++.dg/cpp2a/concepts-ts3.C: Likewise.
Jan Hubicka [Mon, 10 Aug 2020 06:18:13 +0000 (08:18 +0200)]
Fix remove_predictions_associated_with_edge
remove_predictions_associated_with_edge currently calls filter_predicitons
passing it equal_edge_p. Becase filter_predictions removes all edges where
filter returns false, the function does exact oposite. Fixed thus.
Bootstrapped/regtested x86_64-linux.
gcc/ChangeLog:
2020-08-02 Jan Hubicka <hubicka@ucw.cz>
* predict.c (filter_predictions): Document semantics of filter.
(equal_edge_p): Rename to ...
(not_equal_edge_p): ... this; reverse semantics.
(remove_predictions_associated_with_edge): Fix.
For rtx like (eq:HI (V8SI 90) (V8SI 91)), cse will take it as a
boolean value and try to do some optimization. But it is not true for
vector compare, also other places in rtl passes hold the same
assumption.
Roger Sayle [Sun, 9 Aug 2020 22:14:58 +0000 (23:14 +0100)]
middle-end: Correct calculation of mul_widen_cost and mul_highpart_cost.
This patch fixes a subtle bug in the depths of GCC's synth_mult,
where the middle-end queries whether (how well) the target supports
widening and highpart multiplications by calling targetm.rtx_costs.
The code in init_expmed and init_expmed_one_mode iterates over various
RTL patterns querying the cost of each. To avoid generating & garbage
collecting too much junk, it reuses the same RTL over and over, but
adjusting the modes between each call.
Alas this reuse of state is a little fragile, and at some point a
change to init_expmed_one_conv has resulted in the state (mode of
a register) being changed, but not reset before being used again.
Using the old software engineering/defensive programming maxim of
"why fix a bug just once, if it can be fixed in multiple places",
this patch both restores the original value in init_expmed_one_conv,
and also sets it to the expected value in init_expmed_one_mode.
This should hopefully signal the need to be careful of invariants for
anyone modifying this code in future.
2020-08-09 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
* expmed.c (init_expmed_one_conv): Restore all->reg's mode.
(init_expmed_one_mode): Set all->reg to desired mode.
gcc/testsuite/ChangeLog
PR target/71321
* gcc.target/i386/pr71321.c: Check that the code doesn't use
the 4B zero displacement lea, not that it uses lea.
testsuite, Darwin: XFAIL runs for two timode conversion tests.
X86 Darwin fails these at present, because (to work around PR80556)
we insert libSystem ahead of libgcc. The libSystem implementation
has a similar bug to one that was fixed for GCC. We need to fix
80556 properly, and then this issue will go away - we will be able
to use the libgcc impl as intended.
The test makes sense only for targets that return the
"struct { int a, b, c; }" in registers (not in memory).
Starting a skip-construct is IMHO better than another iteration of
that obscuring "{ ... && { ! mytarget-*-* } }". New targets can just
append to the list without additional {}:s. I chose not to "convert"
any of the previous exclusions, as without targets to test, I'd surely
mess up {}-pairs.
A new effective_target would be even better, but such a
check_effective_target_returns_struct_in_memory (or complementary,
_in_registers) would surely have to be parametrized on the size and
type of the returned blob.
Maybe best to restrict to just x86_64, as seems to have been the
original problem target.
gcc/testsuite:
* gcc.dg/pr44194-1.c: Skip for mmix.
IV (loop2_unroll) doesn't like the mmix port. The feelings are mutual.
For mmix, gcc.dg/pr30957-1.c fails (runtime and rtl-scan) for these
reasons:
- IV doesn't handle the zero-extension-by-shift sequences generated by
middle-end (expr.c:convert_mode_scalar) in the absence of
zero-extend patterns in a port.
- (when adding such patterns)
IV doesn't understand the subreg constructs generated by middle-end
in the absence of addsi3 and compare/branch in SImode (int).
- (when hacking pr30957-1.c to iterate using a register-mode type)
IV doesn't understand the admittedly weird SFmode operations
(performing in DFmode, then truncating, for lack of SFmode
operations, but presence of truncdfsf2 and float_extendsfdf2) in
order to perform the "Expanding Accumulator" optimization. When
also editing the type in the test to be double instead of float, the
test passes.
While at least the last point seems like a valid reason to just skip
the test for mmix, it also seems possible that IV (and maybe
convert_mode_scalar by e.g. adding REG_EQUIV notes) be improved to be
both smarter and dumber to actually make the test pass, so I think
it's better to use xfail. Smarter: understanding zero-extend-
by-shift and subregged operations better, and "seeing" the
accumulation through the DF/SFmode truncations and expansions.
Dumber: ignoring the cost; unrolling the several operations per SFmode
add anyway.
I'm considering adding a variant of this test with "double" and
"__SIZE_TYPE__" iteration types, as that passes for mmix as-is.
Maybe as a mmix-specific test; the world has suffered enough from the
questionable gcc.dg/pr30957-1.c (see the test and its history).
gcc/testsuite:
* gcc.dg/pr30957-1.c: xfail for mmix.
Peter Bergner [Sat, 8 Aug 2020 16:54:48 +0000 (11:54 -0500)]
rs6000: MMA built-ins reject typedefs of MMA types
We do not allow conversions between the MMA types and other types.
However, we are being too strict in not matching MMA types with
typdefs of those types. Use TYPE_CANONICAL to see through the
types to their canonical types before comparing them.
2020-08-08 Peter Bergner <bergner@linux.ibm.com>
gcc/
PR target/96530
* config/rs6000/rs6000.c (rs6000_invalid_conversion): Use canonical
types for type comparisons. Refactor code to simplify it.
gcc/testsuite/
PR target/96530
* gcc.target/powerpc/pr96530.c: New test.
Jakub Jelinek [Sat, 8 Aug 2020 09:10:30 +0000 (11:10 +0200)]
openmp: Handle clauses with gimple sequences in convert_nonlocal_omp_clauses properly
If the walk_body on the various sequences of reduction, lastprivate and/or linear
clauses needs to create a temporary variable, we should declare that variable
in that sequence rather than outside, where it would need to be privatized inside of
the construct.
2020-08-08 Jakub Jelinek <jakub@redhat.com>
PR fortran/93553
* tree-nested.c (convert_nonlocal_omp_clauses): For
OMP_CLAUSE_REDUCTION, OMP_CLAUSE_LASTPRIVATE and OMP_CLAUSE_LINEAR
save info->new_local_var_chain around walks of the clause gimple
sequences and declare_vars if needed into the sequence.
Jakub Jelinek [Sat, 8 Aug 2020 09:07:09 +0000 (11:07 +0200)]
openmp: Avoid floating point comparison at the end of bb with -fnon-call-exceptions
The following testcase ICEs with -fexceptions -fnon-call-exceptions because
in that mode floating point comparisons should not be done at the end of bb
in GIMPLE_COND. Fixed by forcing it into a bool SSA_NAME and comparing that against
false.
2020-08-08 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/96424
* omp-expand.c: Include tree-eh.h.
(expand_omp_for_init_vars): Handle -fexceptions -fnon-call-exceptions
by forcing floating point comparison into a bool temporary.
Jonathan Wakely [Fri, 7 Aug 2020 19:29:11 +0000 (20:29 +0100)]
libstdc++: Fix ambiguous comparisons in __gnu_debug::bitset [PR 96303]
With -pedantic the debug mode bitset has an ambiguous equality
comparison operator, because it tries to compare the non-debug base to
the debug object. The base object can be converted to another debug
bitset, making the same operator== a candidate again.
The fix is to do the comparison on both base objects, so the operator
for the derived type isn't a candidate.
For the inequality operator the same change should be done, but that
operator can be removed entirely for C++20 because it can be synthesized
by the compiler.
I don't think either equality or inequality operators are really needed,
because the public _GLIBCXX_STD_C::bitset base class cam always be
compared using its own comparison operators. I'm not changing that here
though.
libstdc++-v3/ChangeLog:
PR libstdc++/96303
* include/debug/bitset (bitset::operator==): Call _M_base() on
right operand.
(bitset::operator!=): Likewise, but don't define it at all when
default comparisons are supported by the compiler.
* testsuite/23_containers/bitset/operations/96303.cc: New test.
Marc Glisse [Fri, 7 Aug 2020 16:49:04 +0000 (18:49 +0200)]
Disable some VEC_COND_EXPR transformations after vector lowering
ARM understands VEC_COND_EXPR<v == w, -1, 0> but not a plain v == w which is
fed to something other than VEC_COND_EXPR (say BIT_IOR_EXPR). This patch avoids
introducing the second kind of statement after the vector lowering pass, which
is the last chance to turn v == w back into something the target handles.
This is just a workaround to avoid ICEs, a v == w produced before vector
lowering will yield pretty bad code. Either the arm target needs to learn to
handle vector comparisons (aarch64 already does), or the middle-end needs to
fall back to vcond when plain comparisons are not supported (or ...).
2020-08-07 Marc Glisse <marc.glisse@inria.fr>
* generic-match-head.c (optimize_vectors_before_lowering_p): New
function.
* gimple-match-head.c (optimize_vectors_before_lowering_p):
Likewise.
* match.pd ((v ? w : 0) ? a : b, c1 ? c2 ? a : b : b): Use it.
Jonathan Wakely [Fri, 7 Aug 2020 16:45:42 +0000 (17:45 +0100)]
libstdc++: Replace some VERIFY tests with static_assert
libstdc++-v3/ChangeLog:
* testsuite/18_support/comparisons/algorithms/partial_order.cc:
Replace VERIFY with static_assert where the compiler now
allows it.
* testsuite/18_support/comparisons/algorithms/weak_order.cc:
Likewise.
Alan Modra [Thu, 6 Aug 2020 04:42:21 +0000 (14:12 +0930)]
PR96493, powerpc local call linkage failure
This corrects current_file_function_operand, an operand predicate used
to determine whether a symbol_ref is safe to use with the local_call
patterns. Calls between pcrel and non-pcrel code need to go via
linker stubs. In the case of non-pcrel code to pcrel the stub saves
r2 but there needs to be a nop after the branch for the r2 restore.
So the local_call patterns can't be used there. For pcrel code to
non-pcrel the local_call patterns could still be used, but I thought
it better to not use them since the call isn't direct. Code generated
by the corresponding call_nonlocal_aix for pcrel is identical anyway.
Incidentally, without the TREE_CODE () == FUNCTION_DECL test,
gcc.c-torture/compile/pr37433.c and pr37433-1.c ICE. Also, if you
make the test more strict by disallowing an op without a
SYMBOL_REF_DECL then a bunch of go and split-stack tests fail. That's
because a prologue call to __morestack can't have a following nop.
(__morestack calls its caller at a fixed offset from the __morestack
call!)
gcc/
PR target/96493
* config/rs6000/predicates.md (current_file_function_operand): Don't
accept functions that differ in r2 usage.
gcc/testsuite/
* gcc.target/powerpc/pr96493.c: New file.
mmix: fix gcc.dg/loop-9.c by more accurate move insns
It looks like gcc.dg/loop-9.c kind-of works as sentinel for sane
move-instruction generation for a port.
Looking at the
FAIL: gcc.dg/loop-9.c scan-rtl-dump loop2_invariant "Decided"
FAIL: gcc.dg/loop-9.c scan-rtl-dump loop2_invariant "without introducing a new temporary register"
it seems the problem is that in the loop:
for (i = 0; i < 100; i++)
a[i] = 18.4242;
the move insn corresponding to "a[i] = 18.4242" happens to be
generated as a move of a constant to a memory address, using no
registers except for the address (edited):
To wit, at the loop2 pass there's no register-initialization to move
out of the loop! The insn above isn't accurate and has to be fixed up
at register allocation time to make constraints match. While there
are insns to set memory to constant in MMIX, that's limited to 64-bit
moves corresponding to the integer bit-patterns for 0..255, and
18.4242 isn't one of them. (Only 0.0 matches; the bit-patterns for
0..255 would IIUC be interpreted as denormal floating-point numbers
a.k.a. subnormal numbers and don't seem worthwhile to handle.)
The fault is with the port, for not requiring a register for an
operand that actually requires an intermediate register, in order to
enable pre-register-allocation passes to do their job. The movdf
pattern (actually, all MMIX movM), only required the destination to be
a non-immediate operand and the source to be a general_operand,
i.e. anything-to-anything.
Better force the source to be a register, when asked to generate such
a move insn. Also, make operands stay sane by using the matching insn
condition to require one of the operands to be a register
pre-register-allocation (for sake of combine-like passes that cook up
"simplified" insns, possibly losing the use of a register). Looking
no deeper than at the results of test-runs with different variants, I
see that the latter "safety latch" has no effect on the test-results
(at 919c9d4bd3db7da0), but it just feels like the right thing to do.
Similarly, there's no effect on test-suite results, to do the same not
just for movdf but for all moves.
gcc:
* config/mmix/mmix.md (MM): New mode_iterator.
("mov<mode>"): New expander to expand for all MM-modes.
("*movqi_expanded", "*movhi_expanded", "*movsi_expanded")
("*movsf_expanded", "*movdf_expanded"): Rename from the
corresponding mov<M> named pattern. Add to the condition that
either operand must be a register_operand.
("*movdi_expanded"): Similar, but also allow STCO in the condition.
Andrew Luo [Thu, 6 Aug 2020 18:35:43 +0000 (19:35 +0100)]
libstdc++: Implement P0966 std::string::reserve should not shrink
Remove ability for reserve(n) to reduce a string's capacity. Add a new
reserve() overload that makes a shrink-to-fit request, and make
shrink_to_fit() use that.
libstdc++-v3/ChangeLog:
2020-07-30 Andrew Luo <andrewluotechnologies@outlook.com>
Jonathan Wakely <jwakely@redhat.com>
* config/abi/pre/gnu.ver (GLIBCXX_3.4): Use less greedy
patterns for basic_string members.
(GLIBCXX_3.4.29): Export new basic_string::reserve symbols.
* doc/xml/manual/status_cxx2020.xml: Update P0966 status.
* include/bits/basic_string.h (shrink_to_fit()): Call reserve().
(reserve(size_type)): Remove default argument.
(reserve()): Declare new overload.
[!_GLIBCXX_USE_CXX11_ABI] (shrink_to_fit, reserve): Likewise.
* include/bits/basic_string.tcc (reserve(size_type)): Remove
support for shrinking capacity.
(reserve()): Perform shrink-to-fit operation.
[!_GLIBCXX_USE_CXX11_ABI] (reserve): Likewise.
* testsuite/21_strings/basic_string/capacity/1.cc: Adjust to
reflect new behavior.
* testsuite/21_strings/basic_string/capacity/char/1.cc:
Likewise.
* testsuite/21_strings/basic_string/capacity/char/18654.cc:
Likewise.
* testsuite/21_strings/basic_string/capacity/char/2.cc:
Likewise.
* testsuite/21_strings/basic_string/capacity/wchar_t/1.cc:
Likewise.
* testsuite/21_strings/basic_string/capacity/wchar_t/18654.cc:
Likewise.
* testsuite/21_strings/basic_string/capacity/wchar_t/2.cc:
Likewise.
Jonathan Wakely [Thu, 6 Aug 2020 18:23:14 +0000 (19:23 +0100)]
libstdc++: Do not set eofbit eagerly in operator>>(istream&, char(&)[N])
Similar to the bugs I fixed recently in istream::ignore, we incorrectly
set eofbit too often in operator>>(istream&, string&) and
operator>>(istream&. char(&)[N]).
We should only set eofbit if we reach EOF but would have kept going
otherwise. If we've already extracted the maximum number of characters
(whether that's because of the buffer size or the istream's width())
then we should not set eofbit.
libstdc++-v3/ChangeLog:
* include/bits/basic_string.tcc
(operator>>(basic_istream&, basic_string&)): Do not set eofbit
if extraction stopped after in.width() characters.
* src/c++98/istream-string.cc (operator>>(istream&, string&)):
Likewise.
* include/bits/istream.tcc (__istream_extract): Do not set
eofbit if extraction stopped after n-1 characters.
* src/c++98/istream.cc (__istream_extract): Likewise.
* testsuite/21_strings/basic_string/inserters_extractors/char/13.cc: New test.
* testsuite/21_strings/basic_string/inserters_extractors/wchar_t/13.cc: New test.
* testsuite/27_io/basic_istream/extractors_character/char/5.cc: New test.
* testsuite/27_io/basic_istream/extractors_character/wchar_t/5.cc: New test.
arm: Clear canary value after stack_protect_test [PR96191]
The stack_protect_test patterns were leaving the canary value in the
temporary register, meaning that it was often still in registers on
return from the function. An attacker might therefore have been
able to use it to defeat stack-smash protection for a later function.
gcc/
PR target/96191
* config/arm/arm.md (arm_stack_protect_test_insn): Zero out
operand 2 after use.
* config/arm/thumb1.md (thumb1_stack_protect_test_insn): Likewise.
gcc/testsuite/
* gcc.target/arm/stack-protector-1.c: New test.
* gcc.target/arm/stack-protector-2.c: Likewise.
Jonathan Wakely [Thu, 6 Aug 2020 15:16:33 +0000 (16:16 +0100)]
libstdc++: Adjust overflow prevention to operator>>
This adjusts the overflow prevention added to operator>> so that we can
distinguish "unknown size" from "zero size", and avoid writing anything
at all in to zero sized buffers.
This also removes the incorrect comment saying extraction stops at a
null byte.
libstdc++-v3/ChangeLog:
* include/std/istream (operator>>(istream&, char*)): Add
attributes to get warnings for pointers that are null or known
to point to the end of a buffer. Request upper bound from
__builtin_object_size check and handle zero-sized buffer case.
(operator>>(istream&, signed char))
(operator>>(istream&, unsigned char*)): Add attributes.
* testsuite/27_io/basic_istream/extractors_character/char/overflow.cc:
Check extracting into the middle of a buffer.
* testsuite/27_io/basic_istream/extractors_character/wchar_t/overflow.cc: New test.
Peter Bergner [Thu, 6 Aug 2020 15:03:03 +0000 (10:03 -0500)]
rs6000: Don't ICE when spilling an MMA accumulator
When we spill an accumulator that has a known zero value, LRA will emit
a new (set (reg:PXI ...) 0) insn, but it does not use the mma_xxsetaccz
pattern to do it, leading to an unrecognized insn ICE. The solution here
is to move the xxsetaccz instruction into the movpxi pattern and have the
xxsetaccz pattern call the move pattern.
2020-08-06 Peter Bergner <bergner@linux.ibm.com>
gcc/
PR target/96446
* config/rs6000/mma.md (*movpxi): Add xxsetaccz generation.
Disable split for zero constant source operand.
(mma_xxsetaccz): Change to define_expand. Call gen_movpxi.
gcc/testsuite/
PR target/96446
* gcc.target/powerpc/pr96446.c: New test.
On the following testcase, if the IL before reassoc would be:
...
<bb 4> [local count: 354334800]:
if (x_3(D) == 2)
goto <bb 7>; [34.00%]
else
goto <bb 5>; [66.00%]
<bb 7> [local count: 1073741824]:
# prephitmp_7 = PHI <1(3), 1(4), 0(5), 1(2), 1(6)>
(i.e. the true/false edges on the last bb with condition swapped
and ditto for the phi args), we don't recognize it. If bb 6
is empty, there should be no functional difference between the two IL
representations.
This patch handles those special cases.
2020-08-06 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/96480
* tree-ssa-reassoc.c (suitable_cond_bb): Add TEST_SWAPPED_P argument.
If TEST_BB ends in cond and has one edge to *OTHER_BB and another
through an empty bb to that block too, if PHI args don't match, retry
them through the other path from TEST_BB.
(maybe_optimize_range_tests): Adjust callers. Handle such LAST_BB
through inversion of the condition.
This patch changes the existing support for BPF kernel helpers to be
more flexible, in two main ways.
First, there is no longer a hardcoded list of kernel helpers defined
in the compiler internals. This is replaced by a new target-specific
attribute `kernel_helper' that the user can use to define her own
helpers, annotating function prototypes.
Second, following feedback from the kernel hackers, the pre-defined
helpers in the distributed bpf-helpers.h are no longer available
conditionally depending on the kernel version used in -mkernel. The
command-line option stays for now, as it may be useful for other
things.
Target tests and documentation updated.
2020-08-06 Jose E. Marchesi <jose.marchesi@oracle.com>
gcc/
* config/bpf/bpf-helpers.h (KERNEL_HELPER): Define.
(KERNEL_VERSION): Remove.
* config/bpf/bpf-helpers.def: Delete.
* config/bpf/bpf.c (bpf_handle_fndecl_attribute): New function.
(bpf_attribute_table): Define.
(bpf_helper_names): Delete.
(bpf_helper_code): Likewise.
(enum bpf_builtins): Adjust to new helpers mechanism.
(bpf_output_call): Likewise.
(bpf_init_builtins): Likewise.
(bpf_init_builtins): Likewise.
* doc/extend.texi (BPF Function Attributes): New section.
(BPF Kernel Helpers): Delete section.
Richard Biener [Thu, 6 Aug 2020 10:18:24 +0000 (12:18 +0200)]
tree-optimization/96491 - avoid store commoning across abnormal edges
This avoids store commoning across abnormal edges since that easily
can disrupt abnormal coalescing because it might create overlapping
lifetime of variables.
2020-08-06 Richard Biener <rguenther@suse.de>
PR tree-optimization/96491
* tree-ssa-sink.c (sink_common_stores_to_bb): Avoid
sinking across abnormal edges.
Roger Sayle [Thu, 6 Aug 2020 08:15:25 +0000 (09:15 +0100)]
x86_64: Integer min/max improvements.
This patch tweaks the way that min and max are expanded, so that the
semantics of these operations are visible to the early RTL optimization
passes, until split into explicit comparison and conditional move
instructions. The good news is that i386.md already contains all of
the required logic (many thanks to Richard Biener and Uros Bizjak),
but this is currently only enabled to scalar-to-vector (STV) synthesis
of min/max instructions. This change enables this functionality for
all TARGET_CMOVE architectures for SImode, HImode and DImode.
2020-08-06 Roger Sayle <roger@nextmovesoftware.com>
Uroš Bizjak <ubizjak@gmail.com>
gcc/ChangeLog
* config/i386/i386.md (MAXMIN_IMODE): No longer needed.
(<maxmin><mode>3): Support SWI248 and general_operand for
second operand, when TARGET_CMOVE.
(<maxmin><mode>3_1 splitter): Optimize comparisons against
0, 1 and -1 to use "test" instead of "cmp".
(*<maxmin>di3_doubleword): Likewise, allow general_operand
and enable on TARGET_CMOVE.
(peephole2): Convert clearing a register after a flag setting
instruction into an xor followed by the original flag setter.
gcc/testsuite/ChangeLog
* gcc.target/i386/minmax-8.c: New test.
* gcc.target/i386/minmax-9.c: New test.
* gcc.target/i386/minmax-10.c: New test.
* gcc.target/i386/minmax-11.c: New test.
Gerald Pfeifer [Thu, 6 Aug 2020 07:02:15 +0000 (09:02 +0200)]
ipa-fnsummary: Include <vector> the proper way
This fixes a bootstrap error with clang 10 that would complain
/usr/include/c++/v1/typeinfo:346:5: error: no member named
'fancy_abort' in namespace 'std::__1'; did you mean simply
'fancy_abort'?
It mirrors how this is handled in gcov.c and indirectly includes
<vector> via system.h.
gcc/ChangeLog:
* ipa-fnsummary.c (INCLUDE_VECTOR): Define.
Remove direct inclusion of <vector>.
Kewen Lin [Wed, 29 Jul 2020 06:38:39 +0000 (14:38 +0800)]
vect/rs6000: Support vector with length cost modeling
This patch is to add the cost modeling for vector with length,
it mainly follows what we generate for vector with length in
functions vect_set_loop_controls_directly and vect_gen_len
at the worst case.
For Power, the length is expected to be in bits 0-7 (high bits),
we have to model the cost of shifting bits, which is implemented
in adjust_vect_cost_per_loop.
Bootstrapped/regtested on powerpc64le-linux-gnu (P9) with explicit
param vect-partial-vector-usage=1.
gcc/ChangeLog:
* config/rs6000/rs6000.c (rs6000_adjust_vect_cost_per_loop): New
function.
(rs6000_finish_cost): Call rs6000_adjust_vect_cost_per_loop.
* tree-vect-loop.c (vect_estimate_min_profitable_iters): Add cost
modeling for vector with length.
(vect_rgroup_iv_might_wrap_p): New function, factored out from...
* tree-vect-loop-manip.c (vect_set_loop_controls_directly): ...this.
Update function comment.
* tree-vect-stmts.c (vect_gen_len): Update function comment.
* tree-vectorizer.h (vect_rgroup_iv_might_wrap_p): New declare.
Kewen Lin [Wed, 5 Aug 2020 07:50:49 +0000 (02:50 -0500)]
vect: Skip epilogue loops for dbgcnt check [PR96451]
As the PR shows, commit r11-2453 exposed one issue that vectorizer
wants to vectorize the epilogue loop and leaves the if-cvt body there,
but later dbgcnt check disables it, the left scalar mask_store
statement causes ICE.
As Richard pointed out in that PR, the dbgcnt is to count original
scalar loops, so this fix is to make it skip the epilogue loops.
gcc/ChangeLog:
* tree-vectorizer.c (try_vectorize_loop_1): Skip the epilogue loops
for dbgcnt check.
P0487R1 resolved LWG 2499 for C++20 by removing the operator>> overloads
that have high risk of buffer overflows. They were replaced by
equivalents that only accept a reference to an array, and so can
guarantee not to write past the end of the array.
In order to support both the old and new functionality, this patch
introduces a new overloaded __istream_extract function which takes a
maximum length. The new operator>> overloads use the array size as the
maximum length. The old overloads now use __builtin_object_size to
determine the available buffer size if available (which requires -O2) or
use numeric_limits<streamsize>::max()/sizeof(char_type) otherwise. This
is a change in behaviour, as the old overloads previously always used
numeric_limits<streamsize>::max(), without considering sizeof(char_type)
and without attempting to prevent overflows.
Because they now do little more than call __istream_extract, the old
operator>> overloads are very small inline functions. This means there
is no advantage to explicitly instantiating them in the library (in fact
that would prevent the __builtin_object_size checks from ever working).
As a result, the explicit instantiation declarations can be removed from
the header. The explicit instantiation definitions are still needed, for
backwards compatibility with existing code that expects to link to the
definitions in the library.
While working on this change I noticed that src/c++11/istream-inst.cc
has the following explicit instantiation definition:
template istream& operator>>(istream&, char*);
This had no effect (and so should not have been present in that file),
because there was an explicit specialization declared in <istream> and
defined in src/++98/istream.cc. However, this change removes the
explicit specialization, and now the explicit instantiation definition
is necessary to ensure the symbol gets defined in the library.
libstdc++-v3/ChangeLog:
* config/abi/pre/gnu.ver (GLIBCXX_3.4.29): Export new symbols.
* include/bits/istream.tcc (__istream_extract): New function
template implementing both of operator>>(istream&, char*) and
operator>>(istream&, char(&)[N]). Add explicit instantiation
declaration for it. Remove explicit instantiation declarations
for old function templates.
* include/std/istream (__istream_extract): Declare.
(operator>>(basic_istream<C,T>&, C*)): Define inline and simply
call __istream_extract.
(operator>>(basic_istream<char,T>&, signed char*)): Likewise.
(operator>>(basic_istream<char,T>&, unsigned char*)): Likewise.
(operator>>(basic_istream<C,T>&, C(7)[N])): Define for LWG 2499.
(operator>>(basic_istream<char,T>&, signed char(&)[N])):
Likewise.
(operator>>(basic_istream<char,T>&, unsigned char(&)[N])):
Likewise.
* include/std/streambuf (basic_streambuf): Declare char overload
of __istream_extract as a friend.
* src/c++11/istream-inst.cc: Add explicit instantiation
definition for wchar_t overload of __istream_extract. Remove
explicit instantiation definitions of old operator>> overloads
for versioned-namespace build.
* src/c++98/istream.cc (operator>>(istream&, char*)): Replace
with __istream_extract(istream&, char*, streamsize).
* testsuite/27_io/basic_istream/extractors_character/char/3.cc:
Do not use variable-length array.
* testsuite/27_io/basic_istream/extractors_character/char/4.cc:
Do not run test for C++20.
* testsuite/27_io/basic_istream/extractors_character/char/9555-ic.cc:
Do not test writing to pointers for C++20.
* testsuite/27_io/basic_istream/extractors_character/char/9826.cc:
Use array instead of pointer.
* testsuite/27_io/basic_istream/extractors_character/wchar_t/3.cc:
Do not use variable-length array.
* testsuite/27_io/basic_istream/extractors_character/wchar_t/4.cc:
Do not run test for C++20.
* testsuite/27_io/basic_istream/extractors_character/wchar_t/9555-ic.cc:
Do not test writing to pointers for C++20.
* testsuite/27_io/basic_istream/extractors_character/char/lwg2499.cc:
New test.
* testsuite/27_io/basic_istream/extractors_character/char/lwg2499_neg.cc:
New test.
* testsuite/27_io/basic_istream/extractors_character/char/overflow.cc:
New test.
* testsuite/27_io/basic_istream/extractors_character/wchar_t/lwg2499.cc:
New test.
* testsuite/27_io/basic_istream/extractors_character/wchar_t/lwg2499_neg.cc:
New test.
Patrick Palka [Wed, 5 Aug 2020 19:05:30 +0000 (15:05 -0400)]
c++: cxx_eval_vec_init after zero-initialization [PR96282]
In the first testcase below, expand_aggr_init_1 sets up t's default
constructor such that the ctor first zero-initializes the entire base b,
followed by calling b's default constructor, the latter of which just
default-initializes the array member b::m via a VEC_INIT_EXPR.
So upon constexpr evaluation of this latter VEC_INIT_EXPR, ctx->ctor is
nonempty due to the prior zero-initialization, and we proceed in
cxx_eval_vec_init to append new constructor_elts to the end of ctx->ctor
without first checking if a matching constructor_elt already exists.
This leads to ctx->ctor having two matching constructor_elts for each
index.
This patch fixes this issue by truncating a zero-initialized array
CONSTRUCTOR in cxx_eval_vec_init_1 before we begin appending array
elements to it. We propagate its zeroed out state during evaluation by
clearing CONSTRUCTOR_NO_CLEARING on each new appended aggregate element.
gcc/cp/ChangeLog:
PR c++/96282
* constexpr.c (cxx_eval_vec_init_1): Truncate ctx->ctor and
then clear CONSTRUCTOR_NO_CLEARING on each appended element
initializer if we're initializing a previously zero-initialized
array object.
gcc/testsuite/ChangeLog:
PR c++/96282
* g++.dg/cpp0x/constexpr-array26.C: New test.
* g++.dg/cpp0x/constexpr-array27.C: New test.
* g++.dg/cpp2a/constexpr-init18.C: New test.
Thomas Koenig [Wed, 5 Aug 2020 16:37:32 +0000 (18:37 +0200)]
Static analysis for definition of DO index variables in contained procedures.
When encountering a procedure call in a DO loop, this patch checks if
the call is to a contained procedure, and if it is, check for
changes in the index variable.
gcc/fortran/ChangeLog:
PR fortran/96469
* frontend-passes.c (doloop_contained_function_call): New
function.
(doloop_contained_procedure_code): New function.
(CHECK_INQ): Macro for inquire checks.
(doloop_code): Invoke doloop_contained_procedure_code and
doloop_contained_function_call if appropriate.
(do_intent): Likewise.
gcc/testsuite/ChangeLog:
PR fortran/96469
* gfortran.dg/do_check_4.f90: Hide change in index variable
from compile-time analysis.
* gfortran.dg/do_check_13.f90: New test.
Marc Glisse [Wed, 5 Aug 2020 14:45:33 +0000 (16:45 +0200)]
VEC_COND_EXPR optimizations
When vector comparisons were forced to use vec_cond_expr, we lost a number of optimizations (my fault for not adding enough testcases to
prevent that). This patch tries to unwrap vec_cond_expr a bit so some optimizations can still happen.
I wasn't planning to add all those transformations together, but adding one caused a regression, whose fix introduced a second regression,
etc.
Restricting to constant folding would not be sufficient, we also need at least things like X|0 or X&X. The transformations are quite
conservative with :s and folding only if everything simplifies, we may want to relax this later. And of course we are going to miss things
like a?b:c + a?c:b -> b+c.
In terms of number of operations, some transformations turning 2 VEC_COND_EXPR into VEC_COND_EXPR + BIT_IOR_EXPR + BIT_NOT_EXPR might not look
like a gain... I expect the bit_not disappears in most cases, and VEC_COND_EXPR looks more costly than a simpler BIT_IOR_EXPR.
2020-08-05 Marc Glisse <marc.glisse@inria.fr>
PR tree-optimization/95906
PR target/70314
* match.pd ((c ? a : b) op d, (c ? a : b) op (c ? d : e),
(v ? w : 0) ? a : b, c1 ? c2 ? a : b : b): New transformations.
(op (c ? a : b)): Update to match the new transformations.
* gcc.dg/tree-ssa/andnot-2.c: New file.
* gcc.dg/tree-ssa/pr95906.c: Likewise.
* gcc.target/i386/pr70314.c: Likewise.
aarch64: Clear canary value after stack_protect_test [PR96191]
The stack_protect_test patterns were leaving the canary value in the
temporary register, meaning that it was often still in registers on
return from the function. An attacker might therefore have been
able to use it to defeat stack-smash protection for a later function.
gcc/
PR target/96191
* config/aarch64/aarch64.md (stack_protect_test_<mode>): Set the
CC register directly, instead of a GPR. Replace the original GPR
destination with an extra scratch register. Zero out operand 3
after use.
(stack_protect_test): Update accordingly.
gcc/testsuite/
PR target/96191
* gcc.target/aarch64/stack-protector-1.c: New test.
* gcc.target/aarch64/stack-protector-2.c: Likewise.
aarch64: Add missing %z prefixes to LDP/STP patterns
For LDP/STP Q, the memory operand might not be valid for "m",
so we need to use %z<N> instead of %<N> in the asm template.
This patch does that for all Ump LDP/STP patterns, regardless
of whether it's strictly needed.
This is needed to unbreak bootstrap.
2020-08-05 Richard Sandiford <richard.sandiford@arm.com>
gcc/
* config/aarch64/aarch64.md (load_pair_sw_<SX:mode><SX2:mode>)
(load_pair_dw_<DX:mode><DX2:mode>, load_pair_dw_tftf)
(store_pair_sw_<SX:mode><SX2:mode>)
(store_pair_dw_<DX:mode><DX2:mode>, store_pair_dw_tftf)
(*load_pair_extendsidi2_aarch64)
(*load_pair_zero_extendsidi2_aarch64): Use %z for the memory operand.
* config/aarch64/aarch64-simd.md (load_pair<DREG:mode><DREG2:mode>)
(vec_store_pair<DREG:mode><DREG2:mode>, load_pair<VQ:mode><VQ2:mode>)
(vec_store_pair<VQ:mode><VQ2:mode>): Likewise.
Richard Biener [Wed, 5 Aug 2020 10:04:59 +0000 (12:04 +0200)]
refactor LIM a bit
This refactors LIM to eschew alloc_aux_for_edges and re-uses the RPO
order of the move_computations walk for invariantness computation as well.
It also removes one unnecessary sorting (but retaining it as checking
code because we bsearch the vector) and moves edge insert commit code
to the place where it doesn't have to scan all the functions edges.
This was all done when investigating whether LIM can be refactored
to work on a specific loop for on-demand processing (but we're not
there yet).
2020-08-05 Richard Biener <rguenther@suse.de>
* tree-ssa-loop-im.c (invariantness_dom_walker): Remove.
(invariantness_dom_walker::before_dom_children): Move to ...
(compute_invariantness): ... this function.
(move_computations): Inline ...
(tree_ssa_lim): ... here, share RPO order and avoid some
cfun references.
(analyze_memory_references): Remove sorting of location
lists, instead assert they are sorted already when checking.
(prev_flag_edges): Remove.
(execute_sm_if_changed): Pass down and adjust prev edge state.
(execute_sm_exit): Likewise.
(hoist_memory_references): Likewise. Commit edge insertions
of each processed exit.
(store_motion_loop): Do not commit edge insertions on all
edges in the function.
(tree_ssa_lim_initialize): Do not call alloc_aux_for_edges.
(tree_ssa_lim_finalize): Do not call free_aux_for_edges.
Richard Biener [Wed, 5 Aug 2020 10:00:07 +0000 (12:00 +0200)]
Make genmatch transform failure handling more consistent
Currently whether a fail during the transform stage is fatal or
whether following patterns are still considers is a bit random
depending on whether the pattern is wrapped in a for for example.
The follwing makes it consistent by replacing early returns with
gotos to the end of the pattern processing.
2020-08-05 Richard Biener <rguenther@suse.de>
* genmatch.c (fail_label): New global.
(expr::gen_transform): Branch to fail_label instead of
returning. Fix indent of call argument checking.
(dt_simplify::gen_1): Compute and emit fail_label, branch
to it instead of returning early.
Jakub Jelinek [Wed, 5 Aug 2020 08:45:16 +0000 (10:45 +0200)]
openmp: Handle even some combined non-rectangular loops
The number of loops computation and logical iteration -> actual iterator values
computations can now be done separately even on composite constructs (though
for triangular loops it would still be more efficient to propagate a few values
through, will handle that incrementally).
simd and taskloop are still unhandled.
Jakub Jelinek [Wed, 5 Aug 2020 08:40:10 +0000 (10:40 +0200)]
openmp: Handle reduction clauses on host teams construct [PR96459]
As the new testcase shows, we weren't actually performing reductions on
host teams construct. And fixing that revealed a flaw in the for-14.c testcase.
The problem is that the tests perform also initialization and checking around the
calls to the functions with the OpenMP constructs. In that testcase, all the
tests have been spawned from a teams construct but only the tested loops were
distribute, which means the initialization and checking has been performed
redundantly and racily in each team. Fixed by performing the initialization
and checking outside of host teams and only do the calls to functions with
the tested constructs inside of host teams.
2020-08-05 Jakub Jelinek <jakub@redhat.com>
PR middle-end/96459
* omp-low.c (lower_omp_taskreg): Call lower_reduction_clauses even in
for host teams.
* testsuite/libgomp.c/teams-3.c: New test.
* testsuite/libgomp.c-c++-common/for-2.h (OMPTEAMS): Define to nothing
if not defined yet.
(N(test)): Use it before all N(f*) calls.
* testsuite/libgomp.c-c++-common/for-14.c (DO_PRAGMA, OMPTEAMS): Define.
(main): Don't call all test_* functions from within
#pragma omp teams reduction(|:err), call them directly.
Jakub Jelinek [Wed, 5 Aug 2020 08:37:25 +0000 (10:37 +0200)]
openmp: Use more efficient logical -> actual computation even if # iterations is computed at runtime
For triangular loops use more efficient logical iteration number
to actual iterator values computation even for non-rectangular loops
where number of loop iterations could not be computed at compile time.
2020-08-05 Jakub Jelinek <jakub@redhat.com>
* omp-expand.c (expand_omp_for_init_counts): Remember
first_inner_iterations, factor and n1o from the number of iterations
computation in *fd.
(expand_omp_for_init_vars): Use more efficient logical iteration number
to actual iterator values computation even for non-rectangular loops
where number of loop iterations could not be computed at compile time.
Carl Love [Wed, 27 May 2020 15:07:44 +0000 (10:07 -0500)]
rs6000, Add vector splat builtin support
GCC maintainers:
The following patch adds support for the vec_splati, vec_splatid and
vec_splati_ins builtins.
This patch adds support for instructions that take a 32-bit immediate
value that represents a floating point value. This support adds new
predicates and a support function to properly handle the immediate value.
Carl Love [Thu, 2 Jul 2020 20:30:30 +0000 (15:30 -0500)]
rs6000, Update support for vec_extract
GCC maintainers:
Move the existing vector extract support in altivec.md to vsx.md
so all of the vector insert and extract support is in the same file.
The patch also updates the name of the builtins and descriptions for the
builtins in the documentation file so they match the approved builtin
names and descriptions.
The patch does not make any functional changes.
Please let me know if the changes are acceptable for mainline. Thanks.
Marek Polacek [Tue, 4 Aug 2020 13:35:25 +0000 (09:35 -0400)]
c++: Template keyword following :: [PR96082]
In r9-4235 I tried to make sure that the template keyword follows
a nested-name-specifier. :: is a valid nested-name-specifier, so
I also have to check 'globalscope' before giving the error.
gcc/cp/ChangeLog:
PR c++/96082
* parser.c (cp_parser_elaborated_type_specifier): Allow
'template' following ::.
gcc/testsuite/ChangeLog:
PR c++/96082
* g++.dg/template/template-keyword3.C: New test.
If we lower a constant string operation in a Binary_expression,
delete the strings. This is safe because constant strings are always
newly allocated.
This is a hack to use much less memory when compiling the new
time/tzdata package, which has a file that contains the sum of over
13,000 constant strings. We don't do this for numeric expressions
because that could cause us to delete an Iota_expression.
We should have a cleaner approach to memory usage some day.
Omar Tahir [Tue, 4 Aug 2020 16:35:18 +0000 (17:35 +0100)]
[Arm] Modify default tuning of armv8.1-m.main to use Cortex-M55
Previously, compiling with -march=armv8.1-m.main would tune for
Cortex-M7.
However, the Cortex-M7 only supports up to Armv7e-M. The Cortex-M55 is
the earliest CPU that supports Armv8.1-M Mainline so is more appropriate.
This also has the effect of changing the branch cost function used, which
will be necessary to correctly prioritise conditional instructions over branches
in the rest of this patch series.
Regression tested on arm-none-eabi.
gcc/ChangeLog
2020-08-04 Omar Tahir <omar.tahir@arm.com>
* config/arm/arm-cpus.in (armv8.1-m.main): Tune for Cortex-M55.
Nathan Sidwell [Tue, 4 Aug 2020 16:24:02 +0000 (09:24 -0700)]
c++: fix template parm count leak
I noticed that we could leak parser->num_template_parameter_lists with
erroneous specializations. We'd increment, notice a problem and then
bail out. This refactors cp_parser_explicit_specialization to avoid
that code path. A couple of tests get different diagnostics because
of the fix. pr39425 then goes to unbounded template instantiation
and exceeds the implementation limit.
xiezhiheng [Tue, 4 Aug 2020 16:25:29 +0000 (17:25 +0100)]
AArch64: Use FLOAT_MODE_P macro and add FLAG_AUTO_FP [PR94442]
Since all FP intrinsics are set by FLAG_FP by default, but not all FP intrinsics
raise FP exceptions or read FPCR register. So we add a global flag FLAG_AUTO_FP
to suppress the flag FLAG_FP.
2020-08-04 Zhiheng Xie <xiezhiheng@huawei.com>
gcc/ChangeLog:
* config/aarch64/aarch64-builtins.c (aarch64_call_properties):
Use FLOAT_MODE_P macro instead of enumerating all floating-point
modes and add global flag FLAG_AUTO_FP.
Roger Sayle [Tue, 4 Aug 2020 15:56:06 +0000 (16:56 +0100)]
Test case for PR rtl-optimization/60473
PR rtl-optimization/60473 is code quality regression that has
been cured by improvements to register allocation. For the function
in the test case, GCC 4.4, 4.5 and 4.6 generated very poor code
requiring two mov instructions, and GCC 4.7 and 4.8 (when the PR was
filed) produced better but still poor code with one mov instruction.
Since GCC 4.9 (including current mainline), it generates optimal
code with no mov instructions, matching what used to be generated
in GCC 4.1.
2020-08-04 Roger Sayle <roger@nextmovesoftware.com>
gcc/testsuite/ChangeLog
PR rtl-optimization/60473
* gcc.target/i386/pr60473.c: New test.
Marc Glisse [Tue, 4 Aug 2020 15:30:16 +0000 (17:30 +0200)]
Simplify X * C1 == C2 with undefined overflow
this transformation is quite straightforward, without overflow, 3*X==15 is
the same as X==5 and 3*X==5 cannot happen. Adding a single_use restriction
for the first case didn't seem necessary, although of course it can
slightly increase register pressure in some cases.
d: Fix struct literals that have non-deterministic hash values (PR96153)
Adds code generation for generating a temporary for, and pre-filling
struct and array literals with zeroes before assigning, so that
alignment holes don't cause objects to produce a non-deterministic hash
value. A new field has been added to the expression visitor to track
whether the result is being generated for another literal, so that
memset() is only called once on the top-level literal expression, and
not for nesting struct or arrays.
gcc/d/ChangeLog:
PR d/96153
* d-tree.h (build_expr): Add literalp argument.
* expr.cc (ExprVisitor): Add literalp_ field.
(ExprVisitor::ExprVisitor): Initialize literalp_.
(ExprVisitor::visit (AssignExp *)): Call memset() on blits where RHS
is a struct literal. Elide assignment if initializer is all zeroes.
(ExprVisitor::visit (CastExp *)): Forward literalp_ to generation of
subexpression.
(ExprVisitor::visit (AddrExp *)): Likewise.
(ExprVisitor::visit (ArrayLiteralExp *)): Use memset() to pre-fill
object with zeroes. Set literalp in subexpressions.
(ExprVisitor::visit (StructLiteralExp *)): Likewise.
(ExprVisitor::visit (TupleExp *)): Set literalp in subexpressions.
(ExprVisitor::visit (VectorExp *)): Likewise.
(ExprVisitor::visit (VectorArrayExp *)): Likewise.
(build_expr): Forward literal_p to ExprVisitor.
Andrew Stubbs [Fri, 31 Jul 2020 10:27:24 +0000 (11:27 +0100)]
amdgcn: TImode shifts
Implement TImode shifts in the backend.
The middle-end support that does it for other architectures doesn't work for
GCN because BITS_PER_WORD==32, meaning that TImode is quad-word, not
double-word.