https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178
--- Comment #18 from Paul Eggert ---
(In reply to uecker from comment #17)
> Fairly limited, but if you only have specific cases where you need
> this, this worked for me as a workaround:
>
> #define TRUNC4(x) { x[0], x[1], x[2], x[3] }
> stati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178
Paul Eggert changed:
What|Removed |Added
CC||eggert at cs dot ucla.edu
--- Comment #16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117320
--- Comment #5 from Paul Eggert ---
(In reply to Andrew Pinski from comment #4)
> I also suspect `b backtrace_function`
> will work correctly and point to the locations, it is just printing of the
> value of backtrace_function which is broken.
Y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117320
--- Comment #3 from Paul Eggert ---
(In reply to Andrew Pinski from comment #1)
> Does it happen in a full linked binary or just in the object file?
The bug occurs in both, though of course I see different values for the
backtrace_function addr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117320
Bug ID: 117320
Summary: wrong debug info for function with cold alternative
(-g -O2)
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109856
--- Comment #5 from Paul Eggert ---
(In reply to Sam James from comment #4)
> Could you file a new bug for the tar case?
Sure, filed as new Bug 117236.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117236
Bug ID: 117236
Summary: -Wnull-dereference false positive in GNU tar
(regression from GCC 12)
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109856
--- Comment #3 from Paul Eggert ---
(In reply to Sam James from comment #2)
> 14 and 15 are fine.
Although GCC 14 is fine with the first attachment, I am still seeing problems
when I compile the second one (attachment 55337) with gcc (GCC) 14.2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116865
Bug ID: 116865
Summary: ICE when compiling GNU coreutils numfmt with
-fanalyzer
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Keywords: ice-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116864
Bug ID: 116864
Summary: "*" and ".." in false positive
-Wanalyzer-use-of-uninitialized-value
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #28 from Paul Eggert ---
Thanks for the fix. I updated Emacs to no longer work around the bug when GCC
15+ is being used, here:
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3d1d4f109ed4115256a08c74eeb704259d91c9f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95496
Paul Eggert changed:
What|Removed |Added
CC||eggert at cs dot ucla.edu
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #22 from Paul Eggert ---
(In reply to Richard Biener from comment #17)
> I suppose this happens even when building without LTO, so can you please
> attach preprocessed source of the TU containing decode_lisp_time
> (preprocessed with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #21 from Paul Eggert ---
Created attachment 58740
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58740&action=edit
Assembly-language illustrating wrong code
Here is the assembly language output (gzip compressed) of the wrong co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #20 from Paul Eggert ---
Created attachment 58739
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58739&action=edit
preprocessed Emacs source code illustrating the bug
Here is the gzip-compressed text of the Emacs source code il
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #16 from Paul Eggert ---
(In reply to Richard Biener from comment #13)
> Paul - can you test if this patch resolves the emacs issue?
Unfortunately not. Although the generated code differs, it's still the same bad
pattern. GDB's comma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #11 from Paul Eggert ---
(In reply to Richard Biener from comment #10)
> The remaining issue is analyzed to be caused by SRA so you can check whether
> -fno-tree-sra fixes it for you.
Thanks, it does, and I modified the Emacs 'config
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, 6);
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: norm
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 t
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 a
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&action=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
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
Pri
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
Compone
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
Prior
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
> behavio
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 represen
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
Compone
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 f
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&action=edit
test program without line number directives (also compressed)
This is the same program as savedir.i, except with
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
Sever
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 i
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
Componen
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&action=edit
xselect.i example from GNU Emacs
Attached is another example taken from bleeding-edge GNU Emacs, compiled with
g
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&action=edit
marker.i example from GNU Emacs
Here is another example of the problem, taken from bleeding-edge GNU Emacs
compi
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 consta
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
Pr
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&action=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
Componen
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
Pr
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, addi
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 ti
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&action=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&action=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
Sever
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 n
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 coreu
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&action=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&action=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
Seve
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: norma
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&action=edit
Another illustration of the bug, taken from GNU tar
Here is another example of the bug, taken from GNU tar. Comp
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 f
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 |Ad
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
Compo
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: nor
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: nor
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 sho
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
Compo
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: n
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
Severity:
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&action=edit
reproducer for the bug (compressed with xz)
The uncompressed t.i was too large for bugzilla, so her
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
Sever
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
Co
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 sam
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
Compone
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: deref
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&action=edit
2nd test case illustrating the bug
I'm attaching a second test case, also taken from GNU Emacs, ill
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
1 - 100 of 127 matches
Mail list logo
