[Bug c++/116882] gcc-14 ICE with coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116882 Jean-Michaël Celerier changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #3 from Jean-Michaël Celerier --- Fixed in a more recent GCC indeed. Ubuntu was stuck on an older version.
[Bug c++/116882] New: gcc-14 ICE with coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116882 Bug ID: 116882 Summary: gcc-14 ICE with coroutines Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- Will try to reproduce - here is in the meantime a CI job: https://github.com/celtera/avendish/actions/runs/11086764898/job/30804702919#step:7:1168 internal compiler error: in coro_promise_type_found_p, at cp/coroutines.cc:460 342 | co_yield r; | ^~~~ 0x72cb50 coro_promise_type_found_p ../../src/gcc/cp/coroutines.cc:460 0xf47f16 finish_co_yield_expr(unsigned int, tree_node*) ../../src/gcc/cp/coroutines.cc:1238 0x10ed246 tsubst_expr(tree_node*, tree_node*, int, tree_node*) ../../src/gcc/cp/pt.cc:21674 0x10fba57 tsubst_stmt ../../src/gcc/cp/pt.cc:19485 0x10fdb27 tsubst_stmt ../../src/gcc/cp/pt.cc:18445 0x10fc7de tsubst_stmt ../../src/gcc/cp/pt.cc:18413 0x10fc7de tsubst_stmt ../../src/gcc/cp/pt.cc:18427 0x10fd34a tsubst_stmt ../../src/gcc/cp/pt.cc:18697 0x10fc783 tsubst_stmt ../../src/gcc/cp/pt.cc:18801 0x10fa7a2 tsubst_stmt ../../src/gcc/cp/pt.cc:18413 0x10fa7a2 instantiate_body ../../src/gcc/cp/pt.cc:27091 0x10fb645 instantiate_decl(tree_node*, bool, bool) ../../src/gcc/cp/pt.cc:27376 0x11207fb instantiate_pending_templates(int) ../../src/gcc/cp/pt.cc:27452 0xfbedb7 c_parse_final_cleanups() ../../src/gcc/cp/decl2.cc:5156 0x1211668 c_common_parse_file() ../../src/gcc/c-family/c-opts.cc:1329
[Bug libstdc++/115839] New: Some common patterns in libstdc++-14 break many libraries with clang in C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115839 Bug ID: 115839 Summary: Some common patterns in libstdc++-14 break many libraries with clang in C++23 Product: gcc Version: 14.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- Issue also posted to the LLVM bugtracker: https://github.com/llvm/llvm-project/issues/97842 Some repros ; easily reproducible on an archlinux container. Ex. 1: https://github.com/boostorg/container/issues/282 Repro: ```bash $ docker run -v $PWD:/src -it archlinux:latest $ pacman -Sy $ pacman -S clang $ echo '#include int main() { boost::container::flat_map f; f[0]; }' > foo.cpp $ clang++ foo.cpp -std=c++23 -I /src/boost_1_85_0 ``` Ex. 2: https://github.com/martinus/unordered_dense/issues/119 Ex. 3: ```c++ #include void x(const char* s, int n) { nlohmann::json::parse(s, s + n); } ``` cause errors such as : ``` /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/tuple:956:36: error: no matching function for call to 'get' 956 | return __convertible(std::declval<_UTuple>()))...>(); | ^ /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/tuple:955:11: note: in instantiation of function template specialization 'std::tuple &>::__convertible_from_tuple_like()::(anonymous class)::operator()<0UL>' requested here 955 | return [](index_sequence<_Is...>) { | ^ /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/tuple:1136:22: note: in instantiation of function template specialization 'std::tuple &>::__convertible_from_tuple_like &>' requested here 1136 | constexpr explicit(!__convertible_from_tuple_like<_UTuple>()) | ^ /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_map.h:514:38: note: while substituting deduced template arguments into function template 'tuple' [with _UTuple = const key_type &] 514 | std::tuple(__k), | ^ /usr/include/nlohmann/detail/input/json_sax.hpp:442:66: note: in instantiation of member function 'std::map, nlohmann::basic_json<>, std::less>::operator[]' requested here 442 | object_element = &(ref_stack.back()->m_value.object->operator[](val) = discarded); | ^ /usr/include/nlohmann/detail/input/parser.hpp:219:56: note: in instantiation of member function 'nlohmann::detail::json_sax_dom_callback_parser>::key' requested here 219 | if (JSON_HEDLEY_UNLIKELY(!sax->key(m_lexer.get_string( |^ /usr/include/nlohmann/detail/input/parser.hpp:98:13: note: in instantiation of function template specialization 'nlohmann::detail::parser, nlohmann::detail::iterator_input_adapter>::sax_parse_internal>>' requested here 98 | sax_parse_internal(&sdp); | ^ /usr/include/nlohmann/json.hpp:4029:113: note: in instantiation of member function 'nlohmann::detail::parser, nlohmann::detail::iterator_input_adapter>::parse' requested here 4029 | parser(detail::input_adapter(std::move(first), std::move(last)), cb, allow_exceptions, ignore_comments).parse(true, result); | ^ /usr/include/nlohmann/json.hpp:5138:28: note: in instantiation of function template specialization 'nlohmann::basic_json<>::parse' requested here 5138 | return nlohmann::json::parse(s, s + n); |^ /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:122:5: note: candidate template ignored: could not match 'tuple' against 'basic_string' 122 | get(tuple<_Elements...>& __t) noexcept; | ^ /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:126:5: note: candidate template ignored: could not match 'tuple' against 'basic_string' 126 | get(const tuple<_Elements...>& __t) noexcept; | ^ /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:130:5: note: candidate template ignored: coul
[Bug libstdc++/115838] New: Some common patterns in libstdc++-14 break many libraries with clang in C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115838 Bug ID: 115838 Summary: Some common patterns in libstdc++-14 break many libraries with clang in C++23 Product: gcc Version: 14.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- Issue also posted to the LLVM bugtracker: https://github.com/llvm/llvm-project/issues/97842 Some repros ; easily reproducible on an archlinux container. Ex. 1: https://github.com/boostorg/container/issues/282 Repro: ```bash $ docker run -v $PWD:/src -it archlinux:latest $ pacman -Sy $ pacman -S clang $ echo '#include int main() { boost::container::flat_map f; f[0]; }' > foo.cpp $ clang++ foo.cpp -std=c++23 -I /src/boost_1_85_0 ``` Ex. 2: https://github.com/martinus/unordered_dense/issues/119 Ex. 3: ```c++ #include void x(const char* s, int n) { nlohmann::json::parse(s, s + n); } ``` cause errors such as : ``` /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/tuple:956:36: error: no matching function for call to 'get' 956 | return __convertible(std::declval<_UTuple>()))...>(); | ^ /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/tuple:955:11: note: in instantiation of function template specialization 'std::tuple &>::__convertible_from_tuple_like()::(anonymous class)::operator()<0UL>' requested here 955 | return [](index_sequence<_Is...>) { | ^ /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/tuple:1136:22: note: in instantiation of function template specialization 'std::tuple &>::__convertible_from_tuple_like &>' requested here 1136 | constexpr explicit(!__convertible_from_tuple_like<_UTuple>()) | ^ /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_map.h:514:38: note: while substituting deduced template arguments into function template 'tuple' [with _UTuple = const key_type &] 514 | std::tuple(__k), | ^ /usr/include/nlohmann/detail/input/json_sax.hpp:442:66: note: in instantiation of member function 'std::map, nlohmann::basic_json<>, std::less>::operator[]' requested here 442 | object_element = &(ref_stack.back()->m_value.object->operator[](val) = discarded); | ^ /usr/include/nlohmann/detail/input/parser.hpp:219:56: note: in instantiation of member function 'nlohmann::detail::json_sax_dom_callback_parser>::key' requested here 219 | if (JSON_HEDLEY_UNLIKELY(!sax->key(m_lexer.get_string( |^ /usr/include/nlohmann/detail/input/parser.hpp:98:13: note: in instantiation of function template specialization 'nlohmann::detail::parser, nlohmann::detail::iterator_input_adapter>::sax_parse_internal>>' requested here 98 | sax_parse_internal(&sdp); | ^ /usr/include/nlohmann/json.hpp:4029:113: note: in instantiation of member function 'nlohmann::detail::parser, nlohmann::detail::iterator_input_adapter>::parse' requested here 4029 | parser(detail::input_adapter(std::move(first), std::move(last)), cb, allow_exceptions, ignore_comments).parse(true, result); | ^ /usr/include/nlohmann/json.hpp:5138:28: note: in instantiation of function template specialization 'nlohmann::basic_json<>::parse' requested here 5138 | return nlohmann::json::parse(s, s + n); |^ /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:122:5: note: candidate template ignored: could not match 'tuple' against 'basic_string' 122 | get(tuple<_Elements...>& __t) noexcept; | ^ /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:126:5: note: candidate template ignored: could not match 'tuple' against 'basic_string' 126 | get(const tuple<_Elements...>& __t) noexcept; | ^ /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:130:5: note: candidate template ignored: coul
[Bug c++/88602] Consider adding ext_vector_type for better clang compatibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88602 Jean-Michaël Celerier changed: What|Removed |Added CC||jeanmichael.celerier@gmail. ||com --- Comment #4 from Jean-Michaël Celerier --- Another vote for this. It's used in the KFR DSP library which for this reason gets restricted to clang in some configurations... Compare https://github.com/kfrlib/kfr/blob/main/include/kfr/simd/impl/backend_clang.hpp and https://github.com/kfrlib/kfr/blob/main/include/kfr/simd/impl/backend_generic.hpp
[Bug c++/111748] New: GCC does not understand partial ordering between non-constrained and constrained templates for specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111748 Bug ID: 111748 Summary: GCC does not understand partial ordering between non-constrained and constrained templates for specialization Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- Consider: #include template void foo() { } template void foo() { } template<> void foo() { } int main() { foo(); } According to the answers I got in https://stackoverflow.com/questions/77261120/ GCC should be able to compile this code, yet it fails due to a supposed ambiguity between template void foo() { } and template void foo() { } as the base of foo
[Bug sanitizer/110936] New: if constexpr: member function pointers cannot be checked with ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110936 Bug ID: 110936 Summary: if constexpr: member function pointers cannot be checked with ubsan Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Repro: struct foo { void bar() { } }; void process(auto f) { if constexpr(&decltype(f)::bar); } int main() { process(foo{}); } Works fine in normal compilation mode as expected, however with -fsanitize=undefined it does not work: https://gcc.godbolt.org/z/9qvz89na8 :6:3: error: '(foo::bar != 0)' is not a constant expression if constexpr(&decltype(f)::bar); I tested as far back as g++ 7.1 and it did not work either back then, and prior versions did not have if constexpr. It would be less of a problem if there was any way to do #if defined(__SANITIZE_UNDEFINED__) or something similar but while asan has it, ubsan does not seem to have any macro to enable detection of it.
[Bug c++/109899] New: ICE in check_noexcept_r, at cp/except.cc:1065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109899 Bug ID: 109899 Summary: ICE in check_noexcept_r, at cp/except.cc:1065 Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- Created attachment 55106 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55106&action=edit Preprocessed source causing the bug Repro: #include #include #include struct T { struct { // Works fine for value == std::array or std::string directly std::array value; } X; }; int main() { boost::pfr::detail::fields_count(); } On godbolt: https://gcc.godbolt.org/z/xd48obMTv Preprocessed source attached. g++ 13.1.1 up-to-date in Arch Linux as of today, and it fails on any Boost version that has (from 1.75 to 1.82+).
[Bug c++/109651] ICE in lookup_template_class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109651 --- Comment #3 from Jean-Michaël Celerier --- Created attachment 54943 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54943&action=edit Preprocessed source
[Bug c++/109651] New: ICE in lookup_template_class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109651 Bug ID: 109651 Summary: ICE in lookup_template_class Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- g++ version: g++ (SUSE Linux) 13.0.1 20230421 (prerelease) [revision f980561c60b0446cc427595198d7f3f4f90e0924] as shipped by opensuse tumbleweed (reproducible in the official opensuse/tumbleweed:latest container) preprocessed source as given by -freport-bug attached. /usr/bin/g++-13 -DBOOST_ASIO_DISABLE_CONCEPTS=1 -DBOOST_MATH_DISABLE_FLOAT128=1 -DBOOST_NO_RTTI=1 -DLIBREMIDI_ALSA -DLIBREMIDI_JACK -DQT_CORE_LIB -DQT_DISABLE_DEPRECATED_BEFORE=0x0605ff -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_KEYWORDS -DQT_NO_LINKED_LIST -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_NO_USING_NAMESPACE -DQT_OPENGL_LIB -DQT_QMLINTEGRATION_LIB -DQT_QML_LIB -DQT_SERIALPORT_LIB -DQT_SHADERTOOLS_LIB -DQT_STATEMACHINE_LIB -DQT_USE_QSTRINGBUILDER -DQT_WEBSOCKETS_LIB -DQT_WIDGETS_LIB -DRAPIDJSON_HAS_STDSTRING=1 -DSCORE_ADDON_NETWORK_EXPORTS -DSCORE_LIB_BASE -DSCORE_LIB_DEVICE -DSCORE_LIB_INSPECTOR -DSCORE_LIB_LOCALTREE -DSCORE_LIB_PCH_EXPORTS -DSCORE_LIB_PROCESS -DSCORE_LIB_STATE -DSCORE_PLUGIN_AUDIO -DSCORE_PLUGIN_AUTOMATION -DSCORE_PLUGIN_AVND -DSCORE_PLUGIN_CURVE -DSCORE_PLUGIN_DATAFLOW -DSCORE_PLUGIN_DEVICEEXPLORER -DSCORE_PLUGIN_ENGINE -DSCORE_PLUGIN_GFX -DSCORE_PLUGIN_LIBRARY -DSCORE_PLUGIN_MEDIA -DSCORE_PLUGIN_SCENARIO -DSCORE_PLUGIN_TRANSPORT -DSERVUS_USE_AVAHI_CLIENT -DTINYSPLINE_DOUBLE_PRECISION -I/tmp/build/src/addons/iscore-addon-network -I/ossia/score/src/addons/iscore-addon-network -I/tmp/build -I/ossia/score/3rdparty -I/ossia/score/3rdparty/zipdownloader/src -I/ossia/score/3rdparty/QProgressIndicator -I/ossia/score/3rdparty/Qt-Color-Widgets -I/ossia/score/3rdparty/Qt-Color-Widgets/src -I/ossia/score/3rdparty/Qt-Color-Widgets/QtColorWidgets -I/ossia/score/3rdparty/libossia/3rdparty/verdigris/src -I/tmp/build/src/lib -I/ossia/score/src/lib -I/ossia/score/3rdparty/libossia/3rdparty/Flicks -I/ossia/score/3rdparty/libossia/src -I/tmp/build/3rdparty/libossia/src -I/ossia/score/3rdparty/libossia/3rdparty/Servus/servus/.. -I/ossia/score/3rdparty/QCodeEditor/include -I/tmp/build/src/plugins/score-plugin-scenario -I/ossia/score/src/plugins/score-plugin-scenario -I/usr/include/qt6/QtDBus/6.5.0 -I/usr/include/qt6/QtDBus/6.5.0/QtDBus -I/tmp/build/src/plugins/score-lib-process -I/ossia/score/src/plugins/score-lib-process -I/tmp/build/src/plugins/score-lib-state -I/ossia/score/src/plugins/score-lib-state -I/tmp/build/src/plugins/score-lib-inspector -I/ossia/score/src/plugins/score-lib-inspector -I/tmp/build/src/plugins/score-lib-device -I/ossia/score/src/plugins/score-lib-device -I/tmp/build/src/plugins/score-lib-localtree -I/ossia/score/src/plugins/score-lib-localtree -I/tmp/build/src/plugins/score-plugin-deviceexplorer -I/ossia/score/src/plugins/score-plugin-deviceexplorer -I/tmp/build/src/plugins/score-plugin-curve -I/ossia/score/src/plugins/score-plugin-curve -I/tmp/build/src/plugins/score-plugin-automation -I/ossia/score/src/plugins/score-plugin-automation -I/tmp/build/src/plugins/score-plugin-library -I/ossia/score/src/plugins/score-plugin-library -I/tmp/build/src/plugins/score-plugin-transport -I/ossia/score/src/plugins/score-plugin-transport -I/tmp/build/src/plugins/score-plugin-engine -I/ossia/score/src/plugins/score-plugin-engine -I/tmp/build/src/plugins/score-plugin-audio -I/ossia/score/src/plugins/score-plugin-audio -I/tmp/build/src/plugins/score-plugin-avnd -I/ossia/score/src/plugins/score-plugin-avnd -I/tmp/build/src/plugins/score-plugin-media -I/ossia/score/src/plugins/score-plugin-media -I/tmp/build/src/plugins/score-plugin-dataflow -I/ossia/score/src/plugins/score-plugin-dataflow -I/ossia/score/3rdparty/libossia/3rdparty -I/ossia/score/3rdparty/DSPFilters/DSPFilters/include -I/ossia/score/3rdparty/Gamma -I/tmp/build/src/plugins/score-plugin-gfx -I/ossia/score/src/plugins/score-plugin-gfx -I/tmp/build/3rdparty/snappy -I/ossia/score/3rdparty/snappy -isystem /ossia/score/3rdparty/libossia/3rdparty/nano-signal-slot -isystem /ossia/score/3rdparty/libossia/3rdparty/brigand -isystem /ossia/score/3rdparty/libossia/3rdparty/readerwriterqueue -isystem /ossia/score/3rdparty/magicitems/include -isystem /ossia/score/3rdparty/avendish/include -isystem /ossia/score/3rdparty/libossia/3rdparty/boost_1_81_0 -isystem /ossia/score/3rdparty/libossia/3rdparty/rnd/include -isystem /usr/include/qt6/QtCore -isystem /usr/include/qt6 -isystem /usr/lib64/qt6/mkspecs/linux-g++ -isystem /usr/include/qt6/QtGui -isystem /usr/include/qt6/QtGui/6.5.0 -isystem /usr/include/qt6/QtGui/6.5.0/QtGui -isystem /usr/include/qt6/QtCore/6.5.0 -isystem /usr/include/qt6/QtCore/6.5.0/QtCore -isystem /usr
[Bug c++/107579] ICE on fold-expression on .* member access operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107579 --- Comment #4 from Jean-Michaël Celerier --- Adding an explicit "member..." to the lambda capture, e.g. [&, member...] makes it work
[Bug c++/107579] ICE on fold-expression on .* member access operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107579 --- Comment #3 from Jean-Michaël Celerier --- It worked in 11.2 and started failing in 11.3. Short repro: https://gcc.godbolt.org/z/GYYbrTdxh #include template constexpr void for_each_field(T&& value, F&& func) { using namespace boost::pfr; using namespace boost::pfr::detail; constexpr std::size_t fields_count_val = fields_count>(); auto t = boost::pfr::detail::tie_as_tuple(value); [&](std::index_sequence) { (func(get(t)), ...); } (std::make_index_sequence{}); } constexpr int index_in_struct(const auto& s, auto... member) { int index = -1; int k = 0; for_each_field(s, [&](auto& m) { if constexpr(requires { bool(&m == &(s.**member)); }) { if(&m == &(s.**member)) { index = k; } } ++k; }); return index; } struct X { int z; }; int main() { constexpr int r = index_in_struct(X{}, &X::z); }
[Bug c++/107579] ICE on fold-expression on .* member access operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107579 --- Comment #2 from Jean-Michaël Celerier --- Clang and MSVC compiles the same thing correctly
[Bug c++/107579] ICE on fold-expression on .* member access operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107579 --- Comment #1 from Jean-Michaël Celerier --- Created attachment 53851 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53851&action=edit bug report provided by -fbug-report
[Bug c++/107579] New: ICE on fold-expression on .* member access operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107579 Bug ID: 107579 Summary: ICE on fold-expression on .* member access operator Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- The function that is causing the ICE: ``` constexpr int index_in_struct(const auto& s, auto... member) { int index = -1; int k = 0; avnd::for_each_field_ref(s, [&](auto& m) { if constexpr(requires { bool(&m == &(s.**member)); }) { if(&m == &(s.**member)) { index = k; } } ++k; }); assert(index >= 0); return index; } ``` The error: /home/jcelerier/score/3rdparty/avendish/include/avnd/common/for_nth.hpp:114:26: internal compiler error: trying to capture 'member#0' in instantiation of generic lambda 114 | if(&m == &(s.**member)) | ^~ 0x19eab38 internal_error(char const*, ...) ???:0 0x71c547 add_capture(tree_node*, tree_node*, tree_node*, bool, bool) ???:0 0x71c5b3 add_default_capture(tree_node*, tree_node*, tree_node*) ???:0 0x7e232a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ???:0 0x7e0baa tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ???:0 0x7e8d8c tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*) ???:0 0x7dff89 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ???:0 0x7e0d41 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ???:0 0x7dfdeb tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ???:0 0x7db043 instantiate_decl(tree_node*, bool, bool) ???:0 0x6edb1b mark_used(tree_node*, int) ???:0 0x68b85f build_op_call(tree_node*, vec**, int) ???:0 0x810f2d finish_call_expr(tree_node*, vec**, bool, bool, int) ???:0 0x7e1f0c tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ???:0 0x7e8d8c tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*) ???:0 0x7dff89 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ???:0 0x7db043 instantiate_decl(tree_node*, bool, bool) ???:0 0x6edb1b mark_used(tree_node*, int) ???:0 0x68b85f build_op_call(tree_node*, vec**, int) ???:0 0x810f2d finish_call_expr(tree_node*, vec**, bool, bool, int) ???:0
[Bug c++/106668] ICE: friend function in struct declaration in generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106668 --- Comment #1 from Jean-Michaël Celerier --- When checking on gcc.godbolt.org it seems that it crashes as far back as GCC 4.9.0 (and 4.8 doesn't seem to be able to compile generic lambdas)
[Bug c++/106668] New: ICE: friend function in struct declaration in generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106668 Bug ID: 106668 Summary: ICE: friend function in struct declaration in generic lambda Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- Repro: foo.cpp void foo(); bool ok = [] (auto x) { struct y { friend void foo(); }; return 0; }(0); build: $ g++ foo.cpp : In instantiation of ' [with auto:1 = int]': :7:6: required from here :3:14: internal compiler error: Segmentation fault 3 | struct y { | ^ 0x1ba65f9 internal_error(char const*, ...) ???:0 0x878158 instantiate_decl(tree_node*, bool, bool) ???:0 0x8936ab instantiate_pending_templates(int) ???:0 0x79c46d c_parse_final_cleanups() ???:0 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. ASM generation compiler returned: 1 : In instantiation of ' [with auto:1 = int]': :7:6: required from here :3:14: internal compiler error: Segmentation fault 3 | struct y { | ^ 0x1ba65f9 internal_error(char const*, ...) ???:0 0x878158 instantiate_decl(tree_node*, bool, bool) ???:0 0x8936ab instantiate_pending_templates(int) ???:0 0x79c46d c_parse_final_cleanups() ???:0 It fails in c++14, 17 and 20 modes
[Bug c++/105683] New: [12 Regression] Infinite loop with construction of vector of variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105683 Bug ID: 105683 Summary: [12 Regression] Infinite loop with construction of vector of variant Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- Created attachment 53012 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53012&action=edit Full repro Hello, Full repro attached (g++ -std=gnu++20 repro.cpp && ./a.out is enough to trigger the issue). Same code works fine for every GCC version < 12 in c++17, c++20, as well as with every released clang version in c++17, c++20, with both libc++ and libstdc++. My code more-or-less looks like this (trying to keep only the relevant parts): // line 58584 struct value_variant_type { union Impl { std::vector m_value8; } m_impl; value_variant_type(const std::vector& v); value_variant_type(std::vector&& v); }; // line 58681 class value { value_variant_type v; value(const std::vector& val) noexcept : v{val} { } explicit value(std::vector&& val) noexcept : v{std::move(val)} { } }; // line 75925 inline value_variant_type::value_variant_type(const std::vector& v) : m_type{Type8} { new (&m_impl.m_value8) std::vector(v); } inline value_variant_type::value_variant_type(std::vector&& v) : m_type{Type8} { new (&m_impl.m_value8) std::vector(std::move(v)); } // line 58916 inline ossia::value init_value(ossia::val_type type) { return std::vector{}; } // line 76232 void create_value_inline(ossia::value& v, ossia::val_type t) { v = ossia::init_value(t); } int main() { ossia::value v; create_value_inline(v, ossia::val_type::LIST); } What it looks that is happening is a loop between the construction of the value and of the vector: #1822 0x87b7 in ossia::value::value (other=..., this=0x55abff10) at /home/jcelerier/ossia/score/3rdparty/libossia/src/ossia/network/value/value.hpp:302 #1823 std::_Construct (__p=0x55abff10) at /usr/include/c++/12.1.0/bits/stl_construct.h:119 #1824 std::__do_uninit_copy (__result=, __last=, __first=0x7f802a50) at /usr/include/c++/12.1.0/bits/stl_uninitialized.h:120 #1825 std::__uninitialized_copy::__uninit_copy (__result=, __last=, __first=) at /usr/include/c++/12.1.0/bits/stl_uninitialized.h:137 #1826 std::uninitialized_copy (__result=, __last=, __first=) at /usr/include/c++/12.1.0/bits/stl_uninitialized.h:185 #1827 std::__uninitialized_copy_a (__result=0x55abff10, __last=0x7f802a78, __first=0x7f802a50) at /usr/include/c++/12.1.0/bits/stl_uninitialized.h:372 #1828 std::vector >::_M_range_initialize (__last=0x7f802a78, __first=0x7f802a50, this=0x55abfee0) at /usr/include/c++/12.1.0/bits/stl_vector.h:1690 #1829 std::vector >::vector (__a=..., Python Exception : value has been optimized out __l=, this=0x55abfee0) at /usr/include/c++/12.1.0/bits/stl_vector.h:677 #1830 ossia::value_variant_type::value_variant_type (other=..., this=0x55abfee0) at /home/jcelerier/ossia/score/3rdparty/libossia/src/ossia/network/value/value_variant_impl.hpp:17017 #1831 ossia::value::value (other=..., this=0x55abfee0) at /home/jcelerier/ossia/score/3rdparty/libossia/src/ossia/network/value/value.hpp:302
[Bug c++/102990] [9/10/11 Regression] ICE in tsubst_copy_and_build with NSDMI and double to int conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102990 --- Comment #12 from Jean-Michaël Celerier --- In any case many thanks for fixing this !
[Bug c++/102990] [9/10/11 Regression] ICE in tsubst_copy_and_build with NSDMI and double to int conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102990 --- Comment #11 from Jean-Michaël Celerier --- Do you know if the patch will be applied to the 10.x / 11.x branches ?
[Bug c++/104720] New: internal compiler error: in tsubst_copy_and_build, at cp/pt.c:19817
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104720 Bug ID: 104720 Summary: internal compiler error: in tsubst_copy_and_build, at cp/pt.c:19817 Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- Created attachment 52527 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52527&action=edit Repro for the bug Repro: ``` $ g++ -std=c++20 processed.cpp -fcoroutines -fext-numeric-literals In file included from /usr/include/boost/pfr/detail/core17.hpp:11, from /usr/include/boost/pfr/detail/core.hpp:17, from /usr/include/boost/pfr/core.hpp:12, from /usr/include/boost/pfr.hpp:12, from /home/jcelerier/ossia/score/3rdparty/avendish/include/avnd/concepts/generic.hpp:7, from /home/jcelerier/ossia/score/3rdparty/avendish/include/avnd/concepts/audio_port.hpp:5, from /home/jcelerier/ossia/score/3rdparty/avendish/examples/Oscr/ControlGallery.hpp:2, from /tmp/av/build/examples__ControlGallery_ossia.cpp:3: /usr/include/boost/pfr/detail/fields_count.hpp: In substitution of ‘template constexpr decltype (sizeof (T{})) boost::pfr::detail::detect_fields_count_dispatch(boost::pfr::detail::size_t_, long int, int) [with T = examples::ControlGallery::; long unsigned int N = ]’: /usr/include/boost/pfr/detail/fields_count.hpp:305:78: required from ‘constexpr std::size_t boost::pfr::detail::fields_count() [with T = const examples::ControlGallery::; std::size_t = long unsigned int]’ /usr/include/boost/pfr/detail/core17.hpp:54:54: required from ‘constexpr auto boost::pfr::detail::tie_as_tuple(T&) [with T = const examples::ControlGallery::]’ /usr/include/boost/pfr/core.hpp:106:29: required from ‘constexpr auto boost::pfr::structure_to_tuple(const T&) [with T = examples::ControlGallery::]’ /home/jcelerier/ossia/score/3rdparty/avendish/include/avnd/concepts/port.hpp:12:549: required from ‘struct avnd::inputs_type’ /home/jcelerier/ossia/score/3rdparty/avendish/include/avnd/concepts/processor.hpp:36:43: required from ‘constexpr const int avnd::mono_sample_array_input_port_count’ /home/jcelerier/ossia/score/3rdparty/avendish/include/avnd/concepts/processor.hpp:60:8: required by substitution of ‘template requires (monophonic_audio_processor) && ((inputs_is_value) && (outputs_is_value)) struct avnd::effect_container [with T = examples::ControlGallery]’ /home/jcelerier/ossia/score/3rdparty/avendish/include/avnd/binding/ossia/node.hpp:471:31: required from ‘class oscr::safe_node_base’ /home/jcelerier/ossia/score/3rdparty/avendish/include/avnd/binding/ossia/port_node.hpp:7:7: required from ‘class oscr::safe_node’ /tmp/av/build/examples__ControlGallery_ossia.cpp:11:25: required from here /usr/include/boost/pfr/detail/fields_count.hpp:243:17: internal compiler error: in tsubst_copy_and_build, at cp/pt.c:19817 243 | -> decltype(sizeof(T{})) | ^~~ 0x16b7aa9 internal_error(char const*, ...) ???:0 0x63d391 fancy_abort(char const*, int, char const*) ???:0 0x69d25e fold_non_dependent_init(tree_node*, int, bool, tree_node*) ???:0 0x807e3d finish_compound_literal(tree_node*, tree_node*, int, fcl_t) ???:0 0x7cd4ae tsubst(tree_node*, tree_node*, int, tree_node*) ???:0 0x7ccc26 tsubst(tree_node*, tree_node*, int, tree_node*) ???:0 0x7dbe67 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node* const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool, bool) ???:0 0x66c809 build_new_function_call(tree_node*, vec**, int) ???:0 0x7f9c5c finish_call_expr(tree_node*, vec**, bool, bool, int) ???:0 0x7dd8b0 instantiate_decl(tree_node*, bool, bool) ???:0 0xfbdbe2 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ???:0 0xfbddfa walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ???:0 0xfbed9c walk_tree_without_duplicates_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ???:0 0x69cde4 maybe_constant_value(tree_node*, tree_node*, bool) ???:0 0x7cd689 tsubst(tree_node*, tree_node*, int, tree_node*) ???:0 0x7dd8b0 instantiate_decl(tree_node*, bool, bool) ???:0 0x6db023 mark_used(tree_node*, int) ???:0 0x66c81e build_new_function_ca
[Bug c++/103764] Global std::string constructor not called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103764 --- Comment #3 from Jean-Michaël Celerier --- Wops, sorry for the noise, forgot that shared libs were "executable"
[Bug c++/103764] New: Global std::string constructor not called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103764 Bug ID: 103764 Summary: Global std::string constructor not called Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- Repro: foo.cpp: #include std::string my_global_string(100, 'x'); main.cpp: #include #include extern std::string my_global_string; int main() { std::cout << my_global_string << std::endl; } Build: $ g++ foo.cpp -shared -O3 -fPIC -o libfoo.so $ g++ main.cpp -shared -O3 -fPIC -L$PWD -lfoo Run: $ LD_LIBRARY_PATH=$PWD ./a.out [1]66470 segmentation fault (core dumped) ./a.out Valgrind: $ valgrind -s ./a.out ==66587== Memcheck, a memory error detector ==66587== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==66587== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info ==66587== Command: ./a.out ==66587== ==66587== Invalid read of size 8 ==66587==at 0x1090B5: main (in /tmp/a.out) ==66587== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==66587== ==66587== ==66587== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==66587== Access not within mapped region at address 0x8 ==66587==at 0x1090B5: main (in /tmp/a.out) ==66587== If you believe this happened as a result of a stack ==66587== overflow in your program's main thread (unlikely but ==66587== possible), you can try to increase the size of the ==66587== main thread stack using the --main-stacksize= flag. ==66587== The main thread stack size used in this run was 8388608. ==66587== ==66587== HEAP SUMMARY: ==66587== in use at exit: 0 bytes in 0 blocks ==66587== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==66587== ==66587== All heap blocks were freed -- no leaks are possible ==66587== ==66587== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) ==66587== ==66587== 1 errors in context 1 of 1: ==66587== Invalid read of size 8 ==66587==at 0x1090B5: main (in /tmp/a.out) ==66587== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==66587== ==66587== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) [1]66587 segmentation fault (core dumped) valgrind -s ./a.out
[Bug c++/102990] New: ICE in tsubst_copy_and_build, à cp/pt.c:19856
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102990 Bug ID: 102990 Summary: ICE in tsubst_copy_and_build, à cp/pt.c:19856 Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- Created attachment 51695 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51695&action=edit Source code that causes the ICE Hello, g++-11.1 (Arch Linux). Here's the stack trace I'm getting: $ g++ -fPIC -fcoroutines -std=gnu++20 -c out.cpp In file included from /usr/include/boost/pfr/detail/core17.hpp:11, from /usr/include/boost/pfr/detail/core.hpp:17, from /usr/include/boost/pfr/core.hpp:12, from /usr/include/boost/pfr.hpp:12, from /home/jcelerier/projets/perso/avendish/src/avnd/concepts/generic.hpp:6, from /home/jcelerier/projets/perso/avendish/src/avnd/concepts/audio_port.hpp:6, from /home/jcelerier/projets/perso/avendish/src/avnd/concepts.hpp:6, from /home/jcelerier/projets/perso/avendish/src/avnd/prepare.hpp:5, from /home/jcelerier/projets/perso/avendish/src/avnd/avnd.hpp:5, from /home/jcelerier/projets/perso/avendish/src/python/processor.hpp:5, from /tmp/sdfljifg/examples__Helpers_python.cpp:5: /usr/include/boost/pfr/detail/fields_count.hpp: In substitution of ‘template constexpr decltype (sizeof (T{})) boost::pfr::detail::detect_fields_count_dispatch(boost::pfr::detail::size_t_, long int, int) [with T = examples::Helpers::; long unsigned int N = ]’: /usr/include/boost/pfr/detail/fields_count.hpp:243:78: required from ‘constexpr std::size_t boost::pfr::detail::fields_count() [with T = const examples::Helpers::; std::size_t = long unsigned int]’ /usr/include/boost/pfr/detail/core17.hpp:54:54: required from ‘constexpr auto boost::pfr::detail::tie_as_tuple(T&) [with T = const examples::Helpers::]’ /usr/include/boost/pfr/core.hpp:106:29: required from ‘constexpr auto boost::pfr::structure_to_tuple(const T&) [with T = examples::Helpers::]’ /home/jcelerier/projets/perso/avendish/src/avnd/concepts/port.hpp:12:424: required from ‘struct avnd::inputs_type >’ /home/jcelerier/projets/perso/avendish/src/avnd/input_introspection.hpp:13:7: required by substitution of ‘template using parameter_input_introspection = avnd::parameter_introspection::type> [with T = examples::Helpers]’ /home/jcelerier/projets/perso/avendish/src/python/processor.hpp:47:54: required from ‘python::processor::processor(pybind11::module_&) [with T = examples::Helpers]’ /tmp/sdfljifg/examples__Helpers_python.cpp:10:52: required from here /usr/include/boost/pfr/detail/fields_count.hpp:189:17: internal compiler error: in tsubst_copy_and_build, at cp/pt.c:19856 189 | -> decltype(sizeof(T{})) | ^~~ 0x1797368 internal_error(char const*, ...) ???:0 0x67f8f9 fancy_abort(char const*, int, char const*) ???:0 0x6be30e fold_non_dependent_init(tree_node*, int, bool, tree_node*) ???:0 0x816127 finish_compound_literal(tree_node*, tree_node*, int, fcl_t) ???:0 0x7e78a9 tsubst(tree_node*, tree_node*, int, tree_node*) ???:0 0x7e721e tsubst(tree_node*, tree_node*, int, tree_node*) ???:0 0x803139 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node* const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool, bool) ???:0 0x6994f5 build_new_function_call(tree_node*, vec**, int) ???:0 0x8177bc finish_call_expr(tree_node*, vec**, bool, bool, int) ???:0 0x7ea4ef instantiate_decl(tree_node*, bool, bool) ???:0 0xfa14b3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ???:0 0xfa16a0 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ???:0 0xfa37da walk_tree_without_duplicates_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ???:0 0x6bdef4 maybe_constant_value(tree_node*, tree_node*, bool) ???:0 0x7e7c3a tsubst(tree_node*, tree_node*, int, tree_node*) ???:0 0x7ea4ef instantiate_decl(tree_node*, bool, bool) ???:0 0x711996 mark_used(tree_node*, int) ???:0 0x
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679 --- Comment #25 from Jean-Michaël Celerier --- My code is built with CMake with CMAKE_POSITION_INDEPENDENT_CODE set, which (I double checked) correctly adds -fPIC to the link line.
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679 Jean-Michaël Celerier changed: What|Removed |Added CC||jeanmichael.celerier@gmail. ||com --- Comment #24 from Jean-Michaël Celerier --- Hello, I am still hitting this exact bug with GCC 11.1: calling std::cout in a library dlopen'd with RTLD_DEEPBIND causes a crash on sentry::sentry. I also found another report here : https://github.com/KhronosGroup/Vulkan-Loader/issues/433#issuecomment-658875808
[Bug libstdc++/96816] bitset: debug mode: operator== ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96816 --- Comment #2 from Jean-Michaël Celerier --- I'd wager this is a result of C++20 operator<=> changes and operator== synthesis.
[Bug libstdc++/96816] bitset: debug mode: operator== ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96816 --- Comment #1 from Jean-Michaël Celerier --- gcc.godbolt.org link for easy repro: https://gcc.godbolt.org/z/WYbzfT
[Bug libstdc++/96816] New: bitset: debug mode: operator== ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96816 Bug ID: 96816 Summary: bitset: debug mode: operator== ambiguous Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- Hello, Given the following code: ``` #define _GLIBCXX_DEBUG 1 #include std::bitset<3> a, b; bool test = (a == b); ``` clang gives the following error: ``` $ clang++ -c foo.cpp -std=c++20 In file included from foo.cpp:2: In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/bitset:1595: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/debug/bitset:356:26: error: use of overloaded operator '==' is ambiguous (with operand types 'const std::__debug::bitset<3>::_Base' (aka 'const bitset<3UL>') and 'const bitset<3UL>' (aka 'const std::__debug::bitset<3>')) { return _M_base() == __rhs; } ~ ^ ~ foo.cpp:5:16: note: in instantiation of member function 'std::__debug::bitset<3>::operator==' requested here bool test = (a == b); ^ /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/bitset:1306:7: note: candidate function operator==(const bitset<_Nb>& __rhs) const _GLIBCXX_NOEXCEPT ^ /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/debug/bitset:355:7: note: candidate function (with reversed parameter order) operator==(const bitset<_Nb>& __rhs) const _GLIBCXX_NOEXCEPT ^ 1 error generated ``` g++ does not, but I guess this still warrants checking ?
[Bug c++/93632] Build time regression in 9.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93632 --- Comment #2 from Jean-Michaël Celerier --- Without these options it goes down from 2 minutes to 16 seconds which is already much better, but still a couple times slower than before
[Bug c++/93632] New: Build time regression in 9.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93632 Bug ID: 93632 Summary: Build time regression in 9.2.1 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- Created attachment 47797 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47797&action=edit preprocessed source of the buggy file Hello, The following source code takes almost two minutes to build on GCC 9.2.1 - it's a boost.spirit parser./ https://github.com/OSSIA/score/blob/master/src/plugins/score-lib-state/State/ExpressionParser.cpp it only takes two seconds on clang and on previous GCC versions (at least 8.0 and 9.1.0, not sure about 9.2.0). Attached a preprocessed source - my build options are $ g++ -fno-stack-protector -g -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wextra -Wno-unused-parameter -Wno-unknown-pragmas -Wnon-virtual-dtor -pedantic -Woverloaded-virtual -pipe -Wno-missing-declarations -Wredundant-decls -Werror=return-type -Werror=trigraphs -Wno-gnu-string-literal-operator-template -Wno-missing-braces -Wmissing-field-initializers -Wno-gnu-statement-expression -Wno-four-char-constants -ftemplate-backtrace-limit=0 -O0 -fdebug-types-section -ggnu-pubnames -ggdb -fPIC -std=gnu++2a -c error.cpp If you want to setup a build from the git repo to reproduce, it's a matter (on archlinux with qt and boost) of : git submodule update --init --recursive cd score && mkdir build && cd build cmake .. -DSCORE_CONFIGURATION=developer -DCMAKE_BUILD_TYPE=Debug this will create a compile_commands.json with the ExpressionParser.cpp command line.
[Bug c++/87410] New: internal compiler error: in fold_convert_loc, at fold-const.c:2530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87410 Bug ID: 87410 Summary: internal compiler error: in fold_convert_loc, at fold-const.c:2530 Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- Created attachment 44743 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44743&action=edit XZ archive of preprocessed source Self-contained repro attached - g++ -std=c++17 repro.cpp is enough to trigger it
[Bug c++/87090] New: Constexpr variables in functions are not optimized correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87090 Bug ID: 87090 Summary: Constexpr variables in functions are not optimized correctly Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- Consider the following code : #include #include struct Table { long long tab[128]; constexpr Table() : tab {} { tab['0'] = 0; tab['1'] = 1; tab['2'] = 2; tab['3'] = 3; tab['4'] = 4; tab['5'] = 5; tab['6'] = 6; tab['7'] = 7; tab['8'] = 8; tab['9'] = 9; tab['a'] = 10; tab['A'] = 10; tab['b'] = 11; tab['B'] = 11; tab['c'] = 12; tab['C'] = 12; tab['d'] = 13; tab['D'] = 13; tab['e'] = 14; tab['E'] = 14; tab['f'] = 15; tab['F'] = 15; } constexpr auto operator[](const std::size_t idx) const { return tab[idx]; } } constexpr t; constexpr auto conv(std::size_t number) { return t[number]; } std::array res; void convert(std::string_view hex) { res[0] = (conv(hex[1])); res[1] = (conv(hex[3])); res[2] = (conv(hex[5])); res[3] = (conv(hex[7])); } When benchmarking it (calling the `convert("#00ABCDEF")` function a few million times from another translation unit), I get the following numbers consistently : g++-8.2.0 : 8-9 nanoseconds per call clang++-6.0.1 : 8-10 nanoseconds per call Now, if I want to put the table inside the conv function to keep it in a small scope, such as this : constexpr auto conv(std::size_t number) { struct Table { long long tab[128]; constexpr Table() : tab {} { tab['0'] = 0; tab['1'] = 1; tab['2'] = 2; tab['3'] = 3; tab['4'] = 4; tab['5'] = 5; tab['6'] = 6; tab['7'] = 7; tab['8'] = 8; tab['9'] = 9; tab['a'] = 10; tab['A'] = 10; tab['b'] = 11; tab['B'] = 11; tab['c'] = 12; tab['C'] = 12; tab['d'] = 13; tab['D'] = 13; tab['e'] = 14; tab['E'] = 14; tab['f'] = 15; tab['F'] = 15; } constexpr auto operator[](const std::size_t idx) const { return tab[idx]; } } constexpr t; return t[number]; } I get the following numbers : clang++-6.0.1 : 8-10 nanoseconds per call (no changes) g++-8.2.0 : 120-150 nanoseconds per call, more than ten times slower ! I tested for both compiles at -O2 and -O3 without observable changes. If I make the "conv" function itself non-constexpr, and mark the table as static constexpr, I get my performance back - I guess that even while constexpr the table must be initialized each time ?
[Bug c++/86403] New: Deduction guides not supported in local classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86403 Bug ID: 86403 Summary: Deduction guides not supported in local classes Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- See for instance : https://godbolt.org/g/6DKxPx
[Bug ipa/83582] GCC is unable to fold the code of identical lambda-expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83582 --- Comment #4 from Jean-Michaël Celerier --- I posted a similar bug report for clang: https://bugs.llvm.org/show_bug.cgi?id=35783
[Bug demangler/83313] A whole lot of symbols cannot be demangled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83313 --- Comment #5 from Jean-Michaël Celerier --- Also the git clone has to be recursive: git clone --recursive -j8 https://github.com/OSSIA/score
[Bug debug/80490] -gsplit-dwarf: top namespace info seems to be lost in GDB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80490 --- Comment #5 from Jean-Michaël Celerier --- That's still the case with G++ 7.2.1 and GDB 8.0.1.
[Bug demangler/83313] A whole lot of symbols cannot be demangled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83313 --- Comment #4 from Jean-Michaël Celerier --- Yuck sorry, I entirely forgot to answer to this. Yes: https://github.com/OSSIA/score on branch feature/dataflow. Requires latest boost, latest cmake, latest Qt5. Building with cmake ../score -DSCORE_CONFIGURATION=static-debug && cmake --build . -- -j8 should work on any distro with recent packages.
[Bug c++/83630] New: GCC 7.2.1: ICE in replace_placeholders_r, at cp/tree.c:2796
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83630 Bug ID: 83630 Summary: GCC 7.2.1: ICE in replace_placeholders_r, at cp/tree.c:2796 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- The following simple code ICEs GCC 7.2.1: struct dummy { }; struct dummy2 { dummy make(); }; struct test_struct { dummy2 m_1; dummy m_2{m_1.make()}; }; template dummy foo(const T&) { dummy b; return b; } int main() { foo(test_struct{}); }
[Bug ipa/83582] New: GCC is unable to fold the code of identical lambda-expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83582 Bug ID: 83582 Summary: GCC is unable to fold the code of identical lambda-expressions Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Case 1: https://godbolt.org/g/JvmxJr Case 2: https://godbolt.org/g/FWo12z It seems that the compiler should be able to pick up lambda functions with the same implementation, at least in a given translation unit.
[Bug demangler/83313] A whole lot of symbols cannot be demangled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83313 --- Comment #2 from Jean-Michaël Celerier --- @Martin Liška I'm using the default arch linux toolchain which is reasonably up-to-date AFAIK: $ g++ --version g++ (GCC) 7.2.1 20171128 $ ld.gold --version GNU gold (GNU Binutils 2.29.1) 1.14
[Bug demangler/83313] New: A whole lot of symbols cannot be demangled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83313 Bug ID: 83313 Summary: A whole lot of symbols cannot be demangled Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- From my software ; I've got them by running nm -a | c++filt | grep _Z. _ZN5Nodes5Chord4Node13dispatchChordIZNS1_3runERKN5ossia9midi_portERKN5boost9container8flat_mapIliSt4lessIlENS8_13new_allocatorISt4pairIliERKNS9_IlNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESB_NSC_ISD_IlSO_ERS4_RNS1_5StateENS3_10time_valueENS3_13token_requestERNS3_15execution_stateEEUlDpOT_E0_EEviRKN2mm11MidiMessageEiSU_OT_ _ZN5Nodes5Chord4Node13dispatchChordIZNS1_3runERKN5ossia9midi_portERKN5boost9container8flat_mapIliSt4lessIlENS8_13new_allocatorISt4pairIliERKNS9_IlNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESB_NSC_ISD_IlSO_ERS4_RNS1_5StateENS3_10time_valueENS3_13token_requestERNS3_15execution_stateEEUlDpOT_E_EEviRKN2mm11MidiMessageEiSU_OT_ etc etc... whole list here: https://paste.debian.net/999651/
[Bug demangler/82026] New: Undemanglable symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82026 Bug ID: 82026 Summary: Undemanglable symbol Product: gcc Version: 7.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- This one makes c++filt and GDB crash: _ZN4eggs8variants6detail7visitorINS1_6_applyIvZN5Media12AudioDecoder14on_startDecodeE7QStringEUlRT_E_NS1_4packIJEEENSA_IJRNS1_8_storageINSA_IJNS1_5emptyEN12_GLOBAL__N_17DecoderIsLm1ELm16ELb1EEENSF_IsLm2ELm16ELb1EEENSF_IsLm2ELm16ELb0EEENSF_IsLm4ELm16ELb1EEENSF_IsLm4ELm16ELb0EEENSF_IsLm6ELm16ELb1EEENSF_IsLm6ELm16ELb0EEENSF_IsLm8ELm16ELb1EEENSF_IsLm8ELm16ELb0EEENSF_IsLm18446744073709551615ELm16ELb1EEENSF_IsLm18446744073709551615ELm16ELb0EEENSF_IiLm1ELm24ELb1EEENSF_IiLm2ELm24ELb1EEENSF_IiLm2ELm24ELb0EEENSF_IiLm4ELm24ELb1EEENSF_IiLm4ELm24ELb0EEENSF_IiLm6ELm24ELb1EEENSF_IiLm6ELm24ELb0EEENSF_IiLm8ELm24ELb1EEENSF_IiLm8ELm24ELb0EEENSF_IiLm18446744073709551615ELm24ELb1EEENSF_IiLm18446744073709551615ELm24ELb0EEENSF_IiLm1ELm32ELb1EEENSF_IiLm2ELm32ELb1EEENSF_IiLm2ELm32ELb0EEENSF_IiLm4ELm32ELb1EEENSF_IiLm4ELm32ELb0EEENSF_IiLm6ELm32ELb1EEENSF_IiLm6ELm32ELb0EEENSF_IiLm8ELm32ELb1EEENSF_IiLm8ELm32ELb0EEENSF_IiLm18446744073709551615ELm32ELb1EEENSF_IiLm18446744073709551615ELm32ELb0EEENSF_IfLm1ELm32ELb1EEENSF_IfLm2ELm32ELb1EEENSF_IfLm2ELm32ELb0EEENSF_IfLm4ELm32ELb1EEENSF_IfLm4ELm32ELb0EEENSF_IfLm6ELm32ELb1EEENSF_IfLm6ELm32ELb0EEENSF_IfLm8ELm32ELb1EEENSF_IfLm8ELm32ELb0EEENSF_IfLm18446744073709551615ELm32ELb1EEENSF_IfLm18446744073709551615ELm32ELb0EELb1ELb1FvOS9_S1Q_EE6_tableIJNS1_5indexILm1EEENS1X_ILm2EEENS1X_ILm3EEENS1X_ILm4EEENS1X_ILm5EEENS1X_ILm6EEENS1X_ILm7EEENS1X_ILm8EEENS1X_ILm9EEENS1X_ILm10EEENS1X_ILm11EEENS1X_ILm12EEENS1X_ILm13EEENS1X_ILm14EEENS1X_ILm15EEENS1X_ILm16EEENS1X_ILm17EEENS1X_ILm18EEENS1X_ILm19EEENS1X_ILm20EEENS1X_ILm21EEENS1X_ILm22EEENS1X_ILm23EEENS1X_ILm24EEENS1X_ILm25EEENS1X_ILm26EEENS1X_ILm27EEENS1X_ILm28EEENS1X_ILm29EEENS1X_ILm30EEENS1X_ILm31EEENS1X_ILm32EEENS1X_ILm33EEENS1X_ILm34EEENS1X_ILm35EEENS1X_ILm36EEENS1X_ILm37EEENS1X_ILm38EEENS1X_ILm39EEENS1X_ILm40EEENS1X_ILm41EEENS1X_ILm42EEENS1X_ILm43EEENS1X_ILm44E5valueE
[Bug debug/80490] -gsplit-dwarf: top namespace info seems to be lost in GDB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80490 --- Comment #3 from Jean-Michaël Celerier --- Okay, I reported on their bug tracker. I guess this issue can be closed ?
[Bug debug/80490] -gsplit-dwarf: top namespace info seems to be lost in GDB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80490 --- Comment #1 from Jean-Michaël Celerier --- Also: * When compiling this way with GCC (with just -g instead of -ggdb) I am not able to debug with lldb * When compiling with the same arguments with clang++, I am able to debug with lldb *and* see the correct types, but with gdb I see the (anonymous namespace):: stuff.
[Bug debug/80490] New: -gsplit-dwarf: top namespace info seems to be lost in GDB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80490 Bug ID: 80490 Summary: -gsplit-dwarf: top namespace info seems to be lost in GDB Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- Given the following code: main.cpp: namespace ossia { class foo { public: void f() { } }; namespace net { class bar { public: void g() { } }; } } int main() { auto x = new ossia::foo; auto y = new ossia::net::bar; x->f(); y->g(); } And the following invocation : g++ -ggdb -O0 -gsplit-dwarf -Wl,--gdb-index -fuse-ld=gold main.cpp Debugging in gdb looks like this : gdb a.out b main > auto x = new ossia::foo; p x > $1 = ((anonymous namespace)::foo *) 0x414c20 n p y > $2 = ((anonymous namespace)::net::bar *) 0x414c40 Doing strings a.out | c++filt seems to yield the correct types, though.
[Bug demangler/79406] Demangler crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79406 --- Comment #1 from Jean-Michaël Celerier --- This stems from the usage of the following lambda expression : [&] (auto&&... args) { return this->fun(std::forward(args)...); } Unlike bug 77950 the enclosing function is not a template but a simple class constructor that takes two int16_t. The arguments passed to the lambda are either : * (std::weak_ptr) * (std::weak_ptr, const std::string&)
[Bug demangler/79406] New: Demangler crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79406 Bug ID: 79406 Summary: Demangler crash Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- With the following symbol : _ZSt4moveIRZN5ossia8oscquery16websocket_server19set_message_handlerIZNS1_24oscquery_server_protocolC4EssEUlDpOT_E2_EEvT_EUlSt8weak_ptrIvESt10shared_ptrIN11websocketpp14message_buffer7messageINSE_5alloc15con_msg_managerE_EONSt16remove_referenceIS9_E4typeEOS9_
[Bug c++/78065] incorrect behavior with std::is_same with nested class in a template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78065 --- Comment #5 from Jean-Michaël Celerier --- Okay, thanks !
[Bug libstdc++/78065] incorrect behavior with std::is_same with nested class in a template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78065 --- Comment #1 from Jean-Michaël Celerier --- Here is the relevant bug report in clang bug tacker : https://llvm.org/bugs/show_bug.cgi?id=30759
[Bug libstdc++/78065] New: incorrect behavior with std::is_same with nested class in a template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78065 Bug ID: 78065 Summary: incorrect behavior with std::is_same with nested class in a template class Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- In this code, the first static_assert compiles with g++ (and also clang, but not MSVC) : #include template struct foo { using sub = struct some_struct; }; template struct bar { using sub = struct some_struct { }; }; int main() { static_assert(std::is_same::sub, foo::sub>::value, "should not pass"); static_assert(std::is_same::sub, bar::sub>::value, "should not pass"); } The second does (correctly, in my opinion) not.
[Bug c++/77950] New: GCC produces un-demanglable symbols with [] (auto&) { ... } lambdas in templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77950 Bug ID: 77950 Summary: GCC produces un-demanglable symbols with [] (auto&) { ... } lambdas in templates Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- Created attachment 39793 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39793&action=edit Preprocessed source exhibiting the bug My problem is in the attachement starting at line 135809, within the struct vec_merger_impl. When I have this code : template struct vec_merger_impl { template ossia::value_with_unit operator()(const Dataspace_T& ds) { if(ds) { return eggs::variants::apply([&] (auto& unit) -> ossia::value_with_unit { return detail::vec_value_merger{idx}(unit, val); }, ds); } return {}; } }; The lambda [&] (auto& unit) ... produces undemanglable code, which makes the software undebuggable... doing "nm -a preprocessed.o | c++filt" fails at the following symbol : _ZN4eggs8variants6detail7forwardIOZN5ossia15vec_merger_implILi2EEclINS0_7variantIJNS3_12strong_valueINS3_11speed_ratioISt5ratioILl1ELl1EENS8_INS9_ISA_ILl16093440ELl3600EENS8_INS9_ISA_ILl1000ELl3600EENS8_INS9_ISA_ILl1852ELl3600EENS8_INS9_ISA_ILl3048ELl1EENS8_INS9_ISA_ILl3048ELl3600EEENS7_IJNS3_5valueENS7_IJNS8_INS3_14distance_ratioISB_NS8_INSV_ISA_ILl1000ELl1EENS8_INSV_ISA_ILl1ELl10EENS8_INSV_ISA_ILl1ELl100EENS8_INSV_ISA_ILl1ELl1000EENS8_INSV_ISA_ILl1ELl100EENS8_INSV_ISA_ILl1ELl10EENS8_INSV_ISA_ILl1ELl1EENS8_INSV_ISA_ILl254ELl1EENS8_INSV_ISN_NS8_INSV_ISA_ILl16093440ELl1ENS7_IJNS8_INS3_14cartesian_3d_uEEENS8_INS3_14cartesian_2d_uEEENS8_INS3_11spherical_uEEENS8_INS3_7polar_uEEENS8_INS3_8opengl_uEEENS8_INS3_13cylindrical_uEEST_NS7_IJNS8_INS3_12quaternion_uEEENS8_INS3_7euler_uEEENS8_INS3_6axis_uEENS7_IJNS8_INS3_8degree_uEEENS8_INS3_8radian_uEENS7_IJNS8_INS3_6argb_uEEENS8_INS3_6rgba_uEEENS8_INS3_5rgb_uEEENS8_INS3_5bgr_uEEENS8_INS3_7argb8_uEEENS8_INS3_5hsv_uEEENS8_INS3_6cmy8_uEEENS8_INS3_5xyz_uEENS7_IJNS8_INS3_8linear_uEEENS8_INS3_10midigain_uEEENS8_INS3_9decibel_uEEENS8_INS3_13decibel_raw_uERKT_EUlRS38_E_EEOS38_RNSt16remove_referenceIS38_E4typeE If I change my lambda by an equivalent functor (can be tested in the attached source by setting -DFIXED_VERSION, the code passes through c++filt (and GDB) without problems.
[Bug c++/77581] New: ICE: instantiate_template_1, cp/pt.c:17391
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77581 Bug ID: 77581 Summary: ICE: instantiate_template_1, cp/pt.c:17391 Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- Created attachment 39613 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39613&action=edit CPP source file that exhibits the bug ICE with g++ (GCC) 6.2.1 20160830
[Bug driver/66293] Support -Weverything to enable all warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66293 --- Comment #5 from Jean-Michaël Celerier --- > In my experience, options like -Weverything tend to be too noisy to be > generally useful for projects of non-trivial size. It's always possible to run -Weverything -Wno-foo -Wno-bar to remove unwanted warnings. It's a bit more work upfront, but will bring benefits at each compiler update. Generally speaking, I'd say that there are more "useful" than "useless" warnings, hence it's less work to disable the useless ones, than to enable the useful ones.
[Bug driver/66293] Support -Weverything to enable all warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66293 Jean-Michaël Celerier changed: What|Removed |Added CC||jeanmichael.celerier@gmail. ||com --- Comment #3 from Jean-Michaël Celerier --- As a Clang user, -Weverything allowed me to remove terrible bugs that would not crop up with -Wall -Wextra -Wfew-other-common-warnings. For instance GCC 6 brings in many new warnings it seems. Well, it is a pity to have to go through the manual to find the new warnings and enable them by hand (very few people will actually do this, while it could certainly make some bugs appear. Maybe it could prevent the next Heartbleed ?).
[Bug c++/67398] Segfault when template static references another template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67398 --- Comment #2 from Jean-Michaël Celerier --- I now get this error : /home/jcelerier/i-score/base/plugins/iscore-plugin-scenario/source/Process/ScenarioModel.cpp:63: internal compiler error: in make_decl_rtl, at varasm.c:1313 constexpr const QMetaObject NotifyingMap::staticMetaObject{ ^ if I change the relevant part of the code to this : template struct strdata_t { QByteArrayData data[5]{ QT_MOC_LITERAL_CUSTOM(0, 0, 12), // "NotifyingMap" QT_MOC_LITERAL_CUSTOM(1, 13, 5), // "added" QT_MOC_LITERAL_CUSTOM(2, 19, 0), // "" QT_MOC_LITERAL_CUSTOM(3, 20, typeLength()), // "T" QT_MOC_LITERAL_CUSTOM(4, 21 + typeLength(), 7) // "removed" }; std::array()> stringdata0 = concat("NotifyingMap\0added\0\0", T::className, "\0removed"); }; static const uint staticMetaData[31]{ // content: 7, // revision 0, // classname 0,0, // classinfo 2, 14, // methods 0,0, // properties 0,0, // enums/sets 0,0, // constructors 0, // flags 2, // signalCount // signals: name, argc, parameters, tag, flags 1,1, 24,2, 0x06 /* Public */, 4,1, 27,2, 0x06 /* Public */, // signals: parameters QMetaType::Void, 0x8000 | 3,2, QMetaType::Void, 0x8000 | 3,2, 0// eod }; template constexpr const QMetaObject NotifyingMap::staticMetaObject{ { &QObject::staticMetaObject, strdata_t{}.data, staticMetaData, qt_static_metacall, Q_NULLPTR, Q_NULLPTR } };
[Bug c++/67398] Segfault when template static references another template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67398 --- Comment #1 from Jean-Michaël Celerier --- I couldn't upload the attachment here (>1mb) so here is the preprocessed source : https://gist.githubusercontent.com/jcelerier/6e67a053e08188cac07f/raw/b74ad5be0dcc12ff230cc7212fe5fa94b6413686/gccsegfault.cpp
[Bug c++/67398] New: Segfault when template static references another template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67398 Bug ID: 67398 Summary: Segfault when template static references another template Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- Error given by gcc : /home/jcelerier/i-score/base/plugins/iscore-plugin-scenario/source/Process/ScenarioModel.cpp : dans l'instantiation de ‘const qt_meta_stringdata_NotifyingMap_t staticStringData’ : /home/jcelerier/i-score/base/plugins/iscore-plugin-scenario/source/Process/ScenarioModel.cpp:57:29: required from ‘const QMetaObject NotifyingMap::staticMetaObject’ /home/jcelerier/i-score/base/plugins/iscore-plugin-scenario/source/Process/ScenarioModel.cpp:73:172: required from here /home/jcelerier/i-score/base/plugins/iscore-plugin-scenario/source/Process/ScenarioModel.cpp:31:3: erreur interne du compilateur: Erreur de segmentation } staticStringData{}; ^ Rough translation of the last line : Internal Compiler Error : segmentation fault. The relevant part starts at line 196141 of the attached preprocessed source. It started when I added a template at line 196240 : staticStringData.data, The "required from here" refers to an usage of staticMetaObject in code. Requires -fPIC and -std=c++14.