From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 321773858410; Wed, 17 Nov 2021 21:49:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 321773858410 From: "slyfox at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/103292] [12 regression] xorg-server-1.20.13 -Werror=array-bounds false positive on unions Date: Wed, 17 Nov 2021 21:49:06 +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: 12.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: slyfox at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2021 21:49:06 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103292 --- Comment #2 from Sergei Trofimovich --- (In reply to Martin Sebor from comment #1) > The warning is intended. The program allocates an object of a size that's > smaller than the size of the type used to access it: >=20 > pPicture->pSourcePict =3D (union _SourcePict*) malloc(sizeof(struct > _PictSolidFill)); > pPicture->pSourcePict->type =3D 0; >=20 > It's not valid to access an object of one type using an lvalue of another= .=20 > In simple cases GCC diagnoses violations of this requirement by > -Wstrict-aliasing. -Warray-bounds doesn't detect aliasing violations but= it > does detect a subset of the problem that's apparent when the size of the > lvalue's type is greater than the size of the object. The object must be > big enough for the whole lvalue, even if the accessed member is within the > bounds of the smaller object. >=20 > The following is a smaller test case that should make the issue clearer.= =20 > See also pr102151 for a similar report. >=20 > $ cat a.c && gcc -O2 -S -Wall a.c > struct A { char a[1]; }; > struct B { char a[2]; }; > union U { struct A a; struct B b; }; >=20 > void* f (void) > { > union U *p =3D __builtin_malloc (sizeof (struct A)); > p->a.a[0] =3D 0; > return p; > } > a.c: In function =E2=80=98f=E2=80=99: > a.c:8:4: warning: array subscript =E2=80=98union U[0]=E2=80=99 is partly = outside array > bounds of =E2=80=98unsigned char[1]=E2=80=99 [-Warray-bounds] > 8 | p->a.a[0] =3D 0; > | ^~ > a.c:7:16: note: object of size 1 allocated by =E2=80=98__builtin_malloc= =E2=80=99 > 7 | union U *p =3D __builtin_malloc (sizeof (struct A)); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Aha, that makes sense. Filed upstream report as https://gitlab.freedesktop.org/xorg/xserver/-/issues/1256 Related question: It sounds like this diagnostic is somewhat related to -fstrict-aliasing. xo= rg builds with -fno-strict-aliasing. Would it be fair to say the access in that case is reasonable and -Warray-bounds is a false positive?=