c/8083 GCC Aliasing bug

c/8083 GCC Aliasing bug

[Bruce Korb]

The following reply was made to PR c/8083; it has been noted by GNATS.

From: Bruce Korb <bkorb@pacbell.net>
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 <dewar@gnat.com>
 :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.