[Bug middle-end/111427] [14 regression] gfortran.dg/vect/pr60510.f fails after r14-3999-g3c834d85f2ec42

["linkw at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111427

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-09-26
           Keywords|ra, wrong-code              |testsuite-fail
           Assignee|unassigned at gcc dot gnu.org      |linkw at gcc dot gnu.org
                 CC|                            |linkw at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED

--- Comment #2 from Kewen Lin <linkw at gcc dot gnu.org> ---
I found it can be reproduced on Power8 but not on Power9 (BE since only BE
supports -m32).

The option can be reduced to:

opts="-m32 -funroll-loops -O2 -mcpu=power8"

Looking into the affected test case, IMHO this is a test issue:

      subroutine foo(a,x,y,n)
      implicit none
      integer n,i

      real*8 y(n),x(n),a

      do i=1,n
         a=a+x(i)*y(i)+x(i)
      enddo

      return
      end

      program test
      real*8 x(1024),y(1024),a    ===> line A
      do i=1,1024
        x(i) = i
        y(i) = i+1
      enddo
      call foo(a,x,y,1024)
      if (a.ne.359488000.0) STOP 1
      end

The variable a in line A is an uninitialized variable.

Without the culprit commit, the address of the passed a is 0xfffeec30:

Dump of assembler code for function MAIN__:
   0x100008b0 <+0>:     stwu    r1,-16416(r1)
   ...
   0x100009f4 <+324>:   lis     r12,4096
   0x100009f8 <+328>:   addi    r5,r1,16
   0x100009fc <+332>:   addi    r4,r1,8208
   0x10000a00 <+336>:   addi    r3,r1,16400
   0x10000a04 <+340>:   addi    r6,r12,3160
=> 0x10000a08 <+344>:   bl      0x10000620 <foo_>

(gdb) i r r3
r3             0xfffeec30          4294896688
(gdb) x /2x 0xfffeec30
0xfffeec30:     0x10000524      0x00000000

the random value of "a" is 0x1000052400000000, a tiny float value
(1.289846527864432e-231) and doesn't cause the comparison to fail.

With the culprit commit, the address of the passed a is 0xfffeec20:

100008b0 <MAIN__>:
100008b0:       94 21 bf d0     stwu    r1,-16432(r1)
100008b4:       3d 20 10 00     lis     r9,4096
...

(gdb) x /2x 0xfffeec20
0xfffeec20:     0xfffeec40      0x0fddd03c
(gdb) i r r3
r3             0xfffeec20          4294896672

the random value of "a" is 0xfffeec400fddd03c, which is NAN, so it causes the
comparison to fail.

I'm not sure why this doesn't get exposed before (so lucky), but an explicit
initialization for a should fix this.