From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 122003858405; Mon, 27 Sep 2021 12:25:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 122003858405 From: "mhillen at linux dot ibm.com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/101876] [s390x] vector builtin vec_permi fails to resolve with #pragma GCC target Date: Mon, 27 Sep 2021 12:25:53 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mhillen at linux dot ibm.com 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: 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: Mon, 27 Sep 2021 12:25:54 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101876 --- Comment #5 from Marius Hillenbrand --- The root cause is not the difference in alignment between vector types in itself, but the resulting "confusion" in the type system when the #pragma G= CC target switches the default vector alignment. It looks like we generally assume that the default vector alignment should = be invariant during a compile run. Failing that will break two other invariants that then result in the s390-specific vector builtins to resolve or the C++ frontend to ICE. Vector types with the same structure yet different alignments would usually= end up as type variants that link to the same TYPE_MAIN_VARIANT and TYPE_CANONI= CAL because of how they are constructed by make_vector_type: (1) construct a default variant of the vector type, (2) try to find the canonical object for that type in the hash table or add the new type as such, (3) if required at= tach the to-be-constructed type as a type variant to the canonical object. The h= ash table lookup compares alignment. Thus, retrieving a previously created canonical object in that process only works if the "default variant" in step (1) has the same alignment as before. When #pragma GCC target switches between non-VX and VX-enabled targets, we break that invariant. pre-VX, vector alignment defaults to natural alignmen= t. with -mvx, vectors align to 8 Bytes. Consequently, make_vector_type will fa= il to identify any existing "canonical objects" for vector types and add new o= nes to the hash table -- possibly resulting in multiple clusters that represent= the same vector types. For example, in=20 typedef int v4si_raw __attribute__((vector_size(16))); // aligned to 16 B typedef int v4si_raw_aligned8 __attribute__((vector_size(16), aligned(8))); #pragma GCC target("arch=3Dz13") // implies -mvx typedef int v4si_z13 __attribute__((vector_size(16))); // aligned to 8 B typedef int v4si_z13_aligned16 __attribute__((vector_size(16), aligned(16))= ); The types v4si_z13 and v4si_z13_aligned16 will fail to be associated to v4s= i as their main variant. Instead, these two will link to v4si_z13 as their main variant. The s390-specific vector builtins fail to resolve, because the code assumes that structurally equivalant vector types would have the same TYPE_MAIN_VARIANT. Similarly, the C++ frontend may hit the failing assertion that structurally equivalent types should have the same TYPE_CANONICAL (for vector types, that would point to the shared TYPE_MAIN_VARIANT).=