[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&action=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&action=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&action=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&action=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
[Bug libstdc++/91807] [9/10/11 Regression] std::variant with multiple identical types assignment fail to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91807 Ville Voutilainen changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Ville Voutilainen --- Fixed.
[Bug libstdc++/91807] [9/10/11 Regression] std::variant with multiple identical types assignment fail to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91807 Ville Voutilainen changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|ville.voutilainen at gmail dot com CC||ville.voutilainen at gmail dot com --- Comment #3 from Ville Voutilainen --- Mine.
[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 Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at gmail dot com Status|NEW |ASSIGNED CC||ville.voutilainen at gmail dot com
[Bug libstdc++/95915] [10/11 Regression] std::variant doesn't like types with a defaulted virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95915 Ville Voutilainen changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Ville Voutilainen --- Fixed.
[Bug libstdc++/95915] [10/11 Regression] std::variant doesn't like types with a defaulted virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95915 --- Comment #1 from Ville Voutilainen --- Patch at https://gcc.gnu.org/pipermail/gcc-patches/2020-June/549030.html
[Bug libstdc++/95915] std::variant doesn't like types with a defaulted virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95915 Ville Voutilainen changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-06-26 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at gmail dot com
[Bug libstdc++/95915] New: std::variant doesn't like types with a defaulted virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95915 Bug ID: 95915 Summary: std::variant doesn't like types with a defaulted virtual destructor Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ville.voutilainen at gmail dot com Target Milestone: --- >From Patrice Roy: The following code compiled in C++17 but seems broken in C++20, at least according the Clang and gcc: #include struct X { virtual ~X() = default; }; int main() { std::variant v; } This is because variant's storage uses an _Uninitialized type that hacks around a compiler bug, where the type X above wasn't literal. Now that it is, the hack breaks. Since variant's other base-layers handle triviality of special member functions properly, this hack can now be removed.
[Bug c++/95111] coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111 --- Comment #17 from Ville Voutilainen --- (In reply to Ville Voutilainen from comment #16) > (In reply to Iain Sandoe from comment #14) > > (In reply to Ville Voutilainen from comment #12) > > The idea of bringing the lambda's captures into the coro frame was what I > > originally implemented. Richard pointed out that this is wrong when the > > lambda is mutable (see > > gcc/testsuite/g++.dg/coroutines/torture/lambda-10-mutable.C) > > > > so if one has > > > > auto X = [...] () -> some_coro {}; > > > > X must exist for the duration of the lambda coro [it was pointed out by > > Lewis that really this is only the same as saying that if you have a class > > with a member function lambda, the instance of that class has to persist for > > the duration of the coro]. > > Ah. So the work-around for this problem is to copy the capture to a local > variable, and co_return that; then the local variable is in the coro-state. > Right? That is, instead of writing [x] {co_return x;} write [x] {auto xx = x; co_return xx;}
[Bug c++/95111] coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #16 from Ville Voutilainen --- (In reply to Iain Sandoe from comment #14) > (In reply to Ville Voutilainen from comment #12) > The idea of bringing the lambda's captures into the coro frame was what I > originally implemented. Richard pointed out that this is wrong when the > lambda is mutable (see > gcc/testsuite/g++.dg/coroutines/torture/lambda-10-mutable.C) > > so if one has > > auto X = [...] () -> some_coro {}; > > X must exist for the duration of the lambda coro [it was pointed out by > Lewis that really this is only the same as saying that if you have a class > with a member function lambda, the instance of that class has to persist for > the duration of the coro]. Ah. So the work-around for this problem is to copy the capture to a local variable, and co_return that; then the local variable is in the coro-state. Right?
[Bug c++/95111] coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111 --- Comment #12 from Ville Voutilainen --- It sure seems to me that a coroutine lambda's captures should be copied to the coroutine state. I don't think the standard says that anywhere.
[Bug c++/94890] std::tuple({0}) fails to compile with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94890 --- Comment #7 from Ville Voutilainen --- ..and as expected, std::optional is broken the same way.
[Bug c++/94890] std::tuple({0}) fails to compile with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94890 --- Comment #8 from Ville Voutilainen --- (In reply to Marek Polacek from comment #6) > Thanks Ville. What I should have said... > > (In reply to Marek Polacek from comment #4) > > My current theory is that it is not a bug. > > ...in the compiler proper. It'd be nice if the original test compiled. No worries. This needs two library fixes and an LWG issue, I'll take care of it.
[Bug c++/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 Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at gmail dot com CC||ville.voutilainen at gmail dot com Last reconfirmed||2020-05-01 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #5 from Ville Voutilainen --- What happens with std::tuple x({0}) is that the _UElements&&... constructor is not a direct candidate, so we fall back to trying a copy constructor. That's a match, and then it tries to convert the argument. Since c is constructible from int, but not convertible from int, the match is the explicit constructor, and calling that fails because initializing the argument is copy-init. The fix that we can apply in tuple is to make __is_implicitly_constructible look at either is_convertible or is_aggregate, and then negate properly in __is_explicitly_constructible. In other words, mine. :)
[Bug c++/94197] __is_constructible gives an access error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94197 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at gmail dot com Status|NEW |ASSIGNED --- Comment #2 from Ville Voutilainen --- Mine.
[Bug c++/94149] __is_constructible doesn't know about C++20 parenthesized init for arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94149 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #3 from Ville Voutilainen --- (In reply to Marek Polacek from comment #2) > C++20 paren-init -> mine. This goes from constructible_expr into perform_direct_initialization_if_possible, which then goes into implicit_conversion, which fails to build a conversion.
[Bug c++/93629] New: A completely non-sensical requires-clause is accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93629 Bug ID: 93629 Summary: A completely non-sensical requires-clause is accepted Product: gcc Version: 10.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: --- Test: template void f() requires b && true && && && && && && && &&&&&&&&&&&&&&&&&&&&&&&&&&&& &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& false {} Compiles fine. Trying to call the function is diagnosed, though: error: use of function 'void f() requires Perhaps we should be a tad stricter at parse time?
[Bug c++/92947] Parenthesized aggregate initialization doesn't work with the library types it's supposed to work with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92947 --- Comment #3 from Ville Voutilainen --- Any chance of progress on this before 10 ships?
[Bug libstdc++/92570] [8/9/10 Regression] clang fails to instantiate std::optional if A is not const copy constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92570 Ville Voutilainen changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #3 from Ville Voutilainen --- This is http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0641r2.html which clang implements only in c++2a mode, because those core issues were never explicitly marked DR. We could almost fix this on the library side by removing the =default from _Optional_payload_base, but _Optional_payload would still run into this problem. This is not worth library heroics.
[Bug libstdc++/92570] [8/9/10 Regression] clang fails to instantiate std::optional if A is not const copy constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92570 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
[Bug c++/92947] Parenthesized aggregate initialization doesn't work with the library types it's supposed to work with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92947 --- Comment #1 from Ville Voutilainen --- Based on some debugging work, build_functional_cast_1 looks like a plausible place where we might need to add understanding of parenthesized aggregates. The previous bug report has an incomplete (because it's not c++2a-conditionalized) patch for constructible_expr that looks like it takes care of __is_constructible. I entertained just making build_special_member_call do all this. That's not quite straightforward because it wants a vector, and the build_aggr_init and its friends want a tree.
[Bug c++/92947] New: Parenthesized aggregate initialization doesn't work with the library types it's supposed to work with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92947 Bug ID: 92947 Summary: Parenthesized aggregate initialization doesn't work with the library types it's supposed to work with Product: gcc Version: 10.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: --- struct aggressive_aggregate { int a; int b; }; int main() { static_assert(__is_constructible(aggressive_aggregate, int, int)); // fails decltype(aggressive_aggregate(1,2)) foo; // ill-formed bool b = noexcept(aggressive_aggregate(1,2)); // ill-formed } All of those things should work. The __is_constructible should be true, and the decltype and noexcept should be well-formed.
[Bug c++/92878] Parenthesized aggregate initialization doesn't work in a new-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92878 --- Comment #9 from Ville Voutilainen --- This seems to do the right thing for __is_constructible. I haven't looked at decltype or noexcept yet. diff --git a/gcc/cp/method.c b/gcc/cp/method.c index 97c27c51ea3..4b8daf8634f 100644 --- a/gcc/cp/method.c +++ b/gcc/cp/method.c @@ -1742,8 +1742,11 @@ constructible_expr (tree to, tree from) tree ob = build_stub_object (to); for (; from; from = TREE_CHAIN (from)) vec_safe_push (args, build_stub_object (TREE_VALUE (from))); - expr = build_special_member_call (ob, complete_ctor_identifier, &args, - ctype, LOOKUP_NORMAL, tf_none); + if (CP_AGGREGATE_TYPE_P (ctype)) + expr = build_aggr_init(ob, from, LOOKUP_NORMAL, tf_none); + else + expr = build_special_member_call (ob, complete_ctor_identifier, &args, + ctype, LOOKUP_NORMAL, tf_none); if (expr == error_mark_node) return error_mark_node; /* The current state of the standard vis-a-vis LWG 2116 is that
[Bug c++/92878] Parenthesized aggregate initialization doesn't work in a new-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92878 --- Comment #8 from Ville Voutilainen --- One more thing besides the __is_constructible; this aggregate doesn't seem to work in an unevaluated context. Both decltype(aggressive_aggregate(1,2)) and noexcept(aggressive_aggregate(1,2)) are rejected.
[Bug c++/92878] Parenthesized aggregate initialization doesn't work in a new-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92878 --- Comment #7 from Ville Voutilainen --- __is_constructible is incorrectly false for such an aggregate: struct aggressive_aggregate { int a; int b; }; int main() { static_assert(__is_constructible(aggressive_aggregate, int, int)); } Do you want a new bug report, or should this be handled as a follow-up on this one? By the way, this is exactly why I asked to add a libstdc++ test for this, for make_shared, make_unique and allocator::construct (and construct_at). When I started writing that test, I semi-immediately ran into make_shared still not working, because the underlying utilities it uses check constructibility, and get a wrong answer.
[Bug c++/92878] Parenthesized aggregate initialization doesn't work in a new-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92878 --- Comment #1 from Ville Voutilainen --- Wishlist item: please add a C++2a mode libstdc++ test that verifies that make_unique and make_shared work with aggregates. Bonus points for std::allocator_traits>::construct.
[Bug c++/92878] New: Parenthesized aggregate initialization doesn't work in a new-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92878 Bug ID: 92878 Summary: Parenthesized aggregate initialization doesn't work in a new-expression Product: gcc Version: 10.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: --- //#include struct aggressive_aggregate { int a; int b; }; int main() { auto x = aggressive_aggregate(1,2); // OK auto y = new aggressive_aggregate(1,2); // rejected, should be OK? //auto z = std::make_unique(1,2); // rejected, should be OK? }
[Bug c++/88136] -Wdeprecated-copy is draconian and shouldn't be in -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136 --- Comment #11 from Ville Voutilainen --- (In reply to Jonathan Wakely from comment #10) > I don't think it has been written yet. Right; I decided against it, since the cats are out of the bag and shipping implementations voted with their feet, so Rule of Five is now the law of the land, as far as I care.
[Bug c++/85254] boost::is_final does not work for template types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85254 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at gmail dot com --- Comment #5 from Ville Voutilainen --- Mine. Patch available: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg02183.html
[Bug libstdc++/88888] Cannot construct filesystem::path from variable length array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #3 from Ville Voutilainen --- Work-around #3 looks splendidly sufficient to me, let's close this without further extension-work into this wonderful overload set.
[Bug c++/88136] -Wdeprecated-copy is draconian and shouldn't be in -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136 --- Comment #7 from Ville Voutilainen --- Innocent users are going to hit it: https://bugreports.qt.io/browse/QTBUG-75210
[Bug c++/88136] -Wdeprecated-copy is draconian and shouldn't be in -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136 --- Comment #6 from Ville Voutilainen --- Any chance of moving this warning out of -Wextra and re-considering adding it there for GCC 10?
[Bug libstdc++/89825] Jump table for variant visitation could be shortened for never empty variants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89825 Ville Voutilainen changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Ville Voutilainen --- Fixed.
[Bug libstdc++/89816] [9 Regression] std::variant move construction regressed since GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816 Ville Voutilainen changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Ville Voutilainen --- Fixed; there are other open PRs, more patches will be incoming, no need to keep this one open. Closing.
[Bug libstdc++/89825] Jump table for variant visitation could be shortened for never empty variants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89825 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
[Bug libstdc++/89816] [9 Regression] std::variant move construction regressed since GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816 --- Comment #10 from Ville Voutilainen --- Assignment can be made to avoid double-visitation, instead of using _M_destructive_move/copy. Other than that, getting it to generate fewer table items needs the idea from the other bug report.
[Bug libstdc++/89819] [9 Regression] std::variant operators regressed since GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89819 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #1 from Ville Voutilainen --- The problem with this idea is that it brings back a run-time branch that the visitation got rid of. What we probably need is a different generated table for these functions, a table that uses the same index for both variants or invokes a cookie-function.
[Bug libstdc++/89816] [9 Regression] std::variant move construction regressed since GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816 Ville Voutilainen changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-03-25 Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at gmail dot com Ever confirmed|0 |1
[Bug libstdc++/89816] [9 Regression] std::variant move construction regressed since GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816 --- Comment #8 from Ville Voutilainen --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01200.html
[Bug libstdc++/89816] [9 Regression] std::variant move construction regressed since GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816 --- Comment #7 from Ville Voutilainen --- Looks good - I'll do a patch shortly.
[Bug libstdc++/89816] [9 Regression] std::variant move construction regressed since GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816 --- Comment #5 from Ville Voutilainen --- Correct.
[Bug libstdc++/89816] [9 Regression] std::variant move construction regressed since GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816 --- Comment #3 from Ville Voutilainen --- The problem here is that the older approach knows that it's always from type X1 to type X1, never from type X4 to X2. The visitation approach generates combinations that we never use.
[Bug libstdc++/89816] [9 Regression] std::variant move construction regressed since GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #2 from Ville Voutilainen --- Yes. That codegen looks.. ..bad.
[Bug libstdc++/52114] SFINAE out the rvalue iostream operators to give better error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52114 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #13 from Ville Voutilainen --- This bug has been fixed, we do nowadays SFINAE in these return types.
[Bug c++/88136] -Wdeprecated-copy is draconian and shouldn't be in -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136 --- Comment #2 from Ville Voutilainen --- This is not just a Qt problem. I will write a proposal to undeprecate this deprecation for C++20 before the next committee meeting.
[Bug c++/88136] New: -Wdeprecated-copy is draconian and shouldn't be in -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136 Bug ID: 88136 Summary: -Wdeprecated-copy is draconian and shouldn't be in -Wall Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ville.voutilainen at gmail dot com Target Milestone: --- Consider code like this: struct X { protected: ~X() {} }; struct Y : X { Y() = default; Y(const Y& other) : X(other) {} }; int main() { Y y; Y y2 = y; } gcc 9 warns about it, because X has a user-provided destructor. However, in this particular case, and in cases where the implicitly-defaulted copy/move are fine but the destructor does some extra work and is thus user-provided, the compiler will warn. The warning completely shatters the ability to build Qt.
[Bug libstdc++/87855] std::optional only copy-constructible if T is trivially copy-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855 --- Comment #16 from Ville Voutilainen --- (In reply to Florian Weimer from comment #15) > (In reply to Ville Voutilainen from comment #13) > > Well, Jonathan found this http://lists.isocpp.org/core/2018/06/4643.php > > Would you please summarize the gist of the discussion if permitted under ISO > rules? I don't think the list archives are public. Richard shows that allowing elision for delegating constructors can lead to subobjects being overwritten by the initialization of other subobjects.
[Bug libstdc++/87855] std::optional only copy-constructible if T is trivially copy-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855 --- Comment #14 from Ville Voutilainen --- (In reply to fiesh from comment #12) > X(double) : X(X(42)) {} // clang doesn't like this > > is also enough to show the difference, no need for an operator. Yeah. The list-archive link that you probably can't open leads to Richard's explanation why copy elision should not happen with delegating constructors. That's the bug, not the lack of deletedness of the union's copy constructor.
[Bug libstdc++/87855] std::optional only copy-constructible if T is trivially copy-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855 --- Comment #13 from Ville Voutilainen --- Well, Jonathan found this http://lists.isocpp.org/core/2018/06/4643.php
[Bug libstdc++/87855] std::optional only copy-constructible if T is trivially copy-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855 Ville Voutilainen changed: What|Removed |Added CC||jason at redhat dot com --- Comment #11 from Ville Voutilainen --- Jason, could you please settle this hash with Richard? The snippets I wrote look naively like they should elide, but the compilers seem to disagree on that.
[Bug libstdc++/87855] std::optional only copy-constructible if T is trivially copy-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855 --- Comment #10 from Ville Voutilainen --- Here's another one where gcc and clang disagree: https://wandbox.org/permlink/UsViiOoDRgdismAy The disagreement is over X(bool b) : X((b, X(42))) {} where b is unused, gcc elides the temporary and clang again doesn't.
[Bug libstdc++/87855] std::optional only copy-constructible if T is trivially copy-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855 --- Comment #9 from Ville Voutilainen --- See https://wandbox.org/permlink/snAuT59ocie38DU5 Here's a tl;dr: struct NonTrivial {NonTrivial(const NonTrivial&) {}}; struct X { X() : x(42) {} X(bool b) : X(b ? X(42): X(666)) {} // clang doesn't like this X(int foo) : x(foo) {} ~X() {} union {int x; NonTrivial y;}; }; X is not copyconstructible in either gcc or clang, but gcc apparently elides the copy in the call to the delegated constructor on the commented line, whereas clang does not.
[Bug libstdc++/87855] std::optional only copy-constructible if T is trivially copy-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855 --- Comment #8 from Ville Voutilainen --- (In reply to Jonathan Wakely from comment #7) > (In reply to fiesh from comment #0) > > (If this is true, is it > > a separate gcc bug that it does not delete the union's constructor?) > > Yes, I think so. Could you please file a Component=c++ bug too? When doing so, please check whether it's actually about not deleting the union's copy constructor, as opposed to possibly too eager copy elision.
[Bug libstdc++/87855] std::optional only copy-constructible if T is trivially copy-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855 --- Comment #5 from Ville Voutilainen --- New patch is at https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01368.html
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 67026, which changed state. Bug 67026 Summary: GCC incorrectly rejects well-formed constexpr function definition https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67026 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/67026] GCC incorrectly rejects well-formed constexpr function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67026 Ville Voutilainen changed: What|Removed |Added Status|NEW |RESOLVED CC||ville.voutilainen at gmail dot com Resolution|--- |DUPLICATE --- Comment #6 from Ville Voutilainen --- This seems to have been fixed by the fix to 86678. *** This bug has been marked as a duplicate of bug 86678 ***
[Bug c++/86678] constexpr evaluation incorrectly diagnoses unevaluated call to non-constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86678 Ville Voutilainen changed: What|Removed |Added CC||anders.granlund.0 at gmail dot com --- Comment #7 from Ville Voutilainen --- *** Bug 67026 has been marked as a duplicate of this bug. ***
[Bug libstdc++/87855] std::optional only copy-constructible if T is trivially copy-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855 --- Comment #3 from Ville Voutilainen --- The fix is not quite right. I'll do a more intrusive one. Stay tuned.
[Bug libstdc++/87855] std::optional only copy-constructible if T is trivially copy-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855 Ville Voutilainen changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-01 CC||ville.voutilainen at gmail dot com Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at gmail dot com Ever confirmed|0 |1 --- Comment #1 from Ville Voutilainen --- Created attachment 44943 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44943&action=edit A proposed patch I have attached a candidate fix. Can you check whether it fixes the problem?
[Bug c++/87726] New: -fdebug-prefix-map doesn't work with lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87726 Bug ID: 87726 Summary: -fdebug-prefix-map doesn't work with lto Product: gcc Version: lto 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 44887 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44887&action=edit Test application With the attached source, uncommenting the lto flags at the top of the Makefile lead to a linker error when making the source. The source needs the development headers and libs for dwarf and dw. This problem breaks the attempts to build boot2qt with lto enabled with yocto.