From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121925 invoked by alias); 3 Sep 2018 16:05:08 -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 121894 invoked by uid 89); 3 Sep 2018 16:05:06 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:CAC1Bbc, yesterday, disregard, H*r:sk:b15-v6s X-HELO: mail-oi0-f65.google.com Received: from mail-oi0-f65.google.com (HELO mail-oi0-f65.google.com) (209.85.218.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 03 Sep 2018 16:05:04 +0000 Received: by mail-oi0-f65.google.com with SMTP id b15-v6so1707789oib.10 for ; Mon, 03 Sep 2018 09:05:04 -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=4Zl1vJZgmWsHAQrbSfu2WfUrsriToVmsV2wSf3ik0hA=; b=uuPlWvX9GObTolXICl0NOK1drE5bodhXLiKm/WQvdPDdFrHmipWNVisrlM6kw+zpiq 4Et86wIt5r821txX9e2/vwtykZ+MO79PT6VsCpsH4vg0U6o7VJ7RaA+8hRMTVIBiIdaV u8AYt/8bh8CIcTLtTrgZz8we31pWVdhenhW+SWidOOX5PyozFcbh7wjqUcz3Tne+Vp7Z BFjg12I6cKEMXlIr5w2NHzC00c5wSmJ4PIFfwccyqPRVEhrc+9R6/YB+eQzUv0ireVpW wGxaw/H4oPiAJLcOC3dKxJcoBfI/O+2RmbntlUFOFWzY7g48hnoNZnofBgfgn2nPaRoX N+RA== MIME-Version: 1.0 References: <1448974501-30981-1-git-send-email-rep.dot.nop@gmail.com> <1448974501-30981-2-git-send-email-rep.dot.nop@gmail.com> <84A89967-93B1-47B5-8312-3BC999FEF0EA@gmail.com> <20171019080303.3uaqy7x32dus5urx@nbbrfq.cc.univie.ac.at> <20171031203509.mz3cz3v2klxjgcgz@nbbrfq.cc.univie.ac.at> In-Reply-To: <20171031203509.mz3cz3v2klxjgcgz@nbbrfq.cc.univie.ac.at> From: Bernhard Reutner-Fischer Date: Mon, 03 Sep 2018 16:05:00 -0000 Message-ID: Subject: Re: [PATCH] Derive interface buffers from max name length To: Thomas Koenig Cc: gfortran , Janne Blomqvist Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg00010.txt.bz2 On Tue, 31 Oct 2017 at 21:35, Bernhard Reutner-Fischer wrote: > > On Sat, Oct 21, 2017 at 08:11:24PM +0200, Bernhard Reutner-Fischer wrote: > > > >> JFYI I'm contemplating to move the stack-based allocations > > >> to heap-based ones now, starting with gfc_match_name and > > >> gradually moving to pointer comparisons with the stringpool based > > >> identifiers. I'll strive to suggest something for discussion in > > >> smallish steps when it's ready. > > So i'm mostly through this. > > One thing that is still missing is to hash keywords like basic types, > "ppr@" (decl.c), "kind", "null", module_natures (intrinsic / > non_intrinsic), the "ieee_" stuff in expr.c, things like inquiry_func_f95 > and inquiry_func_f2003 in expr.c, intrinsic operators, c_interop_kinds_table > etc, etc. FWIW: I've saved away a checkpoint that regtests cleanly (against trunk@264039 from yesterday): https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/aldot/fortran-fe-stringpool Please disregard the first 4 patches, they do not belong to this series and will be dropped. There are some more places left to switch. Not yet included is a patch to switch the symtree to a hash_map, which i think is what we may ultimately want to do. AFAIR doing so was running into GC issues which i did not tackle yet. cheers, > I initially thought about just hashing just all minit()ed data and maybe > i'll end up doing this anyway. We will then have to add a helper in the > initialization to setup the stringpool nodes. It would be easiest to > just do all (or most) of the minit()ed data and integral types in one > place unless you prefer to push this down to appropriate places where > applicable, like add e.g. the basic type nodes and the "kind" node > in gfc_init_types. Whatever is deemed to be more appropriate. WDYT?