From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4617 invoked by alias); 2 Aug 2005 05:12:53 -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 4593 invoked by uid 22791); 2 Aug 2005 05:12:46 -0000 Received: from yosemite.airs.com (HELO yosemite.airs.com) (205.217.158.180) by sourceware.org (qpsmtpd/0.30-dev) with SMTP; Tue, 02 Aug 2005 05:12:46 +0000 Received: (qmail 27102 invoked by uid 10); 2 Aug 2005 05:12:44 -0000 Received: (qmail 19208 invoked by uid 500); 2 Aug 2005 05:12:37 -0000 Mail-Followup-To: gcc-help@gcc.gnu.org, gcc@gcc.gnu.org, truedfx@gentoo.org To: =?utf-8?b?SGFyYWxkIHZhbiBExLNr?= Cc: gcc-help@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: More fun with aliasing - removing assignments? References: <20050801214735.GA12919@boostbox> From: Ian Lance Taylor Date: Tue, 02 Aug 2005 05:12:00 -0000 In-Reply-To: <20050801214735.GA12919@boostbox> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2005-08/txt/msg00041.txt.bz2 Harald van D=C4=B3k writes: > I finally managed to track down the problem I've been having to this > short code: >=20 > typedef struct { > unsigned car; > unsigned cdr; > } cons; >=20 > void nconc (unsigned x, unsigned y) { > unsigned *ptr =3D &x; > while(!(*ptr & 3)) > ptr =3D &((cons *)(*ptr))->cdr; > *ptr =3D y; > } >=20 > With gcc 4.0-20050728 on i686-pc-linux-gnu, compiling this with -O2 > appears to remove the assignment to *ptr. (I didn't prepare an example > program, but it's verifiable with objdump.) Obviously, this code is > non-portable, but still, I don't see why this can happen. Would anyone > be kind enough to explain this to me? It works as expected with -O2 > -fno-strict-aliasing. Well, I'd say it's a bug. It works in 4.1. The final assignment gets removed by tree-ssa-dce.c because it looks like a useless store. This is because alias analysis thinks it knows what is going on, when it clearly does not. This patch happens to fix it in 4.0. I doubt this is the right approach, though. It's a big hammer, which says that if you set a pointer to the address of something, and you're not sure what that thing is, then you have no idea what the pointer points to. This code is completely different in 4.1. In 4.1 the function find_what_p_points_to is called, and it determines that it has no idea what 'ptr' points to. I think this should probably be fixed for 4.0.2, but I don't know if this is the right patch at all. It should at least be safe. Ian Index: tree-ssa-alias.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/gcc/gcc/gcc/tree-ssa-alias.c,v retrieving revision 2.71.2.2 diff -p -u -r2.71.2.2 tree-ssa-alias.c --- tree-ssa-alias.c 26 Jul 2005 20:54:21 -0000 2.71.2.2 +++ tree-ssa-alias.c 2 Aug 2005 05:07:41 -0000 @@ -1901,6 +1901,8 @@ add_pointed_to_var (struct alias_info *a if (is_global_var (pt_var)) pi->pt_global_mem =3D 1; } + else + set_pt_anything (ptr); } =20 =20