undefined reference issue with latest gcc - c++

I have link-time error when trying to compile following code with gcc 12.1.0.
With clang, msvc and older gcc it compiles as expected.
template<typename T>
void def()
{}
template<void (*foobar)() = def<int>>
void bar()
{
foobar();
}
template<typename T>
void foo()
{
bar();
}
int main()
{
foo<int>();
}
Error: /usr/bin/ld: /tmp/cchkaKVw.o: in function `void bar<&(void def<int>())>()':
> main.cpp:(.text._Z3barIXadL_Z3defIiEvvEEEvv[_Z3barIXadL_Z3defIiEvvEEEvv]+0x5): undefined reference to `void def<int>()'
Is this a gcc regression or is there some problem with this code?

Reported this bug to GCC Bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105848

Related

undefined reference to `std::is_constant_evaluated()' in c++20 gcc

This is just a minimal reproducible example:
import <unordered_set>;
import <functional>;
template<class c>
class my_class {
};
template<class c>
struct std::hash<my_class<c>> {
std::size_t operator()(my_class<c> const &s) const noexcept {
return 0;
}
};
int main() {
std::unordered_set<my_class<char>> x;
}
This code, when compiled with g++ -std=c++20 -fmodules-ts test.cpp produces this error:
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\SOURAV~1\AppData\Local\Temp\cclOkCUA.o:test.cpp:(.text$_ZNSt16allocator_traitsISaIPNSt8__detail15_Hash_node_baseEEE10deallocateERS3_PS2_y[_ZNSt16allocator_traitsISaIPNSt8__detail15_Hash_node_baseEEE10deallocateERS3_PS2_y]+0x2d): undefined reference to `std::is_constant_evaluated()'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\SOURAV~1\AppData\Local\Temp\cclOkCUA.o:test.cpp:(.text$_ZNSt16allocator_traitsISaINSt8__detail10_Hash_nodeI8my_classIcELb0EEEEE10deallocateERS5_PS4_y[_ZNSt16allocator_traitsISaINSt8__detail10_Hash_nodeI8my_classIcELb0EEEEE10deallocateERS5_PS4_y]+0x2d): undefined reference to `std::is_constant_evaluated()'
collect2.exe: error: ld returned 1 exit status
Instead if I define template argument directly in hash struct, there is no error!
template<>
struct std::hash<my_class<char>> {
std::size_t operator()(my_class<char> const &s) const noexcept {
return 0;
}
};
I am confused what is the error!
I think it is just some bug in GCC modules implementation as suggested by #ildjarn in comments.
I was able to get rid of error by adding this line in the source code:
constexpr bool std::is_constant_evaluated() noexcept;
But I'm not sure what exactly was wrong or why did adding this solved the error.

Template c++ compiler differences VC++ different output

I had written some c++ code in Visual Studio and was trying to run it on my c++ code on a linux server. When I tried to compile it with G++ however, it failed to compile with tons of errors. I looked through the error and was able to simplify the problem to this:
template<int x>
struct Struct
{
template<int y>
static void F()
{
//Struct<x>::F<0>(); // compiles
//Struct<y>::G(); // compiles
Struct<y>::F<0>(); // does not compile?
}
static void G()
{
}
};
int main ()
{
Struct<0>::F<0>();
}
On Visual Studio this code compiles just fine but on G++ or Clang++, it fails to compile. Errors on G++ 8.3.0:
test.cpp: In static member function ‘static void Struct<x>::F()’:
test.cpp:9:19: error: expected primary-expression before ‘)’ token
Struct<y>::F<0>(); // does not compile?
^
test.cpp: In instantiation of ‘static void Struct<x>::F() [with int y = 0; int x = 0]’:
test.cpp:19:18: required from here
test.cpp:9:15: error: invalid operands of types ‘<unresolved overloaded function type>’ and ‘int’ to binary ‘operator<’
Struct<y>::F<0>(); // does not compile?
Errors on Clang++:
5691311/source.cpp:9:19: error: expected expression
Struct<y>::F<0>(); // does not compile?
^
See it live: https://rextester.com/AAL19278
You can change the compiler and copy the code to see the different errors.
Is there anyway I could get around this problem so that my code will compile on G++ or Clang++?
Original Code:
template<int x, int y>
ThisType add()
{
return ThisType::Create(this->x() + x, this->y() + y);
}
ResultPos to = p.add<0, 1>();
template<int x>
struct Struct
{
template<int y>
static void F()
{
Struct<y>::F<0>(); // does not compile?
}
};
should not compile. You need to specify for the compiler that F in fact requires a template list, since F is a dependent template type. Otherwise the compiler will assume that the next < is a smaller than.
template<int x>
struct Struct
{
template<int y>
static void F()
{
Struct<y>::template F<0>();
}
};
I assume Struct<x>::F<0> works, since the compiler already knows that the current type is Struct<x>, but it cannot know that y is the same as xin this case.

