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]

Re: proposed patch for gcse.c (delete_null_pointer_checks)


>>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:

    Jeffrey> I'm not sure that is a wise thing to do.  Dereferencing a
    Jeffrey> null pointer is an absolute naughty thing to do according
    Jeffrey> to ANSI/ISO.  No other pointer value has that property
    Jeffrey> that I'm aware of.  Thus, I do not consider it safe or
    Jeffrey> wise to delete a check because we found a reference to
    Jeffrey> mem[p + 4].  There's no way to know what p's value was [
    Jeffrey> well, you'd know it can't be -4 :-)]

ANSI/ISO C says you can only perform pointer arithmetic inside one
array.  Certainly, in your example, we know p + 4 is not NULL.  But,
since you can't get to NULL by pointer arithmetic (it's not inside any
array, and isn't one past the end of anything), p can't be NULL
either.

But, this is like -fstrict-aliasing; people probably do this stuff.

More worrisome, in this case, is that I can imagine the compiler doing
this stuff: you write:

  int *p = (int*) 4; /* This is an I/O port.  */
  (*p) = 3;

and, for some reason, it ends up in RTL at some point as:

  int *p = 0;
  *(p + 4) = 3;

I can imagine cases where the compiler doing this would make sense,
even though the second program would be invalid C if written directly.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


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