https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115237
--- Comment #2 from Paul Eggert ---
(In reply to Richard Biener from comment #1)
> 'pure' means the function has no side-effect besides reading global memory
> _when it returns_, so it's valid to turn
>
> x = unite (5, 6);
> y = unite (5,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115237
Bug ID: 115237
Summary: -Wsuggest-attribute=pure false positive for obviously
non-pure function
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109914
--- Comment #6 from Paul Eggert ---
(In reply to Jan Hubicka from comment #5)
> yes, however both const and pure attributes allows compiler to also
> remove the call if return value is unused. So here finiteness matters.
Thanks for mentioning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109914
Paul Eggert changed:
What|Removed |Added
CC||eggert at cs dot ucla.edu
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114965
--- Comment #12 from Paul Eggert ---
Thanks for fixing GCC.
I installed into Gnulib a patch that clarifies strftime's implementation, and
this also works around the GCC bug. It'll take some time for this to propagate
out, though, as Gnulib is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114965
Bug ID: 114965
Summary: wrong code generated for Emacs/Gnulib strftime
(regression from 13.2)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114893
Bug ID: 114893
Summary: -Wanalyzer-null-dereference false positive in Emacs
select_window
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118
Paul Eggert changed:
What|Removed |Added
CC||eggert at cs dot ucla.edu
--- Comment #32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107060
--- Comment #10 from Paul Eggert ---
Created attachment 58064
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58064=edit
"gunzip u.i" then "gcc -O2 -S -fanalyzer u.i" to see how much memory GCC uses
I'm having more trouble with this when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114882
Bug ID: 114882
Summary: Two -fanalyzer false positives after realloc grows
buffer
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114870
Bug ID: 114870
Summary: stddef.h problem with -Wsystem-headers on Fedora 40
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114869
Bug ID: 114869
Summary: GCC says nullptr_t is a C built in but it should be in
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114833
Bug ID: 114833
Summary: --suggest-attribute=returns_nonnull misdiagnoses
functions with __attribute__((nonnull))
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114347
--- Comment #10 from Paul Eggert ---
(In reply to Jakub Jelinek from comment #6)
> You can use -fexcess-precision=16 if you don't want treating _Float16 and
> __bf16 as having excess precision. With excess precision, I think the above
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114347
--- Comment #2 from Paul Eggert ---
(In reply to Andrew Pinski from comment #1)
> I am not so sure that 257.0bf16 gets rounded to 256.
It should get rounded to 256, since 257 has no exact representation in __bf16
and 256 is the closest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114347
Bug ID: 114347
Summary: wrong constant folding when casting __bf16 to int
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51084
Paul Eggert changed:
What|Removed |Added
CC||eggert at cs dot ucla.edu
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113963
--- Comment #1 from Paul Eggert ---
Created attachment 57442
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57442=edit
test program without line number directives (also compressed)
This is the same program as savedir.i, except without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113963
Bug ID: 113963
Summary: analyzer-null-dereference, analyzer-malloc-leak false
alarms in Gnulib savedir.c
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102671
--- Comment #6 from Paul Eggert ---
(In reply to Paul Eggert from comment #4)
> Created attachment 56996 [details]
> marker.i example from GNU Emacs
>
> Here is another example of the problem, taken from bleeding-edge GNU Emacs
Ooops, please
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113253
Bug ID: 113253
Summary: gcc -g causes -fanalyzer to issue false positive
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102671
--- Comment #5 from Paul Eggert ---
Created attachment 56997
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56997=edit
xselect.i example from GNU Emacs
Attached is another example taken from bleeding-edge GNU Emacs, compiled with
gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102671
--- Comment #4 from Paul Eggert ---
Created attachment 56996
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56996=edit
marker.i example from GNU Emacs
Here is another example of the problem, taken from bleeding-edge GNU Emacs
compiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446
--- Comment #20 from Paul Eggert ---
(In reply to jos...@codesourcery.com from comment #14)
> This is just the same as other unspecified things like converting an
> out-of-range value from floating-point to integer.
No, because when GCC's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655
--- Comment #5 from Paul Eggert ---
> I am thinking this is all under specified really ...
Although it is indeed unspecified whether 0.0/0.0 yields -NaN or +NaN, it is
well understood that negating a floating point value flips its sign bit. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655
Bug ID: 111655
Summary: wrong code generated for __builtin_signbit on x86-64
-O2
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111576
--- Comment #5 from Paul Eggert ---
(In reply to Andrew Pinski from comment #4)
> >111715
>
> That is not a valid bug # either.
Sorry, I meant Bug 111575.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111576
--- Comment #1 from Paul Eggert ---
Created attachment 55984
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55984=edit
Generated assembly language for the program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111576
Bug ID: 111576
Summary: gcc generates conditional branch for bitwise "&"
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111575
Bug ID: 111575
Summary: -Wbool-operation mistakenly warns about an int
operation
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43
--- Comment #7 from Paul Eggert ---
(In reply to Alexander Monakov from comment #6)
> Are you binding the benchmark to some core in particular?
I did the benchmark on performance cores, which was my original use case. On
efficiency cores,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43
--- Comment #5 from Paul Eggert ---
(In reply to Alexander Monakov from comment #4)
> To evaluate scheduling aspect, keep 'mov eax, 1' while changing 'add rbx,
> rax' to 'add rbx, 1'.
Adding the (unnecessary) 'mov eax, 1' doesn't affect the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110823
--- Comment #5 from Paul Eggert ---
Also see bug 43 for a related performance issue, which is perhaps more
important given the current state of bleeding-edge GNU diffutils.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43
--- Comment #2 from Paul Eggert ---
Created attachment 55790
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55790=edit
asm code that's 38% faster on my platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43
--- Comment #1 from Paul Eggert ---
Created attachment 55789
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55789=edit
asm code generated by gcc -O2 -S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43
Bug ID: 43
Summary: [missed optimization] unlikely code slows down
diffutils x86-64 ASCII processing
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110884
--- Comment #5 from Paul Eggert ---
(In reply to Andrew Pinski from comment #4)
> PTRDIFF_MAX is required to be less than SIZE_MAX and is the max size of an
> array because otherwise a-b would be undefined ...
That is true for glibc, but it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110884
--- Comment #3 from Paul Eggert ---
(In reply to Richard Biener from comment #2)
> you are basically trying to use strcmp (a, b), so why not do that?
strcmp would not work on Fedora 38, or on most current coreutils platforms.
In the full
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110884
Bug ID: 110884
Summary: strncmp false positive with -Wstringop-overread on
coreutils
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110823
--- Comment #2 from Paul Eggert ---
Created attachment 55645
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55645=edit
code-mbcel1.s with the optimization suggested in the bug report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110823
--- Comment #1 from Paul Eggert ---
Created attachment 55644
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55644=edit
gcc -O2 -S output (from code-mbcel1.i)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110823
Bug ID: 110823
Summary: [missed optimization] >50% speedup for x86-64 ASCII
processing a la GNU diffutils
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110333
--- Comment #2 from Paul Eggert ---
(In reply to Jakub Jelinek from comment #1)
> it is I think a portability warning.
OK, but the 4095-byte portability concern applies to printf, too, and yet
printf doesn't get the warning because of the fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993
Paul Eggert changed:
What|Removed |Added
CC||eggert at cs dot ucla.edu
--- Comment #16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110333
Bug ID: 110333
Summary: GCC 13 -Wformat-overflow=2 should reflect real libc
limits for sprintf
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109856
--- Comment #1 from Paul Eggert ---
Created attachment 55337
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55337=edit
Another illustration of the bug, taken from GNU tar
Here is another example of the bug, taken from GNU tar. Compile it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90094
Paul Eggert changed:
What|Removed |Added
CC||eggert at cs dot ucla.edu
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110014
Bug ID: 110014
Summary: -Wanalyzer-allocation-size mishandles realloc (...,
* sizeof (object))
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21161
Paul Eggert changed:
What|Removed |Added
CC||eggert at cs dot ucla.edu
--- Comment #26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101770
--- Comment #5 from Paul Eggert ---
I can no longer reproduce the bug in bleeding-edge GNU diffutils, so this bug
is not so important in its own right - that is, it's merely that GCC 13.1.1
still mishandles w.i.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 101770, which changed state.
Bug 101770 Summary: -Wmaybe-uninitialized false alarm with only locals in GNU
diffutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101770
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101770
Paul Eggert changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109856
Bug ID: 109856
Summary: -Wnull-dereference false positive in Emacs itree.c
(regression from GCC 12)
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109847
Bug ID: 109847
Summary: -Wanalyzer-out-of-bounds false positive with Emacs
tagged pointers
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109839
Bug ID: 109839
Summary: -Wanalyzer-fd-leak false positive with routine dup2
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109577
Paul Eggert changed:
What|Removed |Added
CC||eggert at cs dot ucla.edu
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109635
Bug ID: 109635
Summary: -Wanalyzer-use-of-uninitialized-value false alarm
involving adding 8 to index
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109628
Bug ID: 109628
Summary: -Wanalyzer-use-of-uninitialized-value false positive
on static storage
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109614
Bug ID: 109614
Summary: -Wanalyzer-use-after-free gets confused about a free
function in Coreutils
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109613
Bug ID: 109613
Summary: -Wanalyzer-null-dereference false positive involving
__builtin_unreachable
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107947
--- Comment #5 from eggert at cs dot ucla.edu ---
Thanks for reporting the conformance bug in TZDB. I fixed it in the TZDB
development repository here:
https://github.com/eggert/tz/commit/9cfe9507fcc22cd4a0c4da486ea1c7f0de6b075f
and the fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107565
Bug ID: 107565
Summary: -Wanalyzer-use-of-uninitialized-value false positive
with rdrand
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107116
Bug ID: 107116
Summary: -Woverflow false alarm in unreachable code
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107060
Bug ID: 107060
Summary: -fanalyzer unbearably slow when compiling GNU Emacs
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106947
Bug ID: 106947
Summary: -Waddress + bool + pragma generates meaningless
diagnostic
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106436
Bug ID: 106436
Summary: -Wanalyzer-null-dereference false positive suggests
data corruption in GCC
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106428
Bug ID: 106428
Summary: -Wanalyzer-file-leak false positive with if ((ptr =
fopen(...)) == NULL) ...
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106427
Bug ID: 106427
Summary: -Wuse-after-free=3 false alarm about int (not pointer)
variable
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105961
--- Comment #2 from eggert at cs dot ucla.edu ---
Created attachment 53131
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53131=edit
reproducer for the bug (compressed with xz)
The uncompressed t.i was too large for bugzilla, so here's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105961
Bug ID: 105961
Summary: -Wanalyzer-use-of-uninitialized-value false positive
after "= {0}"
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105784
Bug ID: 105784
Summary: -Wanalyzer-use-of-uninitialized-value false positive
on partly initialized array
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755
Bug ID: 105755
Summary: -Wanalyzer-null-dereference regression compiling Emacs
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44677
eggert at cs dot ucla.edu changed:
What|Removed |Added
CC||eggert at cs dot ucla.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104262
--- Comment #4 from eggert at cs dot ucla.edu ---
Thanks for looking into the problem. DR#460 says that the C2x committee adopted
wording based on N2072, which which made the point that non-integral multiples
of alignment are useful - for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104262
Bug ID: 104262
Summary: -fsanitize=address false alarm with aligned_alloc
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104060
Bug ID: 104060
Summary: -Wmaybe-uninitialized false alarm on address of local
array
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912
--- Comment #4 from eggert at cs dot ucla.edu ---
(In reply to Aldy Hernandez from comment #3)
> > && !(leapcnt == 0
> >|| (prevcorr < corr
> >? corr == prevcorr + 1
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101713
--- Comment #2 from eggert at cs dot ucla.edu ---
(In reply to David Malcolm from comment #1)
> Am I right in thinking that there's a cast somewhere inside the hash table
> code that at some point casts away the const from the pointer and frees
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102692
--- Comment #1 from eggert at cs dot ucla.edu ---
Sorry, forgot to mention the incorrect GCC output. Here it is:
-
analyzer-null-dereference-simple.i: In function ‘fix_overlays_before’:
analyzer-null-dereference-simple.i:79:35: warning:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102671
--- Comment #2 from eggert at cs dot ucla.edu ---
I have filed what may be a related bug as GCC bug 102692.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102692
Bug ID: 102692
Summary: -Wanalyzer-null-dereference false alarm with (!p || q
|| !p->next)
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102671
--- Comment #1 from eggert at cs dot ucla.edu ---
Created attachment 51582
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51582=edit
2nd test case illustrating the bug
I'm attaching a second test case, also taken from GNU Emacs,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102671
Bug ID: 102671
Summary: -Wanalyzer-null-dereference false positive when
compiling GNU Emacs
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102578
--- Comment #2 from eggert at cs dot ucla.edu ---
Created attachment 51539
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51539=edit
false alarm with 'gcc -O2 -S -Wreturn-type'
Attached is the third and final example I got from Coreutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102578
--- Comment #1 from eggert at cs dot ucla.edu ---
Created attachment 51538
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51538=edit
false alarm with 'gcc -O2 -S -Wimplicit-fallthrough=5'
I'm adding another example of the problem, taken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102578
Bug ID: 102578
Summary: false alarm on noreturn via static function
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99591
eggert at cs dot ucla.edu changed:
What|Removed |Added
CC||eggert at cs dot ucla.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101913
--- Comment #3 from eggert at cs dot ucla.edu ---
(In reply to Andrew Pinski from comment #1)
> >-1L << 63 is LONG_MIN
> No it is undefined and has an overflow bit on it.
> You want (long)(-1UL << 63) for it be correct.
> But the warning is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101913
eggert at cs dot ucla.edu changed:
What|Removed |Added
Attachment #51304|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101913
Bug ID: 101913
Summary: -Wstrict-overflow -O3 false alarm on tzdb localtime.c
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912
Bug ID: 101912
Summary: -Wmaybe-uninitialized false alarm in tzdb localtime.c
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101837
Bug ID: 101837
Summary: ICE with -O3 -fsanitize=undefined -fanalyzer
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101829
Bug ID: 101829
Summary: problems with inline + __attribute__ ((malloc
(deallocator)))
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101770
Bug ID: 101770
Summary: -Wmaybe-uninitialized false alarm with only locals in
GNU diffutils
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101768
Bug ID: 101768
Summary: -Wmaybe-uninitialized false alarm with 'switch'
instead of 'if'
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101713
Bug ID: 101713
Summary: -Wanalyzer-malloc-leak false positive with GNU
coreutils hash table code
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101494
Bug ID: 101494
Summary: -Wmaybe-uninitialized false alarm with memrchr of size
0
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644
--- Comment #12 from eggert at cs dot ucla.edu ---
There are really two bugs here:
(A) GCC emits the false alarm.
(B) there's no way to shut off the false alarm, not even with '# pragma GCC
diagnostic ignored "-Wreturn-local-addr"'.
Although
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644
--- Comment #11 from eggert at cs dot ucla.edu ---
Created attachment 49783
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49783=edit
another instance of a -Wreturn-local-addr false alarm
I ran into a different instance of the bug today,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021
--- Comment #15 from eggert at cs dot ucla.edu ---
(In reply to Andreas Schwab from comment #14)
> I don't follow. It works exactly the same way.
Let me try to explain further. In my comment #11, the first directive:
#warning "You are too
1 - 100 of 110 matches
Mail list logo
