This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Triage of fortran FE regressions
- From: Mikael Morin <mikael dot morin at sfr dot fr>
- To: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>, "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, FX Coudert <fxcoudert at gmail dot com>, Tobias Burnus <burnus at net-b dot de>, Steve Kargl <sgk at troutmask dot apl dot washington dot edu>, Janus Weil <janus at gcc dot gnu dot org>, Dominique Dhumieres <dominiq at lps dot ens dot fr>, Thomas Koenig <tkoenig at netcologne dot de>, Andre Vehreschild <vehre at gmx dot de>, Jakub Jelinek <jakub at redhat dot com>
- Date: Wed, 6 Jan 2016 19:47:34 +0100
- Subject: Re: Triage of fortran FE regressions
- Authentication-results: sourceware.org; auth=none
- Authentication-results: sfrmc.priv.atos.fr; dkim=none (no signature); dkim-adsp=none (no policy) header dot from=mikael dot morin at sfr dot fr
- References: <CAGkQGiJhQCMvhxicCmUeAy6Xa=jR3V_X-zJSa7W2iKvAJS=YbA at mail dot gmail dot com>
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