https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #11 from David Malcolm ---
(In reply to Andrew Cooper from comment #9)
[...snip...]
> Would a const annotation on get_cpu_info() be likely to help? It occurs to
> me that this is true in all cases that the compiler could legitimatel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2023-03-02
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107060
--- Comment #9 from David Malcolm ---
Reconfirming, alas. I just tried adding emacs to my integration test suite
[1], and xdisp.c is still a big outlier, taking ~15 minutes; with gcc (GCC)
13.0.1 20230202 (experimental).
[1] https://github.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107565
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #6 from David Malc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108988
--- Comment #1 from David Malcolm ---
Replacement stmt is created here:
(gdb) bt
#0 gimple_set_op (gs=, i=1, op=) at ../../src/gcc/gimple.h:2629
#1 0x01093a6f in gimple_build_call_1 (fn=,
nargs=4) at ../../src/gcc/gimple.cc:234
#2 0x0
IRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Whilst working on PR analyzer/107565, I noticed that in this fun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107565
--- Comment #4 from David Malcolm ---
Created attachment 54565
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54565&action=edit
Patch that reworks builtin handling
I've been testing this patch, but it might be too invasive at this point i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108935
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #5 from David Malcolm ---
Minimal reproducer: https://godbolt.org/z/E6EEY1WT6
Am I right in understanding that:
register unsigned long sp asm("rsp");
is intended as a way to read the %rsp register?
If so, I think the analyzer m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108935
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108830
--- Comment #3 from David Malcolm ---
(In reply to David Malcolm from comment #0)
> There are also a huge number of spammy "'new_vals' is NULL" messages.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105958#c1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105958
--- Comment #1 from David Malcolm ---
A particularly bad example seems to be gcc.dg/analyzer/null-deref-pr108830.c:
https://godbolt.org/z/rabfxeaxz
which currently emits:
: In function 'apr_hash_merge':
:82:24: warning: dereference of NULL 'ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108879
David Malcolm changed:
What|Removed |Added
Blocks||97110
--- Comment #1 from David Malcolm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108830
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108562
Bug 108562 depends on bug 108830, which changed state.
Bug 108830 Summary: Excess warnings from -Wanalyzer-null-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108830
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104224
--- Comment #6 from David Malcolm ---
Given the above patch, we now need -fno-analyzer-suppress-followups if you want
to see all the warnings in the testcase (rather than just stopping after the
first).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108867
--- Comment #2 from David Malcolm ---
Yeah, IIRC -Wmissing-noreturn/-Wsuggest-attribute=noreturn work on a function
that we have the implementation of, whereas I'm interested in handling the case
where we *don't* have the source.
If code paths
Version: 13.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 54498
--> https://gcc.gnu.org/bugzi
: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Blocks: 108562
Target Milestone: ---
Created attachment 54477
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54477&action=edit
Reproducer
I see lots of (probable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108806
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108725
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108666
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108664
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Blocks: 108562
Target Milestone: ---
Created attachment 54470
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54470&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108745
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108733
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2023-02-09
Status|UNCONFIRM
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 54441
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54441&action=edit
Rep
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 54439
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54439&action=edit
Rep
tatus: 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 54438
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54438&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108704
David Malcolm changed:
What|Removed |Added
Summary|[13 Regression] Many|Many
|-Wanalyzer-use-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108704
--- Comment #2 from David Malcolm ---
Adding -fno-analyzer-state-purge fixes the false positive, looks like it's
erroneously pruning the value of fp0 immediately after the first assignment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108704
David Malcolm changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|UNCONFIRMED
IRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 54425
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54425&action=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108661
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
ty: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
We currently handle calls to "fread" (in sm-file.cc's class kf_fread) by
assuming that any call to
IRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 54408
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54408&
IRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 54407
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54407&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108661
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
tatus: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Consider:
#include
#include
#include
struct ring
{
char buf[1024];
};
int test (
ormal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 54394
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54394&action=edit
Reproducer
The attache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108633
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
13.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 54388
--> https://gcc.gnu.org/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107017
--- Comment #1 from David Malcolm ---
Should probably also handle scanf-style functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108432
--- Comment #6 from David Malcolm ---
Another example: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108598#c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108598
--- Comment #3 from David Malcolm ---
Yeah, it would be good if -fanalyzer detected such issues within loops, and
identified the iteration at which the access goes out-of-bounds. Handling that
is bug 108432 (which I'm treating as an RFE).
Than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108616
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108598
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108616
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
ty: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Consider e.g. this bogusly-sized alloca:
#include
#include
int main(void)
{
int length = 99;
int32_t *arr = all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108400
--- Comment #2 from David Malcolm ---
Looking at the reduced reproducer, -fanalyzer is considering the case where
wu->Contexts is initially non-NULL and thus the loop is entered, but it doesn't
know about the insides of Tick64 and thus considers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108432
David Malcolm changed:
What|Removed |Added
CC||jamie.bainbridge at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107566
David Malcolm changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNED
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Depends on: 102671, 105755, 106436, 107289, 107345, 107526,
107733, 108251, 108325, 108400
Target Milestone: ---
Referenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108400
--- Comment #1 from David Malcolm ---
Created attachment 54356
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54356&action=edit
Reduced reproducer
False positive
seen here with no optimization:
https://godbolt.org/z/cfqz1fYKx
with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108535
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108432
David Malcolm changed:
What|Removed |Added
Summary|Analyzer fails to detect|RFE: analyzer could detect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108524
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 108507, which changed state.
Bug 108507 Summary: [13 regression] new test case
gcc.dg/analyzer/SARD-tc841-basic-00182-min.c in r13-5244-gc6a09bfa03 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108507
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108507
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108507
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108524
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
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
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
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
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=102471
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=108455
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2023-01-18
Status|UNCONFIRM
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?)
: 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=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
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=105273
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
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
--- 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=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=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=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 #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=108252
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2023-01-09
Ever confirmed|0
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=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 #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 #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 #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 #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
-valid-code
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Given:
$ touch empty.S
$ ./xgcc -B. -c empty.S
succeeds, but:
$ ./xgcc -B. -c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106479
--- Comment #3 from David Malcolm ---
(In reply to David Malcolm from comment #2)
> Thanks; should be fixed by the above patch (lightly tested with
> hppa-linux-gnu and riscv32-unknown-linux-gnu).
...referring to the FAIL at line 9.
I believe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106479
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108065
David Malcolm changed:
What|Removed |Added
Summary|[13 Regression] ICE in |[13 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108028
--- Comment #2 from David Malcolm ---
(D) Also, the
(3) dereference of NULL '0'
is poorly worded; ideally we'd say:
(3) dereference of NULL 'q'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108028
David Malcolm changed:
What|Removed |Added
Summary|--Wanalyzer-null-dereferenc |Misleading -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108003
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108003
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2022-12-08
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107882
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107882
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from David Malc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106325
--- Comment #8 from David Malcolm ---
Should be fixed on trunk for GCC 13 by the above patch.
Still affects GCC 12, GCC 11, and GCC 10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106325
--- Comment #6 from David Malcolm ---
Fix for the overzealous reducing is to simply add "__attribute__((nonnull(1,
2)))" to the reproducer here:
__attribute__((nonnull(1, 2)))
void
arranger_object_unsplit (ArrangerObject *r1, ArrangerObject *r2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106325
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from David Malc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106325
--- Comment #4 from David Malcolm ---
Created attachment 54023
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54023&action=edit
Reduced reproducer
Attached is a reduced version of the reproducer, which demonstrates the false
+ve on trunk
501 - 600 of 1757 matches
Mail list logo
