[Bug fortran/43896] [fortran-dev Regression] ICE in gfc_conv_variable, at fortran/trans-expr.c:551

2010-04-26 Thread janus at gcc dot gnu dot org
--- Comment #5 from janus at gcc dot gnu dot org 2010-04-26 19:10 --- (In reply to comment #3) The ICE happens with 4.5, trunk and fortran-dev. Actually this is only half-true. With fortran-dev one already gets an ICE on the first file, which is different from the one reported in

[Bug fortran/43896] [fortran-dev Regression] ICE in gfc_conv_variable, at fortran/trans-expr.c:551

2010-04-26 Thread janus at gcc dot gnu dot org
--- Comment #6 from janus at gcc dot gnu dot org 2010-04-26 19:33 --- Here is a reduced test case for the fortran-dev failure, which turns out to be pretty trivial. All it takes is an array-valued TBP (wonder if we don't have such a thing in the testsuite already): module

[Bug fortran/43896] [fortran-dev Regression] ICE in gfc_conv_variable, at fortran/trans-expr.c:551

2010-04-26 Thread fmartinez at gmv dot com
--- Comment #7 from fmartinez at gmv dot com 2010-04-26 20:34 --- Actually both ROTATION_MATRIX_TIMES_VECTOR are pure; the one in m_vector is elemental, therefore pure, and the one in m_rotation_matrix is pure. I have changed the one in m_rotation_matrix to ROTATION_MATRIX_TIMES_ARRAY

[Bug fortran/43896] [fortran-dev Regression] ICE in gfc_conv_variable, at fortran/trans-expr.c:551

2010-04-26 Thread janus at gcc dot gnu dot org
--- Comment #8 from janus at gcc dot gnu dot org 2010-04-26 20:40 --- Ok, here is a preliminary patch which fixes the fortran-dev problem: Index: gcc/fortran/symbol.c === --- gcc/fortran/symbol.c(revision 158741)