[Fortran-Dev, committed] Set elem_len and use proper element size for stride handling

[Tobias Burnus]

This patch properly sets the elem_len in gfc_array_init_size; it 
probably could restricted to do so only for BT_CLASS and for 
deferred-length BT_CHARACTER as otherwise the correct elem_len is set.

Additionally, the stride handling now uses elem_len to convert from/to 
the stride multiplier instead of the declared TYPE_UNIT_SIZE. The latter 
doesn't properly work for strings (at least not in all cases) and 
(never) for polymorphic variables.

The code keeps using the declared size for nonstrings/record types. The 
reason is that the declared size is a compile-time constant. Using 
elem_len would otherwise cause problems, e.g., with vectorization as the 
vectorizer cannot see that the memory access is contiguous.

(The other patch removes some code which used to be:  new_ubound = 
old_ubound + (old_lbound-new_lbound); with the change of the array 
descriptor to extents, the code was now effectively "new_extent = 
old_extent", which is pointless.)


This patch brings down the regression-test failures from 15 to 6. Still 
failing are:
gfortran.dg/auto_char_len_3.f90
gfortran.dg/mvbits_7.f90
gfortran.dg/mvbits_8.f90
gfortran.dg/proc_decl_23.f90
gfortran.dg/subref_array_pointer_2.f90
gfortran.dg/transfer_intrinsic_3.f90
gfortran.dg/unlimited_polymorphic_1.f03

Besides solving those regressions, the main task is still outstanding: 
Removal of "offset". Additional tasks are lower_bound == 0 for actuals 
to nonpointer/nonallocatables dummies and the proper handling of 
subpointers (i.e. sm != n*elem_len).


Committed as Rev. 198669 after building and regtesting on 
x86-64-gnu-linux. Additionally, I have updated the branch to the trunk, 
Rev. 198670.

Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: array-elem-len.diff
Type: text/x-patch
Size: 4151 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20130507/c65cabad/attachment.bin>