On 11/06/13 08:08, Ian Lance Taylor wrote:
The recent -fisolate-erroneous-paths optimization will change code
like this:
if (p == NULL) { printf ("NULL\n"); }
x = *p;
into code like this:
if (p == NULL) { printf ("NULL\n"); __builtin_trap (); }
x = *p;
That is, it will insert a trap rather than dereferencing the pointer
known to be NULL. This doesn't work for Go because we really do want
the panic, not the __builtin_trap. This optimization would work fine
for Go if there were a way to explicitly call the panic function
rather than calling trap, but that would be a frontend-dependent
aspect to a middle-end optimization.
But then you have -fnon-call-exceptions enabled?
Yes (go_langhook_init_options_struct in go/go-lang.c).
I wonder if we could have the front-ends define a builtin to use in this
kind of situation and use the builtin trap as a fallback if the
front-end didn't provide a suitable builtin.
Where obviously
-fisolate-erroneous-paths also shouldn't apply?
I guess that's not entirely obvious to me. I'm not sure that
-fnon-call-exceptions means that all trapping instructions must be
executed.
In effect, yes.
Jeff
