Re: [PATCH] Derive interface buffers from max name length

[Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>]

On Tue, 31 Oct 2017 at 21:35, Bernhard Reutner-Fischer
<rep.dot.nop@gmail.com> 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?