[Bug c++/78655] gcc doesn't exploit the fact that the result of pointer addition can not be nullptr

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2016-12-06
                 CC|                            |law at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  It might be possible to rely on this nowadays where we make sure
not to transform uintptr_t arithmetic to pointer arithmetic in the IL.

I think that even nullptr + X is invalid.

But for the testcase we'd require threading the jump across the
backedge (FSM threading is not looking at get_ptr_nonnull ()).

VRP parts:

@@ -1145,6 +1147,13 @@ vrp_stmt_computes_nonzero (gimple *stmt,
        }
     }

+  if (flag_delete_null_pointer_checks
+      && is_gimple_assign (stmt)
+      && is_gimple_assign (stmt)
+      && gimple_assign_rhs_code (stmt) == POINTER_PLUS_EXPR
+      && tree_expr_nonzero_p (gimple_assign_rhs2 (stmt)))
+    return true;
+
   return false;
 }

@@ -4873,7 +4854,13 @@ infer_value_range (gimple *stmt, tree op
        return false;
     }

-  if (infer_nonnull_range (stmt, op))
+  if (infer_nonnull_range (stmt, op)
+      /* PTR + X with X != 0 is invalid when PTR is a null pointer.  */
+      || (flag_delete_null_pointer_checks
+         && is_gimple_assign (stmt)
+         && gimple_assign_rhs1 (stmt) == op
+         && gimple_assign_rhs_code (stmt) == POINTER_PLUS_EXPR
+         && tree_expr_nonzero_p (gimple_assign_rhs2 (stmt))))
     {
       *val_p = build_int_cst (TREE_TYPE (op), 0);
       *comp_code_p = NE_EXPR;


Of course I wonder why the check is here in the first place...  Is placement
new valid for nullptr?