[Bug fortran/103023] ICE (Segmentation fault) with !$OMP DECLARE SIMD(func) linear(ref(u))

[bartoldeman at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #2 from bartoldeman at users dot sourceforge.net ---
Yes this is about the ICE mainly.

It was stripped down from this, which HAS uniform.

subroutine func(u,f,ndim)
  !$OMP DECLARE SIMD(func) uniform(ndim) linear(ref(f,u):1)
  integer, intent(in) :: ndim
  double precision, intent(in) :: u(ndim)
  double precision, intent(out) :: f(ndim)
  f(1) = u(1) + u(2)
  f(2) = u(1) - u(2)
end subroutine func

subroutine main(u,f)
  double precision, intent(in) :: u(8)
  double precision, intent(out) :: f(8)
!$OMP SIMD
  do i=1,8,2
 call func(u(i),f(i),2)
  enddo
end subroutine main

If I leave out ndim and hardcode "2" in func (:: u(2) and :: f(2)), or let the
auto-vectorizer and inliner do its work this produces good code (though it
would be better with u and f transposed, as basically the code transposes it to
two ymm registers in the asm output.

With general "ndim" that could still work, e.g. with ndim=3 and 3 equations for
u(1:3) -> f(1:3), you'd work with 3 vector registers.

Now you may wonder why "ndim" here, since we know it's "2": this comes from
feeding a user-defined function into a larger program (that processes e.g.
maps) where that same user needs to specify ndim as a parameter.

Intel (ifort) doesn't like this at all from what I can see:

openfun.f90(1): error #6080: Only scalar variables may be referenced in a
LINEAR or MONOTONIC clause.   [U]
subroutine func(u,f)
^
openfun.f90(1): error #6080: Only scalar variables may be referenced in a
LINEAR or MONOTONIC clause.   [F]
subroutine func(u,f)
--^
compilation aborted for openfun.f90 (code 1)

[Bug fortran/103023] ICE (Segmentation fault) with !$OMP DECLARE SIMD(func) linear(ref(u))

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I think we should warn and ignore the declare simd in this case, this can't be
expressed in the Intel Vector Function ABI mangling we are using, where for
linear the options are:
::
/* empty */ // linear_step is equal to 1
's' non-negative-decimal-number // linear_step is passed in another argument,
// decimal number is the position # of
// linear_step argument, which starts from 0
| number // linear_step is literally constant stride
While at the source level the linear-step is 1 which is constant, it actually
is
1 * type size of u, and that isn't constant.  And the s number isn't an option
in this case either, because it needs to refer to an uniform argument and needs
to be specified as the linear-step.  So e.g. uniform(ndim) linear(ref(u):ndim)
would work, but would do something different.
ifort rejects this with a weird message.

Anyway, besides not ICEing on this, I don't understand what you expect from
this, you'll never get optimized code if each SIMD lane needs to work with its
own arrays, whether fixed or variable sized.