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 [Thu, 10 Sep 2020 17:48:25 +0000 (18:48 +0100)]
libstdc++: Fix -Wdeprecated-declarations warnings
libstdc++-v3/ChangeLog:
* include/experimental/bits/shared_ptr.h (shared_ptr(auto_ptr&&))
(operator=(auto_ptr&&)): Add diagnostic pragmas to suppress
warnings for uses of std::auto_ptr.
* include/experimental/type_traits (is_literal_type_v):
Likewise, for use of std::is_literal_type.
* include/std/condition_variable (condition_variable_any::_Unlock):
Likewise, for use of std::uncaught_exception.
We need to record whether template function-scopestatic decls are
constinit. That's currently held on the var's TEMPLATE_INFO data.
But I want to get rid of such decl's template header as they're not
really templates, and they're never instantiated separately from their
containing function's definition. (Just like auto vars, which don't
get them for instance).
This patch moves the flag into a spare decl_lang_flag.
gcc/cp/
* cp-tree.h (TINFO_VAR_DECLARED_CONSTINIT): Replace with ...
(DECL_DECLARED_CONSTINIT_P): ... this.
* decl.c (start_decl): No need to retrofit_lang_decl for constinit
flag.
(cp_finish_decl): Use DECL_DECLARED_CONSTINIT_P.
* pt.c (tsubst_decl): No need to handle constinit flag
propagation.
(tsubst_expr): Or here.
Alex Coplan [Thu, 10 Sep 2020 16:05:40 +0000 (17:05 +0100)]
aarch64: Add support for Armv8-R
This adds support for Armv8-R AArch64 to GCC. It adds the -march value
armv8-r and sets the ACLE feature macro __ARM_ARCH_PROFILE correctly
when -march is set to armv8-r.
gcc/ChangeLog:
* common/config/aarch64/aarch64-common.c
(aarch64_get_extension_string_for_isa_flags): Don't force +crc for
Armv8-R.
* config/aarch64/aarch64-arches.def: Add entry for Armv8-R.
* config/aarch64/aarch64-c.c (aarch64_define_unconditional_macros): Set
__ARM_ARCH_PROFILE correctly for Armv8-R.
* config/aarch64/aarch64.h (AARCH64_FL_V8_R): New.
(AARCH64_FL_FOR_ARCH8_R): New.
(AARCH64_ISA_V8_R): New.
* doc/invoke.texi: Add Armv8-R to architecture table.
Eric Botcazou [Thu, 10 Sep 2020 15:47:32 +0000 (17:47 +0200)]
Fix uninitialized variable with nested variant record types
This fixes a wrong code issue with nested variant record types: the
compiler generates move instructions that depend on an uninitialized
variable, which was initially a SAVE_EXPR not instantiated early enough.
gcc/ada/ChangeLog:
* gcc-interface/decl.c (build_subst_list): For a definition, make
sure to instantiate the SAVE_EXPRs generated by the elaboration of
the constraints in front of the elaboration of the type itself.
gcc/testsuite/ChangeLog:
* gnat.dg/discr59.adb: New test.
* gnat.dg/discr59_pkg1.ads: New helper.
* gnat.dg/discr59_pkg2.ads: Likewise.
Jakub Jelinek [Thu, 10 Sep 2020 15:40:08 +0000 (17:40 +0200)]
arm: Fix up arm_override_options_after_change_1
Looking further at arm_override_options_after_change_1, it also seems to be
incorrect, rather than testing
!opts->x_str_align_functions
it should be really testing
!opts_set->x_str_align_functions
and get &global_options_set or similar passed to it as additional opts_set
argument. That is because otherwise the decision will be sticky, while it
should be done whenever use provided -falign-functions but didn't provide
-falign-functions= (either on the command line, or through optimize
attribute or pragma).
Here is a fix for that (incremental change on top of the previous patch).
2020-09-10 Jakub Jelinek <jakub@redhat.com>
* config/arm/arm.c (arm_override_options_after_change_1): Add opts_set
argument, test opts_set->x_str_align_functions rather than
opts->x_str_align_functions.
(arm_override_options_after_change, arm_option_override_internal,
arm_set_current_function): Adjust callers.
Jakub Jelinek [Thu, 10 Sep 2020 15:39:00 +0000 (17:39 +0200)]
arm: Fix up arm_override_options_after_change [PR96939]
As mentioned in the PR, the testcase fails to link, because when set_cfun is
being called on the crc function, arm_override_options_after_change is
called from set_cfun -> invoke_set_current_function_hook:
/* Change optimization options if needed. */
if (optimization_current_node != opts)
{
optimization_current_node = opts;
cl_optimization_restore (&global_options, TREE_OPTIMIZATION (opts));
}
and at that point target_option_default_node actually matches even the
current state of options, so this means armv7 (or whatever) arch is set as
arm_active_target, then
targetm.set_current_function (fndecl);
is called later in that function, which because the crc function's
DECL_FUNCTION_SPECIFIC_TARGET is different from the current one will do:
cl_target_option_restore (&global_options, TREE_TARGET_OPTION (new_tree));
which calls arm_option_restore and sets arm_active_target to armv8-a+crc
(so far so good).
Later arm_set_current_function calls:
save_restore_target_globals (new_tree);
which in this case calls:
/* Call target_reinit and save the state for TARGET_GLOBALS. */
TREE_TARGET_GLOBALS (new_tree) = save_target_globals_default_opts ();
which because optimization_current_node != optimization_default_node
(the testcase is LTO, so all functions have their
DECL_FUNCTION_SPECIFIC_TARGET and TREE_OPTIMIZATION nodes) will call:
cl_optimization_restore
(&global_options,
TREE_OPTIMIZATION (optimization_default_node));
and
cl_optimization_restore (&global_options,
TREE_OPTIMIZATION (opts));
The problem is that these call arm_override_options_after_change again,
and that one uses the target_option_default_node as what to set the
arm_active_target to (i.e. back to armv7 or whatever, but not to the
armv8-a+crc that should be the active target for the crc function).
That means we then error on the builtin call in that function.
Now, the targetm.override_options_after_change hook is called always at the
end of cl_optimization_restore, i.e. when we change the Optimization marked
generic options. So it seems unnecessary to call arm_configure_build_target
at that point (nothing it depends on changed), and additionally incorrect
(because it uses the target_option_default_node, rather than the current
set of options; we'd need to revert
https://gcc.gnu.org/legacy-ml/gcc-patches/2016-12/msg01390.html
otherwise so that it works again with global_options otherwise).
The options that arm_configure_build_target cares about will change only
during option parsing (which is where it is called already), or during
arm_set_current_function, where it is done during the
cl_target_option_restore.
Now, arm_override_options_after_change_1 wants to adjust the
str_align_functions, which depends on the current Optimization options (e.g.
optimize_size and flag_align_options and str_align_functions) as well as
the target options target_flags, so IMHO needs to be called both
when the Optimization options (possibly) change, i.e. from
the targetm.override_options_after_change hook, and from when the target
options change (set_current_function hook).
2020-09-10 Jakub Jelinek <jakub@redhat.com>
PR target/96939
* config/arm/arm.c (arm_override_options_after_change): Don't call
arm_configure_build_target here.
(arm_set_current_function): Call arm_override_options_after_change_1
at the end.
* gcc.target/arm/lto/pr96939_0.c: New test.
* gcc.target/arm/lto/pr96939_1.c: New file.
Pat Haugen [Thu, 10 Sep 2020 14:46:46 +0000 (09:46 -0500)]
Fix instruction types.
I noticed that some of the VSR<->GPR move instructions are not typed correctly. This patch fixes those instructions so that the scheduler treats them with the correct latency.
Jonathan Wakely [Thu, 10 Sep 2020 14:39:15 +0000 (15:39 +0100)]
libstdc++: handle small max_blocks_per_chunk in pool resources [PR 94160]
When a pool resource is constructed with max_blocks_per_chunk=1 it ends
up creating a pool with blocks_per_chunk=0 which means it never
allocates anything. Instead it returns null pointers, which should be
impossible.
To avoid this problem, round the max_blocks_per_chunk value to a
multiple of four, so it's never smaller than four.
libstdc++-v3/ChangeLog:
PR libstdc++/94160
* src/c++17/memory_resource.cc (munge_options): Round
max_blocks_per_chunk to a multiple of four.
(__pool_resource::_M_alloc_pools()): Simplify slightly.
* testsuite/20_util/unsynchronized_pool_resource/allocate.cc:
Check that valid pointers are returned when small values are
used for max_blocks_per_chunk.
The primary reason for this change is to reduce the size of buffers
allocated by std::pmr::monotonic_buffer_resource. Previously, a new
buffer would always add the size of the linked list node (11 bytes) and
then round up to the next power of two. This results in a huge increase
if the expected size of the next buffer is already a power of two. For
example, if the resource is constructed with a desired initial size of
4096 the first buffer it allocates will be std::bit_ceil(4096+11) which
is 8192. If the user has carefully selected the initial size to match
their expected memory requirements then allocating double that amount
wastes a lot of memory.
After this patch the allocated size will be rounded up to a 64-byte
boundary, instead of to a power of two. This means for an initial size
of 4096 only 4160 bytes get allocated.
Previously only the base-2 logarithm of the size was stored, which could
be stored in a single 8-bit integer. Now that the size isn't always a
power of two we need to use more bits to store it. As the size is always
a multiple of 64 the low six bits are not needed, and so we can use the
same approach that the pool resources already use of storing the base-2
logarithm of the alignment in the low bits that are not used for the
size. To avoid code duplication, a new aligned_size<N> helper class is
introduced by this patch, which is then used by both the pool resources'
big_block type and the monotonic_buffer_resource::_Chunk type.
Originally the big_block type used two bit-fields to store the size and
alignment in the space of a single size_t member. The aligned_size type
uses a single size_t member and uses masks and bitwise operations to
manipulate the size and alignment values. This results in better code
than the old version, because the bit-fields weren't optimally ordered
for little endian architectures, so the alignment was actually stored in
the high bits, not the unused low bits, requiring additional shifts to
calculate the values. Using bitwise operations directly avoids needing
to reorder the bit-fields depending on the endianness.
While adapting the _Chunk and big_block types to use aligned_size<N> I
also added checks for size overflows (technically, unsigned wraparound).
The memory resources now ensure that when they require an allocation
that is too large to represent in size_t they will request SIZE_MAX
bytes from the upstream resource, rather than requesting a small value
that results from wrapround. The testsuite is enhanced to verify this.
libstdc++-v3/ChangeLog:
PR libstdc++/96942
* include/std/memory_resource (monotonic_buffer_resource::do_allocate):
Use __builtin_expect when checking if a new buffer needs to be
allocated from the upstream resource, and for checks for edge
cases like zero sized buffers and allocations.
* src/c++17/memory_resource.cc (aligned_size): New class template.
(aligned_ceil): New helper function to round up to a given
alignment.
(monotonic_buffer_resource::chunk): Replace _M_size and _M_align
with an aligned_size member. Remove _M_canary member. Change _M_next
to pointer instead of unaligned buffer.
(monotonic_buffer_resource::chunk::allocate): Round up to multiple
of 64 instead of to power of two. Check for size overflow. Remove
redundant check for minimum required alignment.
(monotonic_buffer_resource::chunk::release): Adjust for changes
to data members.
(monotonic_buffer_resource::_M_new_buffer): Use aligned_ceil.
(big_block): Replace _M_size and _M_align with aligned_size
member.
(big_block::big_block): Check for size overflow.
(big_block::size, big_block::align): Adjust to use aligned_size.
(big_block::alloc_size): Use aligned_ceil.
(munge_options): Use aligned_ceil.
(__pool_resource::allocate): Use big_block::align for alignment.
* testsuite/20_util/monotonic_buffer_resource/allocate.cc: Check
upstream resource gets expected values for impossible sizes.
* testsuite/20_util/unsynchronized_pool_resource/allocate.cc:
Likewise. Adjust checks for expected alignment in existing test.
Our handling of block-scope extern decls is insufficient for modern
C++, in particular modules, (but also constexprs). We mark such local
function decls, and this patch extends that to marking local var decls
too, so mainly a macro rename. Also, we set this flag earlier, rather
than learning about it when pushing the decl. This is a step towards
handling these properly.
gcc/cp/
* cp-tree.h (DECL_LOCAL_FUNCTION_P): Rename to ...
(DECL_LOCAL_DECL_P): ... here. Accept both fns and vars.
* decl.c (start_decl): Set DECL_LOCAL_DECL_P for local externs.
(omp_declare_variant_finalize_one): Use DECL_LOCAL_DECL_P.
(local_variable_p): Simplify.
* name-lookup.c (set_decl_context_in_fn): Assert DECL_LOCAL_DECL_P
is as expected. Simplify.
(do_pushdecl): Don't set decl_context_in_fn for friends.
(is_local_extern): Simplify.
* call.c (equal_functions): Use DECL_LOCAL_DECL_P.
* parser.c (cp_parser_postfix_expression): Likewise.
(cp_parser_omp_declare_reduction): Likewise.
* pt.c (check_default_tmpl_args): Likewise.
(tsubst_expr): Assert nested reduction function is local.
(type_dependent_expression_p): Use DECL_LOCAL_DECL_P.
* semantics.c (finish_call_expr): Likewise.
libcc1/
* libcp1plugin.cc (plugin_build_call_expr): Use DECL_LOCAL_DECL_P.
Tom de Vries [Thu, 10 Sep 2020 10:44:20 +0000 (12:44 +0200)]
[tree-optimization] Don't clear ctrl-altering flag for IFN_UNIQUE
There's an invariant for IFN_UNIQUE, listed here in
gimple_call_initialize_ctrl_altering:
...
/* IFN_UNIQUE should be the last insn, to make checking for it
as cheap as possible. */
|| (gimple_call_internal_p (stmt)
&& gimple_call_internal_unique_p (stmt)))
gimple_call_set_ctrl_altering (stmt, true);
...
Recent commit fab77644842 "tree-optimization/96931 - clear ctrl-altering flag
more aggressively" breaks this invariant, causing an ICE triggered during
libgomp testing for x86_64 with nvptx accelerator:
...
during RTL pass: mach
asyncwait-1.f90: In function ‘MAIN__._omp_fn.0’:
asyncwait-1.f90:19: internal compiler error: in nvptx_find_par, at \
config/nvptx/nvptx.c:3293
...
Fix this by listing IFN_UNIQUE as exception in
cleanup_call_ctrl_altering_flag.
Build for x86_64 with nvptx accelerator, tested libgomp.
gcc/ChangeLog:
PR tree-optimization/97000
* tree-cfgcleanup.c (cleanup_call_ctrl_altering_flag): Don't clear
flag for IFN_UNIQUE.
Jakub Jelinek [Thu, 10 Sep 2020 09:25:02 +0000 (11:25 +0200)]
lto: Stream current working directory for first streamed relative filename and adjust relative paths [PR93865]
If the gcc -c -flto ... commands to compile some or all objects are run in a
different directory (or in different directories) from the directory in
which the gcc -flto link line is invoked, then the .debug_line will be
incorrect if there are any relative filenames, it will use those relative
filenames while .debug_info will contain a different DW_AT_comp_dir.
The following patch streams (at most once after each clear_line_info)
the current working directory (what we record in DW_AT_comp_dir) when
encountering the first relative pathname, and when reading the location info
reads it back and if the current working directory at that point is
different from the saved one, adjusts relative paths by adding a relative
prefix how to go from the current working directory to the previously saved
path (with a fallback e.g. for DOS e:\\foo vs. d:\\bar change to use
absolute directory).
2020-09-10 Jakub Jelinek <jakub@redhat.com>
PR debug/93865
* lto-streamer.h (struct output_block): Add emit_pwd member.
* lto-streamer-out.c: Include toplev.h.
(clear_line_info): Set emit_pwd.
(lto_output_location_1): Encode the ob->current_file != xloc.file
bit directly into the location number. If changing file, emit
additionally a bit whether pwd is emitted and emit it before the
first relative pathname since clear_line_info.
(output_function, output_constructor): Don't call clear_line_info
here.
* lto-streamer-in.c (struct string_pair_map): New type.
(struct string_pair_map_hasher): New type.
(string_pair_map_hasher::hash): New method.
(string_pair_map_hasher::equal): New method.
(path_name_pair_hash_table, string_pair_map_allocator): New variables.
(relative_path_prefix, canon_relative_path_prefix,
canon_relative_file_name): New functions.
(canon_file_name): Add relative_prefix argument, if non-NULL
and string is a relative path, return canon_relative_file_name.
(lto_location_cache::input_location_and_block): Decode file change
bit from the location number. If changing file, unpack bit whether
pwd is streamed and stream in pwd. Adjust canon_file_name caller.
(lto_free_file_name_hash): Delete path_name_pair_hash_table
and string_pair_map_allocator.
This makes the BB vectorizer cost independent SLP subgraphs
separately. While on pristine trunk and for x86_64 I failed to
distill a testcase where the vectorizer would think _any_
basic-block vectorization opportunity is not profitable I do
have pending work that would make the cost savings of a
profitable opportunity make another independently not
profitable opportunity vectorized.
2020-09-08 Richard Biener <rguenther@suse.de>
PR tree-optimization/96043
* tree-vectorizer.h (_slp_instance::cost_vec): New.
(_slp_instance::subgraph_entries): Likewise.
(BB_VINFO_TARGET_COST_DATA): Remove.
* tree-vect-slp.c (vect_free_slp_instance): Free
cost_vec and subgraph_entries.
(vect_analyze_slp_instance): Initialize them.
(vect_slp_analyze_operations): Defer passing costs to
the target, instead record them in the SLP graph entry.
(get_ultimate_leader): New helper for graph partitioning.
(vect_bb_partition_graph_r): Likewise.
(vect_bb_partition_graph): New function to partition the
SLP graph into independently costable parts.
(vect_bb_vectorization_profitable_p): Adjust to work on
a subgraph.
(vect_bb_vectorization_profitable_p): New wrapper,
discarding non-profitable vectorization of subgraphs.
(vect_slp_analyze_bb_1): Call vect_bb_partition_graph before
costing.
Marek Polacek [Sun, 6 Sep 2020 00:50:32 +0000 (20:50 -0400)]
c++: Further tweaks for new-expression and paren-init [PR77841]
This patch corrects our handling of array new-expression with ()-init:
new int[4](1, 2, 3, 4);
should work even with the explicit array bound, and
new char[3]("so_sad");
should cause an error, but we weren't giving any.
Fixed by handling array new-expressions with ()-init in the same spot
where we deduce the array bound in array new-expression. I'm now
always passing STRING_CSTs to build_new_1 wrapped in { } which allowed
me to remove the special handling of STRING_CSTs in build_new_1. And
since the DIRECT_LIST_INIT_P block in build_new_1 calls digest_init, we
report errors about too short arrays. reshape_init now does the {"foo"}
-> "foo" transformation even for CONSTRUCTOR_IS_PAREN_INIT, so no need
to do it in build_new.
I took a stab at cp_complete_array_type's "FIXME: this code is duplicated
from reshape_init", but calling reshape_init there, I ran into issues
with has_designator_problem: when we reshape an already reshaped
CONSTRUCTOR again, d.cur.index has been filled, so we think that we
have a user-provided designator (though there was no designator in the
source code), and report an error.
gcc/cp/ChangeLog:
PR c++/77841
* decl.c (reshape_init): If we're initializing a char array from
a string-literal that is enclosed in braces, unwrap it.
* init.c (build_new_1): Don't handle string-initializers here.
(build_new): Handle new-expression with paren-init when the
array bound is known. Always pass string constants to build_new_1
enclosed in braces. Don't handle string-initializers in any
special way.
gcc/testsuite/ChangeLog:
PR c++/77841
* g++.old-deja/g++.ext/arrnew2.C: Expect the error only in C++17
and less.
* g++.old-deja/g++.robertl/eb58.C: Adjust dg-error.
* g++.old-deja/g++.robertl/eb63.C: Expect the error only in C++17
and less.
* g++.dg/cpp2a/new-array5.C: New test.
* g++.dg/cpp2a/paren-init36.C: New test.
* g++.dg/cpp2a/paren-init37.C: New test.
* g++.dg/pr84729.C: Adjust dg-error.
Marek Polacek [Fri, 4 Sep 2020 20:04:26 +0000 (16:04 -0400)]
c++: Fix ICE in reshape_init with init-list [PR95164]
This patch fixes a long-standing bug in reshape_init_r. Since r209314
we implement DR 1467 which handles list-initialization with a single
initializer of the same type as the target. In this test this causes
a crash in reshape_init_r when we're processing a constructor that has
undergone the DR 1467 transformation.
Take e.g. the
foo({{1, {H{k}}}});
line in the attached test. {H{k}} initializes the field b of H in I.
H{k} is a functional cast, so has TREE_HAS_CONSTRUCTOR set, so is
COMPOUND_LITERAL_P. We perform the DR 1467 transformation and turn
{H{k}} into H{k}. Then we attempt to reshape H{k} again and since
first_initializer_p is null and it's COMPOUND_LITERAL_P, we go here:
else if (COMPOUND_LITERAL_P (stripped_init))
gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));
then complain about the missing braces, go to reshape_init_class and ICE
on
gcc_checking_assert (d->cur->index
== get_class_binding (type, id));
because due to the missing { } we're looking for 'b' in H, but that's
not found.
So we have to be prepared to handle an initializer whose outer braces
have been removed due to DR 1467.
gcc/cp/ChangeLog:
PR c++/95164
* decl.c (reshape_init_r): When initializing an aggregate member
with an initializer from an initializer-list, also consider
COMPOUND_LITERAL_P.
gcc/testsuite/ChangeLog:
PR c++/95164
* g++.dg/cpp0x/initlist123.C: New test.
David Malcolm [Fri, 28 Aug 2020 17:43:56 +0000 (13:43 -0400)]
analyzer: generalize sm-malloc to new/delete [PR94355]
This patch generalizes the state machine in sm-malloc.c to support
multiple allocator APIs, and adds just enough support for C++ new and
delete to demonstrate the feature, allowing for detection of code
paths where the result of new in C++ can leak - for some crude examples,
at least (bearing in mind that the analyzer doesn't yet know about
e.g. vfuncs, exceptions, inheritance, RTTI, etc)
It also implements a new warning: -Wanalyzer-mismatching-deallocation.
For example:
demo.cc: In function 'void test()':
demo.cc:8:8: warning: 'f' should have been deallocated with 'delete'
but was deallocated with 'free' [CWE-762] [-Wanalyzer-mismatching-deallocation]
8 | free (f);
| ~~~~~^~~
'void test()': events 1-2
|
| 7 | foo *f = new foo;
| | ^~~
| | |
| | (1) allocated here (expects deallocation with 'delete')
| 8 | free (f);
| | ~~~~~~~~
| | |
| | (2) deallocated with 'free' here; allocation at (1) expects deallocation with 'delete'
|
The patch also adds just enough knowledge of exception-handling to
suppress a false positive from -Wanalyzer-malloc-leak on
g++.dg/analyzer/pr96723.C on the exception-handling CFG edge after
operator new. It does this by adding a constraint that the result is
NULL if an exception was thrown from operator new, since the result from
operator new is lost when following that exception-handling CFG edge.
gcc/analyzer/ChangeLog:
PR analyzer/94355
* analyzer.opt (Wanalyzer-mismatching-deallocation): New warning.
* region-model-impl-calls.cc
(region_model::impl_call_operator_new): New.
(region_model::impl_call_operator_delete): New.
* region-model.cc (region_model::on_call_pre): Detect operator new
and operator delete.
(region_model::on_call_post): Likewise.
(region_model::maybe_update_for_edge): Detect EH edges and call...
(region_model::apply_constraints_for_exception): New function.
* region-model.h (region_model::impl_call_operator_new): New decl.
(region_model::impl_call_operator_delete): New decl.
(region_model::apply_constraints_for_exception): New decl.
* sm-malloc.cc (enum resource_state): New.
(struct allocation_state): New state subclass.
(enum wording): New.
(struct api): New.
(malloc_state_machine::custom_data_t): New typedef.
(malloc_state_machine::add_state): New decl.
(malloc_state_machine::m_unchecked)
(malloc_state_machine::m_nonnull)
(malloc_state_machine::m_freed): Delete these states in favor
of...
(malloc_state_machine::m_malloc)
(malloc_state_machine::m_scalar_new)
(malloc_state_machine::m_vector_new): ...this new api instances,
which own their own versions of these states.
(malloc_state_machine::on_allocator_call): New decl.
(malloc_state_machine::on_deallocator_call): New decl.
(api::api): New ctor.
(dyn_cast_allocation_state): New.
(as_a_allocation_state): New.
(get_rs): New.
(unchecked_p): New.
(nonnull_p): New.
(freed_p): New.
(malloc_diagnostic::describe_state_change): Use unchecked_p and
nonnull_p.
(class mismatching_deallocation): New.
(double_free::double_free): Add funcname param for initializing
m_funcname.
(double_free::emit): Use m_funcname in warning message rather
than hardcoding "free".
(double_free::describe_state_change): Likewise. Use freed_p.
(double_free::describe_call_with_state): Use freed_p.
(double_free::describe_final_event): Use m_funcname in message
rather than hardcoding "free".
(double_free::m_funcname): New field.
(possible_null::describe_state_change): Use unchecked_p.
(possible_null::describe_return_of_state): Likewise.
(use_after_free::use_after_free): Add param for initializing m_api.
(use_after_free::emit): Use m_api->m_dealloc_funcname in message
rather than hardcoding "free".
(use_after_free::describe_state_change): Use freed_p. Change the
wording of the message based on the API.
(use_after_free::describe_final_event): Use
m_api->m_dealloc_funcname in message rather than hardcoding
"free". Change the wording of the message based on the API.
(use_after_free::m_api): New field.
(malloc_leak::describe_state_change): Use unchecked_p. Update
for renaming of m_malloc_event to m_alloc_event.
(malloc_leak::describe_final_event): Update for renaming of
m_malloc_event to m_alloc_event.
(malloc_leak::m_malloc_event): Rename...
(malloc_leak::m_alloc_event): ...to this.
(free_of_non_heap::free_of_non_heap): Add param for initializing
m_funcname.
(free_of_non_heap::emit): Use m_funcname in message rather than
hardcoding "free".
(free_of_non_heap::describe_final_event): Likewise.
(free_of_non_heap::m_funcname): New field.
(allocation_state::dump_to_pp): New.
(allocation_state::get_nonnull): New.
(malloc_state_machine::malloc_state_machine): Update for changes
to state fields and new api fields.
(malloc_state_machine::add_state): New.
(malloc_state_machine::on_stmt): Move malloc/calloc handling to
on_allocator_call and call it, passing in the API pointer.
Likewise for free, moving it to on_deallocator_call. Handle calls
to operator new and delete in an analogous way. Use unchecked_p
when testing for possibly-null-arg and possibly-null-deref, and
transition to the non-null for the correct API. Remove redundant
node param from call to on_zero_assignment. Use freed_p for
use-after-free check, and pass in API.
(malloc_state_machine::on_allocator_call): New, based on code in
on_stmt.
(malloc_state_machine::on_deallocator_call): Likewise.
(malloc_state_machine::on_phi): Mark node param with
ATTRIBUTE_UNUSED; don't pass it to on_zero_assignment.
(malloc_state_machine::on_condition): Mark node param with
ATTRIBUTE_UNUSED. Replace on_transition calls with get_state and
set_next_state pairs, transitioning to the non-null state for the
appropriate API.
(malloc_state_machine::can_purge_p): Port to new state approach.
(malloc_state_machine::on_zero_assignment): Replace on_transition
calls with get_state and set_next_state pairs. Drop redundant
node param.
* sm.h (state_machine::add_custom_state): New.
(Note: This patch has already been accepted/committed in binutils/GDB.
This will bring the same change into the GCC tree.)
For DWARF v5 Dwarf Package Files (.dwp files), the section identifier encodings
have changed. This patch updates dwarf2.h to contain the new
encodings. The table below shows the old & new encodings:
[ref http://dwarfstd.org/doc/DWARF5.pdf, section 7.3.5. ]
David Malcolm [Fri, 28 Aug 2020 11:07:18 +0000 (07:07 -0400)]
analyzer: reimplement on_transition in terms of get_state/set_next_state
This patch is further preliminary work towards generalizing sm-malloc.cc
beyond just malloc/free.
Reimplement sm_context's on_transition vfunc in terms of new get_state
and set_next_state vfuncs, so that in followup patches we can implement
richer transitions (e.g. where the states are parametrized by
allocator).
gcc/analyzer/ChangeLog:
* diagnostic-manager.cc
(null_assignment_sm_context::null_assignment_sm_context): Add old_state
and ext_state params, initializing m_old_state and m_ext_state.
(null_assignment_sm_context::on_transition): Split into...
(null_assignment_sm_context::get_state): ...this new vfunc
implementation and...
(null_assignment_sm_context::set_next_state): ...this new vfunc
implementation.
(null_assignment_sm_context::m_old_state): New field.
(null_assignment_sm_context::m_ext_state): New field.
(diagnostic_manager::add_events_for_eedge): Pass in old state and
ext_state when creating sm_ctxt.
* engine.cc (impl_sm_context::on_transition): Split into...
(impl_sm_context::get_state): ...this new vfunc
implementation and...
(impl_sm_context::set_next_state): ...this new vfunc
implementation.
* sm.h (sm_context::get_state): New pure virtual function.
(sm_context::set_next_state): Likewise.
(sm_context::on_transition): Convert from a pure virtual function
to a regular function implemented in terms of get_state and
set_next_state.
David Malcolm [Mon, 24 Aug 2020 19:17:10 +0000 (15:17 -0400)]
analyzer: use objects for state_machine::state_t
This patch is preliminary work towards generalizing sm-malloc.cc so that
it can check APIs other than just malloc/free (and e.g. detect
mismatching alloc/dealloc pairs).
Generalize states in state machines so that, rather than state_t being
just an "unsigned", it becomes a "const state *", where the underlying
state objects are immutable objects managed by the state machine in
question, and can e.g. have vfuncs and extra fields. The start state
m_start becomes a member of the state_machine base_class.
gcc/analyzer/ChangeLog:
* checker-path.cc (state_change_event::get_desc): Update
state_machine::get_state_name calls to state::get_name.
(warning_event::get_desc): Likewise.
* diagnostic-manager.cc
(null_assignment_sm_context::on_transition): Update comparison
against 0 with comparison with m_sm.get_start_state.
(diagnostic_manager::prune_for_sm_diagnostic): Update
state_machine::get_state_name calls to state::get_name.
* engine.cc (impl_sm_context::on_transition): Likewise.
(exploded_node::get_dot_fillcolor): Use get_id when summing
the sm states.
* program-state.cc (sm_state_map::sm_state_map): Don't hardcode
0 as the start state when initializing m_global_state.
(sm_state_map::print): Use dump_to_pp rather than get_state_name
when dumping states.
(sm_state_map::is_empty_p): Don't hardcode 0 as the start state
when examining m_global_state.
(sm_state_map::hash): Use get_id when hashing states.
(selftest::test_sm_state_map): Use state objects rather than
arbitrary hardcoded integers.
(selftest::test_program_state_merging): Likewise.
(selftest::test_program_state_merging_2): Likewise.
* sm-file.cc (fileptr_state_machine::m_start): Move to base class.
(file_diagnostic::describe_state_change): Use get_start_state.
(fileptr_state_machine::fileptr_state_machine): Drop m_start
initialization.
* sm-malloc.cc (malloc_state_machine::m_start): Move to base
class.
(malloc_diagnostic::describe_state_change): Use get_start_state.
(possible_null::describe_state_change): Likewise.
(malloc_state_machine::malloc_state_machine): Drop m_start
initialization.
* sm-pattern-test.cc (pattern_test_state_machine::m_start): Move
to base class.
(pattern_test_state_machine::pattern_test_state_machine): Drop
m_start initialization.
* sm-sensitive.cc (sensitive_state_machine::m_start): Move to base
class.
(sensitive_state_machine::sensitive_state_machine): Drop m_start
initialization.
* sm-signal.cc (signal_state_machine::m_start): Move to base
class.
(signal_state_machine::signal_state_machine): Drop m_start
initialization.
* sm-taint.cc (taint_state_machine::m_start): Move to base class.
(taint_state_machine::taint_state_machine): Drop m_start
initialization.
* sm.cc (state_machine::state::dump_to_pp): New.
(state_machine::state_machine): Move here from sm.h. Initialize
m_next_state_id and m_start.
(state_machine::add_state): Reimplement in terms of state objects.
(state_machine::get_state_name): Delete.
(state_machine::get_state_by_name): Reimplement in terms of state
objects. Make const.
(state_machine::validate): Delete.
(state_machine::dump_to_pp): Reimplement in terms of state
objects.
* sm.h (state_machine::state): New class.
(state_machine::state_t): Convert typedef from "unsigned" to
"const state_machine::state *".
(state_machine::state_machine): Move to sm.cc.
(state_machine::get_default_state): Use m_start rather than
hardcoding 0.
(state_machine::get_state_name): Delete.
(state_machine::get_state_by_name): Make const.
(state_machine::get_start_state): New accessor.
(state_machine::alloc_state_id): New.
(state_machine::m_state_names): Drop in favor of...
(state_machine::m_states): New field
(state_machine::m_start): New field
(start_start_p): Delete.
omp reductions are modeled as nested functions, which is a thing C++
doesn't have. Leading to much confusion until I figured out what was
happening. Not helped by some duplicate code and inconsistencies in
the dependent and non-dependent paths. This patch removes the parser
duplication and fixes up some bookkeeping. Added some asserts and
comments too.
gcc/cp/
* parser.c (cp_parser_omp_declare_reduction): Refactor to avoid
code duplication. Update DECL_TI_TEMPLATE's context.
* pt.c (tsubst_expr): For OMP reduction function, set context to
global_namespace before pushing.
(tsubst_omp_udr): Assert current_function_decl, add comment about
decl context.
Tom de Vries [Wed, 9 Sep 2020 16:43:13 +0000 (18:43 +0200)]
[nvptx, libgcc] Fix Wbuiltin-declaration-mismatch in atomic.c
When building for target nvptx, we get this and similar warnings for libgcc:
...
src/libgcc/config/nvptx/atomic.c:39:1: warning: conflicting types for \
built-in function ‘__sync_val_compare_and_swap_1’; expected \
‘unsigned char(volatile void *, unsigned char, unsigned char)’ \
[-Wbuiltin-declaration-mismatch]
...
Fix this by making sure in atomic.c that the pointers used are of type
'volatile void *'.
bb-reorder: Remove a misfiring micro-optimization (PR96475)
When the compgotos pass copies the tail of blocks ending in an indirect
jump, there is a micro-optimization to not copy the last one, since the
original block will then just be deleted. This does not work properly
if cleanup_cfg does not merge all pairs of blocks we expect it to. It
also does not work if that last block can be merged into multiple
predecessors.
Nick Clifton [Wed, 9 Sep 2020 14:54:20 +0000 (15:54 +0100)]
If the lto plugin encounters a file with multiple symbol sections, each of which also has a v1 symbol extension section[1] then it will attempt to read the extension data for *every* symbol from each of the extension sections. This results in reading off the end of a buffer with the associated memory corruption that that entails. This patch fixes that problem.
2020-09-09 Nick Clifton <nickc@redhat.com>
* lto-plugin.c (struct plugin_symtab): Add last_sym field.
(parse_symtab_extension): Only read as many entries as are
available in the buffer. Store the data read into the symbol
table indexed from last_sym. Increment last_sym.
Tom de Vries [Wed, 9 Sep 2020 13:37:58 +0000 (15:37 +0200)]
[nvptx] Fix Wformat in nvptx_assemble_decl_begin
I'm running into this warning:
...
src/gcc/config/nvptx/nvptx.c: In function \
‘void nvptx_assemble_decl_begin(FILE*, const char*, const char*, \
const_tree, long int, unsigned int, bool)’:
src/gcc/config/nvptx/nvptx.c:2229:29: warning: format ‘%d’ expects argument \
of type ‘int’, but argument 5 has type ‘long unsigned int’ [-Wformat=]
elt_size * BITS_PER_UNIT);
^
...
which I seem to have introduced in commit b9c7fe59f9f "[nvptx] Fix array
dimension in nvptx_assemble_decl_begin", but not noticed due to configuring
with --disable-build-format-warnings.
Patrick Palka [Wed, 9 Sep 2020 13:21:09 +0000 (09:21 -0400)]
c++: Fix resolving the address of overloaded pmf [PR96647]
In resolve_address_of_overloaded_function, currently only the second
pass over the overload set (which considers just the function templates
in the overload set) checks constraints and performs return type
deduction when necessary. But as the testcases below show, we need to
do the same when considering non-template functions during the first
pass.
gcc/cp/ChangeLog:
PR c++/96647
* class.c (resolve_address_of_overloaded_function): Check
constraints_satisfied_p and perform return-type deduction via
maybe_instantiate_decl when considering non-template functions
in the overload set.
* cp-tree.h (maybe_instantiate_decl): Declare.
* decl2.c (maybe_instantiate_decl): Remove static.
gcc/testsuite/ChangeLog:
PR c++/96647
* g++.dg/cpp0x/auto-96647.C: New test.
* g++.dg/cpp0x/error9.C: New test.
* g++.dg/cpp2a/concepts-fn6.C: New test.
Tom de Vries [Wed, 9 Sep 2020 07:51:43 +0000 (09:51 +0200)]
[nvptx] Fix boolean type test in write_fn_proto
When running this libgomp testcase for nvptx accelerator:
...
/* { dg-do run } */
__uint128_t v;
int main () {
#pragma omp target
{
__uint128_t exp = 2;
__atomic_compare_exchange_n (&v, &exp, 7, false, __ATOMIC_RELEASE,
__ATOMIC_ACQUIRE);
}
}
...
we run into this assert in write_fn_proto:
...
913 gcc_assert (type == boolean_type_node);
...
This happens when doing some special-handling code for
__atomic_compare_exchange_1/2/4/8/16. The function decls have a parameter
called weak of type bool, which is skipped when writing the decl because
the corresponding libatomic functions do not have that parameter. The assert
is there to verify that we skip the correct parameter.
However, we assert because we have different type of bools:
...
(gdb) call debug_generic_expr (type)
_Bool
(gdb) call debug_generic_expr (global_trees[TI_BOOLEAN_TYPE])
bool
...
Fix this by checking for TREE_CODE (type) == BOOLEAN_TYPE instead.
Tested libgomp on x86_64-linux with nvptx accelerator.
Likewise, tested that the test-case above does not ICE anymore.
gcc/ChangeLog:
PR target/96991
* config/nvptx/nvptx.c (write_fn_proto): Fix boolean type check.
Richard Biener [Wed, 9 Sep 2020 10:05:55 +0000 (12:05 +0200)]
enable live comparison vectorization
This removes a check preventing vectorization of live results of
vectorized comparisons. I tested it with AVX512 mask registers
(inspecting assembly) and traditional vector masks.
The following patch improves handling of largefile support with procfs
on 32-bit Solaris. It has already been approved and installed for
binutils-gdb in the thread starting at
[PATCH] Unify Solaris procfs and largefile handling
https://sourceware.org/pipermail/gdb-patches/2020-June/169977.html
I'm syncing the config/largefile.m4 part to gcc now which is the master
for config. Since ACX_LARGEFILE isn't used anywhere in the gcc tree,
I'm installing it as obvious.
Richard Biener [Wed, 9 Sep 2020 07:45:29 +0000 (09:45 +0200)]
tree-optimization/96978 - fix fallout of BB vectorization of live stmts
This avoids looking at STMT_VINFO_LIVE_P when vectorizing BBs.
2020-09-09 Richard Biener <rguenther@suse.de>
PR tree-optimization/96978
* tree-vect-stmts.c (vectorizable_condition): Do not
look at STMT_VINFO_LIVE_P for BB vectorization.
(vectorizable_comparison): Likewise.
Fortran: Fixes for OpenMP loop-iter privatization (PRs 95109 + 94690)
This commit also fixes a gfortran.dg/gomp/target1.f90 regression;
target1.f90 tests the resolve.c and openmp.c changes.
gcc/fortran/ChangeLog:
PR fortran/95109
PR fortran/94690
* resolve.c (gfc_resolve_code): Also call
gfc_resolve_omp_parallel_blocks for 'distribute parallel do (simd)'.
* openmp.c (gfc_resolve_omp_parallel_blocks): Handle it.
(gfc_resolve_do_iterator): Remove special code for SIMD, which is
not needed.
* trans-openmp.c (gfc_trans_omp_target): For TARGET_PARALLEL_DO_SIMD,
call simd not do processing function.
gcc/testsuite/ChangeLog:
PR fortran/95109
PR fortran/94690
* gfortran.dg/gomp/combined-if.f90: Update scan-tree-dump-times for
'omp simd.*if'.
* gfortran.dg/gomp/openmp-simd-5.f90: New test.
Searching for a range match can cause the search order to not match
the sort order, which can cause libbacktrace to miss matching entries.
Allocate an extra entry at the end of function_addrs and unit_addrs vectors,
so that we can safely compare to the next entry when searching.
Adjust the matching code accordingly.
* dwarf.c (function_addrs_search): Compare against the next entry
low address, not the high address.
(unit_addrs_search): Likewise.
(build_address_map): Add a trailing unit_addrs.
(read_function_entry): Add a trailing function_addrs.
(read_function_info): Likewise.
(report_inlined_functions): Search backward for function_addrs
match.
(dwarf_lookup_pc): Search backward for unit_addrs and
function_addrs matches.
The test case was written with assumptions about loop iteration ordering
that are not guaranteed by OpenACC and do not apply on all targets,
in particular AMD GCN. This patch removes those assumptions.
Julian Brown [Mon, 10 Feb 2020 20:26:57 +0000 (12:26 -0800)]
amdgcn: Add waitcnt after LDS write instructions
Data-share write (ds_write) instructions do not necessarily complete
the write to LDS immediately. When a write completes, LGKM_CNT is
decremented. For now, we wait until LGKM_CNT reaches zero after each
ds_write instruction.
This fixes a race condition in the case where LDS is read immediately
after being written. This can happen with broadcast operations.
Julian Brown [Fri, 26 Jun 2020 16:07:58 +0000 (09:07 -0700)]
openacc: Fix mkoffload SGPR/VGPR count parsing for HSACO v3
If an offload kernel uses a large number of VGPRs, AMD GCN hardware may
need to limit the number of threads/workers launched for that kernel.
The number of SGPRs/VGPRs in use is detected by mkoffload and recorded in
the processed output. The patterns emitted detailing SGPR/VGPR occupancy
changed between HSACO v2 and v3 though, so this patch updates parsing
to account for that.
2020-09-08 Julian Brown <julian@codesourcery.com>
gcc/
* config/gcn/mkoffload.c (process_asm): Initialise regcount. Update
scanning for SGPR/VGPR usage for HSACO v3.
Julian Brown [Thu, 25 Jun 2020 14:40:53 +0000 (07:40 -0700)]
openacc: Fix race condition in Fortran loop collapse tests
The gangs participating in a gang-partitioned loop are not all guaranteed
to complete before some given gang continues to execute beyond that loop.
This means that two existing test cases contain a race condition,
because a loop that may be gang-partitioned is followed immediately by
another loop. The fix is to place the loops in separate parallel regions.
Felix Willgerodt [Mon, 17 Aug 2020 11:36:49 +0000 (13:36 +0200)]
floatformat.h: Add bfloat16 support.
This change is motivated by a patchset that adds bfloat16 debugging
support for new avx512 instructions to GDB. The gdb thread can be found
here: https://sourceware.org/pipermail/gdb-patches/2020-July/170820.html
include:
2020-08-17 Felix Willgerodt <felix.willgerodt@intel.com>
David Malcolm [Mon, 7 Sep 2020 22:31:28 +0000 (18:31 -0400)]
analyzer: fix another ICE in constructor-handling [PR96949]
PR analyzer/96949 reports an ICE with
--param analyzer-max-svalue-depth=0, where the param value leads
to INTEGER_CST values in a RANGE_EXPR being treated as unknown
symbolic values.
This patch replaces implicit assumptions that these values are
concrete (and thus have concrete bit offsets), adding
error-handling for symbolic cases instead of assertions.
gcc/analyzer/ChangeLog:
PR analyzer/96949
* store.cc (binding_map::apply_ctor_val_to_range): Add
error-handling for the cases where we have symbolic offsets.
gcc/testsuite/ChangeLog:
PR analyzer/96949
* gfortran.dg/analyzer/pr96949.f90: New test.
David Malcolm [Mon, 7 Sep 2020 21:43:02 +0000 (17:43 -0400)]
analyzer: fix ICE on RANGE_EXPR with CONSTRUCTOR value [PR96950]
gcc/analyzer/ChangeLog:
PR analyzer/96950
* store.cc (binding_map::apply_ctor_to_region): Handle RANGE_EXPR
where min_index == max_index.
(binding_map::apply_ctor_val_to_range): Replace assertion that we
don't have a CONSTRUCTOR value with error-handling.
David Malcolm [Mon, 7 Sep 2020 21:16:37 +0000 (17:16 -0400)]
analyzer: fix ICE on machine-specific builtins [PR96962]
In g:ee7bfbe5eb70a23bbf3a2cedfdcbd2ea1a20c3f2 I added a
switch (DECL_UNCHECKED_FUNCTION_CODE (callee_fndecl))
to region_model::on_call_pre guarded by
fndecl_built_in_p (callee_fndecl).
I meant to handle only normal built-ins, whereas this
single-argument overload of fndecl_built_in_p returns true for any
kind of built-in.
PR analyzer/96962 reports a case where this matches for a
machine-specific builtin, leading to an ICE. Fixed thusly.
gcc/analyzer/ChangeLog:
PR analyzer/96962
* region-model.cc (region_model::on_call_pre): Fix guard on switch
on built-ins to only consider BUILT_IN_NORMAL, rather than other
kinds of build-ins.
MSP430: Fix detection of assembler support for .mspabi_attribute
The assembly code ".mspabi_attribute 4,1" uses the object attribute
mechanism to indicate that the 430 ISA is in use. However, the default
ISA is 430X, so GAS fails to assemble this since the ISA wasn't also set
to 430 on the command line.
gcc/ChangeLog:
* config/msp430/msp430.c (msp430_file_end): Fix jumbled
HAVE_AS_MSPABI_ATTRIBUTE and HAVE_AS_GNU_ATTRIBUTE checks.
* configure: Regenerate.
* configure.ac: Use ".mspabi_attribute 4,2" to check for assembler
support for this object attribute directive.
libphobos: libdruntime doesn't support shadow stack (PR95680)
Rather than implementing support within D runtime itself, use libc
getcontext/swapcontext functions if CET is enabled.
Removes whatever CET support was in the switchContext routine for x86
D runtime, along with setting version AsmExternal, so that the fallback
ucontext_t implementation is used, which is capable of doing shadow
stack handling.
libphobos/ChangeLog:
PR d/95680
* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac (DCFG_ENABLE_CET): Substitute.
* libdruntime/Makefile.in: Regenerate.
* libdruntime/config/x86/switchcontext.S: Remove CET support code.
* libdruntime/core/thread.d: Import gcc.config. Don't set version
AsmExternal when GNU_Enable_CET is true.
* libdruntime/gcc/config.d.in (GNU_Enable_CET): Define.
* src/Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.
The -mcpu= option accepts only a handful of string values.
Using enums instead of strings to handle the accepted values removes the
need to have specific processing of the strings in the backend, and
simplifies any comparisons which need to be performed on the value.
It also allows the default value to have semantic equivalence to a user
set value, whilst retaining the ability to differentiate between them.
Practically, this allows a user set -mcpu= value to override the the ISA set by
-mmcu, whilst the default -mcpu= value can still have an explicit meaning.
gcc/ChangeLog:
* common/config/msp430/msp430-common.c (msp430_handle_option): Remove
OPT_mcpu_ handling.
Set target_cpu value to new enum values when parsing certain -mmcu=
values.
* config/msp430/msp430-opts.h (enum msp430_cpu_types): New.
* config/msp430/msp430.c (msp430_option_override): Handle new
target_cpu enum values.
Set target_cpu using extracted value for given MCU when -mcpu=
option is not passed by the user.
* config/msp430/msp430.opt: Handle -mcpu= values using enums.
gcc/testsuite/ChangeLog:
* gcc.target/msp430/mcpu-is-430.c: New test.
* gcc.target/msp430/mcpu-is-430x.c: New test.
* gcc.target/msp430/mcpu-is-430xv2.c: New test.
Alan Modra [Wed, 2 Sep 2020 02:53:47 +0000 (12:23 +0930)]
ubsan: d-demangle.c:214 signed integer overflow
Running the libiberty testsuite
./test-demangle < libiberty/testsuite/d-demangle-expected
libiberty/d-demangle.c:214:14: runtime error: signed integer overflow: 922337203 * 10 cannot be represented in type 'long int'
On looking at silencing ubsan, I found a real bug in dlang_number.
For a 32-bit long, some overflows won't be detected. For example, 21474836480. Why? Well 214748364 * 10 is 0x7FFFFFF8 (no overflow so
far). Adding 8 gives 0x80000000 (which does overflow but there is no
test for that overflow in the code). Then multiplying 0x80000000 * 10
= 0x500000000 = 0 won't be caught by the multiplication overflow test.
The same holds for a 64-bit long using similarly crafted digit
sequences.
* d-demangle.c: Include limits.h.
(ULONG_MAX, UINT_MAX): Provide fall-back definition.
(dlang_number): Simplify and correct overflow test. Only
write *ret on returning non-NULL. Make "ret" an unsigned long*.
Only succeed for result of [0,UINT_MAX].
(dlang_decode_backref): Simplify and correct overflow test.
Only write *ret on returning non-NULL. Only succeed for
result [1,MAX_LONG].
(dlang_backref): Remove now unnecessary range check.
(dlang_symbol_name_p): Likewise.
(string_need): Take a size_t n arg, and use size_t tem.
(string_append): Use size_t n.
(string_appendn, string_prependn): Take a size_t n arg.
(TEMPLATE_LENGTH_UNKNOWN): Define as -1UL.
(dlang_lname, dlang_parse_template): Take an unsigned long len
arg.
(dlang_symbol_backref, dlang_identifier, dlang_parse_integer),
(dlang_parse_integer, dlang_parse_string),
(dlang_parse_arrayliteral, dlang_parse_assocarray),
(dlang_parse_structlit, dlang_parse_tuple),
(dlang_template_symbol_param, dlang_template_args): Use
unsigned long variables.
* testsuite/d-demangle-expected: Add new tests.
Harald Anlauf [Mon, 7 Sep 2020 19:41:45 +0000 (21:41 +0200)]
PR fortran/96711 - ICE with NINT() for integer(16) result
When rounding a real to the nearest integer, temporarily convert the real
argument to a longer real kind when the result is of type/kind integer(16).
gcc/fortran/ChangeLog:
* trans-intrinsic.c (build_round_expr): Use temporary with
appropriate kind for conversion before rounding to nearest
integer when the result precision is 128 bits.
lra: Avoid cycling on certain subreg reloads [PR96796]
This PR is about LRA cycling for a reload of the form:
----------------------------------------------------------------------------
Changing pseudo 196 in operand 1 of insn 103 on equiv [r105:DI*0x8+r140:DI]
Creating newreg=287, assigning class ALL_REGS to slow/invalid mem r287
Creating newreg=288, assigning class ALL_REGS to slow/invalid mem r288
103: r203:SI=r288:SI<<0x1+r196:DI#0
REG_DEAD r196:DI
Inserting slow/invalid mem reload before:
316: r287:DI=[r105:DI*0x8+r140:DI]
317: r288:SI=r287:DI#0
----------------------------------------------------------------------------
The problem is with r287. We rightly give it a broad starting class of
POINTER_AND_FP_REGS (reduced from ALL_REGS by preferred_reload_class).
However, we never make forward progress towards narrowing it down to
a specific choice of class (POINTER_REGS or FP_REGS).
I think in practice we rely on two things to narrow a reload pseudo's
class down to a specific choice:
(1) a restricted class is specified when the pseudo is created
This happens for input address reloads, where the class is taken
from the target's chosen base register class. It also happens
for simple REG reloads, where the class is taken from the chosen
alternative's constraints.
(2) uses of the reload pseudo as a direct input operand
In this case get_reload_reg tries to reuse the existing register
and narrow its class, instead of creating a new reload pseudo.
However, neither occurs here. As described above, r287 rightly
starts out with a wide choice of class, ultimately derived from
ALL_REGS, so we don't get (1). And as the comments in the PR
explain, r287 is never used as an input reload, only the subreg is,
so we don't get (2):
----------------------------------------------------------------------------
Choosing alt 13 in insn 317: (0) r (1) w {*movsi_aarch64}
Creating newreg=291, assigning class FP_REGS to r291
317: r288:SI=r291:SI
Inserting insn reload before:
320: r291:SI=r287:DI#0
----------------------------------------------------------------------------
IMO, in this case we should rely on the reload of r316 to narrow
down the class of r278. Currently we do:
----------------------------------------------------------------------------
Choosing alt 7 in insn 316: (0) r (1) m {*movdi_aarch64}
Creating newreg=289 from oldreg=287, assigning class GENERAL_REGS to r289
316: r289:DI=[r105:DI*0x8+r140:DI]
Inserting insn reload after:
318: r287:DI=r289:DI
---------------------------------------------------
i.e. we create a new pseudo register r289 and give *that* pseudo
GENERAL_REGS instead. This is because get_reload_reg only narrows
down the existing class for OP_IN and OP_INOUT, not OP_OUT.
But if we have a reload pseudo in a reload instruction and have chosen
a specific class for the reload pseudo, I think we should simply install
it for OP_OUT reloads too, if the class is a subset of the existing class.
We will need to pick such a register whatever happens (for r289 in the
example above). And as explained in the PR, doing this actually avoids
an unnecessary move via the FP registers too.
The patch is quite aggressive in that it does this for all reload
pseudos in all reload instructions. I wondered about reusing the
condition for a reload move in in_class_p:
but I can't really justify that on first principles. I think we
should apply the rule consistently until we have a specific reason
for doing otherwise.
gcc/
PR rtl-optimization/96796
* lra-constraints.c (in_class_p): Add a default-false
allow_all_reload_class_changes_p parameter. Do not treat
reload moves specially when the parameter is true.
(get_reload_reg): Try to narrow the class of an existing OP_OUT
reload if we're reloading a reload pseudo in a reload instruction.
gcc/testsuite/
PR rtl-optimization/96796
* gcc.c-torture/compile/pr96796.c: New test.
doc: Update documentation on MODE_PARTIAL_INT subregs
In d8487c949ad5, MODE_PARTIAL_INT modes were changed from having an
unknown number of undefined bits, to having a known number of undefined
bits, however the documentation on using SUBREG expressions with
MODE_PARTIAL_INT modes was not updated to reflect this.
gcc/ChangeLog:
* doc/rtl.texi (subreg): Fix documentation to state there is a known
number of undefined bits in regs and subregs of MODE_PARTIAL_INT modes.
Alex Coplan [Mon, 7 Sep 2020 14:23:44 +0000 (15:23 +0100)]
aarch64: Remove redundant mult patterns
Following on from the previous commit to fix up the syntax for
add/sub/adds/subs and friends with a sign/zero-extended operand, this
patch removes the "mult" variants of these patterns which are all
redundant.
This patch removes the following patterns from the AArch64 backend:
but this add instruction uses architecturally-invalid syntax: the width
of the third operand conflicts with the width of the extension
specifier. The third operand is only permitted to be an x register when
the extension specifier is (u|s)xtx.
This instruction, and analogous insns for adds, sub, subs, and cmp, are
rejected by clang, but accepted by binutils. Assembling and
disassembling such an insn with binutils gives the architecturally-valid
version in the disassembly:
This patch fixes several patterns in the AArch64 backend to use the
standard syntax as specified in the Arm ARM such that GCC's output can
be assembled by assemblers other than GAS.
Richard Biener [Mon, 7 Sep 2020 12:26:46 +0000 (14:26 +0200)]
improve SLP vect dumping
This adds additional dumping helping in particular basic-block
vectorization SLP dump reading plus showing what we actually
generate code from.
2020-09-07 Richard Biener <rguenther@suse.de>
* tree-vect-slp.c (vect_analyze_slp_instance): Dump
stmts we start SLP analysis from, failure and splitting.
(vect_schedule_slp): Dump SLP graph entry and root stmt
we are about to emit code for.
Martin Storsjö [Mon, 7 Sep 2020 11:18:42 +0000 (13:18 +0200)]
gcc: Make strchr return value pointers const
This fixes compilation of codepaths for dos-like filesystems
with Clang. When built with clang, it treats C input files as C++
when the compiler driver is invoked in C++ mode, triggering errors
when the return value of strchr() on a pointer to const is assigned
to a pointer to non-const variable.
This matches similar variables outside of the ifdefs for dos-like
path handling.
2020-09-07 Martin Storsjö <martin@martin.st>
gcc/
* dwarf2out.c (file_name_acquire): Make a strchr return value
pointer to const.
libcpp/
* files.c (remap_filename): Make a strchr return value pointer
to const.
git://gcc.gnu.org / gcc.git / log