From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-338517-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 29128 invoked by alias); 26 Nov 2010 14:29:50 -0000
Received: (qmail 29109 invoked by uid 22791); 26 Nov 2010 14:29:49 -0000
X-SWARE-Spam-Status: No, hits=-2.8 required=5.0	tests=ALL_TRUSTED,AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Received: from localhost (HELO gcc.gnu.org) (127.0.0.1)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 26 Nov 2010 14:29:44 +0000
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Keywords: ice-checking, ice-on-valid-code, lto, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.6.0
X-Bugzilla-Changed-Fields:
Message-ID: <bug-45586-4-azNjz8dLAh@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-45586-4@http.gcc.gnu.org/bugzilla/>
References: <bug-45586-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Date: Fri, 26 Nov 2010 14:40:00 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2010-11/txt/msg03250.txt.bz2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586

--- Comment #20 from rguenther at suse dot de <rguenther at suse dot de> 2010-11-26 14:29:41 UTC ---
On Fri, 26 Nov 2010, Joost.VandeVondele at pci dot uzh.ch wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
> 
> --- Comment #19 from Joost VandeVondele <Joost.VandeVondele at pci dot uzh.ch> 2010-11-26 13:39:00 UTC ---
> Tobias, thanks for the clean explanation. I overlooked that the target of a
> pointer has that target attribute (seems logical!).
> 
> Richard, I tried to get to a testcase for which the ME generates wrong code,
> but somehow things are always 'right'. I was expecting this to fail (-O3
> -fno-inline), since the ME should not now that X aliases with V1%D:
> 
> MODULE M1
>  IMPLICIT NONE
>  TYPE T1
>    REAL, DIMENSION(:), ALLOCATABLE :: D
>  END TYPE T1
> CONTAINS
>  SUBROUTINE S1(V1)
>    TYPE(T1), POINTER :: V1

We can't exploit restrict information for pointers, it would need to
be a var of type t1 with target attribute - but even then the double
indirection (v1 passed by reference, embedded array desc points to
data) prevents us from exploiting restrict info.

So we might be safe for now (apart from the related ICE seen with lto).

>    REAL, DIMENSION(:), POINTER :: X
>    INTEGER :: I
>    CALL PA(V1,X)
>    DO i=1,4
>       V1%D(i)=1
>       X(i)=2
>       V1%D(i)=2*V1%D(i)
>    ENDDO
>  END SUBROUTINE S1
>  SUBROUTINE PA(V1,X)
>    TYPE(T1), POINTER :: V1
>    REAL, DIMENSION(:), POINTER :: X
>    X=>V1%D
>  END SUBROUTINE
> END MODULE M1
> 
> USE M1
> IMPLICIT NONE
> TYPE(T1), POINTER :: V1
> INTEGER :: i
> ALLOCATE(V1)
> ALLOCATE(V1%D(4))
> V1%D=(/(i,i=1,4)/)
> CALL S1(V1)
> IF (ANY(V1%D.NE.4)) STOP "BUG"
> write(6,*) "ALL IS FINE"
> END
> 
>