similar to: non-32-bit integer problem on SUN-Blade

Full_Name: Krassimir Sedmakov Version: R-1.4.1 OS: Solaris 8 Submission from: (NULL) (134.114.165.52) ******** Problem: ******** When running make for R-1.4.1 on Solaris 8, SPARC 64 bit the following error message is generated: arithmetic.c:672: #error code requires that int have 32 bits gmake[3]: *** [arithmetic.o] Error 1 gmake[3]: Leaving directory `/opt/R/R-1.4.1/src/main' gmake[2]:

Dear All, I have managed perfectly fine to install centos 5.5 x64 on a new sun blade x6270 server module .i had to install in text mode since GUI install mode was not working Actually this machine is going to replace my current working very low hardware server the server is used as my primary dns, mail server , webmail server also running Mailscanner, mailwatch etc. Also I want to use

Dear R-help folks, I am seeing unexpected behaviour from the function mean with option na.rm =TRUE (which is removing a whole column of a data frame or matrix. example: testcase <- data.frame( x = 1:3, y = rep(NA,3)) mean(testcase[,1], na.rm=TRUE) [1] 2 mean(testcase[,2], na.rm = TRUE) [1] NaN OK, so far that seems sensible. Now I'd like to compute both means at once:

R developers, 2 things: a bug in model.frame and a question about setup of generic functions. I don't understand the following behavior for generic functions: Suppose I'm working with the cats data in the MASS library and I want to create a formula object to model Hwt on Sex: # This works: > formula(Hwt ~ Sex) Hwt ~ Sex # But the following does not: > formula(Hwt ~ Sex,

Dear Rhelp folks, I think I read this in recent Rhelp, but I can't find it in the archive. I need to know how to get lg2c in order to build the nlme package. I'm trying to install nlme_3.1-2.tar.gz on a Linux machine (6.1 Redhat) under R Version 0.99.0 (February 7, 2000). Thanks, Jim Jim Robison-Cox ____________ Department of Math Sciences | |

When I run configure for the new release, R-0.63, I get an error: loading cache ./config.cache checking for a BSD compatible install... aux/install-sh -c checking whether ln -s works... yes checking for ranlib... ranlib checking for bison... bison -y checking for ar... ar checking for ratfor... no checking for latex... /psoft/TeX/bin/latex checking for dvips... /psoft/TeX/bin/dvips checking for

When I run configure for the new release, R-0.63, I get an error: loading cache ./config.cache checking for a BSD compatible install... aux/install-sh -c checking whether ln -s works... yes checking for ranlib... ranlib checking for bison... bison -y checking for ar... ar checking for ratfor... no checking for latex... /psoft/TeX/bin/latex checking for dvips... /psoft/TeX/bin/dvips checking for

Dear R-help-ers (Currently running Version 0.65.1 Release (October 07, 1999) on Solaris 2.6) My problem has to do with updates of the R language. When I install a new version, I would like to just change one directive, or a soft link to the current doc/html/ directory, to update a bookmark I have pointing to the current R doumentation directory. I've tried building a soft link:

R-crew, I'm trying to install the R-Snapshot which I downloaded a few hours ago and I'm having a problem I can't trace. My system is Sun SPARC, SunOS 5.3 : 1996 >From running ./configure:*************************************** loading cache ./config.cache checking for a BSD compatible install... /opt/local/R/R-snapshot/etc/install-sh -c checking whether ln -s works... yes

Thanks! That’s probably close enough for practical purposes. I looked at the overrides on various targets, and they all return true if the FMA hardware exists. - Arch From: Jingyue Wu [mailto:jingyue at google.com] Sent: Wednesday, December 10, 2014 2:56 PM To: Robison, Arch Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Best way for JIT to query whether llvm.fma.* is fast? Does

With floating point, won't you need to model a partial order for the end points? I thought there were pairs of floating point values which are incomparable. Not sure if partial order is the right abstraction, but I'm pretty sure a total order isn't. This may make implementing the range comparisons (which are themselves partially ordered) a bit tricky... Philip (Who knows just

> Checks against 1.0 are also common. Why not just add a FP range class, like our constant range, and go from there? That's certainly another way to go. My worry is that a more complicated lattice gets us deeper into rounding-mode issues and considerably more work for smaller gain. I like the idea of creating an FPRange class. We could start with a simple one and extend it as experience

Thanks for the pointers. Looks like LazyValueInfo has the sort of infrastructure I had in mind. LVILatticeVal could be extended to floating point. (The comment "this can be made a lot more rich in the future" is an invitation :-). I'm thinking a simple lattice would address most cases of interest for floating-point checks. The lattice points for floating-point could be all

For the Julia language JIT, we'd like be able to tell whether the llvm.fma.* intrinsic has hardware support. What's the best way to query LLVM (JIT) for this information? The information would be used in situations where the user wants to use different algorithms depending on whether FMA hardware is present or not. - Arch D. Robison -------------- next part -------------- An HTML

tools/llvm-objdump/COFFDump.cpp has two loops that advance the loop iterator using "I = ++I" instead of the usual "++I". For example: import_directory_iterator I = Obj->import_directory_begin(); import_directory_iterator E = Obj->import_directory_end(); if (I == E) return; outs() << "The Import Tables:\n"; for (; I != E; I = ++I) {

Yes, the modeling of floating-point is trickier. The wrap-around trick used by ConstantRange seems less applicable, and there are the unordered NaNs. Though in all cases, the key abstraction is a lattice of values, so an instance of FPRange should be thought of as a point on a lattice, not an interval. The lattice needs to be complicated enough the cover the cases of interest, but not so

In InstCombineCompares.cpp, routine InstCombiner::FoldFCmp_IntToFP_Cst, there are these lines: // Comparisons with zero are a special case where we know we won't lose // information. bool IsCmpZero = RHS.isPosZero(); // If the conversion would lose info, don't hack on this. if ((int)InputSize > MantissaWidth && !IsCmpZero) return nullptr; Why check for positive

Yes, I think the 2 outcomes are: - the current spec is unclear and will be clarified - in order to support safelen() and even the simd construct itself, LLVM will require infrastructure work to know when a lexically backwards dependence may have been introduced. Jon -----Original Message----- From: Tian, Xinmin [mailto:xinmin.tian at intel.com] Sent: Monday, September 29, 2014 10:43 AM To:

Oops, meant to send this to the mailing list instead of to Reid privately. (Why cc the mailing list instead of just sending to the mailing list?) In article <CACs=tyJ6zaHeiS0eNhBkdcZE--JY4k7yH9_P1yFbGqod6uymMw at mail.gmail.com>, Reid Kleckner <rnk at google.com> writes: > Looks like a bug. This can probably be simplified with C++11. > > On Fri, Apr 4, 2014 at 10:39

I noticed that LoopVectorizeHints::setAlreadyVectorized never deletes old "llvm.loop...." metadata. It just appends more, possibly contradicting the old metadata. E.g., after vectorization, a loop previously marked with llvm.loop.vectorize.width ends up with *two* such annotations, like this: br i1 %exitcond.1, label %for.end.loopexit.unr-lcssa, label %for.body, !llvm.loop !8