https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113736
--- Comment #3 from rguenther at suse dot de ---
On Sat, 3 Feb 2024, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113736
>
> Jakub Jelinek changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113712
Richard Biener changed:
What|Removed |Added
Blocks||26163
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059
Jakub Jelinek changed:
What|Removed |Added
Summary|[14 regression] fftw fails |[15 regression] fftw fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113761
Bug ID: 113761
Summary: Abnormal program termination using libstdc++
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059
--- Comment #24 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:d413df070ba5efadd2fb8b6c6aa6003b8cae617b
commit r14-8797-gd413df070ba5efadd2fb8b6c6aa6003b8cae617b
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113563
Jiang An changed:
What|Removed |Added
CC||de34 at live dot cn
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113707
--- Comment #4 from Richard Biener ---
It shows two issues. One we do too many LC-SSA preserving avails, the other
that eliminate_avail can result in different answers for the same name
dependent on later avails - that's of course not OK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113707
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113746
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113765
Bug ID: 113765
Summary: autofdo: val-profiler-threads-1.c compilation, error:
probability of edge from entry block not initialized
Product: gcc
Version: unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113761
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
--- Comment #3 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #2)
> I think that ctor is constexpr since https://wg21.link/N3471
> Does that have some feature test macro?
That was long before we started using feature test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
--- Comment #7 from Kewen Lin ---
(In reply to Sebastian Huber from comment #6)
> It seems that the change
>
> commit acc727cf02a1446dc00f8772f3f479fa3a508f8e
> Author: Kewen Lin
> Date: Tue Dec 27 04:13:07 2022 -0600
>
> rs6000:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104739
--- Comment #8 from Rainer Orth ---
Created attachment 57324
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57324=edit
Proposed patch
Tested on i386-pc-solaris2.11 (as and gas) and i686-pc-linux-gnu. The affected
tests come up as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
--- Comment #9 from Kewen Lin ---
Note that now we only disable implicit powerpc64 for -m32 when the
OS_MISSING_POWERPC64 is set.
/* Don't expect powerpc64 enabled on those OSes with OS_MISSING_POWERPC64,
since they do not save and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
--- Comment #12 from Kewen Lin ---
(In reply to Sebastian Huber from comment #10)
> (In reply to Kewen Lin from comment #9)
> > Note that now we only disable implicit powerpc64 for -m32 when the
> > OS_MISSING_POWERPC64 is set.
> >
> > /*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113725
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113761
--- Comment #2 from Andrew Pinski ---
https://eel.is/c++draft/rand.dist.samp.pconst#8
It seems like libstdc++ miss that part, I wonder if it changed ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113736
--- Comment #4 from Richard Biener ---
(In reply to rguent...@suse.de from comment #3)
> On Sat, 3 Feb 2024, jakub at gcc dot gnu.org wrote:
> > Bitint lowering changes here
> > MEM < _BitInt(768)> [( struct T
> > *)p_2(D)] =
> > s_4(D);
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113762
Richard Biener changed:
What|Removed |Added
Keywords||documentation
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113761
--- Comment #4 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #2)
> It seems like libstdc++ miss that part, I wonder if it changed ...
No, it didn't change. We've just always had that bug. Well, not quite always,
looks like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
--- Comment #11 from Kewen Lin ---
(In reply to Sebastian Huber from comment #8)
> Yes, it seems that -mcpu=e6500 -mno-powerpc64 yields the right code for the
> attached test case (with or without the -m32).
The default is -m32 I guess? :)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113737
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113762
Bug ID: 113762
Summary: TYPE_ADDR_SPACE requirements on tcc_reference trees
not documented/checked
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113448
Rainer Orth changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
--- Comment #10 from Sebastian Huber ---
(In reply to Kewen Lin from comment #9)
> Note that now we only disable implicit powerpc64 for -m32 when the
> OS_MISSING_POWERPC64 is set.
>
> /* Don't expect powerpc64 enabled on those OSes with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113707
Richard Biener changed:
What|Removed |Added
CC||shaohua.li at inf dot ethz.ch
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113761
Andrew Pinski changed:
What|Removed |Added
Summary|Abnormal program|piecewise_constant_distribu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113749
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113737
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:dede174fbb57bdd3e26f322b6096d53edf0089c4
commit r14-8798-gdede174fbb57bdd3e26f322b6096d53edf0089c4
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113707
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113707
--- Comment #6 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:42959acb8409c39e1c71c43528832611c3b71e25
commit r14-8800-g42959acb8409c39e1c71c43528832611c3b71e25
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113761
--- Comment #5 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #4)
> Also, we're missing https://cplusplus.github.io/LWG/issue1439 which fixed
> the return type of densities()
Which requires changing param_type::_M_den which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #4 from Tamar Christina ---
Narrowed down the change part that caused the failure, but it should have been
correct to do. So looking into why the change caused the failure. Please
hold..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113765
--- Comment #1 from Andi Kleen ---
Seems to be a regression, I tested the same setup on gcc 13 and the test passes
there:
55:PASS: gcc.dg/tree-prof/val-profiler-threads-1.c compilation,
-fprofile-generate -D_PROFILE_GENERATE
59:PASS:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104739
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Iain Buclaw ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #5)
> Can give it a go.
>
> https://github.com/dlang/dmd/pull/16136
Great, thanks for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
--- Comment #13 from Sebastian Huber ---
(In reply to Kewen Lin from comment #12)
> (In reply to Sebastian Huber from comment #10)
> > (In reply to Kewen Lin from comment #9)
> > > Note that now we only disable implicit powerpc64 for -m32 when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
--- Comment #15 from Saurabh Jha ---
Have a patch for review here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644454.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113703
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109559
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98491
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109559
--- Comment #7 from Richard Biener ---
So the 2nd hunk tests OK but the first for example runs into
FAIL: gcc.dg/Wfree-nonheap-object-4.c (test for warnings, line 19)
where we explicitly seem to expect the warning when the system header code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113767
Bug ID: 113767
Summary: Missing Destructor Call with goto and return value
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113756
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113735
--- Comment #2 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #1)
> Slightly tweaked, still -O1:
> char b;
> void bar (void);
>
> void
> foo (_BitInt(6110) j)
> {
> for (;;)
> {
> _BitInt(10) k = b % j;
> for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113736
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113764
Bug ID: 113764
Summary: [X86] Generates lzcnt when bsr is sufficient
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
--- Comment #1 from Iain Sandoe ---
I suppose the trivial fix is s/constexpr/const/ (but maybe there's something
more elegant).
If we agree that this is c++14 - only, then maybe we should have a separate bug
that we accept this for c++11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109559
--- Comment #8 from Richard Biener ---
Created attachment 57325
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57325=edit
patch
Patch. Breaks expected diagnostics for inlines from system headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113761
--- Comment #1 from Andrew Pinski ---
Looks like libstdc++ miss:
If
bl.size()
<
2
, let
n
=
1
,
w
0
=
1
,
b
0
=
0
, and
b
1
=
1
.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113759
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
Bug ID: 113763
Summary: [14 Regression] build fails with clang++ host compiler
because aarch64.cc uses C++14 constexpr.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760
--- Comment #4 from Jonathan Wakely ---
Please provide a proper bug report not a macro definition out of context and a
URL.
https://gcc.gnu.org/bugs/
e09b3a7e9-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240205 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
--- Comment #4 from Jonathan Wakely ---
Or just const ... why bother using constexpr at all?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
--- Comment #8 from Sebastian Huber ---
Yes, it seems that -mcpu=e6500 -mno-powerpc64 yields the right code for the
attached test case (with or without the -m32).
I am now a bit confused what the purpose of the -m32 and -m64 options is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113773
Bug ID: 113773
Summary: coroutines: promise deconstructed twice if throwing
from return object
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109809
Giulio Benetti changed:
What|Removed |Added
CC||giulio.benetti@benettiengin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109809
--- Comment #4 from Giulio Benetti ---
It's not a problem, but it looks very similar to me:
CommandScreen.c:54:1: internal compiler error: in
dwarf2out_frame_debug_cfa_offset, at dwarf2cfi.cc:1376
54 | }
| ^
0x16c6616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #5 from Iain Sandoe ---
(In reply to Iain Buclaw from comment #4)
> Looking at gcc/builtins.cc, I have a bad feeling that the only compile-time
> values one can get out of this built-in are "true" and "defer to run-time"
>
> ---
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92407
Jason Merrill changed:
What|Removed |Added
CC||joerg.rich...@pdv-fs.de
--- Comment #14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111286
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113775
Bug ID: 113775
Summary: Bogus Wstringop-overflow in __atomic_load_n combined
with sanitizer flags
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113689
--- Comment #5 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:51f8ac3341078303e81e72d9013698a31c5ddd29
commit r14-8808-g51f8ac3341078303e81e72d9013698a31c5ddd29
Author: H.J. Lu
Date: Thu Feb 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113668
--- Comment #1 from GCC Commits ---
The master branch has been updated by Ian Lance Taylor :
https://gcc.gnu.org/g:f1412546ac8999b7f6e8cf967ce3f31794c2
commit r14-8810-gf1412546ac8999b7f6e8cf967ce3f31794c2
Author: Ian Lance Taylor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109809
--- Comment #3 from Andrew Pinski ---
(In reply to Giulio Benetti from comment #2)
> (In reply to Giulio Benetti from comment #1)
> > This bug shows up also on gcc 13.2.0 while building htop with optimization
> > -O2.
> > This is worked-around
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #1 from Iain Buclaw ---
Isn't __atomic_is_lock_free tied to the __GCC_ATOMIC_XXX_T_LOCK_FREE macros?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #3 from Iain Sandoe ---
extern pure nothrow @nogc @safe bool __atomic_always_lock_free(uint,
shared(const(void))*);
extern pure nothrow @nogc @safe bool __atomic_is_lock_free(uint,
shared(const(void))*);
perhaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #6 from Iain Sandoe ---
(In reply to Iain Buclaw from comment #4)
> Looking at gcc/builtins.cc, I have a bad feeling that the only compile-time
> /* If it isn't always lock free, don't generate a result. */
> if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113767
Jason Merrill changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113214
--- Comment #3 from Jakub Jelinek ---
I think the reason for the warning is fre5 optimizing
_21 = [(struct xe_gt *)uc_8(D) + -2072B].tile;
...
- _20 = uc_8(D) + 18446744073709549544;
- _2 = _20 + _19;
+ _2 = _21 + _19;
...
_5 = _4 * 4;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109809
--- Comment #2 from Giulio Benetti ---
(In reply to Giulio Benetti from comment #1)
> This bug shows up also on gcc 13.2.0 while building htop with optimization
> -O2.
> This is worked-around by disabling optimization with -O0.
For RISCV64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #4 from Iain Buclaw ---
Looking at gcc/builtins.cc, I have a bad feeling that the only compile-time
values one can get out of this built-in are "true" and "defer to run-time"
---
/* Return a one or zero if it can be determined that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113753
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109359
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #8 from Iain Buclaw ---
Created attachment 57329
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57329=edit
The quick fix to the lock-free test
The immediate thing that can be changed is turning the test into a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #9 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #8)
> Created attachment 57329 [details]
> The quick fix to the lock-free test
>
> The immediate thing that can be changed is turning the test into a
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109359
Jason Merrill changed:
What|Removed |Added
Assignee|jason at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109359
--- Comment #10 from Jakub Jelinek ---
r14-1498-ge7cc4d703bceb9095316c106eba0d1939c6c8044
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106531
--- Comment #5 from Andrew Waterman ---
Yeah, RISC-V International decided to define B = {Zba, Zbb, Zbs}: note, not
Zbc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101976
Jonathan Wakely changed:
What|Removed |Added
Keywords||C++-coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109283
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-02-05
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113771
Bug ID: 113771
Summary: [14 Regression][GCN] ICE during GIMPLE pass: vect in
vect_transform_loop tree-vect-loop.cc:11969
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113769
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 113769, which changed state.
Bug 113769 Summary: GCC fails to warn of integer being used uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113769
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81809
Andrew Pinski changed:
What|Removed |Added
CC||symbioticfemale@cumallover.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110987
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Summary|Segmentation fault after|[13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110987
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to John Haiducek from comment #6)
> I encountered what appears to be the same bug under slightly different
> conditions; I've attached the corresponding code (see attachment named
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #2 from Iain Buclaw ---
(In reply to Iain Sandoe from comment #0)
> I am now seeing this on both Darwin and Linux BE powerpc.
>
> The message is somewhat odd, since AFAICS from the core druntime code that
> pulls in builtins.def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113740
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:194ab79b580b69554124cf8257b19c957690a8a8
commit r14-8806-g194ab79b580b69554124cf8257b19c957690a8a8
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113735
--- Comment #3 from Andrew Macleod ---
Seems reasonable to me, adding BBS should be fine throughout. just don't
re-order them :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113740
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-8795-20240204180638-g91e09b3a7e9-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240205 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #7 from Iain Buclaw ---
(In reply to Iain Sandoe from comment #6)
> (In reply to Iain Buclaw from comment #4)
> > Looking at gcc/builtins.cc, I have a bad feeling that the only compile-time
>
>
> > /* If it isn't always lock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109359
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113775
--- Comment #1 from Andrew Pinski ---
See
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Instrumentation-Options.html#index-fsanitize_003dundefined
Note that sanitizers tend to increase the rate of false positive warnings, most
notably those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113689
--- Comment #6 from H.J. Lu ---
Fixed for GCC 14 so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113668
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
1 - 100 of 188 matches
Mail list logo
