[Bug analyzer/104821] RFE: consolidate analyzer leak diagnostics by considering indirect vs direct leaks
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);
[Bug analyzer/101983] analyzer leak false positives building singly linked list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101983 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from David Malcolm --- As noted above, these appear to be true positives. The above patch fixes the issue with detection of "main"; the remaining issue is the use of , which I'm tracking in PR analyzer/99771. Marking this as resolved.
[Bug middle-end/104854] [11/12 Regression] -Wstringop-overread should not warn for strnlen and strndup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104854
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment #1 from David Malcolm ---
Compiler Explorer link for the above (with -fanalyzer -Wall -Wstringop-overread
-O2; -O2 seems to be needed to trigger it):
https://godbolt.org/z/jcEdxfEv9
In function 'foo',
inlined from 'bar' at :12:10:
:6:10: warning: '__builtin_strndup' specified bound 20 exceeds source
size 5 [-Wstringop-overread]
6 | return __builtin_strndup ("test", size);
| ^~~~
[Bug analyzer/104860] New: RFE: -Wanalyzer-possible-null-argument and -Wanalyzer-null-argument should respect __attribute__((access, ...))
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.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Similar to PR analyzer/104793, but relating to NULL/possibly NULL pointers (and
affects reads as well as writes):
typedef __SIZE_TYPE__ size_t;
int getrandom (void *__buffer, size_t __length,
unsigned int __flags)
__attribute__ ((access (__write_only__, 1, 2)));
#define GRND_RANDOM 0x02
void test (int flag)
{
char *buf = __builtin_malloc (1024);
if (getrandom(buf, 16, GRND_RANDOM))
__builtin_printf("%s\n", buf);
__builtin_free (buf);
}
The call to malloc could fail, but we don't yet complain about the
possibly-NULL param to getrandom, that's marked with __attribute__ ((access,
...))
[Bug analyzer/104793] -Wanalyzer-write-to-const and -Wanalyzer-write-to-string-literal should respect attribute((access, write)
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.
[Bug analyzer/104860] RFE: -Wanalyzer-possible-null-argument and -Wanalyzer-null-argument should respect __attribute__((access, ...))
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
[Bug analyzer/104793] -Wanalyzer-write-to-const and -Wanalyzer-write-to-string-literal should respect attribute((access, write)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104793 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from David Malcolm --- Should be fixed by the above commits.
[Bug analyzer/104863] [12 regression] ICE in operator[], at vec.h:889 since r12-6782-gc4b8f3730a800251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104863 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from David Malcolm --- Thanks for filing this; I'm testing a fix.
[Bug analyzer/104863] [12 regression] ICE in operator[], at vec.h:889 since r12-6782-gc4b8f3730a800251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104863 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from David Malcolm --- Should be fixed by the above commit.
[Bug analyzer/104940] New: RFE: integrate analyzer with an SMT solver
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: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
-fanalyzer currently has its own constraint_manager class for tracking the
constraints that hold at a point on an execution path, but it only verifies
some of the interactions between constraints and symbolic values, which can
lead to false positives.
For example, consider:
#include "analyzer-decls.h"
void test (int x, int y)
{
if (y == 3)
if (2 * x == y)
__analyzer_dump_path ();
}
The current constraint_manager code has no knowledge that (2 * x == y) is
impossible for integers, and erroneously outputs:
../../src/gcc/testsuite/gcc.dg/analyzer/t.c: In function ‘test’:
../../src/gcc/testsuite/gcc.dg/analyzer/t.c:7:7: note: path
7 | __analyzer_dump_path ();
| ^~~
‘test’: events 1-5
|
|5 | if (y == 3)
| | ^
| | |
| | (1) following ‘true’ branch (when ‘y == 3’)...
|6 | if (2 * x == y)
| |~~
| || |
| || (2) ...to here
| |(3) following ‘true’ branch...
|7 | __analyzer_dump_path ();
| | ~~~
| | |
| | (4) ...to here
| | (5) here
|
Idea: get out of the business of tracking constraints by instead calling out to
an SMT solver.
I have a work-in-progress prototype of the analyzer which can call express
constraints as an SMT-LIB2 script, and call out to an external z3 binary.
Presumably we'd want an option to select between different constraint-tracking
implementations, to avoid depending on z3 (or other smt solvers). Might be
faster to link it in-process, but let's cross that bridge when we come to it.
I'm filing this bug as a tracker bug for other constraint-tracking bugs.
[Bug analyzer/95000] -fanalyzer confused by switch on non-int type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95000 David Malcolm changed: What|Removed |Added Depends on||104940 --- Comment #6 from David Malcolm --- Still happens on trunk; adding to SMT tracker. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940 [Bug 104940] RFE: integrate analyzer with an SMT solver
[Bug analyzer/104943] New: Analyzer fails to purge state for local structs
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: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
State purging only happens for SSA names, and locals of struct type aren't SSA
names.
Given e.g.:
struct boxed {
int value;
};
extern struct boxed boxed_add (struct boxed a, struct boxed b);
extern struct boxed boxed_mul (struct boxed a, struct boxed b);
struct boxed
test (struct boxed a, struct boxed b)
{
struct boxed result = boxed_add (boxed_mul (a, a),
boxed_mul (b, b));
return result;
}
without optimization we have this gimple:
struct boxed test (struct boxed a, struct boxed b)
{
struct boxed result;
struct boxed D.1994;
struct boxed D.1993;
struct boxed D.1992;
:
D.1992 = boxed_mul (b, b);
D.1993 = boxed_mul (a, a);
result = boxed_add (D.1993, D.1992);
D.1994 = result;
result ={v} {CLOBBER(eol)};
:
:
return D.1994;
}
and this final exploded node:
EN 11:
preds: EN: 10
succs:
callstring: []
after SN: 3
rmodel:
stack depth: 1
frame (index 0): frame: ‘test’@1
clusters within frame: ‘test’@1
cluster for: : CONJURED(D.1992 = boxed_mul (b, b);, )
cluster for: : CONJURED(D.1993 = boxed_mul (a, a);, )
cluster for: : CONJURED(result = boxed_add (D.1993, D.1992);,
result)
cluster for: : CONJURED(result = boxed_add (D.1993, D.1992);,
result)
m_called_unknown_fn: TRUE
constraint_manager:
equiv classes:
constraints:
where the various are the values of the local temporaries of struct
type, which ought to be purged; they don't matter anymore.
Seen on linux kernel: drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c which
amongst other things has:
struct bw_fixed {
int64_t value;
};
with numerous calls to manipulate values; the states get bloated with bindings
for temporaries that persist far longer than they are needed.
[Bug analyzer/104954] New: Analyzer takes a very long time on Linux kernel drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
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 Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- According to my notes, attempting to build a Linux kernel with -fanalyzer, I found that building: drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c was taking over 15 hours; I think this was with a debug build of cc1. On testing this with trunk this week, I saw it take about 31 minutes on a debug build, and about 4 minutes on a release build. Am attaching preprocessed source. Compilation flags in use the 4 minute build (with release build of cc1): ./xgcc -B. -fanalyzer -S ../../src/dce_calcs.i -nostdinc -fmacro-prefix-map=./= -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu89 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -fno-jump-tables -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 -fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector-strong -Wimplicit-fallthrough=5 -Wno-unused-but-set-variable -Wno-unused-const-variable -fno-stack-clash-protection -g -pg -mrecord-mcount -mfentry -DCC_USING_FENTRY -fno-inline-functions-called-once -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds -Wno-array-bounds -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -fno-strict-overflow -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wno-packed-not-aligned -fanalyzer -Wno-analyzer-null-dereference -Wno-analyzer-use-of-uninitialized-value -Wno-array-bounds -Wno-analyzer-null-argument -Wno-analyzer-shift-count-overflow -Wno-analyzer-use-of-pointer-in-stale-stack-frame -Wno-analyzer-shift-count-negative -Wno-analyzer-write-to-const -Wno-use-after-free -fsanitize=kernel-address -fasan-shadow-offset=0xdc00 --param asan-globals=1 --param asan-instrumentation-with-call-threshold=1 --param asan-instrument-allocas=1 --param asan-stack=1 (i.e. with various -Wno-analyzer-* flags; perhaps re-enabling these will trigger the more extreme multihour slowdown)
[Bug analyzer/104954] Analyzer takes a very long time on Linux kernel drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104954
David Malcolm changed:
What|Removed |Added
Depends on||104943
--- Comment #2 from David Malcolm ---
Part of the slowdown may relate to PR analyzer/104943: "perf" shows lots of
time spent traversing state objects, and I'm seeing huge numbers of temporaries
that aren't getting purged. The state bindings show dozens of "region:
{, value: UNKNOWN(struct bw_fixed)}") presumably relating to struct
temporaries.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104943
[Bug 104943] Analyzer fails to purge state for local structs
[Bug analyzer/104954] Analyzer takes a very long time on Linux kernel drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
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 :: {, region: {__UNIQUE_ID_ddebug277, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug277) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug278, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug278) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug279, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug279) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug280, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug280) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug281, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug281) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug282, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug282) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug283, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug283) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug284, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug284) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug285, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug285) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug286, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug286) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug287, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug287) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug288, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug288) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug289, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug289) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug290, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug290) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug291, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug291) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug292, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug292) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug293, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug293) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug294, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug294) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug295, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug295) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug296, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug296) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug297, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug297) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug298, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug298) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug299, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug299) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug300, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug300) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug301, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug301) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug302, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug302) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug303, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug303) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug304, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug304) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug305, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug305) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug306, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug306) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug307, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (
where these seem to be coming from macro expansions of debug logging like this:
static void print_bw_calcs_dceip(struct dc_context *ctx,
[Bug analyzer/104954] Analyzer takes a very long time on Linux kernel drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
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
[Bug analyzer/104955] New: Analyzer slowdown with many diagnostics
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
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
The following artificial testcase for -fanalyzer seems to take at least several
minutes; perhaps much more:
#define DOUBLE_FREE() \
do { \
void *p = __builtin_malloc (1024); \
__builtin_free (p); \
__builtin_free (p); \
} while (0)
#define DOUBLE_FREE_x_10() \
do { \
DOUBLE_FREE(); \
DOUBLE_FREE(); \
DOUBLE_FREE(); \
DOUBLE_FREE(); \
DOUBLE_FREE(); \
DOUBLE_FREE(); \
DOUBLE_FREE(); \
DOUBLE_FREE(); \
DOUBLE_FREE(); \
DOUBLE_FREE(); \
} while (0)
#define DOUBLE_FREE_x_100() \
do { \
DOUBLE_FREE_x_10(); \
DOUBLE_FREE_x_10(); \
DOUBLE_FREE_x_10(); \
DOUBLE_FREE_x_10(); \
DOUBLE_FREE_x_10(); \
DOUBLE_FREE_x_10(); \
DOUBLE_FREE_x_10(); \
DOUBLE_FREE_x_10(); \
DOUBLE_FREE_x_10(); \
DOUBLE_FREE_x_10(); \
} while (0)
#define DOUBLE_FREE_x_1000()\
do { \
DOUBLE_FREE_x_100();\
DOUBLE_FREE_x_100();\
DOUBLE_FREE_x_100();\
DOUBLE_FREE_x_100();\
DOUBLE_FREE_x_100();\
DOUBLE_FREE_x_100();\
DOUBLE_FREE_x_100();\
DOUBLE_FREE_x_100();\
DOUBLE_FREE_x_100();\
DOUBLE_FREE_x_100();\
} while (0)
void test_1 (void)
{
DOUBLE_FREE_x_1000 ();
}
Breaking into it shows that it seems to be spending the bulk of its time
exploring paths to determine if they are feasible (despite the fact that
there's no control flow at all):
(gdb) bt
#0 0x00f22750 in hash_table, ana::binding_cluster*> >::hash_entry, false,
xcallocator>::find_slot_with_hash (this=this@entry=0x7fffc768,
comparable=@0x7fffc5f8: 0x292b5c0, hash=5396152,
insert=insert@entry=INSERT) at ../../src/gcc/hash-traits.h:186
#1 0x00f1b976 in hash_map,
ana::binding_cluster*> >::put (v=, k=@0x7fffc5f8: 0x292b5c0,
this=0x7fffc768) at ../../src/gcc/hash-traits.h:162
#2 ana::store::store (this=this@entry=0x7fffc768, other=...) at
../../src/gcc/analyzer/store.cc:2046
#3 0x00eeaecf in ana::region_model::region_model
(this=this@entry=0x7fffc760, other=...) at
../../src/gcc/analyzer/region-model.cc:260
#4 0x00eccf71 in ana::feasibility_state::feasibility_state
(this=0x7fffc760, other=...) at ../../src/gcc/analyzer/engine.cc:4478
#5 0x018a51f0 in ana::epath_finder::process_worklist_item
(this=, worklist=0x7fffc950, tg=..., fg=0x7fffc8a0,
target_enode=0x2bdcf60, diag_idx=305, out_best_path=0x7fffc858) at
../../src/gcc/analyzer/feasible-graph.h:96
#6 0x018a603c in ana::epath_finder::explore_feasible_paths
(this=0x7fffcb90, target_enode=0x2bdcf60, desc=0x1a64f09 "double_free",
diag_idx=305) at ../../src/gcc/analyzer/diagnostic-manager.cc:414
#7 0x018a6787 in ana::saved_diagnostic::calc_best_epath
(this=0x2bddbf0, pf=0x7fffcb90)
at ../../src/gcc/analyzer/diagnostic-manager.cc:736
#8 0x018aaece in ana::dedupe_winners::add
(this=this@entry=0x7fffcba0, logger=0x0, pf=pf@entry=0x7fffcb90,
sd=0x2bddbf0)
at ../../src/gcc/analyzer/diagnostic-manager.cc:1065
#9 0x018a7ece in ana::diagnostic_manager::emit_saved_diagnostics
(this=0x7fffcea0, eg=...)
at ../../src/gcc/analyzer/analyzer-logging.h:150
#10 0x00ed79ab in ana::impl_run_checkers (logger=logger@entry=0x0) at
../../src/gcc/analyzer/exploded-graph.h:857
#11 0x00ed8804 in ana::run_checkers () at
../../src/gcc/analyzer/analyzer-logging.h:150
[Bug analyzer/104954] Analyzer takes a very long time on Linux kernel drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104954 David Malcolm changed: What|Removed |Added Depends on||104955 --- Comment #5 from David Malcolm --- (In reply to David Malcolm from comment #0) > (i.e. with various -Wno-analyzer-* flags; perhaps re-enabling these will > trigger the more extreme multihour slowdown) Perhaps this related to PR analyzer/104955 also? But if so, I think it's still checking feasibility even before rejecting the diagnostic due to the -Wno-analyzer-* option flag within diagnostic.cc. If that's the case we could reject such diagnostics earlier. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104955 [Bug 104955] Analyzer slowdown with many diagnostics
[Bug analyzer/104955] Analyzer slowdown with many diagnostics
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.
[Bug analyzer/104955] Analyzer slowdown with many diagnostics
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 fixable by amortizing the work, by sharing one feasible_graph for all diagnostics in the diagnostic_manager.
[Bug middle-end/104854] -Wstringop-overread should not warn for strnlen, strndup and strncmp
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, sounds like a good long-term plan. Until that > > That's not quite what I'm suggesting here. I'm not a 100% convinced that > those are the right heuristics at all; the size argument for strnlen, > strndup and strncmp does not intend to describe the size of the passed > strings. It is only recommended security practice that the *n* variant > functions be used instead of their unconstrained relatives to mitigate > overflows. In fact in more common cases the size argument (especially in > case of strnlen and strncmp) may describe a completely different buffer or > some other application-specific property. > > This is different from the -Wformat-overflow, where there is a clear > relationship between buffer, the format string and the string representation > of input numbers and we're only tweaking is the optimism level of the > warnings. So it is not just a question of levels of verosity/paranoia. > > In that context, using size to describe the underlying buffer of the source > only makes sense only for a subset of uses, making this heuristic quite > noisy. So what I'm actually saying is: the heuristic is too noisy but if we > insist on keeping it, it makes sense as an analyzer warning where the user > *chooses* to look for pessimistic scenarios and is more tolerant of noisy > heuristics. Right now -fanalyzer enables all of the various -Wanalyzer-* warnings by default [1], and in theory all of them only emit a diagnostic for the case when the analyzer "thinks" there's a definite problem. There may be bugs in the analyzer, of course. I'm a bit wary of the above sentence, as it suggests that the analyzer should be the place to put noisy diagnostics. Looking at the GCC UX guidelines: https://gcc.gnu.org/onlinedocs/gccint/Guidelines-for-Diagnostics.html note "The user’s attention is important": if a diagnostic is too noisy, the user will either turn it off, or stop paying attention. The distinction I've been making for -fanalyzer is that -fanalyzer enables a more expensive (path-based) analysis of the user's code, and will slow down the user's compile-time, with various warnings tied to that, i.e. I've been messaging it primarily as a compile-time tradeoff for extra warnings that otherwise would be too slow to implement, rather than a signal:noise ratio tradeoff. -fanalyzer can generate false positives, but I've been trying to drive that down via bugfixes (it's also relatively new code) [1] apart from -Wanalyzer-too-complex, but that's more of an implementation detail. > > > happens, rather than gratuitously removing warnings that we've added over > > the years, just because they fall short of the ideal 100% efficacy (as has > > been known and documented), making them easier to control seems like a > > better approach. > > It's not just a matter of efficacy here IMO. The heuristic for strnlen, > strncmp and strndup overreads is too loose for it to be taken seriously.
[Bug analyzer/104979] New: False positive from -Wanalyzer-malloc-leak with cast within boxed pointer
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: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Given:
#include
typedef struct boxed_ptr { void *value; } boxed_ptr;
boxed_ptr
boxed_malloc (size_t sz)
{
boxed_ptr result;
result.value = malloc (sz);
return result;
}
boxed_ptr
boxed_free (boxed_ptr ptr)
{
free (ptr.value);
}
const boxed_ptr boxed_null = {NULL};
struct link
{
boxed_ptr m_ptr;
};
boxed_ptr test_29 (void)
{
boxed_ptr res = boxed_malloc (sizeof (struct link));
if (!res.value)
return boxed_null;
((struct link *)res.value)->m_ptr = boxed_malloc (sizeof (struct link));
return res;
}
-fanalyzer emits (incorrectly, I think):
: In function 'boxed_malloc':
:10:10: warning: leak of '.value' [CWE-401]
[-Wanalyzer-malloc-leak]
10 | return result;
| ^~
'test_29': events 1-4
|
| 26 | boxed_ptr test_29 (void)
| | ^~~
| | |
| | (1) entry to 'test_29'
|..
| 29 | if (!res.value)
| | ~
| | |
| | (2) following 'false' branch...
| 30 | return boxed_null;
| 31 | ((struct link *)res.value)->m_ptr = boxed_malloc (sizeof (struct
link));
| | ~
~~~
| | ||
| | |(4) calling 'boxed_malloc'
from 'test_29'
| | (3) ...to here
|
+--> 'boxed_malloc': events 5-7
|
|6 | boxed_malloc (size_t sz)
| | ^~~~
| | |
| | (5) entry to 'boxed_malloc'
|..
|9 | result.value = malloc (sz);
| | ~~~
| | |
| | (6) allocated here
| 10 | return result;
| | ~~
| | |
| | (7) '.value' leaks here; was
allocated at (6)
|
https://godbolt.org/z/1e9n8dnvM
[Bug analyzer/104943] Analyzer fails to purge state for local structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104943 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above commit.
[Bug analyzer/104954] Analyzer takes a very long time on Linux kernel drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
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 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug analyzer/104997] ICE in add_note, at analyzer/diagnostic-manager.cc:946
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104997 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-03-21 --- Comment #1 from David Malcolm --- Thanks for filing this bug report; confirmed.
[Bug analyzer/105022] New: -Wanalyzer-tainted-allocation-size doesn't warn for custom allocators marked with "malloc" attribute
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: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Given:
typedef __SIZE_TYPE__ size_t;
void *custom_alloc (size_t sz) __attribute__((malloc (__builtin_free)));
void * __attribute__ ((tainted_args))
test_ (size_t sz)
{
return custom_alloc (sz);
}
and compiling with:
-fanalyzer -fanalyzer-checker=taint
there is no output. Ideally the analyzer should complain with
-Wanalyzer-tainted-allocation-size that "sz" is attacker-controlled.
https://godbolt.org/z/oohh39Gjj
[Bug analyzer/105017] [12 Regression] gcc/analyzer/sm-taint.cc:631:21: warning: private field 'm_mem_space' is not used [-Wunused-private-field]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105017 David Malcolm changed: What|Removed |Added Last reconfirmed||2022-03-22 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug analyzer/104997] [12 Regression] ICE in add_note, at analyzer/diagnostic-manager.cc:946 since r12-7677-g7fd6e36ea9aa8575
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104997 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from David Malcolm --- Should be fixed by the above commit.
[Bug analyzer/105017] [12 Regression] gcc/analyzer/sm-taint.cc:631:21: warning: private field 'm_mem_space' is not used [-Wunused-private-field]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105017 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- I'm assuming that this was a clang warning, and that this is fixed by the above commit; please reopen if it's still affected.
[Bug analyzer/104979] False positive from -Wanalyzer-malloc-leak with cast within boxed pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104979 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from David Malcolm --- Should be fixed by the above commit.
[Bug analyzer/104954] Analyzer takes a very long time on Linux kernel drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104954 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #8 from David Malcolm --- At this point, the analyzer is taking less than half of the wallclock time of cc1 on this file, so I'm declaring success.
[Bug analyzer/104954] Analyzer takes a very long time on Linux kernel drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
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 cc1 from about 36s to 21s; the -fanalyzer part of that remains steady at about 16s. Without -fanalyzer, cc1 wallclock is: with sanitizer:~18s without sanitizer: ~5s
[Bug analyzer/105022] -Wanalyzer-tainted-allocation-size doesn't warn for custom allocators marked with "malloc" attribute
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
[Bug analyzer/105022] -Wanalyzer-tainted-allocation-size doesn't warn for custom allocators marked with "malloc" attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105022 David Malcolm changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #2 from David Malcolm --- There isn't currently a way to express size argument(s) to the "malloc" attribute. Perhaps we could have a heuristic where if we see a single size_t argument passed to such a function we assume it's the size - but none of the examples in the docs work that way. There are also cases analogous to calloc which take a pair of numeric values. Resolving this one as WONTFIX (in the absence of a way to express size params for an allocation).
[Bug analyzer/104860] RFE: -Wanalyzer-possible-null-argument and -Wanalyzer-null-argument should respect __attribute__((access, ...))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104860 David Malcolm changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from David Malcolm --- The consensus in that discussion is that "access" and "nonnull" are separate concepts, and thus the user needs to provide both if they mean both. Closing this out as INVALID.
[Bug analyzer/95188] State explosion on bzip2-1.0.8/bzip2.c hides -Wanalyzer-unsafe-call-within-signal-handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95188 David Malcolm changed: What|Removed |Added Summary|analyzer-unsafe-call-within |State explosion on |-signal-handler shows wrong |bzip2-1.0.8/bzip2.c hides |statement for signal|-Wanalyzer-unsafe-call-with |registration event |in-signal-handler --- Comment #14 from David Malcolm --- Comment #9 noted that the original issue here (the wrong location) was fixed, but the remaining issues are to do with state explosions. I tested with today's trunk, and the state explosions still happen (and, for me mask the signal warning, unless I pass e.g. --param=analyzer-bb-explosion-factor=50 Updating subject to reflect that (rather than opening a new bug, to keep the conversation in one place)
[Bug analyzer/105057] [12 Regression] ICE: in get_or_create_cluster, at analyzer/store.cc:2658 with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105057 David Malcolm changed: What|Removed |Added Last reconfirmed||2022-03-25 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Thanks for filing this bug. Confirmed; looks like I introduced this in r12-7809-g5f6197d7c197f9d2b7fb2e1a19dac39a023755e8; I'm working on a fix.
[Bug analyzer/104308] no location info provided for [-Wanalyzer-use-of-uninitialized-value] warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308 David Malcolm changed: What|Removed |Added Keywords||patch --- Comment #5 from David Malcolm --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592331.html
[Bug analyzer/104308] no location info provided for [-Wanalyzer-use-of-uninitialized-value] warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308 David Malcolm changed: What|Removed |Added Status|ASSIGNED|WAITING
[Bug analyzer/105057] [12 Regression] ICE: in get_or_create_cluster, at analyzer/store.cc:2658 with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105057 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above commit. Sorry for the breakage, and thanks again for filing this bug.
[Bug analyzer/104308] no location info provided for [-Wanalyzer-use-of-uninitialized-value] warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308 David Malcolm changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #7 from David Malcolm --- Should be fixed by the above patch.
[Bug analyzer/105074] [12 Regression] -fanalyzer ICEs on gnutls-3.7.3: cgraph_node::get_edge(gimple*) SIGSEGV since r12-7809-g5f6197d7c197f9d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105074 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from David Malcolm --- Thanks for filing this bug report; happens at -O2 and above. Working on a fix now.
[Bug analyzer/105087] fanalyzer double free false positive with vasprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105087 David Malcolm changed: What|Removed |Added Last reconfirmed||2022-03-28 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Thanks for filing this bug; confirmed. FWIW it's treating all three of buf, bar, and baz as having the same conjured_svalue (and, surprisingly, from the __builtin_va_end call due to it treating args as having escaped at the vasprintf call). EN 386: preds: EN: 378 succs: EN: 396 callstring: [(SN: 17 -> SN: 2 in main)] before (SN: 15 stmt: 1): free (bar_15); 48 | free(bar); | ^ rmodel: stack depth: 2 frame (index 1): frame: ‘run_test’@2 frame (index 0): frame: ‘main’@1 clusters within root region cluster for: (*INIT_VAL(argv)): CONJURED(__builtin_va_end (&args);, (*INIT_VAL(argv))) (ESCAPED) (TOUCHED) clusters within frame: ‘main’@1 cluster for: _3: CONJURED(_3 = run_test ();, _3) clusters within frame: ‘run_test’@2 cluster for: bar_15: CONJURED(__builtin_va_end (&args);, resultp) cluster for: baz_19: CONJURED(__builtin_va_end (&args);, resultp) m_called_unknown_fn: TRUE constraint_manager: equiv classes: constraints: malloc: 0x4f72180: CONJURED(__builtin_va_end (&args);, resultp): freed (‘bar_15’) Looks like I need to "teach" -fanalyzer about vasprintf (and va_start/end, for that matter)
[Bug analyzer/105087] fanalyzer double free false positive with vasprintf
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 = outer_alloc ();
__analyzer_eval (p == q); // analyzer correctly thinks this is unknown
}
[Bug analyzer/105087] fanalyzer double free false positive with vasprintf
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 *p, *q;
p = outer_alloc ();
q = outer_alloc ();
__analyzer_eval (p == q); // bug: analyzer thinks this is true
}
[Bug analyzer/105087] fanalyzer double free false positive with vasprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105087 --- Comment #4 from David Malcolm --- Am testing a fix.
[Bug analyzer/105074] [12 Regression] -fanalyzer ICEs on gnutls-3.7.3: cgraph_node::get_edge(gimple*) SIGSEGV since r12-7809-g5f6197d7c197f9d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105074 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from David Malcolm --- Should be fixed by the above commit.
[Bug analyzer/105087] fanalyzer double free false positive with vasprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105087 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from David Malcolm --- Should be fixed on trunk for GCC 12 by the above commit. Please let me know if you run into other false positives building parted with -fanalyzer.
[Bug analyzer/105092] ICE with local with NULL DECL_CONTEXT on templatized OpenMP iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105092
David Malcolm changed:
What|Removed |Added
CC||jakub at redhat dot com,
||jason at redhat dot com
Summary|ICE in |ICE with local with NULL
|get_region_for_local, at|DECL_CONTEXT on templatized
|analyzer/region.cc:874 |OpenMP iterator
Status|NEW |WAITING
--- Comment #2 from David Malcolm ---
The root cause of PR analyzer/104979 involved looking up a local variable in
the wrong stack frame, so in r12-7790-g4cebae0924248beb I added assertions to
the analyzer to ensure that when accessing a local variable in a frame, the
frame is for the correct function.
This new assertion is failing on the templatizing OpenMP reproducer in
ana::frame_region::get_region_for_local:
869 case SSA_NAME:
870 {
871 if (tree var = SSA_NAME_VAR (expr))
872 {
873 if (DECL_P (var))
874 gcc_assert (DECL_CONTEXT (var) == m_fun->decl);
875 }
on this gimple stmt:
i_11 = 0;
The SSA name's underlying var_decl "i" has NULL for its DECL_CONTEXT, despite
appearing to be a local variable.
"i" is created here:
(gdb) bt
#0 copy_node (node=) at ../../src/gcc/tree.cc:1358
#1 0x00bf64a3 in copy_decl (decl=) at
../../src/gcc/cp/lex.cc:1027
#2 0x00d87d5c in tsubst_decl (t=,
args=, complain=3) at ../../src/gcc/cp/pt.cc:14912
#3 0x00d9462f in tsubst_omp_clause_decl (decl=, args=, complain=3,
in_decl=,
iterator_cache=0x7fffcc10) at ../../src/gcc/cp/pt.cc:17540
#4 0x00d9509d in tsubst_omp_clauses (clauses=, ort=C_ORT_OMP, args=, complain=3,
in_decl=) at
../../src/gcc/cp/pt.cc:17643
#5 0x00d9eec5 in tsubst_expr (t=,
args=, complain=3,
in_decl=,
integral_constant_expression_p=false) at ../../src/gcc/cp/pt.cc:18974
#6 0x00d9d132 in tsubst_expr (t=,
args=, complain=3,
in_decl=,
integral_constant_expression_p=false) at ../../src/gcc/cp/pt.cc:18761
#7 0x00d99d5c in tsubst_expr (t=,
args=, complain=3,
in_decl=,
integral_constant_expression_p=false) at ../../src/gcc/cp/pt.cc:18404
#8 0x00d9d132 in tsubst_expr (t=,
args=, complain=3,
in_decl=,
integral_constant_expression_p=false) at ../../src/gcc/cp/pt.cc:18761
#9 0x00dc340d in instantiate_body (pattern=, args=,
d=, nested_p=false) at
../../src/gcc/cp/pt.cc:26338
#10 0x00dc4fcf in instantiate_decl (d=, defer_ok=false, expl_inst_class_mem_p=false)
at ../../src/gcc/cp/pt.cc:26630
#11 0x00dc53bb in instantiate_pending_templates (retries=0) at
../../src/gcc/cp/pt.cc:26709
#12 0x00ba2148 in c_parse_final_cleanups () at
../../src/gcc/cp/decl2.cc:5092
#13 0x00f31e7a in c_common_parse_file () at
../../src/gcc/c-family/c-opts.cc:1262
#14 0x014ef80a in compile_file () at ../../src/gcc/toplev.cc:452
#15 0x00a20e98 in do_compile (no_backend=false) at
../../src/gcc/toplev.cc:2168
#16 toplev::main (this=this@entry=0x7fffdcae, argc=,
argc@entry=25, argv=, argv@entry=0x7fffddb8)
at ../../src/gcc/toplev.cc:2320
#17 0x00a22dd5 in main (argc=25, argv=0x7fffddb8) at
../../src/gcc/main.cc:39
as a copy of the "i" created here:
(gdb) bt
#0 make_node (code=VAR_DECL) at ../../src/gcc/tree.cc:1211
#1 0x017e2d6e in build_decl (loc=292864, code=VAR_DECL,
name=, type=)
at ../../src/gcc/tree.cc:5289
#2 0x00d0c3ce in cp_parser_omp_iterators (parser=0x7fffea6747b8) at
../../src/gcc/cp/parser.cc:39118
#3 0x00d0c746 in cp_parser_omp_clause_affinity (parser=0x7fffea6747b8,
list=) at ../../src/gcc/cp/parser.cc:39181
#4 0x00d0f6b5 in cp_parser_omp_all_clauses (parser=0x7fffea6747b8,
mask=..., where=0x259c622 "#pragma omp task",
pragma_tok=0x7fffea5b41c8, finish_p=true, nested=0) at
../../src/gcc/cp/parser.cc:40274
#5 0x00d1c848 in cp_parser_omp_task (parser=0x7fffea6747b8,
pragma_tok=0x7fffea5b41c8, if_p=0x0) at ../../src/gcc/cp/parser.cc:43585
#6 0x00d307ba in cp_parser_omp_construct (parser=0x7fffea6747b8,
pragma_tok=0x7fffea5b41c8, if_p=0x0) at ../../src/gcc/cp/parser.cc:47225
#7 0x00d31980 in cp_parser_pragma (parser=0x7fffea6747b8,
context=pragma_compound, if_p=0x0) at ../../src/gcc/cp/parser.cc:47866
#8 0x00cd0ee5 in cp_parser_statement (parser=0x7fffea6747b8,
in_statement_expr=, in_compound=true, if_p=0x0, chain=0x0,
loc_after_labels=0x0) at ../../src/gcc/cp/parser.cc:12393
#9 0x00cd1f60 in cp_parser_statement_seq_opt (parser=0x7fffea6747b8,
in_statement_expr=) at ../../src/gcc/cp/parser.cc:12846
#10 0x00cd1e50 in cp_parser_compound_statement (parser
[Bug testsuite/105085] Excess errors from new test case gcc.dg/analyzer/untracked-1.c in r12-7809-g5f6197d7c197f9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105085 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2022-03-29 --- Comment #1 from David Malcolm --- Thanks for reporting this. Sorry about the noise; am working on a fix.
[Bug analyzer/105102] New: RFE: analyzer handling for asprintf and vasprintf
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: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- (spotted while fixing PR analyzer/105087) We don't yet have any special-casing of asprintf and vasprintf, and there doesn't seem to be a way to express their behavior with attributes. Would be nice to bifurcate state, and: - on success, track that *ARG is to be freed with free (and thus we can detect memory leaks, wrong deallocator, etc), - on failure, *ARG is undefined; exactly what we should do here is unclear (what exactly does glibc do? https://linux.die.net/man/3/vasprintf says that the "FreeBSD implementation sets strp to NULL on error.", presumably it means *strp; ee PR 44435). Maybe we need a new kind of poisoned_svalue "undefined" for the error case, since there's no guarantee made about what the state of *ARG is?
[Bug analyzer/105103] New: RFE: detect bogus use of varargs in analyzer
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: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- The analyzer doesn't yet have any handling for the types, macros, functions from : https://en.cppreference.com/w/c/variadic https://www.man7.org/linux/man-pages/man3/stdarg.3.html It would be nice to e.g. detect the various undefined behaviors listed in the above e.g. "If ap is passed to a function that uses va_arg(ap,type), then the value of ap is undefined after the return of that function." etc. We could also implement __builtin_va_start, __builtin_va_end, etc and have region_model unpack variadic args in interprocedural calls, effectively inlining the analysis.
[Bug testsuite/105085] Excess errors from new test case gcc.dg/analyzer/untracked-1.c in r12-7809-g5f6197d7c197f9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105085 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Status|ASSIGNED|RESOLVED --- Comment #3 from David Malcolm --- Should be fixed by the above commit; please reopen if it doesn't.
[Bug analyzer/105112] New: Speed up -fanalyzer on big-code.c
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 Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- Several large functions with arithmetics and one-deep loops, posted by Michael Matz to gcc-patches: https://gcc.gnu.org/ml/gcc-patches/2013-09/msg00062.html Also at: https://github.com/davidmalcolm/gcc-benchmarking/blob/master/test-sources/big-code.c -ftime-report shows that -fanalyzer increases compile time (without optimizations) from 6 seconds to 30 seconds, almost all of which is spent processing the worklist: [...snip...] analyzer : 0.61 ( 2%) 0.01 ( 1%) 0.63 ( 2%) 0 ( 0%) analyzer: supergraph : 0.04 ( 0%) 0.02 ( 2%) 0.06 ( 0%) 0 ( 0%) analyzer: state purge : 0.57 ( 2%) 0.05 ( 5%) 0.62 ( 2%) 0 ( 0%) analyzer: planning : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 ( 0%) analyzer: processing worklist : 23.91 ( 82%) 0.50 ( 50%) 24.55 ( 80%) 24M ( 12%) TOTAL : 29.32 1.00 30.51 200M -Wanalyzer-too-complex shows that it eventually starts giving up. The analyzer isn't going to have anything interesting to report on this code; hopefully there are ways for it to go faster for this example.
[Bug analyzer/105112] Speed up -fanalyzer on big-code.c
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 = 0; j < 8192; j++) { \
| ~~^~
rmodel:
stack depth: 1
frame (index 0): frame: ‘func_schar’@1
clusters within root region
cluster for: (*INIT_VAL(a_8725(D)))
ESCAPED
TOUCHED
key: {byte 0}
value: ‘unsigned char’ {(CAST(unsigned char, CONJURED(_7228 = get_i ();,
(*INIT_VAL(a_8725(D)+(CAST(unsigned char, CONJURED(_7228 = get_i ()
;, (*INIT_VAL(b_8726(D)*CAST(unsigned char, CONJURED(_7228 = get_i ();,
(*INIT_VAL(c_8727(D)))}
key: {byte 1}
value: ‘signed char’ {UNKNOWN(signed char)}
cluster for: (*INIT_VAL(b_8726(D))): UNKNOWN(schar) (ESCAPED) (TOUCHED)
cluster for: (*INIT_VAL(c_8727(D))): UNKNOWN(schar) (ESCAPED) (TOUCHED)
clusters within frame: ‘func_schar’@1
cluster for: i_8127: CONJURED(i_8707 = get_i ();, i_8707)
cluster for: accum_8740: UNKNOWN(schar)
cluster for: z_7997: UNKNOWN(schar)
cluster for: x_7611: UNKNOWN(schar)
cluster for: y_7867: UNKNOWN(schar)
cluster for: j_8254: WIDENING({after SN: 12510}, (int)1, (int)2)
m_called_unknown_fn: TRUE
constraint_manager:
equiv classes:
ec0: {(int)0 == [m_constant]‘0’}
ec1: {(void *)0B == [m_constant]‘0B’}
ec2: {INIT_VAL(a_8725(D))}
ec3: {INIT_VAL(b_8726(D))}
ec4: {INIT_VAL(c_8727(D))}
ec5: {CONJURED(i_8707 = get_i ();, i_8707)}
constraints:
0: ec2: {INIT_VAL(a_8725(D))} != ec1: {(void *)0B == [m_constant]‘0B’}
1: ec3: {INIT_VAL(b_8726(D))} != ec1: {(void *)0B == [m_constant]‘0B’}
2: ec4: {INIT_VAL(c_8727(D))} != ec1: {(void *)0B == [m_constant]‘0B’}
3: ec5: {CONJURED(i_8707 = get_i ();, i_8707)} != ec0: {(int)0 ==
[m_constant]‘0’}
[Bug analyzer/105112] Speed up -fanalyzer on big-code.c
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% libc-2.31.so [.] __memset_sse2_unaligned_erms 2.52% cc1 [.] hash_table, false, xcallocator>::find_slot_with_hash 2.52% cc1 [.] ana::reachable_regions::add 2.45% libc-2.31.so [.] malloc 2.37% cc1 [.] hash_table, false, xcallocator>::find_slot_with_hash 1.98% libc-2.31.so [.] __libc_calloc 1.87% libc-2.31.so [.] cfree@GLIBC_2.2.5 1.71% cc1 [.] hash_table, false, xcallocator>::find_with_hash 1.33% cc1 [.] ana::sm_state_map::clone 1.33% cc1 [.] ana::store::canonicalize 1.25% cc1 [.] ana::store::get_cluster 1.22% cc1 [.] ana::store::escaped_p 1.10% cc1 [.] ana::function_point::hash 1.09% cc1 [.] iterative_hash 1.06% cc1 [.] ana::store::store 0.95% cc1 [.] ana::reachable_regions::init_cluster 0.94% libc-2.31.so [.] malloc_consolidate 0.86% cc1 [.] hash_table, false, xcallocator>::find_with_hash 0.80% cc1 [.] ana::reachable_regions::handle_sval 0.79% libc-2.31.so [.] unlink_chunk.constprop.0 0.79% cc1 [.] ana::region::get_base_region 0.75% cc1 [.] ana::region_model::~region_model 0.73% cc1 [.] xcalloc 0.72% cc1 [.] ana::program_state::prune_for_point 0.69% cc1 [.] ana::svalue::live_p 0.69% cc1 [.] ana::constraint_manager::canonicalize 0.68% cc1 [.] record_reg_classes 0.65% cc1 [.] ana::store::get_any_binding 0.64% cc1 [.] ana::sm_state_map::on_liveness_change 0.64% cc1 [.] ana::decl_region::get_kind 0.55% cc1 [.] hash_table, false, xcallocator>::expand 0.52% cc1 [.] ana::binding_cluster::can_merge_p 0.50% cc1 [.] ana::sm_state_map::get_state
[Bug analyzer/105113] [12 Regression] Analyzer segfaults on __func__ in static function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105113 David Malcolm changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from David Malcolm --- Sorry about the breakage; this should be fixed on trunk now (PR analyzer/105074). *** This bug has been marked as a duplicate of bug 105074 ***
[Bug analyzer/105074] [12 Regression] -fanalyzer ICEs on gnutls-3.7.3: cgraph_node::get_edge(gimple*) SIGSEGV since r12-7809-g5f6197d7c197f9d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105074 David Malcolm changed: What|Removed |Added CC||bero at lindev dot ch --- Comment #6 from David Malcolm --- *** Bug 105113 has been marked as a duplicate of this bug. ***
[Bug analyzer/105112] Speed up -fanalyzer on big-code.c
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 handled with a "we don't care" value. (though do we care about tainted divisors for floating-point?)
[Bug jit/102824] building pdf/dvi documentation for libgccjit fails
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/*.png gcc/jit/docs/_build/texinfo/libgccjit-figures and it seems to fix the "make pdf" for me. Will test a bit more.
[Bug jit/104071] Add support for bitcast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104071 David Malcolm changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/jit/2022q1/001475.html --- Comment #1 from David Malcolm --- Latest version of patch seems to be: https://gcc.gnu.org/pipermail/jit/2022q1/001475.html
[Bug jit/104073] Add option to hide stderr logging in libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104073 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||https://gcc.gnu.org/piperma ||il/jit/attachments/20220123 ||/22c69b0c/attachment.bin Ever confirmed|0 |1 Keywords||patch Last reconfirmed||2022-04-05
[Bug jit/104293] Add support for setting the alignment of variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104293 David Malcolm changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/jit/2022q1/001494.html Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2022-04-05
[Bug jit/102824] building pdf/dvi documentation for libgccjit fails
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. I last used TeX roughly 3 decades ago, so help fixing this would be welcome :)
[Bug analyzer/105190] New: False positive from -Wanalyzer-malloc-leak with symbolic writes to structs
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: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Discovered whilst working on the fix for PR analyzer/102308:
#include "analyzer-decls.h"
struct st
{
void *ptr[10];
int arr[10];
};
struct st
test_conc_sym_ptr_sym_conc_arr (int i, struct st *p)
{
struct st s;
s.ptr[i] = __builtin_malloc (1024);
__analyzer_describe (0, s.ptr[i]); /* { dg-warning "HEAP_ALLOCATED_REGION" }
*/
p->arr[5] = 42;
__analyzer_describe (0, s.ptr[i]); /* { dg-warning "HEAP_ALLOCATED_REGION" }
*/
__analyzer_describe (0, p->arr[5]); /* { dg-warning "42" } */
return s;
} /* { dg-bogus "leak" "" { xfail *-*-* } } */
// TODO: ^^XFAIL
struct st
test_conc_sym_ptr_sym_sym_arr (int i, struct st *p, int j)
{
struct st s;
s.ptr[i] = __builtin_malloc (1024);
__analyzer_describe (0, s.ptr[i]); /* { dg-warning "HEAP_ALLOCATED_REGION" }
*/
p->arr[j] = 42;
__analyzer_describe (0, s.ptr[i]); /* { dg-warning "HEAP_ALLOCATED_REGION" }
*/
__analyzer_describe (0, p->arr[j]); /* { dg-warning "42" } */
return s;
} /* { dg-bogus "leak" "" { xfail *-*-* } } */
// TODO: ^^XFAIL
[Bug analyzer/102308] False positive -Wanalyzer-malloc-leak when writing to array in struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102308 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-04-06 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from David Malcolm --- Thanks for filing this bug report. I'm testing a fix.
[Bug c++/102208] Acceptance of invalid decltype(auto) in the default operator <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102208 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #2 from David Malcolm --- (In reply to CVS Commits from comment #1) > The master branch has been updated by David Malcolm : > > https://gcc.gnu.org/g:88b939b19ab454ab2d932ef292bbc557abe4431c > > commit r12-8047-g88b939b19ab454ab2d932ef292bbc557abe4431c > Author: David Malcolm > Date: Thu Apr 7 08:33:26 2022 -0400 > > analyzer: fix leak false +ve with symbolic writes [PR102208] > Sorry, this should have been PR 102308
[Bug analyzer/102308] False positive -Wanalyzer-malloc-leak when writing to array in struct
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 David Malcolm :
https://gcc.gnu.org/g:88b939b19ab454ab2d932ef292bbc557abe4431c
commit r12-8047-g88b939b19ab454ab2d932ef292bbc557abe4431c
Author: David Malcolm
Date: Thu Apr 7 08:33:26 2022 -0400
analyzer: fix leak false +ve with symbolic writes [PR102208]
PR analyzer/102208 reports false positives from -Wanalyzer-malloc-leak.
The root cause is the analyzer getting confused about symbolic writes
that could alias a pointer referencing a malloced buffer.
struct st
{
void *ptr;
int arr[10];
};
struct st test (int idx)
{
struct st s;
s.ptr = __builtin_malloc (1024); /* (1) */
s.arr[idx] = 42; /* (2) */
return s;
}
When removing overlapping bindings at (2),
store::remove_overlapping_bindings was failing to pass on the
uncertainty_t *, and thus when clobbering the binding of s.ptr, the
heap-allocated pointer was not being added to the set of maybe-bound
svalues, and thus being treated as leaking.
This patch fixes this, so that s.ptr from (1) is treated as maybe-bound
after the write at (2), fixing the leak false postive.
Doing so requires the store to be smarter about how clobbering happens
with various combinations of concrete keys and symbolic keys within
concrete clusters and symbolic clusters, so that we don't lose warnings
about definite leaks.
gcc/analyzer/ChangeLog:
PR analyzer/102208
* store.cc (binding_map::remove_overlapping_bindings): Add
"always_overlap" param, using it to generalize to the case where
we want to remove all bindings. Update "uncertainty" logic to
only record maybe-bound values for cases where there is a symbolic
write involved.
(binding_cluster::mark_region_as_unknown): Split param "reg" into
"reg_to_bind" and "reg_for_overlap".
(binding_cluster::maybe_get_compound_binding): Pass "false" to
binding_map::remove_overlapping_bindings new "always_overlap"
param.
(binding_cluster::remove_overlapping_bindings): Determine
"always_overlap" and pass it to
binding_map::remove_overlapping_bindings.
(store::set_value): Pass uncertainty to remove_overlapping_bindings
call. Update for new param of
binding_cluster::mark_region_as_unknown, passing both the base
region of the iter_cluster, and the lhs_reg.
(store::mark_region_as_unknown): Update for new param of
binding_cluster::mark_region_as_unknown, passing "reg" for both.
(store::remove_overlapping_bindings): Add param "uncertainty", and
pass it on to call to
binding_cluster::remove_overlapping_bindings.
* store.h (binding_map::remove_overlapping_bindings): Add
"always_overlap" param.
(binding_cluster::mark_region_as_unknown): Split param "reg" into
"reg_to_bind" and "reg_for_overlap".
(store::remove_overlapping_bindings): Add param "uncertainty".
gcc/testsuite/ChangeLog:
PR analyzer/102208
* gcc.dg/analyzer/symbolic-9.c: New test.
* gcc.dg/analyzer/torture/leak-pr102308-1.c: New test.
* gcc.dg/analyzer/torture/leak-pr102308-2.c: New test.
Signed-off-by: David Malcolm
[Bug analyzer/102308] False positive -Wanalyzer-malloc-leak when writing to array in struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102308 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above commit for GCC 12.
[Bug analyzer/103892] -Wanalyzer-double-free false positive when compiling libpipeline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103892 --- Comment #2 from David Malcolm --- Still affects trunk
[Bug analyzer/103892] -Wanalyzer-double-free false positive when compiling libpipeline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103892 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from David Malcolm --- Should be fixed by the above patch on trunk for GCC 12. Backporting the fix to GCC 11 is probably not feasible. Marking as resolved. Thanks again for filing this bug.
[Bug analyzer/105103] RFE: detect bogus use of varargs in analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105103 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-04-11 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from David Malcolm --- I have a prototype implementation of this in my patch queue for GCC 13.
[Bug analyzer/105252] [12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -O -fanalyzer -fnon-call-exceptions since r12-1931-ge61ffa201403e381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105252 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from David Malcolm --- Thanks for filing this bug. I'm testing a fix.
gcc-bugs@gcc.gnu.org
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 flags you use to reproduce the false positive, and (b) attach the preprocessed source. You can get this via the -E option to gcc. Thanks!
[Bug jit/95325] Support 128-bit integers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95325 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #5 from David Malcolm --- Marking as resolved; please reopen if there's an issue integrating the version of the patch I committed with rustc_codegen_gcc.
[Bug jit/104071] Add support for bitcast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104071 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Marking as resolved; please reopen if there's an issue integrating the version of the patch I committed with rustc_codegen_gcc.
[Bug jit/104072] Register variables in libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104072 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from David Malcolm --- Marking as resolved; please reopen if there's an issue integrating the version of the patch I committed with rustc_codegen_gcc.
[Bug jit/104073] Add option to hide stderr logging in libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104073 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from David Malcolm --- Marking as resolved; please reopen if there's an issue integrating the version of the patch I committed with rustc_codegen_gcc.
[Bug jit/104293] Add support for setting the alignment of variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104293 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from David Malcolm --- Marking as resolved; please reopen if there's an issue integrating the version of the patch I committed with rustc_codegen_gcc.
[Bug analyzer/104308] no location info provided for [-Wanalyzer-use-of-uninitialized-value] warnings
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 are still printed without any location info: Thanks; I'm testing a fix.
[Bug analyzer/105252] [12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -O -fanalyzer -fnon-call-exceptions since r12-1931-ge61ffa201403e381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105252 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from David Malcolm --- Should be fixed by the above patch.
[Bug analyzer/104308] no location info provided for [-Wanalyzer-use-of-uninitialized-value] warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308 David Malcolm changed: What|Removed |Added Status|ASSIGNED|WAITING URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2022-April/5 ||93245.html --- Comment #10 from David Malcolm --- Followup patch posted; waiting on review: https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593245.html
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105264 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-04-14 --- Comment #5 from David Malcolm --- (In reply to Ævar Arnfjörð Bjarmason from comment #2) > I think I can do one better. Here's a stand-alone reproducible test case > without any headers except standard headers, I've expanded the gcc -E > version of that too, but presumably you won't need it. Thanks - I'm poking at -fanalyzer on both attachments now. FWIW, the -E version can sometimes be very helpful, for the case where we have different headers (e.g. glibc sometimes adds attributes to decls, which can affect things)
gcc-bugs@gcc.gnu.org
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 seems to fix the -Wanalyzer-use-of-uninitialized-value false positives identified in the reproducer. That said, I think for a deeper fix it's probably best to wait until GCC 13.
[Bug analyzer/105273] -Wanalyzer-use-of-uninitialized-value warns on "missing" default for switch when callers can be statically determined
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 this in commit r11-7029-g8a2750086d57d1. There's definitely room for improvement here, possibly with a heuristic for switch statements, or due to fixing how the analyzer handles call summaries.
gcc-bugs@gcc.gnu.org
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.
[Bug analyzer/105287] [12 Regression] ICE in get_region_for_local, at analyzer/region.cc:874
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105287
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2022-04-15
CC||iains at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from David Malcolm ---
Confirmed; it's an assertion failing in
ana::frame_region::get_region_for_local, due to a variable having NULL for its
DECL_CONTEXT:
(gdb) list
869 case SSA_NAME:
870 {
871 if (tree var = SSA_NAME_VAR (expr))
872 {
873 if (DECL_P (var))
874 gcc_assert (DECL_CONTEXT (var) == m_fun->decl);
875 }
This is probably benign if assertions are disabled (perhaps the analyzer is
being more fussy than the rest of the middle-end?)
(gdb) call debug_tree(var)
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea665b28 precision:1 min max
pointer_to_this >
unsigned QI ../../src/gcc/testsuite/g++.dg/analyzer/pr105287.C:35:73 size
unit-size
align:8 warn_if_not_align:0>
(gdb) p var.decl_minimal.context
$2 =
The var_decl is "cond_var" created here in the C++ FE:
#4 0x00b30ec2 in flatten_await_stmt (n=0x317b9b0,
promoted=0x7fffcc40, temps_used=0x7fffcc70, replace_in=)
at ../../src/gcc/cp/coroutines.cc:2792
2792 tree cond_var = build_lang_decl (VAR_DECL, NULL_TREE,
cond_type);
(gdb) list
2787 /* If the condition contains an await expression, then we
need to
2788 set that first and use a separate var. */
2789 if (cp_walk_tree (&cond, find_any_await, &found, NULL))
2790{
2791 tree cond_type = TREE_TYPE (cond);
2792 tree cond_var = build_lang_decl (VAR_DECL, NULL_TREE,
cond_type);
2793 DECL_ARTIFICIAL (cond_var) = true;
2794 layout_decl (cond_var, 0);
2795 gcc_checking_assert (!TYPE_NEEDS_CONSTRUCTING
(cond_type));
2796 cond = build2 (INIT_EXPR, cond_type, cond_var, cond);
2797 var_nest_node *ins
2798= new var_nest_node (cond_var, cond, n->prev, n);
2799 COND_EXPR_COND (n->init) = cond_var;
2800 flatten_await_stmt (ins, promoted, temps_used, NULL);
2801}
Iain: shouldn't the DECL_CONTEXT be being set on var_decls created here?
[Bug analyzer/105285] False positive with -Wanalyzer-null-dereference in git.git's reftable/reader.c
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.
[Bug analyzer/105365] [12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -fanalyzer since r12-2337-g33255ad3ac14e395
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105365 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from David Malcolm --- Thanks for filing this bug; I'm testing a fix.
[Bug analyzer/105366] [11/12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -O -fanalyzer since r11-4511-gf635f0ce87d687b1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105366 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from David Malcolm --- Thanks for filing this bug; I'm testing a fix. Seems to be the same root cause as PR105365; I'm not sure why one manifests with GCC 11 and the other doesn't.
[Bug analyzer/105382] New: Support for coroutines in -fanalyzer
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 Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Blocks: 97110 Target Milestone: --- -fanalyzer doesn't work well with C++ coroutines. For example, trying it on gcc/testsuite/g++.dg/coroutines/torture/co-yield-01-multi.C leads to: warning: dereference of possibly-NULL ‘’ [CWE-690] [-Wanalyzer-possible-null-dereference] 13 | f () noexcept | ^ ‘coro1 f()’: events 1-2 | | 13 | f () noexcept | | ~ | | | | | (2) ‘operator new(40)’ could be NULL: unchecked value from (1) |.. | 23 | } | | ^ | | | | | (1) this call could return NULL | along with numerous: warning: use of uninitialized value ‘’ [CWE-457] [-Wanalyzer-use-of-uninitialized-value] e.g.: ../../src/gcc/testsuite/g++.dg/coroutines/torture/co-yield-01-multi.C:23:1: warning: use of uninitialized value ‘’ [CWE-457] [-Wanalyzer-use-of-uninitialized-value] 23 | } | ^ ‘coro1 f()’: events 1-3 | | 13 | f () noexcept | | ^ | | || | | |(2) region created on stack here | | (1) entry to ‘f’ | | (3) calling ‘f’ from ‘f’ | +--> ‘void f(f()::_Z1fv.Frame*)’: events 4-10 | | 13 | f () noexcept | | ^ | | | | | (4) entry to ‘f’ | | (8) ...to here | | (9) following ‘true’ branch... | | (10) ...to here |.. | 23 | } | | ~ | | | | | (5) following ‘false’ branch... | | (6) ...to here | | (7) following ‘case 0:’ branch... | <--+ | ‘coro1 f()’: events 11-12 | | 13 | f () noexcept | | ^ | | | | | (11) returning to ‘f’ from ‘f’ |.. | 23 | } | | ~ | | | | | (12) use of uninitialized value ‘’ here | Note how the path refers to "case 0:"; I believe this is a reference to the synthetic switch for handling re-entering the coroutine: : _3 = frame_ptr_56(D)->_Coro_resume_index; _4 = (int) _3; switch (_4) [INV], case 1: [INV], case 3: [INV], case 5: [INV], case 7: [INV], case 9: [INV]> So I think that the way we generate events in diagnostic paths might need some kind of support for presenting the information in a form that more closely resembles what the user wrote, rather than the gimplification of what the C++ FE generated. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97110 [Bug 97110] [meta-bug] tracker bug for supporting C++ in -fanalyzer
[Bug analyzer/105287] [12 Regression] ICE in analyzer get_region_for_local on C++ await cond_var
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).
[Bug analyzer/105365] [12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -fanalyzer since r12-2337-g33255ad3ac14e395
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105365 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from David Malcolm --- Should be fixed for gcc 12 by the above commit.
[Bug analyzer/105366] [11 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -O -fanalyzer since r11-4511-gf635f0ce87d687b1
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 |cmp_cst, at |cmp_cst, at |analyzer/svalue.cc:309 with |analyzer/svalue.cc:309 with |-O -fanalyzer since |-O -fanalyzer since |r11-4511-gf635f0ce87d687b1 |r11-4511-gf635f0ce87d687b1 --- Comment #4 from David Malcolm --- Should be fixed for gcc 12 by the above commit. Keeping open for backporting to gcc 11.
[Bug analyzer/104308] no location info provided for [-Wanalyzer-use-of-uninitialized-value] warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #12 from David Malcolm --- Should be fixed by the above commit.
[Bug analyzer/105382] Support for coroutines in -fanalyzer
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 is re-entering i.e. this data value exists to affect control flow. Presumably that ought to be expressed in the exploded graph, so that it properly respects control flow. So I think we need to be smarter about _Coro_resume_index values in various ways e.g. not merge state for them, and assume some initial value for the initial entry to the coroutine, etc.
[Bug analyzer/105285] False positive with -Wanalyzer-null-dereference in git.git's reftable/reader.c
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.
[Bug analyzer/105285] False positive with -Wanalyzer-null-dereference in git.git's reftable/reader.c
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).
[Bug analyzer/105285] False positive with -Wanalyzer-null-dereference in git.git's reftable/reader.c
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 is passed to reader_get_block:
if (next_off >= r->size)
return 1;
err = reader_get_block(r, &block, next_off, guess_block_size);
if (err < 0)
goto done;
block_size = extract_block_size(block.data, &block_typ, next_off,
r->version);
There's an early-reject case in reader_get_block, which is:
if (off >= r->size)
return 0;
I believe the analyzer's feasibility checker is getting confused; it appears to
be getting placeholder values when it access r->size, and each time it accesses
r->size it gets a different placeholder value, and thus erroneously considers
the execution path where (next_off >= r->size) && !(off >= r->size) when
next_off == off.
I'm working on a simpler reproducer, and a fix.
[Bug analyzer/105285] False positive with -Wanalyzer-null-dereference in git.git's reftable/reader.c
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 = reader_get_block(r, &block, next_off, guess_block_size); if (err < 0) goto done; so if the early reject does happen, the returned "err" will be zero, not less-than-zero. Is that a problem?
