From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19817 invoked by alias); 7 Jul 2011 12:19:18 -0000 Received: (qmail 19799 invoked by uid 22791); 7 Jul 2011 12:19:17 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mx01.qsc.de (HELO mx01.qsc.de) (213.148.129.14) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 07 Jul 2011 12:19:03 +0000 Received: from [192.168.178.22] (port-92-204-30-62.dynamic.qsc.de [92.204.30.62]) by mx01.qsc.de (Postfix) with ESMTP id AFE963DC21; Thu, 7 Jul 2011 14:19:01 +0200 (CEST) Message-ID: <4E15A435.30901@net-b.de> Date: Thu, 07 Jul 2011 12:28:00 -0000 From: Tobias Burnus User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110414 SUSE/3.1.10 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mikael Morin CC: fortran@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: [Patch, Fortran] PR fortran/49648 ICE with use-associated array-returning function References: <201107071242.14440.mikael.morin@sfr.fr> In-Reply-To: <201107071242.14440.mikael.morin@sfr.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-07/txt/msg00464.txt.bz2 Dear Mikael, On 07/07/2011 12:42 PM, Mikael Morin wrote: > this is the patch I posted yesterday on bugzilla at > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49648#c8 > > This patch calls gfc_resolve_array_spec on sym->result, which calls > gfc_resolve_expr on every bound, which in turn calls resolve_ref on them. > > As pointed out by Tobias in the PR audit trail, there could be some similar > bugs with character lengths. The character length variant of the testcase > doesn't ICE however, so I have decided to propose the patch as is, because it > should be a step forward anyway. My impression is that the type-spec - contrary to the array spec - is shared between the function symbol and the result symbol. That's also what I get for the example you posted, when looking at the expressions in the debugger. Thus, it seems as the array spec is the only case where one needs to do something. > Regression tested on x86_64-unknown-freebsd8.2. OK for trunk? Should I > backport to the branches? OK. Regarding backporting: I don't know; I don't have a strong opinion. It's not a regression - but it is also a simple fix. Thus, backporting to 4.6 should be OK, but I wouldn't port it to older versions. Thanks a lot for the patch and going though resolve.c! Tobias