[LLVMdev] interesting possible compiler bug

[Krzysztof Parzyszek]

On 10/15/2012 7:49 PM, Chris Lattner wrote:
>
> I'm pointing out that you're making strong claims without backing them up by anything.  For example "malloc is not known to always return a non-null pointer" is true, but not pertinent.  "malloc has side-effects and hence cannot be eliminated" is not true.

Ok, I admit, my first reply was a bit hasty.  I looked at the loop and 
saw that it iterated for as long as malloc returned non-null.  In 
general, malloc cannot be relied on never returning a non-null value, 
hence my first comment.  Second one came from the fact that malloc does 
indeed have side effects, regardless of whether it can or cannot return 
null in any particular implementation.  The side effects are those that 
"free" or "realloc" use.  If the return value from malloc is never used, 
this may be irrelevant, but the "state" may be visible to the user when 
using "custom" memory allocation routines.  There is also a more 
practical side of this, namely the observable effects such as running 
out of memory.  On systems, where malloc can eventually run out of 
storage, the testcase in question will eventually complete.  When 
dealing with functions like strcmp, making such optimizations is fine, 
but those that have a deeper impact may require more care.  Using 
-fno-builtin may not always be acceptable.

-K

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation