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.
Tom
