similar to: [LLVMdev] Visual C patches - forgot to attach to last mail...

> 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

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

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 > ---

Hmm, 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. 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(

Here I am again... I missed that in the previous diff, they 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

These calls are in ExternalCalls.cpp, they are platform dependent calls, so maybe llvm should consider including it's own implementation of a random number generator? For the time being I just replaced with calls to srand and rand like Paolo also did, but it needs to be fixed... m.

On Wed, 29 Sep 2004, Reid Spencer 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

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() /

There do not seem to be any binaries for CygWin only Linux and the Mac :( I tried building the frontend on CygWin but ended up with a makeinfo error then a build error that I could not do anything about. I will have to get my Linux Laptop from home and use that. Many thanks, Aaron

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

This patch makes keys work again. This bug was introduced in r1.78: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/authfile.c.diff?r1=1.77;r2=1.78. Joachim Index: authfile.c =================================================================== RCS file: /usr/obsd-repos/src/usr.bin/ssh/authfile.c,v retrieving revision 1.78 diff -u -N -p authfile.c --- authfile.c 11 Jan 2010 04:46:45 -0000

Hello, Reid. You wrote Friday, January 21, 2005, 11:14:41 PM: RS> FYI, work progresses on the Win32 native port which you might also find RS> interesting. It might even get done before the cygwin stuff. Jeff Cohen RS> is working on that. Perhaps he can indicate the status of that effort. There is too much work to do native Win32 builds. I've tried to get llvm compiled on mingw32

Alec Benzer <alecbenzer at gmail.com> writes: > Ok, so calling lle_X_FUNCTIONNAME instead of FUNCTIONNAME works (is there > any reason the post used the lle_X_ prefix other than convention? was it > once possible to call external functions as I was originally trying, or, why > did the blog post think it was possible?) AFAIK you can name the function as you please (with some

> I'm afraid that you might be utterly confused about how to use LLVM. Er, I don't think so? I think I was mostly just confused about interfacing with external functions, since whoever wrote that blog post ( http://www.gearleaf.com/blog/post/44) didn't seem to know what he was talking about (or he was doing stuff that once worked but now doesn't? I don't know). If you

>From today's maillog: maillog:Dec 28 09:29:40 aurora dovecot: IMAP(doug): msync() failed with index file /home/doug/Maildir/.projects.job591/dovecot.index: Invalid argument maillog:Dec 28 09:30:21 aurora dovecot: IMAP(doug): msync() failed with index file /home/doug/Maildir/dovecot.index: Invalid argument maillog:Dec 28 09:30:22 aurora dovecot: IMAP(doug): msync() failed with index file

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:

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?

We've had this argument before. IMO LLVM should not be in the business of closing stdout, and no code in lib/ should print to stdout because users may expect output there (-o -). On Fri, Jan 23, 2015 at 10:20 AM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2015-Jan-23, at 09:52, mats petersson <mats at planetcatfish.com> wrote: > > > >

Hi, the following patch fixes a potential security hole in the Cygwin version of sshd. If you're logging in to a Cygwin sshd with version 2 protocol using an arbitrary user name which is not in /etc/passwd, the forked sshd which is handling this connection crashes with a segmentation violation. The client side encounters an immediate disconnect ("Connection reset by peer").

Chris Lattner wrote: > Hacking on the interpreter is easy, but has several drawbacks. In > particular, the interpreter is very slow (even compared to other > interpreters) and it is missing functionality: you cannot call arbitrary > external functions, which causes many programs to fail in it. What do you mean by external functions? I only need to print stuff to file, the