From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10319 invoked by alias); 27 Aug 2006 04:12:23 -0000 Received: (qmail 10284 invoked by alias); 27 Aug 2006 04:12:10 -0000 Date: Sun, 27 Aug 2006 04:12:00 -0000 Message-ID: <20060827041210.10283.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/28778] [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "dberlin at dberlin dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-08/txt/msg02340.txt.bz2 List-Id: ------- Comment #19 from dberlin at gcc dot gnu dot org 2006-08-27 04:12 ------- Subject: Re: [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered rguenth at gcc dot gnu dot org wrote: > ------- Comment #17 from rguenth at gcc dot gnu dot org 2006-08-26 20:42 ------- > So, making pointer arguments effectively using alias-set zero for alias and > call clobbering computation would fix this. > Yes, if you change it so *everything passed to calls* is assumed to be aliasing every variable with it's address taken, you will get the right result in this case. So what do you think will happen when you add one level of indirection to the mess, and TBAA now prunes out *that* alias instead, so you miss it again? (IE break the chain of clobber transitivity one link in the other direcftion). IMHO, i'd rather just see this bug, which has been in our compiler for 3 releases now, fixed properly in the next one, than hacked around. It's relatively easy to fix this testcase in some hacky way, but i'm not sure why we'd want to, when we know it will only fix this testcase, and not the underlying problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778