From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 459 invoked by alias); 19 Feb 2014 21:24:02 -0000 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 Received: (qmail 390 invoked by uid 89); 19 Feb 2014 21:23:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 3 recipients X-HELO: mail-wi0-f170.google.com Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com) (209.85.212.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 19 Feb 2014 21:23:57 +0000 Received: by mail-wi0-f170.google.com with SMTP id hi5so5016888wib.3 for ; Wed, 19 Feb 2014 13:23:53 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.87.9 with SMTP id t9mr3593235wiz.36.1392845033092; Wed, 19 Feb 2014 13:23:53 -0800 (PST) Received: by 10.216.18.67 with HTTP; Wed, 19 Feb 2014 13:23:53 -0800 (PST) In-Reply-To: References: <5148D5DF.9000508@net-b.de> Date: Wed, 19 Feb 2014 21:24:00 -0000 Message-ID: Subject: Re: [Patch, fortran] PR51976 - [F2003] Support deferred-length character components of derived types (allocatable string length) From: Paul Richard Thomas To: Janus Weil Cc: Tobias Burnus , "fortran@gcc.gnu.org" , gcc-patches Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2014-02/txt/msg01191.txt.bz2 Dear Janus, I had completely forgotten about this patch... I even thought that it had been applied :-) I'll have time, either tomorrow evening or Saturday to take a look. After nearly 11 months, a couple more days will not hurt! Thanks for bringing it to my attention. Paul On 19 February 2014 16:51, Janus Weil wrote: > The patch was not applying cleanly any more, so here is a re-diffed > version for current trunk. It works nicely on the included test case > as well as the one provided by Walter Spector in comment 12 of the PR. > > Since, also in the current state, "character(:)" works only in a > subset of all cases, I think it cannot hurt to add more cases that > work for 4.9 (even if still not all possible cases work). > > Please let me know what you think ... > > Cheers, > Janus > > > > > 2014-02-19 16:16 GMT+01:00 Janus Weil : >> Hi all, >> >> the patch below has been posted a long time ago, but was never >> actually committed (although it seems close to being finished). >> >> Could it still be considered for trunk? I think it is a rather popular >> feature, which would be helpful for many users ... >> >> Cheers, >> Janus >> >> >> >> 2013-03-19 22:17 GMT+01:00 Tobias Burnus : >>> Dear Paul, dear all, >>> >>> >>> On February 24, 2013 Paul Richard Thomas wrote: >>>> >>>> The attached patch represents progress to date. It fixes the original >>>> problem in this PR and allows John Reid's version of >>>> iso_varying_string/vocabulary_word_count.f90 to compile and run >>>> correctly. It even bootstraps and regtests! >>> >>> >>> Attached is a re-diffed patch; I have additionally fixed some indenting >>> issues. >>> >>> Additionally, I have tested the patch - and it fails with deferred-length >>> *array* character components. See attached test case. Also, the following >>> line of the included test case leaks memory: >>> allocate (array(2), source = [t("abcedefg","hi"), t("jkl","mnop")]) >>> >>> I think at least the array bug should be fixed prior committal. (Fixing the >>> memory leak and some of the below-mentioned issues would be nice, too.) >>> Otherwise, I think the patch looks fine. For completeness, I have some >>> naming remarks, which I would also like to considered: >>> http://thread.gmane.org/gmane.comp.gcc.fortran/40393/focus=281580 >>> >>> Tobias >>> >>> >>>> However, it doe not fix: >>>> PR51976 comment #6 and PR51550 - allocate with typespec ICEs >>>> PR51976 comment #6 FORALL assignment is messed up and ICEs.. >>>> PR47545 the compiler complains about the lack of an initializer for >>>> the hidden character length field. >>>> PR45170 will need going through from one end to the other - there is a >>>> lot of "stuff" here! >>>> >>>> Of these, I consider the fix of the PR47545 problem to be a must and >>>> the allocate with typespec desirable. -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy