[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-12 09:33:00 UTC --- Author: jakub Date: Wed Dec 12 09:32:52 2012 New Revision: 194438 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194438 Log: PR fortran/55633 * tree-ssa-loop-niter.c (discover_iteration_bound_by_body_walk): Ignore bounds on which bound += double_int_one overflowed. * gcc.dg/torture/pr55633.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr55633.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-niter.c
[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-12 09:46:10 UTC --- Fixed.
[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-11 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 08:59:53 UTC --- Indeed, looks like HWI issue, as I can reproduce it with i686-linux - hppa cross, but not x86_64-linux - hppa. The first difference starts during ivcanon, looking into it.
[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-11 10:22:49 UTC --- Created attachment 28923 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28923 gcc48-pr55633.patch Untested fix.
[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-10 08:57:04 UTC --- Can you pin-point which version causes the regression? BIT_SIZE(m) is (correctly) 64 while ma is (wrongly) 0. And NOT returns the bitwise Boolean inverse of I. Can you run the following code? It matches the failing code but contains some debugging printout. Can you also try kind=4? That seems to work while kind=8 seems to fail. integer(kind=8) m, ma ma = 0 m = 0 print '(m =,i21,z17, ma=,i2,z13)', m, m, ma, ma m = not(m) print '(m =,i21,z17, ma=,i2,z13)', m, m, ma, ma do while ( (m.ne.0) .and. (ma.lt.127) ) ma = ma + 1 m = ishft(m,-1) print '(m =,i21,z17,, ma=,i2,z13)', m, m, ma, ma end do print *, BIT_SIZE(m), ma if (BIT_SIZE(m) /= ma) error stop end
[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |4.8.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2012-12-10 09:42:58 UTC --- If only -Os fails then it's (liekly) not a frontend issue. Leaving P3 for the moment.
[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633 --- Comment #3 from dave.anglin at bell dot net 2012-12-10 13:31:31 UTC --- On 10-Dec-12, at 3:57 AM, burnus at gcc dot gnu.org wrote: Can you pin-point which version causes the regression? At this point, I onnly know the test didn't fail in early September. BIT_SIZE(m) is (correctly) 64 while ma is (wrongly) 0. And NOT returns the bitwise Boolean inverse of I. Can you run the following code? It matches the failing code but contains some debugging printout. Can you also try kind=4? That seems to work while kind=8 seems to fail. integer(kind=8) m, ma ma = 0 m = 0 print '(m =,i21,z17, ma=,i2,z13)', m, m, ma, ma m = not(m) print '(m =,i21,z17, ma=,i2,z13)', m, m, ma, ma do while ( (m.ne.0) .and. (ma.lt.127) ) ma = ma + 1 m = ishft(m,-1) print '(m =,i21,z17,, ma=,i2,z13)', m, m, ma, ma end do print *, BIT_SIZE(m), ma if (BIT_SIZE(m) /= ma) error stop end Here are the results from hppa-unknown-linux-gnu which also fails. kind=8: m =00 ma= 00 m = -1 ma= 00 m = 9223372036854775807 7FFF, ma= 11 m = 4611686018427387903 3FFF, ma= 22 m = 2305843009213693951 1FFF, ma= 33 m = 1152921504606846975 FFF, ma= 44 m = 576460752303423487 7FF, ma= 55 m = 288230376151711743 3FF, ma= 66 m = 144115188075855871 1FF, ma= 77 m =72057594037927935 FF, ma= 88 m =36028797018963967 7F, ma= 99 m =18014398509481983 3F, ma=10A m = 9007199254740991 1F, ma=11B m = 4503599627370495F, ma=12C m = 22517998136852477, ma=13D m = 11258999068426233, ma=14E m = 5629499534213111, ma=15F m = 281474976710655 , ma=16 10 m = 140737488355327 7FFF, ma=17 11 m = 70368744177663 3FFF, ma=18 12 m = 35184372088831 1FFF, ma=19 13 m = 17592186044415 FFF, ma=20 14 m =8796093022207 7FF, ma=21 15 m =4398046511103 3FF, ma=22 16 m =219902321 1FF, ma=23 17 m =1099511627775 FF, ma=24 18 m = 549755813887 7F, ma=25 19 m = 274877906943 3F, ma=26 1A m = 137438953471 1F, ma=27 1B m = 68719476735F, ma=28 1C m = 343597383677, ma=29 1D m = 171798691833, ma=30 1E m = 85899345911, ma=31 1F m = 4294967295 , ma=32 20 m = 2147483647 7FFF, ma=33 21 m = 1073741823 3FFF, ma=34 22 m =536870911 1FFF, ma=35 23 m =268435455 FFF, ma=36 24 m =134217727 7FF, ma=37 25 m = 67108863 3FF, ma=38 26 m = 33554431 1FF, ma=39 27 m = 16777215 FF, ma=40 28 m = 8388607 7F, ma=41 29 m = 4194303 3F, ma=42 2A m = 2097151 1F, ma=43 2B m = 1048575F, ma=44 2C m = 5242877, ma=45 2D m = 2621433, ma=46 2E m = 1310711, ma=47 2F m =65535 , ma=48 30 m =32767 7FFF, ma=49 31 m =16383 3FFF, ma=50 32 m = 8191 1FFF, ma=51 33 m = 4095 FFF, ma=52 34 m = 2047 7FF, ma=53 35 m = 1023 3FF, ma=54 36 m = 511 1FF, ma=55 37 m = 255 FF, ma=56 38 m = 127 7F, ma=57 39 m = 63 3F, ma=58 3A m = 31 1F, ma=59 3B m =
[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
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. ldi 0,%r19 ldi 0,%r20 ldi 126,%r31 ldi -1,%r28 ldi -1,%r29 L$0032: copy %r19,%r21 copy %r20,%r22 addi 1,%r20,%r20 addc %r19,%r0,%r19 comiclr,= 0,%r21,%r0 b,n L$0029 comib, 0,%r21,L$0050 or %r28,%r29,%r23 comclr,= %r31,%r22,%r0 b,n L$0029 L$0050: comib,=,n 0,%r23,L$0029 shd %r28,%r29,1,%r21 extru %r28,30,31,%r22 copy %r21,%r29 b L$0032 copy %r22,%r28 L$0029: stw %r21,-240(%r30) ldo -240(%r30),%r25 ldi 20,%r23 stw %r22,-236(%r30) is the assembly I get for the interesting part. So, if you have the same, can you step through this and see why you get 0 in %r21/%r22?
[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
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 Anglindave.ang...@bell.net
[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633 --- Comment #6 from John David Anglin danglin at gcc dot gnu.org 2012-12-11 01:29:00 UTC --- Created attachment 28920 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28920 Reduced testcase
[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633 --- Comment #7 from John David Anglin danglin at gcc dot gnu.org 2012-12-11 02:00:11 UTC --- Created attachment 28921 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28921 Tree dump Looks to me like things go bad in lim1.
