[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((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((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=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=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( == &(s.**member)); })
{
if( == &(s.**member))
{
index = k;
}
}
++k;
});
return index;
}
struct X
{
int z;
};
int main()
{
constexpr int r = index_in_struct(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=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( == &(s.**member)); })
{
if( == &(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( == &(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=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 (_impl.m_value8) std::vector(v);
}
inline value_variant_type::value_variant_type(std::vector&&
v) : m_type{Type8}
{
new (_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=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_call(t
[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=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
0x69950a build_new_function_cal
[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=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=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<foo::sub, foo::sub>::value,
"should not pass");
static_assert(std::is_same<bar::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=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=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 #1 from Jean-Michaël Celerier jeanmichael.celerier at gmail dot com --- 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
staticStringDataConstraintModel’ :
/home/jcelerier/i-score/base/plugins/iscore-plugin-scenario/source/Process/ScenarioModel.cpp:57:29:
required from ‘const QMetaObject
NotifyingMapConstraintModel::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 :
staticStringDataT.data,
The required from here refers to an usage of staticMetaObject in code.
Requires -fPIC and -std=c++14.
[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 jeanmichael.celerier at gmail dot
com ---
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 NotifyingMapT::staticMetaObject{
^
if I change the relevant part of the code to this :
templatetypename T
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, typeLengthT()), // T
QT_MOC_LITERAL_CUSTOM(4, 21 + typeLengthT(), 7) // removed
};
std::arraychar, 29 + typeLengthT() 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
};
templatetypename T
constexpr const QMetaObject NotifyingMapT::staticMetaObject{
{ QObject::staticMetaObject,
strdata_tT{}.data,
staticMetaData, qt_static_metacall, Q_NULLPTR, Q_NULLPTR }
};
