From patchwork Wed Oct 3 23:15:39 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Edelsohn X-Patchwork-Id: 188958 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 13E552C0326 for ; Thu, 4 Oct 2012 09:15:52 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1349910953; h=Comment: DomainKey-Signature:Received:Received:Received:Received: MIME-Version:Received:Received:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:Mailing-List: Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:Sender:Delivered-To; bh=J6ZDgtJaMEmQ37X3rnFTx3+eGgg=; b=rB1/chTkIMgP8AuSSCzVKmEXudC4eE4MPqXguOeIprQPh7AlWZBZ0HZSia8vb8 1ExuLW664wi6dp+hUh+2jbg9I2vxMJuwcNbOQ8Nh0nwmMnI7L8+hFOrXBHK/a/mm O0ajnBGKtH4h7EKhXp1bGedFIF/SVrW2He+AxrbfMU0XI= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:MIME-Version:Received:Received:In-Reply-To:References:Date:Message-ID:Subject:From:To:Cc:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=oaYcCW6pYqWUGdYyGNA5JgKZlro+cV+PfplSr5Z1rfUaCtFUQ6xLUgF5yAR/lQ Cr0BiaIhx58LQh19RZ48UZqwUnlaEOJoFywoldeWn3WD1BP4ZrFsR8RMp5+bKJ/b 1FWWADfvfSEU65YOPbsRiiCK+t8T9pz8Dqf5qHEdAqgU4=; Received: (qmail 19496 invoked by alias); 3 Oct 2012 23:15:49 -0000 Received: (qmail 19481 invoked by uid 22791); 3 Oct 2012 23:15:48 -0000 X-SWARE-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, KHOP_RCVD_TRUST, KHOP_THREADED, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-vc0-f175.google.com (HELO mail-vc0-f175.google.com) (209.85.220.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 03 Oct 2012 23:15:41 +0000 Received: by vcqp1 with SMTP id p1so10401146vcq.20 for ; Wed, 03 Oct 2012 16:15:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.148.134 with SMTP id p6mr2033528vcv.3.1349306139857; Wed, 03 Oct 2012 16:15:39 -0700 (PDT) Received: by 10.58.128.169 with HTTP; Wed, 3 Oct 2012 16:15:39 -0700 (PDT) In-Reply-To: <506CA783.20202@net-b.de> References: <506CA783.20202@net-b.de> Date: Wed, 3 Oct 2012 19:15:39 -0400 Message-ID: Subject: Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars From: David Edelsohn To: Tobias Burnus Cc: Fortran List , Paul Richard Thomas , GCC Patches Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Maybe something like the following: Thanks, David On Wed, Oct 3, 2012 at 5:00 PM, Tobias Burnus wrote: > David, > > > David Edelsohn wrote: >> >> I am not sure why you chose a period and how best to correct this. > > > Well, in principle any name which the user cannot enter would do. (Not > enter: At least not as valid Fortran identifier.) > > The reason for choosing "." is that is used elsewhere in > gfortran for such identifier for the string-length variable belonging to > , e.g. "._result" in trans-decl.c. I assume the reason that it > didn't pop up with those is that those are local variables, but I wouldn't > be surprised if it would break elsewhere. > > I wonder whether "@" would work, otherwise, one could also use "_". The only > other problem is that it will break the ABI. On the other hand, it's a > rather new feature and if we bump the .mod version number, the chance that > one effectively forces the user to re-compile is rather high. So far we > always bumped the .mod version number as something changed. There are also > some other patches pending which effectively lead to a bump in the .mod > version. > > (The .mod version won't affect code which doesn't use modules such as > BLAS/LAPACK or any Fortran 66/77 code, but those won't be affected by the > ABI change anyway as there the name doesn't propagate as it does with > modules..) > > > Thanks for investigating the test-suite failure. > > Tobias Index: trans-decl.c =================================================================== --- trans-decl.c (revision 192019) +++ trans-decl.c (working copy) @@ -1097,9 +1097,9 @@ /* Also prefix the mangled name. */ if (sym->module) - name = gfc_get_string (".__%s_MOD_%s", sym->module, sym->name); + name = gfc_get_string ("_F_%s_MOD_%s", sym->module, sym->name); else - name = gfc_get_string (".%s", sym->name); + name = gfc_get_string ("_F_%s", sym->name); length = build_decl (input_location, VAR_DECL, get_identifier (name),