[Bug tree-optimization/87314] pointless comparison of malloc result to a string not eliminated

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 45399
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45399&action=edit
patch for the string cases

OK, these special cases could be handled easily.  They should already
be covered by

/* When the addresses are not directly of decls compare base and offset.
   This implements some remaining parts of fold_comparison address
   comparisons but still no complete part of it.  Still it is good
   enough to make fold_stmt not regress when not dispatching to fold_binary. 
*/
(for cmp (simple_comparison)
 (simplify
  (cmp (convert1?@2 addr@0) (convert2? addr@1))
  (with

but we fall into

      (if (equal == 0
           && DECL_P (base0) && DECL_P (base1)
           /* If we compare this as integers require equal offset.  */
           && (!INTEGRAL_TYPE_P (TREE_TYPE (@2))
               || known_eq (off0, off1)))
       (switch
        (if (cmp == EQ_EXPR)
         { constant_boolean_node (false, type); })
        (if (cmp == NE_EXPR)
         { constant_boolean_node (true, type); })))))))))

which only handles decl vs. decl.

I'm not sure how to handle "foo" ==/!= "foo" though, dependent on string
merging they could be either equal or not equal.  I guess similar
for "foobar"+3 and "bar"?

So sth like the attached which is conservative about string-merging (delaying
to runtime).