Am 23.07.24 um 08:09 schrieb Paul Richard Thomas:
Hi Thomas,
Welcome back!
I was going to propose that we introduce -std=f2028 and to allow
proposed features to be run only if that option is selected; ie. not by
default or -std=gnu. gfortran.dg should have an f2028 directory as well.
That makes sense, I think.
I have already written and tested a patch for Reinhold Bader's proposed
assumed rank features, extended to include pointer assignment. Please
see the attached. I was so taken by his proposal because it is so
intuitive and easy to implement that I decided to pursue it in his
memory. I will be writing the standards boilerplate as well.
Sounds good!
The likely timescale for implementation of f2028 is such that I am
unlikely to be around and so wanted to be sure that such test work as I
do is incorporated in gfortran. We have found in the past that
experimental branches are fraught with maintenance problems and tend to
wither and die.
What do you think?
I agree that branches should be merged into main line development
as soon as possible. However, the work on UNSIGNED will be quite
extensive, and there will be a time (such as right now) where it
is not useful. I think we should at least wait until something
can be done with it.
What I would propose is to use a public branch for development
until what is in there is actually useful for some work, and then
to merge it into trunk and do further development work there.
Things that should work before merging to trunk:
Basic arithmetic, I/O, constant simplification, selected_uint_kind
and friends, UNSIGNED entities in modules, bit intrinsics and
fixing the ICEs that come up. I have started with that, and it seems
to be going surprisingly fast at the moment, but I am sure that problems
will come up.
To do next: Array intrinsics, ISO_C_BINDING, ISO_FORTRAN_ENV,
other intrinsics, the rest of it and fixing even more ICEs.
That could be then done on trunk.
How does that sound?
Best regards
Thomas
