On Mon, Nov 11, 2013 at 4:11 AM, Jeff Law <l...@redhat.com> wrote:
> 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.
Can't you simply keep the trapping stmt as-is?
Richard.
> 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
>
