This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: proposed patch for gcse.c (delete_null_pointer_checks)
- To: law at cygnus dot com
- Subject: Re: proposed patch for gcse.c (delete_null_pointer_checks)
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Thu, 28 Oct 1999 08:15:26 -0700
- Cc: trt at unx dot sas dot com, gcc-patches at gcc dot gnu dot org
- Organization: CodeSourcery, LLC
- References: <199910271731.AA23873@newlgn54.unx.sas.com><24046.941100957@upchuck>
>>>>> "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