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 580483858409; Thu, 16 Feb 2023 12:08:00 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 580483858409
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1676549280;
	bh=sxNKMXb30+n3yngXflf8MWldhjYtV8G7TLxKURNBkGE=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=kt6JuXXBi0TpCE3+pVI+4ZTlRJIV5hITqyYNe+1nDYib9Y5dP8W9KQGwicJB1iSp5
	 Clx3NvMAv9ckmLBx3YxCJFivxluV8fqqb1cDJS1GzbS/HnnHMdmNrFj6YHKrJ7tbx/
	 iRj7gAhIExZ1nSm7hd4/4RLfHXHpi6zVbfv64bk0=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/108721] [10/11/12/13 Regression] csmith: really old
 bug with -O2
Date: Thu, 16 Feb 2023 12:07:59 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 10.5
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-108721-4-h8nUkUoJzF@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108721-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108721-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
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
In the reduced testcase there is certainly an aliasing violation.
struct {
  unsigned f0
} g_95 =3D {65531};
...
*g_412 =3D &g_95;
...
  --g_95.f0;
  *g_86 =3D g_613 || 0;
  *g_412 =3D 0;
  short *l_873 =3D &g_95;
  --*l_873;
even after making g_412 unsigned *g_412 =3D &g_95.f0; it gets different res=
ults,
but
while short *l_873 =3D &g_95.f0; does as well, doing
  typedef short sa __attribute__((may_alias));
  sa *l_873 =3D &g_95.f0;
one gets the same result.
Now, in the original testcase it actually uses
union U0 {
   uint16_t f0;
   int64_t f1;
   int64_t f2;
   uint32_t f3;
};
static union U0 g_95 =3D {65531UL};
but then has
static int64_t *g_279 =3D &g_95.f2;
...
    int64_t *l_939 =3D &g_95.f2;
...
        uint16_t *l_873 =3D &g_95.f0;
...
                uint32_t *l_933[8] =3D
{&g_95.f3,&g_95.f3,&g_95.f3,&g_95.f3,&g_95.f3,&g_95.f3,&g_95.f3,&g_95.f3};
...
        int64_t *l_425 =3D &g_95.f2;
...
        uint16_t *l_597 =3D &g_95.f0;
etc.  Now, all of this doesn't necessarily mean it is UB, but it is a strong
indication that it very likely is.  Standard C/C++ doesn't allow type punni=
ng
through union, only one of the members can be active at a time, GCC allows =
it,
but for aliasing requires that accesses have the union type visible to the
compiler on the access.  Taking addresses of different union members means =
that
most likely that isn't followed, UB would be whenever some union member is
stored and another one read through a pointer without the union in access p=
ath
etc.

Now, I think some of the readings of the standard say that whenever say
uint16_t and uint32_t appear in some union anywhere, one basically needs to
treat them as the same alias set, but such reading makes TBAA totally usele=
ss.=20
So if csmith follows that reading, it is indeed unsafe for TBAA.=