On Fri, 2020-01-10 at 08:35 -0700, Jeff Law wrote:
> On Wed, 2020-01-08 at 17:07 -0500, David Malcolm wrote:
> > (replying to my own "[PATCH 05/41] Add -fdiagnostics-nn-line-
> > numbers"
> > with a followup that does it at the DejaGnu level rather than as a
> &
On Fri, 2020-01-10 at 08:53 -0700, Jeff Law wrote:
> On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> > Jeff reviewed an earlier version of this here:
> > https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00503.html
> > My response:
> > https://gcc.gnu.org/ml/g
On Fri, 2020-01-10 at 09:10 -0700, Jeff Law wrote:
> On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> > Jeff's initial review of v1 of this patch:
> > https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00813.html
> > I've addressed most of the issues he rais
On Fri, 2020-01-10 at 10:24 -0700, Jeff Law wrote:
> On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> > Needs review.
> >
> > Changed in v5:
> > - update ChangeLog path
> > - updated copyright years to include 2020
> >
> > Changed in v4
On Fri, 2020-01-10 at 08:38 -0700, Jeff Law wrote:
> On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> > I believe I can self-approve this with my "diagnostic messages"
> > maintainer hat on. It has dependencies on the auto_delete_vec
> > and the -fdiag
On Fri, 2020-01-10 at 09:46 -0700, Jeff Law wrote:
> On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
> > The v1 version of this patch was reviewed by Jeff here:
> > https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00805.html
> > TODO: looks like I still need to act on
On Wed, 2019-12-11 at 17:00 +0100, Jakub Jelinek wrote:
> On Wed, Dec 11, 2019 at 10:44:58AM -0500, David Malcolm wrote:
> > Is it OK for a hash_map key to have a "empty" value that isn't
> > all-zeroes (and thus the same for a hash_table entry)?
> >
>
On Mon, 2020-01-13 at 10:46 +0100, Rainer Orth wrote:
> Hi David,
>
> > On Fri, 2020-01-10 at 08:38 -0700, Jeff Law wrote:
> > > On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
[...]
> > I've gone ahead and committed this to trunk (r280142) after testin
I posted the initial version of the analyzer patch kit on 2019-11-15,
shortly before the close of stage 1.
Jeff reviewed (most of) the latest version of the kit on Friday, and
said:
> I'm not going to have time to finish #22 or #37 -- hell, I'm not even
> supposed to be working today :-)
>
> I'd
On Tue, 2020-01-14 at 00:26 +0100, Jakub Jelinek wrote:
> On Mon, Jan 13, 2020 at 11:56:14PM +0100, Jakub Jelinek wrote:
> > > Some options:
> > > (a) the patch to fix hash_table::empty, and the analyzer kit
> > > (b) the analyzer kit with the following kludge
> > > (c) someone with better C++-fu t
On Tue, 2020-01-14 at 00:55 +0100, Jakub Jelinek wrote:
> On Mon, Jan 13, 2020 at 06:42:06PM -0500, David Malcolm wrote:
> > Thanks. Does it have warnings, though?
> >
> > My attempt was similar, but ran into warnings from -Wclass-
> > memaccess in
> > four plac
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu
OK for master?
gcc/analyzer/ChangeLog:
* diagnostic-manager.cc (dedupe_hash_map_traits::empty_zero_p):
New static constant.
* engine.cc
(default_hash_traits::empty_zero_p): Likewise.
* exploded-g
On Mon, 2020-01-13 at 21:58 -0500, David Malcolm wrote:
> On Tue, 2020-01-14 at 00:55 +0100, Jakub Jelinek wrote:
> > On Mon, Jan 13, 2020 at 06:42:06PM -0500, David Malcolm wrote:
> > > Thanks. Does it have warnings, though?
> > >
> > > My attempt was similar
On Tue, 2020-01-14 at 11:02 +0100, Jakub Jelinek wrote:
> On Mon, Jan 13, 2020 at 11:51:53PM -0500, David Malcolm wrote:
> > > * cfg.s correctly has a call to memset (even with no
> > > optimization)
> > > for
> > > hash_table::empty_slow
>
> I h
On Mon, 2020-01-13 at 11:23 +0800, luoxhu wrote:
> On 2020/1/10 19:08, Jan Hubicka wrote:
> > OK. You will need to do the obvious updates for Martin's patch
> > which turned some member functions into static functions.
> >
> > Honza
>
> Thanks a lot! Rebased & updated, will commit below patch sh
On Tue, 2020-01-14 at 08:55 +0100, Richard Biener wrote:
> On Mon, 13 Jan 2020, David Malcolm wrote:
>
> > I posted the initial version of the analyzer patch kit on 2019-11-
> > 15,
> > shortly before the close of stage 1.
> >
> > Jeff reviewed (most of) the
Committed to master under the "obvious" rule
(ab7c7b46c35ed1be68d4c020a2f20ee96f68b64b)
gcc/ChangeLog:
* doc/invoke.texi (-fdiagnostics-show-cwe): Add note that some of
the analyzer options provide CWE identifiers.
---
gcc/doc/invoke.texi | 3 ++-
1 file changed, 2 insertions(+),
These have been in the dmalcolm/analyzer branch for a while.
I've pushed them to master, as the given commits.
(successfully bootstrapped & regrtested on x86_64-pc-linux-gnu)
"analyzer: better logging for dedupe_winners::add"
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01235.html
f474fbd5e3cca
Although most of the analyzer work is now on master I'm tracking
additional work in a branch (for future features, work that isn't quite
ready yet, etc).
This used to be "dmalcolm/analyzer" on the git mirror.
The new git server doesn't seem to like such branch names [1], so I'm
now using "devel/a
On Wed, 2020-01-15 at 13:30 +0100, Rainer Orth wrote:
> Hi David,
>
> > I've rebased and squashed the analyzer patch kit and squashed patch
> > 2
> > of the hash_table fix into it, and re-tested it successfully, so
> > I've
> > pushed it to master (as 757bf1dff5e8cee34c0a75d06140ca972bfecfa7).
> >
I rewrote class impl_region_model_context to avoid using multiple
inheritance during patch review but forgot to update this comment.
Fix it.
Pushed to origin/master as 49e9a9996ab334133c78f1445173d8e663edd3e9
gcc/analyzer/ChangeLog:
* engine.cc (class impl_region_model_context): Fix comm
Pushed to origin/master as 5b6681201ae54a3272d49e390f96a1a45a6eb435
gcc/ChangeLog:
* doc/analyzer.texi (Overview): Add note about
-fdump-ipa-analyzer.
---
gcc/doc/analyzer.texi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/doc/analyzer.texi b/gcc/doc/analyzer.texi
inde
Various 32-bit targets show failures in gcc.dg/analyzer/data-model-1.c
with tests of the form:
__analyzer_eval (q[-2].x == 107024); /* { dg-warning "TRUE" } */
__analyzer_eval (q[-2].y == 107025); /* { dg-warning "TRUE" } */
where they emit UNKNOWN instead.
The root cause is that gimple has a
On Thu, 2020-01-16 at 18:01 +0100, Jakub Jelinek wrote:
> Hi!
>
> The PR87488 changes include:
> * lib/prune.exp (TEST_ALWAYS_FLAGS): Add -fdiagnostics-
> urls=never.
> Unfortunately, this broke all the compat.exp etc. compatibility
> testing with
> alternate compilers, because those compile
On Thu, 2020-01-16 at 09:14 +0100, Jakub Jelinek wrote:
> On Wed, Jan 15, 2020 at 06:56:48PM -0500, David Malcolm wrote:
> > gcc/analyzer/ChangeLog:
> > PR analyzer/93281
> > * region-model.cc
> > (region_model::convert_byte_offset_to_array_index): Co
DejaGnu test directives such as dg-warning support an optional
"comment" argument for disambiguating multiple tests on the same line.
Jeff noticed various name collisions of test names in the analyzer
testsuite, due to me using empty comment strings when using line
offsets in test directives.
Thi
PR analyzer/93290 reports an ICE on calls to isnan().
The root cause is that an UNORDERED_EXPR is passed
to region_model::eval_condition_without_cm, and there's
a stray gcc_unreachable () in the case where we're comparing
an svalue against itself.
I attempted a more involved patch that properly ha
PR analyzer/93307 reports that in an LTO bootstrap, there are ODR
violations between:
- the "region" type:
gcc/analyzer/region-model.h:792
vs:
gcc/sched-int.h:1443
- the "constraint" type:
gcc/analyzer/constraint-manager.h:121
vs:
gcc/tree-ssa-structalias.c:533
This patches sol
Amongst the inputs to the analyzer state machines that can lead to state
transitions are conditions on CFG edges, such as a test for a pointer
being non-NULL.
These conditionals can be non-trivial to determine in the face of
optimization. For example, at -O2:
if (p == NULL || q == NULL)
is op
I ran into difficulties with the Graphviz format changing from under
me during an upgrade, where the new version of "dot" would reject .dot
files generated by the analyzer.
The analyzer testsuite has a dot-output.c test that attempts to check
that the generated .dot can be handled by dot, with a d
> > On Mon, 2020-01-13 at 11:23 +0800, luoxhu wrote:
> > On 2020/1/10 19:08, Jan Hubicka wrote:
> > > OK. You will need to do the obvious updates for Martin's patch
> > > which turned some member functions into static functions.
> > >
> > > Honza
> >
> > Thanks a lot! Rebased & updated, will com
On Sat, 2020-01-18 at 18:42 +0100, Jan Hubicka wrote:
> > > > On Mon, 2020-01-13 at 11:23 +0800, luoxhu wrote:
> > > > On 2020/1/10 19:08, Jan Hubicka wrote:
> > > > > OK. You will need to do the obvious updates for Martin's
> > > > > patch
> > > > > which turned some member functions into static f
On Tue, 2020-01-21 at 16:10 +0100, Jan Hubicka wrote:
> > If we do, then, if I understand correctly, this would only affect
> > someone who tried to use libgccjit to generate .o files with -flto,
> > repeatedly, within a single process. I don't know of anyone doing
> > that, and if that's broken,
PR analyzer/93352 reports a qsort failure
"comparator not anti-symmetric: -2147483648, -2147483648)"
within the analyzer on code involving an array access of [0x7fff + 1].
The issue is that array_region (which uses int for keys into known
values in the array) uses subtraction to implement in
On Fri, 2020-01-17 at 16:54 -0500, David Malcolm wrote:
> PR analyzer/93307 reports that in an LTO bootstrap, there are ODR
> violations between:
> - the "region" type:
> gcc/analyzer/region-model.h:792
> vs:
> gcc/sched-int.h:1443
> - the "constraint&
PR analyzer/93316 reports various testsuite failures where I
accidentally relied on properties of x86_64-pc-linux-gnu.
The following patch fixes them on sparc-sun-solaris2.11 (gcc211 in the
GCC compile farm), and, I hope, the other configurations showing
failures.
There may still be other failure
PR analyzer/93378 reports an ICE at -O1 -g when analyzing a rewind via
longjmp to a setjmp call with.
The root cause is that the rewind_info_t::get_setjmp_call attempts to
locate the setjmp GIMPLE_CALL via within the exploded_node containing
it, but the exploded_node has two stmts: a GIMPLE_DEBUG,
On Wed, 2020-01-22 at 14:56 -0500, David Malcolm wrote:
> PR analyzer/93378 reports an ICE at -O1 -g when analyzing a rewind
> via
> longjmp to a setjmp call with.
>
> The root cause is that the rewind_info_t::get_setjmp_call attempts to
> locate the setjmp GIMPLE_C
When adding namespaces to the analyzer in
r10-6151-g75038aa6aa5b562e6358108619d66ef2ccab9a53
I messed up the nesting of the #endif for #if CHECKING_P
and the closing of namespace ana.
This patch fixes it.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu;
verified stage 1 build with -
The ICE in PR analyzer/93382 is a validation error.
The global variable "idx" acquires a "tainted" state from local array
n1[0]. When the frame is popped, the svalue for n1[0] is purged, but
the "taint" sm_state_map's entry for "idx" has a svalue_id referencing
the now-purged svalue. This is cau
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
OK for master? I'm working on various followup bugfixes that could
use this for test coverage.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/data-model-3.c: Remove hardcoded "-O2" and move
to torture/conftest-1.c.
On Wed, 2020-01-22 at 19:02 +0100, Jakub Jelinek wrote:
> On Wed, Jan 22, 2020 at 08:08:32PM +0300, Alexander Monakov wrote:
> >
> > On Wed, 22 Jan 2020, Stefan Schulze Frielinghaus wrote:
> >
> > > Hi David,
> > >
> > > In function `tree_cmp` an invariant [1] is assumed which does not
> > > nec
PR analyzer/93375 reports an ICE under certain circumstances
involving a call where the number of arguments at the callsite
is less than the parameter count of the callee,
Specifically, the ICE occurs when pruning a checker_path for a
diagnostic, when attempting to maintain which expression is of
On Thu, 2020-01-23 at 18:46 +0300, Alexander Monakov wrote:
> On Thu, 23 Jan 2020, David Malcolm wrote:
>
> > Removing the assertions fixes it for me (a stage1 build, at least,
> > and
> > it then passes the testsuite).
> >
> > I've made th
On Wed, 2020-01-22 at 20:40 +0100, Jakub Jelinek wrote:
> On Wed, Jan 22, 2020 at 02:35:13PM -0500, David Malcolm wrote:
> > PR analyzer/93316 reports various testsuite failures where I
> > accidentally relied on properties of x86_64-pc-linux-gnu.
> >
> > The followin
PR analyzer/93367 reports a testsuite failure in abort.c on
hppa64-hp-hpux11.11 when detecting if the analyzer "knows" that the
condition holds after the assert.
The root cause is that the assertion failure function in that
configuration's is not marked with
__attribute__ ((__noreturn__)).
This
PR analyzer/93349 reports an ICE in IPA pass: simdclone for
some input files when -fanalyzer is supplied, with:
error: location references block not in block tree
The root cause is that the analyzer touches input_location in some
places (to make it easier to track down which source construct the
This patch fixes various build failures seen with gcc 4.4
gcc prior to 4.6 complains about:
error: #pragma GCC diagnostic not allowed inside functions
for various uses of PUSH_IGNORE_WFORMAT and POP_IGNORE_WFORMAT.
This patch makes them a no-op with such compilers.
The patch also fixes variou
On Mon, 2020-01-27 at 10:57 +0100, Martin Liška wrote:
> Hello.
>
> The patch is about splitting pair of errors into
> error and inform which seems logical to me in this
> situation:
[...]
> diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> index 4520c995028..f9bed1ea4fb 100644
> --- a/gcc/cp/pt.c
> +++
On Thu, 2020-01-23 at 17:16 -0500, David Malcolm wrote:
> On Wed, 2020-01-22 at 20:40 +0100, Jakub Jelinek wrote:
> > On Wed, Jan 22, 2020 at 02:35:13PM -0500, David Malcolm wrote:
> > > PR analyzer/93316 reports various testsuite failures where I
> > > accidentally rel
On Fri, 2020-01-24 at 11:16 +0100, Stefan Schulze Frielinghaus wrote:
> On Thu, Jan 23, 2020 at 05:13:20PM -0500, David Malcolm wrote:
> [...]
> > Fixes build on s390x-ibm-linux-gnu for stage 1, at least, with no
> > testsuite regressions. Full bootstrap and regression test r
On Mon, 2020-01-27 at 16:23 +0100, Martin Liška wrote:
> On 1/27/20 2:38 PM, David Malcolm wrote:
> > Please add an
> >auto_diagnostic_group d;
> > here, so that -fdiagnostics-format=json can nest the note below the
> > error.
> >
> > OK w
PR analyzer/93451 reports an ICE when canonicalizing the constants
in a region_model, with a failed qsort_chk when attempting to sort
the constants within the region_model.
The svalues in the model were:
sv0: {poisoned: uninit}
sv1: {type: ‘double’, ‘0.0’}
sv2: {type: ‘double’, ‘1.0e+0’}
s
On Wed, 2020-01-22 at 20:40 +0100, Jakub Jelinek wrote:
> On Wed, Jan 22, 2020 at 02:35:13PM -0500, David Malcolm wrote:
> > PR analyzer/93316 reports various testsuite failures where I
> > accidentally relied on properties of x86_64-pc-linux-gnu.
> >
> > The followin
On Tue, 2020-01-28 at 11:16 +0100, Jakub Jelinek wrote:
> On Wed, Dec 18, 2019 at 07:08:25PM -0500, David Malcolm wrote:
> > This patch adds support for associating a diagnostic message with
> > an
> > optional diagnostic_metadata object, so that plugins can add extra
On Tue, 2020-01-28 at 15:36 +0100, Jakub Jelinek wrote:
> On Tue, Jan 28, 2020 at 09:30:17AM -0500, David Malcolm wrote:
> > * diagnostic-core.h (warning_at): Rename overload to...
> > (warning_with_metadata_at): ...this.
>
> I think this is just too long, especiall
On Tue, 2020-01-28 at 11:13 +0100, Jakub Jelinek wrote:
> On Fri, Jan 24, 2020 at 07:53:28PM -0500, David Malcolm wrote:
> > This patch fixes various build failures seen with gcc 4.4
> >
> > gcc prior to 4.6 complains about:
> >
> > error: #pragma GCC diagno
On Tue, 2020-01-28 at 16:34 +0100, Jakub Jelinek wrote:
> On Tue, Jan 28, 2020 at 10:30:58AM -0500, David Malcolm wrote:
> > gcc/analyzer/ChangeLog:
> > * region-model.cc (poisoned_value_diagnostic::emit): Update for
> > renaming of warning_at overload to warning_meta.
Comments 11-16 within PR analyzer/93316 discuss an ICE in some setjmp
tests seen on AIX and powerpc-darwin9.
The issue turned out to be an implicit assumption that longjmp is
marked "noreturn". There are two places in engine.cc where the code
attempted to locate the longjmp GIMPLE_CALL by finding
PR analyzer/93450 reports an ICE trying to fold an EQ_EXPR comparison
of (int)0 with (float)Inf.
Most comparisons inside the analyzer come from gimple conditions, for
which the necessary casts have already been added.
This one is done inside constant_svalue::eval_condition as part of
purging sm-s
PR analyzer/93356 reports an ICE handling __builtin_isnan due to a
failing assertion:
674 gcc_assert (lhs_ec_id != rhs_ec_id);
with op=UNORDERED_EXPR.
when attempting to add an UNORDERED_EXPR constraint.
This is an overzealous assertion, but underlying it are various forms of
sloppiness rega
Successfully regrtested on x86_64-pc-linux-gnu.
Committed to master as e34ad101a4338eab41e38e624f2c7178d0b83d24.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/conditionals-2.c: Move to...
* gcc.dg/analyzer/torture/conditionals-2.c: ...here, converting
to a torture test. Remov
This test assumes that memset and strlen have been marked with
__attribute__((nonnull)), which isn't necessarily the case for an
arbitrary . This likely explains these failures:
FAIL: gcc.dg/analyzer/malloc-1.c (test for warnings, line 417)
FAIL: gcc.dg/analyzer/malloc-1.c (test for warnings
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Committed to master as ebe9174e940c94e99cd688a05309833ae64a998b.
gcc/analyzer/ChangeLog:
* diagnostic-manager.cc (for_each_state_change): Use
extrinsic_state::get_num_checkers rather than accessing m_checkers
di
I found this useful whilst investigating a bug.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Committed to master as ebe9174e940c94e99cd688a05309833ae64a998b.
gcc/analyzer/ChangeLog:
* program-state.cc (extrinsic_state::dump_to_pp): New.
(extrinsic_state::dump_to_
gcc/analyzer/ChangeLog:
PR analyzer/93450
* constraint-manager.cc
(constraint_manager::get_or_add_equiv_class): Only compare constants
if their types are compatible.
* region-model.cc (constant_svalue::eval_condition): Replace check
for identical type
On Thu, 2020-01-30 at 15:36 +0100, Jakub Jelinek wrote:
> On Thu, Jan 30, 2020 at 09:27:33AM -0500, David Malcolm wrote:
> > --- a/gcc/analyzer/region-model.cc
> > +++ b/gcc/analyzer/region-model.cc
> > @@ -666,12 +666,16 @@ constant_svalue::eval_condition
>
Various places in the analyzer use fold_build2, test the result, then
discard it. It's more efficient to use fold_binary, which avoids
building and GC-ing a redundant tree for the cases where folding fails.
gcc/analyzer/ChangeLog:
* constraint-manager.cc (range::constrained_to_single_elem
On Tue, 2020-01-28 at 08:36 +0100, Jakub Jelinek wrote:
> On Mon, Jan 27, 2020 at 09:09:37PM -0500, David Malcolm wrote:
> > > Please see calls.c (special_function_p), you should treat
> > > certainly
> > > also sigsetjmp as a setjmp call, and similarly to
> > &
PR analyzer/93438 reports an ICE when merging two region_models
in which an older stack frame has a local pointing to a local in
a more recent stack frame.
stack
older frame
int *: "ow" --+
|
newer frame |
int: "pk" <---+
The root cause is that the st
PR analyzer/93379 reports an ICE within
region_model::update_for_return_superedge when writing the
returned svalue_id to the lhs of the call_stmt
The root cause is that this analyzer code assumed that for any call
with a non-NULL gimple_call_lhs, the called fndecl would have non-void
return type,
On Fri, 2020-01-31 at 14:31 -0500, Lewis Hyatt wrote:
> Hello-
>
> Here is the second patch that I mentioned when I submitted the other
> related
> patch (which is awaiting review):
> https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01626.html.
Sorry about that; I'm v. busy with analyzer bugs right
On Fri, 2020-01-31 at 16:59 +, Bernd Edlinger wrote:
> Hi,
>
> this is patch is heavily based on David's original patch here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01409.html
>
> and addresses Jakub's review comments here:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01412.html
>
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r10-6385-g09bea5845a50189b093e7fa8d5b840da702197d4.
gcc/analyzer/ChangeLog:
PR analyzer/93373
* region-model.cc (ASSERT_COMPAT_TYPES): Convert to...
(assert_compat_types): ...this, and bail w
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r10-6386-g6775172431a8e6f0d20ac0c4946d6b5db2f46450.
gcc/analyzer/ChangeLog:
PR analyzer/93457
* region-model.cc (make_region_for_type): Use VOID_TYPE_P rather
than checking against void_type_
On Sat, 2020-02-01 at 07:30 +, Bernd Edlinger wrote:
>
> On 1/31/20 11:06 PM, David Malcolm wrote:
> > On Fri, 2020-01-31 at 16:59 +, Bernd Edlinger wrote:
> > > Hi,
> > >
> > > this is patch is heavily based on David's original patch here:
&
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r10-6409-g287ccd3bd6b92f11ec90c52ffccb764aacfadb89.
gcc/analyzer/ChangeLog:
PR analyzer/93547
* constraint-manager.cc
(constraint_manager::get_or_add_equiv_class): Ensure types are
co
PR analyzer/93546 reports an ICE within region_model::add_region_for_type
when merging two region_models each containing a label pointer. The
two labels are stored as pointers to symbolic_regions, but these regions
were created with NULL type, leading to an assertion failure when a
merged copy is
I found this useful whilst debugging PR analyzer/93544
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as 73f386581bddc4d630b93eeb0cddd32943bf24e7.
gcc/analyzer/ChangeLog:
* engine.cc (supernode_cluster::dump_dot): Show BB index as
well as SN index.
PR analyzer/93544 reports an ICE when attempting to report a double-free
within diagnostic_manager::prune_for_sm_diagnostic, in which the
variable of interest has become an INTEGER_CST. Additionally, it picks
a nonsensical path through the function in which the pointer being
double-freed is known
Fix some failures on xstormy16-elf:
gcc.dg/analyzer/data-model-1.c (test for warnings, line 595)
gcc.dg/analyzer/data-model-1.c (test for warnings, line 642)
gcc.dg/analyzer/data-model-1.c (test for warnings, line 690)
gcc.dg/analyzer/data-model-1.c (test for warnings, line 738)
due to
The analyzer recognizes __analyzer_dump_exploded_nodes as a "magic"
function for use in DejaGnu tests: at the end of the pass, it issues
a warning at each such call, dumping the count of exploded nodes seen at
the call, which can be checked in test cases via dg-warning directives,
along with the ID
Although the analyzer works on GIMPLE SSA and therefore in theory ought
to support all languages supported by GCC, the code currently only
supports the subset of GIMPLE SSA expressible via the C frontend.
For GCC 10 I want to explicitly restrict the scope of the analyzer to
C code, to keep the ini
On Wed, 2020-02-05 at 16:18 +0100, Jakub Jelinek wrote:
> On Wed, Feb 05, 2020 at 09:59:19AM -0500, David Malcolm wrote:
> > Although the analyzer works on GIMPLE SSA and therefore in theory
> > ought
> > to support all languages supported by GCC, the code currently only
>
The dumps from the analyzer sometimes contain garbled output.
The root cause is due to nesting of calls to pp_printf: I'm using
pp_printf with %qT to print types with a PP using default_tree_printer.
default_tree_printer handles 'T' (and various other codes) via
dump_generic_node (pp, t, 0, TDF
When investigating how the analyzer handles malloc/free of Cray pointers
in gfortran I noticed that that analyzer was losing information on
pointers that were cast to an integer type, and then back to a pointer
type again.
The root cause is that region_model::maybe_cast_1 was only preserving
the r
PR analyzer/93405 reports an ICE when attempting to use -fanalyzer on
certain gfortran code. The second patch in this kit fixes that, but
in the meantime I need somewhere to put regression tests for -fanalyzer
with gfortran.
This patch adds a gfortran.dg/analyzer subdirectory with an analyzer.exp
PR analyzer/93405 reports an ICE with -fanalyzer when passing
a constant "by reference" in gfortran.
The issue is that the constant is passed as an ADDR_EXPR
of a CONST_DECL, and region_model::get_lvalue_1 doesn't
know how to handle CONST_DECL.
This patch implements it for CONST_DECL by providing
PR analyzer/93288 reports a C++-specific ICE with -fanalyzer.
This patch creates the beginnings of a C++ test suite for the analyzer,
so that there's a place to put test coverage for the fix.
It adds a regression test for PR analyzer/93212, an ICE fixed
in r10-5970-g32077b693df8e3ed0424031a322df23
PR analyzer/93288 reports an ICE in a C++ testcase when calling a
constructor.
The issue is that when building the supergraph, we encounter the
cgraph edge to "__ct_comp ", the DECL_COMPLETE_CONSTRUCTOR_P, and
this node's DECL_STRUCT_FUNCTION has a NULL CFG, which the analyzer
reads through, leadi
Reproducing the ICE in PR analyzer/93375 required some kind of
analyzer diagnostic occurring after a call with fewer arguments
than required by the callee.
The testcase used __builtin_memcpy with a NULL argument for this.
On x86_64-pc-linux-gnu this happened to be already optimized into:
_4 = M
On Sun, 2020-02-09 at 12:55 -0800, Steve Kargl wrote:
> On Sun, Feb 09, 2020 at 09:15:46PM +0100, Toon Moene wrote:
> > On 2/6/20 9:01 PM, David Malcolm wrote:
> >
> > > PR analyzer/93405 reports an ICE when attempting to use
> > > -fanalyzer on
> > > c
On Sun, 2020-02-09 at 16:38 -0800, Steve Kargl wrote:
> On Sun, Feb 09, 2020 at 04:19:13PM -0500, David Malcolm wrote:
> > On Sun, 2020-02-09 at 12:55 -0800, Steve Kargl wrote:
> > > On Sun, Feb 09, 2020 at 09:15:46PM +0100, Toon Moene wrote:
> > > > On 2/6/2
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r10-6566-ge953f9588d4a7ea4183d14914f915329cc37941f.
gcc/analyzer/ChangeLog:
PR analyzer/93647
* diagnostic-manager.cc
(diagnostic_manager::prune_for_sm_diagnostic): Bulletproof against
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r10-6567-ge87deb37649cfe480217fc83c8d56fe925600f93.
gcc/analyzer/ChangeLog:
PR analyzer/93350
* region-model.cc (region_model::get_lvalue_1):
Handle BIT_FIELD_REF.
(make_region_for_ty
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r10-6568-geb031d4ba27b3fdc292f5a1092e66024f5ee239c.
gcc/analyzer/ChangeLog:
PR analyzer/93659
* analyzer.opt (-param=analyzer-max-recursion-depth=): Fix "tha"
-> "that" typo.
(Wanaly
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r10-6579-g5e17c1bdadbbd5606d869b1178ed3e653f931cda.
gcc/analyzer/ChangeLog:
PR analyzer/93657
* analyzer.opt (fdump-analyzer): Reword description.
(fdump-analyzer-stderr): Likewise.
---
gcc/
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r10-6580-gcd28b75921354c64fd4c8a1c238991e522abc38e.
gcc/analyzer/ChangeLog:
PR analyzer/93649
* constraint-manager.cc (constraint_manager::add_constraint): When
merging equivalence classes an
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r10-6581-ga0e4929b0461226722d6d08b1fdc2852b9100b75.
gcc/analyzer/ChangeLog:
PR analyzer/93669
* engine.cc (exploded_graph::dump_exploded_nodes): Handle missing
case of STATUS_WORKLIST in impl
PR analyzer/93374 reports an ICE within state_change::validate due to an
m_new_sid in a recorded state-change being out of range of the svalues
of the region_model of the new state.
During get_or_create_node we attempt to merge the new state with the
state of each of the existing enodes at the pro
101 - 200 of 5423 matches
Mail list logo
