From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14007 invoked by alias); 29 Sep 2002 17:16:02 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 13993 invoked by uid 71); 29 Sep 2002 17:16:02 -0000 Date: Sun, 29 Sep 2002 10:16:00 -0000 Message-ID: <20020929171602.13991.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Bruce Korb Subject: c/8083 GCC Aliasing bug Reply-To: Bruce Korb X-SW-Source: 2002-09/txt/msg00826.txt.bz2 List-Id: The following reply was made to PR c/8083; it has been noted by GNATS. From: Bruce Korb To: gcc-gnats@gcc.gnu.org Cc: Subject: c/8083 GCC Aliasing bug Date: Sun, 29 Sep 2002 10:15:07 -0700 :To: Robert Dewar :CC: zack@codesourcery.com, gcc@gcc.gnu.org, bkorb@pacbell.net :References: <20020929094132.3E262F2D68@nile.gnat.com> Robert Dewar wrote: > Can you justify this position from the standard? Just because something is in the standard doesn't mean it is right. The committees make mistakes. 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 such a pointer can refer an object 'a'. They are equivalent. If the standard says otherwise, then this construct: (mumble*)&stumble where 'stumble' is not of type 'mumble' must be deemed a hard error. If it is both not a hard error and the compiler is reserving the "right" (??) to render the resulting pointer ineffective, then GCC is reserving the right to destroy the workings of a program. This is wrong. I don't care if the standard says otherwise. Of course, what is particularly obnoxious about the particular circumstance is that the object that triggered the issue is a YYSTYPE. This is a YACC/Bison anonymous bucket. It is specifically intended that it be recast as a scalar or a pointer to arbitrary objects. Perhaps most of the real world problems would be solved by adding ``intptr_t'' and ``uintptr_t'' to the list of ``void*'' and ``char*'' types that can be aliased by pointers to arbitrary things. That would solve my specific problem, but I think the proper solution is to have specific casts enable multi-type aliasing within the context of the specific routine.