Hi Jiangning,
Sorry, I don’t buy that argument. I don’t see why the compiler statically emulating the behaviour of a well behaved malloc/free pair is any different to it inlining a version of strcmp() (the library may have a strcmp that just returns -1 - the standard says it’s allowed to), or doing constant propagation with well known library calls such as fabs().
The non -ffreestanding behaviour is that the compiler knows it is sitting on top of a C library and it knows vaguely what a C library behaves like. Granted, malloc() is one of the few C library functions that the compiler can do something with that can have sideeffects, but removing it completely is certainly a good thing.
Consider:
int *my_useless_buffer = malloc(LOTS);
for (n : X) {
my_useless_buffer[0] += n;
}
free(my_useless_buffer);
The compiler would be expected to reduce my_useless_buffer to a single int and remove the malloc. I agree with David that -ffreestanding is the way to inform the compiler that it shouldn’t make any assumptions about malloc/free/strcmp/memcpy/memset…
Cheers,
James