On Wed, Nov 06, 2013 at 09:15:57AM -0700, Jeff Law wrote:
> On 11/06/13 08:27, Jakub Jelinek wrote:
> >On Wed, Nov 06, 2013 at 04:23:06PM +0100, Richard Biener wrote:
> >>>In that case I think it would be fine to run the isolate paths
> >>>optimization, but to not omit the actual dereference of the NULL
> >>>pointer (possibly the dereference could be followed by a trap).
> >>
> >>Yeah, we need the trap to properly end the BB (even if that is a
> >>waste instruction generated).
> >
> >BTW, why do we generate in this optimization __builtin_trap rather than
> >just __builtin_unreachable ()? The former still generates some code (abort,
> >some aborting instruction, ...), while the former is just an assertion that
> >valid code will not reach it.
> Because if you do reach the site, you really want to halt the
> program to avoid potential security exploits. I'm actually of the
> opinion that builtin_unreachable should be trapping as well.
__builtin_unreachable () is trapping if -fsanitize=unreachable, but
otherwise it is just an optimization hint, intentionally so, that allows
optimizing on the fact that it doesn't happen. If from fear of security
exploits we'd stop trying to optimize code well, we'd need to punt on using
undefined integer overflow and many other things.
Jakub
