In struct _dep, there is an implicit padding of 4bits. This
bit-field padding is uninitialized when init_dep_1 is being called.
This means we access uninitialized memory but never use it for
anything. Adding an unused bit-field field and initializing it
in init_dep_1 will improve code generation also as we initialize
the whole 32bits now rather than just part of it.
ChangeLog:
* sched-int.h (_dep): Add unused bit-field field for the padding.
* sched-deps.c (init_dep_1): Init unused field.
Commit g:f96bf49a0 added the target field to expand_operand.
But it leaves it uninitialized when doing a full initialization
inside create_expand_operand. This fixes the problem and improves
the code generation inside create_expand_operand too.
ChangeLog:
* optabs.h (create_expand_operand): Initialize target field also.
The monotonically increasing revision ids need to be globally unique, so they should
only identify commits that were committed to the upstream repo to its master or
releases/gcc-N branches. The alias could print something even for private branches
or vendor branches etc., but if such an identifier is then used publicly, it will
refer to something else.
2020-01-16 Jakub Jelinek <jakub@redhat.com>
* gcc-git-customization.sh: Verify the id to be printed is ancestor of
the corresponding remote release branch (or master), otherwise print
nothing.
This patch addresses the problem reported in PR92429. When creating an
epilogue for vectorization we have to replace the SSA_NAMEs in the
PATTERN_DEF_SEQs and RELATED_STMTs of the epilogue's loop_vec_infos. When doing
this we were using simplify_replace_tree which always folds the replacement.
This may lead to a different tree-node than the one which was analyzed in
vect_loop_analyze. In turn the new tree-node may require a different
vectorization than the one we had prepared for which caused the ICE in
question.
gcc/ChangeLog:
2020-01-16 Andre Vieira <andre.simoesdiasvieira@arm.com>
PR tree-optimization/92429
* tree-ssa-loop-niter.h (simplify_replace_tree): Add parameter.
* tree-ssa-loop-niter.c (simplify_replace_tree): Add parameter to
control folding.
* tree-vect-loop.c (update_epilogue_vinfo): Do not fold when replacing
tree.
gcc/testsuite/ChangeLog:
2020-01-16 Andre Vieira <andre.simoesdiasvieira@arm.com>
PR tree-optimization/92429
* gcc.dg/vect/pr92429.c: New test.
This suppresses an array out of bounds warning in mkdeps.c as proposed
by Martin Sebor in the bugzilla.
array subscript 2 is outside array bounds of ‘const char [2]’
Since this warning does occur during bootstrap it currently breaks
werror builds on IBM Z.
The problem can be reproduced also on x86_64 by changing the inlining
threshold using: --param max-inline-insns-auto=80
Bootstrapped and regression tested on x86_64 and IBM Z.
libcpp/ChangeLog:
2020-01-16 Andreas Krebbel <krebbel@linux.ibm.com>
PR tree-optimization/92176
* mkdeps.c (deps_add_default_target): Avoid calling apply_vpath to
suppress an array out of bounds warning.
The patterns used by aarch64_split_sve_subreg_move only support
integer modes, so if the widest mode is a float, we should get
its integer equivalent.
Fixes gcc.target/aarch64/sel_3.c for big-endian targets.
2020-01-16 Richard Sandiford <richard.sandiford@arm.com>
gcc/
* config/aarch64/aarch64.c (aarch64_split_sve_subreg_move): Apply
aarch64_sve_int_mode to each mode.
PR fortran/93253
* check.c (gfc_invalid_boz): Mention -fallow-invalid-boz
in the error message.
* gfortran.texi (BOZ literal constants): List another missing
extension and refer to -fallow-invalid-boz.
* lang.opt (fallow-invalid-boz): Also mention 'X' in the help text
as it is not covered by the previous wording.
* primary.c (match_boz_constant): Tweak wording such that it is
clear how to fix the nonstandard use.
PR fortran/93253
* fortran.dg/boz_7.f90: Updated dg-error.
I rewrote class impl_region_model_context to avoid using multiple
inheritance during patch review but forgot to update this comment.
Fix it.
gcc/analyzer/ChangeLog:
* engine.cc (class impl_region_model_context): Fix comment.
This is a rather serious regression, filed in July 2019. Luckily the
fix is simple: is localized to parser.c and cp-tree.h in cp and boils
down to only a few lines.
Testing OK on x86_64-linux. Approved off-line by Jason Merrill.
/cp
PR c++/91073
* cp-tree.h (is_constrained_auto): New.
* parser.c (cp_parser_maybe_commit_to_declaration): Correctly
handle concept-check expressions; take a cp_decl_specifier_seq*
instead of a bool.
(cp_parser_condition): Update call.
(cp_parser_simple_declaration): Likewise.
(cp_parser_placeholder_type_specifier): Correctly handle
concept-check expressions.
/testsuite
PR c++/91073
* g++.dg/concepts/pr91073-1.C: New.
* g++.dg/concepts/pr91073-2.C: Likewise.
A prvalue can have void type, and if it doesn't do anything prohibited in a
constant expression, it's vacuously constant.
* constexpr.c (verify_constant): Allow void_node.
I steered Jakub wrong on the desired behavior for temp-extend1.C in the
context of bug 92831; it doesn't make sense to try to extend the lifetime of
a temporary that we've already materialized to evaluate the test. So this
patch munges the stabilized expression so that it won't be subject to
lifetime extension.
* call.c (prevent_lifetime_extension): New.
(build_conditional_expr_1): Use it.
Further improve the ctz recognition: Avoid ICEing on negative shift
counts or multiply constants. Check the type is a char type for the
string constant case to avoid accidentally matching a wide STRING_CST.
Add a tree_expr_nonzero_p check to allow the optimization even if
CTZ_DEFINED_VALUE_AT_ZERO returns 0 or 1. Add extra test cases.
Bootstrap OK on AArch64 and x64.
gcc/
PR tree-optimization/93231
* tree-ssa-forwprop.c (optimize_count_trailing_zeroes): Check
input_type is unsigned. Use tree_to_shwi for shift constant.
Check CST_STRING element size is CHAR_TYPE_SIZE bits.
(simplify_count_trailing_zeroes): Add test to handle known non-zero
inputs more efficiently.
testsuite/
PR tree-optimization/93231
* gcc.dg/pr90838.c: New test.
* gcc.dg/pr93231.c: New test.
* gcc.target/aarch64/pr90838.c: Use #define u 0.
The __iota_diff_t alias can be the type __int128, but that does not
satisfy the signed_integral and __is_signed_integer_like concepts when
__STRICT_ANSI__ is defined (which is true for -std=c++2a).
Because weakly_incrementable is defined in terms of signed_integral, it
is not satisfied by __int128, which means iota_view's iterator doesn't
always satisfy input_or_output_iterator and so iota_view is not always a
range.
The solution is to define __max_size_type and __max_diff_type using
__int128, so that __is_signed_integer_like allows __int128, and then
make weakly_incrementable use __is_signed_integer_like instead of
signed_integral.
PR libstdc++/93267
* include/bits/iterator_concepts.h (__max_diff_type, __max_size_type):
Move here from <bits/range_access.h> and define using __int128 when
available.
(__is_integer_like, __is_signed_integer_like): Move here from
<bits/range_access.h>.
(weakly_incrementable): Use __is_signed_integer_like.
* include/bits/range_access.h (__max_diff_type, __max_size_type)
(__is_integer_like, __is_signed_integer_like): Move to
<bits/iterator_concepts.h>.
(__make_unsigned_like_t): Move here from <ranges>.
* include/std/ranges (__make_unsigned_like_t): Move to
<bits/range_access.h>.
(iota_view): Replace using-directive with using-declarations.
* testsuite/std/ranges/iota/93267.cc: New test.
* testsuite/std/ranges/iota_view.cc: Move to new 'iota' sub-directory.
The previous work to fix PR93199 didn't take into account backedges
when defering insertion. The following simply avoids to defer in that
case since we know we'll not take secondary opportunities there.
2020-01-15 Richard Biener <rguenther@suse.de>
PR middle-end/93273
* tree-eh.c (sink_clobbers): If we already visited the destination
block do not defer insertion.
(pass_lower_eh_dispatch::execute): Maintain BB_VISITED for
the purpose of defered insertion.
* g++.dg/torture/pr93273.C: New testcase.
My earlier update_epilogue_loop_vinfo patch introduced an ICE on these
tests for AVX512. If we use pattern stmts, STMT_VINFO_GATHER_SCATTER_P
is valid for both the original stmt and the pattern stmt, but
STMT_VINFO_MEMORY_ACCESS_TYPE is valid only for the latter.
2020-01-15 Richard Sandiford <richard.sandiford@arm.com>
gcc/
PR tree-optimization/93247
* tree-vect-loop.c (update_epilogue_loop_vinfo): Check the access
type of the stmt that we're going to vectorize.
gcc/testsuite/
PR tree-optimization/93247
* gcc.dg/vect/pr93247-1.c: New test.
* gcc.dg/vect/pr93247-2.c: Likewise.
Having the "same" vector types with different modes means that we can
end up vectorising a constructor with a different mode from the lhs.
This patch adds a VIEW_CONVERT_EXPR in that case.
This showed up on existing tests when testing with fixed-length
-msve-vector-bits=128.
2020-01-15 Richard Sandiford <richard.sandiford@arm.com>
gcc/
* tree-vect-slp.c (vectorize_slp_instance_root_stmt): Use a
VIEW_CONVERT_EXPR if the vectorized constructor has a diffeent
type from the lhs.
Originally, it seemed like a good idea to add automatic 'push' rules
to the git configuration, so that personal- and vendor-space commits
would automatically push to the right place. Unfortunately, this
changes git's behaviour and with these settings "git push" will try to
push all branches in a local tree up to the corresponding location on
the server (ignoring the push.default setting). The only known
mitigation for this is to ALWAYS use "git push <server> <branch>".
So instead, we no-longer add those rules by default and will document
the options on the wiki. We don't automatically remove the push
entries but do print out the command that will do so, if the user so
wishes.
* gcc-git-customization.sh: Explain why we want the user's
upstream account name. Don't add push rules. Check if push rules
have been added and suggest that they should be removed.
* git-fetch-vendor.sh: Don't add push rules.
When an alias-set is an already existing subset there is no need
to re-record its children as childs of the parent.
2020-01-15 Richard Biener <rguenther@suse.de>
* alias.c (record_alias_subset): Avoid redundant work when
subset is already recorded.
Bug 93072 is a case where the C front end (a) wrongly interprets an
inline declaration at block scope as indicating that DECL_CONTEXT
should be set for an inline function and (b) this results in an ICE.
This is a regression resulting from a previous fix of mine for other
bugs involving such declarations being wrongly interpreted elsewhere
as nested function declarations. The fix is similar to the previous
fix: use TREE_PUBLIC instead of DECL_EXTERNAL in another place as the
relevant test to determine whether to set DECL_CONTEXT. (When a
variable reaches the code in question in pushdecl, the two are
equivalent.)
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
PR c/93072
gcc/c:
* c-decl.c (pushdecl): Use TREE_PUBLIC, not DECL_EXTERNAL, to
determine whether to set DECL_CONTEXT.
gcc/testsuite:
* gcc.dg/inline-42.c, gcc.dg/inline-43.c: New tests.
PR analyzer/93212 reports an ICE when attempting to use -fanalyzer
on a C++ source file. That isn't supported yet, but the fix is
trivial (handling METHOD_TYPE as well as FUNCTION_TYPE).
gcc/analyzer/ChangeLog:
PR analyzer/93212
* region-model.cc (make_region_for_type): Use
FUNC_OR_METHOD_TYPE_P rather than comparing against FUNCTION_TYPE.
* region-model.h (function_region::function_region): Likewise.
sm-signal.cc was failing to warn about the use of an fprintf call in a
signal handler when the signal handler function was non-static.
The root cause was a failure to copy global sm-state within
sm_state_map::clone_with_remapping as called by
program_state::can_merge_with_p, which led to the exploded node for
the entrypoint to the handler in the "normal" state being erroneously
reused for the "in_signal_handler" state, thus losing the global state,
and thus failing to warn.
This patch fixes the above, so that non-equal global sm-state values
prevent merger of program_state, thus requiring separate exploded nodes
for the "normal" and "in signal handler" states, and thus triggering
the warning for the reproducer.
gcc/analyzer/ChangeLog:
* program-state.cc (sm_state_map::clone_with_remapping): Copy
m_global_state.
(selftest::test_program_state_merging_2): New selftest.
(selftest::analyzer_program_state_cc_tests): Call it.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/signal-6.c: New test.
This patch adds DISABLE_COPY_AND_ASSIGN to checker_path, and makes its
fields private.
gcc/analyzer/ChangeLog:
* checker-path.h (checker_path::get_checker_event): New function.
(checker_path): Add DISABLE_COPY_AND_ASSIGN; make fields private.
* diagnostic-manager.cc
(diagnostic_manager::prune_for_sm_diagnostic): Replace direct
access to checker_path::m_events with accessor functions. Fix
overlong line.
(diagnostic_manager::prune_interproc_events): Replace direct
access to checker_path::m_events with accessor functions.
(diagnostic_manager::finish_pruning): Likewise.
This patch fixes an issue with the output of -fdump-analyzer-supergraph
on BBs with no statements, where the resulting files were unreadable by
dot e.g.:
Error: syntax error in line 1
... <TABLE BORDER="0"></TABLE> ...
in label of node node_10
gcc/analyzer/ChangeLog:
* supergraph.cc (supernode::dump_dot): Ensure that the TABLE
element has at least one TR.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/dot-output.c: Add test coverage for a BB with
no statements.
In the reproducer for PR analyzer/58237 I noticed that some events were
missing locations (and text); for example event 3 here:
| 15 | while (fgets(buf, 10, fp) != NULL)
| | ~
| | |
| | (2) following 'false' branch...
|
'f1': event 3
|
|cc1:
|
'f1': event 4
|
|<source>:19:1:
| 19 | }
| | ^
| | |
| | (4) 'fp' leaks here; was opened at (1)
|
The root cause is that various places in the analyzer compare locations
against UNKNOWN_LOCATION, which fails to detect an unknown location for
the case where an unknown_location has been wrapped into an ad-hoc
location to record a block.
This patch fixes the issue by using get_pure_location whenever testing
against UNKNOWN_LOCATION to look through ad-hoc wrappers.
For the case above, it thus picks a better location in
supernode::get_start_location for event (3) above, improving it to:
| 15 | while (fgets(buf, 10, fp) != NULL)
| | ~
| | |
| | (2) following 'false' branch...
|......
| 19 | }
| | ~
| | |
| | (3) ...to here
| | (4) 'fp' leaks here; was opened at (1)
|
gcc/analyzer/ChangeLog:
PR analyzer/58237
* engine.cc (leak_stmt_finder::find_stmt): Use get_pure_location
when comparing against UNKNOWN_LOCATION.
(stmt_requires_new_enode_p): Likewise.
(exploded_graph::dump_exploded_nodes): Likewise.
* supergraph.cc (supernode::get_start_location): Likewise.
(supernode::get_end_location): Likewise.
gcc/testsuite/ChangeLog:
PR analyzer/58237
* gcc.dg/analyzer/file-paths-1.c: New test.
In the reproducer for PR analyzer/58237 I noticed that some events that
were missing locations were also missing text; for example event 3 here:
| 15 | while (fgets(buf, 10, fp) != NULL)
| | ~
| | |
| | (2) following 'false' branch...
|
'f1': event 3
|
|cc1:
|
The root cause is that the path_summary-printing code doesn't consider
ad-hoc locations when looking for reserved locations, and so fails to
detect an unknown location for the case where an unknown location has
been wrapped into an ad-hoc location to record a block.
This patch fixes the issue by using get_pure_location, thus looking
through ad-hoc wrappers, improving the result to:
| 15 | while (fgets(buf, 10, fp) != NULL)
| | ~
| | |
| | (2) following 'false' branch...
|
'f1': event 3
|
|cc1:
| (3): ...to here
|
gcc/ChangeLog:
* tree-diagnostic-path.cc (path_summary::event_range::print):
When testing for UNKNOWN_LOCATION, look through ad-hoc wrappers
using get_pure_location.
The analyzer ought to report various file leaks for the reproducer in
PR analyzer/58237, such as:
void f1(const char *str)
{
FILE * fp = fopen(str, "r");
char buf[10];
while (fgets(buf, 10, fp) != NULL)
{
/* Do something with buf */
}
/* Missing call to fclose. Need warning here for resource leak */
}
but fails to do so, due to not recognizing fgets, and thus
conservatively assuming that it could close "fp".
This patch adds a function_set to sm-file.cc of numerous stdio.h
functions that are known to not close the file (and which require a
valid FILE *, but that's a matter for a followup), fixing the issue.
gcc/analyzer/ChangeLog:
PR analyzer/58237
* analyzer-selftests.cc (selftest::run_analyzer_selftests): Call
selftest::analyzer_sm_file_cc_tests.
* analyzer-selftests.h (selftest::analyzer_sm_file_cc_tests): New
decl.
* sm-file.cc: Include "analyzer/function-set.h" and
"analyzer/analyzer-selftests.h".
(get_file_using_fns): New function.
(is_file_using_fn_p): New function.
(fileptr_state_machine::on_stmt): Return true for known functions.
(selftest::analyzer_sm_file_cc_tests): New function.
gcc/testsuite/ChangeLog:
PR analyzer/58237
* gcc.dg/analyzer/file-1.c (test_4): New.
* gcc.dg/analyzer/file-pr58237.c: New test.
The following testcase shows that GCC trunk mishandles DSE of __*_chk
calls. Tail trimming of the calls is fine, we want to just decrease the
third argument and keep the first two and last arguments unmodified.
But for head trimming, we currently increment the two by head_trim and
decrease the third by head_trim, so
__builtin___memcpy_chk (&a, b_2(D), 48, 32);
__builtin_memset (&a, 32, 16);
into:
_5 = b_2(D) + 16;
__builtin___memcpy_chk (&MEM <char> [(void *)&a + 16B], _5, 32, 32);
__builtin_memset (&a, 32, 16);
This is wrong, because the 32 was the determined (maximum) size of the
destination (char a[32]), but &a[16] has maximum size of 16, not 32.
The __builtin___memcpy_chk (&MEM <char> [(void *)&a + 16B], _5, 32, 32);
call is just folded later into
__builtin_memcpy (&MEM <char> [(void *)&a + 16B], _5, 32);
because it says that it copies as many bytes into destination as the
destination has. We need:
__builtin___memcpy_chk (&MEM <char> [(void *)&a + 16B], _5, 32, 16);
instead, which will terminate the program instead of letting it silently
overflow the buffer.
The patch just punts if we'd need to decrease the last argument below 0.
Fortunately, release branches are unaffected.
P.S. it was quite hard to make the runtime test working, in builtins.exp
neither dg-options nor dg-additional-options work and builtins.exp adds
-fno-tree-dse among several other -fno-* options. Fortunately optimize
attribute works.
2020-01-15 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/93262
* tree-ssa-dse.c (maybe_trim_memstar_call): For *_chk builtins,
perform head trimming only if the last argument is constant,
either all ones, or larger or equal to head trim, in the latter
case decrease the last argument by head_trim.
* gcc.c-torture/execute/builtins/pr93262-chk.c: New test.
* gcc.c-torture/execute/builtins/pr93262-chk-lib.c: New file.
* gcc.c-torture/execute/builtins/pr93262-chk.x: New file.
As the testcase shows, tail trimming of strncpy in tree-ssa-dse.c is fine,
we just copy or clear fewer bytes in the destination, but unlike
memcpy/memset etc., head trimming is problematic in certain cases.
If we can prove that there are no zero bytes among initial head_trim bytes,
it is ok to trim it, if we can prove there is at least one zero byte among
initial head_trim bytes, we could (not implemented in the patch) turn
the strncpy into memset 0, but otherwise we need to avoid the head trimming,
because the presence or absence of NUL byte there changes the behavior for
subsequent bytes, whether further bytes from src are copied or if further
bytes are cleared.
2020-01-15 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/93249
* tree-ssa-dse.c: Include builtins.h and gimple-fold.h.
(maybe_trim_memstar_call): Move head_trim and tail_trim vars to
function body scope, reindent. For BUILTIN_IN_STRNCPY*, don't
perform head trim unless we can prove there are no '\0' chars
from the source among the first head_trim chars.
* gcc.c-torture/execute/pr93249.c: New test.
This patch uses the class function_set from the previous patch to
generalize the test for an fprintf inside a signal handler to
check for a set of known async-signal-unsafe functions.
gcc/analyzer/ChangeLog:
* analyzer-selftests.cc (selftest::run_analyzer_selftests): Call
selftest::analyzer_sm_signal_cc_tests.
* analyzer-selftests.h (selftest::analyzer_sm_signal_cc_tests):
New decl.
* sm-signal.cc: Include "analyzer/function-set.h" and
"analyzer/analyzer-selftests.h".
(get_async_signal_unsafe_fns): New function.
(signal_unsafe_p): Reimplement in terms of the above.
(selftest::analyzer_sm_signal_cc_tests): New function.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/signal-5.c: New test.
This patch adds a simple mechanism for tracking sets of functions
for which a particular property holds, as a pragmatic way to build
knowledge about important APIs into the analyzer without requiring
markup of the user's libc.
gcc/ChangeLog:
* Makefile.in (ANALYZER_OBJS): Add analyzer/function-set.o.
gcc/analyzer/ChangeLog:
* analyzer-selftests.cc (selftest::run_analyzer_selftests): Call
selftest::analyzer_function_set_cc_tests.
* analyzer-selftests.h (selftest::analyzer_function_set_cc_tests):
New decl.
* function-set.cc: New file.
* function-set.h: New file.
Whilst analyzing the reproducer for detecting CVE-2005-1689
(krb5-1.4.1's src/lib/krb5/krb/recvauth.c), the analyzer reports
a false double-free of the form:
krb5_xfree(inbuf.data);
krb5_read_message(..., &inbuf);
krb5_xfree(inbuf.data); /* false diagnostic here. */
where the call to krb5_read_message overwrites inbuf.data with
a freshly-malloced buffer.
This patch fixes the issue by purging state more thorougly when
handling a call with unknown behavior, by walking the graph of
memory regions that are reachable from the call.
gcc/analyzer/ChangeLog:
* analyzer.h (fndecl_has_gimple_body_p): New decl.
* engine.cc (impl_region_model_context::on_unknown_change): New
function.
(fndecl_has_gimple_body_p): Make non-static.
(exploded_node::on_stmt): Treat __analyzer_dump_exploded_nodes as
known. Track whether we have a call with unknown side-effects and
pass it to on_call_post.
* exploded-graph.h (impl_region_model_context::on_unknown_change):
New decl.
* program-state.cc (sm_state_map::on_unknown_change): New function.
* program-state.h (sm_state_map::on_unknown_change): New decl.
* region-model.cc: Include "bitmap.h".
(region_model::on_call_pre): Return a bool, capturing whether the
call has unknown side effects.
(region_model::on_call_post): Add arg "bool unknown_side_effects"
and if true, call handle_unrecognized_call.
(class reachable_regions): New class.
(region_model::handle_unrecognized_call): New function.
* region-model.h (region_model::on_call_pre): Return a bool.
(region_model::on_call_post): Add arg "bool unknown_side_effects".
(region_model::handle_unrecognized_call): New decl.
(region_model_context::on_unknown_change): New vfunc.
(test_region_model_context::on_unknown_change): New function.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/data-model-1.c: Remove xfail.
* gcc.dg/analyzer/data-model-5b.c: Likewise.
* gcc.dg/analyzer/data-model-5c.c: Likewise.
* gcc.dg/analyzer/setjmp-3.c: Mark "foo" as pure.
* gcc.dg/analyzer/setjmp-4.c: Likewise.
* gcc.dg/analyzer/setjmp-6.c: Likewise.
* gcc.dg/analyzer/setjmp-7.c: Likewise.
* gcc.dg/analyzer/setjmp-7a.c: Likewise.
* gcc.dg/analyzer/setjmp-8.c: Likewise.
* gcc.dg/analyzer/setjmp-9.c: Likewise.
* gcc.dg/analyzer/unknown-fns.c: New test.
Whilst analyzing the reproducer for detecting CVE-2005-1689
(krb5-1.4.1's src/lib/krb5/krb/recvauth.c), the analyzer reported
11 double-free diagnostics on lines of the form:
krb5_xfree(inbuf.data);
with no deduplication occcurring.
The root cause is that the diagnostics each have a COMPONENT_REF for
the inbuf.data, but they are different trees, and the de-duplication
logic was using pointer equality.
This patch replaces the pointer equality tests with calls to a new
pending_diagnostic::same_tree_p, implemented using simple_cst_equal.
With this patch, de-duplication occurs, and only 3 diagnostics are
reported. The 11 diagnostics are partitioned into 3 dedupe keys,
2 with 2 duplicates and 1 with 7 duplicates.
gcc/analyzer/ChangeLog:
* diagnostic-manager.cc (saved_diagnostic::operator==): Move here
from header. Replace pointer equality test on m_var with call to
pending_diagnostic::same_tree_p.
* diagnostic-manager.h (saved_diagnostic::operator==): Move to
diagnostic-manager.cc.
* pending-diagnostic.cc (pending_diagnostic::same_tree_p): New.
* pending-diagnostic.h (pending_diagnostic::same_tree_p): New.
* sm-file.cc (file_diagnostic::subclass_equal_p): Replace pointer
equality on m_arg with call to pending_diagnostic::same_tree_p.
* sm-malloc.cc (malloc_diagnostic::subclass_equal_p): Likewise.
(possible_null_arg::subclass_equal_p): Likewise.
(null_arg::subclass_equal_p): Likewise.
(free_of_non_heap::subclass_equal_p): Likewise.
* sm-pattern-test.cc (pattern_match::operator==): Likewise.
* sm-sensitive.cc (exposure_through_output_file::operator==):
Likewise.
* sm-taint.cc (tainted_array_index::operator==): Likewise.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/CVE-2005-1689-dedupe-issue.c: New test.
As mentioned in the PR, the following testcase is miscompiled with avx512vl.
The reason is that the fma *_bcst_1 define_insns have two alternatives:
"=v,v" "0,v" "v,0" "m,m" and use the same
vfmadd213* %3<avx512bcst>, %2, %0<sd_mask_op4>
pattern. If the first alternative is chosen, everything is ok, but if the
second alternative is chosen, %2 and %0 are the same register, so instead
of doing dest=dest*another+membcst we do dest=dest*dest+membcst.
Now, to fix this, either we'd need separate:
"vfmadd213<ssemodesuffix>\t{%3<avx512bcst>, %2, %0<sd_mask_op4>|%0<sd_mask_op4>, %2, %3<avx512bcst>}
vfmadd213<ssemodesuffix>\t{%3<avx512bcst>, %1, %0<sd_mask_op4>|%0<sd_mask_op4>, %1, %3<avx512bcst>}"
where for the second alternative, we'd just use %1 instead of %2, but
what I think is actually cleaner is just use a single alternative and
make the two multiplication operands commutative, which they really are.
2020-01-15 Jakub Jelinek <jakub@redhat.com>
PR target/93009
* config/i386/sse.md
(*<sd_mask_codefor>fma_fmadd_<mode><sd_maskz_name>_bcst_1,
*<sd_mask_codefor>fma_fmsub_<mode><sd_maskz_name>_bcst_1,
*<sd_mask_codefor>fma_fnmadd_<mode><sd_maskz_name>_bcst_1,
*<sd_mask_codefor>fma_fnmsub_<mode><sd_maskz_name>_bcst_1): Use
just a single alternative instead of two, make operands 1 and 2
commutative.
* gcc.target/i386/avx512vl-pr93009.c: New test.
