https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
--- Comment #15 from Jiang An ---
(In reply to Arthur O'Dwyer from comment #11)
> @jwakely, I propose that this issue should be recategorized as a compiler
> bug. (And I'm also voting effectively "NAD" on LWG3967.)
Hmm... IMO given the current
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
--- Comment #13 from Arthur O'Dwyer ---
(In reply to Andrew Pinski from comment #12)
> I suspect this is a dup of bug 100470 then.
Yep, I agree. My previous comment was a longwinded version of jwakely's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
--- Comment #12 from Andrew Pinski ---
I suspect this is a dup of bug 100470 then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
--- Comment #10 from Jiang An ---
https://cplusplus.github.io/LWG/issue3967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
--- Comment #9 from Jiang An ---
(In reply to Nikolas Klauser from comment #8)
> I agree that the wording is a bit ambiguous, but GCC should decide on one
> of them instead of returning different results between the type trait
> builtins and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
--- Comment #8 from Nikolas Klauser ---
I agree that the wording is a bit ambiguous, but GCC should decide on one of
them instead of returning different results between the type trait builtins and
the noexcept operator.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
Jiang An changed:
What|Removed |Added
CC||de34 at live dot cn
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
--- Comment #6 from Nikolas Klauser ---
Is there any update on this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
--- Comment #5 from Nikolas Klauser ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Nikolas Klauser from comment #2)
> > static_assert(!noexcept(std::declval(;
> >
> > is fine.
>
> It doesn't look fine to me! Is there a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
--- Comment #4 from Jonathan Wakely ---
(In reply to Nikolas Klauser from comment #2)
> static_assert(!noexcept(std::declval(;
>
> is fine.
It doesn't look fine to me! Is there a 'CopyConstructible(' missing?
The reproducer for comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
--- Comment #3 from Nikolas Klauser ---
I did some more digging and it looks like nobody can agree on what the right
result is.
This is the result of the question whether the listed operation on struct S {
noexcept(false) = default; } is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
--- Comment #2 from Nikolas Klauser ---
(In reply to Jonathan Wakely from comment #1)
> The noexcept specifier is wrong, but is ignored. The implicitly defined copy
> constructor is noexcept, so the trait gives the right answer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
--- Comment #1 from Jonathan Wakely ---
The noexcept specifier is wrong, but is ignored. The implicitly defined copy
constructor is noexcept, so the trait gives the right answer.
15 matches
Mail list logo
