well 32-bit GCC still assumes that malloc has to return 0 for this input.
-
-
Replying to @volatile_void
Do you mean it as a philosophical POV or that gcc will optimize "if (p)" away based on this assumption?
2 replies 0 retweets 0 likes -
Replying to @ch3root
I meant it philosophically, but now I have investigated and ugh https://godbolt.org/g/piu9ka cc
@RichFelker1 reply 0 retweets 0 likes -
I am pretty sure it's possible to merge these to programs into one that shows GCC is as wrong as Clang on this.
1 reply 0 retweets 0 likes -
oops that was still Clang being wrong in that link, no sign of GCC being inconsistent so far.
1 reply 0 retweets 0 likes -
Replying to @volatile_void @ch3root
Indeed. The invalid optimization clang is making is assuming malloc doesn't fail. Unless GCC also does that, GCC is ok.
1 reply 0 retweets 1 like -
Replying to @RichFelker
Why do you think this is an invalid optimization? Compilers routinely mess with libc functions, e.g. inline memcpy.
2 replies 0 retweets 0 likes -
Replying to @ch3root
Because the behavior is changed. A call which necessarily must fail falsely succeeds.
2 replies 0 retweets 0 likes -
Replying to @RichFelker
The change of behavior is exactly the reason for optimizations.
2 replies 0 retweets 1 like -
Replying to @ch3root @RichFelker
Programs become smaller, require less memory and can successfully process larger data sets.
2 replies 0 retweets 0 likes
I challenge you to provide an example where that can actually happen.
-
-
Replying to @RichFelker @ch3root
You obviously can't optimize out malloc if the memory is actually used. Moving to stack could overflow stack.
1 reply 0 retweets 1 like - 5 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.