On Thu, Oct 10, 2013 at 4:17 PM, Tom Tromey <tro...@redhat.com> wrote:
> Marc> + if (flag_delete_null_pointer_checks
> Marc> + && lookup_attribute ("returns_nonnull",
> Marc> + TYPE_ATTRIBUTES (TREE_TYPE (fndecl))))
> Marc> + return true;
>
> I wired all this up to gcj, but it tripped over the
> flag_delete_null_pointer_checks test, because java/lang.c sets it:
>
> /* Java catches NULL pointer exceptions, thus we can not necessarily
> rely on a pointer having a non-NULL value after a dereference. */
> opts->x_flag_delete_null_pointer_checks = 0;
>
> svn claims that Jeff wrote this line. Hi Jeff, I'm sure you remember
> this patch from two years ago in great detail :-). (I did look up the
> original mail thread but there wasn't really anything there.)
>
> My question is, is this really needed? The docs for
> -fdelete-null-pointer-checks say:
>
> In
> addition, other optimization passes in GCC use this flag to
> control global dataflow analyses that eliminate useless checks for
> null pointers; these assume that if a pointer is checked after it
> has already been dereferenced, it cannot be null.
>
> I think the key situation is one where the code has a dereference that
> is caught, followed by a null pointer check, like:
>
> try {
> x.toString();
> } catch (NullPointerException _) {
> }
>
> if (x == null)
> System.out.println("ok");
>
> I changed java/lang.c to set x_flag_delete_null_pointer_checks and I
> couldn't make this test case (or a few others) fail.
>
> However, I'm not sure if that is because GCC understands that
> -fnon-call-exceptions means that the dereference can throw, and thus
> does the right thing; or whether I'm just getting lucky.
In this case it will notice that if x.toString did not throw x will be
not null. But as you catch the exception before the NULL test
this information doesn't prevail until the test.
Richard.
> Tom
