[cfe-dev] Is valid optimization: dropping new[]

John McCall rjmccall at apple.com
Wed Feb 6 00:28:04 PST 2013

On Feb 6, 2013, at 12:19 AM, Dmitri Shubin <sbn at tbricks.com> wrote:
> On 02/06/13 11:49, John McCall wrote:
>> The optimizer is making not-strictly-standard assumptions about the
>> behavior of global operator new[] and the merits of intentionally triggering
>> an out-of-memory condition with a leak vs. promoting leaked allocations
>> to the stack.  You can disable these assumptions with -fno-builtin, avoid
>> them by compiling at -O0, or work around them by assigning each 'p' in
>> turn to a volatile global variable, which will stop the compiler from realizing
>> that they leak.
> Yes, making p to be 'static volatile char *' fixed the problem, thank you!

Making it "char * volatile" would be a more stable workaround;  it should
prevent the optimizer from reasoning about the store at all.

> Do I understand you right that the compiler did the following:
> 1. replaced 'new char[1024]' with smth like 'alloca(1024)'
> 2. since alloca() cannot fail it removed try/catch and if() statements.
> 3. since the result isn't used 'alloca()' call was removed also.

Something approximately like this, although I don't know the details.

> Well for 1024 bytes I think it's reasonable, but I can see the same behavior when changing 1024 to smth bigger, like 2^30 which makes this transformation wrong from my point of view.

Yes, I certainly agree that arbitrary allocations should not be moved to the stack.  I don't know the limits on this optimization.  It may be that it wouldn't normally just turn the heap-allocation into a stack-allocation, and it's only because it's obviously completely unused that it removes the allocation entirely.


More information about the cfe-dev mailing list