This is the mail archive of the
gcc-patches@gcc.gnu.org
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: Eric Botcazou <ebotcazou at adacore dot com>, gcc-patches at gcc dot gnu dot org, Ian Lance Taylor <iant at google dot com>, Richard Biener <richard dot guenther at gmail dot com>
- Date: Mon, 11 Nov 2013 17:27:46 +0100
- Subject: Re: [RFA][PATCH] Isolate erroneous paths optimization
- Authentication-results: sourceware.org; auth=none
- References: <5271F493 dot 4020308 at redhat dot com> <1586972 dot iyObK3nBib at polaris> <52804ACB dot 9010206 at redhat dot com> <28252664 dot nAfHr8z7i3 at polaris> <528104BB dot 3000901 at redhat dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Mon, Nov 11, 2013 at 09:24:27AM -0700, Jeff Law wrote:
> On 11/11/13 02:33, Eric Botcazou wrote:
> >>However, that brings up an couple interesting questions.
> >>
> >>Let's say we find a NULL pointer which reaches a return statement in a
> >>function which is marked as returns_nonnull. In that case there is no
> >>dereference. Presumably for that kind of scenario we'll just keep the
> >>builtin trap.
> >>
> >>Similarly, assume we extend this pass to detect out-of-bounds array
> >>indexing. It's fairly simple to do and has always been in my plan. In
> >>that case leaving in the array indexing won't necessarily generate a
> >>fault. For those presumably we'll just want the builtin_trap as well?
> >>
> >>Again, I don't mind inserting a *0, I just want to have a plan for the
> >>other undefined behaviours we currently detect and those which I plan on
> >>catching soon.
> >
> >The more general problem is that, with -fnon-call-exceptions, we really expect
> >a fully-fledged exception to be raised when something goes wrong. Inserting
> >__builtin_trap doesn't work because it's simply not equivalent to a throw. In
> >other words, if __builtin_throw would be inserted instead of __builtin_trap
> >with -fnon-call-exceptions, things would probably be acceptable as-is.
> Hmm, maybe that's a better soultion then. When non-call-exceptions
> is active, throw rather than trap.
But throw what? It is up to the runtimes of -fnon-call-exceptions languages
to decide if they actually want to throw or do something else in the signal
handlers, and what exactly to throw.
Jakub