From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4626 invoked by alias); 1 Oct 2002 03:50:03 -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 4619 invoked from network); 1 Oct 2002 03:50:02 -0000 Received: from unknown (HELO mtvmime02.veritas.com) (143.127.3.10) by sources.redhat.com with SMTP; 1 Oct 2002 03:50:02 -0000 Received: from megami (unverified) by mtvmime02.veritas.com (Content Technologies SMTPRS 4.2.10) with SMTP id ; Mon, 30 Sep 2002 20:50:07 -0700 Received: from pacbell.net([172.22.12.210]) (2574 bytes) by megami via sendmail with P:esmtp/R:smart_host/T:smtp (sender: ) id for ; Mon, 30 Sep 2002 20:49:58 -0700 (PDT) (Smail-3.2.0.101 1997-Dec-17 #15 built 2001-Aug-30) Message-ID: <3D991C7D.CEA72179@pacbell.net> Date: Mon, 30 Sep 2002 21:42:00 -0000 From: Bruce Korb Organization: Home X-Accept-Language: en MIME-Version: 1.0 To: Alexandre Oliva CC: Robert Dewar , zack@codesourcery.com, gcc@gcc.gnu.org Subject: Re: module level flags References: <20020929094132.3E262F2D68@nile.gnat.com> <3D972FFC.641F4F46@pacbell.net> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg01278.txt.bz2 Alexandre Oliva wrote: > > On Sep 29, 2002, Bruce Korb wrote: > > > In this case, the issue is that the aliasing analysis is incomplete. > > If a routine contains explicit code to cast the address of an object > > of type 'a' to pointers to type b, then in the context of that > > routine it is reasonable to presume a '*b' can refer an object 'a'. > > They are equivalent. > > Now what if you factor the code that uses *b into a separate function? You have that problem with "void*" aliasing or any other kind of aliasing. Some you are required to guard against (assume aliasing), some not. My claim is that ANSI ought to have considered intptr_t as being potentially aliased by arbitrary pointers, _exactly_ the same way void* values are treated. And, my argument went on, if you aren't going to support "obvious" cases such as this, then you should support hard errors on obvious cases. It is clear you cannot warn about all potential cases. > All of a sudden, the code stops working because within that separate > function it is not known that *b may alias an object of type stumble? So, to protect users from this catastrophe, you silently destroy the efficacy of a pointer causing their programs to head south without a discernible error or even a warning. Phooey. It is true you can stretch stuff into improbable cases whereby you cannot effectively warn; you cannot detect the aliasing; and you wind up with a bug. That's not a sufficient excuse for throwing up your hands on being helpful and silently generate trash. Here's what it comes down to: where feasible (99% of cases), either emit working code (as I suggest), or emit a hard error. But at least warn. Currently, it's none of these.