Triage of fortran FE regressions

Triage of fortran FE regressions

[Paul Richard Thomas]

Dear All,

On the basis of past performance, we should expect that the release of
6 branch should occur in April. I though that it is timely to do a
triage of regressions and serious bugs. Note that the list below is
not a triage, in that the DOAs and walking wounded are not identified.
I thought that best done after you have checked the status of the PRs
that you are associated with.

We have 43 front-end regressions right now, which is far too many.
However, roughly 20 either look as if they have been fixed or have
fixes posted. It would be helpful, where you are fingered below, if
you could check the status of the corresponding PRs and, if you think
that you can, take them on. Equally, if you can take a PR or two for
which there has been no activity, that would be great.

It is encouraging that 23/43 of the regressions were reported in 2015
since it does imply that we are continuing to make progress, even at
the cost of breaking things occasionally :-)

I will post a similar message in respect of the library regressions
and the "serious bugs".

With best regards

Paul

Reported in 2013 or before:
42954     [4.9/5/6 regression] TARGET_*_CPP_BUILTINS issues with gfortran
     FX was working on this. Can it be even partially completed?
50410     [4.9/5/6 Regression] ICE in record_reference
    Fix posted by Tobias + Steve's fix for the ICE. Testcases needed?
54070     [4.9/5/6 Regression] Wrong code with allocatable
deferred-length (array) function results
     Paul has patch since 11/15 that fails at any level of
optimization. As of 04/01/15 have picked it up again
57019     [4.9/5/6 Regression] Compiler crashes (and make wrong
assignments) at some combinations of pointers
     Response here has always been "descriptor reform". However,
Tobias and Paul have stopped effort on fortran-dev. Paul will look at
the kludgy fix.
57048     [4.9/5/6 Regression] Handling of C_PTR and C_FUNPTR leads to
reject valid
     Mikael was working on it.
57129     [4.9/5/6 Regression] Improve error message for conflicts
between PROCEDURE and DERIVED.
    Looks like it has been fixed. Paul will verify and close.
57197     [Fortran-Dev][Regression] ICE in record_reference, at cgraphbuild.c:66
    Leave for the time being
57611     [Fortran-Dev Regression] Too much memory allocated
(gfortran.dg/coarray_lib_alloc_2.f90)
     Leave for the time being
59107     [4.9/5/6 Regression] Spurious "Type specified for intrinsic
function 'command_argument_count' at (1) is ignored" under
-Wsurprising.
     Janus and Dominique posted fixes

Reported in 2014:
59781     [4.9/5/6 Regression] [F03] Incorrect initialisation of
derived type     2015-06-26
    Janus and Dominique were working on this. Patch causes some
co-array failures which should be easy to fix.
60483     [4.9/5/6 Regression] No IMPLICIT type error with: ASSOCIATE(
X => derived_type() ) [i.e. w/ structure constructor]
     Low hanging fruit?
60500     [4.9/5/6 Regression] Spurious warning on derived type initialization
     Mikael diagnosed the problem.
60526     [4.9/5/6 Regression] Accepts-invalid: Variable name same as type name
     No activity but should be straightforward.
60576     [4.9/5/6 Regression] FAIL: gfortran.dg/assumed_rank_7.f90
     Was closed on 28/03/14 but then reopened - looks to be something
that must be fixed.
60795     [4.9/5/6 Regression] Wrong length when allocating character array
     Looks like it has been fixed. Paul will verify and close.
61156     [4.9/5/6 Regression] Internal compiler error for Fortran
files when specifying a file instead of an include directory with -I
    Easy to fix?
61420     [4.9/5/6 Regression] type bound procedure with pass
attribute, that returns a procedure pointer, fails to compile
    Funny one - implicit none causes error. Janus started diagnosis.
61527     [4.9/5/6 Regression] class/extends, multiple generic
assignment, accept invalid
     Janus posted fix that caused a few regressions.
61765     [4.9/5/6 Regression] Rejects valid BIND(C) ENTRY
     Dominique identified revision that caused regression
61831     [4.9/ 5 Regression] runtime error: pointer being freed was
not allocated
     Mikael, is this fixed or not?

Reported in 2015
65045     [4.9/5 Regression] ICE when using the same name for a block
and a variable.
     Paul just posted testcase on trunk. Patch for 4.9 and 5
available. Fix this weekend.
65542     [4.9/5/6 Regression] SPREAD intrinsic incorrectly accepted
in initialization expressions with -std=f95
     No activity
65996     [5/6 Regression] gfortran ICE with -dH     2015-12-04
    Fixed?
66089     [6 Regression] elemental dependency mishandling when derived
types are involved
    Mikael posted fix.
66244     [4.9/5/6 Regression] ICE on assigning a value to a pointer variable
     Initialization problem. A must fix?
66461     [4.9/5/6 Regression] ICE on missing end program in fixed source
     Steve posted a viable patch
66680     [5 Regression] ICE with openmp, a loop and a type bound
procedure     2015-12-27
    Appears to be fixed - testcase needed?
66695     [4.9/5/6 Regression] ICE with binding-name equal to the name
of a use-associated procedure
     No activity
67076     [5/6 Regression] Critical inside a module procedure
     No activity
67219     [6 Regression] Incorrect conversion warning
     Thomas made a start on diagnosing this one - do you want to take
