From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32524 invoked by alias); 25 Jan 2002 19:36:37 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 32465 invoked from network); 25 Jan 2002 19:36:35 -0000 Received: from unknown (HELO boden.synopsys.com) (204.176.20.19) by sources.redhat.com with SMTP; 25 Jan 2002 19:36:35 -0000 Received: from maiden.synopsys.com (maiden.synopsys.com [146.225.100.170]) by boden.synopsys.com (Postfix) with ESMTP id 661D9DB29; Fri, 25 Jan 2002 11:36:35 -0800 (PST) Received: from atrus.synopsys.com (localhost [127.0.0.1]) by maiden.synopsys.com (8.9.1/8.9.1) with ESMTP id LAA19690; Fri, 25 Jan 2002 11:36:46 -0800 (PST) From: Joe Buck Received: (from jbuck@localhost) by atrus.synopsys.com (8.9.3+Sun/8.9.1) id LAA21076; Fri, 25 Jan 2002 11:36:33 -0800 (PST) Message-Id: <200201251936.LAA21076@atrus.synopsys.com> Subject: Re: g++ and aliasing bools To: dje@watson.ibm.com (David Edelsohn) Date: Fri, 25 Jan 2002 11:53:00 -0000 Cc: mark@codesourcery.com (Mark Mitchell), pcarlini@unitus.it (Paolo Carlini), gcc@gcc.gnu.org In-Reply-To: <200201251838.NAA29128@makai.watson.ibm.com> from "David Edelsohn" at Jan 25, 2002 01:38:53 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-01/txt/msg01674.txt.bz2 David E. writes: > You originally contributed c_get_alias_set(). Would you please > provide us with a reference to the proof showing that it is safe for C? Dan sabotaged his own cause by bringing up a lot of extraneous arguments that just sidetracked people, I think. Let's proceed in another way. I think that, for the purpose of Dan's proof, he should be allowed to accept as a postulate that c_get_alias_set is correct when applied to C. If this postulate is not acceptable, then it seems that if someone owes us a proof, it is Mark, not Daniel. However, c_get_alias_set has been there long enough that we have reasonable confidence in it. I think it's also fair to assume as a postulate that the current conservative cxx_get_alias_set is safe. Again, long experience. Given that, let's look at Dan's proposal: currently we assume that all aggregates alias with each other in C++, but for C, we compute aliasing specifically based on structs and their members. The way we do this is by putting all aggregates in alias set 0 in C++. Dan's proposed modification, in pseudocode, is cxx_get_alias_set () { if (AGGREGATE_TYPE && HAS_BASECLASSES && HAS_VIRTUALS) return 0; return c_get_alias_set(); } Let's assume that, while c_get_alias_set is correct, Dan is wrong, for purposes of the proof, and that his change introduces an error that was not there before. Then there must be an aggregate and another object, neither of which has baseclasses or virtual functions, and neither of which would alias in C, but that alias in C++. Let's assume that this is so. This means that I can construct a legal C++ program that creates the extra aliasing; this program cannot be a legal C program as well. There is only one extra C++ operation that will allow "type punning" that doesn't exist in C: casting between base classes and derived classes. But any derived class pointer or reference, once constructed, will go into alias set 0. Even if the derived class pointer is created later, from the base pointer, the compiler will not assume that it can use its knowledge of the base object to learn anything about the extra members. While this is not a formal proof, it's enough to convince me that Daniel's change is safe.