From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8713 invoked by alias); 23 Jan 2013 10:06:30 -0000 Received: (qmail 8691 invoked by uid 22791); 23 Jan 2013 10:06:29 -0000 X-SWARE-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mx02.qsc.de (HELO mx02.qsc.de) (213.148.130.14) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 23 Jan 2013 10:06:22 +0000 Received: from archimedes.net-b.de (port-92-195-86-178.dynamic.qsc.de [92.195.86.178]) by mx02.qsc.de (Postfix) with ESMTP id 718FA27604; Wed, 23 Jan 2013 11:06:19 +0100 (CET) Message-ID: <50FFB61B.3060008@net-b.de> Date: Wed, 23 Jan 2013 10:06:00 -0000 From: Tobias Burnus User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130105 Thunderbird/17.0.2 MIME-Version: 1.0 To: Paul Richard Thomas CC: "fortran@gcc.gnu.org" , gcc-patches Subject: Re: [Patch, fortran] PR56008 (and PR47517) [F03] wrong code with lhs-realloc on assignment with derived types having allocatable components References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: 2013-01/txt/msg01137.txt.bz2 Paul Richard Thomas wrote: > *************** gfc_alloc_allocatable_for_assignment (gf > *** 8224,8229 **** > --- 8250,8262 ---- > desc, tmp); > tmp = gfc_conv_descriptor_dtype (desc); > gfc_add_modify (&alloc_block, tmp, gfc_get_dtype (TREE_TYPE (desc))); > + if ((expr1->ts.type == BT_DERIVED) > + && expr1->ts.u.derived->attr.alloc_comp) > + { > + tmp = gfc_nullify_alloc_comp (expr1->ts.u.derived, desc, > + expr1->rank); > + gfc_add_expr_to_block (&alloc_block, tmp); > + } > alloc_expr = gfc_finish_block (&alloc_block); When glancing at the patch, I wondered whether it would be better to use CALLOC instead of MALLOC and avoid the nullification: /* Malloc expression. */ gfc_init_block (&alloc_block); tmp = build_call_expr_loc (input_location, builtin_decl_explicit (BUILT_IN_MALLOC), 1, size2); On the other hand, the nullification is probably still required for REALLOC. If so, the question is whether CALLOC + nullify in the realloc branch - or malloc + nullify after the realloc/malloc branches is better. Hence, your version is probably fine. Sorry for not yet reviewing your patch. Tobias PS: Regarding "allocatable" and "memory leak": PR55603 has as similar issue. For scalars, gfortran never frees allocatable function results; that's independent of the LHS (allocatable, pointer, neither). Thus, if you are in the mood of fixing those kind of bugs … (Actually, I am not even sure whether that's restricted to allocation, it might also occur with expressions like "a = f() + 5". Untested.)