On Wed, Nov 6, 2013 at 6:29 AM, Richard Biener <richard.guent...@gmail.com> wrote: > On Wed, Nov 6, 2013 at 3:24 PM, Ian Lance Taylor <i...@google.com> wrote: >> On Tue, Nov 5, 2013 at 10:50 PM, Marc Glisse <marc.gli...@inria.fr> wrote: >>> On Tue, 5 Nov 2013, Ian Lance Taylor wrote: >>> >>>> This patch actually breaks the Go testsuite. In Go dereferencing a >>>> nil pointer is well-defined: it causes panic that can be caught. This >>>> breaks a test for that functionality by changing the panic to a >>>> builtin_trap. >>>> >>>> That's not a big deal; I'll just disable this optimization in the Go >>>> frontend. >>> >>> >>> Shouldn't go use -fno-delete-null-pointer-checks by default then? That >>> should disable this optimization and others that rely on the same idea. >> >> No, that is a different optimization with different properties. The >> -fdelete-null-pointer-checks optimization assumes that if you write >> x = *p; >> if (p == NULL) { printf ("NULL\n"); } >> that the test p == NULL can not succeed. In Go, that is true. If p >> is NULL the *p will cause a panic and ordinary code execution will not >> proceed. >> >> 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). > 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. Ian