This is the mail archive of the
mailing list for the GCC project.
Re: [RFA][PATCH] Isolate erroneous paths optimization
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Ian Lance Taylor <iant at google dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 6 Nov 2013 17:20:43 +0100
- Subject: Re: [RFA][PATCH] Isolate erroneous paths optimization
- Authentication-results: sourceware.org; auth=none
- References: <CAKOQZ8x5FAnYzkepikoJSpX9467H0Xx_28SO3abGu6J+PSpNEQ at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1311060743550 dot 4174 at laptop-mg dot saclay dot inria dot fr> <CAKOQZ8xS5Dpk9Fe9wvRpQ3WC_1NsPMSkomGqav5p0ijhKKCkSQ at mail dot gmail dot com> <CAFiYyc0es-DxOwbcka2RtiP4HshSWMcj-3nOdFCvXD39pvXJnA at mail dot gmail dot com> <CAKOQZ8zYjMzGuGRGbL75bkPHc1gKVcTBaBcwkhhbC3nOhjXvrQ at mail dot gmail dot com> <CAFiYyc1JiWcH05crFnO9tMdouw=Z3TDgexpCTOfX4ezMsF-oTw at mail dot gmail dot com> <CAKOQZ8ytOYug0+FFP6kR_yov1N_D6NERT3Y-n6806xp2GqyPkQ at mail dot gmail dot com> <CAFiYyc2Eh=GJ37aO9yRUU9gfgOaRZXJPUYnv-YFfk9Y-rqadKQ at mail dot gmail dot com> <20131106152732 dot GC27813 at tucnak dot zalov dot cz> <527A6B3D dot 8020806 at redhat dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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.