David Malcolm [Thu, 27 Feb 2020 19:19:33 +0000 (14:19 -0500)]
analyzer: detect malloc, free, calloc within "std" [PR93959]
PR analyzer/93959 reported that g++.dg/analyzer/malloc.C was failing
with no output on Solaris.
The issue is that <stdlib.h> there has "using std::free;", converting
all the "free" calls to std::free, which fails the name-matching via
is_named_call_p.
This patch implements an is_std_named_call_p variant of is_named_call_p
to check for the name within "std", and uses it in sm-malloc.c to check
for std::malloc, std::calloc, and std::free.
gcc/analyzer/ChangeLog:
PR analyzer/93959
* analyzer.cc (is_std_function_p): New function.
(is_std_named_call_p): New functions.
* analyzer.h (is_std_named_call_p): New decl.
* sm-malloc.cc (malloc_state_machine::on_stmt): Check for "std::"
variants when checking for malloc, calloc and free.
gcc/testsuite/ChangeLog:
PR analyzer/93959
* g++.dg/analyzer/cstdlib-2.C: New test.
* g++.dg/analyzer/cstdlib.C: New test.
Iain Sandoe [Mon, 2 Mar 2020 20:29:32 +0000 (20:29 +0000)]
coroutines: Update lambda capture handling to n4849.
In the absence of specific comment on the handling of closures I'd
implemented something more than was intended (extending the lifetime
of lambda capture-by-copy vars to the duration of the coro).
After discussion at WG21 in February and by email, the correct handling
is to treat the closure "this" pointer the same way as for a regular one,
and thus it is the user's responsibility to ensure that the lambda capture
object has suitable lifetime for the coroutine. It is noted that users
frequently get this wrong, so it would be a good thing to revisit for C++23.
This patch removes the additional copying behaviour for lambda capture-by-
copy vars.
gcc/cp/ChangeLog:
2020-03-02 Iain Sandoe <iain@sandoe.co.uk>
* coroutines.cc (struct local_var_info): Adjust to remove the
reference to the captured var, and just to note that this is a
lambda capture proxy.
(transform_local_var_uses): Handle lambda captures specially.
(struct param_frame_data): Add a visited set.
(register_param_uses): Also check for param uses in lambda
capture proxies.
(struct local_vars_frame_data): Remove captures list.
(register_local_var_uses): Handle lambda capture proxies by
noting and bypassing them.
(morph_fn_to_coro): Update to remove lifetime extension of
lambda capture-by-copy vars.
gcc/testsuite/ChangeLog:
2020-03-02 Iain Sandoe <iain@sandoe.co.uk>
Jun Ma <JunMa@linux.alibaba.com>
* g++.dg/coroutines/torture/class-05-lambda-capture-copy-local.C:
* g++.dg/coroutines/torture/lambda-09-init-captures.C: New test.
* g++.dg/coroutines/torture/lambda-10-mutable.C: New test.
Uros Bizjak [Mon, 2 Mar 2020 20:13:36 +0000 (21:13 +0100)]
i386: Allow only registers with VALID_INT_MODE_P modes in movstrict<mode> [PR93997]
*movstrict<mode>_1 insn pattern allows only general registers,
so we have to reject modes not suitable for general regs in
corresponding movstrict<mode> expander.
PR target/93997
* config/i386/i386.md (movstrict<mode>): Allow only
registers with VALID_INT_MODE_P modes.
testsuite/ChangeLog:
PR target/93997
* gcc.target/i386/pr93997.c: New test.
Andrew Benson [Mon, 2 Mar 2020 17:28:35 +0000 (17:28 +0000)]
Ensure sufficient size of variables used for module+submodule names.
PR fortran/93486
* module.c: Increase size of variables used to read module names
when loading interfaces from module files to permit cases where
the name is the concatenation of a module and submodule name.
* gfortran.dg/pr93486.f90: New test.
Jonathan Wakely [Mon, 2 Mar 2020 17:03:28 +0000 (17:03 +0000)]
libstdc++: Fix std::lexicographic_compare for unsigned char (PR 93972)
The new 25_algorithms/lexicographical_compare/93972.cc test fails on
targets where char is unsigned, revealing an existing regression with
the std::__memcmp helper that had gone unnoticed in
std::lexicographical_compare. When comparing char and unsigned char, the
memcmp optimisation is enabled, but the new std::__memcmp function fails
to compile for mismatched types.
PR libstdc++/93972
* include/bits/stl_algobase.h (__memcmp): Allow pointer types to
differ.
* testsuite/25_algorithms/lexicographical_compare/uchar.cc: New test.
Jonathan Wakely [Mon, 2 Mar 2020 17:03:28 +0000 (17:03 +0000)]
libstdc++: Rename __detail::__maybe_empty_t alias template
The key property of this alias is not that it may be an empty type, but
that the type argument may not be used. The fact it's replaced by an
empty type is just an implementation detail. The name was also
backwards with respect to the bool argument.
This patch changes the name to better reflect its purpose.
* include/std/ranges (__detail::__maybe_empty_t): Rename to
__maybe_present_t.
(__adaptor::_RangeAdaptor, join_view, split_view): Use new name.
Iain Sandoe [Mon, 2 Mar 2020 15:35:45 +0000 (15:35 +0000)]
coroutines: Don't make duplicate frame copies of awaitables.
In general, we need to manage the lifetime of compiler-
generated awaitable instances in the coroutine frame, since
these must persist across suspension points.
However, it is quite possible that the user might provide the
awaitable instances, either as function params or as a local
variable. We will already generate a frame entry for these as
required.
At present, under this circumstance, we are duplicating these,
awaitable, initialising a second frame copy for them (which we
then subsequently destroy manually after the suspension point).
That's not efficient - so an undesirable thinko in the first place.
However, there is also an actual bug; if the compiler elects to
elide the copy (which is perfectly legal), it does not have visibility
of the manual management of the post-suspend destruction
- this subsequently leads to double-free errors.
The solution is not to make the second copy (as noted, params
and local vars already have frame copies with managed lifetimes).
gcc/cp/ChangeLog:
2020-03-02 Iain Sandoe <iain@sandoe.co.uk>
* coroutines.cc (build_co_await): Do not build frame
proxy vars when the co_await expression is a function
parameter or local var.
(co_await_expander): Do not initialise a frame var with
itself.
(transform_await_expr): Only substitute the awaitable
frame var if it's needed.
(register_awaits): Do not make frame copies for param
or local vars that are awaitables.
gcc/testsuite/ChangeLog:
2020-03-02 Iain Sandoe <iain@sandoe.co.uk>
* g++.dg/coroutines/torture/func-params-09-awaitable-parms.C: New test.
* g++.dg/coroutines/torture/local-var-5-awaitable.C: New test.
Andrew Stubbs [Fri, 7 Feb 2020 11:14:43 +0000 (11:14 +0000)]
amdgcn: Extend reductions to all types
Add support for V64DFmode addition, and V64DImode min, max. There's no
direct hardware support for these, so we use regular vector instructions
and separate lane shift instructions.
Also add support for V64QI and V64HI reductions. Some of these require
additional extends and truncates, because AMD GCN has 32-bit vector lanes.
2020-03-02 Andrew Stubbs <ams@codesourcery.com>
gcc/
* config/gcn/gcn-valu.md (dpp_move<mode>): New.
(reduc_insn): Use 'U' and 'B' operand codes.
(reduc_<reduc_op>_scal_<mode>): Allow all types.
(reduc_<reduc_op>_scal_v64di): Delete.
(*<reduc_op>_dpp_shr_<mode>): Allow all 1reg types.
(*plus_carry_dpp_shr_v64si): Change to ...
(*plus_carry_dpp_shr_<mode>): ... this and allow all 1reg int types.
(mov_from_lane63_v64di): Change to ...
(mov_from_lane63_<mode>): ... this, and allow all 64-bit modes.
* config/gcn/gcn.c (gcn_expand_dpp_shr_insn): Increase buffer size.
Support UNSPEC_MOV_DPP_SHR output formats.
(gcn_expand_reduc_scalar): Add "use_moves" reductions.
Add "use_extends" reductions.
(print_operand_address): Add 'I' and 'U' codes.
* config/gcn/gcn.md (unspec): Add UNSPEC_MOV_DPP_SHR.
Kewen Lin [Mon, 2 Mar 2020 09:36:30 +0000 (03:36 -0600)]
[testsuites] Update several scev/IVOPTs cases
Several scev/IVOPTs cases aim to check some array references are sceved and
later marked as REFERENCE ADDRESS IV groups. With IV group type dumping
improving, these check strings can be improved. Otherwise, they become fragile
with dumping changes.
This patch is to keep check strings concise, meanwhile recover the coverage of
case scev-8.c.
Iain Sandoe [Sun, 1 Mar 2020 14:40:57 +0000 (14:40 +0000)]
Darwin, libsanitizer: Adjust minimum supported Darwin version (PR93731).
The current imported libsanitizer code produces kernel panics for
Darwin 11 (macOS 10.7) and is unsupported for earlier versions already.
It is not clear if the current sources are even intended to be supported
on Darwin 11, so this patch causes the default to be build without
sanitizers for Darwin <= 11.
2020-03-01 Iain Sandoe <iain@sandoe.co.uk>
PR sanitizer/93731
* configure.tgt (x86_64-*-darwin*, i?86-*-darwin*): Enable by
default only for Darwin versions greater than 12 (macOS 10.8).
François Dumont [Thu, 27 Feb 2020 18:08:40 +0000 (19:08 +0100)]
libstdc++ Hastable: Move std::is_permutation to limit includes
Move std::is_permutation algorithm with associated helpers to stl_algobase.h
to remove stl_algo.h include from hashtable_policy.h and so reduce preprocess
size of unordered_map and unordered_set headers.
The rule change in the title matches GCC's current behavior, so no change
was needed. But the paper also makes 'typename' optional in a
requirement-parameter-list, so this implements that.
gcc/cp/ChangeLog
2020-02-28 Jason Merrill <jason@redhat.com>
Patrick Palka [Fri, 28 Feb 2020 19:16:06 +0000 (14:16 -0500)]
libstdc++: Fix bogus use of memcmp in ranges::lexicographical_compare (PR 93972)
We were enabling the memcmp optimization in ranges::lexicographical_compare for
signed integral types and for integral types wider than a byte. But memcmp
gives the wrong answer for arrays of such types. This patch fixes this issue by
refining the condition that enables the memcmp optimization. It's now
consistent with the corresponding condition used in
std::lexicographical_compare.
libstdc++-v3/ChangeLog:
PR libstdc++/93972
* include/bits/ranges_algo.h (__lexicographical_compare_fn::operator()):
Fix condition for when to use memcmp, making it consistent with the
corresponding condition used in std::lexicographical_compare.
* testsuite/25_algorithms/lexicographical_compare/93972.cc: New test.
Iain Sandoe [Fri, 28 Feb 2020 13:51:43 +0000 (13:51 +0000)]
coroutines: Update func-params-08.C to suspend three times.
The awaitable initially committed was returning "always ready"
which meant that the suspension code was not used. Update
the test to suspend at each co_await, since this exercises more
of the infrastructure.
gcc/testsuite/ChangeLog:
2020-02-28 Iain Sandoe <iain@sandoe.co.uk>
* g++.dg/coroutines/torture/func-params-08.C: Update
to suspend for each co_await operation.
Patrick Palka [Fri, 28 Feb 2020 17:43:14 +0000 (12:43 -0500)]
libstdc++: Update the <numeric> synopsis test to latest standard
Tested with
make check RUNTESTFLAGS="conformance.exp=*numeric*synopsis* --target_board=unix/-std=$std"
for std in {c++98, c++11, c++17, c++2a}.
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/headers/numeric/synopsis.cc: Add signatures for
functions introduced in C++11, C++17 and C++2a. Add 'constexpr' to
existing signatures for C++2a.
Patrick Palka [Fri, 28 Feb 2020 15:47:26 +0000 (10:47 -0500)]
libstdc++: Also disable caching of reverse_view::begin() for common_ranges
When the underlying range models common_range, then reverse_view::begin() is
already O(1) without caching. So we should disable the cache in this case too.
libstdc++-v3/ChangeLog:
* include/std/ranges (reverse_view::_S_needs_cached_begin): Set to false
whenever the underlying range models common_range.
Jakub Jelinek [Fri, 28 Feb 2020 16:35:32 +0000 (17:35 +0100)]
c++: Further tweak for P1937R2 - const{expr,eval} inconsistencies
Seems I've missed one thing, as the first hunk in
https://github.com/cplusplus/draft/commit/c8e68ed202b4a9260616bcee8a9768b5dca4bbca
changes the wording so that only potentially-evaluated id-expressions that
denote immediate functions must appear only in the specified contexts.
That IMO means that in unevaluated contexts there aren't such restrictions
anymore, so I think in unevaluated contexts one should be able to take the
address of an immediate function.
2020-02-28 Jakub Jelinek <jakub@redhat.com>
P1937R2 - Fixing inconsistencies between const{expr,eval} functions
* typeck.c (cp_build_addr_expr_1): Allow taking address of immediate
functions in unevaluated contexts.
* g++.dg/cpp2a/consteval3.C: Change dg-error about taking address of
immediate function in unevaluated contexts into dg-bogus.
* g++.dg/cpp2a/consteval16.C: New test.
Joel Hutton [Fri, 28 Feb 2020 14:46:26 +0000 (14:46 +0000)]
Fix misleading aarch64 mcpu/march warning string
The message for conflicting mcpu and march previously printed the
architecture of the CPU instead of the CPU name, as well as omitting the
extensions to the march string. This patch corrects both errors. This
patch fixes PR target/87612.
This patch adds memoization to these four views so that their begin() has the
required amortized constant time complexity.
The cache is enabled only for forward_ranges and above because we need the
underlying iterator to be copyable and multi-pass in order for the cache to be
usable. In the general case we represent the cached result of begin() as a bare
iterator. This takes advantage of the fact that value-initialized forward
iterators can be compared to as per N3644, so we can use a value-initialized
iterator to denote the "empty" state of the cache.
As a special case, when the underlying range models random_access_range and when
it's profitable size-wise, then we cache the offset of the iterator from the
beginning of the range instead of caching the iterator itself.
Additionally, in drop_view and reverse_view we disable the cache when the
underlying range models random_access_range, because in these cases recomputing
begin() takes O(1) time anyway.
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::_CachedPosition): New struct.
(views::filter_view::_S_needs_cached_begin): New member variable.
(views::filter_view::_M_cached_begin): New member variable.
(views::filter_view::begin): Use _M_cached_begin to cache its
result.
(views::drop_view::_S_needs_cached_begin): New static member variable.
(views::drop_view::_M_cached_begin): New member variable.
(views::drop_view::begin): Use _M_cached_begin to cache its result
when _S_needs_cached_begin.
(views::drop_while_view::_M_cached_begin): New member variable.
(views::drop_while_view::begin): Use _M_cached_begin to cache its
result.
(views::reverse_view::_S_needs_cached_begin): New static member
variable.
(views::reverse_view::_M_cached_begin): New member variable.
(views::reverse_view::begin): Use _M_cached_begin to cache its result
when _S_needs_cached_begin.
* testsuite/std/ranges/adaptors/drop.cc: Augment test to check that
drop_view::begin caches its result.
* testsuite/std/ranges/adaptors/drop_while.cc: Augment test to check
that drop_while_view::begin caches its result.
* testsuite/std/ranges/adaptors/filter.cc: Augment test to check that
filter_view::begin caches its result.
* testsuite/std/ranges/adaptors/reverse.cc: Augment test to check that
reverse_view::begin caches its result.
Jonathan Wakely [Thu, 27 Feb 2020 16:38:00 +0000 (16:38 +0000)]
libstdc++: Fix FS-dependent filesystem tests
These tests were failing on XFS because it doesn't support setting file
timestamps past 2038, so the expected overflow when reading back a huge
timestamp into a file_time_type didn't happen.
Additionally, the std::filesystem::file_time_type::clock has an
epoch that is out of range of 32-bit time_t so testing times around that
epoch may also fail.
This fixes the tests to give up gracefully if the filesystem doesn't
support times that can't be represented in 32-bit time_t.
* testsuite/27_io/filesystem/operations/last_write_time.cc: Fixes for
filesystems that silently truncate timestamps.
* testsuite/experimental/filesystem/operations/last_write_time.cc:
Likewise.
Jakub Jelinek [Fri, 28 Feb 2020 08:44:53 +0000 (09:44 +0100)]
testsuite: Fix up g++.dg/torture/pr92152.C test for ilp32 targets
2020-02-28 Jakub Jelinek <jakub@redhat.com>
PR middle-end/92152
* g++.dg/torture/pr92152.C (size_t): Use decltype (sizeof (0)) instead
of hardcoding unsigned long.
(uint64_t): Use unsigned long long instead of unsigned long.
Michael Meissner [Thu, 27 Feb 2020 19:41:39 +0000 (14:41 -0500)]
Fix PR target/93932
[gcc]
2020-02-27 Michael Meissner <meissner@linux.ibm.com>
PR target/93932
* config/rs6000/vsx.md (vsx_extract_<mode>_var, VSX_D iterator):
Split the insn into two parts. This insn only does variable
extract from a register.
(vsx_extract_<mode>_var_load, VSX_D iterator): New insn, do
variable extract from memory.
(vsx_extract_v4sf_var): Split the insn into two parts. This insn
only does variable extract from a register.
(vsx_extract_v4sf_var_load): New insn, do variable extract from
memory.
(vsx_extract_<mode>_var, VSX_EXTRACT_I iterator): Split the insn
into two parts. This insn only does variable extract from a
register.
(vsx_extract_<mode>_var_load, VSX_EXTRACT_I iterator): New insn,
do variable extract from memory.
[gcc/testsuite]
2020-02-27 Michael Meissner <meissner@linux.ibm.com>
Nathan Sidwell [Thu, 27 Feb 2020 18:50:36 +0000 (10:50 -0800)]
Compare ARGUMENT_PACKS [pr93933]
This implements Jason's suggested approach: 'I'd think that the bug is
that we're treating them as types in the first place; they aren't
types, so they shouldn't reach comptypes. I'd lean toward adding an
assert to that effect and fixing the caller to use
e.g. template_args_equal.'
PR c++/93933
* pt.c (template_args_equal): Pass ARGUMENT_PACKS through to
cp_tree_equal.
* tree.c (cp_tree_equal): Compare ARGUMENT_PACKS here,
* typeck.c (comptypes): Assert we don't get any argument packs.
Patrick Palka [Wed, 26 Feb 2020 17:31:01 +0000 (12:31 -0500)]
libstdc++: Add missing friend declarations in some range adaptors
Some of the range adaptors have distinct constant and non-constant
iterator/sentinel types, along with converting constructors that can convert a
non-constant iterator/sentinel to a constant iterator/sentinel. This patch adds
the missing appropriate friend declarations in order to make these converting
constructors well formed.
Strictly speaking it seems the friendship relations don't need to go both ways
-- we could get away with declaring e.g. friend _Iterator<false>; instead of
friend _Iterator<!_Const>; but both reference implementations seem to use the
latter symmetric form anyway.
Martin Jambor [Thu, 27 Feb 2020 17:43:05 +0000 (18:43 +0100)]
ipa-cp: Avoid an ICE processing self-recursive cloned edges (PR 93707)
2020-02-27 Martin Jambor <mjambor@suse.cz>
Feng Xue <fxue@os.amperecomputing.com>
PR ipa/93707
* ipa-cp.c (same_node_or_its_all_contexts_clone_p): Replaced with
new function calls_same_node_or_its_all_contexts_clone_p.
(cgraph_edge_brings_value_p): Use it.
(cgraph_edge_brings_value_p): Likewise.
(self_recursive_pass_through_p): Return false if caller is a clone.
(self_recursive_agg_pass_through_p): Likewise.
Jan Hubicka [Thu, 27 Feb 2020 17:36:39 +0000 (18:36 +0100)]
middle-end: Fix wrong code caused by disagreemed between FRE and access path oracle [PR 92152]
FRE is checking stores for equivalence based on their address, value and
base+ref alias sets. Because ref alias set is not always the alias set of
innermost type, but it may be one of refs in the access path (as decided by
component_uses_parent_alias_set_from) it means that we can not really rely on
the remaining part of access path to be meaningful in any way except for
offset+size computation.
The patch makes alias (which is used by FRE to validate transform) and
tree-ssa-alias to share same logic for ending the access path relevant for
TBAA. tree-ssa-alias previously ended access paths on VIEW_CONVERT_EXPR and
BIT_FIELD_REF so it is not hard to wire in common predicate. However it led to
additional issues (I tried to read the code quite carefully for possible extra
fun, so I hope I found it all):
1) alias_component_refs_walk compares base and reference sizes to see
if one access path may continue by another. This check can be confused
by an union containing structure with zero sized array. In this case we
no longer see the refernece to zero sized array and think that ref size
is 0.
In an access path there can be at most one (valid) trailing/zero sized
array access, so the sizes in the access path are decreasing with the
this exception. This is already handled by the logic, however the access
is not expected to happen past the end of TBAA segment. I suppose this
was kind of latent problem before because one can think of access path
doing traling array past VIEW_CONVERT_EXPR, but since in C code we don't
VCE and in non-C we don't do trailing arrays, we did not hit the problem.
I fixed this by tracking if the trailing array references appearing after
the end of TBAA access path and mostly punt in the second case (because we
need to support kind of all type puning here). I do not think we can assume
much of sanity here, in particular, we no longer know there is only one
because FRE may mix things up.
An exception is the walk that looks for occurence of basetype of path1
within TBAA relevant part of path2. Here we realy care about TBAA
relevant parts of paths and thus do not need to give up.
I broke out the logic into ends_tbaa_access_path_p to avoid duplication and
to let me stick some detailed comments. This became much more complex
than I originally imagined (still it is useful to make oracle both faster
and more precise).
Note that logic in aliasing_component_refs_walk is safe since it works
on TBAA relevant segments of paths only.
2) nonoverlapping_refs_since_match_p is using TBAA only in the corner case
that the paths got out of sync and re-synchronize of types of same size
are found. I thus extended it to whole paths (not only TBAA relevant
parts) and track if the TBAA part can be used by counting of number of
TBAA relevant res on the stack.
I have noticed that in one case we call nonoverlapping_refs_since_match_p
before checking for view converting MEM_REFs and in others we check
after. I think we want to just disable TBAA part if view convert
is in there but still disambiguate. I will do this incrementaly.
3) nonoverlapping_component_refs_p uses TBAA so it needs to punt on
end of TBAA path. It deals with no sizes and thus there is not the issue
as in 1).
I am also attaching one (most probably) valid C++ testcase (by Mark Williams)
where we incorrectly disambiguated while the code is valid by the common
initial sequence rule. This happens to be fixed by same patch. Here one access
goes through union and follows by access path trhough one filed, while other
access path start by different field of the union with common initial sequence.
This made aliasing_component_refs_p to not find the overlapping type (because
there is none) and disambiguate. Now we cut the first access path by the union
reference and this makes us to find the path continuation in
alias_component_refs_walk.
If FRE is ever made more careful about access paths past the fist union
reference (I think that would be good idea since unions are quite common in C++
and we throw away quite useful info) then we will need to teach access path
oracle about the common initial sequence rule (which, as Mark pointed out, is
part of both C and C++ standards).
Only argument that can possibly invalidate this testcase is that I do not see
that stadnard is clear about the situation where one access path contains the
union but other starts after the union.
Clearly if both start after the union reference we are right to disambiguate
(since there is no union unvolved). If both starts before union then there is
common initial sequence and by standard it is defined. This case works on current
trunk because aliasing_component_refs_p resorts to base+offset after finding
the match. But even that is more or less an accident I would say.
I had to xfail three testcases. While alias-access-path ones are artificial
and odd, 20030807-7 is derived from gcc and shows that we give up on
disambiguations of tree_node union, so this patch disables useful transform
in real world code.
I am still planning to collect some data on the effect of this change to TBAA,
but unless we want to reorganize FRE, I do not think there is better solution.
gcc/ChangeLog:
2020-02-26 Jan Hubicka <hubicka@ucw.cz>
PR middle-end/92152
* alias.c (ends_tbaa_access_path_p): Break out from ...
(component_uses_parent_alias_set_from): ... here.
* alias.h (ends_tbaa_access_path_p): Declare.
* tree-ssa-alias.c (access_path_may_continue_p): Break out from ...;
handle trailing arrays past end of tbaa access path.
(aliasing_component_refs_p): ... here; likewise.
(nonoverlapping_refs_since_match_p): Track TBAA segment of the access
path; disambiguate also past end of it.
(nonoverlapping_component_refs_p): Use only TBAA segment of the access
path.
gcc/testsuite/ChangeLog:
2020-02-26 Jan Hubicka <hubicka@ucw.cz>
PR middle-end/92152
* gcc.dg/tree-ssa/alias-access-path-12.c: New testcase.
* g++.dg/torture/pr92152.C: New testcase.
* gcc.dg/torture/pr92152.c: New testcase.
* gcc.dg/tree-ssa/20030807-7.c: xfail.
* gcc.dg/tree-ssa/alias-access-path-4.c: xfail one case.
* gcc.dg/tree-ssa/alias-access-path-5.c: xfail one case.
Mihail Ionescu [Thu, 27 Feb 2020 16:00:48 +0000 (16:00 +0000)]
[GCC][PATCH][ARM] Add vreinterpret, vdup, vget and vset bfloat16 intrinsics
This patch adds support for the bf16 vector create, get, set,
duplicate and reinterpret intrinsics.
ACLE documents are at https://developer.arm.com/docs/101028/latest
ISA documents are at https://developer.arm.com/docs/ddi0596/latest
gcc/ChangeLog:
2020-02-27 Mihail Ionescu <mihail.ionescu@arm.com>
Alexandre Oliva [Thu, 27 Feb 2020 16:34:47 +0000 (13:34 -0300)]
define NO_DOT_IN_LABEL only in vxworks6
There was a mistake in forward-porting and contributing some
vxworks7r2 changes, that caused a conditional to be dropped around a
couple of preprocessor directives, needed only up to vxworks6, that
change the compiler's behavior WRT introducing dollars and dots in
symbol names.
This deviates GCC's behavior from the native system compiler, in a way
that appears to have ABI implications, so we'd like to correct that,
even at this late stage in the development cycle.
for gcc/ChangeLog
* config/vx-common.h (NO_DOLLAR_IN_LABEL, NO_DOT_IN_LABEL): Leave
them alone on vx7.
Nathan Sidwell [Thu, 27 Feb 2020 14:34:23 +0000 (06:34 -0800)]
Fix broken type comparison assert
In implementing Jason's suggested direction for 93933, the compiler
exploded in a surprising way. Turns out an assert had been passing
NULLS to comptypes, and therefore not checking what it intended.
Further comptypes, could silently accept such nulls under most
circumstances.
Richard Biener [Thu, 27 Feb 2020 12:46:34 +0000 (13:46 +0100)]
tree-optimization/93508 - make VN translate through _chk and valueize length
Value-numbering failed to handle __builtin_{memcpy,memset,...}_chk
variants when removing abstraction and also failed to use the
value-numbering lattice when requiring the length argument of the
call to be constant.
2020-02-27 Richard Biener <rguenther@suse.de>
PR tree-optimization/93508
* tree-ssa-sccvn.c (vn_reference_lookup_3): Handle _CHK like
non-_CHK variants. Valueize their length arguments.
Andrew Stubbs [Wed, 26 Feb 2020 16:45:29 +0000 (16:45 +0000)]
amdgcn: fix ICE on subreg of BI reg.
BImode usually only requires one bit, but instructions that write to VCC also
clobber the reset of the DImode register pair, so gcn_class_max_nregs reports
that two registers are needed for BImode. Paradoxically, accessing VCC via
SImode is therefore uses fewer registers than accessing via BImode.
The LRA checking code takes this into account, but the DF liveness data also
looks at the subreg, so it says (subreg:SI (reg:BI VCC) 0) only makes the low
part live. Both are "correct", but they disagree, which causes an ICE.
This doesn't happen when writing conditions to VCC; it happens when accessing
VCC_LO via a regular move to a regular SImode register.
If we transform the subregs so that BImode is always the outer mode then it
basically means the same thing, except that now both LRA and DF calculate nregs
the same, and ICE goes away.
As soon as LRA is done the subregs all evaporate anyway.
2020-02-27 Andrew Stubbs <ams@codesourcery.com>
gcc/
* config/gcn/gcn.md (mov<mode>): Add transformations for BI subregs.
Jonathan Wakely [Thu, 27 Feb 2020 10:52:28 +0000 (10:52 +0000)]
libstdc++: Make _GLIBCXX_CONCEPT_CHECKS more constexpr-friendly
Although most of the old-style "concept checks" are only really usable
with C++98 because they enforce the wrong things, this is a simple
change that makes them a bit more useful for C++14 and up.
* include/bits/boost_concept_check.h (__function_requires): Add
_GLIBCXX14_CONSTEXPR.
* testsuite/25_algorithms/min/concept_checks.cc: New test.
Richard Biener [Thu, 27 Feb 2020 10:42:50 +0000 (11:42 +0100)]
fix -fdebug-prefix-map without gas .file support
This applies file mapping when emitting the directory table
directly instead of using the assemblers .file directive where
we already correctly apply the map. Notably the non-assembler
path is used for the early debug emission for LTO.
2020-02-27 Mark Williams <mwilliams@fb.com>
* dwarf2out.c (file_name_acquire): Call remap_debug_filename.
* lto-opts.c (lto_write_options): Drop -fdebug-prefix-map,
-ffile-prefix-map and -fmacro-prefix-map.
* lto-streamer-out.c: Include file-prefix-map.h.
(lto_output_location): Remap the file part of locations.
Jakub Jelinek [Thu, 27 Feb 2020 09:45:30 +0000 (10:45 +0100)]
gimplify: Don't optimize register const vars to static [PR93949]
The following testcase is rejected, while it was accepted in 3.4 and earlier
(before tree-ssa merge).
The problem is that we decide to promote the const variable to TREE_STATIC,
but TREE_STATIC DECL_REGISTER VAR_DECLs may only be the global register vars
and so assemble_variable/make_decl_rtl diagnoses it.
Either we do what the following patch does, where we could consider
register as a hint the user doesn't want such optimization, because if
something is forced static, it is not "register" anymore and register static
is not valid in C either, or we could clear DECL_REGISTER instead, but would
still need to punt at least on DECL_HARD_REGISTER cases.
Jakub Jelinek [Thu, 27 Feb 2020 09:12:52 +0000 (10:12 +0100)]
sccvn: Handle non-byte aligned offset or size for memset (, 123, ) [PR93945]
The following is the last spot in vn_reference_lookup_3 that didn't allow
non-byte aligned offsets or sizes. To be precise, it did allow size that
wasn't multiple of byte size and that caused a wrong-code issue on
big-endian, as the pr93945.c testcase shows, so for GCC 9 we should add
&& multiple_p (ref->size, BITS_PER_UNIT) check instead.
For the memset with SSA_NAME middle-argument, it still requires byte-aligned
offset, as we'd otherwise need to rotate the value at runtime.
2020-02-27 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/93582
PR tree-optimization/93945
* tree-ssa-sccvn.c (vn_reference_lookup_3): Handle memset with
non-zero INTEGER_CST second argument and ref->offset or ref->size
not a multiple of BITS_PER_UNIT.
* gcc.dg/tree-ssa/pr93582-9.c: New test.
* gcc.c-torture/execute/pr93945.c: New test.
Jakub Jelinek [Thu, 27 Feb 2020 08:38:12 +0000 (09:38 +0100)]
maintainer-scripts: Speed up git clone in gcc_release
When doing the 8.4-rc1, I've noticed (probably also because of the dying
disk on sourceware) that git clone is extremely slow, and furthermore when
all of us have some local snapshots, it is a waste of resources to download
everything again. Especially for the -f runs when we'll need to wait until
git tag -s asks us for a gpg password interactively.
The following patch adds an option through which one can point the script
at a local gcc .git directory from which it can --dissociate --reference ...
during cloning to speed it up.
2020-02-27 Jakub Jelinek <jakub@redhat.com>
* gcc_release: Add support for -b local-git-repo argument.
gcc/
* doc/invoke.texi (Option Summary): Re-alphabetize warnings in
C++ Language Options, Warning Options, and Static Analyzer
Options lists. Document negative form of options enabled by
default. Move some things around to more accurately sort
warnings by category.
(C++ Dialect Options, Warning Options, Static Analyzer
Options): Document negative form of options when enabled by
default. Move some things around to more accurately sort
warnings by category. Add some missing index entries.
Light copy-editing.
projects / thirdparty / gcc.git / log
