https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104821
--- Comment #2 from David Malcolm ---
(In reply to David Malcolm from comment #1)
Copy&paste error:
result->m_b = malloc (sz_c);
should have been:
result->m_c = malloc (sz_c);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101983
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104854
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104860
Bug ID: 104860
Summary: RFE: -Wanalyzer-possible-null-argument and
-Wanalyzer-null-argument should respect
__attribute__((access, ...))
Product: gcc
Version: 12.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104793
--- Comment #1 from David Malcolm ---
See also PR analyzer/104860, which covers this for
-Wanalyzer-possible-null-argument and -Wanalyzer-null-argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104860
--- Comment #1 from David Malcolm ---
Questions posted to GCC list about this: "__attribute__ ((access, ...)) vs
__attribute__ ((nonnull))"
https://gcc.gnu.org/pipermail/gcc/2022-March/238389.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104793
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104863
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from David Malc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104863
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940
Bug ID: 104940
Summary: RFE: integrate analyzer with an SMT solver
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95000
David Malcolm changed:
What|Removed |Added
Depends on||104940
--- Comment #6 from David Malcolm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104943
Bug ID: 104943
Summary: Analyzer fails to purge state for local structs
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104954
Bug ID: 104954
Summary: Analyzer takes a very long time on Linux kernel
drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104954
David Malcolm changed:
What|Removed |Added
Depends on||104943
--- Comment #2 from David Malcol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104954
--- Comment #3 from David Malcolm ---
I'm also seeing states with dozens of bindings for touched regions for
__UNIQUE_ID_ddebugN for various N:
clusters within :: {, r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104954
--- Comment #4 from David Malcolm ---
Created attachment 52634
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52634&action=edit
Gzipped preprocessed source, unreduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104955
Bug ID: 104955
Summary: Analyzer slowdown with many diagnostics
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104954
David Malcolm changed:
What|Removed |Added
Depends on||104955
--- Comment #5 from David Malcol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104955
--- Comment #1 from David Malcolm ---
Also takes a long time with -Wno-analyzer-double-free; perhaps we ought to
reject saved_diagnostics that will ultimately not be emitted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104955
--- Comment #2 from David Malcolm ---
I suspect that this issue is due to building a feasible_graph per saved
diagnostic, thus leading to an O(N^2) where as the function gets bigger, each
individual diagnostic requires more work. Perhaps fixabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104854
--- Comment #9 from David Malcolm ---
(In reply to Siddhesh Poyarekar from comment #8)
> (In reply to Martin Sebor from comment #7)
> > Moving warnings into the analyzer and scaling it up to be able to run by
> > default, during development, sou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104979
Bug ID: 104979
Summary: False positive from -Wanalyzer-malloc-leak with cast
within boxed pointer
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104943
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104954
Bug 104954 depends on bug 104943, which changed state.
Bug 104943 Summary: Analyzer fails to purge state for local structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104943
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104997
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105022
Bug ID: 105022
Summary: -Wanalyzer-tainted-allocation-size doesn't warn for
custom allocators marked with "malloc" attribute
Product: gcc
Version: 12.0
Status: UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105017
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2022-03-22
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104997
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105017
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104979
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104954
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104954
--- Comment #9 from David Malcolm ---
(In reply to Richard Biener from comment #1)
> Does not enabling sanitizer improve things?
Removing the sanitizer options speeds up the non-analyzer part of the build,
reducing the overall wallclock time of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105022
--- Comment #1 from David Malcolm ---
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-malloc-function-attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105022
David Malcolm changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104860
David Malcolm changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95188
David Malcolm changed:
What|Removed |Added
Summary|analyzer-unsafe-call-within |State explosion on
|-s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105057
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2022-03-25
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308
David Malcolm changed:
What|Removed |Added
Keywords||patch
--- Comment #5 from David Malcolm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105057
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308
David Malcolm changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105074
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from David Malc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105087
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2022-03-28
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105087
--- Comment #2 from David Malcolm ---
#include "analyzer-decls.h"
extern void *inner_alloc (void);
void * __attribute__((noinline))
outer_alloc (void)
{
return inner_alloc ();
}
void test_1 (void)
{
void *p, *q;
p = outer_alloc ();
q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105087
--- Comment #3 from David Malcolm ---
#include "analyzer-decls.h"
extern void inner_alloc (void **);
void * __attribute__((noinline))
outer_alloc (void)
{
void *result;
inner_alloc (&result);
return result;
}
void test_1 (void)
{
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105087
--- Comment #4 from David Malcolm ---
Am testing a fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105074
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105087
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105092
David Malcolm changed:
What|Removed |Added
CC||jakub at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105085
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105102
Bug ID: 105102
Summary: RFE: analyzer handling for asprintf and vasprintf
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105103
Bug ID: 105103
Summary: RFE: detect bogus use of varargs in analyzer
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105085
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105112
Bug ID: 105112
Summary: Speed up -fanalyzer on big-code.c
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105112
--- Comment #1 from David Malcolm ---
Example state (picked at random from -fdump-analyzer-exploded-nodes-2 output):
EN 113734:
preds: EN: 113733
succs: EN: 113735
callstring: []
before (SN: 12511 stmt: 0):
if (j_8254 <= 8191)
31 | for (j =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105112
--- Comment #2 from David Malcolm ---
FWIW, "perf report" shows that these are the top items in the profile:
8.72% libc-2.31.so [.] _int_malloc
6.68% libc-2.31.so [.] _int_free
2.91% cc1 [.] ana::binding_map::binding_map
2.76% l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105113
David Malcolm changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105074
David Malcolm changed:
What|Removed |Added
CC||bero at lindev dot ch
--- Comment #6 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105112
--- Comment #3 from David Malcolm ---
Possible simplification: don't try to model floating-point operations e.g. any
binop on a floating point value has unknown_svalue as the result, so that
complicated floating-point computations can be quickly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102824
--- Comment #2 from David Malcolm ---
make pdf is looking for the images in:
gcc/jit/docs/_build/texinfo/libgccjit-figures
but they're in the source tree in:
gcc/jit/docs/_build/texinfo
I just tried:
git mv gcc/jit/docs/_build/texinfo/*.p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104071
David Malcolm changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104073
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104293
David Malcolm changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102824
--- Comment #4 from David Malcolm ---
As noted in https://gcc.gnu.org/pipermail/gcc-patches/2022-April/592889.html
the above patch seems to fix "make jit.pdf", but doesn't fix "make jit.dvi"; it
seems to be looking for .eps files for the images.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105190
Bug ID: 105190
Summary: False positive from -Wanalyzer-malloc-leak with
symbolic writes to structs
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102308
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102208
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102308
--- Comment #2 from David Malcolm ---
I typoed this bug's ID 102308 as 102208 in the commit message; so the message
went to the wrong bug; here's a copy-and-paste of the commit notification that
went there:
The master branch has been updated by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102308
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103892
--- Comment #2 from David Malcolm ---
Still affects trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103892
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105103
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105252
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from David Malc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105264
--- Comment #1 from David Malcolm ---
Thanks for filing this bug. I suspect the analyzer is getting confused about
the loop index on successive iterations (and state relating to this).
Please can you:
(a) specify exactly which compilation flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95325
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104071
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104072
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104073
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104293
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308
--- Comment #9 from David Malcolm ---
(In reply to Kamil Dudka from comment #8)
> As spotted by Vincent Mihalkovic, the fix seems to be incomplete. If we run
> gcc-12.0.1-0.14.fc37.x86_64 on the following test-case, some diagnostic
> messages a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105252
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|WAITING
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105264
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105264
--- Comment #6 from David Malcolm ---
There are some fiddly issues where the analyzer fails to figure out that ptr +
i and &ptr[i] refer to the same memory, for certain symbolic values of i.
I'm testing a partial fix for GCC 12, which at least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105273
--- Comment #4 from David Malcolm ---
Thanks for filing this bug.
IIRC in the initial GCC 10 release of the analyzer, it didn't directly explore
within static functions, and instead only explored them via callsites. I
tweaked the policy for th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105264
--- Comment #8 from David Malcolm ---
The above patch hopefully fixes the false positive you're seeing, but as noted,
there are some deeper issues that it doesn't fix; keeping this bug open.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105287
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105285
--- Comment #3 from David Malcolm ---
Thanks for filing this bug; I can reproduce it with the initial attachment;
it's unclear to me yet what's going on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105365
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from David Malc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105366
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from David Malc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105382
Bug ID: 105382
Summary: Support for coroutines in -fanalyzer
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105287
--- Comment #5 from David Malcolm ---
Thanks. FWIW I've filed PR 105382 to track the various other issues I'm seeing
with -fanalyzer with coroutines (though given that we don't properly support
C++ yet, that's relatively low priority for me).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105365
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105366
David Malcolm changed:
What|Removed |Added
Summary|[11/12 Regression] ICE: in |[11 Regression] ICE: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105382
--- Comment #1 from David Malcolm ---
Looks like the analyzer is assuming that all of the different
_Coro_resume_index values are possible at each entry to f(f()::_Z1fv.Frame*),
but AIUI that value is expressing which basic block the coroutine i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105285
--- Comment #4 from David Malcolm ---
Created attachment 52892
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52892&action=edit
Partially reduced reproducer
I reduced the reproducer and am attaching it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105285
--- Comment #5 from David Malcolm ---
I've been attempting to debug this.
I think that there is a bug in both (a) the analyzer, and, possibly (b) in the
software under test (git).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105285
--- Comment #6 from David Malcolm ---
For (a):
If I'm reading this right:
reader_init_block_reader has:
struct reftable_block block = {((void *)0)};
reader_init_block_reader checks for (next_off >= r->size) and bails out,
otherwise, block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105285
--- Comment #7 from David Malcolm ---
For (b), I'm not convinced git's code is totally correct here.
The early-reject case in reader_get_block returns 0:
if (off >= r->size)
return 0;
but at the caller, the condition is < 0:
err = re
401 - 500 of 1425 matches
Mail list logo
