Dear All, These PRs all have a similar or identical cause. GFC_CLASS_TYPE_P was not being set and/or pointer references were not being cast correctly. The fundamental fix is in trans_types.c(gfc_get_derived_type), where the flag is now explicitly set for field_type, thereby ensuring that no matter what gfc_build_array_type does with the type, the component is correctly marked. A partial fix had been to check the TYPE_CANONICAL in trans-expr.c (gfc_get_vptr_from_expr) and trans-array.c (build_array_ref). I have left these checks in place, just in case any unmarked types get through by different routes.
The testcase is an amalgam of the three contributed testcases,
developed to make certain that the correct dynamic type is being
picked up and that pointer arithmetic is correctly done to access
array elements.
Boostratpped and regtested on FC17/x86_64 - OK for trunk?
Paul
2013-01-06 Paul Thomas <pa...@gcc.gnu.org>
PR fortran/PR53876
PR fortran/PR55990
PR fortran/PR55992
* trans-array.c (build_array_ref): Check the TYPE_CANONICAL
to see if it is GFC_CLASS_TYPE_P.
* trans-expr.c (gfc_get_vptr_from_expr): The same.
(gfc_conv_class_to_class): If the types are not the same,
cast parmese->expr to the type of ctree.
* trans-types.c (gfc_get_derived_type): GFC_CLASS_TYPE_P of
CLASS components must be set.
2013-01-06 Paul Thomas <pa...@gcc.gnu.org>
PR fortran/PR53876
PR fortran/PR55990
PR fortran/PR55992
* gfortran.dg/class_array_15.f03: New test.
submit.diff
Description: Binary data
