This is the mail archive of the gcc-patches@gcc.gnu.org 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: New attribute: returns_nonnull


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


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