[Bug fortran/55633] New: [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test

[Bug fortran/55633] New: [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test

[danglin at gcc dot gnu.org]

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

             Bug #: 55633
           Summary: [4.8 Regression] FAIL:
                    gfortran.dg/g77/f90-intrinsic-bit.f  -Os  execution
                    test
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: danglin@gcc.gnu.org
              Host: hppa*-*-* (32-bit)
            Target: hppa*-*-* (32-bit)
             Build: hppa*-*-* (32-bit)


Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/g77/f90-intrinsic-bit.f 
-fno-diagnostics-show-caret   -Os   -pedantic-errors 
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdi
r/hppa2.0w-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-h
pux11.11/./libgfortran/.libs
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libq
uadmath/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs
-
L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs  -lm   -o
./f90-
intrinsic-bit.exe    (timeout = 300)
spawn /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B/test/gnu/gcc
/objdir/gcc/testsuite/gfortran/../../
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.
11/./libgfortran/
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/g77/f90-intrinsic-bit.f
-fno-diagnostics-show-caret -Os -pedantic-errors
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs -lm -o
./f90-intrinsic-bit.exePASS: gfortran.dg/g77/f90-intrinsic-bit.f  -Os  (test
for excess errors)
Setting LD_LIBRARY_PATH to
.:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs:/test
/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/gcc:.:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/gcc
spawn [open ...]
Test BIT_SIZE(integer(8)) FAILED
 Got                    64  expected                     0

Backtrace for this error:
#0  0xC1C39DDB
FAIL: gfortran.dg/g77/f90-intrinsic-bit.f  -Os  execution test

Expected value seems wrong...

[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test

[burnus at gcc dot gnu.org]

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

[rguenth at gcc dot gnu.org]

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

[dave.anglin at bell dot net]

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 =                    0                0 ma= 0            0
m =                   -1 FFFFFFFFFFFFFFFF ma= 0            0
m =  9223372036854775807 7FFFFFFFFFFFFFFF, ma= 1            1
m =  4611686018427387903 3FFFFFFFFFFFFFFF, ma= 2            2
m =  2305843009213693951 1FFFFFFFFFFFFFFF, ma= 3            3
m =  1152921504606846975  FFFFFFFFFFFFFFF, ma= 4            4
m =   576460752303423487  7FFFFFFFFFFFFFF, ma= 5            5
m =   288230376151711743  3FFFFFFFFFFFFFF, ma= 6            6
m =   144115188075855871  1FFFFFFFFFFFFFF, ma= 7            7
m =    72057594037927935   FFFFFFFFFFFFFF, ma= 8            8
m =    36028797018963967   7FFFFFFFFFFFFF, ma= 9            9
m =    18014398509481983   3FFFFFFFFFFFFF, ma=10            A
m =     9007199254740991   1FFFFFFFFFFFFF, ma=11            B
m =     4503599627370495    FFFFFFFFFFFFF, ma=12            C
m =     2251799813685247    7FFFFFFFFFFFF, ma=13            D
m =     1125899906842623    3FFFFFFFFFFFF, ma=14            E
m =      562949953421311    1FFFFFFFFFFFF, ma=15            F
m =      281474976710655     FFFFFFFFFFFF, ma=16           10
m =      140737488355327     7FFFFFFFFFFF, ma=17           11
m =       70368744177663     3FFFFFFFFFFF, ma=18           12
m =       35184372088831     1FFFFFFFFFFF, ma=19           13
m =       17592186044415      FFFFFFFFFFF, ma=20           14
m =        8796093022207      7FFFFFFFFFF, ma=21           15
m =        4398046511103      3FFFFFFFFFF, ma=22           16
m =        2199023255551      1FFFFFFFFFF, ma=23           17
m =        1099511627775       FFFFFFFFFF, ma=24           18
m =         549755813887       7FFFFFFFFF, ma=25           19
m =         274877906943       3FFFFFFFFF, ma=26           1A
m =         137438953471       1FFFFFFFFF, ma=27           1B
m =          68719476735        FFFFFFFFF, ma=28           1C
m =          34359738367        7FFFFFFFF, ma=29           1D
m =          17179869183        3FFFFFFFF, ma=30           1E
m =           8589934591        1FFFFFFFF, ma=31           1F
m =           4294967295         FFFFFFFF, ma=32           20
m =           2147483647         7FFFFFFF, ma=33           21
m =           1073741823         3FFFFFFF, ma=34           22
m =            536870911         1FFFFFFF, ma=35           23
m =            268435455          FFFFFFF, ma=36           24
m =            134217727          7FFFFFF, ma=37           25
m =             67108863          3FFFFFF, ma=38           26
m =             33554431          1FFFFFF, ma=39           27
m =             16777215           FFFFFF, ma=40           28
m =              8388607           7FFFFF, ma=41           29
m =              4194303           3FFFFF, ma=42           2A
m =              2097151           1FFFFF, ma=43           2B
m =              1048575            FFFFF, ma=44           2C
m =               524287            7FFFF, ma=45           2D
m =               262143            3FFFF, ma=46           2E
m =               131071            1FFFF, ma=47           2F
m =                65535             FFFF, 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 =                   15                F, ma=60           3C
m =                    7                7, ma=61           3D
m =                    3                3, ma=62           3E
m =                    1                1, ma=63           3F
m =                    0                0, ma=64           40
                    64                   64

kind=4:
m =                    0                0 ma= 0            0
m =                   -1         FFFFFFFF ma= 0            0
m =           2147483647         7FFFFFFF, ma= 1            1
m =           1073741823         3FFFFFFF, ma= 2            2
m =            536870911         1FFFFFFF, ma= 3            3
m =            268435455          FFFFFFF, ma= 4            4
m =            134217727          7FFFFFF, ma= 5            5
m =             67108863          3FFFFFF, ma= 6            6
m =             33554431          1FFFFFF, ma= 7            7
m =             16777215           FFFFFF, ma= 8            8
m =              8388607           7FFFFF, ma= 9            9
m =              4194303           3FFFFF, ma=10            A
m =              2097151           1FFFFF, ma=11            B
m =              1048575            FFFFF, ma=12            C
m =               524287            7FFFF, ma=13            D
m =               262143            3FFFF, ma=14            E
m =               131071            1FFFF, ma=15            F
m =                65535             FFFF, ma=16           10
m =                32767             7FFF, ma=17           11
m =                16383             3FFF, ma=18           12
m =                 8191             1FFF, ma=19           13
m =                 4095              FFF, ma=20           14
m =                 2047              7FF, ma=21           15
m =                 1023              3FF, ma=22           16
m =                  511              1FF, ma=23           17
m =                  255               FF, ma=24           18
m =                  127               7F, ma=25           19
m =                   63               3F, ma=26           1A
m =                   31               1F, ma=27           1B
m =                   15                F, ma=28           1C
m =                    7                7, ma=29           1D
m =                    3                3, ma=30           1E
m =                    1                1, ma=31           1F
m =                    0                0, ma=32           20
           32          32

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

[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test

[jakub at gcc dot gnu.org]

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

[dave.anglin at bell dot net]

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

[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test

[danglin at gcc dot gnu.org]

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

[danglin at gcc dot gnu.org]

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.

[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test

[jakub at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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=gcc&view=rev&rev=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

[jakub at gcc dot gnu.org]

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.