This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA][PATCH] Isolate erroneous paths optimization


On Mon, Nov 11, 2013 at 8:27 AM, Jakub Jelinek <jakub@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]