[LLVMdev] optimization assumes malloc return is non-null

[Jonathan S. Shapiro]

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.

In general, calls to procedures that are outside the current unit of
compilation are presumed to involve side effects performed in the body
of the external procedure (at least in the absence of annotation).

Can you say what version of the standard you are referencing, and (just
so I know) why section 5.1.2.3 makes a call to malloc() different from
any other procedure call with respect to side effects?


Thanks


Jonathan

On Wed, 2008-04-30 at 14:29 -0400, David Vandevoorde wrote:
> On Apr 30, 2008, at 2:10 PM, 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 malloc to return NULL, if
> > it can not allocate more space.  In fact, some programs should be able
> > to gracefully handle such situations.
> 
> It's an allowable program transformation because a call to malloc is  
> not in itself a side effect.  See e.g. 5.1.2.3 in the C standard.
> 
> 	Daveed
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev