From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121463 invoked by alias); 19 Oct 2017 08:03: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 121440 invoked by uid 89); 19 Oct 2017 08:03:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=whichever, blomqvist, Blomqvist X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-wr0-f195.google.com Received: from mail-wr0-f195.google.com (HELO mail-wr0-f195.google.com) (209.85.128.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Oct 2017 08:03:11 +0000 Received: by mail-wr0-f195.google.com with SMTP id k7so7360791wre.2; Thu, 19 Oct 2017 01:03:11 -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=O5XqBQWg5ud+JLrQMqMFgADvFtXhctgQsyz9jwyMck8=; b=ExcQ71xkrKbquC/nlMETSlH5ncovmwx8Ahu0yYjbXQarlbyZQbyDrrZN4+8g8NAqV0 YiH8lVVF1nwSgGkwol0idlCKDYma/XMf+unf1gXgBXG8nNFhZPcVheORbN2p50Y54tLj KRiX/Cb8YJMUDjDDPk/Slz4u+RsbQ4jwqWj1miCVfx5mf1+fIzAJuBa4jywRwXERuo+E r/8iNTrfnM1jHGORqqfUW06CJSqRiqteWPGh8jkRD0AgOmbCfr3hs+KUR1PUNXxw5YCq S0/27hdya0rX+h/i1Xw7Lglpv9s6Nhn/cty+A6Ye1SUwfgW4VH4y7DTr8JTxNENgvhkZ brhw== X-Gm-Message-State: AMCzsaXgypc3YULmn/IHKGVU1vSqIih0TgYGFTJGjxcR6pMCJiuxmahr L5z+Ou8j2EpR6Rrc5MGXxsQ= X-Google-Smtp-Source: ABhQp+Rx/VYQAhWAZO8+J7HgVD9KujbGjXhpt86BXQdTFxDWoQuTnD6+vBba9sia0nqHpHZ8pZ1fHw== X-Received: by 10.223.183.1 with SMTP id l1mr664144wre.139.1508400189683; Thu, 19 Oct 2017 01:03:09 -0700 (PDT) Received: from nbbrfq.cc.univie.ac.at (91-119-106-232.dsl.dynamic.surfer.at. [91.119.106.232]) by smtp.gmail.com with ESMTPSA id c4sm7920345wre.57.2017.10.19.01.03.08 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 19 Oct 2017 01:03:08 -0700 (PDT) Date: Thu, 19 Oct 2017 08:03:00 -0000 From: Bernhard Reutner-Fischer To: Janne Blomqvist Cc: Fortran List , GCC Patches Subject: Re: [PATCH] Derive interface buffers from max name length Message-ID: <20171019080303.3uaqy7x32dus5urx@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84A89967-93B1-47B5-8312-3BC999FEF0EA@gmail.com> User-Agent: NeoMutt/20170609 (1.8.3) X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg00083.txt.bz2 On Sat, Jun 18, 2016 at 09:46:17PM +0200, Bernhard Reutner-Fischer wrote: > On December 3, 2015 10:46:09 AM GMT+01:00, Janne Blomqvist wrote: > >On Tue, Dec 1, 2015 at 6:51 PM, Bernhard Reutner-Fischer > > wrote: > >> On 1 December 2015 at 15:52, Janne Blomqvist > > wrote: > >>> On Tue, Dec 1, 2015 at 2:54 PM, Bernhard Reutner-Fischer > >>> wrote: > >>>> These three function used a hardcoded buffer of 100 but would be > >better > >>>> off to base off GFC_MAX_SYMBOL_LEN which denotes the maximum length > >of a > >>>> name in any of our supported standards (63 as of f2003 ff.). > >>> > >>> Please use xasprintf() instead (and free the result, or course). One > >>> of my backburner projects is to get rid of these static symbol > >>> buffers, and use dynamic buffers (or the symbol table) instead. We > >>> IIRC already have some ugly hacks by using hashing to get around > >>> GFC_MAX_SYMBOL_LEN when handling mangled symbols. Your patch doesn't > >>> make the situation worse per se, but if you're going to fix it, lets > >>> do it properly. > >> > >> I see. > >> > >> /scratch/src/gcc-6.0.mine/gcc/fortran$ git grep > >> "^[[:space:]]*char[[:space:]][[:space:]]*[^[;[:space:]]*\[" | wc -l > >> 142 > >> /scratch/src/gcc-6.0.mine/gcc/fortran$ git grep "xasprintf" | wc -l > >> 32 > > > >Yes, that's why it's on the TODO-list rather than on the DONE-list. :) > > > >> What about memory fragmentation when switching to heap-based > >allocation? > >> Or is there consensus that these are in the noise compared to other > >> parts of the compiler? > > > >Heap fragmentation is an issue, yes. I'm not sure it's that > >performance-critical, but I don't think there is any consensus. I just > >want to avoid ugly hacks like symbol hashing to fit within some fixed > >buffer. Perhaps an good compromise would be something like std::string > >with small string optimization, but as you have seen there is some > >resistance to C++. But this is more relevant for mangled symbols, so > >GFC_MAX_MANGLED_SYMBOL_LEN is more relevant here, and there's only a > >few of them left. So, well, if you're sure that mangled symbols are > >never copied into the buffers your patch modifies, please consider > >your original patch Ok as well. Whichever you prefer. > > > >Performance-wise I think a bigger benefit would be to use the symbol > >table more and then e.g. be able to do pointer comparisons rather than > >strcmp(). But that is certainly much more work. > > Hm, worth a look indeed since that would certainly be a step in the right direction. Installed the initial patch as intermediate step as r253881 for now. thanks, > > > > >> BTW: > >> $ git grep APO > >> io.c: static const char *delim[] = { "APOSTROPHE", "QUOTE", "NONE", > >NULL }; > >> io.c: static const char *delim[] = { "APOSTROPHE", "QUOTE", "NONE", > >NULL }; > > > >? What are you saying? > > delim is duplicated, we should remove one instance. > thanks, >