Re: Triage of fortran FE regressions

[Paul Richard Thomas <paul.richard.thomas@gmail.com>]

Hi Mikael,

I had thought that you might be tied up! Anything that you can do
would be gratefully received.

Cheers

Paul

On 6 January 2016 at 19:47, Mikael Morin <mikael.morin@sfr.fr> wrote:
> 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



-- 
The difference between genius and stupidity is; genius has its limits.

Albert Einstein