search for: externalfunct

-------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041025/d290c6e0/attachment.txt>

On Oct 25, 2004, at 3:41 AM, Morten Ofstad wrote: > Index: lib/ExecutionEngine/Interpreter/ExternalFunctions.cpp > =================================================================== > RCS file: > /var/cvs/llvm/llvm/lib/ExecutionEngine/Interpreter/ > ExternalFunctions.cpp,v > retrieving revision 1.78 > diff -u -r1.78 ExternalFunctions.cpp > --- lib/ExecutionEngine/Interpreter/E...

...mentation. Reid. Chris Lattner wrote: > On Tue, 28 Sep 2004, Paolo Invernizzi wrote: > > >>The next major problem is that VC has only >> >>int rand(void) >>void srand( int seed ) >> >>So I donno how to compile the >>ExecutionEngine/Interpreter/ExternalFunctions.cpp that refers to the >>drand48 srand48 lrand48 etc series... >>For now I hacked them, like >> >>double drand48(void) { return (float) rand() / (float) RAND_MAX > > > For these, just ifdef them out. If the platform doesn't support drand48, > there is...

...ncer wrote: > > On Tue, 28 Sep 2004, Paolo Invernizzi wrote: > >>The next major problem is that VC has only > >> > >>int rand(void) > >>void srand( int seed ) > >> > >>So I donno how to compile the > >>ExecutionEngine/Interpreter/ExternalFunctions.cpp that refers to the > >>drand48 srand48 lrand48 etc series... > I guess I need a sys::Math::getRandom() function that uses a "good" random > number generator on the given platform. I'll make a note of this and tuck it > away for future implementation. No, LL...

Morten Ofstad wrote: >> Hi, >> >> There's no HAVE_RAND48 symbol provided by autoconf. You'll have to >> add the appropriate check to autoconf/configure.ac before we can take >> this patch. I installed autoconf with cygwin now and I think I've managed to do this right now -- there are some strange problems with running the AutoRegen.sh script, so I

> Hi, > > There's no HAVE_RAND48 symbol provided by autoconf. You'll have to add > the appropriate check to autoconf/configure.ac before we can take this > patch. Sorry I forgot to mention I didn't make any changes to the configure script. The problem is that I can't test these things since I'm not on a Unix platform, and I'm not even using the

And, one more weird thing in this function. The FILESize static variable is never initialized so its likely initial value is 0 due to zero fill on many MMUs. The value is never written and used as a divisor. Why hasn't this function caused an arithmetic violation? Because the IOBBase point, also a static variable is initialized to zero and never modified and used in a conditional that thwarts

I mis-stated what I think should be deleted. The block of code from "GlobalVariable *IOB = 0;" to the end of the loop should be delted because the only effect the loop has is on the IOB variable and that variable is never used after the loop. Reid. On Tue, 2004-05-11 at 18:14, Reid Spencer wrote: > Hi, > > I'm working on bug 122, consolidating the interface to the

...are the usual missing <algorithm> and the std:: namespace missing in sort, find, make_pair. Alkis can you please give them an eye when you have time? The next major problem is that VC has only int rand(void) void srand( int seed ) So I donno how to compile the ExecutionEngine/Interpreter/ExternalFunctions.cpp that refers to the drand48 srand48 lrand48 etc series... For now I hacked them, like double drand48(void) { return (float) rand() / (float) RAND_MAX and so... Is it -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diffs.txt URL: <...

Hi, I'm working on bug 122, consolidating the interface to the SymbolTable class. In doing so, I found the function below which traverses the symbol table but apparently unnecessarily. Before I remove the traversal, I thought I better check with you guys. Posted this to the list because it looks like _everyone_ has edited this file :) In the code below, the IOB variable is the only thing in

I’ve been experimenting with SEH handling in LLVM, and it seems like the unwind funclets generated by LLVM are much larger than those generated by Microsoft’s CL compiler. I used the following code as a test: void test() { MyClass x; externalFunction(); } Compiling with CL, the unwind funclet that destroys ‘x’ is just two lines of asm: lea rcx, QWORD PTR x$[rdx] jmp ??1MyClass@@QEAA at XZ However when compiling with clang-cl, it seems like it sets up an entire function frame just for the destructor call: mov qword ptr [rsp + 16], rdx pus...

...ection. If you don't want this behavior, don't use outs(). > > I don't really have an opinion on whether this is a good idea, but it > does suggest that any use of `outs()` in `lib/` is a bug. > > $ git grep -l 'outs()' -- lib/ > lib/ExecutionEngine/Interpreter/ExternalFunctions.cpp > lib/IR/GCOV.cpp > lib/Support/CommandLine.cpp > lib/Support/FormattedStream.cpp > lib/Support/TargetRegistry.cpp > lib/Support/raw_ostream.cpp > lib/Target/CppBackend/CPPBackend.cpp > > All of these cases seem to be for outputting help text of some sort. But >...

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 " -- Kind Regards Xin Tong -------------- next part -------------- An HTML attachment was scrubbed... URL:

...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 lib/ExecutionEngine/Interpreter/ExternalFunctions.cpp to see how LLVM interpreter handle external functions. "... If such a wrapper does not exist, and libffi is available, then the Interpreter will attempt to invoke the function using libffi, after finding its address." I guess you have to configure LLVM with "--enable-...

...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 lib/ExecutionEngine/Interpreter/ExternalFunctions.cpp > to see how LLVM interpreter handle external functions. > > "... If such a wrapper does not exist, and libffi is available, then the Interpreter will > attempt to invoke the function using libffi, after finding its address." > > I guess you have to configu...

ISSUE: ExternalFunctions.cpp::lookupFunction() calls dlsym(RTLD_DEFAULT, ...). In glibc, dlfcn.h does not make RTLD_DEFAULT visible unless _GNU_SOURCE is #defined. Unlike the evil money-grubbing non-free software pigs at sun, the FSF is trying not to pollute the C namespace. ;) ACTION: Hack the Makefile to #defin...

On Tue, 28 Sep 2004, Paolo Invernizzi wrote: > The next major problem is that VC has only > > int rand(void) > void srand( int seed ) > > So I donno how to compile the > ExecutionEngine/Interpreter/ExternalFunctions.cpp that refers to the > drand48 srand48 lrand48 etc series... > For now I hacked them, like > > double drand48(void) { return (float) rand() / (float) RAND_MAX For these, just ifdef them out. If the platform doesn't support drand48, there is no reason for the interpreter to d...

Linking lli debug executable (without symbols) /mounts/zion/disks/0/localhome/pmeredit/llvm/lib/Debug/lli-interpreter.o(.te xt+0x643a): In function `llvm::Interpreter::callExternalFunction(llvm::Function*, std::vector<llvm::GenericValue, std::allocator<llvm::GenericValue> > const&)': /localhome/pmeredit/llvm/lib/ExecutionEngine/Interpreter/ExternalFunctions.c pp:98: undefined reference to `llvm::WriteBytecodeToFile(llvm::Module const*, std::basic_ostream<cha...

I was just fixing a bug that was caused by `stdout` being closed before the runtime has done `fflush(stdout)` [or however this is implemented in the runtime]. The cause of this seems to be that `outs()` returns a static object created from `raw_fd_stream(STDOUT_FILENO, true)` - the `true` being the `shouldClose` parameter. Surely LLVM is not supposed to close `stdout` as part of its operations?

...that use libdl 2. include/Support/DataTypes.h doesn't work for FreeBSD; I hacked a new version 3. alloca.h doesn't exist and is not needed to use alloca(); #ifdef it out 4. no malloc.h and no mallinfo(); malloc doesn't track this stuff; #ifdef it out 5. isnan() may be a macro; lli's ExternalFunctions.cpp doesn't pick it up (why?) Not surprisingly, autoconf will probably be able to take care of most of these fairly easily. I didn't really have a chance to figure out what was going on with #5. I'll probably check in a few fixes based on my findings, once we get back. -Brian --...