it, Thomas?
67451     [5/6 Regression] ICE with sourced allocation from coarray.
     Co-lateral damage arising from one of Andre's patches?
67509     [6 regression] FAIL: gfortran.dg/ieee/ieee_7.f90 -O0 execution test
     FX posted patch, which was never committed.
68009     [6 Regression] prototype for gfortran_runtime_error with inline matmul
     Thomas, can you follow Jan's recomendation for fixing this?
68040     [5/6 Regression] Internal compiler error: Error reporting
routines re-entered.
     Manuel seems to have pinpointed how to fix. Any takers?
68283     [5/6 Regression] ice: gfc_variable_attr(): Bad array reference
     Dominique posted patch
68560     [6 Regression] The test gfortran.dg/shape_8.f90 now fails
when compiled with -flto
    Mikael was on the way to a patch....
68649     [6 Regression] note: code may be misoptimized unless
-fno-strict-aliasing is used
     No activity - similar to previous?
68717     [6 Regression] New (bogus?) warnings when compiling some
gfortran.dg tests with -flto after r231239
    ditto
68829     [4.9/5/6 Regression] Segfaults with -Ofast due to large array on stack
     Should be relatively easy to fix
68887     [6 regression] gfortran.dg/coarray/event_[12].f90
-fcoarray=lib -O2 -lcaf_single -latomic fails
     No activity
69011     [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE
     Andre seems to have fixed this. Why is it marked as WAIT?
69064     [5/6 Regression] ICE: in gfc_typenode_for_spec, at
fortran/trans-types.c:1062 when LEN is set to a variable with no
explicit type
     Pretty much diagnosed
69128     [4.9/5/6 Regression] OpenMP workshare problem with SUM()
     Jakub - can you see what is wrong here?
43 bugs found.

Re: Triage of fortran FE regressions

[Dominique d'Humières]

> Le 5 janv. 2016 à 14:23, Dominique d'Humières <dominiq@lps.ens.fr> a écrit :
> 
> I am planning to add at test to trunk and 5 branch unless someone objects.
> 
> Dominique
> 
>> Le 5 janv. 2016 à 14:09, Paul Richard Thomas <paul.richard.thomas@gmail.com> a écrit :
>> 
>> 66680     [5 Regression] ICE with openmp, a loop and a type bound
>> procedure     2015-12-27
>>    Appears to be fixed - testcase needed?
> 

Re: Triage of fortran FE regressions

[Andre Vehreschild]

Hi Paul,

> 67451     [5/6 Regression] ICE with sourced allocation from coarray.
>      Co-lateral damage arising from one of Andre's patches?

I took a look at the above one, but couldn't get a fix then. Will try
again soon.

> 69011     [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE
>      Andre seems to have fixed this. Why is it marked as WAIT?

Resolved -> Fixed now. I tend to wait a week between patching and
closing a pr, to prevent reopen cycles, when the patch was
accidently incomplete. In this case your report and my closing just
overlapped. :-)

- Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Re: Triage of fortran FE regressions

[Paul Richard Thomas]

Thanks Andre and Dominique.

57129 is indeed fixed. I will commit a testcase and close it on 6
branch, at least.
60795 is fixed in that catastrophe does not occur. However, the
deferred character length of dummies is not being returned to the
caller and full array references do not work correctly (element
references are OK though). Both these errors are encountered in
PR54070, so I think that I might fix this PR first.
61831 is fixed
65996 is not fixed. The compiler is still aborted with option -dH even
if no error occurred.
69011 has just been marked as fixed by Andre.

Cheers

Paul

On 5 January 2016 at 14:35, Andre Vehreschild <vehre@gmx.de> wrote:
> Hi Paul,
>
>> 67451     [5/6 Regression] ICE with sourced allocation from coarray.
>>      Co-lateral damage arising from one of Andre's patches?
>
> I took a look at the above one, but couldn't get a fix then. Will try
> again soon.
>
>> 69011     [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE
>>      Andre seems to have fixed this. Why is it marked as WAIT?
>
> Resolved -> Fixed now. I tend to wait a week between patching and
> closing a pr, to prevent reopen cycles, when the patch was
> accidently incomplete. In this case your report and my closing just
> overlapped. :-)
>
> - Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de



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

Albert Einstein

Re: Triage of fortran FE regressions

[Paul Richard Thomas]

Dear All,


> 60795 is fixed in that catastrophe does not occur. However, the
> deferred character length of dummies is not being returned to the
> caller and full array references do not work correctly (element
> references are OK though). Both these errors are encountered in
> PR54070, so I think that I might fix this PR first.

The test in comment #1 works correctly with trunk. The test in comment
#4 fails completely until I apply the draft patch for PR54070,
whereupon it works correctly albeit with the ALLOCATE not setting the
dtype correctly (it sets the dtype with the entry value dummy string
length and then sets the string length correctly.).

I will therefore work on completing the fix for PR54070.

Cheers

Paul

Re: Triage of fortran FE regressions

[Jerry DeLisle]

On 01/05/2016 10:27 AM, Paul Richard Thomas wrote:
> Dear All,
> 

I have taken a few regressions on bugzilla.  If you see any others you think I
can tackle, let me know.

Jerry

"In it to win it!"

Re: Triage of fortran FE regressions

[Mikael Morin]

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

Re: Triage of fortran FE regressions

[Paul Richard Thomas]

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