Fix str1d deallocation

[Manangka]

Due to a bug in gfortran 11, 12, 13.1, and 13.2 we cant store a str1d in the MemoryType.
Upon deallocation a segmentation fault is produced. That's because due to the bug the len of the character is correctly assigned to the type descriptor

We worked around this by either ignoring it (potential bug) or using the CharString type

In this PR I added another workaround that allows us deallocated the str1d. To do so I'm using a c_ptr cast to readd the needed information to the type descriptor.

Note:
I tested it in WSL using gfortran 11.4
I tested it in WSL using gfortran 12.3
I tested it in WSL using gfortran 13.1
I tested it in WSL using gfortran 13.2
I tested it in WSL using gfortran 13.3
I tested it in WSL using gfortran 14.1

Note2
This also fix the remaining memory leaks we have according to valgrind

Checklist of items for pull request

• Replaced section above with description of pull request
• Closed issue #xxxx
• Referenced issue or pull request #xxxx
• Added new test or modified an existing test
• Ran ruff on new and modified python scripts in .doc, autotests, doc, distribution, pymake, and utils subdirectories.
• Formatted new and modified Fortran source files with fprettify
• Added doxygen comments to new and modified procedures
• Updated meson files, makefiles, and Visual Studio project files for new source files
• Updated definition files
• Updated develop.tex with a plain-language description of the bug fix, change, feature; required for changes that may affect users
• Updated input and output guide
• Removed checklist items not relevant to this pull request

For additional information see instructions for contributing and instructions for developing.

[wpbonelli]

@Manangka I see that gfortran 12 is the oldest supported version right now. I don't see any indication how long they will support 12, but if the bug has been fixed in 13+, this workaround is hopefully temporary?

[Manangka]

@wpbonelli I hope this is temporary as well. I don't know how long we will be supporting gfortran 12 (and 11?) I don't have a clear overview of how many of our users are using it.

[mjr-deltares]

@wpbonelli I hope this is temporary as well. I don't know how long we will be supporting gfortran 12 (and 11?) I don't have a clear overview of how many of our users are using it.

Just a note: the oldest compiler versions are usually on HPC/supercomputers, and they are not as flexible to upgrade (sometimes impossible even) as it would be for your personal machine. MODFLOW on Snellius (Dutch national supercomputer) is currently build with gfortran 12, for example.

[mjr-deltares]

I was thinking, using iso_c_binding is powerful. If we do that, maybe we could make that the type of str1d in the memory manager for the time being? So:

type MemoryType
...
type(c_ptr) :: astr1d

Maybe that's an option too? Let's discuss.

[Manangka]

I was thinking, using iso_c_binding is powerful. If we do that, maybe we could make that the type of str1d in the memory manager for the time being? So:

type MemoryType ... type(c_ptr) :: astr1d

Maybe that's an option too? Let's discuss.

I rather won't do that. Doing so would mean that the "workaround" will also get into the memorymanager. The way it is setup now it is constraint to the memory class

[Manangka]

I tested the code on with different gfortran versions. The bug causing this issue is solved in gfortran 13,3. So from that version and onwards we don't have to apply the workaround anymore.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106317

There is one caveat. In gfortran 13.3 and 14.1 I did get a warning that some variables didn't get deallocated. There could be something else wrong in the compiler, or there might still be something wrong in our code. However we don't get the segementation error anymore

On windows with ifx and ifort everthing works fine

[christianlangevin]

Thanks for this, @Manangka!

[mjr-deltares]

Sorry for the delay, nice job!