From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D1BEF385841A; Wed, 7 Sep 2022 13:08:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D1BEF385841A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1662556093; bh=WpyvQdUCLVr8zKoR1bXS3gMkMy9JQMT5AHMQH8TWnco=; h=From:To:Subject:Date:In-Reply-To:References:From; b=b5uLa0hMzavxdrrMeFBy4Fz2WG1C+4GcjdHbNiVbAJ0MjDg6bYgVXtR/xjCt8KF2Z 6IpiBTfeb9Yv4WyNp5A7DuVxOlnMDN4mtwYHHvGbndmzeO4ltwwF2KE0HBykjaxJw6 /OCyTEp2XRxssqiHMHHR1UxHyTqVSlA4epWASfjQ= From: "segher at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/106833] Miss to handle OPAQUE_TYPE specially in verify_type Date: Wed, 07 Sep 2022 13:08:13 +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 #12 from Segher Boessenkool --- (In reply to Kewen Lin from comment #10) > (In reply to Segher Boessenkool from comment #9) > > Although, preferably we should not allow assigning one opaque type to a= nother > > opaque type just because they will eventually use the same mode, not wi= thout > > warning anyway? Or is that unavoidable? Compare assigning a V4SI to a= V4SF. >=20 > IIUC, you meant the assignment happening for two different opaque types, > then it's a conversion? Yes exactly. > If so, I think we can check it in > rs6000_invalid_conversion, currently it just simply checks the modes. Yup. > If we > have two different opaque types mapping to one same mode, we can further > check if the things like TYPE_CANONICAL match. Like that. It isn't urgent -- we currently have only one type for each of our two opaque modes -- but if we allow too much here, we would need a sepa= rate mode for each opaque thing we want to distinguish, which is contrary to the point of having it :-) > > 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 :-) >=20 > This patch doesn't handle that, the main issue here is that some > cv-qualified opaque type can cause ICE in type verification during LTO. > IMHO, opaque types conversion issue looks like a separated issue and it c= an > be handled in target 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. :-) I think it can be handled generically, no target code is needed for it.=