From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by sourceware.org (Postfix) with ESMTPS id 675FF3857B83 for ; Tue, 28 Nov 2023 10:47:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 675FF3857B83 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 675FF3857B83 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=195.135.223.130 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701168456; cv=none; b=ZEoXahU+kN02jQ9yGVePQCzd0EN+qwoICC7bT0Op8yqeMMQIM4477NgDPMkW6n0A6YD+pg8R7QbS+QSO5fe2vpUnU9yVsm9opch23ibJZwWIZ0Gc9QpGKxCkbZbge3IGif2SVrkxB6y3jYdoPKrvuwVJjgkg3+cxQpNj6l1ju4g= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701168456; c=relaxed/simple; bh=RQ9SPe7vceQhP4i09hzzFg2kYJ3P8Bcg2bbf4Izpn64=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=JFqBeETj23GmrCDxl0stodcNZgHzQiHFSq8fARoG0UWa0kEmh//igvf6P7kS9UcCSZtz7SzmYNk3JirSTTYC+73lyPm0Ej34ST4ktv/hC+1TOT35FZaKYdkfjqpREsPkokMs2gtlRET41/QXvE0g8NfpUe/xRK/kxH6ZaCBWGf0= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from relay2.suse.de (unknown [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 5569B2198E; Tue, 28 Nov 2023 10:47:34 +0000 (UTC) Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 51EC52C145; Tue, 28 Nov 2023 10:47:33 +0000 (UTC) Date: Tue, 28 Nov 2023 10:47:32 +0000 (UTC) From: Richard Biener To: Joseph Myers cc: Martin Uecker , gcc-patches@gcc.gnu.org Subject: Re: [PATCH 3/4] c23: aliasing of compatible tagged types In-Reply-To: <47966764-3dd6-8499-a798-c497dab393d@codesourcery.com> Message-ID: References: <02a9b94e4d653b6f1b9f89a1b62187f46e871738.camel@tugraz.at> <223aa096afbdbb177d4ad5245696d439ad4cf87f.camel@tugraz.at> <4337947e3d85a6796567eceb7e3470db6327f7a8.camel@tugraz.at> <47966764-3dd6-8499-a798-c497dab393d@codesourcery.com> User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1609957120-2118887572-1701168453=:21409" X-Spam-Level: X-Rspamd-Server: rspamd1 Authentication-Results: smtp-out1.suse.de; none X-Rspamd-Queue-Id: 5569B2198E X-Spam-Score: -4.00 X-Spamd-Result: default: False [-4.00 / 50.00]; REPLY(-4.00)[] X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1609957120-2118887572-1701168453=:21409 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Tue, 28 Nov 2023, Joseph Myers wrote: > On Sun, 26 Nov 2023, Martin Uecker wrote: > > > My understand is that it is used for aliasing analysis and also > > checking of conversions. TYPE_CANONICAL must be consistent with > > the idea the middle-end has about type conversions. But as long > > as we do not give the same TYPE_CANONICAL to types the middle-end > > thinks must be incompatible using its own type checking machinery, > > it should be safe even for types the C standard thinks must be > > incompatible for some reason. > > And presumably also for types that definitely can't be assigned because > they have incompatible layout through the use of different array sizes - > since the front end won't generate such assignments, it would never matter > whether the middle end considers them valid without conversion or not? I guess so. The middle-end considers an aggregate copy to have the size of the LHS, so any mismatch there (in size) is the frontends fault and will likely result in code generation with problems. > > > I also think more rationale is needed for ignoring sizes like this. Is it > > > intended for e.g. making structs with flexible array members > > > alias-compatible with similar structs with a fixed-size array? > > > > The main reason are pointers to arrays: > > > > struct foo { int (*x)[]; } > > struct foo { int (*x)[2]; }; > > struct foo { int (*x)[1]; }; > > Thanks for the explanation. > > I guess the cases involving flexible array members actually show up a bug > in the standard rather than any kind of issue with this patch - the > standard allows one structure ending with a flexible array member, and > another ending with a fixed-size array, to be compatible (and in different > translation units allowed that even before C23), but there is also clear > text in the standard showing it's not intended to require the layout to be > consistent (the fixed-size and flexible arrays might have different > offsets), and what you'd actually get with an assignment or conditional > expression mixing such structures certainly isn't clearly specified. > Maybe the right resolution for that issue with the standard would be to > make that particular case incompatible, but it would need to be raised as > an issue after C23 is out. I think from a middle-end perspective it's desirable that accessing either of the foo with size 2 and 1 through a pointer of the type of the foo with unknown size is permissible from a TBAA view. But it's not clear to me that accessing the foo with array size 2 via an lvalue of the type of foo with array size 1 is required to be supported (from a TBAA view). Richard. ---1609957120-2118887572-1701168453=:21409--