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.
Jason Merrill [Fri, 20 Nov 2020 20:20:45 +0000 (15:20 -0500)]
dwarf2: ICE with local class in unused function [PR97918]
Here, since we only mention bar<B>, we never emit debug information for it.
But we do emit debug information for H<J>::h, so we need to refer to the
debug info for bar<B>::J even though there is no bar<B>. We deal with this
sort of thing in dwarf2out with the limbo_die_list; parentless dies like J
get attached to the CU at EOF. But here, we were flushing the limbo list,
then generating the template argument DIE for H<J> that refers to J, which
adds J to the limbo list, too late to be flushed. So let's flush a little
later.
gcc/ChangeLog:
PR c++/97918
* dwarf2out.c (dwarf2out_early_finish): flush_limbo_die_list
after gen_scheduled_generic_parms_dies.
gcc/testsuite/ChangeLog:
PR c++/97918
* g++.dg/debug/localclass2.C: New test.
Jason Merrill [Thu, 8 Oct 2020 19:43:26 +0000 (15:43 -0400)]
c++: Fix member alias template in C++17 and up. [PR96805]
Here we're trying to push into a<T>::c<N> in order to instantiate t<N>, but
were building a TYPENAME_TYPE for it because a<T> isn't open yet. Don't
do that when we know we're trying to enter the scope.
gcc/cp/ChangeLog:
PR c++/96805
PR c++/96199
* pt.c (tsubst_aggr_type): Don't build a TYPENAME_TYPE when
entering_scope.
(tsubst_template_decl): Use tsubst_aggr_type.
gcc/testsuite/ChangeLog:
PR c++/96805
* g++.dg/cpp0x/alias-decl-pr96805.C: New test.
Richard Earnshaw [Tue, 24 Nov 2020 16:21:17 +0000 (16:21 +0000)]
arm: correctly handle negating INT_MIN in arm_split_atomic_op [PR97534]
arm_split_atomic_op handles subtracting a constant by converting it
into addition of the negated constant. But if the type of the operand
is int and the constant is -1 we currently end up generating invalid
RTL which can lead to an abort later on.
The problem is that in a HOST_WIDE_INT, INT_MIN is represented as
0xffffffff80000000 and the negation of this is 0x0000000080000000, but
that's not a valid constant for use in SImode operations.
The fix is straight-forward which is to use gen_int_mode rather than
simply GEN_INT. This knows how to correctly sign-extend the negated
constant when this is needed.
gcc/
PR target/97534
* config/arm/arm.c (arm_split_atomic_op): Use gen_int_mode when
negating a const_int.
gcc/testsuite
* gcc.dg/pr97534.c: New test.
Thomas Schwinge [Fri, 20 Nov 2020 09:41:46 +0000 (10:41 +0100)]
More explicit checking of which OMP constructs we're expecting, part II
In particular, more precisely highlight what applies generally vs. the special
handling for the current 'parloops'-based OpenACC 'kernels' implementation.
gcc/
* omp-expand.c (expand_oacc_for): More explicit checking of which
OMP constructs we're expecting.
Thomas Schwinge [Fri, 6 Nov 2020 08:51:16 +0000 (09:51 +0100)]
[testsuite] Emit 'warning' instead of 'error' diagnostics for 'dg-optimized', 'dg-missed'
The diagnostics produced by 'dg-optimized', 'dg-missed' aren't error
diagnostics (fatal, meaning: causes compilation to fail) but rather warning
diagnostics (non-fatal, doesn't cause compilation to fail). Thus, same as
'dg-message', these should use 'saved-dg-warning' instead of 'saved-dg-error',
which then prints: "(test for *warnings*, line [...]) instead of currently:
"(test for *errors*, line [...])".
This is a small bug-fix for commit ed2d9d3720adef3a260b8a55e17e744352a901fc
"dumpfile.c: use prefixes other than 'note: ' for
MSG_{OPTIMIZED_LOCATIONS|MISSED_OPTIMIZATION}", which added 'dg-optimized',
'dg-missed'.
gcc/testsuite/
* lib/gcc-dg.exp (dg-optimized, dg-missed): Use 'saved-dg-warning'
instead of 'saved-dg-error'.
Thomas Schwinge [Fri, 6 Nov 2020 08:18:06 +0000 (09:18 +0100)]
[testsuite] Enable column location checking for 'dg-optimized', 'dg-missed'
'process-message' would like the 'msgprefix' argument without trailing space.
This is a small bug-fix for commit ed2d9d3720adef3a260b8a55e17e744352a901fc
"dumpfile.c: use prefixes other than 'note: ' for
MSG_{OPTIMIZED_LOCATIONS|MISSED_OPTIMIZATION}", which added 'dg-optimized',
'dg-missed'.
Iain Buclaw [Sun, 22 Nov 2020 13:29:54 +0000 (14:29 +0100)]
d: Fix OutOfMemoryError thrown when appending to an array with a side effect
When appending a character to an array, the result of that concat
assignment was not the new value of the array, similarly, when appending
an array to another array, side effects were evaluated in reverse to the
expected order of evaluation.
As of this change, the address of the left-hand side expression is
saved and re-used as the result. Its evaluation is now also forced to
occur before the concat operation itself is called.
gcc/d/ChangeLog:
PR d/97889
* expr.cc (ExprVisitor::visit (CatAssignExp *)): Enforce LTR order of
evaluation on left and right hand side expressions.
Jonathan Wakely [Fri, 20 Nov 2020 11:30:33 +0000 (11:30 +0000)]
libstdc++: Remove <memory_resource> dependency from <regex> [PR 92546]
Unlike the other headers that declare alias templates in namespace pmr,
<regex> includes <memory_resource>. That was done because the
pmr::string::const_iterator typedef requires pmr::string to be complete,
which requires pmr::polymorphic_allocator<char> to be complete.
By using __normal_iterator<const char*, pmr::string> instead of the
const_iterator typedef we can avoid the completeness requirement.
This makes <regex> smaller, by not requiring <memory_resource> and its
<shared_mutex> dependency, which depends on <chrono>. Backporting this
will also help with PR 97876, where <stop_token> ends up being needed by
<regex> via <memory_resource>.
libstdc++-v3/ChangeLog:
PR libstdc++/92546
* include/std/regex (pmr::smatch, pmr::wsmatch): Declare using
underlying __normal_iterator type, not nested typedef
basic_string::const_iterator.
Jonathan Wakely [Thu, 19 Nov 2020 22:32:54 +0000 (22:32 +0000)]
libstdc++: Fix compilation error with clang-8 [PR 97876]
This fixes a compilation error with clang-8 and earlier. This change is
only on the gcc-10 branch, not master, because the <stop_token> header
is included indirectly in more places on the branch than on master.
PR libstdc++/97876
* include/std/stop_token (_Stop_state_t): Define default
constructor as user-provided not defaulted.
Jonathan Wakely [Thu, 19 Nov 2020 21:07:06 +0000 (21:07 +0000)]
libstdc++: Avoid calling undefined __gthread_self weak symbol [PR 95989]
Since glibc 2.27 the pthread_self symbol has been defined in libc rather
than libpthread. Because we only call pthread_self through a weak alias
it's possible for statically linked executables to end up without a
definition of pthread_self. This crashes when trying to call an
undefined weak symbol.
We can use the __GLIBC_PREREQ version check to detect the version of
glibc where pthread_self is no longer in libpthread, and call it
directly rather than through the weak reference.
It would be better to check for pthread_self in libc during configure
instead of hardcoding the __GLIBC_PREREQ check. That would be
complicated by the fact that prior to glibc 2.27 libc.a didn't have the
pthread_self symbol, but libc.so.6 did. The configure checks would need
to try to link both statically and dynamically, and the result would
depend on whether the static libc.a happens to be installed during
configure (which could vary between different systems using the same
version of glibc). Doing it properly is left for a future date, as that
will be needed anyway after glibc moves all pthread symbols from
libpthread to libc. When that happens we should revisit the whole
approach of using weak symbols for pthread symbols.
For the purposes of std::this_thread::get_id() we call
pthread_self() directly when using glibc 2.27 or later. Otherwise, if
__gthread_active_p() is true then we know the libpthread symbol is
available so we call that. Otherwise, we are single-threaded and just
use ((__gthread_t)1) as the thread ID.
An undesirable consequence of this change is that code compiled prior to
the change might inline the old definition of this_thread::get_id()
which always returns (__gthread_t)1 in a program that isn't linked to
libpthread. Code compiled after the change will use pthread_self() and
so get a real TID. That could result in the main thread having different
thread::id values in different translation units. This seems acceptable,
as there are not expected to be many uses of thread::id in programs
that aren't linked to libpthread.
An earlier version of this patch also changed __gthread_self() to use
__GLIBC_PREREQ(2, 27) and only use the weak symbol for older glibc. Tha
might still make sense to do, but isn't needed by libstdc++ now.
libstdc++-v3/ChangeLog:
PR libstdc++/95989
* config/os/gnu-linux/os_defines.h (_GLIBCXX_NATIVE_THREAD_ID):
Define new macro to get reliable thread ID.
* include/std/stop_token (_Stop_state_t::_M_request_stop):
Use new macro if it's defined.
(_Stop_state_t::_M_remove_callback): Likewise.
* include/std/thread (this_thread::get_id): Likewise.
* testsuite/30_threads/jthread/95989.cc: New test.
* testsuite/30_threads/this_thread/95989.cc: New test.
Alex Coplan [Thu, 12 Nov 2020 10:03:21 +0000 (10:03 +0000)]
aarch64: Fix SVE2 BCAX pattern [PR97730]
This patch adds a missing not to the SVE2 BCAX (Bitwise clear and
exclusive or) pattern, fixing the PR. Since SVE doesn't have an
unpredicated not instruction, we need to use a (vacuously) predicated
not here.
To ensure that the predicate is instantiated correctly (to all 1s) for
the intrinsics, we pull out a separate expander from the define_insn.
From the ISA reference [1]:
> Bitwise AND elements of the second source vector with the
> corresponding inverted elements of the third source vector, then
> exclusive OR the results with corresponding elements of the first
> source vector.
Uros Bizjak [Thu, 19 Nov 2020 08:26:01 +0000 (09:26 +0100)]
i386: Disable *<absneg:code><mode>2_i387_1 for TARGET_SSE_MATH modes
This pattern interferes with *<absneg:code><mode>2_1 when TARGET_SSE_MATH
modes are active. Combine pass is able to remove (use) RTXes and transforms
*<absneg:code><mode>2_1 to *<absneg:code><mode>2_i387_1 where SSE
alternatives are not available.
2020-11-19 Uroš Bizjak <ubizjak@gmail.com>
gcc/
PR target/97887
* config/i386/i386.md (*<absneg:code><mode>2_i387_1):
Disable for TARGET_SSE_MATH modes.
gcc/testsuite/
PR target/97887
* gcc.target/i386/pr97887.c: New test.
This applies the proposed resolution of LWG 3500, which corrects the
return type and constraints of this member function to use the right
iterator type. Additionally, a nearby local variable is uglified.
libstdc++-v3/ChangeLog:
* include/std/ranges (join_view::_Iterator::_M_satisfy): Uglify
local variable inner.
(join_view::_Iterator::operator->): Use _Inner_iter instead of
_Outer_iter in the function signature as per LWG 3500.
* testsuite/std/ranges/adaptors/join.cc (test08): Test it.
Jonathan Wakely [Tue, 6 Oct 2020 08:41:16 +0000 (09:41 +0100)]
libstdc++: Avoid CTAD for std::ranges::join_view [LWG 3474]
In commit ef275d1f2083f8a1fa1b59a3cd07fd3e8431023e I implemented the
wrong resolution of LWG 3474. This removes the deduction guide and
alters the views::join factory to create the right type explicitly.
libstdc++-v3/ChangeLog:
* include/std/ranges (join_view): Remove deduction guide.
(views::join): Add explicit template argument list to prevent
deducing the wrong type.
* testsuite/std/ranges/adaptors/join.cc: Move test for LWG 3474
here, from ...
* testsuite/std/ranges/adaptors/join_lwg3474.cc: Removed.
Jonathan Wakely [Thu, 10 Sep 2020 17:51:24 +0000 (18:51 +0100)]
libstdc++: Fix macro redefinition warnings
Including <version> after <iterator> gives a warning about redefining
the __cpp_lib_array_constexpr macro. What happens is that <iterator>
sets the C++20 value, then <version> redefines it to the C++17 value,
then undefines it and defines it again to the C++20 value.
This change avoids defining it to the C++17 value when compiling C++20
or later (which also means we no longer need the #undef).
A similar warning happens for __cpp_lib_constexpr_char_traits when
including <version> after any header that includes <bits/char_traits.h>.
libstdc++-v3/ChangeLog:
* include/std/version (__cpp_lib_array_constexpr)
(__cpp_lib_constexpr_char_traits): Only define C++17 value when
compiling C++17.
Jonathan Wakely [Mon, 15 Jun 2020 13:31:26 +0000 (14:31 +0100)]
libstdc++: Update value of __cpp_lib_constexpr_char_traits for C++20
Although not required by SD-6 or the C++20 draft, we define the macro
__cpp_lib_constexpr_char_traits to indicate support for P0432R1. This
updates the value in C++20 mode for the P1032R1 changes to char_traits.
* include/bits/char_traits.h (__cpp_lib_constexpr_char_traits):
Update value for C++20.
* include/std/version (__cpp_lib_constexpr_char_traits): Likewise.
* testsuite/21_strings/char_traits/requirements/constexpr_functions_c++17.cc:
Update expected value.
Jonathan Wakely [Tue, 17 Nov 2020 15:26:29 +0000 (15:26 +0000)]
libstdc++: Fix unconditional definition of __cpp_lib_span in <version> [PR 97869}
The <span> header is empty unless Concepts are supported, but <version>
defines the __cpp_lib_span feature test macro unconditionally. It should
be guarded by the same conditions as in <span>.
libstdc++-v3/ChangeLog:
PR libstdc++/97869
* include/precompiled/stdc++.h: Include <coroutine>.
* include/std/version (__cpp_lib_span): Check __cpp_lib_concepts
before defining.
Iain Buclaw [Tue, 17 Nov 2020 12:11:33 +0000 (13:11 +0100)]
d: Fix LHS of array concatentation evaluated before the RHS.
In an array append expression:
array ~= fun(array);
The array in the left hand side of the expression was extended before
evaluating the result of the right hand side, which resulted in the
newly uninitialized array index being used before set.
This fixes that so that the result of the right hand side is always
saved in a reusable temporary before assigning to the destination.
gcc/d/ChangeLog:
PR d/97843
* d-codegen.cc (build_assign): Evaluate TARGET_EXPR before use in
the right hand side of an assignment.
* expr.cc (ExprVisitor::visit (CatAssignExp *)): Force a TARGET_EXPR
on the element to append if it is a CALL_EXPR.
Iain Buclaw [Tue, 17 Nov 2020 09:48:41 +0000 (10:48 +0100)]
d: Fix a couple of ICEs found in the dmd front-end (PR97842)
- Segmentation fault on incomplete static if.
- Segmentation fault resolving typeof() expression when gagging is on.
gcc/d/ChangeLog:
PR d/97842
* dmd/cond.c (StaticIfCondition::include): Return error if condition
expression is unset.
* dmd/mtype.c (TypeTypeof::resolve): Return error if scope is unset.
gcc/testsuite/ChangeLog:
PR d/97842
* gdc.test/fail_compilation/fail18970.d: New test.
* gdc.test/fail_compilation/imports/test21164a.d: New test.
* gdc.test/fail_compilation/imports/test21164b.d: New test.
* gdc.test/fail_compilation/imports/test21164c.d: New test.
* gdc.test/fail_compilation/imports/test21164d.d: New test.
* gdc.test/fail_compilation/test21164.d: New test.
Iain Buclaw [Fri, 13 Nov 2020 08:57:57 +0000 (09:57 +0100)]
d: Explicitly determine which built-in copysign function to call.
For some targets, mathfn_built_in returns NULL as copysign is not
implicitly available, causing an ICE. Now copysign is explicitly
requested when expanding the intrinsic.
gcc/d/ChangeLog:
* intrinsics.cc (expand_intrinsic_copysign): Explicitly determine
which built-in copysign function to call.
Iain Buclaw [Fri, 23 Oct 2020 07:41:11 +0000 (09:41 +0200)]
d: Fix undefined template references with circular module imports
In `TemplateInstance::semantic`, there exists special handling of
matching template instances for the same template declaration to ensure
that only at most one instance gets codegen'd.
If the primary instance `inst` originated from a non-root module, the
`minst` field will be updated so it is now coming from a root module,
however all Dsymbol `inst->members` of the instance still have their
`_scope->minst` pointing at the original non-root module. We must now
propagate `minst` to all members so that forward referenced dependencies
that get instantiated will also be appended to the root module,
otherwise there will be undefined references at link-time.
This doesn't affect compilations where all modules are compiled
together, as every module is a root module in that situation. What this
primarily affects are cases where there is a mix of root and non-root
modules, and a template was first instantiated in a non-root context,
then later instantiated again in a root context.
gcc/d/ChangeLog:
* dmd/dtemplate.c (TemplateInstance::semantic): Propagate the root
module where the instantiated template should belong from the instance
to all member scopes.
gcc/testsuite/ChangeLog:
* gdc.test/compilable/imports/test21299/func.d: New test.
* gdc.test/compilable/imports/test21299/mtype.d: New test.
* gdc.test/compilable/imports/test21299/rootstringtable.d: New test.
* gdc.test/compilable/test21299a.d: New test.
* gdc.test/compilable/test21299b.d: New test.
* gdc.test/compilable/test21299c.d: New test.
* gdc.test/compilable/test21299d.d: New test.
Sebastian Pop [Tue, 17 Nov 2020 18:56:15 +0000 (18:56 +0000)]
[AArch64] add --with-{cpu,arch,tune}-{32,64} as alias flags for --with-{cpu,arch,tune}
gcc/
* config.gcc: add configure flags --with-{cpu,arch,tune}-{32,64}
as alias flags for --with-{cpu,arch,tune} on AArch64.
* doc/install.texi: Document new flags for aarch64.
Sebastian Pop [Tue, 17 Nov 2020 16:00:51 +0000 (16:00 +0000)]
[AArch64] add --with-tune configure flag
fixes a configure error on Arm64 when passing --with-tune=... to configure:
```
This target does not support --with-tune.
Valid --with options are: abi cpu arch
```
The missing flag sets target tuning to a different value than generic tuning.
gcc/
* config.gcc: Add --with-tune to AArch64 configure flags.
Patrick Palka [Tue, 17 Nov 2020 15:28:20 +0000 (10:28 -0500)]
libstdc++: Fix ranges::search_n for random access iterators [PR97828]
My ranges transcription of the std::search_n implementation for random
access iterators missed a crucial part of the algorithm which the
existing tests didn't exercise. When __remainder is less than __count
at the start of an iteration of the outer while loop, it means we're
continuing a partial match of __count - __remainder elements from the
previous iteration. If at the end of the iteration we don't complete
this partial match, we need to reset __remainder so that it's only
offset by the size of the most recent partial match before starting the
next iteration.
This patch fixes this appropriately, mirroring how it's done in the
corresponding std::search_n implementation.
libstdc++-v3/ChangeLog:
PR libstdc++/97828
* include/bits/ranges_algo.h (__search_n_fn::operator()): Check
random_access_iterator before using the backtracking
implementation. When the backwards scan fails prematurely,
reset __remainder appropriately.
* testsuite/25_algorithms/search_n/97828.cc: New test.
Tamar Christina [Tue, 17 Nov 2020 10:19:20 +0000 (10:19 +0000)]
AArch64: Fix overflow in memcopy expansion on aarch64.
Currently the inline memcpy expansion code for AArch64 is using a signed int
to hold the number of elements to copy. When you giver give it a value larger
than INT_MAX it will overflow.
The overflow causes the maximum number of instructions we want to expand to
check to fail since this assumes an unsigned number.
This patch changes the maximum isns arithmetic to be unsigned. The type can
stay 32-bits since the number of instructions we are allowed to expand to
are at most 8 which is far below what you could fit in an unsigned int.
note that the calculation *must* remained signed as the memcopy issues
overlapping unaligned copies. This means the pointer must be moved back and
so you need signed arithmetic.
gcc/ChangeLog:
PR target/97535
* config/aarch64/aarch64.c (aarch64_expand_cpymem): Use unsigned
arithmetic in check.
gcc/testsuite/ChangeLog:
PR target/97535
* gcc.target/aarch64/pr97535.c: New test.
Monk Chiang [Sat, 14 Nov 2020 03:35:11 +0000 (19:35 -0800)]
PR target/97682 - Fix to reuse t1 register between call address and epilogue.
- When expanding the call pattern, choose t1 register be a jump register.
Epilogue also uses a t1 register to adjust Stack point. The call pattern
and epilogue will initial t1 twice, if both are generated in the same
function. The call pattern will emit 'la t1,symbol' and 'jalr t1'instructions.
Epilogue also emits 'li t1,4096' and 'addi sp,sp,t1' instructions.
But li and addi instructions will be placed between la and jalr instructions.
The la instruction will be removed by some optimizations,
because t1 register define twice, the first define instruction look
likes duplicate.
- To resolve this issue, Prologue and Epilogue use the t0 register
be a temporary register, the call pattern use the t1 register be
a temporary register.
PR target/97682
* config/riscv/riscv.h (RISCV_PROLOGUE_TEMP_REGNUM): Change register
to t0.
(RISCV_CALL_ADDRESS_TEMP_REGNUM): New Marco, define t1 register.
(RISCV_CALL_ADDRESS_TEMP): Use it for call instructions.
* config/riscv/riscv.c (riscv_legitimize_call_address): Use
RISCV_CALL_ADDRESS_TEMP.
(riscv_compute_frame_info): Change temporary register to t0 form t1.
(riscv_trampoline_init): Adjust comment.
Jonathan Wakely [Fri, 13 Nov 2020 19:11:02 +0000 (19:11 +0000)]
libstdc++: Remove redundant overflow check for futex timeout [PR 93456]
The relative_timespec function already checks for the case where the
specified timeout is in the past, so the difference can never be
negative. That means we dn't need to check if it's more negative than
the minimum time_t value.
Jonathan Wakely [Fri, 13 Nov 2020 15:19:04 +0000 (15:19 +0000)]
libstdc++: Avoid 32-bit time_t overflows in futex calls
The existing code doesn't check whether the chrono::seconds value is out
of range of time_t. When using a timeout before the epoch (with a
negative value) subtracting the current time (as time_t) and then
assigning it to a time_t can overflow to a large positive value. This
means that we end up waiting several years even though the specific
timeout was in the distant past.
We do have a check for negative timeouts, but that happens after the
conversion to time_t so happens after the overflow.
libstdc++-v3/ChangeLog:
* src/c++11/futex.cc (relative_timespec): New function to
create relative time from two absolute times.
(__atomic_futex_unsigned_base::_M_futex_wait_until): Use
relative_timespec.
Jonathan Wakely [Thu, 12 Nov 2020 21:25:14 +0000 (21:25 +0000)]
libstdc++: Optimise std::future::wait_for
To poll a std::future to see if it's ready you have to call one of the
timed waiting functions. The most obvious way is wait_for(0s) but this
was previously very inefficient because it would turn the relative
timeout to an absolute one by calling system_clock::now(). When the
relative timeout is zero (or less) we're obviously going to get a time
that has already passed, but the overhead of obtaining the current time
can be dozens of microseconds.
This patch makes future::wait_for avoid waiting at all when the relative
timeout is zero or less, to avoid the unnecessary overhead of getting
the current time. This makes polling with wait_for(0s) take only a few
cycles instead of dozens of milliseconds.
libstdc++-v3/ChangeLog:
* include/std/future (future::wait_for): Do not wait for
durations less than or equal to zero.
* testsuite/30_threads/future/members/poll.cc: New test.
Thomas Schwinge [Tue, 13 Oct 2020 12:56:59 +0000 (14:56 +0200)]
More explicit checking of which OMP constructs we're expecting
In particular, more precisely highlight what applies generally vs. the special
handling for the current 'parloops'-based OpenACC 'kernels' implementation.
gcc/
* omp-low.c (scan_sharing_clauses, scan_omp_for)
(lower_oacc_reductions, lower_omp_target): More explicit checking
of which OMP constructs we're expecting.
The expression used to calculate the maximum value for an integer type
assumes that the number of bits in the value representation is always
sizeof(T) * CHAR_BIT. This is not true for the __int20 type on msp430,
which has only 20 bits in the value representation but 32 bits in the
object representation. This causes an integer overflow in a constant
expression, which is ill-formed.
This problem was already solved by DJ for std::numeric_limits<__int20>
by generalizing the helper macros to use a specified number of bits
instead of assuming sizeof(T) * CHAR_BIT. Then the INT_N_n types can
specify the number of bits using the __GLIBCXX_BITSIZE_INT_N_n macros
that the compiler defines.
I'm using a slightly different approach here. I've replaced the helper
macros entirely, and just expanded the calculations in the initializers
for the static data members. By reordering the data members we can reuse
__is_signed and __digits in the other initializers. This removes the
repetition of expanding __glibcxx_signed(T) and __glibcxx_digits(T)
multiple times in each initializer.
The __is_integer_nonstrict trait now defines a new constant, __width,
which is sizeof(T) * CHAR_BIT by default (defined as an enumerator so
that no storage is needed for a static data member). By specializing
__is_integer_nonstrict for the INT_N types that have padding bits, we
can provide the correct width via the __GLIBCXX_BITSIZE_INT_N_n macros.
libstdc++-v3/ChangeLog:
PR libstdc++/97798
* include/ext/numeric_traits.h (__glibcxx_signed)
(__glibcxx_digits, __glibcxx_min, __glibcxx_max): Remove
macros.
(__is_integer_nonstrict::__width): Define new constant.
(__numeric_traits_integer): Define constants in terms of each
other and __is_integer_nonstrict::__width, rather than the
removed macros.
(_GLIBCXX_INT_N_TRAITS): Macro to define explicit
specializations for non-standard integer types.
Jonathan Wakely [Fri, 13 Nov 2020 13:04:10 +0000 (13:04 +0000)]
libstdc++: Fix test that fails for targets without __int128 [PR 96042]
When backporting this test (and the changes it depends on) I forgot that
the __max_diff_type and __max_size_type classes are only present on
trunk, not the gcc-10 branch. That using iota_view<long long, long long>
oonly works correctly when __int128 is available, so the test fails on
32-bit targets.
This just skips the failing check.
PR libstdc++/96042
* testsuite/std/ranges/iota/96042.cc: Only assert that the
difference type is wider than long long if __int128 is
supported.
Peter Bergner [Fri, 6 Nov 2020 23:00:49 +0000 (17:00 -0600)]
rs6000: Fix default alignment ABI break caused by MMA base support
As part of the MMA base support, we incremented BIGGEST_ALIGNMENT in
order to align the __vector_pair and __vector_quad types to 256 and 512
bytes respectively. This had the unintended effect of changing the
default alignment used by __attribute__ ((__aligned__)) which causes
an ABI break because of some dodgy code in GLIBC's struct pthread.
The fix is to revert the BIGGEST_ALIGNMENT change and to force the
alignment on the type itself rather than the mode used by the type.
2020-11-06 Peter Bergner <bergner@linux.ibm.com>
gcc/
* config/rs6000/rs6000.h (BIGGEST_ALIGNMENT): Revert previous commit
so as not to break the ABI.
* config/rs6000/rs6000-call.c (rs6000_init_builtins): Set the ABI
mandated alignment for __vector_pair and __vector_quad types.
gcc/testsuite/
* gcc.target/powerpc/mma-alignment.c: New test.
Tobias Burnus [Tue, 10 Nov 2020 09:31:33 +0000 (10:31 +0100)]
Fortran: Fix function decl's location [PR95847]
gcc/fortran/ChangeLog:
PR fortran/95847
* trans-decl.c (gfc_get_symbol_decl): Do not (re)set the location
of an external procedure.
(build_entry_thunks, generate_coarray_init, create_main_function,
gfc_generate_function_code): Use fndecl's location in BIND_EXPR.
gcc/testsuite/ChangeLog:
PR fortran/95847
* gfortran.dg/coverage.f90: New test.
Jonathan Wakely [Thu, 20 Aug 2020 18:41:15 +0000 (19:41 +0100)]
libstdc++: Make incrementable<__int128> satisfied in strict mode
This adds specializations of std::incrementable_traits so that 128-bit
integers are always considered incrementable (and therefore usable with
std::ranges::iota_view) even when they don't satisfy std::integral.
libstdc++-v3/ChangeLog:
* include/bits/iterator_concepts.h [__STRICT_ANSI__]
(incrementable_traits<__int128>): Define specialization.
(incrementable_traits<unsigned __int128>): Likewise.
* testsuite/std/ranges/iota/96042.cc: Test iota_view with
__int128.
Jonathan Wakely [Wed, 19 Aug 2020 19:36:10 +0000 (20:36 +0100)]
libstdc++: Make make-unsigned-like-t<__int128> work [PR 96042]
As well as ensuring that numeric_limits<__int128> is defined, we need to
ensure that make-unsigned-like-t and to-unsigned-like work correctly for
128-bit integers in strict mode. This ensures that a subrange created
from an iota_view's iterator and sentinel can represent its size.
Co-authored-by: Patrick Palka <ppalka@redhat.com>
libstdc++-v3/ChangeLog:
2020-08-19 Jonathan Wakely <jwakely@redhat.com>
Patrick Palka <ppalka@redhat.com>
PR libstdc++/96042
* include/bits/range_access.h (__detail::__to_unsigned_like):
Do not use make_unsigned_t<T> in the return type, as it can
result in an error before the integral<T> constraint is checked.
[__STRICT_ANSI__]: Add overloads for 128-bit integer types.
(__detail::__make_unsigned_like_t): Define as the return type
of __to_unsigned_like.
* testsuite/std/ranges/subrange/96042.cc: New test.
Jonathan Wakely [Wed, 19 Aug 2020 15:27:25 +0000 (16:27 +0100)]
libstdc++: Make __int128 meet integer-class requirements [PR 96042]
Because __int128 can be used as the difference type for iota_view, we
need to ensure that it meets the requirements of an integer-class type.
The requirements in [iterator.concept.winc] p10 include numeric_limits
being specialized and giving meaningful answers. Currently we only
specialize numeric_limits for non-standard integer types in non-strict
modes. However, nothing prevents us from defining an explicit
specialization for any implementation-defined type, so it doesn't matter
whether std::is_integral<__int128> is true or not.
This patch ensures that the numeric_limits specializations for signed
and unsigned __int128 are defined whenever __int128 is available. It
also makes the __numeric_traits and __int_limits helpers work for
__int128, via a new __gnu_cxx::__is_integer_nonstrict trait.
libstdc++-v3/ChangeLog:
PR libstdc++/96042
* include/ext/numeric_traits.h (__is_integer_nonstrict): New
trait which is true for 128-bit integers even in strict modes.
(__numeric_traits_integer, __numeric_traits): Use
__is_integer_nonstrict instead of __is_integer.
* include/std/limits [__STRICT_ANSI__ && __SIZEOF_INT128__]
(numeric_limits<__int128>, (numeric_limits<unsigned __int128>):
Define.
* testsuite/std/ranges/iota/96042.cc: New test.
Jakub Jelinek [Thu, 12 Nov 2020 09:46:04 +0000 (10:46 +0100)]
c++: Fix up constexpr CLEANUP_POINT_EXPR and TRY_FINALLY_EXPR handling [PR97790]
As the testcase shows, CLEANUP_POINT_EXPR (and I think TRY_FINALLY_EXPR too)
suffer from the same problem that I was trying to fix in r10-3597-g1006c9d4395a939820df76f37c7b085a4a1a003f
for CLEANUP_STMT, namely that if in the middle of the body expression of
those stmts is e.g. return stmt, goto, break or continue (something that
changes *jump_target and makes it start skipping stmts), we then skip the
cleanups too, which is not appropriate - the cleanups were either queued up
during the non-skipping execution of the body (for CLEANUP_POINT_EXPR), or
for TRY_FINALLY_EXPR are relevant already after entering the body block.
> Would it make sense to always use a NULL jump_target when evaluating
> cleanups?
I was afraid of that, especially for TRY_FINALLY_EXPR, but it seems that
during constexpr evaluation the cleanups will most often be just very simple
destructor calls (or calls to cleanup attribute functions).
Furthermore, for neither of these 3 tree codes we'll reach that code if
jump_target && *jump_target initially (there is a return NULL_TREE much
earlier for those except for trees that could embed labels etc. in it and
clearly these 3 don't count in that).
2020-11-12 Jakub Jelinek <jakub@redhat.com>
PR c++/97790
* constexpr.c (cxx_eval_constant_expression) <case CLEANUP_POINT_EXPR,
case TRY_FINALLY_EXPR, case CLEANUP_STMT>: Don't pass jump_target to
cxx_eval_constant_expression when evaluating the cleanups.
Jakub Jelinek [Tue, 10 Nov 2020 14:56:20 +0000 (15:56 +0100)]
c, c++: Fix up -Wunused-value on COMPLEX_EXPRs [PR97748]
The -Wunused-value warning in both C and C++ FEs (implemented
significantly differently between the two) sees the COMPLEX_EXPRs created
e.g. for complex pre/post increment and many other expressions as useless
and warns about it.
For the C warning implementation, on e.g.
COMPLEX_EXPR < ++REALPART_EXPR <x>, IMAGPART_EXPR <x>>;
would warn even on the IMAGPART_EXPR <x> there alone etc., so what works
is check if we'd warn about both operands of COMPLEX_EXPR and if yes,
warn on the whole COMPLEX_EXPR, otherwise don't warn.
The C++ warning implementation is significantly different and for that one
the only warn if both would be warned about doesn't really work,
we then miss warnings e.g. about
COMPLEX_EXPR <REALPART_EXPR <SAVE_EXPR <x>> + 1.0e+0, IMAGPART_EXPR <SAVE_EXPR <x>>> >>>>>
The patch replaces the warning_at call with call to the c-family
warn_if_unused_value function.
On the testcase which after the initial new tests contains pretty much
everything from gcc.dg/Wunused-value-1.c both approaches seem to work
nicely.
2020-11-10 Jakub Jelinek <jakub@redhat.com>
PR c/97748
gcc/c-family/
* c-common.h (warn_if_unused_value): Add quiet argument defaulted
to false.
* c-warn.c (warn_if_unused_value): Likewise. Pass it down
recursively and just return true instead of warning if it is true.
Handle COMPLEX_EXPR.
gcc/cp/
* cvt.c (convert_to_void): Check (complain & tf_warning) in the outer
if rather than twice times in the inner one. Use warn_if_unused_value.
Formatting fix.
gcc/testsuite/
* c-c++-common/Wunused-value-1.c: New test.
Jakub Jelinek [Fri, 6 Nov 2020 19:33:39 +0000 (20:33 +0100)]
c++: Propagate attributes to clones in duplicate_decls [PR67453]
On the following testcase where the cdtor attributes aren't on the
in-class declaration but on an out-of-class definition, the cdtors
have their clones created from the in-class declaration, and later on
duplicate_decls updates attributes on the abstract cdtors, but nothing
propagates them to the clones.
2020-11-06 Jakub Jelinek <jakub@redhat.com>
PR c++/67453
* decl.c (duplicate_decls): Propagate DECL_ATTRIBUTES and
DECL_PRESERVE_P from olddecl to its clones if any.
Jakub Jelinek [Fri, 6 Nov 2020 08:52:59 +0000 (09:52 +0100)]
c-common: Remove DEBUG_FUNCTION from verify_sequence_points
While perhaps the function name might suggest that it is a verification/debugging
only routine, it is actually implementation of the -Wsequence-point warning
and so doesn't need the DEBUG_FUNCTION macro on it.
Jakub Jelinek [Tue, 3 Nov 2020 20:42:51 +0000 (21:42 +0100)]
c++: Don't try to parse a function declaration as deduction guide [PR97663]
While these function declarations have NULL decl_specifiers->type,
they have still type specifiers specified from which the default int
in the return type is added, so we shouldn't try to parse those as
deduction guides.
2020-11-03 Jakub Jelinek <jakub@redhat.com>
PR c++/97663
* parser.c (cp_parser_init_declarator): Don't try to parse
C++17 deduction guides if there are any type specifiers even when
type is NULL.
Eric Botcazou [Wed, 11 Nov 2020 13:52:45 +0000 (14:52 +0100)]
Fix segfault on elaboration of empty 1-element array at -O
This is a rather obscure case where the elaboration of an empty array
whose base type is an array type of length at most 1 goes awry when
the code is compiled with optimization.
gcc/ada/ChangeLog:
* gcc-interface/trans.c (can_be_lower_p): Remove.
(Regular_Loop_to_gnu): Add ENTRY_COND unconditionally if
BOTTOM_COND is non-zero.
gcc/testsuite/ChangeLog:
* gnat.dg/opt89.adb: New test.
Eric Botcazou [Wed, 11 Nov 2020 12:53:01 +0000 (13:53 +0100)]
Fix internal error with Shift_Right operator on signed type
This is a regression present on the mainline and 10 branch in the form
of an ICE with a shift operator applied to a variable of a signed type,
and which is caused by a type mismatch.
gcc/ada/ChangeLog:
* gcc-interface/trans.c (gnat_to_gnu) <N_Op_Shift>: Also convert
GNU_MAX_SHIFT if the type of the operation has been changed.
* gcc-interface/utils.c (can_materialize_object_renaming_p): Add
pair of missing parentheses.
gcc/testsuite/ChangeLog:
* gnat.dg/shift1.adb: New test.
Paul Scharnofske [Wed, 11 Nov 2020 09:29:37 +0000 (09:29 +0000)]
libstdc++: Assigning to a joinable std::jthread calls std::terminate
Move assigning to a std::jthread that represents a thread of execution
needs to send a stop request and join that running thread. Otherwise the
std::thread data member will terminate in its assignment operator.
Co-authored-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* include/std/thread (jthread::operator=(jthread&&)): Transfer
any existing state to a temporary that will request a stop and
then join.
* testsuite/30_threads/jthread/jthread.cc: Test move assignment.
Jakub Jelinek [Wed, 11 Nov 2020 07:27:38 +0000 (08:27 +0100)]
fortran: Fix up gfc_typename CHARACTER length handling [PR97768]
The first testcase below ICEs when f951 is 32-bit (or 64-bit big-endian).
The problem is that ex->ts.u.cl && ex->ts.u.cl->length are both non-NULL,
but ex->ts.u.cl->length->expr_type is not EXPR_CONSTANT, but EXPR_FUNCTION.
value.function.actual and value.function.name are in that case pointers,
but value._mp_alloc and value._mp_size are 4 byte integers no matter what.
So, in 64-bit little-endian the function returns most of the time incorrect
CHARACTER(0) because the most significant 32 bits of the
value.function.actual pointer are likely 0.
Anyway, the following patch is an attempt to get all the cases right.
Uses ex->value.character.length only for ex->expr_type == EXPR_CONSTANT
(i.e. CHARACTER literals), handles the deferred lengths, assumed lengths,
known constant lengths and finally if the length is something other,
just doesn't print it, i.e. prints just CHARACTER (for default kind)
or CHARACTER(KIND=4) (for e.g. kind 4).
2020-11-11 Jakub Jelinek <jakub@redhat.com>
PR fortran/97768
gcc/fortran/
* misc.c (gfc_typename): Use ex->value.character.length only if
ex->expr_type == EXPR_CONSTANT. If ex->ts.deferred, print : instead
of length. If ex->ts.u.cl && ex->ts.u.cl->length == NULL, print *
instead of length. Otherwise if character length is non-constant,
print just CHARACTER or CHARACTER(KIND=N).
gcc/testsuite/
* gfortran.dg/pr97768_1.f90: New test.
* gfortran.dg/pr97768_2.f90: New test.
Jakub Jelinek [Tue, 10 Nov 2020 10:17:46 +0000 (11:17 +0100)]
sccvn: Fix up push_partial_def little-endian bitfield handling [PR97764]
This patch fixes a thinko in the left-endian push_partial_def path.
As the testcase shows, we have 3 bitfields in the struct,
bitoff bitsize
0 3
3 28
31 1
the corresponding read is the byte at offset 3 (i.e. 24 bits)
and push_partial_def first handles the full store ({}) to all bits
and then is processing the store to the middle bitfield with value of -1.
Here are the interesting spots:
pd.offset -= offseti;
this adjusts the pd to { -21, 28 }, the (for little-endian lowest) 21
bits aren't interesting to us, we only care about the upper 7.
len = native_encode_expr (pd.rhs, this_buffer, bufsize,
MAX (0, -pd.offset) / BITS_PER_UNIT);
native_encode_expr has the offset parameter in bytes and we tell it
that we aren't interested in the first (lowest) two bytes of the number.
It encodes 0xff, 0xff with len == 2 then.
HOST_WIDE_INT size = pd.size;
if (pd.offset < 0)
size -= ROUND_DOWN (-pd.offset, BITS_PER_UNIT);
we get 28 - 16, i.e. 12 - the 16 is subtracting those 2 bytes that we
omitted in native_encode_expr.
size = MIN (size, (HOST_WIDE_INT) needed_len * BITS_PER_UNIT);
needed_len is how many bytes the read at most needs, and that is 1,
so we get size 8 and copy all 8 bits (i.e. a single byte plus nothing)
from the native_encode_expr filled this_buffer; this incorrectly sets
the byte to 0xff when we want 0x7f. The above line is correct for the
pd.offset >= 0 case when we don't skip anything, but for the pd.offset < 0
case we need to subtract also the remainder of the bits we aren't interested
in (the code shifts the bytes by that number of bits).
If it weren't for the big-endian path, we could as well do
if (pd.offset < 0)
size += pd.offset;
but the big-endian path needs it differently.
With the following patch, amnt is 3 and we subtract from 12 the (8 - 3)
bits and thus get the 7 which is the value we want.
2020-11-10 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/97764
* tree-ssa-sccvn.c (vn_walk_cb_data::push_partial_def): For
little-endian stores with negative pd.offset, subtract
BITS_PER_UNIT - amnt from size if amnt is non-zero.
Sudakshina Das [Mon, 2 Nov 2020 15:52:22 +0000 (15:52 +0000)]
[PATCH] aarch64: Fix PR97638
Currently the testcase in the patch was failing to produce
a 'bti c' at the beginning of the function. This was because
in aarch64_pac_insn_p, we were wrongly returning at the first
check!
2020-10-30 Sudakshina Das <sudi.das@arm.com>
gcc/ChangeLog:
PR target/97638
* config/aarch64/aarch64-bti-insert.c (aarch64_pac_insn_p): Update
return value on INSN_P check.
gcc/testsuite/ChangeLog:
PR target/97638
* gcc.target/aarch64/pr97638.c: New test.a
Cui,Lili [Wed, 4 Nov 2020 06:20:31 +0000 (14:20 +0800)]
Enable MOVDIRI, MOVDIR64B, CLDEMOTE and WAITPKG for march=tremont
1. Enable MOVDIRI, MOVDIR64B, CLDEMOTE and WAITPKG for march=tremont
2. Move PREFETCHW from march=broadwell to march=silvermont.
3. Add PREFETCHWT1 to march=knl
gcc/ChangeLog:
2020-11-09 Lili Cui <lili.cui@intel.com>
PR target/97685
* config/i386/i386.h:
(PTA_BROADWELL): Delete PTA_PRFCHW.
(PTA_SILVERMONT): Add PTA_PRFCHW.
(PTA_KNL): Add PTA_PREFETCHWT1.
(PTA_TREMONT): Add PTA_MOVDIRI, PTA_MOVDIR64B, PTA_CLDEMOTE and PTA_WAITPKG.
* doc/invoke.texi: Delete PREFETCHW for broadwell, skylake, knl, knm,
skylake-avx512, cannonlake, icelake-client, icelake-server, cascadelake,
cooperlake, tigerlake and sapphirerapids.
Add PREFETCHW for silvermont, goldmont, goldmont-plus and tremont.
Add XSAVEC and XSAVES for goldmont, goldmont-plus and tremont.
Add MOVDIRI, MOVDIR64B, CLDEMOTE and WAITPKG for tremont.
Add KEYLOCKER and HREST for alderlake.
Add AMX-BF16, AMX-TILE, AMX-INT8 and UINTR for sapphirerapids.
Add KEYLOCKER for tigerlake.
Richard Biener [Wed, 21 Oct 2020 19:28:45 +0000 (14:28 -0500)]
rs6000: MMA type causes an ICE in ranger pass due to incompatible types
PR97360 shows a problem in how we create our PXI and POI modes that cause
an ICE in the ranger pass. The problem seems to be that the extra call
to build_distinct_type_copy() also creates new TYPE_{MIN,MAX}_VALUEs that
are not compatible/the same as the base type itself. The simple "fix" is
to actually remove the unneeded build_distinct_type_copy(), since according
to richi, the types returned from make_unsigned_type() are already distinct.
gcc/
2020-10-21 Richard Biener <rguenther@suse.de>
PR target/97360
* config/rs6000/rs6000-call.c (rs6000_init_builtins): Remove call to
build_distinct_type_copy().
gcc/testsuite/
2020-10-21 Martin Liska <mliska@suse.cz>
PR target/97360
* gcc.target/powerpc/pr97360.c: New test.
Co-authored-by: Andrew MacLeod <amacleod@redhat.com> Co-authored-by: Martin Liska <mliska@suse.cz>
(cherry picked from commit 84cc3370d6d5972fe495b2114fb32f7b4a49a98d)
Tobias Burnus [Fri, 6 Nov 2020 07:26:51 +0000 (08:26 +0100)]
Fortran: Fix type-decl for PDT / wrong-code pdt_14.f03 issue [PR97652]
Parameterized derived types are handled in a special way and start with 'Pdt'.
If the 'P' is not uppercase, gfc_get_derived_type (which calls
gfc_get_module_backend_decl) does not find the existing declaration and
builds a new type. The middle end then sees those types as being different
and nonalising, creating an endless loop for pdt_14.f03.
gcc/fortran/ChangeLog:
PR fortran/97652
* module.c (mio_symbol): Fix symbol name for pdt_type.
projects / thirdparty / gcc.git / log
