This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
- From: "dave.anglin at bell dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 11 Dec 2012 01:16:16 +0000
- Subject: [Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
- Auto-submitted: auto-generated
- References: <bug-55633-4@http.gcc.gnu.org/bugzilla/>
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