You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
%tmp15.i.i.i23 = malloc [2564 x i32]
icmp eq [2564 x i32]* %tmp15.i.i.i23, null
%retval = zext i1 %0 to i32
ret i32 %retval
Believe it or not, this came up in a real program!
I see no reason why the optimizers should not assume
that the malloc was successful, eliminate the call
and have the function return 0.
The text was updated successfully, but these errors were encountered:
You probably don't want to do this unconditionally. On MacOSX, for example, a failing malloc call sets
errno, which might be checked elsewhere. Various versions of malloc also exist that have side effects
such as accumulating statistics or emitting a log message.
I agree that there are use cases that can be affected. For example, on a 32-bit system, it is reasonable to
assume that "if (malloc(~0U))" will fail. However, that's depending on undefined behavior (e.g. the call
could succeed on a 64-bit machine), so I think we're ok.
-Chris
llvmbot
transferred this issue from llvm/llvm-bugzilla-archive
Dec 3, 2021
Extended Description
From the reduced example:
Believe it or not, this came up in a real program!
I see no reason why the optimizers should not assume
that the malloc was successful, eliminate the call
and have the function return 0.
The text was updated successfully, but these errors were encountered: