From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-156061-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 5482 invoked by alias); 20 Aug 2009 08:45:23 -0000
Received: (qmail 5472 invoked by uid 22791); 20 Aug 2009 08:45:22 -0000
X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 	tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS
X-Spam-Check-By: sourceware.org
Received: from mail-vw0-f178.google.com (HELO mail-vw0-f178.google.com) (209.85.212.178)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 20 Aug 2009 08:45:12 +0000
Received: by vws8 with SMTP id 8so4280397vws.14         for <gcc@gcc.gnu.org>; Thu, 20 Aug 2009 01:45:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.12.130 with SMTP id x2mr10515747vcx.75.1250757909661; Thu,  	20 Aug 2009 01:45:09 -0700 (PDT)
In-Reply-To: <4A8C99DF.10608@redhat.com>
References: <4A8C8A42.3020008@redhat.com> <m3k50z8iz2.fsf@google.com> 	 <4A8C99DF.10608@redhat.com>
Date: Thu, 20 Aug 2009 09:48:00 -0000
Message-ID: <84fc9c000908200145l53d0e86dt47ddf3ecb8f02ee3@mail.gmail.com>
Subject: Re: Latent bug in update_equiv_regs?
From: Richard Guenther <richard.guenther@gmail.com>
To: Jeff Law <law@redhat.com>
Cc: Ian Lance Taylor <iant@google.com>, GCC <gcc@gcc.gnu.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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/msg00359.txt.bz2

On Thu, Aug 20, 2009 at 2:33 AM, Jeff Law<law@redhat.com> wrote:
> 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. =A0It's not no_equiv th=
at
>> 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. =A0This 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 -fope=
nmp
>
> In the .expand dump we have:
>
> (insn 242 241 243 47 j.f90:138 (set (reg:SF 74 [ D.3137 ])
> =A0 =A0 =A0 =A0(mem/s:SF (plus:SI (reg/f:SI 247 [ .omp_data_i ])
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(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 ])
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(const_int 32 [0x20])) [13 S4 A64])
> =A0 =A0 =A0 =A0(reg:SF 351)) -1 (nil))
>
> As you can see we've got different alias sets on the two MEMs. =A0 This c=
ould
> be an expansion bug, f95 bug, or a bug in one of the SSA optimizers. =A0 =
Ugh.

It looks indeed bogus.  Do you have a testcase at hand?

Richard.

> Thanks,
> jeff
>
>
>
>