search for: callconvwrong

I too have stumbled over this. Wouldn't it be a good idea to add a check for this to the function verifier pass? Hans Anton Korobeynikov wrote: > Hello > >> I naively though it would pick up the call convention from the declaration >> as there was no error like we have when the wrong number of parameters is >> used. > This is not an error, you're just

Hans Wennborg wrote: > I too have stumbled over this. > > Wouldn't it be a good idea to add a check for this to the function > verifier pass? No. This is a FAQ: http://llvm.org/docs/FAQ.html#callconvwrong Nick > > > Hans > > Anton Korobeynikov wrote: >> Hello >> >>> I naively though it would pick up the call convention from the declaration >>> as there was no error like we have when the wrong number of parameters is >>> used. >> This is n...

...9 at 12:21 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Hans Wennborg wrote: >> I too have stumbled over this. >> >> Wouldn't it be a good idea to add a check for this to the function >> verifier pass? > > No. This is a FAQ: http://llvm.org/docs/FAQ.html#callconvwrong IMO you could move the cc to the type and still replace mismatched calls with unreachable. Are there other design considerations for not doing this? Reid

...9;re running with assertions off). Further, there are semantics of the program that the verifier will never verify. It is undefined behaviour to shift beyond the width of an integer. It is undefined behaviour to call a function with mismatching calling conventions. http://llvm.org/docs/FAQ.html#callconvwrong > 2) visitFreeInst has been removed from lib/ExecutionEngine/Interpreter in 2.7 > Will this have any back-compatible problem when interpreting any > *.bc from 2.6? The 'free' instruction has been removed from LLVM 2.7. Any .bc files using it will have a 'call @free' inse...

Sounds like LLVM thinks the calling conventions or declarations are mismatched. See: http://llvm.org/docs/FAQ.html#callconvwrong Reid On Sat, Oct 3, 2009 at 1:16 AM, Talin <viridia at gmail.com> wrote: > Well, after some investigation I have a few more clues as to what is > going on. > > I have a module which contains a call to an external native function. > This native function lives in a static libra...

Hi llvm, 1) The lib/VMCore/Verifier.cpp in 2.7 implements Verifier::VerifyType, which is empty in 2.6. I noticed that it does not check all types, for example, UnionTyID, OpaqueTyID, LabelTyID, MetadataTyID and etc are ignored in the 'default' branch. Does it mean we dont need to check them? Another question is: How much does Verifier.cpp check statically? Can I take it as a type checker

Well, after some investigation I have a few more clues as to what is going on. I have a module which contains a call to an external native function. This native function lives in a static library, and there is an external declaration for it in the module. I find that I can run "llvm-ld -disable-opts -native -l mylibrary test.bc" and it works fine. That is, llvm-ld is able to

If you have been wondering why the verifier doesn't reject calls and callees with mismatched calling convs, any why the optimizer mercilessly deletes them, there is a new FAQ here: http://llvm.org/docs/FAQ.html#callconvwrong -Chris

On Wed, Apr 6, 2011 at 10:48 PM, Nicolas Ojeda Bar <nojb at math.harvard.edu> wrote: > Hi, > > Is this correct behaviour? > > test.ll: > > declare {} @__ex__print_int(i64) > > define i32 @main() { > entry: >  %0 = call i64 @f.1() >  %1 = call {} @__ex__print_int(i64 %0) >  ret i32 0 > } > > define internal fastcc i64 @f.1() { > entry: >

Hi, Is this correct behaviour? test.ll: declare {} @__ex__print_int(i64) define i32 @main() { entry: %0 = call i64 @f.1() %1 = call {} @__ex__print_int(i64 %0) ret i32 0 } define internal fastcc i64 @f.1() { entry: ret i64 7 } > opt -std-compile-opts test.ll -S ; ModuleID = 'test.ll' define i32 @main() noreturn nounwind { entry: tail call void @llvm.trap()

...ertions off). > > Further, there are semantics of the program that the verifier will never > verify. It is undefined behaviour to shift beyond the width of an integer. > It is undefined behaviour to call a function with mismatching calling > conventions. http://llvm.org/docs/FAQ.html#callconvwrong > >> 2) visitFreeInst has been removed from lib/ExecutionEngine/Interpreter in >> 2.7 >> Will this have any back-compatible problem when interpreting any >> *.bc from 2.6? > > The 'free' instruction has been removed from LLVM 2.7. Any .bc files using > it...