[Bug c++/89074] valid pointer equality constexpr comparison rejected

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
There are some further questions though.
E.g. address_compare has a smart code to assume that static vars will never be
adjacent to automatic vars or vice versa (the implementation guarantees that):
  /* Assume that automatic variables can't be adjacent to global
     variables.  */
  else if (is_global_var (base0) != is_global_var (base1))
    ;
or similarly there is code that assumes that string literals won't be adjacent
to  user variables or vice versa:
  if ((DECL_P (base0) && TREE_CODE (base1) == STRING_CST)
       || (TREE_CODE (base0) == STRING_CST && DECL_P (base1))
       || (TREE_CODE (base0) == STRING_CST
           && TREE_CODE (base1) == STRING_CST
           && ioff0 >= 0 && ioff1 >= 0
           && ioff0 < TREE_STRING_LENGTH (base0)
           && ioff1 < TREE_STRING_LENGTH (base1)
          /* This is a too conservative test that the STRING_CSTs
             will not end up being string-merged.  */
           && strncmp (TREE_STRING_POINTER (base0) + ioff0,
                       TREE_STRING_POINTER (base1) + ioff1,
                       MIN (TREE_STRING_LENGTH (base0) - ioff0,
                            TREE_STRING_LENGTH (base1) - ioff1)) != 0))
    ;
The question is what do we want for folding_initializer cases.
Do we want to add !folding_initializer && to the is_global_var != checks and
the first two above (the STRING_CST vs. STRING_CST in some form is needed I
think)?
Though, there is
  else if (!DECL_P (base0) || !DECL_P (base1))
    return 2;
and so such !folding_initalizer && in there would reject valid cases where
a pointer doesn't point to start of a string or end of it.

And in another PR, we have mentioned that &"foo"[0] != &"foo"[0] is
pedantically
not a constant expression, but if it was e.g. const char *s = "foo"; &s[0] !=
&s[0], then it would be well defined, and we certainly don't track whether it
must be the same string literal or could be another one (neither does clang++
AFAIK).