https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779
--- Comment #2 from Richard Biener ---
I don't think IVOPTs would use postinc for the intermediate increments. It's
constant propagation/forwarding that accumulates the increments to a constant
offset which removes dependences on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113775
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
Marc Poulhiès changed:
What|Removed |Added
CC||dkm at gcc dot gnu.org
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113780
--- Comment #1 from Tejas Belagod ---
Testing a fix as we speak..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113780
Tejas Belagod changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113780
Tejas Belagod changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |belagod at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113780
Bug ID: 113780
Summary: [ARM] Incorrect indirect tailcall generated for
PAC-enabled function.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113332
--- Comment #4 from Patrick Palka ---
Another reduced valid testcase:
struct tuple {
template
static constexpr bool __is_implicitly_default_constructible() { return true;
}
template()>
tuple();
};
struct DBusStruct {
DBusStruct() =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107291
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107291
--- Comment #6 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:db8d5b0ad074344559b3201e567c1e47e65d0bdd
commit r12-10138-gdb8d5b0ad074344559b3201e567c1e47e65d0bdd
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107291
--- Comment #5 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:67ac78caf31f7cb3202177e6428a46d829b70f23
commit r13-8285-g67ac78caf31f7cb3202177e6428a46d829b70f23
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113715
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113715
Huaqi changed:
What|Removed |Added
CC||fanghuaqi at vip dot qq.com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107291
--- Comment #4 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:c5d34912ad576be1ef19be92f7eabde54b9089eb
commit r14-8817-gc5d34912ad576be1ef19be92f7eabde54b9089eb
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492
--- Comment #16 from Li Pan ---
I have a try like below and finally have the Standard Name "SAT_ADD". Could you
please help to double-check if my understanding is correct?
Given below example code below:
typedef unsigned int uint32_t;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107291
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110084
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113455
--- Comment #5 from newbie-02 ---
> If you're doing arithmetic with constant operands, it might be folded at
> compile time; make sure you're using -frounding-math to avoid that.
hm... that issue is left. From your comment I was in hope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113766
--- Comment #1 from Li Pan ---
Thanks, I will take care of it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205
Sérgio Basto changed:
What|Removed |Added
CC||sergio at serjux dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #11 from Iain Buclaw ---
(In reply to Iain Sandoe from comment #10)
> (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109359
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111286
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109359
--- Comment #13 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:9b8e82ab45d1ad976a824cfd7c9bd2640c8bc8e3
commit r13-8282-g9b8e82ab45d1ad976a824cfd7c9bd2640c8bc8e3
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111286
--- Comment #6 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:c21c46032ebafb8fc36b7f02f2886a831e8c696a
commit r13-8283-gc21c46032ebafb8fc36b7f02f2886a831e8c696a
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95226
--- Comment #7 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:9b8e82ab45d1ad976a824cfd7c9bd2640c8bc8e3
commit r13-8282-g9b8e82ab45d1ad976a824cfd7c9bd2640c8bc8e3
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109359
--- Comment #12 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:470f501f31a4bdb9fa04c691ca7db2915ac3ae5b
commit r12-10136-g470f501f31a4bdb9fa04c691ca7db2915ac3ae5b
Author: Jason
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95226
--- Comment #6 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:470f501f31a4bdb9fa04c691ca7db2915ac3ae5b
commit r12-10136-g470f501f31a4bdb9fa04c691ca7db2915ac3ae5b
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111286
--- Comment #5 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:3add6b9ceefe37faac82e2d24b11c6f45e630877
commit r12-10135-g3add6b9ceefe37faac82e2d24b11c6f45e630877
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113027
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #9 from Martin Jambor ---
SRA creates the replacements (in GCC 13) during total scalarization,
i.e. the bit that is not driven by pre-existing accesses to
aggregates, but because it sees an aggregate that is small and regular
and so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
--- Comment #10 from Jakub Jelinek ---
Created attachment 57334
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57334=edit
gcc14-pr113763.patch
Can't we just get rid of std::pair here? I mean, 0xff certainly fits into host
unsigned char,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109359
--- Comment #11 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:d49780c08aade447953bfe4e877d386f5757f165
commit r14-8813-gd49780c08aade447953bfe4e877d386f5757f165
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111286
--- Comment #4 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:c7e8381748f78335e9fef23f363b6a9e4463ce7e
commit r14-8811-gc7e8381748f78335e9fef23f363b6a9e4463ce7e
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113778
--- Comment #1 from Andrew Pinski ---
I noticed the loop which calls rtx_properties::add_insn does not check if the
insn was not a RTX_INSN (BARRIER, CODE_LABEL and NOTE can appeal bare in the
RTL IR but are not insns).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779
--- Comment #1 from Andrew Pinski ---
> So what's the catch here? Why gcc hates move.l (ax)+,(ay)+ so much?
At one point of time (before I think GCC 9 or 8 or so), GCC's IV-OPTs
optimization does not take into account post/pre increment, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779
Bug ID: 113779
Summary: Very inefficient m68k code generated for simple copy
loop
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
std
gcc version 14.0.1 20240205 (experimental) (GCC)
on 14.0.1 20240205 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110676
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110676
--- Comment #4 from Jakub Jelinek ---
Started with r8-5902-gc42d0aa0893cab444366c80fdd5b23bb45de6276
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106531
Andrew Pinski changed:
What|Removed |Added
Summary|-march=rv32iabmc should |-march=rv32iabmc should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113776
Jakub Jelinek changed:
What|Removed |Added
Summary|[14 regression] |[14 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113776
--- Comment #1 from Sam James ---
tl;dr: are d and f supposed to be compilable / are they constant expressions in
C?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113776
Bug ID: 113776
Summary: [14 regression] postgresql-16.1 build failure with
-Werror=vla in configure test
Product: gcc
Version: 14.0
Status: UNCONFIRMED
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=113668
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=113689
--- Comment #6 from H.J. Lu ---
Fixed for GCC 14 so far.
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=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=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=109359
--- Comment #10 from Jakub Jelinek ---
r14-1498-ge7cc4d703bceb9095316c106eba0d1939c6c8044
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=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=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=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=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 #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=113767
Jason Merrill changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92407
Jason Merrill changed:
What|Removed |Added
CC||joerg.rich...@pdv-fs.de
--- Comment #14
-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 #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=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=113740
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=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=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 #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=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=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=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=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=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=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=109809
Giulio Benetti changed:
What|Removed |Added
CC||giulio.benetti@benettiengin
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=81809
Andrew Pinski changed:
What|Removed |Added
CC||symbioticfemale@cumallover.
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=113769
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113770
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113757
Martin Jambor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113214
--- Comment #2 from Arnd Bergmann ---
The warning is now turned off in the kernel as a workaround:
https://lore.kernel.org/all/CAHk-=whzbdlc024nxgjesfoopj9bo2bkuxhxr4h5wosyk9a...@mail.gmail.com/
Also, my local one-line workaround is applied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113767
Jason Merrill changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113767
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
Iain Sandoe changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113765
--- Comment #3 from Andi Kleen ---
-O1 fixes it, so an easy patch would be
diff --git a/gcc/auto-profile.cc b/gcc/auto-profile.cc
index 63d0c3dc36df..180ed7a8260f 100644
--- a/gcc/auto-profile.cc
+++ b/gcc/auto-profile.cc
@@ -1758,7 +1758,7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
Bug ID: 113772
Summary: [14 Regression] atomic.d compile error since recent
upstream imports.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
--- Comment #9 from Jonathan Wakely ---
No, _GLIBCXX14_CONSTEXPR only cares about 11 vs 14, not strict vs gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110987
--- Comment #6 from John Haiducek ---
I encountered what appears to be the same bug under slightly different
conditions; I've attached the corresponding code (see attachment named
"Additional test case"). In this code the crash occurs when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
--- Comment #8 from Iain Sandoe ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Jakub Jelinek from comment #6)
> > Jon, what about Iain's question whether it isn't a bug we use constexpr on
> > the ctor even in C++11 mode?
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
--- Comment #7 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #6)
> Jon, what about Iain's question whether it isn't a bug we use constexpr on
> the ctor even in C++11 mode?
> Do we treat such papers as DRs on the library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113767
Patrick Palka changed:
What|Removed |Added
Keywords|needs-bisection |
Target Milestone|---
1 - 100 of 188 matches
Mail list logo
