[Patch, fortran] PR31217 - ICE using FORALL on character substrings

["Paul Richard Thomas" <paul dot richard dot thomas at gmail dot com>]

:ADDPATCH fortran:

This turned out to be a double whammy - not only did FORALL suffer
this problem but ordinary assignment did as well (PR33811).

The PR exposed two bugs - one in dependency.c, where substrings were
not being correctly analysed:

For the original PR testcase, forall(i=1:1) a(i:i) = a(i:i) detected a
dependency where there is none and forall(i=1:1) b(2:4)(i:i) =
b(1:3)(i:i) failed to detect the dependency.

Once this was fixed, both FORALL and ordinary assignments ICED because
gfc_typenode_for_spec was used to get the tree type.  This comes back
with an incomplete char[1:] for variable substrings.  This was cured
in both cases by calling gfc_get_character_type_len with the string
length and the default kind.

The testcase contains the two originals and various others that were broken.

Regtested on Cygwin_NT/amd64 (I'll do the checks tonight on
x86_ia64/FC5) - OK for trunk?

Paul

2007-07-18  Paul Thomas <pault@gcc.gnu.org>

	PR fortran/31217
	PR fortran/33811
	* trans-array.c (gfc_conv_loop_setup): Send a complete type to
	gfc_trans_create_temp_array if the temporary is character.
	* trans-stmt.c (gfc_trans_assign_need_temp): Do likewise for
	allocate_temp_for_forall_nest.
	* dependency.c (gfc_check_dependency): Use gfc_dep_resolver for
	all references, not just REF_ARRAY.
	(gfc_dep_resolver): Correct the logic for substrings so that
	overlapping arrays are handled correctly.

2007-07-18  Paul Thomas <pault@gcc.gnu.org>

	PR fortran/31217
	PR fortran/33811
	* gfortran.dg/forall_12.f90: New test.


-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy

Attachment: submit.diff
Description: Text document