Hi Mikael, dear all,
Mikael Morin wrote:
PPS: The offset handling in gfortran is really complicated. I wonder
whether we have to (or at least should) change it for the new array
descriptor.
I don't know exactly what you mean by "really complicated". There are
not many simple things in gfortran
On 28/06/2012 09:34, Tobias Burnus wrote:
> This patch generates inline code for C_F_POINTER with an array argument.
> One reason is that GCC didn't handle SHAPE= arguments which were
> noncontiguous.
>
> However, the real motivation is the fortran-dev branch with the new
> array-descriptor: C_F_P
*ping*
On 06/28/2012 09:34 AM, Tobias Burnus wrote:
This patch generates inline code for C_F_POINTER with an array
argument. One reason is that GCC didn't handle SHAPE= arguments which
were noncontiguous.
Actually, I just messed up my test case and didn't properly read the
libgfortran/intrin
Hi Tobias,
I am puzzled by the subject: the test gfortran.dg/c_f_pointer_shape_tests_5.f90
does
not need the patch to succeed (at least after 4.5.3, it fails only for 4.4.6).
Note that the similar test in
http://gcc.gnu.org/ml/fortran/2012-04/msg00115.html
fails because c_f_pointer(x, ptr, shap
This patch generates inline code for C_F_POINTER with an array argument.
One reason is that GCC didn't handle SHAPE= arguments which were
noncontiguous.
However, the real motivation is the fortran-dev branch with the new
array-descriptor: C_F_POINTER needs then to set the stride multiplier,
b
