c++compiler-optimizationnew-operator

Why would a C++ compiler not eliminate null check of pointer returned by new?


Recently I ran the following code on ideone.com (gcc-4.3.4)

#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <new>

using namespace std;

void* operator new( size_t size ) throw(std::bad_alloc)
{
     void* ptr = malloc( 2 * 1024 * 1024 * 1024);
     printf( "%p\n", ptr );
     return ptr;
}

void operator delete( void* ptr )
{
    free( ptr );
}

int main()
{
    char* ptr = new char;
    if( ptr == 0 ) {
        printf( "unreachable\n" );
    }
    delete ptr;
}

and got this output:

(nil)
unreachable

although new should never return a null pointer and so the caller can count on that and the compiler could have eliminated the ptr == 0 check and treat dependent code as unreachable.

Why would the compiler not eliminate that code? Is it just a missed optimization or is there some other reason for that?


Solution

  • I think you're expecting way too much of the optimizer. By the time the optimizer gets to this code, it considers new char to be just another function call whose return value is stored on the stack. So it doesn't see the if condition as deserving special treatment.

    This is probably triggered by the fact that you overrode operator new, and it's beyond the optimizer's pay grade to look in there, see you called malloc, which can return NULL, and decide that this overridden version won't return NULL. malloc looks like Just Another Function Call. Who knows? You might be linking in your own version of that, too.

    There are a couple other examples of overridden operators changing their behavior in C++: operator &&, operator ||, and operator ,. Each of these has a special behavior when not overridden, but behave like standard operators when overridden. For example, operator && will not even compute its right hand side at all if the left hand side evaluates as false. However, if overridden, both sides of the operator && are computed before passing them to operator &&; the short-circuit feature goes away completely. (This is done to support using operator overloading to define mini-languages in C++; for one example of this, see the Boost Spirit library.)