From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46948 invoked by alias); 5 Sep 2018 18:57:39 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 46927 invoked by uid 89); 5 Sep 2018 18:57:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,KAM_NUMSUBJECT,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=surface, H*c:alternative X-HELO: mail-yw1-f52.google.com Received: from mail-yw1-f52.google.com (HELO mail-yw1-f52.google.com) (209.85.161.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 05 Sep 2018 18:57:36 +0000 Received: by mail-yw1-f52.google.com with SMTP id n207-v6so3063242ywn.9; Wed, 05 Sep 2018 11:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QMGoaPYennwjV2DBZTMEVlETPyGeIofJSi8VgUt5YE0=; b=aNzWvtAIlk1C4ArTBJ/SXsLUG094MrG5Ec7A1Yq6ScJRG6LagVprjjnqQ0XhdkXsMe 3BSXUeFA6ZPdwivCiEuAUbxRFN6WFFQBblcZcDyRZ89ntShojALJiVb/H/D0sw1njpaw sZ8OkwNsjkfnqBgTIhi594uU0qcEM2WMJdC+QNYB1CovShgUOnBm5iPm2z9HD3MD6DP/ VkkTN264f9n5wYjM5sRrHWmNIjcY1tQV8hie1Qk7BIZLF5e+GIGBADKTBfU0x61RLK2R HdhzmlIfqvrmVz5oEvF6Okg4iNDianhfaHhiyyR0UUKi9r/m7WD/GQ7sv28oG3JrJlPt Xl3A== MIME-Version: 1.0 References: <20180905145732.404-1-rep.dot.nop@gmail.com> In-Reply-To: <20180905145732.404-1-rep.dot.nop@gmail.com> From: Janne Blomqvist Date: Wed, 05 Sep 2018 18:57:00 -0000 Message-ID: Subject: Re: [PATCH,FORTRAN 00/29] Move towards stringpool, part 1 To: Bernhard Reutner-Fischer Cc: Fortran List , GCC Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg00066.txt.bz2 On Wed, Sep 5, 2018 at 5:58 PM Bernhard Reutner-Fischer < rep.dot.nop@gmail.com> wrote: > Hi, > > The fortran frontend still uses stack-based handling of (symbol) names > with fixed-sized buffers. Furthermore these buffers often are too small > when dealing with F2003 identifiers which can be up to, including 63 > bytes long. > > Other frontends use the stringpool since many years. > This janitorial series is a first step towards using the stringpool in > the frontend. > Consequently this allows us to use pointer-comparison to see if two > given "names" are identical instead of doing lots and lots of string > comparisons. > > > Part 1 switches most of the fortran FE. An eventual part 2 would > continue to switch the few remaining stack-based identifier > manipulations to use the stringpool. My initial plan was to also see if > switching gfc_symtree from treap to a hash_map would bring us any > measurable benefit, but that, too, is left for an eventual part 2. > > Bootstrapped and regtested on x86_64-foo-linux. > > I'd appreciate if someone could double check for regressions on other > setups. Git branch: > > https://gcc.gnu.org/git/?p=gcc.git;a=log;h=refs/heads/aldot/fortran-fe-stringpool > > Ok for trunk? > Hi, this is quite an impressive patch set. I have looked through all the patches, and on the surface they all look ok. Unfortunately I don't have any exotic target to test on either, so I think you just have to commit it and check for regression reports. Though I don't see this set doing anything which would work differently on other targets, but you never know.. I'd say wait a few days in case anybody else wants to comment on it, then commit it to trunk. Thanks for doing all this! -- Janne Blomqvist