From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9A5A43858D28; Mon, 6 May 2024 11:19:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9A5A43858D28 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1714994365; bh=Ogx+gTB1Fqyx8R2W8brOQx7DqHFoDQekdSGOLhmwxnM=; h=From:To:Subject:Date:From; b=c3UMjhWMBSDzVAxOFSudBgGc45D7b3l5QVKGAPsA7uOTYaB8XjkCb9yuC6fIbC9mV g3vBTrCdqZx3xwmOu9rduUNWHcG1IwqGHS0qvI3X3MbOgLiSAzO1HRwqjRfLVo+mve q06Z930SUV9aFFwpOzhwNWMBgDenbMX2tNyMSIR4= From: "muecker at gwdg dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/114959] New: incorrect TBAA for drived types involving function types Date: Mon, 06 May 2024 11:19:24 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: muecker at gwdg dot de X-Bugzilla-Status: UNCONFIRMED 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114959 Bug ID: 114959 Summary: incorrect TBAA for drived types involving function types Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: muecker at gwdg dot de Target Milestone: --- The example below shows that aliasing analysis treats some derived types as incompatible even though they are derived from compatible types char (*)[1]= and char (*)[] and should then be compatible themselves. The effect type rules are defined in "6.5 Expressions" and allows accesses = with=20 =E2=80=94 a type compatible with the effective type of the object, =E2=80=94 a qualified version of a type compatible with the effective type = of the object, =E2=80=94 a type that is the signed or unsigned type corresponding to the e= ffective type of the object, =E2=80=94 a type that is the signed or unsigned type corresponding to a qua= lified version of the effective type of the object, =E2=80=94 an aggregate or union type that includes one of the aforementione= d types among its members (including, recursively, a member of a subaggregate or contained union), or =E2=80=94 a character type. The relevant condition is the first which refers to type compatibility. Type compatibility rules are defined in "6.2.7 Type compatibility and compo= site type" "Two types are compatible types if they are the same. Additional rules for determining whether two types are compatible are described in 6.7.2 for type specifiers, in 6.7.3 for type qualifiers, and in 6.7.6 for declarators.58) Moreover, two complete structure, union, or enumerated types declared..." In 6.7.6 we then have "For two pointer types to be compatible, both shall be identically qualified and both shall be pointers to compatible types." "For two array types to be compatible, both shall have compatible element types, and if both size specifiers are present, and are integer constant expressions, then both size specifiers shall have the same constant value." "For two function types to be compatible, both shall specify compatible ret= urn types. Moreover, the parameter type lists shall agree in the number of parameters and in use of the final ellipsis; corresponding parameters shall have compatible types. In the determination of type compatibility and of a composite type, each parameter declared with function or array type is take= n as having the adjusted type and each parameter declared with qualified type is taken as having the unqualified version of its declared type." So type compatibility builds up recursively and types derived in the same w= ay from different but compatible types are compatible. Example: https://godbolt.org/z/rTsE3PhKc #define COMPAT typedef char (*(*t0)())[]; typedef char (*(*t1)())[1]; #ifdef COMPAT typedef char (*(*t2)())[/*2*/]; #else typedef char (*(*t2)())[2]; #endif //[[gnu::noinline]] t0 foo(t0 *x, t0 *y, t0 u, t0 v) { t1 *a =3D x; t2 *b =3D y; #ifdef COMPAT _Static_assert(_Generic(*b, typeof(*a): 1, default: 0), ""); #endif (*a) =3D u; // since *a and *b alias and the types are compatible, // this should overwrite the result (*b) =3D v;=20=20=20 return *a; } char (*(a()))[1] { return 0; } char (*(b()))[2] { return 0; } int main() { t0 t; return &a =3D=3D foo(&t, &t, &a, &b); }=