similar to: negative numbers from object.size() on 64 bit systems

Hello! I'm not sure if is it a BUG or not... I'm using R 1.9.0, and I used the command below: > is.integer(9) [1] FALSE R manual contains this words about the is.integer() function: "is.integer returns TRUE or FALSE depending on whether its argument is of integer type or not." What's the problem? Am I wrong about the BUG report? Thank you very much. M?rcio de

In R-devel, the Depends: field in the DESCRIPTION file is now used by library() to load the named packages before the current package, and also to set up the environment to save images and prepare for lazy loading. Would authors please use a minimally necessary set of packages in Depends, and put others in Suggests: -- the distinction is made in `Writing R Extensions'. On the other hand,

Full_Name: Dr. Hans A. Kestler Version: 1.8.1. OS: Linux, Win, Mac OSX Submission from: (NULL) (134.60.73.116) The code below produces after a different number of iterations i the following error: Error in optim(par = rep(0.5, length(edges)), loglik, method = "L-BFGS-B", : non-finite value supplied by optim This was reproducible on different machines (Mac G4 OSX, AMD Opteron

Full_Name: Axel Benz Version: 1.7.1 OS: Windows Submission from: (NULL) (137.251.33.43) This feature seems to be a basic bug: > 1=="1" [1] TRUE > as.numeric(1)=="1" [1] TRUE > as.numeric(1)==as.character("1") [1] TRUE isn't it necessary to distinguish beteen numbers and characters?? Best Regards, Axel

Full_Name: Wolfgang Huber Version: R-devel_2005-03-10 OS: alphaev68-dec-osf4.0f Submission from: (NULL) (62.253.128.15) This report concerns allocation of large (>2^31 byte) chunks of memory with R_alloc. I suspect it is a bug/typo but please don't hate me if it's actually a feature: In R, I can happily create large matrices: > a= matrix(0, nrow=191481, ncol=3063) > dim(a) [1]

Dear all, I have several questions regarding fisher.test() in R, and I'd highly appreciate any help with it. I have a group of observations, each having people's income, and an indicator of whether selected in or out a program. I want to test the difference between income of people who are in and out. Because the distribution is far from normal, I decide to use the fisher's exact

Dear all, I have several questions regarding fisher.test() in R, and I'd highly appreciate any help with it. I have a group of observations, each having people's income, and an indicator of whether selected in or out a program. I want to test the difference between income of people who are in and out. Because the distribution is far from normal, I decide to use the fisher's exact

Hi, I tried to install the "pixmap" package on R 1.5.1. running on Windows 2000, but all I get are the following errors - could it be that something is wrong with the build of this particular package? Installation of other packages (I just tried with "pinktoe") seems to work fine. --------------------------------------------------------------- ### When trying to "Install

Hi George, On Mon, Jan 2, 2017 at 10:41 AM, George Burgess IV <george.burgess.iv at gmail.com> wrote: > Thanks for the comments! > >> Have you considered changing our existing behavior to match GCC's >> builtin_object_size instead of adding a new parameter > > Yup! My issue with turning `i1 %min` into `i8 %flags` is that > __builtin_object_size would get

This is a new build failure as of today. Does this look familiar to anyone? -bw llvm[2]: Compiling CommonProfiling.ll to CommonProfiling.bc for Debug build (bytecode) Intrinsic parameter #1 is wrong! i64 (i8*, i32)* @llvm.objectsize.i64 Intrinsic parameter #1 is wrong! i64 (i8*, i32)* @llvm.objectsize.i64 Intrinsic parameter #1 is wrong! i64 (i8*, i32)* @llvm.objectsize.i64 Intrinsic parameter

Hi George, Have you considered changing our existing behavior to match GCC's builtin_object_size instead of adding a new parameter? That may be simpler overall. There's also a clear upgrade strategy -- fold every old style call to "<min> ? 0 : 1". You probably already know this, but GCC folds builtin_object_size(0, 0) to -1 and builtin_object_size(0, 2) to 0. We'll

tl;dr: We'd like to add a bit to @llvm.objectsize to make it optionally be conservative when it's handed a null pointer. Happy Wednesday! We're trying to fix PR23277, which is a bug about how clang+LLVM treat __builtin_object_size when it's given a null pointer. For compatibility with GCC, clang would like to be able to hand back a conservative result (e.g. (size_t)-1), but the

My mistake. I needed to update llvm-gcc as well. Sorry for the noise. -bw On Dec 23, 2009, at 3:22 PM, Bill Wendling wrote: > This is a new build failure as of today. Does this look familiar to anyone? > > -bw > > llvm[2]: Compiling CommonProfiling.ll to CommonProfiling.bc for Debug build (bytecode) > Intrinsic parameter #1 is wrong! > i64 (i8*, i32)* @llvm.objectsize.i64

> we lower llvm.objectsize later than we should Is there a well-accepted best (or even just better) place to lower objectsize? I ask because I sorta fear that these kinds of problems will become more pronounced as llvm.is.constant, which is also lowered in CGP, gains popularity. (To be clear, I think it totally makes sense to lower is.constant and objectsize in the same place. I'm just

On Feb 27, 2013, at 4:05 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Hi, > > Regarding the definition of object for @llvm.objectsize, it is identical to gcc's __builtin_object_size(). So it's not wrong; it's just the way it was defined to be. > > Regarding the BasicAA's usage of these functions, I'm unsure. It seems to me that isObjectSmallerThan()

Hi, In the following instruction sequence, llvm.objectsize.i64(p) returns 6 (the entire *.ll is attached to the mail). Is this correct? Shouldn't the "object" refer to the entire block of memory being allocated? (char*) p = malloc(56) llvm.objectisize.i32(p+50); Thanks Shuxin This question is related to PR14988 (failure in bootstrap build with LTO). Part of the

Thanks for your reply. I'm attempting to expand KLEE to support this intrinsic function. That's why I need to handle this myself. According to the reply, the correct implementation should first find the definition of the object and then determine the size of the object. BTW, can I just refer to the implementation in InstCombineCalls.cpp. On Wed, Nov 5, 2014 at 2:24 PM, Matt Arsenault

Hi, Regarding the definition of object for @llvm.objectsize, it is identical to gcc's __builtin_object_size(). So it's not wrong; it's just the way it was defined to be. Regarding the BasicAA's usage of these functions, I'm unsure. It seems to me that isObjectSmallerThan() also expects the same definition, but I didn't review the code carefully. When you do a

Hi, Nuno and Arnold: Thank you all for the input. Let me coin a term, say "clique" for this discussion to avoid unnecessary confusion. A clique is statically or dynamically allocated type-free stretch of memory. A "clique" 1) is maximal in the sense that a clique dose not have any enclosing data structure that can completely cover or, partially

Optimizer doesn't know how to calculate the object size when it finds condition that cannot be eliminated. There is example: ----------------------------------------------- #include<stdlib.h> #define STATIC_BUF_SIZE 10 #define LARGER_BUF_SIZE 30 size_t foo(int flag) { char *cptr; char chararray[LARGER_BUF_SIZE]; char chararray2[STATIC_BUF_SIZE]; if(flag) cptr =