On 11/10/13 05:34, Eric Botcazou wrote:
But I think that you cannot transform
foo ()
{
*0 = 1;
}
to __builtin_trap as you can catch the trap via an exception handler
in a caller of foo, no?
That is true. OK, I can see an argument that when using
-fnon-call-exceptions that kind of code should not be changed to call
__builtin_trap.
That's exactly the reason why gnat.dg/memtrap.adb started to fail after Jeff's
patch went it. So, if -fisolate-erroneous-paths isn't amended, we'll need to
disable it in Ada like in Go.
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).
This would probably work for Ada as well.
OK. It sounds like there's a pretty general consensus that we ought ot
go ahead and leave in a load/store of a NULL pointer. I'll go ahead and
run with that. I'll probably just emit SSA_NAME = *0, unless someone
thinks we ought ot distinguish between loads and stores, emitting
SSA_NAME = *0 and *0 = 0 for the two cases respectively.
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.
Jeff
