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).
