search for: mallocs

On Wednesday 30 April 2008 21:21, Chris Lattner wrote: > If LLVM is able to eliminate all users of the malloc assuming the > malloc succeeded (as in this case), then it is safe to assume the malloc > returned success. Ah, I missed this bit. I didn't see that the result of malloc was not used outside the if test. But is the if test considered a "use?" If so, it's a

Hi Victor, this code from the verifier broke the Ada front-end build: const Module* M = CI.getParent()->getParent()->getParent(); Constant *MallocFunc = M->getFunction("malloc"); if (CI.getOperand(0) == MallocFunc) { const PointerType *PTy = PointerType::getUnqual(Type::getInt8Ty(CI.getParent()->getContext())); Assert1(CI.getType() == PTy, "Malloc

I discovered that LLVM's malloc only allows a 32-bit size argument, so you cannot use it to allocate huge blocks on 64-bit machines. So I considered replacing all of my uses of LLVM's malloc instruction with calls to the libc malloc function instead. That got me wondering why LLVM even has its own malloc intrinsic anyway... Am I correct in assuming that LLVM's malloc intrinsic

Hi David and Mats, Thanks for your explanation. If my understanding is correct, it means we don't need to consider the side-effect of malloc/free unless compiling with -ffreestanding. Because without -ffreestanding, user defined malloc/free should be compatible with std library. It makes sense to me. My point is, in std library, malloc is allowed to return null if this malloc failed. Why

i was debugging a program on FreeBSD 6, and much to my surprise, i noticed that malloc(0) returns 0x800, as shown by this program: > more a.c #include <stdio.h> int main(int argc, char *argv[]) { char *p = malloc(0); printf(" malloc 0 returns %p\n", p); } > cc -o a a.c > ./a malloc 0 returns 0x800 if you look at the source this is indeed clear - internally

Duncan, Thanks for brining the Ada issue to my attention. On Sep 22, 2009, at 6:11 AM, Duncan Sands wrote: > Hi Victor, this code from the verifier broke the Ada front-end build: > > const Module* M = CI.getParent()->getParent()->getParent(); > Constant *MallocFunc = M->getFunction("malloc"); > > if (CI.getOperand(0) == MallocFunc) { > const

Hi Victor, > What does the Ada front-end declare malloc as? I don't really want to tell you because a correct solution should work no matter what malloc is defined to be :) What I mean by "work" is that if malloc has the standard prototype then you perform transforms on it, and otherwise you should probably just ignore it. That said, Ada outputs malloc as: i32 @malloc(i32)

On Thu, 2008-05-01 at 12:00 -0500, David Greene wrote: > On Wednesday 30 April 2008 21:21, Chris Lattner wrote: > > > If LLVM is able to eliminate all users of the malloc assuming the > > malloc succeeded (as in this case), then it is safe to assume the malloc > > returned success. > > Ah, I missed this bit. I didn't see that the result of malloc was not used

On Dec 23, 2008, at 9:14 AM, Jon Harrop wrote: > I discovered that LLVM's malloc only allows a 32-bit size argument, > so you > cannot use it to allocate huge blocks on 64-bit machines. So I > considered > replacing all of my uses of LLVM's malloc instruction with calls to > the libc > malloc function instead. That got me wondering why LLVM even has its >

Consider the following c code: #include <stdlib.h> int main(int argc, char** argv){ if(malloc(sizeof(int)) == NULL){ return 0; } else{ return 1; } } When I compile it with -O3, it produces the following bytecode: define i32 @main(i32 %argc, i8** %argv) { entry: ret i32 1 } Is this an error? It should be possible for malloc to return NULL, if it can not allocate more

On Wed, 2008-04-30 at 15:25 -0400, David Vandevoorde wrote: > On Apr 30, 2008, at 2:47 PM, Jonathan S. Shapiro wrote: > > Daveed: > > > > Perhaps I am looking at the wrong version of the specification. > > Section > > 5.1.2.3 appears to refer to objects having volatile-qualified type. > > The > > type of malloc() is not volatile qualified in the

On Wed, 30 Apr 2008, Ryan M. Lefever wrote: > Consider the following c code: > #include <stdlib.h> > int main(int argc, char** argv){ > if(malloc(sizeof(int)) == NULL){ return 0; } > else{ return 1; } > } > > > When I compile it with -O3, it produces the following bytecode: > > define i32 @main(i32 %argc, i8** %argv) { > entry: > ret i32 1

>is this "internal state” supposed to be private to the function? It could be private or not. Hence the name "inaccessible", to mean that the program under compilation has no access to the state. So while printf and malloc (for example) could share state in libc, the program under compilation cannot access this state. >how this flag would prevent the last “optimization”

On May 1, 2008, at 12:47 PM, David Greene wrote: > On Wednesday 30 April 2008 20:01, David Vandevoorde wrote: > >> Correct. It's an extreme form of garbage collection, I suppose ;-) >> >> (In theory, it can also be assumed to fail -- because an >> implementation is allowed to make any call to malloc fail -- though >> that's probably not useful.) >

...gram under compilation. >if you’re attribute is saying they have some internal state, then malloc() cannot access the state of free() and vice versa. Which is why it would be preferable to call it "inaccessible" state rather than "internal". >It would prevent to swap two mallocs but not moving freely a malloc with respect to a free. No, it would also prevent interchanging the order of malloc and free, since they both maintain states (which can be shared, but not accessible to the program under compilation) and the swapping order could result in a different final state. &g...

Sorry, for j On Thu, May 1, 2008 at 1:16 PM, David Vandevoorde <daveed at vandevoorde.com> wrote: > > Another valid implementation of malloc is one that actually returns a > non-null pointer in this case, and for such an implementation, a valid > reduction is "int main() { return 1; }". That reduction is IMO not > only valid, but also defensible and maybe

On Wed, 2008-04-30 at 18:26 -0400, David Vandevoorde wrote: > > Daveed: > > > > Good to know that I was looking at the correct section. I do not agree > > that your interpretation follows the as-if rule, because I do not > > agree > > with your interpretation of the C library specification of malloc(). > > > Before I go on, let me state that this is

Hi Mats, I think Kevin's point is malloc can return 0, if malloc/free pair is optimized way, the semantic of the original would be changed. On the other hand, malloc/free are special functions, but programmers can still define their own versions by not linking std library, so we must assume malloc/free always have side-effect like other common functions, unless we know we will link std

On Wednesday 30 April 2008 17:26, David Vandevoorde wrote: > >> ...malloc() is not specified to access a volatile > >> object, modify an object, or modifying a file (directly or > >> indirectly); i.e., it has no side effect from the language point of > >> view. > > > > Daveed: > > > > Good to know that I was looking at the correct

...>if you’re attribute is saying they have some internal state, then > malloc() cannot access the state of free() and vice versa. > Which is why it would be preferable to call it "inaccessible" state rather > than "internal". > > >It would prevent to swap two mallocs but not moving freely a malloc with > respect to a free. > No, it would also prevent interchanging the order of malloc and free, > since they both maintain states (which can be shared, but not accessible to > the program under compilation) and the swapping order could result in a > d...