[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
[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, , - 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, , + 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=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=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.
[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87665 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #8 from Ville Voutilainen --- It seems that either -fno-strict-aliasing or -march=native makes it work. That bears a *striking* similarity to the symptoms seen in https://bugreports.qt.io/browse/QTBUG-69388 !
[Bug libstdc++/87619] sizeof(std::variant) can be reduced if its variant_size is UCHAR_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87619 Ville Voutilainen changed: What|Removed |Added Status|NEW |RESOLVED CC||ville.voutilainen at gmail dot com Resolution|--- |FIXED --- Comment #2 from Ville Voutilainen --- Fixed.
[Bug c++/87051] is_trivially_move_constructible wrongly gives `false` for class with user-provided non-const copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87051 --- Comment #2 from Ville Voutilainen --- Patch available: https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00670.html
