From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96578 invoked by alias); 31 Oct 2017 20:35:15 -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 96552 invoked by uid 89); 31 Oct 2017 20:35:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=H*r:sk:20.2017, sk:inquiry X-HELO: mail-wm0-f46.google.com Received: from mail-wm0-f46.google.com (HELO mail-wm0-f46.google.com) (74.125.82.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 31 Oct 2017 20:35:14 +0000 Received: by mail-wm0-f46.google.com with SMTP id b9so1334378wmh.0 for ; Tue, 31 Oct 2017 13:35:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=785aIJPZss2hWo7+WYGffAIQiuwIJJz38x6NinM6kp0=; b=eXs8jffiT440nMWvT2LKt+Nb+bBMnG8rJ/CQ+woqVi0NhwjWgZCU0YbAszyYmBLUaj Jz94/cSqaP/x2xSjUBsqSbhJAYV5a1TrjbbLZCddwREc+2afzEpL2skAn3c9awpanesl pKOnE7GXH0XCC/y1BzG64Qu/h9WKUaGg2MDqB8sqX2YUYesnG+tRmjM9conSjMPYDUgo RtgfKjEGoRKGjuDodK+Xq7h02MRdKUrSuIW1B1xVc02gm2C0mq8CsibpQrn3hlCnj9Df r95N4CmN5hyWG+LygXojnkHCOPTYBhHL06f1JSBIVB6i7MIzHHAlX+fMYHpDqXPjdAux CyyQ== X-Gm-Message-State: AMCzsaXo1Ncff2PkFxKbNORA0Qq4911p3luJTNcreSElUV1qN/dDOrb6 AMGpjxvxauGuWl5piuNKPbY= X-Google-Smtp-Source: ABhQp+R2Mh1MawIt9Y/ChhSIAfsKW05zngr0Cf4DB+ogS1wV0jUTrlgtHZCPH5aYn1y7mOq4pF0kvg== X-Received: by 10.28.23.129 with SMTP id 123mr2771692wmx.54.1509482112322; Tue, 31 Oct 2017 13:35:12 -0700 (PDT) Received: from nbbrfq.cc.univie.ac.at (194-96-26-143.adsl.highway.telekom.at. [194.96.26.143]) by smtp.gmail.com with ESMTPSA id f10sm2192834wrg.20.2017.10.31.13.35.11 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 31 Oct 2017 13:35:11 -0700 (PDT) Date: Tue, 31 Oct 2017 20:35:00 -0000 From: Bernhard Reutner-Fischer To: Thomas Koenig Cc: gfortran , Janne Blomqvist Subject: Re: [PATCH] Derive interface buffers from max name length Message-ID: <20171031203509.mz3cz3v2klxjgcgz@nbbrfq.cc.univie.ac.at> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg00137.txt.bz2 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. 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? thanks