Re: Mattermost discussion on PR98426

2024-04-26 Thread Jerry Delisle
On Fri, Apr 26, 2024, 2:47 AM Tobias Burnus  wrote:

> Hi Bernhard, hello all,
> Bernhard Reutner-Fischer wrote:
>
> PS: unfortunately the git branch 
> (https://gcc.gnu.org/git/?p=gcc.git;a=log;h=refs/heads/aldot/fortran-fe-stringpool
>  ) mentioned in mail (I) lived in the old git, before we switched to
> git, and i fear that branch maybe got lost.
>
> Try gcc-old.git instead:
>
>
> https://gcc.gnu.org/git/?p=gcc-old.git;a=log;h=refs/heads/aldot/fortran-fe-stringpool
> Tobias
>

Thanks for all this information. At least we don't start from zero.

Jerry -

>


Re: Mattermost discussion on PR98426

2024-04-26 Thread Tobias Burnus

Hi Bernhard, hello all,

Bernhard Reutner-Fischer wrote:

PS: unfortunately the git branch (
https://gcc.gnu.org/git/?p=gcc.git;a=log;h=refs/heads/aldot/fortran-fe-stringpool
  ) mentioned in mail (I) lived in the old git, before we switched to
git, and i fear that branch maybe got lost.


Try gcc-old.git instead:

https://gcc.gnu.org/git/?p=gcc-old.git;a=log;h=refs/heads/aldot/fortran-fe-stringpool

Tobias

Re: Mattermost discussion on PR98426

2024-04-26 Thread Bernhard Reutner-Fischer
Hi Jerry, all!

Just a quick comment for that area.

On Thu, 25 Apr 2024 20:00:24 -0700
Jerry D  wrote:

> Hi posted some thoughts on the subject at our mattermost workspace.
> 
> This particular PR caught my attention because I have done things like 
> this before. I am looking forward to gcc15. I think changing things at 
> this point might be a bit intrusive.

Agree, clearly gcc-15 material.

> 
> I am thinking about:
> 
> "The FNV-1a algorithm is:
> 
> hash = FNV_offset_basis
> for each octetOfData to be hashed
>  hash = hash xor octetOfData
>  hash = hash * FNV_prime
> return hash"
> 
> Found here:
> 
> https://softwareengineering.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed
> 
> If you are interested, comment on MatterMost.
> 
> Jerry -

As you may remember i was looking into using the stringpool for names
in the frontend. The plan was to
1) use the stringpool for names
2) Use a hashmap (or some suitable data structure) to lookup names
instead of lots of strcmp().

I posted patches for 1) to that effect here in this thread:
(I)
https://inbox.sourceware.org/fortran/20230413230440.229ebc2f@nbbrfq/

AFAIR part 1) was complete. But the (only) tricky part of 1) involved
module symbols, as mentioned in the link above.
Specifically "[PATCH,FORTRAN v2] Use stringpool on loading module
symbols": 
https://inbox.sourceware.org/gcc-patches/20180919225533.20009-1-rep.dot@gmail.com/
I described the problems i was seeing with module writing,
free_pi_tree (around true_name), finalization wrapper vars and
names of fixups in the mail (I). Unfortunately this would involve a
bump of the module version. Furthermore this patch was not reviewed
yet, so if you have comments, i'm all ears :) Thoughts?

There in (I) you can also see why i think that using attr.artificial is
the way to go. Later i also sent a patch (that was also not applied
yet) to additionally tweak class component and such internally generated
symbols to be marked as artificial:
https://inbox.sourceware.org/fortran/2024231748.376086cd@nbbrfq/
Thoughts?

It would be nice if we could finally tackle this for gcc-15, IMHO.

PS: unfortunately the git branch (
https://gcc.gnu.org/git/?p=gcc.git;a=log;h=refs/heads/aldot/fortran-fe-stringpool
 ) mentioned in mail (I) lived in the old git, before we switched to
git, and i fear that branch maybe got lost. But i strongly believe
that all patches of the fortran-fe-stringpool branch can be found in
the thread mentioned above.

HTH