[Bug c++/117913] destroying delete operator should have implicit expection speciification

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117913 --- Comment #4 from Alisdair Meredith --- In this case, clang and MSVC are not even considering the destroying delete within the noexcept operator within a static_assert --- I am not sure at what point that breaks down though. The runtime tests

[Bug c++/117913] destroying delete operator should have implicit expection speciification

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117913 --- Comment #3 from Alisdair Meredith --- Clang and MSVC have bigger bugs that I am filing bug reports on shortly! EDG gets this correct and passes all parts of the test, including the "expected" undefined behavior: https://godbolt.org/z/EG3EP5

[Bug c++/117913] destroying delete operator should have implicit expection speciification

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117913 --- Comment #1 from Alisdair Meredith --- Sorry, I made no effort to verify how far back this bug goes, but I expect it has been an issue ever since destroying delete was first implemented.

[Bug c++/117913] New: destroying delete operator should have implicit expection speciification

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117913 Bug ID: 117913 Summary: destroying delete operator should have implicit expection speciification Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: norma

[Bug preprocessor/94535] __LINE__ value changed for function-like macro invocations spanning multiple lines

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535 --- Comment #15 from Alisdair Meredith --- I suggest either INVALID or WONTFIX would be appropriate, depending on whether you think the original report on a change of behavior was valid.

[Bug c++/92034] extern template declarations cannot have internal linkage (unnamed namespace)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92034 --- Comment #6 from Alisdair Meredith --- Minor update: in the current standard, the paragraph number is now p12, and per my last comment, I still believe the use of "shall" makes this ill-formed, and without "no diagnostic required" wording it s

[Bug c++/71029] large fold expressions compile slowly with -Wall

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71029 --- Comment #4 from Alisdair Meredith --- Revisiting some of my old bug reports, I can confirm that this performance issue is resolved. I verified it was still present in gcc 10 so that it was not a failure to reproduce on my part, and then stop

[Bug c++/63287] __STDCPP_THREADS__ is not defined

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63287 --- Comment #7 from Alisdair Meredith --- Late comment: according to [intro.multithread.general] it is a requirement for hosted implementations to support more than one thread of execution, but implementation defined for a free-standing implement

[Bug c++/90960] declaring a member function with a computed typedef is confused as a data member definition

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90960 --- Comment #4 from Alisdair Meredith --- I now believe my original bug report is invalid, due to a rarely consulted paragraph of the standard, [temp.spec.general]p8. If a function declaration acquired its function type through a dependent type

[Bug c++/98939] [C++23] Implement P1787R6 "Declarations and where to find them"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98939 Alisdair Meredith changed: What|Removed |Added CC||alisdairm at me dot com --- Comment

[Bug c++/43144] Possible ADL bug in GCC 4.4.1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43144 --- Comment #2 from Alisdair Meredith --- gcc 4.5 and later correctly report errors, as the language specification for rvalue and forwarding references changed between 4.4 and 4.5. I'm not sure what ADL bug I thought I was hitting, but with the

[Bug c++/98038] ICE on invalid trying to recursively invoke a lambda object with operator()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98038 --- Comment #1 from Alisdair Meredith --- The following example code gives an internal compiler error, I suspect due to the invalid attempt to call `operator()` recursively on the lambda object. Use the -std=c++20 language flag: #include #incl

[Bug c++/98038] New: ICE on invalid trying to recursively invoke a lambda object with operator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98038 Bug ID: 98038 Summary: ICE on invalid trying to recursively invoke a lambda object with operator Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal