[Bug fortran/29400] New: ANY and COUNT used on parameter arrays

[Bug fortran/29400] New: ANY and COUNT used on parameter arrays

[fxcoudert at gcc dot gnu dot org]

I found that bug while reducing PR29391, so it might be related (but I doubt
it).

$ cat a6.f90 
  integer,parameter :: i(1,1) = 0

  write(*,*) lbound(any(i==1,2)), ubound(any(i==1,2))
  write(*,*) lbound(count(i==1,2)), ubound(count(i==1,2))
  write(*,*) lbound(matmul(i,i))
end
$ gfortran a6.f90 && ./a.out
Operating system error: Cannot allocate memory
Memory allocation failed

If I remove the line with matmul, I get another error:

$ gfortran a6.f90 && ./a.out
           0           1
           0           1
zsh: segmentation fault  ./a.out


-- 
           Summary: ANY and COUNT used on parameter arrays
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: fxcoudert at gcc dot gnu dot org


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

[Bug fortran/29400] ANY and COUNT used on parameter arrays

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-10-09 11:53:37
               date|                            |


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

[Bug fortran/29400] ANY and COUNT used on parameter arrays

[fxcoudert at gcc dot gnu dot org]

------- Comment #1 from fxcoudert at gcc dot gnu dot org  2006-10-09 12:36 -------
The generated code for:
  integer,parameter :: i(1,1) = 0
  integer :: j(1)
  j = lbound(any(i==1,2))
  end
is weird:

MAIN__ ()
{
  int4 j[1];

  _gfortran_set_std (70, 127, 0);
  {
    int8 S.0;

    S.0 = 1;
    while (1)
      {
        if (S.0 > 1) goto L.1; else (void) 0;
        {
          struct array1_logical4 atmp.1;
          int8 C.1248 = 2;
          logical4 C.1247 = 0;

          atmp.1.dtype = 273;
          atmp.1.data = 0B;
          atmp.1.offset = 0;
          _gfortran_any_l4 (&atmp.1, &C.1247, &C.1248);
          j[NON_LVALUE_EXPR <S.0> + -1] = (int4) atmp.1.dim[S.0 - 1].lbound;
          _gfortran_internal_free (atmp.1.data);
        }
        S.0 = S.0 + 1;
      }
    L.1:;
  }
}

Why are we passing a pointer to a logical4 as a second argument to
_gfortran_any_l4, and not an array descriptor.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2006-10-09 11:53:37         |2006-10-09 12:36:31
               date|                            |


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

[Bug fortran/29400] ANY and COUNT used on parameter arrays

[fxcoudert at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]



------- Comment #2 from fxcoudert at gcc dot gnu dot org  2006-10-09 12:44 -------
And while I'm there, a few possibly related bugs:

$ cat pr29400-2.f90 
  integer,parameter :: i(1,1) = 0
  logical :: l(2)
  l = any(i==1,2)
  end
$ gfortran pr29400-2.f90 && ./a.out
Fortran runtime error: rank of return array incorrect
$ cat pr29400-3.f90 
  integer,parameter :: i(1,1) = 0
  logical :: l
  l = any(i==1)
  end
$ gfortran pr29400-3.f90 && ./a.out
pr29400-3.f90: In function ‘MAIN__’:
pr29400-3.f90:1: internal compiler error: in gfc_conv_intrinsic_anyall, at
fortran/trans-intrinsic.c:1339


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.1.2 4.2.0
   Last reconfirmed|2006-10-09 12:36:31         |2006-10-09 12:44:16
               date|                            |


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

[Bug fortran/29400] ANY and COUNT used on parameter arrays

[fxcoudert at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]



------- Comment #3 from fxcoudert at gcc dot gnu dot org  2007-02-06 12:25 -------
> $ cat pr29400-3.f90 
>   integer,parameter :: i(1,1) = 0
>   logical :: l
>   l = any(i==1)
>   end
> $ gfortran pr29400-3.f90 && ./a.out
> pr29400-3.f90: In function ‘MAIN__’:
> pr29400-3.f90:1: internal compiler error: in gfc_conv_intrinsic_anyall, at
> fortran/trans-intrinsic.c:1339

Same thing happens for count. We try to walk the constant, and it doesn't work
(we fail on the next assert). dot_product works, while seemingly doing the same
thing, maybe we can borrow from it...


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2006-10-09 12:44:16         |2007-02-06 12:25:46
               date|                            |


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

[Bug fortran/29400] ANY and COUNT used on parameter arrays

[fxcoudert at gcc dot gnu dot org]

------- Comment #4 from fxcoudert at gcc dot gnu dot org  2007-02-06 13:41 -------
I was wrong: the bug basically happens for all intrinsics which gfc_walk_expr
one of their arguments and then simply assert that the ss != gfc_ss_terminator.
This is a wrong thing to do for constant arguments. I audited all the
intrinsics to find out which I could lead to an ICE, and here's the complete
list:

  integer,parameter :: i(1,1) = 0, j(2) = 42
  logical :: l

!  print *, maxloc(j+j,mask=(j==2))

  print *, size(j+j)
  print *, minval(j+j)
  print *, minval(j,mask=(j==2))
  print *, maxval(j+j)
  print *, maxval(j,mask=(j==2))
  print *, sum(j,mask=j==2)
  print *, sum(j+j)
  print *, product(j+j)
  print *, ubound(j+j)
  print *, lbound(j+j)
  print *, dot_product(j+j,j)
  print *, dot_product(j,j+j)
  print *, count(i==1)
  print *, any(i==1)
  print *, all(i==1)

  end

I couldn't make maxloc/minloc ICE, although I'm pretty sure there should be a
way to get it.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


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

[Bug fortran/29400] constant arrays as intrinsic arguments lead to ICE

[pault at gcc dot gnu dot org]

------- Comment #5 from pault at gcc dot gnu dot org  2007-05-07 08:59 -------
(In reply to comment #4)

FX,

  integer,parameter :: i(1,1) = reshape ((/0/),(/1,1/))
!  integer,parameter :: i(1,1) = 1
  integer :: j(1)
  j = lbound(any(i==1,2))
  print *, j
  end

works correctly, so it is the initializer that is wrong.  In fact, this is one
and the same as PR29397.  My fix for that did not mend this PR until I added
the shape expressions.  Then, even your great long test in comment#4 works
correctly.

I'll do a regtest and submit later today.

Cheers

Paul


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2007-02-06 13:44:49         |2007-05-07 08:59:00
               date|                            |


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