From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-156055-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 23499 invoked by alias); 20 Aug 2009 00:33:12 -0000
Received: (qmail 23491 invoked by uid 22791); 20 Aug 2009 00:33:11 -0000
X-SWARE-Spam-Status: No, hits=-0.0 required=5.0 	tests=AWL,BAYES_00,BOTNET,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: sourceware.org
Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 20 Aug 2009 00:33:01 +0000
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) 	by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n7K0WwXC024340; 	Wed, 19 Aug 2009 20:32:59 -0400
Received: from omfg.slc.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) 	by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n7K0WvDe016316; 	Wed, 19 Aug 2009 20:32:58 -0400
Message-ID: <4A8C99DF.10608@redhat.com>
Date: Thu, 20 Aug 2009 01:20:00 -0000
From: Jeff Law <law@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3
MIME-Version: 1.0
To: Ian Lance Taylor <iant@google.com>
CC: GCC <gcc@gcc.gnu.org>
Subject: Re: Latent bug in update_equiv_regs?
References: <4A8C8A42.3020008@redhat.com> <m3k50z8iz2.fsf@google.com>
In-Reply-To: <m3k50z8iz2.fsf@google.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
X-SW-Source: 2009-08/txt/msg00353.txt.bz2

On 08/19/09 17:46, Ian Lance Taylor wrote:
>
> My understanding is that that scenario is supposed to not happen because
> update_equiv_regs is only supposed to equate a register and a memory
> location in the specific cases where that is OK.  It's not no_equiv that
> is supposed to fix this, the equivalence should only be created when it
> will always be OK.
>
> So I think you need to explain more about why the equivalence was
> created.
>
> Ian
>    
You're right.  This should have been rejected by validate_equiv_mem, but 
isn't because the two memory references are in different alias sets.

You can see this in the mainline sources configured for 
i686-pc-linux-gnu by compiling 
libgomp/testsuite/libgomp.fortran/reduction1.f90 with -O3 -fopenmp

In the .expand dump we have:

(insn 242 241 243 47 j.f90:138 (set (reg:SF 74 [ D.3137 ])
         (mem/s:SF (plus:SI (reg/f:SI 247 [ .omp_data_i ])
                 (const_int 32 [0x20])) [2 .omp_data_i_55(D)->c+0 S4 
A64])) -1 (nil))
[ ... ]

(insn 247 246 248 47 j.f90:138 (set (mem/s:SF (plus:SI (reg/f:SI 247 [ 
.omp_data_i ])
                 (const_int 32 [0x20])) [13 S4 A64])
         (reg:SF 351)) -1 (nil))

As you can see we've got different alias sets on the two MEMs.   This 
could be an expansion bug, f95 bug, or a bug in one of the SSA 
optimizers.   Ugh.

Thanks,
jeff