https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537
--- Comment #1 from David Malcolm ---
Am trying to reproduce locally, but when I run this in my BUILDDIR/gcc:
./gdc -B. -S -fanalyzer oob.d
I get:
d21: error: cannot find source code for runtime library file 'object.d'
Possibly a silly que
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116143
--- Comment #1 from David Malcolm ---
Sorry about this.
Demangling,
_ZNK22simple_diagnostic_path10num_eventsEv
is
simple_diagnostic_path::num_events() const
which is a vfunc implemented in gcc/simple-diagnostic-path.o
My guess is that not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115970
--- Comment #3 from David Malcolm ---
>From what I can tell, in Microsoft's implementation the JSON-RPC messages are
being "packaged" or "framed" via LSP's base protocol, as per:
https://microsoft.github.io/language-server-protocol/specificatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116143
--- Comment #5 from David Malcolm ---
(In reply to David Malcolm from comment #1)
[...snip...]
> My guess is that nothing is using class simple_diagnostic_path in cc1, and
> thus the code for simple_diagnostic_path is being dropped by the linker
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Sam's been doing great work lately fixing malformed dg directives in our
testsuite.
We chatted briefly on IRC about
ormal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Currently our SARIF output only captures fix-it hints on the top-level
diagnostic in a group. Followup notes within a group are
SARIF
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Consider:
namespace ns {
class foo
{
void bar ()
{
retu
Status: UNCONFIRMED
Keywords: SARIF
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
When the compilation fails with an error, the SARIF outp
SARIF
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
We have:
std::uniqu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116228
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2024-08-05
Status|UNCONFIRM
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
There's an interesting proposal from Sy Brand here:
P3358R0: SARIF for Structured Diagnostics
https://www.open-std.org/jtc1/sc22/wg21/docs/p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116253
David Malcolm changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116253
--- Comment #2 from David Malcolm ---
Created attachment 58852
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58852&action=edit
Output from attachment 58851 with -fconcepts-diagnostics-depth=3 -std=c++20
-fdiagnostics-format=sarif-file on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115970
--- Comment #4 from David Malcolm ---
Created attachment 58854
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58854&action=edit
WIP patch to output diagnostics as SARIF notifications to a unix domain socket
The attached patch is very much
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115970
David Malcolm changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116177
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Our machine-readable diagnostic output doesn't include information on macro
expansions.
It would be ni
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Our SARIF output code is currently hardcoded to emit version 2.1.0 of SARIF.
2.2 isn't out yet, but has gained some features we might want to use, su
NCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
gcc/testsuite/c-c++-common/analyzer/malloc-CWE-401-example.c has:
return NULL; /* TODO: shoul
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Similar to RFE 116300 (which is for macro expansions), our textual output can
report inlining information for middle-end warnings, but our
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
GCC diagnostic messages can contain URLs, but I believe we're currently
dropping them on the floor when emitting SARIF.
See "3.11.6 Mes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116419
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116419
--- Comment #2 from David Malcolm ---
Filed https://github.com/oasis-tcs/sarif-spec/issues/656 with the spec about
escaping of link text.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116419
--- Comment #3 from David Malcolm ---
Filed https://github.com/oasis-tcs/sarif-spec/issues/657 about possible need to
escape URIs within embedded links.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116419
--- Comment #4 from David Malcolm ---
Filed https://github.com/oasis-tcs/sarif-spec/issues/658 about ambiguity with
'[' literals in plaintext messages.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110522
David Malcolm changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110522
--- Comment #4 from David Malcolm ---
I wonder if extending -fdiagnostics-format to support extra args would be a way
out of this e.g.
-fdiagnostics-format=sarif-file=path/to/foo.sarif
But it would also be nice to support multiple output str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116419
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
I have an experimental patch that uses libbacktrace to scrape a backtrace, turn
it into JSON values, and add it to SARIF output on an
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Currently we're using:
#define SARIF_SCHEMA
"https://raw.githubusercontent.com/oasis-tcs/sarif-spec/master/Schemata/sarif-schema-2.1.0.j
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Currently there is a single diagnostic output format, specified via
-fdiagnostics-format=.
It would be nice if it were possible to
Keywords: SARIF
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: dmalcolm at gcc dot gnu.org
Blocks: 116613
Target Milestone: ---
I notice that d_diagnostic_report_diagnostic has:
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116173
--- Comment #2 from David Malcolm ---
Thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116603
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2024-09-10
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116060
--- Comment #1 from David Malcolm ---
https://godbolt.org/z/jrqEKfsd1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111567
--- Comment #3 from David Malcolm ---
FWIW I posted some ideas about this here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653719.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111567
--- Comment #4 from David Malcolm ---
Perhaps a lot of this could be handled by teaching the analyzer about the
.ACCESS_WITH_SIZE internal func (that wraps an access, annotating it with size
info)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87588
--- Comment #2 from David Malcolm ---
FWIW here's the reproducer in Compiler Explorer:
https://godbolt.org/z/54KzMcasP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87588
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
Keywords: SARIF
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
CC: hp at gcc dot gnu.org
Target Milestone: ---
We were chatting about this at Cauldron
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116724
--- Comment #1 from David Malcolm ---
I tried this for some examples; consider:
$ LANG=C ./xgcc -B. ../../src/gcc/testsuite/gcc.dg/format/sentinel-1.c
-fdiagnostics-format=text -Wall -S -fdiagnostics-format=text
../../src/gcc/testsuite/gcc.dg/f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116724
--- Comment #2 from David Malcolm ---
See e.g. §3.19.4 "Translations"
https://docs.oasis-open.org/sarif/sarif/v2.1.0/errata01/os/sarif-v2.1.0-errata01-os-complete.html#_Toc141790787
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116724
--- Comment #3 from David Malcolm ---
Note to self:
499 diagnostic_set_info (diagnostic_info *diagnostic, const char *gmsgid,
500 va_list *args, rich_location *richloc,
501 diagnostic_t kind)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116724
--- Comment #5 from David Malcolm ---
(In reply to Hans-Peter Nilsson from comment #4)
> (In reply to David Malcolm from comment #1)
>
> > Perhaps we should try to capture both the untranslated text and the
> > translated text? SARIF has vario
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116724
--- Comment #6 from David Malcolm ---
(In reply to David Malcolm from comment #5)
[...]
> (the SARIF spec's tutorial doesn't seem to cover translations yet)
FWIW I've requested this as
https://github.com/microsoft/sarif-tutorials/issues/40
[..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116724
--- Comment #7 from David Malcolm ---
(In reply to Hans-Peter Nilsson from comment #4)
> (In reply to David Malcolm from comment #1)
>
> > Perhaps we should try to capture both the untranslated text and the
> > translated text? SARIF has vario
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85716
--- Comment #15 from David Malcolm ---
Brainstorming some ideas here:
LSP has an interface for reporting progress notifications; see:
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workDoneProgress
T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85716
David Malcolm changed:
What|Removed |Added
Ever confirmed|1 |0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109097
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109094
--- Comment #4 from David Malcolm ---
(In reply to Martin Liška from comment #3)
> Fixed?
Sadly no, the comment above is just to mention that at least the crash is now
captured in the .sarif dump.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109094
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2023-03-16
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
David Malcolm changed:
What|Removed |Added
Last reconfirmed|2023-01-30 00:00:00 |2023-03-16
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
--- Comment #8 from David Malcolm ---
Note that section 3.1 ("File Format" > "General") specifies:
"A SARIF log file SHALL be encoded in UTF-8 [RFC3629]."
https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html
Though I suppose it wo
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
gcc/json.cc's json::object uses a hash_map for tracking the key/value pairs,
and object::print iterates through them in arbitrary orde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
--- Comment #9 from David Malcolm ---
(In reply to David Malcolm from comment #7)
[...snip...]
> There some variation due to json::object using a hash_map for the key/value
> pairs, which means (annoyingly) it outputs things in arbitrary order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109163
--- Comment #1 from David Malcolm ---
This would also help with one of the requests from a SARIF expert's review of
GCC's output:
https://github.com/oasis-tcs/sarif-spec/issues/531#issuecomment-1181191100
which is that the "version" property
||2023-03-16
Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #2 from David Malcolm ---
I'm working on a fix for this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
--- Comment #11 from David Malcolm ---
(In reply to Hans-Peter Nilsson from comment #10)
> (I see an identifier using ideographs?
> Wouldn't want to review that code... Might as well use Linear A -which you
> indeed can in UTF-8- - it's all gr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
--- Comment #12 from David Malcolm ---
Thanks for the ideas. If I hack in the following into dg-scan (to force the
scanned file to be treated as UTF-8 as it is read), then the existing case
works with both:
LC_ALL=C
LC_ALL=en_US.UTF-8
so p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
--- Comment #13 from David Malcolm ---
Created attachment 54698
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54698&action=edit
Patch that I'm about to put through full testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109163
David Malcolm changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109094
David Malcolm changed:
What|Removed |Added
Attachment #54637|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109094
--- Comment #7 from David Malcolm ---
Trunk: https://godbolt.org/z/MKh4h1ccP
12.2: https://godbolt.org/z/73EY4TMcx (no ICE, but assertions likely disabled)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109094
--- Comment #8 from David Malcolm ---
Created attachment 54700
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54700&action=edit
Patch that I'm about to put through full testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109094
David Malcolm changed:
What|Removed |Added
Keywords|ice-checking|
Target Milestone|13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109201
--- Comment #1 from David Malcolm ---
The division by zero warning on:
if ((d.b = 1) / 0)
is from -Wdiv-by-zero, which isn't from the analyzer (
https://godbolt.org/z/433PhKhvM )
The analyzer currently only implements -Wanalyzer-tainted-divi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109201
--- Comment #2 from David Malcolm ---
*** Bug 109200 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109200
David Malcolm changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99669
David Malcolm changed:
What|Removed |Added
CC||geoffreydgr at icloud dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109201
David Malcolm changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109191
--- Comment #1 from David Malcolm ---
GCC does emit a -Wint-to-pointer-cast warning on this code, for the int to void
* conversion.
Is this reduced from a real-world example, or just synthesized by hand?
I suppose in theory the analyzer could:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109194
--- Comment #1 from David Malcolm ---
Well, strictly speaking not all of these are true; consider
a == INT_MAX
b == INT_MAX - 1
Then a > b, but:
* a + 1 is, I believe, undefined, but we may want to treat it as INT_MIN
* b + 1 is INT_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109193
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940
David Malcolm changed:
What|Removed |Added
CC||geoffreydgr at icloud dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940
--- Comment #2 from David Malcolm ---
*** Bug 109194 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109194
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109195
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940
--- Comment #3 from David Malcolm ---
*** Bug 109195 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109196
David Malcolm changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109197
David Malcolm changed:
What|Removed |Added
Summary|GCC Static Analyzer does|Analyzer gets confused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109191
--- Comment #2 from David Malcolm ---
It is valid in the embedded space to do things like
*(SOME_CONSTANT_ADDRESS) = SOME_VALUE;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109199
David Malcolm changed:
What|Removed |Added
Summary|GCC Static Analyzer |GCC Static Analyzer
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
David Malcolm changed:
What|Removed |Added
Keywords||patch
URL|
IRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
https://gcc.gnu.org/pipermail/gcc/2023-March/240928.html reports:
> there is no error or warnin
: 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 54724
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54724&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109239
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
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 54734
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54734&action=edit
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Currently the analyzer uses its widening_svalue and complexity limits on
svalues/regions to attempt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109098
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109266
--- Comment #1 from David Malcolm ---
Thanks for filing this bug.
We probably want to allow accesses to hard-coded addresses, for the case of
embedded development, so we presumably need some way to distinguish between
accesses of:
((struct fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109098
--- Comment #9 from David Malcolm ---
(In reply to Hans-Peter Nilsson from comment #8)
> (In reply to David Malcolm from comment #7)
> > The invalid UTF-8 in the patch seems to have broken the server-side script:
>
> Maybe the not-really-utf8 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109266
--- Comment #3 from David Malcolm ---
(In reply to Jonny Grant from comment #2)
> Thank you for your reply David. Your analyzer is very good already.
>
> I played around a bit, a base of nullptr doesn't give a warning. But
> changing to 0x10 do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109266
--- Comment #4 from David Malcolm ---
(In reply to David Malcolm from comment #3)
> (In reply to Jonny Grant from comment #2)
[...]
> >
> > I wondered if you know how to turn on that "cc1plus: note: source object is
> > likely at address zero?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107002
--- Comment #4 from David Malcolm ---
Created attachment 54778
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54778&action=edit
Untested patch
(In reply to Jakub Jelinek from comment #3)
> David, any progress here?
I've currently testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107002
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109094
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105784
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107345
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108562
Bug 108562 depends on bug 107345, which changed state.
Bug 107345 Summary: -Wanalyzer-null-dereference false positive with giving
weird path infomation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107345
What|Removed
3001 - 3100 of 3524 matches
Mail list logo
