From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9A61D38582B4; Tue, 6 Sep 2022 21:21:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9A61D38582B4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1662499297; bh=qWf3EVSlk9xhhHsqO0beWfFM1ZMEK6VguMdTJTp3ct4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=h5mm9akrRl4BRBuc2olBKRhXm5SRJNzzXbAn0V5NqlseVKLngliYR7jMT+9te8hR3 Z1/i/PhMqm+GQgtNDLdnTdcmCnYjmJG0gZPOrjvcalKLuiukmmQM8VKMsn6aPAFaVu aVO+ZujnHmxLNL3X2PJQld8dxJKaO1cjmDdDfqEk= From: "segher at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/106833] Handle OPAQUE_TYPE in gimple_canonical_types_compatible_p Date: Tue, 06 Sep 2022 21:21:36 +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: ice-checking X-Bugzilla-Severity: normal X-Bugzilla-Who: segher at gcc dot gnu.org 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106833 --- Comment #9 from Segher Boessenkool --- Although, preferably we should not allow assigning one opaque type to anoth= er opaque type just because they will eventually use the same mode, not without warning anyway? Or is that unavoidable? Compare assigning a V4SI to a V4S= F. I don't know if your patch does this, btw, and it isn't so easy to test, we currently have only one type for each of our opaque modes. Maybe test by adding an extra builtin type :-)=