void *data = "">
if(data == NULL) {//it’s usage of data, is it not????
return 1
} else {
free data;
return 0;
}
checking data for NULL is clearly usage of variable data and compiler can’t know what outcome of the actual malloc call at runtime
I agree it’s “stupid” code, C/C++ standard doesn’t define code stupidity
code could be valid or not vaild
that code is valid, no doubt
ideally optimization MUST NOT change the code outcome in any way
in the very simple code (I provided) optimization clearly changes code outcome, which is not acceptable.
suppose I’m writing naive attempt to identify available memory and program exit with code 1 if memory wasn’t allocated and 0 if memory was allocated successfully
if malloc is optimized out then my tool won’t work properly, therefore compiler alters behavior of my program, whatever explanation one can provide
that is not acceptable (g++ and VS work correctly)
On Jul 4, 2016, at 3:34 PM, Jens Alfke <
email@hidden> wrote:
On Jul 4, 2016, at 11:09 AM, Dmitry Markman <
email@hidden> wrote:
clang can’t optimize malloc here, because result of the malloc is used.
It’s only used by free(), whose behavior is also known to the compiler, not by anything in your code. Thus the compiler saw that the malloc and free together formed a no-op, and optimized them both away.
also if I use
std::cout << "data != NULL" << data << std::endl;
malloc wasn’t optimized
Right, because then the program actually uses the pointer, so the compiler can’t optimize it away.
we have much more complex use case where
malloc was optimized out,
Did this code actually use the pointer returned by malloc? If so, that would seem to be a bug. But the example you showed here isn’t.
On Jul 4, 2016, at 11:55 AM, Quincey Morris <
email@hidden> wrote:
I don’t know the answer, but it seems to me at least possible that it didn’t fail. It’s at least possible that it gave you an unmapped virtual allocation of the size you asked for.
No, it does fail — I just tried it on OS X 10.11.5, and with no optimizations (-O0) the malloc call isn’t optimized away, and logs:
a.out(9897,0x7fff75a05000) malloc: *** mach_vm_map(size=281474976710656) failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
—Jens