https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
--- Comment #5 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114930
Richard Biener changed:
What|Removed |Added
Keywords||ice-checking,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114932
--- Comment #1 from Richard Biener ---
The change likely made SCEV/IVOPTs "stop" at more convenient places, but we can
only know when there's more detailed analysis.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114921
--- Comment #2 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:87e35da16df74cd1c4729a55d94e7bc592487f48
commit r15-124-g87e35da16df74cd1c4729a55d94e7bc592487f48
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114924
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.5
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114927
uecker at gcc dot gnu.org changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114932
Bug ID: 114932
Summary: Improvement in CHREC can give large performance gains
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931
--- Comment #4 from Sam James ---
```
struct Tcl_Obj;
void(Tcl_FreeInternalRepProc)(struct Tcl_Obj *);
typedef struct Tcl_Obj {
} Tcl_Obj;
struct {
void (*tclFreeObj)(Tcl_Obj *);
} Tcl_InitStubs;
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114930
Sam James changed:
What|Removed |Added
Summary|ICE in |[14/15 regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931
--- Comment #3 from Andrew Pinski ---
It will involve the struct TclStubs too. I suspect it does not have its
aliasing set correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931
--- Comment #1 from Sam James ---
With -Wuninitialized, it dies in an earlier pass:
```
# gcc -c tclStubLib.i -std=c23 -Wuninitialized
during GIMPLE pass: early_uninit
/var/tmp/portage/dev-lang/tcl-8.6.14/work/tcl8.6.14/generic/tclStubLib.c: In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931
Bug ID: 114931
Summary: ICE in get_alias_set when building tcl with -std=c23
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114930
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114930
--- Comment #1 from Sam James ---
reduced:
```
typedef struct WebPPicture WebPPicture;
typedef int (*WebPProgressHook)(const WebPPicture *);
WebPProgressHook progress_hook;
struct WebPPicture {
} WebPGetColorPalette(const struct WebPPicture *);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114930
Bug ID: 114930
Summary: ICE in fld_incomplete_type_of when building libwebp
with -std=c23 -flto
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114927
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Summary|ICE when buildi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114927
Sam James changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
--- Comment #9 from nfxjfg at googlemail dot com ---
Oh, I completely missed that your statement was restricted to "in HW". Normally
there are mechanisms in place that make all CPU-level memory accesses to
registers strictly ordered. (In our hard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114929
Gaius Mulley changed:
What|Removed |Added
Version|14.0|15.0
--- Comment #4 from Gaius Mulley -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114929
--- Comment #3 from GCC Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:a561dc0f6c7085e102fe9e9b6abd7f2138512576
commit r15-122-ga561dc0f6c7085e102fe9e9b6abd7f2138512576
Author: Gaius Mulley
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114929
--- Comment #2 from Gaius Mulley ---
Created attachment 58092
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58092&action=edit
Proposed fix
Here is a proposed bug fix with 6 for loop regression tests.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114929
Gaius Mulley changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114929
Bug ID: 114929
Summary: for loop fails to iterate down to zero if a cardinal
type (unsigned type) is used with a step of -1.
Product: gcc
Version: 14.0
Status: UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
--- Comment #8 from Andrew Pinski ---
(In reply to nfxjfg from comment #7)
> > Note also the order of the writes to reg1 and reg2 might happen in a
> > different order in HW so you need to have a full (HW) write barrier between
> > them to mak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
--- Comment #27 from GCC Commits ---
The releases/gcc-11 branch has been updated by Peter Bergner
:
https://gcc.gnu.org/g:f8f02fd0bfeeb733a044a120b394eeac48de318a
commit r11-11413-gf8f02fd0bfeeb733a044a120b394eeac48de318a
Author: Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
--- Comment #26 from GCC Commits ---
The releases/gcc-11 branch has been updated by Peter Bergner
:
https://gcc.gnu.org/g:26d48b6d3e2d07583f25f0769d0c005864760aee
commit r11-11412-g26d48b6d3e2d07583f25f0769d0c005864760aee
Author: Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
--- Comment #7 from nfxjfg at googlemail dot com ---
> Note also the order of the writes to reg1 and reg2 might happen in a
> different order in HW so you need to have a full (HW) write barrier between
> them to make sure the write is done in t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114928
Bug ID: 114928
Summary: #pragma packed(push,1) should give the same warning as
__attribute__((packed))
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114927
Bug ID: 114927
Summary: ICE when building Emacs with -std=c23 -flto (error:
‘TYPE_CANONICAL’ has different ‘TYPE_CANONICAL’)
Product: gcc
Version: 14.0
Status: UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290
--- Comment #34 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #22)
> Without load/store handling, here are the following optimizations that
> either can move to match.pd already or need some extra work to do it:
>
> * value_repl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61110
--- Comment #5 from Andrew Pinski ---
Created attachment 58089
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58089&action=edit
Start of rewriting value_replacement to use match-and-simplify
This is a start and does not remove the old code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23872
--- Comment #10 from Andrew Pinski ---
Patches submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650586.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650587.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650585.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
Andrew Pinski changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106928
--- Comment #5 from Andrew Pinski ---
*** This bug has been marked as a duplicate of bug 103088 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106928
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #4 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103318
Andrew Pinski changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97263
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111882
Richard Ball changed:
What|Removed |Added
CC||ricbal02 at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107021
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Andrew Pinski ---
> If Aldy does not fix it by Saturday, I will give the union a try then. I will
Great, thanks. Your alignas patch also worked fine btw.
> al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77704
Rustam Abdullaev changed:
What|Removed |Added
CC||rustamabd at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
--- Comment #10 from Andrew Pinski ---
If Aldy does not fix it by Saturday, I will give the union a try then. I will
also try out the solaris machine on the compile farm if possible.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114582
--- Comment #3 from Ian Lance Taylor ---
*** Bug 114583 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114583
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114582
--- Comment #4 from Ian Lance Taylor ---
*** Bug 114584 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114584
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114582
--- Comment #2 from Ian Lance Taylor ---
*** Bug 114581 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114581
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114582
--- Comment #1 from Ian Lance Taylor ---
The bug here, and also with PR 114581, is in unwinding from a signal call. A
simplified version of the code for this issue is:
func main() {
defer func() { recover() }()
f()
}
func f() { *p = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114672
--- Comment #6 from GCC Commits ---
The releases/gcc-12 branch has been updated by Richard Ball
:
https://gcc.gnu.org/g:87e37c72cfb153d65ac8b26d6f2d1fe155818318
commit r12-10410-g87e37c72cfb153d65ac8b26d6f2d1fe155818318
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114672
--- Comment #5 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Ball
:
https://gcc.gnu.org/g:0d625dc1bffd885b04eb90ff48a6d34acacc3e0b
commit r13-8676-g0d625dc1bffd885b04eb90ff48a6d34acacc3e0b
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
--- Comment #6 from Andrew Pinski ---
Some resources about memory barriers and why they are needed here (for both HW
and SW):
https://en.wikipedia.org/wiki/Memory_barrier
https://www.kernel.org/doc/Documentation/memory-barriers.txt
https://www.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114920
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114922
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910
--- Comment #6 from Marc Poulhiès ---
It fails with -Os.
It works with -O0, -O1, -O2, -O3 and -Os -fno-var-tracking.
Mikael, is it possible that you're not using -Os for target libs?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114925
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-05-02
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114922
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |INVALID
Status|U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734
--- Comment #15 from GCC Commits ---
The master branch has been updated by Patrick O'Neill :
https://gcc.gnu.org/g:ff4dc8b10a421cdb0c56f7f8c238609de4f9fbe2
commit r15-116-gff4dc8b10a421cdb0c56f7f8c238609de4f9fbe2
Author: Patrick O'Neill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114925
--- Comment #2 from fabian_kessler at gmx dot de
---
(In reply to Andrew Pinski from comment #1)
> I thought char8_t is still a character type so aliasing wise it falls under
> that rule.
Actually no. They are distinct types and only 4 types a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114926
Bug ID: 114926
Summary: Add way to silence deprecation warning for fs::u8path
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
--- Comment #25 from Nicolas Boulenguez ---
The suggested changes for libgnat slightly affect gprbuild.
https://salsa.debian.org/debian/gprbuild/-/blob/debian/master/debian/patches/adapt-to-private-time-t.diff
https://salsa.debian.org/debian/gpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111709
John David Anglin changed:
What|Removed |Added
Last reconfirmed||2024-05-02
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114913
Patrick Palka changed:
What|Removed |Added
See Also|https://gcc.gnu.org/bugzill |https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114925
--- Comment #1 from Andrew Pinski ---
I thought char8_t is still a character type so aliasing wise it falls under
that rule.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #19 from Peter Dimov ---
This should work.
I still don't understand why JF so insisted on all these padding shenanigans.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114925
Bug ID: 114925
Summary: include/bits/fs_path.h#L841 deprecation note suggests
UB
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672
Jonathan Wakely changed:
What|Removed |Added
Known to work||13.2.1, 14.0
Summary|[11/12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104606
Jonathan Wakely changed:
What|Removed |Added
Known to work||13.2.1, 14.0
Summary|[11/1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672
--- Comment #7 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:fcf60d0baafa1245f768ac375dc60a07e92e9673
commit r13-8675-gfcf60d0baafa1245f768ac375dc60a07e92e9673
Author: Jonathan Wakel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104606
--- Comment #15 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:3d16f8f2aec9583422d00c531732ca9d33e6ef26
commit r13-8674-g3d16f8f2aec9583422d00c531732ca9d33e6ef26
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114913
Patrick Palka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
--- Comment #4 from Alexander Monakov ---
You can place points of possible access outside of abstract machine in a
fine-grained manner with volatile asms:
asm volatile("" : "=m"(buf));
This cannot be reordered against accesses to volatile va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 114917, which changed state.
Bug 114917 Summary: [modules] Explicit specialisations in export namespace not
permitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114917
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114917
Nathaniel Shead changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114917
--- Comment #1 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:7317d62a1200dbd3685015e5d6b811497a27fe5f
commit r15-114-g7317d62a1200dbd3685015e5d6b811497a27fe5f
Author: Nathaniel Shead
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
--- Comment #3 from nfxjfg at googlemail dot com ---
I'm expecting gcc to realize that the pointer escaped into the unknown, and
that it can't assume that the memory won't change. This is just causality, not
any vague made up viralyness.
Anyway,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910
--- Comment #5 from Mikael Pettersson ---
I don't use crosstool-ng, but I have no problems building a cross to
c6x-unknown-elf with binutils-2.42, gcc-14.1.0-RC-20240430, and
newlib-4.4.0.20231231. (A cross to c6x-unknown-uclibc with uclibc-ng-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
--- Comment #25 from GCC Commits ---
The releases/gcc-12 branch has been updated by Peter Bergner
:
https://gcc.gnu.org/g:04ca18ff5e2592ac88a5b72248332f519a17184b
commit r12-10409-g04ca18ff5e2592ac88a5b72248332f519a17184b
Author: Will Schmidt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
--- Comment #24 from GCC Commits ---
The releases/gcc-12 branch has been updated by Peter Bergner
:
https://gcc.gnu.org/g:135402288a1b1b082d2e71ff2ee5c63b7dafed9f
commit r12-10408-g135402288a1b1b082d2e71ff2ee5c63b7dafed9f
Author: Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114924
Alex Coplan changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot
gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114924
Bug ID: 114924
Summary: [11/12/13/14/15 Regression] Wrong update of MEM_EXPR
by RTL loop unrolling since r11-2963-gd6a05b494b4b71
Product: gcc
Version: 14.0
Status: UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
--- Comment #1 from nfxjfg at googlemail dot com ---
To make this explicitly clear: I expect that gcc reads back the buf value from
memory and returns that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
Bug ID: 114923
Summary: gcc ignores escaping pointer and applies invalid
optimization
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114922
Bug ID: 114922
Summary: fsyntax-only need the modules
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113706
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #13 from Jason Merrill ---
> Should be fixed now.
It is indeed. Thanks a lot.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114672
Richard Ball changed:
What|Removed |Added
CC||ricbal02 at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113836
Gaius Mulley changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113836
--- Comment #10 from GCC Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:43dc4302b4181535d24e83759514b774ae4dbfcc
commit r15-110-g43dc4302b4181535d24e83759514b774ae4dbfcc
Author: Gaius Mulley
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112958
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Gerald Pfeifer ---
> FreeBSD i386 is on it's way out: FreeBSD 14 is the last series supporting
> it; FreeBSD 15 is dropping support for it.
Ah, I wasn't aware of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #18 from Jonathan Wakely ---
So maybe:
diff --git a/libstdc++-v3/include/bits/atomic_base.h
b/libstdc++-v3/include/bits/atomic_base.h
index aa7374bb252..662cff39df5 100644
--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #17 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #15)
> --- a/libstdc++-v3/include/std/atomic
> +++ b/libstdc++-v3/include/std/atomic
> @@ -238,8 +238,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>
>constexp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #16 from Jonathan Wakely ---
Alternatively, we could skip all the padding cope in compare_exchange for
C++11, since that was a C++20 change and not a DR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114921
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #15 from Jonathan Wakely ---
--- a/libstdc++-v3/include/std/atomic
+++ b/libstdc++-v3/include/std/atomic
@@ -238,8 +238,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
constexpr atomic(_Tp __i) noexcept : _M_i(__i)
{
-#if __cpl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #14 from Jonathan Wakely ---
Because a constexpr function can't have an if statement in C++11.
But maybe we should just clear padding unconditionally for C++11.
1 - 100 of 141 matches
Mail list logo
