From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id C7C31385803D; Wed,  5 Jan 2022 19:56:18 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C7C31385803D
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/89074] valid pointer equality constexpr comparison rejected
Date: Wed, 05 Jan 2022 19:56:18 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 9.0
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-89074-4-XffPIaFmT8@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-89074-4@http.gcc.gnu.org/bugzilla/>
References: <bug-89074-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jan 2022 19:56:18 -0000

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

--- 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 tha=
t):
  /* Assume that automatic variables can't be adjacent to global
     variables.  */
  else if (is_global_var (base0) !=3D is_global_var (base1))
    ;
or similarly there is code that assumes that string literals won't be adjac=
ent
to  user variables or vice versa:
  if ((DECL_P (base0) && TREE_CODE (base1) =3D=3D STRING_CST)
       || (TREE_CODE (base0) =3D=3D STRING_CST && DECL_P (base1))
       || (TREE_CODE (base0) =3D=3D STRING_CST
           && TREE_CODE (base1) =3D=3D STRING_CST
           && ioff0 >=3D 0 && ioff1 >=3D 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)) !=3D 0))
    ;
The question is what do we want for folding_initializer cases.
Do we want to add !folding_initializer && to the is_global_var !=3D 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] !=3D &"foo"[0] is
pedantically
not a constant expression, but if it was e.g. const char *s =3D "foo"; &s[0=
] !=3D
&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).=