From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AC2BA385AC1C; Wed, 7 Sep 2022 04:28:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AC2BA385AC1C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1662524924; bh=q8VSJCAJ3xEDk8R0b0+lQGr7JAt+pvvEJPMuO+1nS1A=; h=From:To:Subject:Date:In-Reply-To:References:From; b=g+TforoFGptySurx+ZWq55M05I3y0EKReXdwA7wRVn8aajzm8TWXpiS0A6eEA5l5I VzKdJ+/L+43YRmTA4MITPqd7nQNlBq3FesKUkIvTo13yu59UtcvdvZW+kjpSlm9aEs 1k03VIw4LamM1t1QcxrzDAsm/Ywjrzxjlt9+eLQg= From: "linkw 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: Wed, 07 Sep 2022 04:28:42 +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: linkw 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 #10 from Kewen Lin --- (In reply to Segher Boessenkool from comment #9) > Although, preferably we should not allow assigning one opaque type to ano= ther > opaque type just because they will eventually use the same mode, not with= out > warning anyway? Or is that unavoidable? Compare assigning a V4SI to a V= 4SF. >=20 IIUC, you meant the assignment happening for two different opaque types, th= en it's a conversion? If so, I think we can check it in rs6000_invalid_convers= ion, currently it just simply checks the modes. If we have two different opaque types mapping to one same mode, we can further check if the things like TYPE_CANONICAL match. > 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 :-) This patch doesn't handle that, the main issue here is that some cv-qualifi= ed opaque type can cause ICE in type verification during LTO. IMHO, opaque typ= es conversion issue looks like a separated issue and it can be handled in targ= et hook invalid_conversion. But I guess you want a more generic check? And as= you pointed out, there is no such scenario that two opaque types have the same mode, not sure if we really want to handle it for now. :-)=