From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4537 invoked by alias); 29 May 2007 05:59:49 -0000 Received: (qmail 4500 invoked by uid 48); 29 May 2007 05:59:41 -0000 Date: Tue, 29 May 2007 05:59:00 -0000 Message-ID: <20070529055941.4499.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "brooks at gcc dot gnu dot org" 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: 2007-05/txt/msg02572.txt.bz2 ------- Comment #4 from brooks at gcc dot gnu dot org 2007-05-29 05:59 ------- I misunderstood something slightly in that last comment; MERGE is elemental, so the conforming I mentioned doesn't matter. Also, my guess that fixing the transfer("A", "x", 20) problem would fix the whole thing proved to be incorrect. So, even once the first bit is fixed, if we change the code to be legitimate, as follows, then it still has an error: character(len=20) :: string logical :: a(20) write(*,*) transfer (merge (transfer("A", "x", 20), "b", a), string ) end Specifically, we ICE by failing the "gcc_assert (integer_zerop (loop -> from[n]))" at line 593 of trans-array.c, when doing gfc_conv... stuff to the arguments of the outer transfer function. I'm having a bear of a time tracking down why this is happening. The problem is that we're generating a temporary, so loop->temp_dim is 1 (as set in gfc_trans_constant_array_constructor, line 1576). However, the loop seems to be picking up dimensions from the result of the inner transfer function somehow. Walking through the ss list for the loop gives a GFC_SS_CONSTRUCTOR, a GFC_SS_SCALAR, and a GFC_SS_SECTION, and the GFC_SS_SECTION causes the info->start[0] and info->end[0] values to be set (to 1 and 20, respectively) in gfc_conv_ss_startstride, which then propagate to the from[0] and to[0] values for the loop. I can't seem to duplicate this with any other set of functions. It's only happening with characters, not integers, and if I break up the expression or substitute other things for transfer and merge, it doesn't replicate this behavior. Help? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610