create two Twine object

Project Infrastructure LLVM Dev List Archives
1

I need to generate variables like

status1, status2, status3, …
request1, request2, request3, …

this is my code, other unrelated detail are eliminated.

static int varNum;

static const char *getVarNum() {
++varNum;
std::stringstream ss;
ss << varNum;
std::string *varname = new std::string(ss.str());
return varname->c_str();
}

const char *VarNum = getVarNum();

Twine *x1 = new Twine(StringRef(“status”), VarNum); // 1
Twine *x2 = new Twine(StringRef(“request”), VarNum); // 2

Instruction *sstatusInst = new AllocaInst(StatusTy, *x1, entry_inst); // 3
Instruction *sreqInst = new AllocaInst(ReqTy, *x2, entry_inst); // 4

with only 1&3, my code works well, I can have status1, status2, status3, …

with 1&2&3&4 exists at the same time, it compiles without problem, but
segmentation fault happens.

Instruction *sreqInst = new AllocaInst(ReqTy, “request”, entry_inst); // 5
with 1&2&3&5, everything work, but that’s not what I want.

I really can’t figure out what is broken. I create everything new on the heap.
Each alloca inst with its own Twine object on the heap. Could anyone help me
out? Thanks a lot.

yuanfang

2

This is the error:

0 opt 0x087e59ee
1 opt 0x087e5863
2 0x00a49400 __kernel_sigreturn + 0
3 opt 0x083bdd0b llvm::PATypeHolder::operator llvm::Type*() const + 29
4 opt 0x083bddb6 llvm::Value::getType() const + 32
5 opt 0x08725e33 llvm::CallInst::init(llvm::Value*, llvm::Value* const*, unsigned int) + 313
6 opt 0x083d7c4c void llvm::CallInst::init<__gnu_cxx::__normal_iterator<llvm::Value**, std::vector<llvm::Value*, std::allocatorllvm::Value* > > >(llvm::Value*, __gnu_cxx::__normal_iterator<llvm::Value**, std::vector<llvm::Value*, std::allocatorllvm::Value* > >, __gnu_cxx::__normal_iterator<llvm::Value**, std::vector<llvm::Value*, std::allocatorllvm::Value* > >, llvm::Twine const&, std::random_access_iterator_tag) + 92
7 opt 0x083d6c46 llvm::CallInst::CallInst<__gnu_cxx::__normal_iterator<llvm::Value**, std::vector<llvm::Value*, std::allocatorllvm::Value* > > >(llvm::Value*, __gnu_cxx::__normal_iterator<llvm::Value**, std::vector<llvm::Value*, std::allocatorllvm::Value* > >, __gnu_cxx::__normal_iterator<llvm::Value**, std::vector<llvm::Value*, std::allocatorllvm::Value* > >, llvm::Twine const&, llvm::Instruction*) + 266
8 opt 0x083d5ed3 llvm::CallInst* llvm::CallInst::Create<__gnu_cxx::__normal_iterator<llvm::Value**, std::vector<llvm::Value*, std::allocatorllvm::Value* > > >(llvm::Value*, __gnu_cxx::__normal_iterator<llvm::Value**, std::vector<llvm::Value*, std::allocatorllvm::Value* > >, __gnu_cxx::__normal_iterator<llvm::Value**, std::vector<llvm::Value*, std::allocatorllvm::Value* > >, llvm::Twine const&, llvm::Instruction*) + 103
9 LLVMMpiAware.so 0x0011b842
10 LLVMMpiAware.so 0x0011b22e
11 opt 0x0875ad26 llvm::MPPassManager::runOnModule(llvm::Module&) + 388
12 opt 0x0875b212 llvm::PassManagerImpl::run(llvm::Module&) + 122
13 opt 0x0875b4f7 llvm::PassManager::run(llvm::Module&) + 39
14 opt 0x083b108b main + 3303
15 libc.so.6 0x005e0b56 __libc_start_main + 230
16 opt 0x083a2bd1
Stack dump:
0. Program arguments: opt -load …/…/…/Debug/lib/LLVMMpiAware.so -mpiaware

  1. Running pass ‘MPI Aware Pass’ on module ‘’.
    Segmentation fault
3

This is dangerously wrong; the Twines end up with a dangling pointer
to an implicitly constructed StringRef. Try using a SmallString
instead.

-Eli

4

According to documentation Twines should be used only for temporary
values and not stored, so allocating the in heap sounds wrong.
I think all you need here is

static int varNum;

++varNum;
Instruction *sstatusInst = new AllocaInst(StatusTy, Twine("status") +
Twine(varNum), entry_inst);
Instruction *sreqInst = new AllocaInst(ReqTy, Twine("request") +
Twine(varNum), entry_inst);

btw, your getVarNum() leaks.

Eugene

5

According to documentation Twines should be used only for temporary
values and not stored, so allocating the in heap sounds wrong.

Yes, in general you should never be naming Twine directly, except in
the case where you need to make a Twine for an integer. All other uses
should be considered poor style, as they are dangerously subtle.

- Daniel

6

thank you guys. I see what the problem is now.

yuanfang