search for: malloc

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 use in the con...

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 call must return i8*", &CI); } I think it is c...

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

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 compiler knows it must succeed at compile time?...

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

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 PointerType *PTy = > PointerType::getUnqual(Type::getInt8Ty(CI.getParent()->getContext())); > Assert1(CI.getType() == PTy, "Malloc call must return i8*", &CI); >...

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, Ad...

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 > outside the if test. > > But is the if test considered a "use?&quot...

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

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

...ote: > 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 standard library > > definition. > > ...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:...

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 an error? It should be possible for mall...

>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” you’re illustrating Assuming you are referring to the quoted examples, currently these optimizations are not happening anyway (from what I unders...

...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.) > > You just contradicted yourself. If an implementation can return > zero/null, > then the optimizer can't assume the direction of the branch in this > case. It > has to allow the call to proceed and get the retur...

>what is a non-public state that no-one but you can access? (I’d call that private). malloc and free could both use global variables that are defined in libc, but are inaccessible to the program 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...

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 desirable. (And LLVM > apparently does so.) But this...

...0, 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 not a contentious issue > among WG14: There is no doubt that the intent of the standard is that > this be a valid optimization. And of course, ANSI C working groups are infallible. Consider "noalias". :-) But I thin...

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

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

>there would be two disjoint global states In some sense yes, but technically not disjoint. Functions marked with this attribute should still be able to access the globals within the program under compilation, if its not marked with ReadNone. >If malloc and free can both use global variables (there is no notion of library in the compiler) Inaccessible state here refers to any global that is not visible to the program under compilation. The key idea (behind the new attribute) is to convey that these external functions do things inside that the comp...