public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/21305] flag_delete_null_pointer_checks is target specific
       [not found] <bug-21305-4@http.gcc.gnu.org/bugzilla/>
@ 2012-01-11 13:13 ` rguenth at gcc dot gnu.org
  0 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-01-11 13:13 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21305

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-11 13:13:29 UTC ---
6.5.3.2/4 says that the behavior unary * operator is undefined if the
pointer is a null pointer.  For QOI reasons several targets / frontends have
-fdelete-null-pointer-checks disabled.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug middle-end/21305] flag_delete_null_pointer_checks is target specific
  2005-04-30 20:48 [Bug tree-optimization/21305] New: " roger at eyesopen dot com
                   ` (3 preceding siblings ...)
  2005-05-09 22:33 ` pinskia at gcc dot gnu dot org
@ 2005-05-19  3:55 ` schlie at comcast dot net
  4 siblings, 0 replies; 6+ messages in thread
From: schlie at comcast dot net @ 2005-05-19  3:55 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From schlie at comcast dot net  2005-05-19 03:55 -------
(In reply to comment #0)
> The current -fdelete_null_pointer_checks implementation makes assumptions that
> the target processor will trap on reads or writes to address zero.  Unfortunately,
> these assumptions are target (often operating system) specific.
> ...
> I propose we should add target macros, TARGET_NULL_POINTER_READABLE and
> TARGET_NULL_POINTER_WRITABLE and control the effects of the
> -fdelete_null_pointer_checks with that.  The current situation is that
> these transformations are enabled automatically at -O2 without regard to
> the target environment.

Correct, and as coppied from PR21479:

> >    "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 occure 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.

("If -O2 or greater, enable -fdelete-null-pointer-checks" can not be
 unconditionally enabled without violating the semantics of the language.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21305


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug middle-end/21305] flag_delete_null_pointer_checks is target specific
  2005-04-30 20:48 [Bug tree-optimization/21305] New: " roger at eyesopen dot com
                   ` (2 preceding siblings ...)
  2005-04-30 21:19 ` pinskia at gcc dot gnu dot org
@ 2005-05-09 22:33 ` pinskia at gcc dot gnu dot org
  2005-05-19  3:55 ` schlie at comcast dot net
  4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-05-09 22:33 UTC (permalink / raw)
  To: gcc-bugs



-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |21479
              nThis|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21305


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug middle-end/21305] flag_delete_null_pointer_checks is target specific
  2005-04-30 20:48 [Bug tree-optimization/21305] New: " roger at eyesopen dot com
  2005-04-30 21:13 ` [Bug middle-end/21305] " pinskia at gcc dot gnu dot org
  2005-04-30 21:18 ` roger at eyesopen dot com
@ 2005-04-30 21:19 ` pinskia at gcc dot gnu dot org
  2005-05-09 22:33 ` pinskia at gcc dot gnu dot org
  2005-05-19  3:55 ` schlie at comcast dot net
  4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-04-30 21:19 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-30 21:19 -------
Note the flag is old, it comes from:
Thu Sep 23 13:55:21 1999  Jeffrey A Law  (law@cygnus.com)
        
        * invoke.texi: Document -fdelete-null-pointer-checks
        * toplev.c (flag_delete_null_pointer_checks): New.
        (f_options): Add entry for -fdelete-null-pointer-checks.
        (rest_of_compilation): Conditionalize null pointer check
        elimination on flag_delete_null_pointer_checks.
        (main): If -O2 or greater, enable -fdelete-null-pointer-checks
        

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21305


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug middle-end/21305] flag_delete_null_pointer_checks is target specific
  2005-04-30 20:48 [Bug tree-optimization/21305] New: " roger at eyesopen dot com
  2005-04-30 21:13 ` [Bug middle-end/21305] " pinskia at gcc dot gnu dot org
@ 2005-04-30 21:18 ` roger at eyesopen dot com
  2005-04-30 21:19 ` pinskia at gcc dot gnu dot org
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: roger at eyesopen dot com @ 2005-04-30 21:18 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From roger at eyesopen dot com  2005-04-30 21:18 -------
Apparently the behaviour of this code is undefined in the C/C++ language
standards, though this transformation is performed in front-end independent
code.  Perhaps its only a quality of implementation issue.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21305


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug middle-end/21305] flag_delete_null_pointer_checks is target specific
  2005-04-30 20:48 [Bug tree-optimization/21305] New: " roger at eyesopen dot com
@ 2005-04-30 21:13 ` pinskia at gcc dot gnu dot org
  2005-04-30 21:18 ` roger at eyesopen dot com
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-04-30 21:13 UTC (permalink / raw)
  To: gcc-bugs



-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|tree-optimization           |middle-end


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21305


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2012-01-11 13:13 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bug-21305-4@http.gcc.gnu.org/bugzilla/>
2012-01-11 13:13 ` [Bug middle-end/21305] flag_delete_null_pointer_checks is target specific rguenth at gcc dot gnu.org
2005-04-30 20:48 [Bug tree-optimization/21305] New: " roger at eyesopen dot com
2005-04-30 21:13 ` [Bug middle-end/21305] " pinskia at gcc dot gnu dot org
2005-04-30 21:18 ` roger at eyesopen dot com
2005-04-30 21:19 ` pinskia at gcc dot gnu dot org
2005-05-09 22:33 ` pinskia at gcc dot gnu dot org
2005-05-19  3:55 ` schlie at comcast dot net

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).