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

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

[bartoldeman at users dot sourceforge.net]

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

            Bug ID: 103023
           Summary: ICE (Segmentation fault) with !$OMP DECLARE SIMD(func)
                    linear(ref(u))
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bartoldeman at users dot sourceforge.net
  Target Milestone: ---

Created attachment 51717
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51717&action=edit
Test case for crash

For the following Fortran code gfortran gives a SIGSEGV (tested GCC 9.3,10.3
locally, 11.2 and trunk on Godbolt)

subroutine func(u,ndim)
  !$OMP DECLARE SIMD(func) linear(ref(u))
  integer, intent(in) :: ndim
  double precision, intent(in) :: u(ndim)
end subroutine func

Here's the output for 10.3:

$ gfortran -c -fopenmp-simd openfun2.f90
openfun2.f90:1:15:

    1 | subroutine func(u,ndim)
      |               1
internal compiler error: Segmentation fault

0xc147cf crash_signal
        ../../gcc/toplev.c:328
0x948ae6 size_binop_loc(unsigned int, tree_code, tree_node*, tree_node*)
        ../../gcc/fold-const.c:1906
0x7b8258 gfc_trans_omp_clauses
        ../../gcc/fortran/trans-openmp.c:2324
0x7bb168 gfc_trans_omp_declare_simd(gfc_namespace*)
        ../../gcc/fortran/trans-openmp.c:5838
0x77b767 gfc_create_function_decl(gfc_namespace*, bool)
        ../../gcc/fortran/trans-decl.c:3069
0x77b767 gfc_generate_function_code(gfc_namespace*)
        ../../gcc/fortran/trans-decl.c:6744
0x6f679e translate_all_program_units
        ../../gcc/fortran/parse.c:6306
0x6f679e gfc_parse_file()
        ../../gcc/fortran/parse.c:6567
0x74dfbf gfc_be_parse_file
        ../../gcc/fortran/f95-lang.c:210
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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:
<stride>::
/* 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.

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

[bartoldeman at users dot sourceforge.net]

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)