similar to: [LLVMdev] PR 12207: sign extension of parameters and return values on x86-64

On Thu, Feb 23, 2012 at 3:54 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > LLVM has traditionally assumed that all integer argument and return > types narrower than int are promoted to int on all architectures. > Nobody has actually noticed any issues with this before now, as far as > I know. The only reason that I noticed was that Python ctypes started misbehaving when

On Wed, Feb 8, 2012 at 6:49 PM, Meador Inge <meadori at gmail.com> wrote: > I recently noticed a difference between the way GCC and LLVM treat > sign extension for parameters and return values on x86-64.  I could > not find a clear answer in the x86-64 ABI [1] concerning whether > parameters should be sign extended by the caller or callee and > similarly whether return values

I recently noticed a difference between the way GCC and LLVM treat sign extension for parameters and return values on x86-64. I could not find a clear answer in the x86-64 ABI [1] concerning whether parameters should be sign extended by the caller or callee and similarly whether return values should be sign extended by the caller or callee. Consider a simple 'signed char' division

Hi Meador, Have you filed a bugzilla report? What's the PR number? Evan On Feb 23, 2012, at 3:11 PM, Meador Inge wrote: > On Thu, Feb 23, 2012 at 3:54 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > >> LLVM has traditionally assumed that all integer argument and return >> types narrower than int are promoted to int on all architectures. >> Nobody has

Hi Eli, I think the llvm configure has already configured with ffi. ../llvm-2.6/configure -help | grep ffi --enable-libffi Check for the presence of libffi (default is YES) In addition, the printf() can work in program, reflecting that libffi is working, right? How can I make Interpreter work with getpid(), fork(), and clone()? On Thu, Dec 31, 2009 at 2:33 AM, Eli

On 02/01/2010 01:13 PM, Kristaps Straupe wrote: > Hello again! > > We have fetched the latest llvm sources from repository and the > original problem has went away. Though now we are facing a new problem > with interpreter on the following c code: > > -------------- > #include <stdarg.h> > #include <stdio.h> > > void doTheThing(int dummy, ...) > {

Hi, > It seems llvm interpreter only supports a limited number of external > functions. fmod, in particular is not supported. any reason why it is not > supported ? > > "lli -force-interpreter test.bc > LLVM ERROR: Tried to execute an unknown external function: double (double, > double)* fmod > " You can check out the comments in

On Jun 14, 2011, at 7:57 PM, 陳韋任 wrote: > Hi, > >> It seems llvm interpreter only supports a limited number of external >> functions. fmod, in particular is not supported. any reason why it is not >> supported ? >> >> "lli -force-interpreter test.bc >> LLVM ERROR: Tried to execute an unknown external function: double (double, >> double)* fmod

Hi Nick: Thanks for pointing me to libffi. Recompile LLVM with libffi does solve the problem of printf. But it still has other problems: 1) sinf() returns 0 in the interpreter, but returns correct value in JIT (see hellosin.c) 2) calling pthread_create cause lli to crash in the interpreter mode, but no problem in JIT (see phello.c). My questions are: i) can I call any arbitrary external function

Nick Lewycky <nicholas at mxc.ca> writes: > The interpreter uses libffi to make external function calls. However, it > needs to be detected at LLVM's compile time. If you're using the > released packages, we disabled that because we were worried about users > who don't have libffi installed. This seems to be quite a common problem (I too hit it once, thought it

On Thu, Nov 20, 2014 at 12:19:06AM +0100, Joerg Sonnenberger wrote: > On Wed, Nov 19, 2014 at 01:53:17PM -0800, Peter Collingbourne wrote: > > llgo depends on certain third-party components, namely a copy of the Go > > standard library (libgo), a Go program analysis library (go.tools) and two > > library dependencies of the standard library (libbacktrace and libffi). >

Hi Nick: The first problem have been solved by calling llvm-ld: $ llvm-ld -o hellosin.llvm hellosin.bc -lm $ lli -force-interpreter=true -load=/usr/lib/libm.so hellosin.llvm.bc hello sin: 0.50 The pthread problem remains after llvm-ld: $ lli -force-interpreter=true -load=/lib/libpthread.so.0 phello.llvm.bc 0 lli 0x08796bf8 Segmentation fault For those who are getting "invalid

On 5/14/2012 9:18 AM, Jim Grosbach wrote: > > On May 14, 2012, at 9:07 AM, Ashok Nalkund<ashoknn at qualcomm.com> wrote: > >> I was able to get past the error by calling InitializeNativeTargetAsmParser() in my code. Now I have a failure in resolving external libraries, so looking into that (recompiled with --enable-ffi but I now get an error LLVMgold.so not found). >>

On 5/14/2012 9:51 AM, Jim Grosbach wrote: > >>> >>> If you're hitting that code, you're running the old JIT (which does indeed not support inline assembly), not the MCJIT. >>> >> >> Do I need to enable anything at configure, my configure looks like this: >>> ../llvm/configure --enable-libffi --enable-targets=host-only

Timo Juhani Lindfors wrote: > Nick Lewycky<nicholas at mxc.ca> writes: >> The interpreter uses libffi to make external function calls. However, it >> needs to be detected at LLVM's compile time. If you're using the >> released packages, we disabled that because we were worried about users >> who don't have libffi installed. > > This seems to be

Xu Yang wrote: > Hi: > > When I try to execute lli -force-interpreter=true hello.bc, it gave the > following error: > > LLVM ERROR: Tried to execute an unknown external function: i32 (i8*)* puts > > I think the error is because C library is not being linked with the byte > code, but I was not able to find any helpful instruction in lli's document. > > Can you

Hello everyone, I'm trying to run a LLVM-Bytecode-file in the interpreter (lli --force-interpreter), but i'm getting the following error-message: LLVM ERROR: Tried to execute an unknown external function: i8* (i32)* malloc My program is calling malloc. If I omit --force-interpreter everything runs as expected. Compiling to Assembler also works without problems. I have compiled LLVM with

Xu Yang wrote: > Hi Nick: > > The first problem have been solved by calling llvm-ld: > > $ llvm-ld -o hellosin.llvm hellosin.bc -lm > $ lli -force-interpreter=true -load=/usr/lib/libm.so hellosin.llvm.bc > hello sin: 0.50 Only because the optimizer saw sin(constant) and folded it away. The entire program became 'print constant string'. There is certainly a bug

I have an issue with the OCaml build system and the ExecutionEngine. PR2128 has a patch to change the Interpreter to use libffi. This breaks test/Bindings/Ocaml/executionengine.ml because OCaml doesn't try to link with libffi, even though llvm-config knows that we should: $ Debug/bin/llvm-config --ldflags interpreter -L/home/nicholas/llvm-commit/Debug/lib -lpthread -lffi -ldl -lm

> > Is it turned ON in your build? > Yes it is turned on in my build here is my build script PATH=/mingw64/bin:$PATH FFI_INCLUDE_DIR="$(pkg-config --cflags libffi)" > FFI_INCLUDE_DIR=$(echo $FFI_INCLUDE_DIR | sed 's|-I||g') > > /mingw64/bin/cmake.exe \ > -G"MSYS Makefiles" \ > -DCMAKE_MAKE_PROGRAM="/usr/bin/make.exe" \ >