From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31967 invoked by alias); 29 Oct 2008 21:00:08 -0000 Received: (qmail 31613 invoked by uid 48); 29 Oct 2008 20:59:53 -0000 Date: Wed, 29 Oct 2008 21:00:00 -0000 Message-ID: <20081029205953.31612.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/37749] ICE on array section with vector subscript In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "mikael dot morin at tele2 dot fr" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-10/txt/msg01944.txt.bz2 ------- Comment #1 from mikael dot morin at tele2 dot fr 2008-10-29 20:59 ------- Reduced case: subroutine subr (m, n, a, b, c, d, p) implicit none integer m, n real a(m,n), b(m,n), c(n,n), d(m,n) integer p(n) d = a(:,p) - matmul(b, c) end subroutine The problem is with a(:,p) - matmul(b,c) It arises because: (1) gfc_conv_loop_setup chooses matmul's ss to setup the loop bounds. This explains why -matmul(b,c) + a(:,p) works. (2) The loop->to are asserted to be NULL in gfc_conv_loop_setup (GFC_SS_FUNCTION case) (3) gfc_add_ss_loop_code for the second dimension of a(:,p) calls gfc_set_loop_bounds_from_array_spec which sets the second dimension of the loop.to (4) in the loop setting the descriptor in gfc_trans_create_temp_array, in the first iteration, (n = 0), loop.to is NULL, and the size is set to NULL. (5) In the next iteration, (n = 1), loop.to != NULL, and the loop follows the normal path. The size however was set to NULL (condition (4)). (4) and (5) explain why it works with a(q,:) - matmul(b,c) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37749