Segmentation fault on gcc caused by lambda wrapper over variadic template function call

I've spent quite a few hours today trying to understand why this code segfaults on g++6.2 and g++7.0, while happily working as intended on clang++3.9 (and 4.0).
I reduced the issue to a 85 lines self-contained code snippet, which does not segfault upon normal execution, but always reports an error under UBSAN.
The issue is reproducible on wandbox, by compiling with g++7, enabling optimizations and passing -fsanitize=undefined as an extra flag.
This is what UBSAN reports:
prog.cc: In function 'int main()':
prog.cc:61:49: warning: 'ns#0' is used uninitialized in this function [-Wuninitialized]
([&] { ([&] { n.execute(ns...); })(); })();
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
prog.cc:28:10: note: 'ns#0' was declared here
auto execute(TNode& n, TNodes&... ns)
^~~~~~~
prog.cc:30:9: runtime error: member call on null pointer of type 'struct node_then'
g++ claims that ns#0 is uninitialized inside the "lambda gibberish" (which simulates the for_tuple from the original snippet). Now, some very interesting things occur:
If I remove the "lambda gibberish", transforming line 61 into
n.execute(ns...);
then UBSAN stops complaining.
If I change the capture list from [&] to [&n, &ns...], UBSAN stops complaining as well:
([&](auto) { ([&n, &ns...] { n.execute(ns...); })(); })(0);
...wait what? How is that different from [&]?
Applying the above discoveries to the original code snippet fixes the segfaults.
Is this a g++ bug? Or is there any undefined behavior in my code?
This has nothing to do with temporaries: it's a gcc7.0 optimizer bug. This is a simpler reproducer:
#include <utility>
struct root
{
template <typename TNode, typename... TNodes>
void start(TNode n, TNodes... ns)
{
n->execute(ns...);
}
};
template <typename TParent>
struct node_then
{
TParent *_p;
node_then(TParent *p) : _p{ p }
{
}
auto execute()
{
}
template <typename TNode, typename... TNodes>
auto execute(TNode n, TNodes... ns)
{
n->execute(ns...);
}
template <typename... TNodes>
auto start(TNodes... ns)
{
_p->start(this, ns...);
}
};
template <typename TParent>
struct node_wait_all
{
TParent *_p;
node_wait_all(TParent *p) : _p{ p }
{
}
template <typename TNode, typename... TNodes>
auto execute(TNode n, TNodes... ns)
{
([&] { ([&] { n->execute(ns...); })(); })();
}
template <typename... TNodes>
auto start(TNodes... ns)
{
_p->start(this, ns...);
}
};
int main()
{
//node_wait_all<root> obj(new root());
//node_then<node_wait_all<root>> obj2(new node_wait_all<root>(new root()));
node_then<node_then<node_wait_all<root>>> obj3(new node_then<node_wait_all<root>>(new node_wait_all<root>(new root())));
obj3.start();
}
Output:
prog.cc: In function 'int main()':
prog.cc:67:1: internal compiler error: in visit_ref_for_mod_analysis, at ipa-prop.c:2308
}
^
0x96c4d6 visit_ref_for_mod_analysis
/home/heads/gcc/gcc-source/gcc/ipa-prop.c:2308
0x8f615d walk_stmt_load_store_addr_ops(gimple*, void*, bool (*)(gimple*, tree_node*, tree_node*, void*), bool (*)(gimple*, tree_node*, tree_node*, void*), bool (*)(gimple*, tree_node*, tree_node*, void*))
/home/heads/gcc/gcc-source/gcc/gimple-walk.c:817
0x9761a2 ipa_analyze_params_uses_in_bb
/home/heads/gcc/gcc-source/gcc/ipa-prop.c:2335
0x9761a2 analysis_dom_walker::before_dom_children(basic_block_def*)
/home/heads/gcc/gcc-source/gcc/ipa-prop.c:2415
0x10c8472 dom_walker::walk(basic_block_def*)
/home/heads/gcc/gcc-source/gcc/domwalk.c:265
0x977ceb ipa_analyze_node(cgraph_node*)
/home/heads/gcc/gcc-source/gcc/ipa-prop.c:2486
0x1108f0a ipcp_generate_summary
/home/heads/gcc/gcc-source/gcc/ipa-cp.c:5036
0xa4759c execute_ipa_summary_passes(ipa_opt_pass_d*)
/home/heads/gcc/gcc-source/gcc/passes.c:2167
0x7d6b45 ipa_passes
/home/heads/gcc/gcc-source/gcc/cgraphunit.c:2311
0x7d6b45 symbol_table::compile()
/home/heads/gcc/gcc-source/gcc/cgraphunit.c:2425
0x7d8616 symbol_table::compile()
/home/heads/gcc/gcc-source/gcc/cgraphunit.c:2587
0x7d8616 symbol_table::finalize_compilation_unit()
/home/heads/gcc/gcc-source/gcc/cgraphunit.c:2584
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
Link: http://melpon.org/wandbox/permlink/E11fOumFJda6OW6m
To aid in this code's comprehension I'm using a powerful debugging tool: paint.exe

