This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/21479] optimizer removes incorrectly variable comparision in if clause
- From: "schlie at comcast dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 17 May 2005 21:25:01 -0000
- Subject: [Bug target/21479] optimizer removes incorrectly variable comparision in if clause
- References: <20050509222003.21479.chaac@nic.fi>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From schlie at comcast dot net 2005-05-17 21:24 -------
(In reply to comment #10)
> (In reply to comment #8)
> > - yes, however as the loigical extention of:
> > "a null reference is undefined" => "may trap" => "will trap"
> > is simply wrong, and is not justifyable; such an optimization
> > is target specific, as it depends on "will trap" target semantics.
>
> Right. However, the logic here is simply "a null pointer dereference is
> undefined" => "if you still do it, your code may behave however gcc feels
> like", which is backed by the C standard. So this is invalid.
No, only the "null pointer dereference" itself is undefined. which means
that upon a null pointer reference any or no value may be returned.
Is says, implies, and grants no rights what so ever to an implementation,
to define that an arbitrary behavior will occure which may be subsequenlty
relied upon to occured unless the implementation inforces that behavior.
More specifically, unless GCC can warrent that a "null pointer dereference"
will trap will terminate program execution, it must preserve the semantics
of the remaining programs execution as defined by the standard, which
includes but not limited to preserving null-pointer comparision semantics,
as defined by the standard; as not to do so would be in violation of the same.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21479