When I am trying to run the following code
#include<bits/stdc++.h>
using namespace std;
int main()
{
int n;
cin>>n;
vector<vector<int>> v(n, vector<int>(2));
cout<<2<<"\n";
return 0;
}
using the command g++ file.cpp then it is giving the following error
0 0x1022a41a0 __assert_rtn + 140
1 0x10212ba8c mach_o::relocatable::Parser<arm64>::parse(mach_o::relocatable::ParserOptions const&) + 4536
2 0x1020fdd38 mach_o::relocatable::Parser<arm64>::parse(unsigned char const*, unsigned long long, char const*, long, ld::File::Ordinal, mach_o::relocatable::ParserOptions const&) + 148
3 0x1021664ac ld::tool::InputFiles::makeFile(Options::FileInfo const&, bool) + 1468
4 0x102169360 ___ZN2ld4tool10InputFilesC2ER7Options_block_invoke + 56
5 0x1c17b41f4 _dispatch_client_callout2 + 20
6 0x1c17c8f8c _dispatch_apply_invoke_and_wait + 224
7 0x1c17c826c _dispatch_apply_with_attr_f + 1152
8 0x1c17c847c dispatch_apply + 108
9 0x1021691f4 ld::tool::InputFiles::InputFiles(Options&) + 616
10 0x1020eb6c0 main + 552
A linker snapshot was created at:
/tmp/a.out-2022-09-19-011653.ld-snapshot
ld: Assertion failed: (_file->_atomsArrayCount == computedAtomCount && "more atoms allocated than expected"), function parse, file macho_relocatable_file.cpp, line 2061.
collect2: error: ld returned 1 exit status
Related
Im having issues with a class constructors that i define. my .cpp's and .h compile on there own but once i try to use them in a main and construct a class it throws errors.
ive read about how not properly defining a user created constructor may cause the same error but im positive that everything is correct.
joust.cpp
#include "joust.h"
2 //create class construct for knight class
3 //set his name stam and put him on a horse
4 knight::knight (string n) : equipped_wep(5,5,"Basic Blade"){
5 name = n;
6 stamina = 100;
7 mounted = true;
8 }
9
10 void knight::show_stats() {
11 if (stamina) {
12 cout << name << " is not exhausted (stamina="<< stamina<< ") and is moun ted" << endl;
13 } else {
14 cout << name << " has passed out from exhaustion" << endl;
15 }
16 }
17 void knight::show_wep() {
18 cout << name << " is using " << equipped_wep.display_wep() << endl;
19 }
20
21 void knight::equip_weapon(weapon wep) {
22 equipped_wep = wep;
joust.h
13 #ifndef JOUST_H
14 #define JOUST_H
15
16 #include <iostream>
17 #include <fstream>
18 #include <vector>
19
20 using namespace std;
21
22 class weapon {
23 public:
24 weapon(float = 1, float = 1, string = "base");
25 void set(float, float);
26 string display_wep();
27 private:
28 float effectivness;
29 float weight;
30 string name;
31 };
32
33 class knight {
34 public:
35 knight( string = "base");
36 void show_stats();
37 void show_wep();
38 void equip_weapon(weapon wep);
39 private:
40 weapon equipped_wep;
41 string name;
42 int stamina;
43 bool mounted;
44 };
45
46
47 #endif
test.cpp
#include "joust.h"
2
3 int main() {
4 //knight jim("Rob the Third");
5 //jim.show_stats();
6 weapon c(15,12,"jard");
7
8 return 0;
9 }
makefile
test: test.o joust.o
2 g++ -std=c++11 joust.o test.o -o test
3 test.o: test.cpp joust.h
4 g++ -std=c++11 test.cpp
5 joust.o: joust.cpp joust.h
6 g++ -std=c++11 -c joust.cpp
7 clean:
8 rm -f joust.o
It should of just created a weapon object bust instead threw this error
make
g++ -std=c++11 test.cpp
Undefined symbols for architecture x86_64:
"weapon::weapon(float, float, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >)", referenced from:
_main in test-501f47.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [test.o] Error 1
There are two problems that you have:
First you need to build all source file together, or to create object files from each source file that you then link together.
The second error is that you don't define (implement) the weapon constructor anywhere.
The first problem is solved by adding the -c flag when building the source files. The -c flags tells GCC to create object files (the files ending in .o). You have it when building the joust.cpp source file, but seem to have forgotten it for the test.cpp source file.
The second problem should be pretty obvious how to solve: Implement the constructor function.
I have a cross platform console application. The purpose of it is to transfer data between two peers. Sometimes packets received are not complete so we append the data into a string while the complete packet has been arrived. But it get crashed in appending data in string after sometime. Here is the back tarce -
1 libsystem_c.dylib 0x93b77acf pthread_kill + 101
2 libsystem_c.dylib 0x93bae4f8 abort + 168
3 libc++abi.dylib 0x9698180c abort_message + 151
4 libc++abi.dylib 0x9697f275 default_terminate() + 34
5 libc++abi.dylib 0x9697f2b5 safe_handler_caller(void (*)()) + 13
6 libc++abi.dylib 0x9697f31d std::terminate() + 23
7 libc++abi.dylib 0x96980412 __cxa_throw + 110
8 libstdc++.6.dylib 0x90e23d6c std::__throw_length_error(char const*) + 104
9 libstdc++.6.dylib 0x90e4f3a9 std::string::append(char const*, unsigned long) + 175
10 libConnector.dylib 0x13905228 ConnectionSocket::AdjustPartialData(char const*, int)
14 libConnector.dylib 0x1383e0b6 ConnectionChannel::ProcessData(int, void const*, int, char*, int) + 7886
15 libConnector.dylib 0x13861ecb ConnectionManager::BaseThreadImpl() + 1185
16 libConnector.dylib 0x13861a23 ConnectionManager::BaseThread(void*) + 17
17 libsystem_c.dylib 0x93b76557 _pthread_start + 344
18 libsystem_c.dylib 0x93b60cee thread_start + 34
Can someone give any idea about this issue?
EXAMPLE CODE:
AdjustPartialData(char* const pData, int dataLen)
{
if (true == packetIncomplete)
{
partialDataBuffer.append(pData, dataLen); // crash occurs in this line
}
}
if partialDataBuffer.size() + dataLen > partialDataBuffer.max_size() then append throws a length_error (http://en.cppreference.com/w/cpp/string/basic_string/append)
Either partialDataBuffer or dataLen are too big.
Finally I have resolved the issue by discarding the extra data which causes the overflow. Previously I thought this will not be feasible solution as it could lead to possible data loss. But I found that TCP stream size shouldn't be greater than 65535 which is 16 bit. But found another issue when the following condition added -
if(partialDataBuffer.size() + dataLen >= partialDataBuffer.max_size())
{
// do not append data
}
else partialDataBuffer.append(pData, dataLen);
The issue was in windows platform it always crashes even though size of partialDataBuffer is much less than partialDataBuffer.max_size(). So, for resolving this issue I have done the following -
try{
partialDataBuffer.append(pData, dataLen);
}
catch(...)
{
// got exception, return
}
And it worked fine for me.
N.B: I have posted my answer because it will be helpful for others who are facing similar issue.
I'm trying a very simple example with LLVM/clang and seem to fail.
I try the following:
clang++ -emit-llvm -c -x c++ -o main.bc -isystem include/ main.cc
clang++ -emit-llvm -c -x c++ -o test_class.bc -isystem include/ test_class.cc
llvm-link main.bc test_class.bc -o all.bc
lli all.bc
However, 4. fails (segfaults) with:
0 libLLVM-3.3.so 0x0000003b890f9e52 llvm::sys::PrintStackTrace(_IO_FILE*) + 34
1 libLLVM-3.3.so 0x0000003b890f9cb9
2 libpthread.so.0 0x0000003b8520efa0
3 libLLVM-3.3.so 0x0000003b89982790 llvm::MachineJumpTableInfo::getEntrySize(llvm::DataLayout const&) const + 0
4 libLLVM-3.3.so 0x0000003b894bfb23
5 libLLVM-3.3.so 0x0000003b894c8dc3
6 libLLVM-3.3.so 0x0000003b8981b27f
7 libLLVM-3.3.so 0x0000003b8969d2d6 llvm::FPPassManager::runOnFunction(llvm::Function&) + 422
8 libLLVM-3.3.so 0x0000003b8969d3f6 llvm::FunctionPassManagerImpl::run(llvm::Function&) + 102
9 libLLVM-3.3.so 0x0000003b8969d4cb llvm::FunctionPassManager::run(llvm::Function&) + 91
10 libLLVM-3.3.so 0x0000003b894b3264 llvm::JIT::jitTheFunction(llvm::Function*, llvm::MutexGuard const&) + 36
11 libLLVM-3.3.so 0x0000003b894b394f llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) + 15
12 libLLVM-3.3.so 0x0000003b894b3b7e llvm::JIT::getPointerToFunction(llvm::Function*) + 254
13 libLLVM-3.3.so 0x0000003b894c6649
14 libLLVM-3.3.so 0x0000003b894c909c
15 libLLVM-3.3.so 0x0000003b8981b27f
16 libLLVM-3.3.so 0x0000003b8969d2d6 llvm::FPPassManager::runOnFunction(llvm::Function&) + 422
17 libLLVM-3.3.so 0x0000003b8969d3f6 llvm::FunctionPassManagerImpl::run(llvm::Function&) + 102
18 libLLVM-3.3.so 0x0000003b8969d4cb llvm::FunctionPassManager::run(llvm::Function&) + 91
19 libLLVM-3.3.so 0x0000003b894b3264 llvm::JIT::jitTheFunction(llvm::Function*, llvm::MutexGuard const&) + 36
20 libLLVM-3.3.so 0x0000003b894b394f llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) + 15
21 libLLVM-3.3.so 0x0000003b894b3b7e llvm::JIT::getPointerToFunction(llvm::Function*) + 254
22 lli 0x00000000004073cf main + 2527
23 libc.so.6 0x0000003b84621b75 __libc_start_main + 245
24 lli 0x000000000040a271
Stack dump:
0. Program arguments: lli all.bc
1. Running pass 'X86 Machine Code Emitter' on function '#main'
2. Running pass 'X86 Machine Code Emitter' on function '#_ZN10test_classC2ESs'
[1] 15327 segmentation fault (core dumped) lli all.bc
Do I have a fundamental missunderstanding on how this is supposed to work? My ultimate goal is to do the compilation
part using the libclang API, but for now understanding what I do wrong here would be awesome! Thanks!
I attached the source code for the example below:
include/test_class.h:
#ifndef __TEST_CLASS_H__
#define __TEST_CLASS_H__
#include <string>
#include <iostream>
struct test_class
{
test_class(std::string foo);
~test_class();
std::string foo;
};
#endif
test_class.cc:
#include <test_class.h>
test_class::test_class(std::string foo) : foo(foo)
{
std::cout << foo << std::endl;
}
test_class::~test_class(void)
{
}
main.cc:
#include <cstdlib>
#include <string>
#include <iostream>
#include <test_class.h>
int main(int argc, char** argv)
{
test_class test("foo");
return EXIT_SUCCESS;
}
In test_class you refer to std::string. I guess, calls to related functions are marked external if you have a look into the IR (eg: llvm-dis < all.bc).
If you compile to "normal" executable code, these calls are resolved by the linker.
Since you link manually with llvm-link you will have to provide IR-code for the C++ libraries, otherwise execution might fail.
I am getting this error
> clang -std=c99 -c derivative.c -o derivative.a
fatal error: error in backend: Cannot select: intrinsic %llvm.spu.si.sf
when I try to compile this simple C program with Clang
#include <stdio.h>
#include <math.h>
int N = 100;
double H = 0.001;
double PI = 3.14159265;
void derive(double* input, long elements, double* output) {
for (int i = 1; i < elements - 1; i++) {
output[i - 1] = (input[i + 1] - input[i - 1])/ (2 * H);
}
}
int main() {
double f[N];
double f_prime[N - 2];
for (int i = 0; i < N; i++) {
f[i] = sin(i * 2 * PI / (double)N);
}
derive(f, N, f_prime);
for (int i = 0; i < N - 2; i++) {
printf("%f %f\n", i * 2 * PI / (double)N, f_prime[i]);
}
}
I already searched the Internet, but was not (yet) able to find a solution.
When I compile to Bitcode, it compiles but the execution dumps core.
> clang -emit-llvm -c derivative.c -o derivative.bc
> lli derivative.bc
lli: BitcodeReader.cpp:283: llvm::Value* llvm::BitcodeReaderValueList::getValueFwdRef(unsigned int, llvm::Type*): Assertion `(Ty == 0 || Ty == V->getType()) && "Type mismatch in value table!"' failed.
0 lli 0x0000000000c6fb02
1 lli 0x0000000000c6ff93
2 libpthread.so.0 0x00007f304d7dbbd0
3 libc.so.6 0x00007f304ca19037 gsignal + 55
4 libc.so.6 0x00007f304ca1c698 abort + 328
5 libc.so.6 0x00007f304ca11e03
6 libc.so.6 0x00007f304ca11eb2
7 lli 0x000000000052eeb0 llvm::BitcodeReaderValueList::getConstantFwdRef(unsigned int, llvm::Type*) + 0
8 lli 0x0000000000538943 llvm::BitcodeReader::ParseFunctionBody(llvm::Function*) + 10275
9 lli 0x000000000053acb1 llvm::BitcodeReader::Materialize(llvm::GlobalValue*, std::string*) + 241
10 lli 0x0000000000535195 llvm::BitcodeReader::MaterializeModule(llvm::Module*, std::string*) + 85
11 lli 0x0000000000c0a82f llvm::Module::MaterializeAllPermanently(std::string*) + 31
12 lli 0x00000000005360fc llvm::ParseBitcodeFile(llvm::MemoryBuffer*, llvm::LLVMContext&, std::string*) + 44
13 lli 0x00000000004f70b7
14 lli 0x00000000004e74f3 main + 339
15 libc.so.6 0x00007f304ca03ea5 __libc_start_main + 245
16 lli 0x00000000004f0f41
Stack dump:
0. Program arguments: lli derivative.bc
Aborted (core dumped)
Trying llvm-dis on the bc-file yields an almost identical core dump.
EDIT:
I tried to find the minimal failing example, and it seems, the problem is defining the array size via the constant.
this fails:
int main() {
int N = 100;
double f[N];
}
this works:
int main() {
double f[100];
}
EDIT2:
Changing int N = 100 to const int N = 100 makes the program compile with Clang.
It makes sense that the variable should be const, but on the other hand, gcc -std=c99 -Wall derivative.c -lm does not complain if it is not const.
This is ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/llvm-3.2/+bug/1131614. Looks like they patched llvm+clang blindly, without understanding what they are doing.
The fatal error message is an indication you have discovered a bug in the compiler. Try reporting the bug at llvm.org/bugs.
While trying to compile an LLVM IR, like this
llc main.ll -o main.s && g++ main.s -O3 -o main -pthread
I get the following error. The same thing compiles on my Ubuntu 10 system, but in the CentOS I get the following error. Any idea what is going on here and why LLVM is going mad? And lastly, how to solve this?
llc: /home/schism/llvm/include/llvm/ADT/IntervalMap.h:606: unsigned int llvm::IntervalMapImpl::LeafNode< <template-parameter-1-1>, <template-parameter-1-2>, <anonymous>, <template-parameter-1-4> >::insertFrom(unsigned int&, unsigned int, KeyT, KeyT, ValT) [with KeyT = llvm::SlotIndex, ValT = unsigned int, unsigned int N = 9u, Traits = llvm::IntervalMapInfo<llvm::SlotIndex>]: Assertion `!Traits::stopLess(b, a) && "Invalid interval"' failed.
0 llc 0x0000000000d5009f
1 llc 0x0000000000d50db7
2 libpthread.so.0 0x0000003cfde0ebe0
3 libc.so.6 0x0000003cfce30285 gsignal + 53
4 libc.so.6 0x0000003cfce31d30 abort + 272
5 libc.so.6 0x0000003cfce29706 __assert_fail + 246
6 llc 0x000000000093624c llvm::IntervalMapImpl::LeafNode<llvm::SlotIndex, unsigned int, 9u, llvm::IntervalMapInfo<llvm::SlotIndex> >::insertFrom(unsigned int&, unsigned int, llvm::SlotIndex, llvm::SlotIndex, unsigned int) + 716
7 llc 0x0000000000936a00
8 llc 0x0000000000929898 llvm::SplitEditor::useIntv(llvm::SlotIndex, llvm::SlotIndex) + 88
9 llc 0x000000000092f369 llvm::SplitEditor::splitRegInBlock(llvm::SplitAnalysis::BlockInfo const&, unsigned int, llvm::SlotIndex) + 1513
10 llc 0x00000000008c20ea
11 llc 0x00000000008c3c78
12 llc 0x00000000008c90d1
13 llc 0x00000000008c95ab
14 llc 0x0000000000a06c84 llvm::RegAllocBase::allocatePhysRegs() + 324
15 llc 0x00000000008c4edc
16 llc 0x0000000000880005 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 53
17 llc 0x0000000000ce4c66 llvm::FPPassManager::runOnFunction(llvm::Function&) + 646
18 llc 0x0000000000ce4cfd llvm::FPPassManager::runOnModule(llvm::Module&) + 45
19 llc 0x0000000000ce641c llvm::MPPassManager::runOnModule(llvm::Module&) + 556
20 llc 0x0000000000ce657e llvm::PassManagerImpl::run(llvm::Module&) + 174
21 llc 0x0000000000ce66dd llvm::PassManager::run(llvm::Module&) + 13
22 llc 0x00000000004d0f1b main + 5451
23 libc.so.6 0x0000003cfce1d994 __libc_start_main + 244
24 llc 0x00000000004ce8e9
Stack dump:
0. Program arguments: llc main.ll -o main.s
1. Running pass 'Function Pass Manager' on module 'main.ll'.
2. Running pass 'Greedy Register Allocator' on function '#_Z7InitSimPKcj'
Aborted
Looks like LLVM is miscompiled by your system compiler. See http://llvm.org/docs/GettingStarted.html#brokengcc for a list of known broken compilers.
The solution is simple - use other version of the compiler (gcc in your case) to compile LLVM.
There's a similar problem to this floating around here somewhere. Answer was to check the versions of gcc and llvm. Turned out one was 32 bit the other 64 bit. ymmv.