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.
