From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay.tugraz.at (mailrelay.tugraz.at [129.27.2.202]) by sourceware.org (Postfix) with ESMTPS id EF34B3858D28 for ; Tue, 2 Apr 2024 21:22:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EF34B3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=tugraz.at Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tugraz.at ARC-Filter: OpenARC Filter v1.0.0 sourceware.org EF34B3858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=129.27.2.202 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712092945; cv=none; b=fmCuWHs3cGU47t40uIadnBTz+JBILSxpcZL9GRNgpcvDDbTVGC6sHF05bgycOfjwpNCvmFQ69hKYf9xTMv5w6TQhAdGSujnI2tKb40GcWoXkkVvKFqGuy64QZWHGBUAvgzliKGH95bJFY6ltDUhOlXjxklanrcc3NbcP4lIhymo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712092945; c=relaxed/simple; bh=Zol7tL2iQrNOwLHYt+IDeqMgA3pKoriBJdIGhOKFZzo=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=DGRa0R/2kwohT2MxZOMk6hjJIWy+pHqBPtYgpnmv+9wPBzbogTKdZrENSRe/k+E6HHRwmNm9wltlmuUt4MrcXphILEhmPnoDr5TlODTtLg+4wfmafltd9P/Ek/n2dg1kvrNo8AvvfI0WJs1eRoF+i43iRDUxKWyPujcrcEQOMjE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from vra-169-244.tugraz.at (vra-169-244.tugraz.at [129.27.169.244]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4V8LS55NkGz1LM0Q; Tue, 2 Apr 2024 23:22:13 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4V8LS55NkGz1LM0Q DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1712092933; bh=4T8VQbcRK5qbvJMdPvz8jLe9Kxw1RZ+/mebQDgpFoDg=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=X6fn0OvwJcrtRn2ZehgeTW7/yY9Sw33U5K8lX0eHkFj8GDh4baCW5QW6/rhm3YiZ5 H1gLZEvfmNlRQE6q3eoTDbcAbxcdNCFzyCRtmu1o1weaNdIzUxJvXZ1Jq9Z6BKwy8o 3oZf2k8ZoS9XQFux8EkIcN+s9sSkVZX6sVMrYdnI= Message-ID: <8e8176ce13f9c4af19f9c9848f28f99efecf75a8.camel@tugraz.at> Subject: Re: [C PATCH] fix aliasing for structures/unions with incomplete types From: Martin Uecker To: Joseph Myers Cc: gcc-patches@gcc.gnu.org Date: Tue, 02 Apr 2024 23:22:13 +0200 In-Reply-To: <4aaeac41-2c95-8a5-85ea-f24137c9cee0@redhat.com> References: <02a9b94e4d653b6f1b9f89a1b62187f46e871738.camel@tugraz.at> <0379aa34b5050780f99894b4040e416e3e95e851.camel@tugraz.at> <4aaeac41-2c95-8a5-85ea-f24137c9cee0@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-TUG-Backscatter-control: G/VXY7/6zeyuAY/PU2/0qw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116 X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Am Dienstag, dem 02.04.2024 um 20:42 +0000 schrieb Joseph Myers: > On Tue, 2 Apr 2024, Martin Uecker wrote: >=20 > > [C23]fix aliasing for structures/unions with incomplete types > >=20 > > When incomplete structure/union types are completed later, compatibilit= y > > of struct types that contain pointers to such types changes. When form= ing > > equivalence classes for TYPE_CANONICAL, we therefor need to be conserva= tive > > and treat all structs with the same tag which are pointer targets as > > equivalent. >=20 > I don't see how what it done is actually about "which are pointer=20 > targets". Right, I see now that the description needs to be improved. This refers only=C2=A0to targets of pointers included somewhere in the type we process for purposes of determining the equivalence class of this type (but not for other contexts). >=20 > > @@ -1355,6 +1356,7 @@ comptypes_internal (const_tree type1, const_tree = type2, > > /* Do not remove mode information. */ > > if (TYPE_MODE (t1) !=3D TYPE_MODE (t2)) > > return false; > > + data->pointedto =3D true; > > return comptypes_internal (TREE_TYPE (t1), TREE_TYPE (t2), data)= ; >=20 > This appears to be more like "which are the targets of pointers that *hav= e=20 > just been compared in the present comptypes call*". Not which are target= s=20 > of some other pointers not involved in that call. Correct. >=20 > Maybe some such logic based only on pointers compared in the present call= =20 > makes sense for some purposes, but it's not clear to me that either this= =20 > or any similar approach is a good approach for TYPE_CANONICAL - couldn't= =20 > that mean that two types are considered equivalent for TYPE_CANONICAL at= =20 > one point in the translation unit, but no longer equivalent at some later= =20 > point when the comparison takes place in the context of comparing two=20 > other pointer types? They would always be considered equivalent when pointed to from another struct (or indirectly from a type nested in this struct) for purposes of determining the equivalence class of this struct. When not a pointer target, i.e. when considering the struct type itself for which we compute TYPE_CANONICAL or another struct type directly used for a member, then the types are compared by recursing=C2=A0into them. Such= =C2=A0 types can never be incomplete at this point, so this is also stable propert= y. To summarize: for determining equivalence classes we always stop the recursion after following pointers into other structs. We give the same TYPE_CANONICAL to the following two structs foo: struct foo { struct aa { int x; } *p; }; struct foo { struct aa { float x; } *p; }; while we give different TYPE_CANONICAL to struct bar { struct aa { int x; } p; }; struct bar { struct aa { float x; } p; }; (not pointer). The reason is that for the struct foo's there could be a=20 struct foo { struct aa *p; }; with incomplete type struct aa that later turns out to be compatible with either of them. So we have to put them all into the same=C2=A0 equivalence class. (a potential alternative is to compute the classes only at the very end when all types have stablized, but this would require much more changes and another pass over all the types.) Note that the TYPE_CANONICAL for the aa's is not affected in any case and always computed based on *their* content independent of whether they are pointer targets or not. (but this reminds me to double check=C2=A0what happens with types that are never completed in a TU.). I hope this explanation makes sense. Martin >=20