llvm dev - Apr 2016 - Problems with GEP and CallInst

I got a little problems with strings (const char pointers). Global variables
holding the string literal are declared correctly, but i have a problem when I
pass this string to a function: it asserts with this message.

Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) ==
Args[i]->getType()) && "Calling a function with a bad
signature!"), function init, file llvm-3.8.0.src/lib/IR/Instructions.cpp,
line 245.

Function declaration in the IR:
; Function Attrs: nounwind ssp uwtable
declare i32 @_wrts(i8*) #0

All the types match (even if the assertion condition makes me think they
shouldn’t), am I doing something wrong with GEP?
here’s the code that translates the AST Literal into LLVM IR and creates the GEP
(the return value will be passed to the Callee):

llvm::Value *ast::StringLiteral::build(llvmir_builder *builder) {
    TypeRef *strtype = evalType();
    TypeRef *chrtype = strtype->getType()->getPointedType();
    llvm::ArrayType *arty = llvm::ArrayType::get(chrtype->getIRType(),
val.length()+1);
    if (!strcst) {
        strcst = new llvm::GlobalVariable(*container,
                                          arty,
                                          true,
                                          llvm::GlobalValue::PrivateLinkage,
                                         
llvm::ConstantDataArray::getString(container->getContext(), val.c_str()),
                                          ".str");
        strcst->setUnnamedAddr(true);
        strcst->setAlignment(chrtype->getByteSize());
    }
    return builder->CreateInBoundsGEP(arty, strcst,
llvm::ConstantInt::get(llvm::Type::getInt8Ty(container->getContext()), 0));
}


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160417/f5a4df11/attachment.html>

On 17 April 2016 at 05:52, Lorenzo Laneve via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>     return builder->CreateInBoundsGEP(arty, strcst,
> llvm::ConstantInt::get(llvm::Type::getInt8Ty(container->getContext()),
0));
@strcst has type "[N x i8]*" so this "getelemntptr @strcst, i8
0" has
type "[N x i8]*" too (the first index is sort of special in GEPs. What
you want is "getelemntptr @strcst, i32 0, i32 0" which has type i8*.
Something like "builder->CreateInBoundsGEP2_32(arty, strcst, 0, 0)"
is
probably the simplest way to get it.

If you haven't seen it already,
http://llvm.org/docs/GetElementPtr.html is a good introduction to GEP.
The other usual advice is to check what Clang outputs for something
equivalent in C or C++. It's also often easier to fiddle around with
tiny .ll test-cases than implement everything in C++ from the start.

Cheers.

Tim.

Oh thanks, seeing clang's output is actually what I'm doing to see how
it generates the IR, so I try to do the same thing for my lang.
The problem is I don't know exactly what C++ method generates what IR
statement.

So [N x i8]* != i8* in IR? Good to know it
Now it works perfectly.

Another little issue is that Clang is givin me a warning saying that in
llvm/IR/Type.h there's llvm::Type::getSequentialElementType() which is
inline and not defined.
> On Apr 17, 2016, at 4:47 PM, Tim Northover <t.p.northover at
gmail.com> wrote:
> 
> On 17 April 2016 at 05:52, Lorenzo Laneve via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>>    return builder->CreateInBoundsGEP(arty, strcst,
>>
llvm::ConstantInt::get(llvm::Type::getInt8Ty(container->getContext()), 0));
> 
> @strcst has type "[N x i8]*" so this "getelemntptr @strcst,
i8 0" has
> type "[N x i8]*" too (the first index is sort of special in GEPs.
What
> you want is "getelemntptr @strcst, i32 0, i32 0" which has type
i8*.
> Something like "builder->CreateInBoundsGEP2_32(arty, strcst, 0,
0)" is
> probably the simplest way to get it.
> 
> If you haven't seen it already,
> http://llvm.org/docs/GetElementPtr.html is a good introduction to GEP.
> The other usual advice is to check what Clang outputs for something
> equivalent in C or C++. It's also often easier to fiddle around with
> tiny .ll test-cases than implement everything in C++ from the start.
> 
> Cheers.
> 
> Tim.