From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-409447-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 6627 invoked by alias); 11 Dec 2012 01:16:35 -0000
Received: (qmail 6564 invoked by uid 55); 11 Dec 2012 01:16:18 -0000
From: "dave.anglin at bell dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f  -Os  execution test
Date: Tue, 11 Dec 2012 01:16:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dave.anglin at bell dot net
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.0
X-Bugzilla-Changed-Fields:
Message-ID: <bug-55633-4-IKryczBbzK@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-55633-4@http.gcc.gnu.org/bugzilla/>
References: <bug-55633-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
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: 2012-12/txt/msg01055.txt.bz2


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

--- Comment #5 from dave.anglin at bell dot net 2012-12-11 01:16:16 UTC ---
On 10-Dec-12, at 11:29 AM, jakub at gcc dot gnu.org wrote:

>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633
>
> --- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org>  
> 2012-12-10 16:29:10 UTC ---
> The test is really large, I guess it would be useful if you could  
> try to reduce
> the testcase as long as it still fails that BIT_SIZE(integer(8)) test.
>
> Or can you step through the interesting part of the testcase and see  
> where
> things go wrong?  I've eyeballed the *.final assembly of the ma  
> computation and
> it looks ok to me.


I'm seeing different code:

         ; /home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/g77/f90- 
intrinsic-bit.f:48
         .loc 1 48 0
         ldi 0,%r28
         ldi 0,%r29
.LBB19:
         ; /home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/g77/f90- 
intrinsic-bit.f:55
         .loc 1 55 0
         ldo -240(%r30),%r25
.LBE19:
         ; /home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/g77/f90- 
intrinsic-bit.f:48
         .loc 1 48 0
         stw %r28,-240(%r30)
         stw %r29,-236(%r30)
.LBB20:
         ; /home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/g77/f90- 
intrinsic-bit.f:55
         .loc 1 55 0
         ldi 20,%r23
         ldil LR'.LC12,%r26
         ldil LR'.LC13,%r24
         ldo RR'.LC12(%r26),%r26
         ldo RR'.LC13(%r24),%r24
         bl c_i8_,%r2
         ldil LR'.LC15,%r3

The second argument of the call is passed in r25 (pointer to ma).  As  
can be seen,
ma is 0.

In .expand, we have:

   ma = 0;
   c_i8 (&C.920, &ma, &"BIT_SIZE(integer(8))"[1]{lb: 1 sz: 1}, 20);

So, I guess this is likely a tree optimization bug.

--
John David Anglin    dave.anglin@bell.net