------- Comment #8 from mikael dot morin at tele2 dot fr 2008-10-28 14:42 ------- Created an attachment (id=16573) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16573&action=view) second fix
This patch solves the problem by releasing the (4) condition, making the loop bounds reset unconditional at the beginning of gfc_trans_create_temp_array. This is harmless because most of the time the loop->from is already zero (there was an assertion for that before PR31610) and the code adds nothing, while in other cases the bounds reset is executed. I had initially a problem though, because then the array indexes for accessing elements of (/1,1,1/) were wrong as the offset for that array was set too early, taking the initial loop bounds into account instead of the later zero-based ones. I looked at what happened in the case of i as its indexes were not miscalculated and found that there was a code for that at the end of gfc_conv_loop_setup. What this patch does is remove the code setting the offset according to the loop in gfc_trans_array_constructor, and allow GFC_SS_CONSTRUCTOR in gfc_conv_loop_setup's code. This patch passes the regression tests without any new failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37903
