[Bug c++/114663] Several contracts test cases fail with -fsanitize=undefined -fsanitize-trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114663 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #3 from Ville Voutilainen --- (4) We can have multiple failing contracts in one test, as long as - the continuation mode is on - all such contracts are evaluated, I mean checked. In other words, no mixing of would-fail (axiom) contracts with ones that we want to test to fail. So, the tests are bad. contract10.C has a failing axiom contract in it, but it also tries to test checked contracts for failing. That won't work. The axiom contract's assumption nukes the whole test. We should test failing checked contracts by looking at the output of the run, and separately from that, test failing unchecked contracts by looking at the tree output of the compilation. And not mix the two, unless we do all testing by looking at the tree output. But we should never have failing unchecked contracts in tests where we also want to runtime-verify contract failures. I do expect to eventually resurrect axiom contracts in a non-assumed form, and when we do that, there should be a possibility to runtime-check them with code that is entirely compiler-instrumented/generated. But that work is some ways off, and in the meantime we should remove the UB from runtime tests that attempt to runtime-test for contract failures.
[Bug c++/115601] ICE when compiling a function marked noipa/noinline called in a contract predicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115601 --- Comment #2 from Ville Voutilainen --- Created attachment 58499 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58499=edit Preprocessed source
[Bug c++/115601] New: ICE when compiling a function marked noipa/noinline called in a contract predicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115601 Bug ID: 115601 Summary: ICE when compiling a function marked noipa/noinline called in a contract predicate Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ville.voutilainen at gmail dot com Target Milestone: ---
[Bug middle-end/112312] New: GCC fails to optimize a C++ algorithm with a function passed in as well as with a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112312
Bug ID: 112312
Summary: GCC fails to optimize a C++ algorithm with a function
passed in as well as with a lambda
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
See
https://godbolt.org/z/s8dWGzb9r
When passing a (pointer to) function as a predicate argument for a C++ stdlib
algorithm, various people hope that it optimizes as well as passing a lambda
that does exactly the same thing. And with clang, it does. With gcc, the
generated
code is much worse for the function case, even though the function definition
is nearby and visible.
The test code used on godbolt pasted for convenience:
#include
#include
#include
static bool pred1(const std::string& a, const std::string& b)
{
return false;
}
auto pred2 = [](const std::string& a, const std::string& b)
{
return false;
};
bool func1(const std::vector& vec, const std::string& needle)
{
return std::ranges::lower_bound(vec, needle, pred1) != vec.end();
}
bool func2(const std::vector& vec, const std::string& needle)
{
return std::ranges::lower_bound(vec, needle, pred2) != vec.end();
}
[Bug c++/110851] New: [contracts] Inheriting multiple base functions with clashing contracts is not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110851
Bug ID: 110851
Summary: [contracts] Inheriting multiple base functions with
clashing contracts is not diagnosed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
See https://wandbox.org/permlink/SICxkVAe2gVql3Ae
tl;dr:
struct Base1 {
virtual void g(int x) [[ pre : x > 0 ]] {}
};
struct Base2 {
virtual void g(int x) [[ pre : x <= 0 ]] {}
};
struct Derived : public Base1, public Base2 {
virtual void g(int x) override {}
};
int main()
{
Derived d1;
Base1& b1 = d1;
Base2& b2 = d1;
b1.g(42);
//b2.g(-42);
}
The various online compilers accept and run the code. On my machine, I get an
assembler diagnostic:
/tmp/ccYlVuY9.s: Assembler messages:
/tmp/ccYlVuY9.s:53: Error: symbol `_ZN7Derived1gEi' is already defined
which is saying that Derived::g(int)
is already defined.
The declaration of Derived::g() ought to be ill-formed, because the base
functions do not have the same list of contracts.
[Bug c++/108099] [12/13 Regression] ICE with type alias with `signed __int128_t`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
--- Comment #11 from Ville Voutilainen ---
More cases that ICE:
template using AT = int;
using AA = AT;
template struct AT{};
using AA = AT;
template struct AT{};
AT x;
[Bug libstdc++/107525] propagate_const should not be using SFINAE on its conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107525 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #8 from Ville Voutilainen --- (In reply to Jonathan Wakely from comment #7) > Ping Ville: please take a look Looks fine to me.
[Bug c++/85889] lambda expression can capture structured bindings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85889 --- Comment #5 from Ville Voutilainen --- And the papers that changed this are https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1091r3.html and https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1381r1.html
[Bug c++/85889] lambda expression can capture structured bindings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85889 Ville Voutilainen changed: What|Removed |Added Status|SUSPENDED |ASSIGNED --- Comment #4 from Ville Voutilainen --- Clang and MSVC now accept the code in their C++20 modes. Close as invalid? Or does someone want to fix this for the C++17 and below modes only? I don't suppose we ever decided in the committee to make this a DR. [expr.prim.lambda.capture]/4 says: "The identifier in a simple-capture shall denote a local entity (6.5.3, 6.1)." 6.1 specifies structured bindings to be local entities, so capturing them is now supported.
[Bug c++/107049] error: ‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator __sv_type() const [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator; __sv_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107049 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #9 from Ville Voutilainen --- Just a historical anecdote of something eerily similar in so many ways, including Jonathan's reduction and its steps :) : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94197
[Bug c++/106567] [13 Regression] An array with a dependent type and initializer-deduced bound is treated as an array of unknown bound when captured in a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106567 --- Comment #7 from Ville Voutilainen --- Since this is a 13 regression, we can close this, right? There's no backports needed.
[Bug c++/106423] -Wc++20-compat diagnostics not suppressed by #pragma GCC diagnostic ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106423 --- Comment #4 from Ville Voutilainen --- (In reply to Tom Honermann from comment #3) > I believe this issue can be resolved as fixed via commit > 60468d6cd46a3bd3afe8ff856f82afcd4c65a217 for the gcc 13 release. Yes, it's normal procedure that the bz will be closed as fixed once the patches have been merged, it's just a separate step.
[Bug c++/106423] -Wc++20-compat diagnostics not suppressed by #pragma GCC diagnostic ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106423 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com Last reconfirmed||2022-08-09 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug c++/106567] [13 regression] An array with a dependent type and initializer-deduced bound is treated as an array of unknown bound when captured in a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106567
--- Comment #1 from Ville Voutilainen ---
Repro without std::vector:
template
void urgh()
{
const V x[] = {V(0), V(1), V(2), V(0)};
[&]() {
for (auto& v : x) {}
}();
}
void no_urgh()
{
using V = int;
const V x[] = {V(0), V(1), V(2), V(0)};
[&]() {
for (auto& v : x) {}
}();
}
int main()
{
no_urgh();
urgh();
}
[Bug c++/106567] New: An array with a dependent type and initializer-deduced bound is treated as an array of unknown bound when captured in a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106567
Bug ID: 106567
Summary: An array with a dependent type and initializer-deduced
bound is treated as an array of unknown bound when
captured in a lambda
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
Test:
#include
template
void urgh()
{
using V = typename T::value_type;
const V x[] = {V(0), V(1), V(2), V(0)};
[&]() {
for (auto& v : x) {}
}();
}
void no_urgh()
{
using V = int;
const V x[] = {V(0), V(1), V(2), V(0)};
[&]() {
for (auto& v : x) {}
}();
}
int main()
{
no_urgh();
urgh>();
}
Live demo at https://wandbox.org/permlink/9hSQdxhNzgDCuXYZ
prog.cc: In instantiation of 'void urgh() [with T = std::vector]':
prog.cc:29:27: required from here
prog.cc:11:9: error: range-based 'for' expression of type 'const int []' has
incomplete type
11 | for (auto& v : x) {}
| ^~~
[Bug libstdc++/105926] Using a spaceship operator on an optional of a type derived from optional causes infinite constraint recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105926 Ville Voutilainen changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at gmail dot com --- Comment #1 from Ville Voutilainen --- I have a patch for it, and this likely needs a LWG issue and probably a LEWG ack. I'll submit the latter soon-ish, and will post the patch for review, too.
[Bug libstdc++/105926] New: Using a spaceship operator on an optional of a type derived from optional causes infinite constraint recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105926
Bug ID: 105926
Summary: Using a spaceship operator on an optional of a type
derived from optional causes infinite constraint
recursion
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
Testcase:
#include
struct oink : std::optional {
};
bool operator<(const oink&, const oink) {return false;}
bool operator>(const oink&, const oink) {return true;}
bool operator<=(const oink&, const oink) {return false;}
bool operator>=(const oink&, const oink) {return true;}
bool operator==(const oink&, const oink) {return false;}
bool operator!=(const oink&, const oink) {return true;}
int main()
{
oink a;
std::optional b;
b <=> a;
}
Ends up, eventually, with..
error: satisfaction of atomic constraint 'requires(const typename
std::remove_reference<_Tp>::type& __t, const typename
std::remove_reference<_Arg>::type& __u) {{__t < __u} -> decltype(auto)
[requires std::__detail::__boolean_testable<, >];{__t > __u} ->
decltype(auto) [requires std::__detail::__boolean_testable<,
>];{__t <= __u} -> decltype(auto) [requires
std::__detail::__boolean_testable<, >];{__t >= __u} ->
decltype(auto) [requires std::__detail::__boolean_testable<,
>];{__u < __t} -> decltype(auto) [requires
std::__detail::__boolean_testable<, >];{__u > __t} ->
decltype(auto) [requires std::__detail::__boolean_testable<,
>];{__u <= __t} -> decltype(auto) [requires
std::__detail::__boolean_testable<, >];{__u >= __t} ->
decltype(auto) [requires std::__detail::__boolean_testable<, >];}
[with _Up = oink; _Tp = oink]' depends on itself
302 | = requires(const remove_reference_t<_Tp>& __t,
| ^~~~
303 |const remove_reference_t<_Up>& __u) {
|~
304 | { __t < __u } -> __boolean_testable;
| ~
305 | { __t > __u } -> __boolean_testable;
| ~
306 | { __t <= __u } -> __boolean_testable;
| ~
307 | { __t >= __u } -> __boolean_testable;
| ~
308 | { __u < __t } -> __boolean_testable;
| ~
309 | { __u > __t } -> __boolean_testable;
| ~
310 | { __u <= __t } -> __boolean_testable;
| ~
311 | { __u >= __t } -> __boolean_testable;
| ~
312 | };
The relevant bit being "satisfaction of atomic constraint foo depends on
itself".
[Bug c++/82470] Structured bindings don't work with std::tuple if a type has a get member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82470 --- Comment #7 from Ville Voutilainen --- We should close this, the fixes are in 11 and the related bugs have been closed without backports. I'm happy to let JWakely do that closing, but I don't think he'll disagree on it. :P
[Bug c++/82470] Structured bindings don't work with std::tuple if a type has a get member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82470 --- Comment #6 from Ville Voutilainen --- I think this was fixed by the fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71096
[Bug c++/62274] [C++11] Variadic templates expansion into non-variadic class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62274 Ville Voutilainen changed: What|Removed |Added CC||jason at redhat dot com --- Comment #7 from Ville Voutilainen --- I think this may be subject to various Core discussions. Jason?
[Bug libstdc++/99277] C++2a synchronisation is inefficient in GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99277 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #5 from Ville Voutilainen --- Look people, this just *CAN'T* be a blocker for GCC11. That's a tail wagging a dog; yeah sure there may be an ABI break in a C++20 concurrency facility, but to have that block the GCC 11 release is just.. ..unfathomable. Just my 0.02 on the blocker-ness of this.
[Bug c++/98646] New: A static_cast confuses -Wnonnull, causing false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98646 Bug ID: 98646 Summary: A static_cast confuses -Wnonnull, causing false positives Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ville.voutilainen at gmail dot com Target Milestone: --- Created attachment 49957 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49957=edit Preprocessed source Compile with /usr/local/bin/c++ -DQT_ASCII_CAST_WARNINGS -DQT_BUILDING_QT -DQT_BUILD_XCB_PLUGIN -DQT_BUILD_XCB_QPA_LIB_LIB -DQT_CORE_LIB -DQT_DEPRECATED_WARNINGS -DQT_DEPRECATED_WARNINGS_SINCE=0x06 -DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_GUI_LIB -DQT_MOC_COMPAT -DQT_NO_CAST_TO_ASCII -DQT_NO_EXCEPTIONS -DQT_NO_FOREACH -DQT_OPENGL_LIB -DQT_USE_QSTRINGBUILDER -DXcbQpa_EXPORTS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wextra -fno-exceptions -fPIC -Werror -Wno-error=cpp -Wno-error=deprecated-declarations -Wno-error=strict-overflow -Wno-error=implicit-fallthrough -Wno-error=deprecated-copy -Wno-error=redundant-move -Wno-error=init-list-lifetime -Wno-error=format-overflow -Wsuggest-override -std=c++17 -c winid-nonnull.cpp The result is /home/vivoutil/kuutti/kuuttikutonen/qt5/qtbase/src/plugins/platforms/xcb/qxcbwindow.cpp: In member function ‘void QXcbWindow::show()’: /home/vivoutil/kuutti/kuuttikutonen/qt5/qtbase/src/plugins/platforms/xcb/qxcbwindow.cpp:685:91: error: ‘this’ pointer null [-Werror=nonnull] 685 | transientXcbParent = static_cast(tp->handle())->winId(); | ^ In file included from /home/vivoutil/kuutti/kuuttikutonen/qt5/qtbase/src/plugins/platforms/xcb/qxcbwindow.cpp:40: /home/vivoutil/kuutti/kuuttikutonen/qt5/qtbase/src/plugins/platforms/xcb/qxcbwindow.h:87:9: note: in a call to non-static member function ‘virtual WId QXcbWindow::winId() const’ 87 | WId winId() const override; | ^ Removing the static_cast removes the warning.
[Bug c++/97284] internal compiler error: 'global_options' are modified in local context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97284 --- Comment #10 from Ville Voutilainen --- Right - that's the Qt bug I'm hoping to fix, but I don't get far because of the ICE. :) The libstdc++ headers have been reorganized, so Qt's expectations that numeric_limits is available without including are no longer valid with GCC 11.
[Bug c++/97284] internal compiler error: 'global_options' are modified in local context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97284 --- Comment #8 from Ville Voutilainen --- Also, you can just try the actual build, if you follow https://wiki.qt.io/Building_Qt_6_from_Git
[Bug c++/97284] internal compiler error: 'global_options' are modified in local context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97284 --- Comment #7 from Ville Voutilainen --- (In reply to Martin Liška from comment #5) > Still can't reproduce it. > Please send me also output of --verbose. Yeah, I fed that output to g++, and then it compiles just fine. But when it's in the actual build with all the -MD -MT -MF flags, it doesn't. Those are, btw, in case it's of any help, -MD -MT qtbase/qmake/CMakeFiles/qmake.dir/__/src/corelib/global/qendian.cpp.o -MF qtbase/qmake/CMakeFiles/qmake.dir/__/src/corelib/global/qendian.cpp.o.d -o qtbase/qmake/CMakeFiles/qmake.dir/__/src/corelib/global/qendian.cpp.o
[Bug c++/97284] internal compiler error: 'global_options' are modified in local context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97284 --- Comment #6 from Ville Voutilainen --- Created attachment 49946 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49946=edit Output of --verbose
[Bug c++/97284] internal compiler error: 'global_options' are modified in local context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97284 --- Comment #4 from Ville Voutilainen --- Created attachment 49943 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49943=edit Output of gcc -E
[Bug c++/97284] internal compiler error: 'global_options' are modified in local context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97284 --- Comment #3 from Ville Voutilainen --- ..or maybe I'm just too dumb to invoke g++ -E properly, and the rest of the options confuse the compiler.
[Bug c++/97284] internal compiler error: 'global_options' are modified in local context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97284 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #2 from Ville Voutilainen --- (In reply to Martin Liška from comment #1) > Please provide a pre-processed soure file (-E option). The output of gcc -E for this build is empty, so sure looks like the crash is in the preprocessor.
[Bug c++/98054] [11 Regression] ICE: in pp_cxx_trait_expression, at cp/cxx-pretty-print.c:2671 since r11-4386-g9e2256dcd481ffe3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98054 Ville Voutilainen changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Ville Voutilainen --- Fixed.
[Bug c++/98054] [11 Regression] ICE: in pp_cxx_trait_expression, at cp/cxx-pretty-print.c:2671 since r11-4386-g9e2256dcd481ffe3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98054 --- Comment #4 from Ville Voutilainen --- Patch at https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560591.html
[Bug c++/98054] [11 Regression] ICE: in pp_cxx_trait_expression, at cp/cxx-pretty-print.c:2671 since r11-4386-g9e2256dcd481ffe3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98054 Ville Voutilainen changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at gmail dot com Status|NEW |ASSIGNED --- Comment #3 from Ville Voutilainen --- Whoops, I need to add the handling of the new intrinsics into pp_cxx_trait_expression. This should be quite straightforward, stay tuned...
[Bug libstdc++/96269] optional comparison with nullopt fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96269
--- Comment #9 from Ville Voutilainen ---
Ha, well spotted. In general, in a spaceship world, you do want to provide
comparisons symmetrically and const-correctly, and that also works in the
pre-spaceship world, thus:
#include
struct X {
template
bool operator==(const T&) const {
return false;
}
template friend bool operator==(const T&, const X&) {return
false;}
};
bool foo() {
std::optional x;
#ifndef FLIP
return x == std::nullopt;
#else
return std::nullopt == x;
#endif
}
[Bug libstdc++/96269] optional comparison with nullopt fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96269 --- Comment #5 from Ville Voutilainen --- Oh, and if you define a spaceship operator for your type, then things work again, with or without FLIP.
[Bug libstdc++/96269] optional comparison with nullopt fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96269 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #4 from Ville Voutilainen --- Right; even gcc trunk is happy with that code in C++17 mode with both values of FLIP, it's the C++20 spaceship rules that cause trouble here.
[Bug c++/97663] [c++17] Function with return type 'unsigned' in nested namespace misinterpreted as deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97663 Ville Voutilainen changed: What|Removed |Added CC||jason at redhat dot com Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-11-01
[Bug libstdc++/97449] [11 Regression] libstdc++ cannot be compiled with clang after 3427e31331677ca826c5588c87924214f7e5c54b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97449 Ville Voutilainen changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Ville Voutilainen --- Fixed.
[Bug libstdc++/97449] [11 Regression] libstdc++ cannot be compiled with clang after 3427e31331677ca826c5588c87924214f7e5c54b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97449 --- Comment #2 from Ville Voutilainen --- Patch available: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556323.html
[Bug libstdc++/97449] [11 Regression] libstdc++ cannot be compiled with clang after 3427e31331677ca826c5588c87924214f7e5c54b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97449 Ville Voutilainen changed: What|Removed |Added Status|NEW |ASSIGNED CC||ville.voutilainen at gmail dot com Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at gmail dot com --- Comment #1 from Ville Voutilainen --- Mine. I have a patch for it already, doing testing and submission chores...
[Bug libstdc++/95904] Improve the diagnostic for conflicting return types in std::visit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95904 Ville Voutilainen changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Ville Voutilainen --- There are aspirations to change the variant tables to a flat one, but that's a separate enhancement. This particular problem is fixed.
[Bug libstdc++/94890] std::tuple({0}) fails to compile with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94890 Ville Voutilainen changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #9 from Ville Voutilainen --- LEWG says NO: https://cplusplus.github.io/LWG/issue3440
