https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112339
--- Comment #3 from Niall Douglas ---
Thanks for the patch. I've sent it on to the originator of the bug, if they
confirm it fixes their issue to me I'll let you know.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112339
Bug ID: 112339
Summary: ICE with namespaced attribute on function
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111041
Bug ID: 111041
Summary: Malformed requires syntax should produce better
diagnostics
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659
--- Comment #10 from Niall Douglas ---
(In reply to Jakub Jelinek from comment #9)
> (In reply to Wilco from comment #8)
> > Yes that sounds like a reasonable approach.
>
> I don't think so. Not all variables on which __atomic_* intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659
--- Comment #7 from Niall Douglas ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Niall Douglas from comment #3)
> > You may be interested in reading https://reviews.llvm.org/D110069. It wanted
> > to have LLVM generate a 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659
--- Comment #3 from Niall Douglas ---
> AMD has guaranteed it, but there is still VIA and Zhaoxin and while we have
> some statement from the latter, I'm not sure it is enough and we don't have
> anything from VIA. See PR104688 for details.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659
Bug ID: 108659
Summary: Suboptimal 128 bit atomics codegen on AArch64 and x64
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101133
Niall Douglas changed:
What|Removed |Added
CC||s_gccbugzilla at nedprod dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95609
--- Comment #8 from Niall Douglas ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Niall Douglas from comment #0)
> > I would assume that the ABI ship has sailed, as usual, but if libstdc++'s
> > span could instead have the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #35 from Niall Douglas ---
(In reply to Jonathan Wakely from comment #34)
> > Perhaps I ought to open a separate issue here, as my specific problem is
> > that std::atomic<__int128>::compare_exchange_weak() is not using cmpxchg16b?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649
Niall Douglas changed:
What|Removed |Added
CC||s_gccbugzilla at nedprod dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #33 from Niall Douglas ---
(In reply to Andrew Pinski from comment #31)
>
> Again the problem is stuff like:
> static const _Atomic __int128_t t = 2000;
>
> __int128_t g(void)
> {
> return t;
> }
>
> DOES NOT WORK if you use CAS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
Niall Douglas changed:
What|Removed |Added
CC||s_gccbugzilla at nedprod dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95609
--- Comment #6 from Niall Douglas ---
Cool, thanks. I believe that all three major STLs now implement struct iovec
compatibility with span. That's a nice win.
14 matches
Mail list logo
