This is the mail archive of the 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 11/11/13 05:16, Richard Biener wrote:
On Mon, Nov 11, 2013 at 4:11 AM, Jeff Law <> 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

That's exactly the reason why gnat.dg/memtrap.adb started to fail after
patch went it.  So, if -fisolate-erroneous-paths isn't amended, we'll need
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?
You eliminate less dead code if the trapping statement is a store. You want all the RHS nonsense in that case to just "go away".


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