As reported by Andrew Benson in the thread starting at http://gcc.gnu.org/ml/fortran/2012-10/msg00087.html The problem is that gfortran generates the wrong code for: targetNode%cBh(2)%hostNode => targetNode where "cBh" is a polymorphic array. The offset is calculated as ((base_type *)targetNode->_data->cBh->_data)[ index ].host Instead of the proper: targetNode->_data->cBh->_data.data + (index * targetNode->_data->cBh->_vptr_size) Test case: http://gcc.gnu.org/ml/fortran/2012-10/msg00100.html Analysis: http://gcc.gnu.org/ml/fortran/2012-10/msg00101.html
(In reply to comment #0) > Test case: http://gcc.gnu.org/ml/fortran/2012-10/msg00100.html Note: While this test case fails with trunk, it seems to work with 4.7.
Revision 187190 is OK, revision 187198 is not -> likely r187192.
Related (or duplicate): PR 55057.
This is another result of the underlying bug unearthed in PR54990. Index: gcc/fortran/trans-array.c =================================================================== *** gcc/fortran/trans-array.c (revision 194721) --- gcc/fortran/trans-array.c (working copy) *************** static tree *** 3099,3112 **** build_array_ref (tree desc, tree offset, tree decl) { tree tmp; /* Class array references need special treatment because the assigned type size needs to be used to point to the element. */ if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (desc)) && TREE_CODE (desc) == COMPONENT_REF ! && GFC_CLASS_TYPE_P (TREE_TYPE (TREE_OPERAND (desc, 0)))) { ! tree type = gfc_get_element_type (TREE_TYPE (desc)); tmp = TREE_OPERAND (desc, 0); tmp = gfc_get_class_array_ref (offset, tmp); tmp = fold_convert (build_pointer_type (type), tmp); --- 3099,3118 ---- build_array_ref (tree desc, tree offset, tree decl) { tree tmp; + tree type; + + type = TREE_TYPE (TREE_OPERAND (desc, 0)); + if (TYPE_CANONICAL (type) + && GFC_CLASS_TYPE_P (TYPE_CANONICAL (type))) + type = TYPE_CANONICAL (type); /* Class array references need special treatment because the assigned type size needs to be used to point to the element. */ if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (desc)) && TREE_CODE (desc) == COMPONENT_REF ! && GFC_CLASS_TYPE_P (type)) { ! type = gfc_get_element_type (TREE_TYPE (desc)); tmp = TREE_OPERAND (desc, 0); tmp = gfc_get_class_array_ref (offset, tmp); tmp = fold_convert (build_pointer_type (type), tmp); fixes it. As remarked in PR54990, I do not know why this regression has occurred. Evidently, GFC_CLASS_TYPE_P is not being transferred from the canonical type, whereas this was happening before the regression (or a new type was not being generated?). I will investigate more. I have taken this PR. Cheers Paul
Fixed by http://gcc.gnu.org/viewcvs?view=revision&revision=194953 It did not register here because I screwed up on the ChangeLog Format (I really am rusty :-) ). I'll fix this tonight. Thanks for the report. Paul
Author: pault Date: Mon Jan 7 19:10:32 2013 New Revision: 194994 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194994 Log: 2013-01-07 Paul Thomas <pault@gcc.gnu.org> PR fortran/53876 PR fortran/54990 PR fortran/54992 * ChangeLog: Correct format error in revision 194953 2013-01-07 Paul Thomas <pault@gcc.gnu.org> PR fortran/53876 PR fortran/54990 PR fortran/54992 * ChangeLog: Correct format error in revision 194953 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog