On Mon, Nov 11, 2013 at 8:27 AM, Jakub Jelinek <ja...@redhat.com> wrote: > 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.
Yes. At least for Go it would work fine to call a language defined function for a nil pointer dereference (in fact I already have one you could call), but then LTO might be an issue. Ian
