Re: Triage of fortran FE regressions

[Mikael Morin <mikael.morin@sfr.fr>]

Hello Paul,

a status update for the bugs I am associated with.

> Reported in 2013 or before:
[...]
> 57048     [4.9/5/6 Regression] Handling of C_PTR and C_FUNPTR leads to
> reject valid
>       Mikael was working on it.
I wasn't even close to a working patch, and have no time for it in the 
foreseeable future.
[...]

>
> Reported in 2014:
[...]
> 60500     [4.9/5/6 Regression] Spurious warning on derived type initialization
>       Mikael diagnosed the problem.
Initialisation is somewhat messy, it is sometimes generated by 
artificial statements during resolution, sometimes done in the 
translation phase.  It's easy to fix one end and break the other end 
(ending up with either conflicting initializations or missing ones).
I haven't really tried to fix this one, basically the initialization 
code that caused the bug should be moved from the resolution phase to 
the translation phase.
[...]
> 61831     [4.9/ 5 Regression] runtime error: pointer being freed was
> not allocated
>       Mikael, is this fixed or not?
The original problem is fixed on trunk as far as I know.
For the branches the kludge proposed by Dominique (which regresses a 
memory leak PR) could be used.  I had planned to strip the boolean 
argument from expr_may_alias_variables and replace Dominique's kludge by 
a call to expr_may_alias_variables as patch for the branches.
IIRC, it didn't simply pass the testcase, or I had a more complex one 
that failed, and I gave up after an hour or so scratching my head.

>
> Reported in 2015
[...]
> 66089     [6 Regression] elemental dependency mishandling when derived
> types are involved
>      Mikael posted fix.
The fix works as far as I know, but each condition in 
gfc_scalar_elemental_arg_saved_as_reference can potentially lead to the 
same bug and needs auditing.
[...]
> 68560     [6 Regression] The test gfortran.dg/shape_8.f90 now fails
> when compiled with -flto
>      Mikael was on the way to a patch....
The patch has been needing one more fix after one more fix.


In general, I have little time to devote to gfortran.
I can have a look at PR66089 as a start, possibly PR68560 as well, but I 
probably need more time for the other, so don't hold your breath for them.

Mikael