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=107017
--- Comment #1 from David Malcolm ---
Should probably also handle scanf-style functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108633
Bug ID: 108633
Summary: -Wanalyzer-fd-type-mismatch erroneously emitted on
missing error-checking in qemu's
tests/qtest/libqtest.c
Product: gcc
Version: 13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108633
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108648
Bug ID: 108648
Summary: -Wanalyzer-fd-leak false positives seen on haproxy's
proto_tcp.c
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108661
Bug ID: 108661
Summary: -Wanalyzer-use-of-uninitialized-value false positive
seen in haproxy's sink_rotate_file_backed_ring
Product: gcc
Version: 13.0
Status: UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108661
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108664
Bug ID: 108664
Summary: -Wanalyzer-use-of-uninitialized-value false positive
seen in coreutils's cksum.c: cksum_slice8
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108666
Bug ID: 108666
Summary: -Wanalyzer-use-of-uninitialized-value false positives
seen in coreutils's sum.c: bsd_sum_stream
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108689
Bug ID: 108689
Summary: RFE: more precise handling of "fread"-style functions
in -fanalyzer
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108661
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108704
Bug ID: 108704
Summary: Many -Wanalyzer-use-of-uninitialized-value false
positives seen in qemu's softfloat.c
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108704
David Malcolm changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|UNCONFIRMED
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
Summary|[13 Regression] Many|Many
|-Wanalyzer-use-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108725
Bug ID: 108725
Summary: -Wanalyzer-use-of-uninitialized-value on ternary
pointer access seen in qemu-7.2.0's dump/win_dump.c
Product: gcc
Version: 13.0
Status: UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108733
Bug ID: 108733
Summary: -Wanalyzer-use-of-uninitialized-value false positives
seen with __attribute__((cleanup))
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108745
Bug ID: 108745
Summary: -Wanalyzer-deref-before-check false positives seen in
ImageMagick due to checks in macros
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108733
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2023-02-09
Status|UNCONFIRM
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=108806
Bug ID: 108806
Summary: -Wanalyzer-null-dereference false positives due to not
handling bitmasks
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108664
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=108725
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=108830
Bug ID: 108830
Summary: Excess warnings from -Wanalyzer-null-dereference
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108867
Bug ID: 108867
Summary: RFE: analyzer could suppress false positives by
detecting functions that are likely missing
__attribute__((noreturn))
Product: gcc
Versio
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
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=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=108879
David Malcolm changed:
What|Removed |Added
Blocks||97110
--- Comment #1 from David Malcolm
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=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=108935
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
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
Resolution|--- |FIXED
Status|ASSIGNED
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=108988
Bug ID: 108988
Summary: gimple_fold_builtin_fputs doesn't preserve
gimple_builtin_call_types_compatible_p
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severi
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
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=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=108968
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2023-03-02
Status|UNCONFIRM
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
--- Comment #12 from David Malcolm ---
(In reply to Andrew Cooper from comment #9)
[...snip...]
> Our code does fundamentally rely on get_cpu_info() always returning the same
> pointer (on a single CPU). For example, `current` is defined as
> `
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #16 from David Malcolm ---
Minimized version of attachment 54572:
struct cpu_info {
/* [...snip...] */
struct vcpu *current_vcpu;
/* [...snip...] */
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #17 from David Malcolm ---
...where trunk emits:
test.c:35:22: warning: dereference of NULL 'ptr' [CWE-476]
[-Wanalyzer-null-dereference]
35 | ptr[0] = ~ptr[0];
| ~~~^~~
'foo': events 1-6
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #18 from David Malcolm ---
Looks like it doesn't even need the asm stmt at line 32 to consider that it
could take the false-then-true path.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107999
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109014
Bug ID: 109014
Summary: -Wanalyzer-use-of-uninitialized-value seen in
pcre2-10.42's pcre2test.c
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109014
--- Comment #1 from David Malcolm ---
I believe the issue here is that:
* display_properties partially initializes the "found" buffer, writing a -1
terminator at the end of the initialized part at:
fv[m] = -1;
* display_properties then ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109015
Bug ID: 109015
Summary: Analyzer doesn't know about atomic builtins
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: anal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109016
Bug ID: 109016
Summary: Analyzer doesn't know about OMP builtins
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108988
--- Comment #8 from David Malcolm ---
(In reply to Jakub Jelinek from comment #6)
> Fixed.
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109058
Bug ID: 109058
Summary: RFE: analyzer should elide repeated calls to strcmp in
execution paths
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109058
--- Comment #1 from David Malcolm ---
Even better would be for the event condition to express the string, when it's a
string literal, so that it reads:
../../src/gcc/testsuite/gcc.dg/analyzer/strcmp-path-1.c:27:5: note: path
27 | __analy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109059
Bug ID: 109059
Summary: -Wanalyzer-malloc-leak false +ve seen on haproxy's
cfgparse.c: cfg_register_postparser
Product: gcc
Version: 13.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109060
Bug ID: 109060
Summary: -Wanalyzer-deref-before-check false positives seen in
haproxy's cfgparse.c: parse_process_number
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109058
--- Comment #2 from David Malcolm ---
(In reply to David Malcolm from comment #0)
> Seen on a diagnostic in haproxy's cfgparse-global.c: cfg_parse_global
For reference, see cfg_parse_global in:
http://git.haproxy.org/?p=haproxy.git;a=blob;f=sr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108475
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109060
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109059
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2023-03-10
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109094
Bug ID: 109094
Summary: [13 Regression] ICE in -fanalyzer seen in qemu's
target/i386/tcg/translate.c
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109094
--- Comment #1 from David Malcolm ---
Created attachment 54637
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54637&action=edit
Unreduced reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109097
Bug ID: 109097
Summary: No SARIF output happens on an ICE
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109098
Bug ID: 109098
Summary: Encoding errors on SARIF output for non-UTF-8 source
files
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109098
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2023-03-11
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109098
--- Comment #3 from David Malcolm ---
(In reply to Andrew Pinski from comment #1)
> I would have assumed you need -finput-charset= for the non-utf8 ones really
> if your LANG/LANGUAGE is not set to C/UTF8 really.
Yeah, but when complaining abou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109098
--- Comment #4 from David Malcolm ---
(In reply to Andrew Pinski from comment #2)
> So I think there is a bug in that code ...
The issue is in sarif_builder::maybe_make_artifact_content_object, which uses;
char *text_utf8 = maybe_read_file (f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109106
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107017
David Malcolm changed:
What|Removed |Added
CC||geoffreydgr at icloud dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105906
--- Comment #2 from David Malcolm ---
Looks like this is fixed on trunk for GCC 13; seem to have been via
688fc162b76dc6747a30fcfd470f4770da0f4924
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105906
--- Comment #3 from David Malcolm ---
(In reply to David Malcolm from comment #2)
> Looks like this is fixed on trunk for GCC 13; seem to have been via
> 688fc162b76dc6747a30fcfd470f4770da0f4924
aka r13-5113-g688fc162b76dc6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
--- Comment #4 from David Malcolm ---
Created attachment 54653
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54653&action=edit
Generated diagnostic-format-sarif-file-4.c.sarif output file on my machine
(In reply to Hans-Peter Nilsson fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109120
--- Comment #1 from David Malcolm ---
Thanks for filing this bug. Seems to affect GCC 11 onwards, as GCC 10 didn't
support the 2nd argument to __attribute__((malloc)):
Trunk: https://godbolt.org/z/MbWezaxrz
GCC 12.2: https://godbolt.org/z/v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109120
--- Comment #2 from David Malcolm ---
Looks like the attribute was added to iconv_open in glibc in this commit:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=260a430dd841072020c4dae91468322e619e7330
Unfortunately, as currently written
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109120
--- Comment #3 from David Malcolm ---
(In reply to David Malcolm from comment #2)
> Looks like the attribute was added to iconv_open in glibc in this commit:
>
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;
> h=260a430dd841072020c4dae9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109120
--- Comment #4 from David Malcolm ---
...and thus presumably glibc 2.36 onwards uses the attribute on iconv_open.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109120
--- Comment #5 from David Malcolm ---
Potentially could be worked around from the gcc side by adding a known_function
implementation for iconv_{open,close}.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109120
--- Comment #6 from David Malcolm ---
Note to self: there's a usage example in the glibc manual here:
https://www.gnu.org/software/libc/manual/html_node/iconv-Examples.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109131
Bug ID: 109131
Summary: -Wanalyzer-deref-before-check false positive seen in
git's builtin/show-ref.c
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105909
--- Comment #1 from David Malcolm ---
Perhaps via 3.58 notification object:
https://docs.oasis-open.org/sarif/sarif/v2.1.0/os/sarif-v2.1.0-os.html#_Toc34317894
which: "describes a condition encountered during the execution of an analysis
tool wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104434
--- Comment #2 from David Malcolm ---
On rereading
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
I think that "pure" isn't strong enough for the above example: the result of a
pure function is allowed to change between inv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104434
--- Comment #3 from David Malcolm ---
OpenBLAS issue filed as https://github.com/xianyi/OpenBLAS/issues/3543
suggesting the use of __attribute__((const)) on LAPACKE_lsame.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104434
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104434
--- Comment #6 from David Malcolm ---
OpenBLAS commit adding __attribute__((const)) to the decl:
https://github.com/xianyi/OpenBLAS/commit/1c1ffb0591186e50311670369dee2cb450980d9a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103521
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2022-03-02
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103521
--- Comment #3 from David Malcolm ---
Comparing the IR, the discrepancy looks like it relates to signedness of the
"char" type.
Works with --target=powerpc64le-linux-gnu if I add -fsigned-char to the command
line; otherwise it fails as noted in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104680
--- Comment #2 from David Malcolm ---
> trunk.git/gcc/config/avr/avr.cc:8674:22: warning: Identical inner 'if'
> condition is always true. [identicalInnerCondition]
In avr_out_fract:
8665 │ /* We need to consider to-be-discarded b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104680
--- Comment #3 from David Malcolm ---
> trunk.git/gcc/config/mn10300/mn10300.cc:888:8: warning: Identical inner 'if'
> condition is always true. [identicalInnerCondition]
In mn10300_expand_prologue:
877 │ /* Consider alternative save
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104680
--- Comment #4 from David Malcolm ---
> trunk.git/gcc/d/expr.cc:689:17: warning: Identical inner 'if' condition is
> always true. [identicalInnerCondition]
In 'void visit (CatExp *e)':
682 │ if (e->e1->op == EXP::concatenate)
683 │
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104680
--- Comment #5 from David Malcolm ---
> trunk.git/libffi/src/m32r/ffi.c:66:15: warning: Identical inner 'if'
> condition is always true. [identicalInnerCondition]
In ffi_prep_args:
56 │ for (i = ecif->cif->nargs, p_arg = ecif->cif->arg_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104680
--- Comment #6 from David Malcolm ---
> trunk.git/liboffloadmic/runtime/offload_engine.cpp:113:13: warning: Identical
> inner 'if' condition is always true. [identicalInnerCondition]
108 │ void Engine::init(void)
109 │ {
110 │ if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104680
--- Comment #7 from David Malcolm ---
> trunk.git/zlib/contrib/minizip/zip.c:1212:26: warning: Identical inner 'if'
> condition is always true. [identicalInnerCondition]
In zipOpenNewFileInZip4_64:
1206 │ #ifdef HAVE_BZIP2
1207 │ if (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104680
David Malcolm changed:
What|Removed |Added
Component|analyzer|c
Assignee|dmalcolm at gcc do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103521
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104793
Bug ID: 104793
Summary: -Wanalyzer-write-to-const and
-Wanalyzer-write-to-string-literal should respect
attribute((access, write)
Product: gcc
Version: 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101983
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104821
Bug ID: 104821
Summary: RFE: consolidate analyzer leak diagnostics by
considering indirect vs direct leaks
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104821
--- Comment #1 from David Malcolm ---
Example: https://godbolt.org/z/afvEd99qn
#include
struct s
{
void *m_a;
void *m_b;
void *m_c;
};
struct s *
make_s (size_t sz_a, size_t sz_b, size_t sz_c)
{
struct s *result = calloc (1, sizeof
301 - 400 of 1425 matches
Mail list logo
