https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93355
--- Comment #7 from David Malcolm ---
(In reply to CVS Commits from comment #6)
> The master branch has been updated by David Malcolm :
>
> https://gcc.gnu.org/g:8a2750086d57d1a2251d9239fa4e6c2dc9ec3a86
>
> commit r11-7029-g8a2750086d57d1a2251d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97932
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98575
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2021-02-04
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97932
David Malcolm changed:
What|Removed |Added
Summary|[8/9/10/11 Regression] |[8/9/10 Regression]
|P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98575
--- Comment #2 from David Malcolm ---
This turns out to be due to differences in the inline implementation of getchar
in which expose a latent bug in leak-detection.
On my x86_64 Fedora 32 box,
/usr/include/bits/stdio.h is from glibc-headers-2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98575
--- Comment #3 from David Malcolm ---
The pertinent glibc commit was:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=26c07172cde74617ca7214c93cdcfa75321e6b2b
("Remove getc and putc macros from the public stdio.h.", 2018-02-06).
It's list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98575
--- Comment #4 from David Malcolm ---
The false leak bug appears to very similar to PR analyzer/97072.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98969
David Malcolm changed:
What|Removed |Added
Assignee|msebor at gcc dot gnu.org |dmalcolm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
--- Comment #11 from David Malcolm ---
FWIW I had another go at reproduing this, but after various failures due to
running out of disk space, I was able to rebuild the SRPM from comment #0
without seeing the crash, via:
mock --rebuild mingw-wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99028
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99028
--- Comment #2 from David Malcolm ---
At -fanalyzer-verbosity=1 and below, we only show those two events:
In function ‘add_to_trie’:
../../src/gcc/testsuite/gcc.dg/analyzer/pr99028.c:175:28: warning: dereference
of possibly-NULL ‘child’ [CWE-690
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98575
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99042
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Summary|file-leak is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99044
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99042
--- Comment #3 from David Malcolm ---
(In reply to Antonio Chirizzi from comment #2)
> just curious of what you mean with "unknown function". Is it something that
> has not been declared or is not known to the compiler up to that point?
A functi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
--- Comment #13 from David Malcolm ---
(In reply to Michael Cronenworth from comment #12)
> That's the Linux GCC. You will want to see the version for MinGW:
> mingw-gcc-9.2.1-6.fc32 - which does not crash so I'm not surprised you
> didn't crash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
--- Comment #14 from David Malcolm ---
(In reply to David Malcolm from comment #13)
> $ rpm -q mock
> mock-2.3-1.fc32.noarch
Sorry, my bad; I had quite an old mock. I've upgraded, and the build is now
progressing beyond that point.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
--- Comment #15 from David Malcolm ---
#0 fancy_abort (file=0x95b0ab6 "../../libcpp/line-map.c", line=1359,
function=0x95b0ace "linemap_compare_locations")
at ../../gcc/diagnostic.c:1778
#1 0x08fcbecf in linemap_compare_locations (set=0xf7f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2021-02-10
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
--- Comment #19 from David Malcolm ---
(In reply to David Malcolm from comment #18)
> Converting one of both of those "const" and "void" to non-macros ought to
"one or both", I meant to say
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99064
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
David Malcolm changed:
What|Removed |Added
Summary|[10/11 Regression] ICE in |[10 Regression] ICE in
||dmalcolm at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #3 from David Malcolm ---
This does indeed look like a duplicate of bug 96391; note the missing column
number, and the two declspecs in different macros here:
/x/bcm_sdk/sdk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
--- Comment #22 from David Malcolm ---
*** Bug 96940 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021
--- Comment #17 from David Malcolm ---
One aspect of the original case in comment #0 that hasn't been mentioned in
this discussion is that the two #warning messages are related to each other.
It looks to me like the author of those lines intende
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93109
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99064
David Malcolm changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98969
--- Comment #9 from David Malcolm ---
*** Bug 99064 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98969
--- Comment #11 from David Malcolm ---
As noted above, the ICE is fixed, but the leak false positive is not yet fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96395
--- Comment #3 from David Malcolm ---
Sandra: what is the status of your loop unification changes?
FWIW, I'm not able to reproduce this issue with trunk. Note that
g:fd111c419d146ee47c7df9a36a535e8d843d4802 fixed a state-explosion bug in how
sw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96395
--- Comment #4 from David Malcolm ---
(In reply to David Malcolm from comment #3)
> FWIW, I'm not able to reproduce this issue with trunk. Note that
> g:fd111c419d146ee47c7df9a36a535e8d843d4802 fixed a state-explosion bug in
> how switch stateme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98969
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94362
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2021-02-17
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94362
--- Comment #2 from David Malcolm ---
Oops; I was wrong; this isn't yet fixed on trunk. I can reproduce this with
the attachment. It also reports warnings from -Wanalyzer-too-complex.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93773
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93773
--- Comment #5 from David Malcolm ---
Specifically:
+--> ‘make_assignable’: events 5-6
|
| 5352 | make_assignable(INSTRUCTION *ip)
| | ^~~
| | |
| | (5) entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94596
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94596
David Malcolm changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126
--- Comment #3 from David Malcolm ---
Created attachment 50216
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50216&action=edit
Minimal reproducer as a test case
Attached is a minimal reproducer, as a test case. I don't have a fix for thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from David Malco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126
--- Comment #7 from David Malcolm ---
(In reply to Andrea Corallo from comment #5)
> As a side question: do you guys think disabling "isolate-paths" is the
> right workaround for the affected versions or might have harmful side
> effects?
It oug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126
--- Comment #8 from David Malcolm ---
(In reply to CVS Commits from comment #6)
> The master branch has been updated by David Malcolm :
>
> https://gcc.gnu.org/g:b258e263e0d74ca1f76aeaac5f4d1abef6b13707
>
> commit r11-7288-gb258e263e0d74ca1f76a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99196
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2021-02-22
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99196
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
The analyzer currently has no knowledge of the behavior of "realloc" (leading
e.g. to bug 99193).
For example, it currently fails to issue a warning for the cla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193
--- Comment #7 from David Malcolm ---
I'm testing a workaround for this; I've filed bug 99260 to cover other issues
with realloc(3) in the analyzer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193
--- Comment #11 from David Malcolm ---
BTW, looking at the
#pragma GCC diagnostic ignored "-Wanalyzer-null-argument"
at
https://github.com/libguestfs/libguestfs/blob/f19fd566f6387ce7e4d82409528c9dde374d25e0/df/main.c#L317
I'm guessing that thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212
--- Comment #2 from David Malcolm ---
Failing test is in test_45 at:
__analyzer_eval (bits.b0 == 1); /* { dg-warning "TRUE" "desired" { xfail
*-*-* } } */
/* { dg-warning "UNKNOWN" "status quo" { target *-*-* } .-1 } */
x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212
--- Comment #3 from David Malcolm ---
(In reply to David Malcolm from comment #2)
> x86_64-pc-linux-gnu has:
I messed up the copy and paste here; the x86_64 gimple actually reads:
bits.b0 = 1;
_1 = BIT_FIELD_REF ;
_2 = _1 & 1;
_3 = _2 !
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212
--- Comment #5 from David Malcolm ---
Possibly a dumb question, but how am I meant to get at the size in bits of a
bitfield? TYPE_SIZE appears to be expressed in bytes, rather than bits (or
maybe I messed up when debugging?)
On a 1-bit unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212
--- Comment #6 from David Malcolm ---
Answering my own question:
https://gcc.gnu.org/onlinedocs/gccint/Types.html
INTEGER_TYPE
Used to represent the various integral types, including char, short, int,
long, and long long. This code is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100540
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
ormal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
clang's static analyzer found this leak on an error-handling path:
https://github.com/stackpath/rxtxcpu/pull/42
which gcc&#x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100615
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100688
--- Comment #6 from David Malcolm ---
Thanks for the patch; I like the idea; various nits below:
> diff --git a/gcc/jit/docs/topics/expressions.rst
> b/gcc/jit/docs/topics/expressions.rst
> index 396259ef07e..b39f6c02527 100644
> --- a/gcc/jit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100688
--- Comment #7 from David Malcolm ---
One other thing: the docs should make it clear about the leading ".".
If I want to create the equivalent of:
__attribute__((section(".section")))
do I call it with:
gcc_jit_lvalue_set_link_section(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100705
David Malcolm changed:
What|Removed |Added
Summary|warn about dead store |RFE: warn about dead store
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212
David Malcolm changed:
What|Removed |Added
Summary|[11/12 Regression] |[11 Regression]
|gcc.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100904
--- Comment #3 from David Malcolm ---
FWIW the following hackish workaround seems to fix it, though am still
investigating why this is happening.
diff --git a/libcpp/directives.c b/libcpp/directives.c
index f4aa17d1156..b5bdd443a5a 100644
--- a
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Looking at gcc.dg/analyzer/explode-2.c, it appears that it treats the SSA names
for the results of the two "get" calls a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212
--- Comment #18 from David Malcolm ---
(In reply to Stefan Schulze Frielinghaus from comment #17)
> The new testcases introduced by commit d3b1ef7a83c fail on IBM Z as well as
> some older data-model tests:
Sorry about this; it sounds similar to
: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Fedora's build of GCC showed some new analyzer failures:
+FAIL: gcc.dg/analyzer/analyzer-verbosity-2a.c (test for e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101081
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2021-06-15
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101082
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101082
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101143
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from David Malc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101143
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
libstdc++-v3/doc/html/manual/policy_based_data_structures_test.html
has this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
Severity: normal
Priority: P3
Component: middle-end
Assignee: msebor at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573695.html reports
On Li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101216
David Malcolm changed:
What|Removed |Added
Summary|[12 regression] |[12 regression]
|setj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108251
--- Comment #1 from David Malcolm ---
Created attachment 54219
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54219&action=edit
Simplified reproducer for smp_fetch_ssl_fc_has_early
Thanks for filing this bug. I see the warnings, and have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108251
--- Comment #2 from David Malcolm ---
With trunk and -Wno-address-of-packed-member -O2, I get:
../../src/null-deref-pr108251-smp_fetch_ssl_fc_has_early.c: In function
‘smp_fetch_ssl_fc_has_early’:
../../src/null-deref-pr108251-smp_fetch_ssl_fc_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108251
--- Comment #3 from David Malcolm ---
Adding -fanalyzer-verbosity=3 to comment #2, I get:
../../src/null-deref-pr108251-smp_fetch_ssl_fc_has_early.c: In function
‘smp_fetch_ssl_fc_has_early’:
../../src/null-deref-pr108251-smp_fetch_ssl_fc_has_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108251
--- Comment #4 from David Malcolm ---
Without optimization, trunk with just -Wno-address-of-packed-member (and
-fanalyzer), I get:
../../src/null-deref-pr108251-smp_fetch_ssl_fc_has_early.c: In function
‘smp_fetch_ssl_fc_has_early’:
../../src/n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108251
--- Comment #5 from David Malcolm ---
As per comment #4 (optimization disabled), but adding: -fanalyzer-verbosity=3
makes things clearer:
../../src/null-deref-pr108251-smp_fetch_ssl_fc_has_early.c: In function
‘smp_fetch_ssl_fc_has_early’:
../.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108251
--- Comment #6 from David Malcolm ---
The analyzer sees the error-handling case in objt_conn, and considers the
execution path where it bails out early due to "t" being NULL i.e.
smp->sess->origin is NULL, and thus conn being initialized to NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108252
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2023-01-09
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108252
--- Comment #2 from David Malcolm ---
Created attachment 54221
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54221&action=edit
Reduced reproducer
Reproduces with trunk, with -fanalyzer:
https://godbolt.org/z/x15xdYa57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003
--- Comment #7 from David Malcolm ---
For reference, this article (by one of my colleagues) talks about how valgrind
can detect file descriptor leaks *dynamically*:
https://developers.redhat.com/articles/2023/01/09/how-use-valgrind-track-file-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108252
--- Comment #4 from David Malcolm ---
Should be fixed on trunk for gcc 13 by the above commit.
I *think* the store::set_value change can be readily backported to GCC 12, so
keeping this bug open to track that backport (perhaps even earlier???)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108252
--- Comment #6 from David Malcolm ---
(In reply to Илья Шипицин from comment #5)
> thank you, David!
>
> I'll rerun haproxy check soon
Note that I haven't yet fixed bug 108251, so I don't know how useful the
results will be to you :/
FWIW I'v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105273
--- Comment #5 from David Malcolm ---
Similar thing seen in linuxdoom-1.10:
p_floor.c: In function ‘EV_BuildStairs’:
p_floor.c:503:22: warning: use of uninitialized value ‘speed’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
503 |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105273
--- Comment #6 from David Malcolm ---
Another instance from Doom, this time where the enum is in a field lookup,
rather than an input parameter:
p_maputl.c: In function ‘P_BoxOnLineSide’:
p_maputl.c:151:8: warning: use of uninitialized value ‘p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105273
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Consider:
https://samate.nist.gov/SARD/test-cases/149169/versions/2.0.0
Without optimization, gcc trunk with -fanalyzer fails to report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102471
--- Comment #6 from David Malcolm ---
I've created
https://github.com/davidmalcolm/gcc-analyzer-integration-tests
which builds Juliet plus various real-world C projects with a candidate build
of GCC with -fanalyzer and captures the diagnostics
: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 54299
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54299&action=edit
Reduced reproduc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108455
--- Comment #1 from David Malcolm ---
Perhaps should only complain if the deref site dominates the check site in the
supergraph (and both are in the same function?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108455
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2023-01-18
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108455
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102471
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
erity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 54314
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54314&action=edit
Reproducer
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107950
--- Comment #11 from David Malcolm ---
(In reply to Richard Biener from comment #10)
> I suppose a fix would be to provide a dummy implementation for
> range_label_for_type_mismatch::get_text in lto/, but I wonder how
> for example the fortran f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108432
--- Comment #2 from David Malcolm ---
(In reply to Segher Boessenkool from comment #1)
> Many warning messages are also dependent on optimisation level. And the
> actual generated code is as well ;-)
>
> -O0 means do the least possible work to
erity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 54338
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54338&action=edit
Reproduc
2101 - 2200 of 3524 matches
Mail list logo
