Mattermost discussion on PR98426

Mattermost discussion on PR98426

[Jerry D]

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.

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 -

Re: Mattermost discussion on PR98426

[Bernhard Reutner-Fischer]

Hi Jerry, all!

Just a quick comment for that area.

On Thu, 25 Apr 2024 20:00:24 -0700
Jerry D <jvdelisle2@gmail.com> 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.nop@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/20211114231748.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

Re: Mattermost discussion on PR98426

[Tobias Burnus]

[-- Attachment #1: Type: text/plain, Size: 416 bytes --]

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

[Jerry Delisle]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

On Fri, Apr 26, 2024, 2:47 AM Tobias Burnus <burnus@net-b.de> 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

[Jerry D]

On 4/26/24 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

I found these (and several more) patches dated around 2018.

https://gcc.gnu.org/git/?p=gcc-old.git;a=commitdiff;h=d38e734485cc84ed0eda7f30b16fb62bdb0cb174

https://gcc.gnu.org/git/?p=gcc-old.git;a=commitdiff;h=2b3f2cd325234a8eb9e9e197ebbbc18de623d7bb

https://gcc.gnu.org/git/?p=gcc-old.git;a=commitdiff;h=f77b9ecc5fac886164fee75254aca14c42e95f1b

https://gcc.gnu.org/git/?p=gcc-old.git;a=commitdiff;h=48d6fc163c26752ca53f23d8b846102338c32ad9

The question is how do we merge these with current master?

Jerry --

Re: Mattermost discussion on PR98426

[rep.dot.nop]

On 27 April 2024 16:11:32 CEST, Jerry D <jvdelisle2@gmail.com> wrote:

>
>I found these (and several more) patches dated around 2018.
>
>https://gcc.gnu.org/git/?p=gcc-old.git;a=commitdiff;h=d38e734485cc84ed0eda7f30b16fb62bdb0cb174

IOPARM_type_char2 stands out. I do not remember why, but it looks odd that I had to not rely on it being seen yet (if that was deliberate in the first place)..

hmz
Is that what I sent in the last thread, or did I revisit this, I.e. that oddity went away in the patch to the ML?

thanks

Re: Mattermost discussion on PR98426

[rep.dot.nop]

On 27 April 2024 22:02:21 CEST, rep.dot.nop@gmail.com wrote:
>On 27 April 2024 16:11:32 CEST, Jerry D <jvdelisle2@gmail.com> wrote:
>
>>
>>I found these (and several more) patches dated around 2018.
>>
>>https://gcc.gnu.org/git/?p=gcc-old.git;a=commitdiff;h=d38e734485cc84ed0eda7f30b16fb62bdb0cb174
>
>IOPARM_type_char2 stands out. I do not remember why, but it looks odd that I had to not rely on it being seen yet (if that was deliberate in the first place)..
>
>hmz
>Is that what I sent in the last thread, or did I revisit this, I.e. that oddity went away in the patch to the ML?
>
>thanks

I think this boils down to minit as asked/questioned upthread. But that's done by now.