[Bug analyzer/93993] ICE in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93993 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- The ICE should be fixed by r10-7024-ge516294a1acb28d44cfd583cc6a80354044e.
[Bug analyzer/94028] ICE: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786 with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94028 --- Comment #2 from David Malcolm --- Yes, the ICE was fixed by r10-7023-g3d66e153b40ed000af30a9e569a05f34d5d576aa. It's a similar issue to the reproducer for PR analyzer/93993. I'll add your reproducer as a further regression test; thanks.
[Bug analyzer/94028] ICE: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786 with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94028 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from David Malcolm --- Fixed (see comment 2); regression test added (see comment 3); marking as resolved. Thanks for filing this.
[Bug analyzer/94047] ICE: SIGSEGV in ana::region_model::get_lvalue_1() with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94047 --- Comment #2 from David Malcolm --- Fixed by g:787477a226033e36be3f6d16b71be13dd917e982; I'll add a regression test.
[Bug analyzer/94047] ICE: SIGSEGV in ana::region_model::get_lvalue_1() with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94047 --- Comment #3 from David Malcolm --- (In reply to David Malcolm from comment #2) > Fixed by g:787477a226033e36be3f6d16b71be13dd917e982; I'll add a regression > test. Sorry; that should be g:90f7c3007d58c5cb538d00351c038f3f2cfcaf67.
[Bug analyzer/94099] ICE in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4874 since r10-7023-g3d66e153b40ed000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94099 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from David Malcolm --- Should be fixed by g:5c048755ec98645f8436b630df3f9294ca9cbc2a.
[Bug analyzer/94105] ICE in get_region, at analyzer/region-model.h:1744
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94105 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from David Malcolm --- Should be fixed by g:5c048755ec98645f8436b630df3f9294ca9cbc2a.
[Bug analyzer/94047] ICE: SIGSEGV in ana::region_model::get_lvalue_1() with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94047 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from David Malcolm --- Regression test added; marking as resolved.
[Bug c/94230] provide an option to change the size limitation for -Wmisleading-indent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230 --- Comment #6 from David Malcolm --- I'm not sure this has a changed a lot "recently"; I did 2-3 years ago IIRC. The warning occurs when we have location_t > LINE_MAP_MAX_LOCATION_WITH_COLS which means that we've run out of values for expressing locations. If you have a huge workload, one possible workaround would be to disable range tracking, perhaps tweaking line_table->default_range_bits, which would give you a bit more "headroom". IIRC we don't currently expose a way to do this, and probably some extra code would be needed. It's currently hardcoded to 5. Perhaps some kind of -fno-location-ranges? It could either: (a) don't attempt to store location ranges (would probably have to disable e.g. fix-it hints) (b) set line_table->default_range_bits to 0, so that all ranges have to go to the ad-hoc table, but buying space for more locations. I'm not sure if either of these are good ideas though.
[Bug analyzer/94350] internal compiler error: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4874
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94350 --- Comment #3 from David Malcolm --- Also, which version of the compiler? I've fixed a few similar-looking problems to this recently.
[Bug analyzer/94362] New: False analyzer report due to i >= 0 and i < 0 on openssl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94362 Bug ID: 94362 Summary: False analyzer report due to i >= 0 and i < 0 on openssl Product: gcc Version: 10.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: --- Created attachment 48134 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48134&action=edit Reduced test case https://github.com/openssl/openssl/issues/11420 reports what looks like a false positive: crypto/asn1/ameth_lib.c:131:18: error: dereference of NULL 'ameth' [CWE-690] [-Werror=analyzer-null-dereference] where on the path to the diagnostic i >= 0 and i < 0, which ought to be rejected by constraint-checking. I'm attaching a somewhat simplified reproducer.
[Bug analyzer/94371] New: Macro-printing within diagnostic paths can be very verbose.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94371 Bug ID: 94371 Summary: Macro-printing within diagnostic paths can be very verbose. Product: gcc Version: 10.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 default -fdiagnostics-path-format=inline-events prints each macro expansion for every event in the path that's from a macro expansion. This can be very verbose; consider e.g. the krb5 example here: https://dmalcolm.fedorapeople.org/gcc/2020-02-28/recvauth.c.html where there's a: #define krb5_xfree(val) free((char *)(val)) The expansion is printed many times: * for the primary location of each of the two diagnostics * for events 9, 10, and 11 of the first diagnostic * for events 9, 10, 12 and 13 of the second diagnostic i.e. it's printed 4 times for the first diagnostic, and 5 times for the second diagnostic. Ideas for making it less verbose: * only print macro expansions with paths once per path (so in the example it would print the expansions per primary loc, and once per path) * only print macro expansions within paths once per diagnostic_group (and not printing it if the primary location showed it, so in the example it would only print it per primary loc) * only once within paths per diagnostic_context (so it the example it would only print it once) * or some other kind of consolidation However, this is a simple macro; it's not clear what we should do with more complicated macros. Perhaps do it per token of the macro, so that if we're exploring control flow within a macro, we show that.
[Bug analyzer/94447] New: Not handling CONSTRUCTOR tree code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94447
Bug ID: 94447
Summary: Not handling CONSTRUCTOR tree code
Product: gcc
Version: 10.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: ---
Consider e.g.:
struct foo
{
int *v;
};
int test (void)
{
struct foo f = {};
return *f.v;
}
This currently reports
t.c: In function ‘test’:
t.c:9:10: warning: use of uninitialized value ‘’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
9 | return *f.v;
| ^~~~
‘test’: event 1
|
|
when it should be a NULL dereference.
The f = {}; shows up as f = {}; in the gimple dump, a CONSTRUCTOR, and
region_model::on_assignment is hitting a TODO for that tree code.
[Bug analyzer/94378] -Wanalyzer-malloc-leak false positive when returning a struct by value holding a heap-allocated pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94378 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from David Malcolm --- Thanks for reporting this. Should be fixed by above commit.
[Bug analyzer/94378] -Wanalyzer-malloc-leak false positive when returning a struct by value holding a heap-allocated pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94378 --- Comment #4 from David Malcolm --- Can you attach the analyzer report please?
[Bug analyzer/94378] -Wanalyzer-malloc-leak false positive when returning a struct by value holding a heap-allocated pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94378 --- Comment #6 from David Malcolm --- Thanks Simon. The second diagnostic definitely looks like a false positive; am not sure about the first. Please can you file a separate bug about this.
[Bug analyzer/94503] ICE in saved_diagnostic, at analyzer/diagnostic-manager.cc:84
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94503 --- Comment #2 from David Malcolm --- Appears to be due to return slot optimization.
[Bug c/94382] conflicting function types should show more context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94382 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #1 from David Malcolm --- Beyond simply showing the entire prototype, some other ideas: ./fs/iomap/apply.c:13:1: error: conflicting types for ‘__iomap_apply’ 13 | __iomap_apply(struct inode *inode, loff_t pos, loff_t length, unsigned flags, 14 | struct iomap *iomap, struct iomap *srcmap, | --- | || | param 5 param 6 15 | const struct iomap_ops *ops, iomap_actor_t actor) | --- --- | || | param 7 param 8 In file included from ../fs/iomap/apply.c:9: ../include/linux/iomap.h:152:1: note: previous declaration of ‘__iomap_apply’ was here 152 | __iomap_apply(struct inode *inode, loff_t pos, loff_t length, unsigned flags, 153 | const struct iomap_ops *ops, iomap_actor_t actor, | --- --- || | |param 5 param 6 154 | struct iomap *iomap, struct iomap *srcmap); | --- || | |param 7 param 8 note: you've transposed params 5 and 7, and params 6 and 8 But it's probably simplest to just show the full prototype.
[Bug middle-end/92830] -fdiagnostics-url shows the wrong URL for warnings which are not in 'gcc' but e.g. in 'gfortran'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92830 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #4 from David Malcolm --- Similarly, -fanalyzer warnings are documented within Static-Analyzer-Options.html.
[Bug middle-end/92830] -fdiagnostics-url shows the wrong URL for warnings which are not in 'gcc' but e.g. in 'gfortran'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92830 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from David Malcolm --- Should be fixed by last commit; marking as resolved. Please reopen if there are any still any warnings with the wrong URL (note that my patch only fixed warnings, not all command-line options, but only warnings currently have user-visible URLs).
[Bug analyzer/94754] -fanalyzer false positive due to it ignoring previous if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94754 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by r10-8012-g78b9783774bfd3540f38f5b1e3c7fc9f719653d7.
[Bug analyzer/94732] Analyzer: false positive in MPFR's atan.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94732 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from David Malcolm --- Should be fixed by r10-8012-g78b9783774bfd3540f38f5b1e3c7fc9f719653d7.
[Bug analyzer/94447] Not handling CONSTRUCTOR tree code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94447 --- Comment #2 from David Malcolm --- r10-8012-g78b9783774bfd3540f38f5b1e3c7fc9f719653d7 removes the false positive, but we should still handle CONSTRUCTOR tree nodes. Keeping this open.
[Bug analyzer/94639] false-positive uninitialized value on fixed sized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94639 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from David Malcolm --- Should be fixed by r10-8012-g78b9783774bfd3540f38f5b1e3c7fc9f719653d7.
[Bug analyzer/94714] Analyzer: no warning on access of an uninitialized variable of automatic storage duration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94714 David Malcolm changed: What|Removed |Added Target Milestone|--- |11.0 --- Comment #1 from David Malcolm --- Thanks for filing this bug. I've removed -Wanalyzer-use-of-uninitialized-value for GCC 10 (in r10-8012-g78b9783774bfd3540f38f5b1e3c7fc9f719653d7) since the underlying region_model code is too buggy to support it. I'm rewriting it for GCC 11 and hope to reintroduce the warning there; setting target milestone accordingly.
[Bug analyzer/94816] ICE: Segmentation fault (in ana::region_model::add_region_for_type) since r10-5950-g757bf1dff5e8cee3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94816 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Thanks for filing this. Should be fixed by the above commit.
[Bug analyzer/95006] New: Reimplement -Wanalyzer-use-of-uninitialized-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95006 Bug ID: 95006 Summary: Reimplement -Wanalyzer-use-of-uninitialized-value Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Depends on: 94447, 94639, 94732, 94754 Target Milestone: --- I removed -Wanalyzer-use-of-uninitialized-value in r10-8012-g78b9783774bfd3540f38f5b1e3c7fc9f719653d7 as it had too many false positives: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544726.html This is a tracker bug, for keeping track of what needs fixing in order to reimplement it. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94447 [Bug 94447] Not handling CONSTRUCTOR tree code https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94639 [Bug 94639] false-positive uninitialized value on fixed sized array https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94732 [Bug 94732] Analyzer: false positive in MPFR's atan.c https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94754 [Bug 94754] -fanalyzer false positive due to it ignoring previous if
[Bug analyzer/94447] Not handling CONSTRUCTOR tree code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94447 David Malcolm changed: What|Removed |Added CC||tommy-gccbugs at thorn dot ws --- Comment #3 from David Malcolm --- *** Bug 94999 has been marked as a duplicate of this bug. ***
[Bug analyzer/94999] internal compiler error: in saved_diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94999
David Malcolm changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED |RESOLVED
Blocks||95006
--- Comment #1 from David Malcolm ---
Thanks for filing this.
I'm able to reproduce this with the revision in question
(f883c46b4877f637e0fa5025b4d6b5c9040ec566), but it's fixed in GCC 10.1
It's an assertion failure here:
#1 0x0242ee44 in ana::saved_diagnostic::saved_diagnostic
(this=0x3c6ca60, sm=0x0, enode=0x3ce0b20,
snode=0x332a110, stmt=0x0, stmt_finder=0x0, var=, state=0,
d=0x3cff4e0)
at ../../src/gcc/analyzer/diagnostic-manager.cc:84
84gcc_assert (m_stmt || m_stmt_finder);
when handling a false positive from -Wanalyzer-use-of-uninitialized-value,
which I removed in r10-8012-g78b9783774bfd3540f38f5b1e3c7fc9f719653d7.
The diagnostic is generated when analyzing the return from mk_entry to
memory_ensure_mapped_range on this code:
static struct entry
mk_entry(uint64_t start, uint64_t end)
{
return (struct entry) {safe_calloc(end - start, 1), start, end};
}
I think -fanalyzer is failing to handle a CONSTRUCTOR tree code (on those
{...}), and thus is erroneously treating the return value as uninitialized,
when the code looks correct to me.
The failure to handle CONSTRUCTOR tree codes is PR analyzer/94447, so I'm going
to close this out as a duplicate of that bug; clearly it needs to be fixed in
order to reimplement -Wanalyzer-use-of-uninitialized-value; adding to the
analyzer-uninit tracker bug.
*** This bug has been marked as a duplicate of bug 94447 ***
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95006
[Bug 95006] Reimplement -Wanalyzer-use-of-uninitialized-value
[Bug analyzer/95006] Reimplement -Wanalyzer-use-of-uninitialized-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95006 Bug 95006 depends on bug 94999, which changed state. Bug 94999 Summary: internal compiler error: in saved_diagnostic https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94999 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug analyzer/94999] internal compiler error: in saved_diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94999 --- Comment #2 from David Malcolm --- Actually, it's possibly failing to realize that calloc zeroes the memory. Either way it makes a good test case for when reintroducing -Wanalyzer-use-of-uninitialized-value; thanks.
[Bug analyzer/95007] New: RFE: -fanalyzer should complain about writes to string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95007
Bug ID: 95007
Summary: RFE: -fanalyzer should complain about writes to string
literals
Product: gcc
Version: 11.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: ---
(Motivated by PR analyzer/95000, which has a false-positive path to a write to
a string literal)
Consider:
void test (void)
{
char *s = "foo";
s[0] = 'g';
}
-fanalyzer should complain about the write to s[0], but currently doesn't
See e.g.
https://wiki.sei.cmu.edu/confluence/display/c/STR30-C.+Do+not+attempt+to+modify+string+literals
[Bug analyzer/95000] -fanalyzer confused by switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95000 --- Comment #3 from David Malcolm --- Thanks for filing this bug. I've filed PR analyzer/95007 to track the RFE for a warning about writes to a string literal. Clearly there's a bug somewhere in the handling for the path condition for the warning in comment #0; am investigating.
[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
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2020-05-08
Summary|-fanalyzer confused by |-fanalyzer confused by
|switch |switch on non-int type
--- Comment #4 from David Malcolm ---
This turns out to be a problem with tracking path-conditions with casts.
Switch statements on a non-int type (such as char) have an implicit cast to int
and trigger the issue.
Consider this test case, using the not-quite-a-builtin "__analyzer_eval" to
evaluate a condition. In each case we expect __analyzer_eval to emit "TRUE":
--
extern void __analyzer_eval (int);
void test_switch_char(char x) {
switch (x) {
case 'b':
__analyzer_eval (x == 'b');
}
}
void test_switch_int(int x) {
switch (x) {
case 97:
__analyzer_eval (x == 97);
}
}
void test_if_char(char x) {
if (x == 'b')
__analyzer_eval (x == 'b');
}
void test_if_int(int x) {
if (x == 97)
__analyzer_eval (x == 97);
}
--
I get this output (note that the output is in reverse order):
s.c: In function ‘test_if_int’:
s.c:24:5: warning: TRUE
24 | __analyzer_eval (x == 97);
| ^
s.c: In function ‘test_if_char’:
s.c:19:5: warning: TRUE
19 | __analyzer_eval (x == 'b');
| ^~
s.c: In function ‘test_switch_int’:
s.c:13:5: warning: TRUE
13 | __analyzer_eval (x == 97);
| ^
s.c: In function ‘test_switch_char’:
s.c:6:5: warning: UNKNOWN
6 | __analyzer_eval (x == 'b');
| ^~
where we get it wrong for test_switch_char.
At the gimple level, we have:
test_switch_char (char x)
{
int _1;
_Bool _2;
int _3;
:
_1 = (int) x_5(D);
if (_1 == 98)
goto ; [INV]
else
goto ; [INV]
:
:
_2 = x_5(D) == 98;
_3 = (int) _2;
__analyzer_eval (_3);
:
:
return;
}
The cast here:
_1 = (int) x_5(D);
if (_1 == 98)
seems to thwart my constraint-tracking.
If I use -fno-analyzer-state-purge it at least "knows" that _1 == 98 within the
"case" BB.
I'm working on a rewrite of state-tracking for GCC 11 that ought to better
handle casts.
[Bug analyzer/94851] -fanalyzer erroneously reporting NULL dereference - simple test case attached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94851
David Malcolm changed:
What|Removed |Added
Summary|-fanalyzer erroniously |-fanalyzer erroneously
|reporting NULL dereference |reporting NULL dereference
|- simple test case attached |- simple test case attached
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2020-05-08
Ever confirmed|0 |1
--- Comment #2 from David Malcolm ---
Thanks for filing this bug.
It does indeed look like a false positive.
With -fanalyzer-verbosity=3 I get this output:
--
$ ./xgcc -B. -c -fanalyzer t.c -O2 -fanalyzer-verbosity=3
t.c: In function ‘pamark’:
t.c:48:19: warning: dereference of NULL ‘last’ [CWE-690]
[-Wanalyzer-null-dereference]
48 |last->m_next = p;
|~~~^~~
‘pamark’: events 1-5
|
| 28 | while(p != (AMARK*)NULL && p->m_name != (char)c) {
| | ^
| | |
| | (1) following ‘false’ branch (when ‘p’ is NULL)...
|..
| 33 | if(p != (AMARK*) NULL) {
| |~
| ||
| |(2) ...to here
| |(3) following ‘false’ branch (when ‘p’ is NULL)...
|..
| 40 | if((p = (AMARK*) malloc(sizeof(AMARK))) == (AMARK*) NULL)
| | ~ ~
| | | |
| | | (4) ...to here
| | (5) following ‘false’ branch (when ‘p’ is non-NULL)...
|
‘pamark’: event 6
|
| 43 | p->m_next = (AMARK*) NULL;
| | ^
| | |
| | (6) ...to here
|
‘pamark’: events 7-10
|
|
--
It's considering the case where at:
AMARK* p= curbp->b_amark;
AMARK* last = curbp->b_amark;
both pointers are NULL.
I'm not sure why it's filtered those events at the default verbosity level.
It's also not printing events 7-10 for some reason, but with
-fdiagnostics-path-format=separate-events they show up as:
t.c:43:13: note: (7) ‘last’ is NULL
t.c:45:5: note: (8) following ‘false’ branch...
45 | if(curbp->b_amark == (AMARK*) NULL)
| ^
t.c:48:19: note: (9) ...to here
48 |last->m_next = p;
|~~~^~~
t.c:48:19: note: (10) dereference of NULL ‘last’
However, it seems to have lost the fact that "curbp->b_amark == NULL" at event
(8); hence a false positive.
I've tried to simplify the reproducer but have had no success so far.
[Bug analyzer/94458] -Wanalyzer-malloc-leak false positive when returning a heap-allocated struct by value holding a heap-allocated pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94458 David Malcolm changed: What|Removed |Added Last reconfirmed||2020-05-08 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Thanks for filing this bug; confirmed.
[Bug analyzer/95007] RFE: -fanalyzer should complain about writes to string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95007 --- Comment #2 from David Malcolm --- I guess I'm thinking about the case where a string literal has been exposed as a non-const "char *": the RFE here is for -fanalyzer to be able to detect if we ever write to such a string (with interprocedural analysis etc etc).
[Bug analyzer/95043] GCC 10 Analyzer and false positive on 'memcpy(dest, src, count);'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95043 --- Comment #1 from David Malcolm --- Please note that C++ isn't supported in the GCC 10 implementation of -fanalyzer (I hope to do so for GCC 11, but there's a lot of work to do). In particular, I haven't implemented exceptions yet.
[Bug analyzer/95031] GCC 10 Analyzer and fatal error: Terminated signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95031 --- Comment #2 from David Malcolm --- Please note that C++ isn't supported in the -fanalyzer implementation in GCC 10. I hope to get it working for GCC 11 (but there's a lot of work to do).
[Bug jit/95296] Segfault when trying to return a void value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95296 David Malcolm changed: What|Removed |Added Last reconfirmed||2020-05-24 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from David Malcolm --- Thanks for filing this. It looks like calls to (at least): gcc_jit_function_new_local gcc_jit_context_new_global should gracefully fail with an error if the client code attempts to create a variable of void type. Similarly we may need additional checking throughout for uses of rvalues of void type (but I need to check this).
[Bug jit/95314] Sharing a local reference to a global variable in multiple functions results in location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314 --- Comment #1 from David Malcolm --- Thanks for reporting it; this sounds like a bug. Please can you use attach a reproducer (e.g. using gcc_jit_context_dump_reproducer_to_file). Looking at the backtrace, it looks like a bad interaction with inlining, FWIW.
[Bug jit/95314] Sharing a local reference to a global variable in multiple functions results in location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314 --- Comment #3 from David Malcolm --- Thanks Jakub, that sounds like the problem: I'm creating a tree per playback::rvalue (m_inner), and I need to unshare them.
[Bug jit/95314] Sharing a local reference to a global variable in multiple functions results in location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314 --- Comment #6 from David Malcolm --- Sorry about that; thanks for trying. I think I can figure out a reproducer, and will try tomorrow.
[Bug jit/95296] Segfault when trying to return a void value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95296 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above commit.
[Bug jit/95306] Getting __builtin_sadd_overflow gives the error "unimplemented primitive type for builtin: 42"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95306 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above commit. Note that not all builtins can supported (or, at least, it would be a lot of extra work); see the commit message.
[Bug jit/87005] gcc_jit_context_get_builtin_function not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87005 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from David Malcolm --- Fixed by r11-647-gbf40f0ba95037f235b007a55a7682646a0578b26.
[Bug jit/95314] Sharing a local reference to a global variable in multiple functions results in location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314 --- Comment #7 from David Malcolm --- Created attachment 48615 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48615&action=edit Non-reproducing attempt at a reproducer I attempted to reproduce this, but was unsuccessful. I'm attaching what I have so far (for gcc/testsuite/jit.dg), but annoyingly this runs successfully.
[Bug jit/95314] Sharing a local reference to a global variable in multiple functions results in location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-05-27 --- Comment #10 from David Malcolm --- Thanks; I'm seeing the crash with your reproducer.
[Bug jit/91330] JIT "dir" entry for info is incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91330 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from David Malcolm --- Thanks; should be fixed by above commit.
[Bug jit/95314] Sharing a local reference to a global variable in multiple functions results in location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from David Malcolm --- Should be fixed by the above commit.
[Bug jit/95415] Add support for thread-local variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95415
--- Comment #1 from David Malcolm ---
Perhaps, but it looks non-trivial.
Notes to self:
c/c-tree.h: struct c_declspecs has:
/* Whether "__thread" or "_Thread_local" was specified. */
BOOL_BITFIELD thread_p : 1;
/* Whether "__thread" rather than "_Thread_local" was specified. */
BOOL_BITFIELD thread_gnu_p : 1;
tree.h has:
/* In a VAR_DECL, the model to use if the data should be allocated from
thread-local storage. */
#define DECL_TLS_MODEL(NODE) decl_tls_model (NODE)
/* In a VAR_DECL, nonzero if the data should be allocated from
thread-local storage. */
#define DECL_THREAD_LOCAL_P(NODE) \
((TREE_STATIC (NODE) || DECL_EXTERNAL (NODE)) && decl_tls_model (NODE) >=
TLS_MODEL_REAL)
decl_tls_model/set_decl_tls_model get/set a field of the varpool_node, based on
this enum in coretypes.h:
/* The thread-local storage model associated with a given VAR_DECL
or SYMBOL_REF. This isn't used much, but both trees and RTL refer
to it, so it's here. */
enum tls_model {
TLS_MODEL_NONE,
TLS_MODEL_EMULATED,
TLS_MODEL_REAL,
TLS_MODEL_GLOBAL_DYNAMIC = TLS_MODEL_REAL,
TLS_MODEL_LOCAL_DYNAMIC,
TLS_MODEL_INITIAL_EXEC,
TLS_MODEL_LOCAL_EXEC
};
[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426
--- Comment #1 from David Malcolm ---
gcc_jit_context_dump_reproducer_to_file runs in the testsuite, and I see it
generating sane-looking reproducers (with non-empty create_code functions).
Are you calling gcc_jit_context_dump_reproducer_to_file before or after calling
gcc_jit_context_compile? (or when not calling gcc_jit_context_compile?) I
have a feeling that calling it after an unsuccessful compile might break it
("unsuccessful" in the sense of a compile that generates a non-fatal error but
doesn't crash the process).
Can you attach the result of gcc_jit_context_dump_reproducer_to_file to this
bug please?
Another thing to try might be to use gcc_jit_context_set_logfile and to attach
the resulting logfile (though you may need to flush it and close it and not
call gcc_jit_context_compile).
[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426 --- Comment #3 from David Malcolm --- Aha - thanks. Re-reading https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html#debugging it looks like the documentation for these entrypoints could use some clarification on whether each one relates to the current state of the context, or whether it takes effect when the context is compiled.
[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-05-31 Status|UNCONFIRMED |ASSIGNED --- Comment #4 from David Malcolm --- The reproducer you attached reproduces the crash from comment #0 for me; marking as ASSIGNED. (gdb) call debug(insn) (barrier 29 28 30)
[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426 --- Comment #5 from David Malcolm --- Created attachment 48657 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48657&action=edit Reduced test case I've reduced the reproducer you posted to this test case. Seems to require a call to __builtin_unreachable followed by code, without optimization, leading to a crash in the "expand" pass when transitioning from gimple to RTL internally, due to an unexpected barrier insn in the RTL.
[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426 --- Comment #7 from David Malcolm --- This seems like a bug with how libgccjit interacts with __builtin_unreachable, sorry. As a workaround, try removing the __builtin_unreachable calls for now.
[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426 --- Comment #8 from David Malcolm --- Looks like the way libgccjit sets up attributes (such as "noreturn") on builtins has somehow become a no-op. Am investigating.
[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from David Malcolm --- Should be fixed by the above commit.
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #3 from David Malcolm --- Note to self: GCC's documentation for using asm from C: https://gcc.gnu.org/onlinedocs/gcc/Using-Assembly-Language-with-C.html Thanks for the suggestions. I'm not seeing how the proposed entrypoints in comment #2 would work; sorry. I suspect we'd need to closely mirror the "basic" and "extended" asm approaches from C linked to above (probably using the terms "basic" and "extended" in the entrypoint names, to signal to the developer that that's what the calls would be analogous to). I'm wary about basic asm at the top level (outside functions), given that libgccjit has such an unusual relationship with the rest of the compiler (it might work, but it might have unexpected snags). I think the extended asm would need be along the lines of gcc_jit_block_add_extended_asm (gcc_jit_block *block, ...something...); possibly with and without goto labels. Do you have a specific use-case in mind? Thanks
[Bug jit/95306] Getting __builtin_sadd_overflow gives the error "unimplemented primitive type for builtin: 42"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95306 --- Comment #6 from David Malcolm --- I've added the type; hopefully the builtin works as expected.
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291
--- Comment #7 from David Malcolm ---
(In reply to Andrew Pinski from comment #5)
> (In reply to bouanto from comment #4)
> > So, an example like this:
> >
> > ```c
> > bool old;
> > __asm__ ("btsl %2,%1\n\t" // Turn on zero-based bit #Offset in Base.
> > "sbb %0,%0" // Use the CF to calculate old.
> >: "=r" (old), "+rm" (*Base)
> >: "Ir" (Offset)
> >: "cc");
>
> Could we instead try to get this produced from normal gimple/C code?
Note that this is the example from "6.47.2.3 Output Operands" on
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
I believe bouanto is merely citing it as an example.
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #8 from David Malcolm --- Reading the docs for extended asm, I think the API entrypoint would need to look something like: extern void gcc_jit_block_add_extended_asm (gcc_jit_block *block, int is_volatile, int is_inline, const char *asm_template, int num_output_operands, gcc_jit_asm_operand **output_operands, int num_input_operands, gcc_jit_asm_operand **input_operands, int num_clobbers, const char **clobbers, int num_goto_labels, gcc_jit_block **goto_labels); which is a lot of arguments, and we'd also need a way to create gcc_jit_asm_operand instances. If there are goto_labels, then the asm is implicitly "goto"-qualified; the asm also is treated as potentially falling through to whatever is after it in the block; it doesn't terminated its gcc_jit_block.
[Bug jit/95521] libgccjit.so: error: in build2, at tree.c:4743
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95521 --- Comment #2 from David Malcolm --- (In reply to Andrew Pinski from comment #1) > >libgccjit.so: error: in build2, at tree.c:4743 > > This means the PLUS_EXPR is being used when adding a pointer and an integer > together. It needs to be POINTER_PLUS_EXPR. > > This does not mean the bug is not in the JIT library but it might mean a bug > in your code. A goal of libgccjit is that it shouldn't be possible to generate an ICE by making API calls; so this seems like a violation of that; we either need stronger type-checking at the API boundary, or to be smarter about how we make our trees.
[Bug jit/95521] libgccjit.so: error: in build2, at tree.c:4743
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95521 --- Comment #3 from David Malcolm --- (In reply to bouanto from comment #0) > The reproducer is very big, so tell me if you want me to try to make it > smaller. Yes please! The attachment reproduces the ICE for me, but is too big for me to work with. By adding this: gcc_jit_context_dump_to_file (ctxt_0x7feee9512e00, "/tmp/something.c", 1 /* update_locations */); to immediately after the create call code, it generates "source" locations in the generated /tmp/something.c. By poking in the debugger at the location info: (gdb) p loc->m_recording_loc->m_line $10 = 6773 it shows that the issue is triggered at line 6773, which is here in the dump: repeat_loop_body: *((unsigned char *)loop_var) = returnValue; intLocal = (unsigned long long)1; loop_var += *((unsigned char * *)&intLocal); < HERE goto repeat_loop_header; within extern bool _ZN4core3fmt3num12GenericRadix7fmt_int17h0643c6b8b66acb3dE (struct fmt::num::Binary * param, unsigned int param, struct fmt::Formatter * param) Is it possible for you to use the above info to make a small(er) reproducer? Thanks.
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #13 from David Malcolm --- An alternative approach that reduces the number of params by splitting it into successive calls: extern gcc_jit_extended_asm * gcc_jit_block_add_extended_asm (gcc_jit_block *block, int is_volatile, int is_inline, const char *asm_template); // location? gcc_jit_extended_asm_add_output_operand (gcc_jit_extended_asm *ext_asm, ...something...); gcc_jit_extended_asm_add_input_operand (gcc_jit_extended_asm *ext_asm, ...something...); gcc_jit_extended_asm_add_clobber (gcc_jit_extended_asm *ext_asm, const char *victim); gcc_jit_extended_asm_add_goto_label (gcc_jit_extended_asm *ext_asm, gcc_jit_block *block);
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #14 from David Malcolm --- Or even move the flags to API calls: extern gcc_jit_extended_asm * gcc_jit_block_add_extended_asm (gcc_jit_block *block, const char *asm_template); // location? extern void gcc_jit_extended_asm_set_volatile_flag (gcc_jit_extended_asm *ext_asm, int flag); extern void gcc_jit_extended_asm_set_inline_flag (gcc_jit_extended_asm *ext_asm, int flag);
[Bug jit/95521] libgccjit.so: error: in build2, at tree.c:4743
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95521 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-06-04 Status|UNCONFIRMED |ASSIGNED --- Comment #5 from David Malcolm --- (In reply to bouanto from comment #4) > Here's a smaller bug reproducer. Thanks; this reproduces it for me.
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #16 from David Malcolm --- Created attachment 48677 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48677&action=edit Work-in-progress patch I had a go at implementing this; attached is a work-in-progress prototype. It works for simple cases (albeit with various TODO/FIXME items). See the test case at the end of the patch for two examples of usage. How does it look? Various issues that occurred to me while prototyping this: "gotos"/labels/control flow The new entrypoint "gcc_jit_block_add_extended_asm" in the patch assumes no control flow, and libgccjit enforces a requirement that gcc_jit_blocks are terminated. If there are to be conditional jumps, then I think we need a 2nd entrypoint "gcc_jit_block_end_with_asm" or somesuch that takes an array of gcc_jit_blocks and terminates the gcc_jit_block. Rather than having a jump vs implicitly falling through, you'd have to specify both destination blocks. "Basic" asm Do we actually need "basic" asm (as opposed to extended asm)? In particular I'm wary about asm code that's outside of any given function. Is that needed? asm dialects I'm ignoring this in the prototype. I would prefer not to expose dialect-selection as a first-class entrypoint in the libgccjit API as it touches the interaction with the driver, and libgccjit uses the driver code in a weird way compared with the rest of GCC. Perhaps you'd be able to affect it via e.g. gcc_jit_context_add_driver_option.
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #17 from David Malcolm --- (also uploaded to https://dmalcolm.fedorapeople.org/gcc/2020-06-04/0001-FIXME-WIP-on-extended-asm-support.patch )
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #19 from David Malcolm --- (In reply to bouanto from comment #18) > (In reply to David Malcolm from comment #16) > > Created attachment 48677 [details] > This API looks good. Thanks. [...snip...] > > "Basic" asm > > > > Do we actually need "basic" asm (as opposed to extended asm)? > > In particular I'm wary about asm code that's outside of any given function. > > Is that needed? > > That's something I use in my compiler, so that would be very appreciated if > you could add this. Can you give concrete example(s) please? I'm having trouble thinking through how this would work. [...snip...]
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #21 from David Malcolm --- (In reply to bouanto from comment #20) > Well, there's syntax for assembly at the top-level so the user can enter > anything he wants, like in C. > I can craft you an example if you need to, though. I could use a concrete example of what you might use in C. An issue is ordering: in C, these top-level statements presumably are ordered relative to each other and the function bodies, based on the order they're seen by the parser (though I'm guessing here). Would something similar happen based on the order of calls to gcc_jit_context_new_function?
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 David Malcolm changed: What|Removed |Added Attachment #48677|0 |1 is obsolete|| --- Comment #22 from David Malcolm --- Created attachment 48684 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48684&action=edit Updated work-in-progress patch which adds "asm goto" support Here's an updated version of the patch which adds "asm goto" support. grep for test_i386_basic_asm_3a to see an example. Also uploaded to: https://dmalcolm.fedorapeople.org/gcc/2020-06-05/0001-FIXME-WIP-on-extended-asm-support-v2.patch Does this API make sense?
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #24 from David Malcolm --- (In reply to bouanto from comment #23) > Created attachment 48685 [details] > Example of global assembly [...snip; thanks for the feedback] > I attached an example of global assembly. Thanks. > I don't understand the ordering issue. > I also don't understand how gcc_jit_context_new_function is used here. I see that you have a balanced .pushsection/.popsection pair in your example. Is it ever the case that people might want to have a .pushsection, then some C code, then a .popsection? (and, by analogy, the same for libgccjit rather than C). That's the ordering issue I'm concerned about, since at that point it matters what order the hand-written asm is in relative to the compiler-generated asm.
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #26 from David Malcolm --- (there's also -fno-toplevel-reorder which makes me wonder if we do need to preserve ordering with such constructs)
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 David Malcolm changed: What|Removed |Added Attachment #48684|0 |1 is obsolete|| --- Comment #27 from David Malcolm --- Created attachment 48694 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48694&action=edit v3 of the work-in-progress patch Here's an updated version of the patch; also uploaded to: https://dmalcolm.fedorapeople.org/gcc/2020-06-06/0001-FIXME-WIP-on-extended-asm-support-v3.patch In particular, this adds a new: gcc_jit_context_add_top_level_asm entrypoint. On implementing this, it hooks into the symbol table like the C frontend does, so it looks like it will respect ordering as much as the C frontend does. How does this look? The top-level asm code is barely tested though; I'd appreciate a way to verify it from the automated test case. Changes in v3: * added gcc_jit_context_add_top_level_asm * drop redundant gcc_jit_extended_asm_add_goto_label * added gcc_jit_extended_asm_as_object * started adding documentation * added comments to libgccjit.h * consolidated test-asm.c, grouping create/verify pairs * add test coverage for "volatile" * initial implementation of make_debug_string * added some error-checking
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #28 from David Malcolm --- Generated HTML for docs (albeit without css) here: https://dmalcolm.fedorapeople.org/gcc/2020-06-06/asm-v3.html
[Bug jit/95498] unhandled conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95498 --- Comment #2 from David Malcolm --- Try putting a breakpoint on add_error (there are a few classes with add_error methods; a sufficiently smart gdb ought to put the breakpoint on all of them).
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 David Malcolm changed: What|Removed |Added Last reconfirmed||2020-06-08 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #30 from David Malcolm --- (In reply to Antoni from comment #29) > asm( > "add:\n" > "movq %rdi, %rax\n" > "add %rsi, %rax\n" > "ret\n"); Thanks; I've updated the testcases and examples to use this. I needed to slightly tweak this to allow the dynamic linker to find it, to allow gcc_jit_result_get_code to work.
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 David Malcolm changed: What|Removed |Added Attachment #48694|0 |1 is obsolete|| --- Comment #31 from David Malcolm --- Created attachment 48704 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48704&action=edit v4 of the patch v4 patch, close to being finished (I hope) Also uploaded to: https://dmalcolm.fedorapeople.org/gcc/2020-06-08/0001-FIXME-WIP-on-extended-asm-support-v4.patch C API docs: https://dmalcolm.fedorapeople.org/gcc/2020-06-08/jit-html-docs/topics/asm.html C++ API docs: https://dmalcolm.fedorapeople.org/gcc/2020-06-08/jit-html-docs/cp/topics/asm.html
[Bug other/86904] Column numbers ignore tab characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86904 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from David Malcolm --- Thanks; marking as resolved.
[Bug other/84889] Ideas on revamping how we format diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889 David Malcolm changed: What|Removed |Added Target Milestone|10.3|--- Status|WAITING |NEW --- Comment #24 from David Malcolm --- Clearing the milestone field. I think the only remaining things are (still): > (In reply to David Malcolm from comment #0) > [...] > > * the diagnostic and the followup notes are grouped, so it's easier to pick > > out what messages relate to what > [...] > > IIRC, clang does something where the left-hand column is only non-empty for > > the start of a diagnostic; followup lines (e.g. due to line wrapping) are > > indented by 1 char, so that the "wall of text" is broken up somewhat > [...]
[Bug analyzer/96374] New: Analyzer erroneously rejects certain diagnostics due to path-feasibility being used on shortest path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96374
Bug ID: 96374
Summary: Analyzer erroneously rejects certain diagnostics due
to path-feasibility being used on shortest path
Product: gcc
Version: 11.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: ---
Analyzer fails to find a path to the __analyzer_dump_path call:
#include "analyzer-decls.h"
int test_6 (int a, int b)
{
int problem = 0;
if (a)
problem = 1;
if (b)
{
if (!problem)
problem = 2;
__analyzer_dump_path (); /* { dg-message "path" "" { xfail *-*-* } } */
}
return problem;
}
It's rejecting the path due to picking the shortest path, and then a bad
interaction with feasibility-checking.
If feasibility-checking is hacked out, it picks this path (with
-fanalyzer-verbosity=3 for clarity):
‘test_6’: events 1-7
|
|6 | if (a)
| | ^
| | |
| | (1) following ‘false’ branch (when ‘a == 0’)...
|7 | problem = 1;
|8 | if (b)
| | ~
| | |
| | (2) ...to here
| | (3) following ‘true’ branch (when ‘b != 0’)...
|9 | {
| 10 | if (!problem)
| | ~
| | |
| | (4) ...to here
| | (5) following ‘false’ branch (when ‘problem != 0’)...
| 11 | problem = 2;
| 12 | __analyzer_dump_path ();
| | ~~~
| | |
| | (6) ...to here
| | (7) here
|
However, with feasibility-checking, "problem" is still 0 at event (5) (due to
the shortest path skipping the "problem = 1" suite), and hance the "problem !=
0" edge is invalid, and the edge from (5) to (6) is rejected, and the
diagnostic rejected.
We want the shortest feasible path if one exists, and are currently
approximating this by picking the shortest path, and checking if it's feasible,
which isn't the same thing.
Am not sure how best to fix this, but need a PR to mark this as XFAIL.
[Bug analyzer/96374] Analyzer erroneously rejects certain diagnostics due to path-feasibility being used on shortest path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96374 --- Comment #1 from David Malcolm --- This is likely to be associated with "merger" exploded_nodes (where we have merged state to help the exploded graph converge). Perhaps if we fail to find a feasible path on the first try we could retry, finding the shortest path that doesn't include each merger node in turn, and if any of those are feasible, find the shortest one.
[Bug analyzer/96395] gcc.dg/analyzer/explode-2.c fails when compiled as C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96395 --- Comment #1 from David Malcolm --- Thanks for filing this. FWIW I've spent the last 4 months rewriting the state-tracking heart of the analyzer, with a patch kit I hope to land next month. Along with many other changes, explode-2.c changes behavior significantly in my new implementation. It sounds like we might have to coordinate on how we get our changes into trunk. I believe that that test case currently isn't compiled with g++. Are you changing that? Feel free to special-case it if need be if you need that to get your changes in.
[Bug analyzer/93032] analyzer fails to detect FILE * leak in zlib/contrib/minizip/mztools.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93032 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from David Malcolm --- The missing leak diagnostics should be fixed by 808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug analyzer/93938] ICE in validate, at analyzer/region-model.cc:231
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93938 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from David Malcolm --- The ICE should be fixed by 808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug analyzer/94011] ICE in validate, at analyzer/region-model.cc:3727
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94011 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from David Malcolm --- The ICE should be fixed by 808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug analyzer/94399] analyzer reports false positives for stuff freed using __attribute__((cleanup()))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94399 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED CC||dmalcolm at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from David Malcolm --- The leak false positive should be fixed by g:808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug analyzer/94458] -Wanalyzer-malloc-leak false positive when returning a heap-allocated struct by value holding a heap-allocated pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94458 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- The leak false positive should be fixed by g:808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug analyzer/94640] false-positive leaking FILE pointer assigned to function passed pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94640 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from David Malcolm --- The leak false positive should be fixed by g:808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug analyzer/94839] False positive with -fanalyzer and direct field assignment from calloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94839 Bug 94839 depends on bug 94640, which changed state. Bug 94640 Summary: false-positive leaking FILE pointer assigned to function passed pointer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94640 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug analyzer/94503] ICE on C++ return-value-optimization (in saved_diagnostic, at analyzer/diagnostic-manager.cc:84)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94503 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from David Malcolm --- The ICE (on C++ return-value-optimization) should be fixed by g:808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug analyzer/94688] ICE caused by analyzer since r10-7502-ga96f1c38a787fbc8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94688 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from David Malcolm --- The ICE should be fixed by g:808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug analyzer/94689] arrays of functions are not meaningful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94689 David Malcolm changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from David Malcolm --- The bogus "arrays of functions are not meaningful" error from -fanalyzer should be fixed by g:808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug analyzer/94858] False report of memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94858 Bug 94858 depends on bug 94839, which changed state. Bug 94839 Summary: False positive with -fanalyzer and direct field assignment from calloc https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94839 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug analyzer/94839] False positive with -fanalyzer and direct field assignment from calloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94839 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from David Malcolm --- The leak false positive should be fixed by g:808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug analyzer/95026] "leak of FILE" false positive [CWE-775] [-Wanalyzer-file-leak]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95026 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from David Malcolm --- The leak false positive should be fixed by g:808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug analyzer/95042] ICE in can_merge_p, at analyzer/region-model.cc:2053
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95042 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from David Malcolm --- The ICE should be fixed by g:808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug analyzer/95240] calloc() false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95240 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from David Malcolm --- Thanks for filing this bug. The leak false positive should be fixed by g:808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as fixed.
[Bug analyzer/96598] false NULL argument warning [-Wanalyzer-null-argument]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96598 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-08-13 --- Comment #1 from David Malcolm --- Thanks for filing this bug. I can reproduce it, but it looks like I fixed it in g:808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). I'll close this out once I've added a regression test for it.
