------- Comment #2 from paul dot thomas at jet dot uk 2006-05-04 09:50 ------- (In reply to comment #1) > Confirmed, this is a front-end issue. > we have: > struct calc_signal_type D.904; > D.904 = (*(struct calc_signal_type[0:] *) > outputs->data)[outputs->dim[0].stride * NON_LVALUE_EXPR <S.4>]; > (*D.896)[(NON_LVALUE_EXPR <S.4> + D.900) * D.903 + D.897].used = > (*used.0)[D.904 * D.902 + D.895]; > but really D.904 should be an integer and there should be a COMPONET_REF to > "signal_number" there. > The parse tree is ok though: > ASSIGN activate_gd_calcs:outputs(FULL) % used > activate_gd_calcs:used(activate_gd_calcs:outputs(FULL) % signal_number) > So this is a bug in the trans* functions.
I am seeing this problem of incorrect casting in several failing testcases for the allocatable component patch that Erik and I are working on. None of them generate the ICE and this has made the problem very hard to pinpoint. For example, several of the varying string testsuite crash because trans-io is being fed characters, when an integer is expected, or a string comparison is producing a pointer to one of the strings, instead of a logical. This case helps a lot. Thanks, Richard. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27411