similar to: [LLVMdev] patches and problem...

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

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(

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

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

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.

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

Morten, have a look at the http://mail.cs.uiuc.edu/pipermail/llvmdev/2004-September/002235.html thread... On Oct 19, 2004, at 2:40 PM, Morten Ofstad wrote: > 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

Hello, I have some C code that I'm interfacing to R using the .C calling interface. Currently the C code uses the rand() function from the GNU C library to generate random numbers. Since I need the random numbers in a range from 0 to a (where a is an integer) I use the RAND_MAX macro as (int)(rand() * (float)(*nobs-1) / (RAND_MAX+1.0)) (taken from the rand() manpage) However, since I have

Hi everyone, sorry if this has been answered before - I caught a whiff of a discussion about c's rand() function in a mailing list archive, but couldn't find a definitive answer. I'm trying to do a simple CS project on my machine where I generate two sets of values in parallel using rand() and am running into infinite loops of values, and couldn't figure out why, so I wrote a test

Hello I'm trying to use C random generator function drand48() which return floating-point values, uniformly distributed over [0,1], (http://www.opengroup.org/onlinepubs/007908799/xsh/drand48.html). When values are returned to R, they are not in [0,1]. A simple C program using drand48() gives values in [0,1] so I suppose there is a problem (type definition ?) between C and R. Here are R

Hi, There is a bug in the shuffle of ogg123 which was here at least until the CVS version of 3 days ago. Here's our fix: (it seems to be not perfectly equiprobable but at least fixes the old one which sometimes gives two times the same song and never the other song) -=-=-- --- vorbis-tools-1.0beta3/ogg123/ogg123.c.pix Sat Nov 4 01:23:21 2000 +++ vorbis-tools-1.0beta3/ogg123/ogg123.c Thu

The scons file that I posted yesterday is broken... I've not taken in account the commit of 2 days ago that modified *iterator.in* and friends. I've updated it and now it works again; inside it you can find comments about what files currently are NOT compiled and why (hint appreciated!) Attached to this email you can find it and a new series of patches against current CVS, that I hope

On Oct 25, 2011, at 6:09 AM, Marcello Maggioni wrote: > Hi, I'm trying to compile the latest clang/llvm SVN versions and I get > this error on multiple systems : Linking, not compiling, but still. I am getting a similar error when building this morning. > Undefined symbols for architecture x86_64: > "clang::Sema::checkPseudoObjectRValue(clang::Expr*)", referenced

On Sun, 2004-09-26 at 12:42, Paolo Invernizzi wrote: > Attached to this email you can find it and a new series of patches > against current CVS, that I hope are pretty safe. Paolo, I applied most of your patches to cvs. I didn't apply the patches for things under lib/Support. I will leave that to Reid (if you can resend those to this list it would be great). Here is the list of the

Hi All, I am first time trying build CLANG+LLVM using cmake+ninja build system. I updated all my CLANG+LLVM sources to current trunk, and I successfully built it using classic *make* build system. But, trying to build the same with cmake+ninja build system resulting in following build failures for compiler-rt sources. Am I missing something basics here? ==================== cmake command used:

I'm looking for some help in getting R to compile on Sunos. We run a collection of Sunos and Solaris machines in the department here. I got to compile on Solaris 2.5.1 using gcc 2.7.2.2. On my Sunos 4.1.3 (and I've tried it on Sunos 4.1.4 as well) machines, it crashes during the compile. I'm using gcc 2.8.1 on there. It gets to this point: gcc -g -O2 -I../include

Please, take a look on the discussion from Reid and Chris: http://mail.cs.uiuc.edu/pipermail/llvmdev/2004-September/002243.html >From: Morten Ofstad <morten at hue.no> >Date: Tue, 19 Oct 2004 14:40:17 +0200 > >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

I'm seeing this too. CC'ing the author ubsan stuff. Richard, I know you were OK with only supporting Clang-bootstraps, but I don't think that's terribly viable here. We should be able to build ubsan's runtime with standards conforming code unless there is some fairly extreme reason not to... On Fri, Oct 12, 2012 at 7:19 AM, Mahesha HS <mahesha.llvm at gmail.com> wrote:

we have got asterisk 1.0 (over 1 yrs old) version and very old zaptel version. That code is working only with 8 or less ports (accumulative) on digium fxs/fxo cards (2 cards with 4 ports each). the questoin is, what if we want 12 ports?..well, really, i don't understand the limitations? is it simply zaptel driver code fix? or kernel fix? or technology limitation? donno any tips would