https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93388
--- Comment #24 from David Malcolm ---
As noted in https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556203.html
I was able to bootstrap using the method described in comment #0, albeit taking
7 hours (compared to the 45 minutes it normally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97489
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from David Malco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94169
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97514
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2020-10-21
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97489
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97514
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97568
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97568
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97608
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97411
--- Comment #1 from David Malcolm ---
Looks like a dup of PR 97090 (though that one is on arm).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97621
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090
David Malcolm changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090
--- Comment #5 from David Malcolm ---
PR 97621 reports it as starting on powerpc64*-linux-gnu with r11-4434, which
was a fix for non-determinism in -fanalyzer, so perhaps this is a flaky test
that the non-determinism fixes have made fail more rel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090
--- Comment #6 from David Malcolm ---
(In reply to Christophe Lyon from comment #1)
> I see random results from one run to another, so it's likely that something
> is not initialized correctly.
I think it's due to places in -fanalyzer that iterat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090
--- Comment #7 from David Malcolm ---
*** Bug 97411 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97411
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97614
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608
David Malcolm changed:
What|Removed |Added
CC||brechtsanders at users dot
sourcef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608
--- Comment #14 from David Malcolm ---
(In reply to David Malcolm from comment #7)
> (In reply to Andrew Pinski from comment #6)
> > What I mean is if you ever traversing a hashtable, the hash should not use
> > the value of a pointer because it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97608
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090
--- Comment #8 from David Malcolm ---
I tested with a cross build on x86_64-pc-linux-gnu with
target==powerpc64-unknown-linux-gnu after various fixes for non-determinism
(g:f635f0ce87d687b177b734968f18226d50499e75) and I'm not seeing the bogus
di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97668
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97668
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97424
--- Comment #5 from David Malcolm ---
The above commit implements it as an analyzer warning. Should I close this
out, or should we keep it open for the __builtin_warning approach?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93067
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97867
David Malcolm changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96089
--- Comment #1 from David Malcolm ---
gcc_jit_global_set_initializer was added in GCC 11, which can initialize some
global variables.
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
>From an email from a user:
> -Wanalyzer-possible-null-dereference reports CWE-690. If we
> know that the NULL is t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97893
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
-combination.c.exe |thunk_info::release breaks
|test-functions.c.exe|function calls in libgccjit
|test-pr66779.c.exe |
|test-threads.c.exe killed |
Assignee|dmalcolm at gcc dot gnu.org|hubicka at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97867
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98293
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97115
--- Comment #1 from David Malcolm ---
"Static Initialization Order Fiasco"
https://en.cppreference.com/w/cpp/language/siof
https://isocpp.org/wiki/faq/ctors#static-init-order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97169
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97111
--- Comment #1 from David Malcolm ---
References:
https://en.cppreference.com/w/cpp/language/exceptions
https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html ("Itanium C++ ABI:
Exception Handling")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96646
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96841
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94433
--- Comment #1 from David Malcolm ---
Thanks for filing this. I've been attempting to reproduce this, but I'm not
getting any warnings out of cppcheck.
That said, looking at
git show
a96f1c38a787fbc847cb014d4b094e2787d539a7:gcc/analyzer/diagn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94433
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2020-09-28
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97233
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94433
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #4 from David Malcol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863
Bug 89863 depends on bug 94433, which changed state.
Bug 94433 Summary: enhancement: 12 * constify some parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94433
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94433
David Malcolm changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95188
--- Comment #5 from David Malcolm ---
Thanks Mark. What architecture are you on?
When I do those steps, there's a long wait and then in terminates with no
analyzer output.
If I add -Wanalyzer-too-complex I see lots of warnings about "terminati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95188
--- Comment #7 from David Malcolm ---
Thanks. I see a similar deluge of
"terminating analysis for this program point"
warnings, but at different locations.
My warnings eventually terminate with:
bzip2.c:1537:31: warning: analysis bailed ou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95188
--- Comment #9 from David Malcolm ---
The above patch fixes (a) from comment #7 above, but (b), (c) and (d) still
need fixing, so keeping this open for now.
: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
If a function is "static" we only look inside it if it gets directly called by
a non-static function in the TU; we don't consider callbacks that get
registe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94527
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97116
--- Comment #1 from David Malcolm ---
The C++ FE has %P for printing parm indices, with index < 0 printed as "this";
implemented in cp/error.c: parm_to_string as called from cp_printer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97116
--- Comment #2 from David Malcolm ---
(using "i - is_method" as the value)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97116
--- Comment #3 from David Malcolm ---
is_method seems to be set by:
if (TREE_CODE (TREE_TYPE (fn)) == METHOD_TYPE)
so perhaps we can simply reimplement this logic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97116
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97110
Bug 97110 depends on bug 97116, which changed state.
Bug 97116 Summary: Fix argument numbering in C++ member function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97116
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95188
--- Comment #11 from David Malcolm ---
(In reply to Mark Wielaard from comment #10)
> Created attachment 49293 [details]
> supergraph
Thanks. Compared to my testing, I'm seeing what appear to be differences in
the inputs to the analyzer at the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98223
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98293
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98223
--- Comment #2 from David Malcolm ---
I believe the existing false positive may relate to bug 97072, where the
analyzer doesn't capture that the pointer to the malloc-ed buffer has been
written to one of the fields (perhaps due to state-merging),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98223
--- Comment #3 from David Malcolm ---
i.e. it rejects the path as infeasible since p_2 needs to be NULL and then
non-NULL for the path conditions to be satisfied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98073
David Malcolm changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98223
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97072
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98564
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97074
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98564
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98580
David Malcolm changed:
What|Removed |Added
Summary|ICE with -fanalyzer and |ICE with -fanalyzer when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98580
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98586
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98599
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98599
--- Comment #2 from David Malcolm ---
As far as I can tell, there are two invocations of lto1: wpa, then ltrans.
The analyzer is run in the first invocation.
The analyzer updates the gimple stmt uids; if I disable this updating the crash
doesn'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98599
--- Comment #4 from David Malcolm ---
I set them so that each stmt has a unique id, unique across all functions. I
was assuming from the comments I quoted above in gimple.h that this is safe to
do, but it sounds like from your comment that WPA m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98628
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from David Malco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98586
--- Comment #3 from David Malcolm ---
Patch posted as
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563266.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98628
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98599
--- Comment #6 from David Malcolm ---
(In reply to Martin Liška from comment #5)
> @David: Can you really reproduce that on x86_64-linux-gnu (I can't for some
> reason)?
Yes (with current master e.g. cfaaa6a1ca744c1a93fa08a3e7ab2a821383cac1), usi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98599
--- Comment #8 from David Malcolm ---
Saving and restoring the uids fixes the issue, so I'm working on a patch to the
analyzer pass to do that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98599
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #9 from David Malcol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98679
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from David Malco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98679
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98586
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
|1
Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #2 from David Malcolm ---
Sorry, I introduced this in g:f10960558540636800cf5d3d6355969621fbc17e.
I didn't consider
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98696
--- Comment #3 from David Malcolm ---
Created attachment 49976
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49976&action=edit
Patch to fix the failing selftest
Does the attached patch fix the build on Windows hosts?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98696
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
us: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Most of the jit.exp testsuite is failing, where the tests fail on 3rd
in-process iteration, wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98751
--- Comment #1 from David Malcolm ---
s/generations/generation/g
t;`.Ldebug_loc2' is
|defined" asm error |already defined" asm error
Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #3 from David Malcolm ---
(In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98751
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98819
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98830
--- Comment #1 from David Malcolm ---
Why is it a false positive? The call to p->f () is a call to
B* B::f ();
and that could return NULL, hence the call to C::g would be passing NULL as
'this'.
Arguably the message would be more readable as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98830
--- Comment #2 from David Malcolm ---
I looked at your examples in bug 98646, and the analyzer seems to me to be
working correctly.
Specifically:
Analyzer correctly doesn't warn for:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98646#c5
Anal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98830
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2021-01-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93355
--- Comment #4 from David Malcolm ---
Current status is that there is testcase coverage for this in git, but the test
requires:
/* { dg-additional-options "-Wno-analyzer-too-complex
-fno-analyzer-feasibility" } */
(a) It happens to successfu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98294
David Malcolm changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot
gnu.org
at gcc dot gnu.org |dmalcolm at gcc dot
gnu.org
--- Comment #4 from David Malcolm ---
Mine
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Reported to me via email:
> gcc -fanalyzer for the sample code below gives false positive results.
> If I remove field re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98918
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98918
David Malcolm changed:
What|Removed |Added
Summary|Analyzer false positives|[11 Regression] Analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98918
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
2001 - 2100 of 3523 matches
Mail list logo