How does this one template compile while this other one gives a syntax error?

I have this template that compiles successfully with g++. When I remove a seemingly irrelevant function, it results in a syntax error.
Exhibit 1: This compiles successfully. Note that this is the only content of the file; the template is not instantiated.
template<typename T> struct aaa {
void w() {
T x;
x.goo<5>();
}
template<float***, char> void goo() {
}
};
Exhibit 2: The following results in a syntax error.
template<typename T> struct aaa {
void w() {
T x;
x.goo<5>();
}
};
The error is
aoeu.cpp: In member function 'void aaa<T>::w()':
aoeu.cpp:6:18: error: expected primary-expression before ')' token
x.goo<5>();
I tried this using GCC 4.8 and 5.2 with the same result. How does the presence of void goo influence whether the line x.goo<5>(); generates an error?

Possible gcc bug with C++14 polymorphic lambdas?

I've found a strange behavior using polymorphic C++14 lambdas (lambdas with auto in their parameters):
Snippet 0:
#include <iostream>
template<typename T> void doLambda(T&& mFn)
{
std::forward<T>(mFn)(int{0});
}
template<typename T> void test(T&& mV)
{
doLambda([&mV](auto mE)
{
std::forward<decltype(mV)>(mV);
});
}
int main() { test(int{0}); return 0; }
clang++ 3.5.1: the snippet compiles and runs successfully.
g++ 4.9.2: the snippet fails to compile:
example.cpp: In instantiation of 'test(T&&)::<lambda(auto:1)> [with auto:1 = int; T = int]':
5 : required from 'void doLambda(T&&) [with T = test(T&&) [with T = int]::]'
13 : required from 'void test(T&&) [with T = int]'
18 : required from here
12 : error: 'mV' was not declared in this scope
std::forward<decltype(mV)>(mV);
^
Compilation failed
Snippet 1:
The only difference from snippet 0 is that the auto inside the lambda was replaced to int.
#include <iostream>
template<typename T> void doLambda(T&& mFn)
{
std::forward<T>(mFn)(int{0});
}
template<typename T> void test(T&& mV)
{
doLambda([&mV](int mE)
{
std::forward<decltype(mV)>(mV);
});
}
int main() { test(int{0}); return 0; }
clang++ 3.5.1: the snippet compiles and runs successfully.
g++ 4.9.2: the snippet compiles and runs successfully.
Snippet 3:
The lambda is now called in-place. auto is still used.
#include <iostream>
template<typename T> void test(T&& mV)
{
[&mV](auto mE)
{
std::forward<decltype(mV)>(mV);
}(int{0});
}
int main() { test(int{0}); return 0; }
clang++ 3.5.1: the snippet compiles and runs successfully.
g++ 4.9.2: the snippet compiles and runs successfully.
Why is g++ complaining about snippet 0? Is there anything wrong in my code? Is this a known bug or should I submit this?
As stated in the comments, this behavior is indeed a gcc bug.