This is the mail archive of the
mailing list for the GCC project.
Re: [patch, fortran, backport, 4.8] PR51825 - Fortran runtime error: Cannot match namelist object name
- From: "Tilo Schwarz" <tilo at tilo-schwarz dot de>
- To: "Janus Weil" <janus at gcc dot gnu dot org>
- Cc: gfortran <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 20 Apr 2013 14:44:39 +0200
- Subject: Re: [patch, fortran, backport, 4.8] PR51825 - Fortran runtime error: Cannot match namelist object name
- References: <op dot wvd7zu0ma8ed4e at dellschleppa dot fritz dot box> <CAKwh3qhTVPoZJGW-O2XLGYro+0UhfRemU=B3fL6ZqPv2RXu9jw at mail dot gmail dot com>
On Sat, 13 Apr 2013 10:29:26 +0200, Janus Weil <firstname.lastname@example.org> wrote:
I would like to backport the fix for PR51825 I posted here
to the 4.8 branch.
well, the usual gfortran policy is to only do backports of regression
fixes. In exceptional cases, also non-regression fixes can be
backported (and have been in the past), if the bug is extremely severe
and/or the the fix is extremely simple (IMHO the most severe type of
bug is a wrong-code issue, where the user does not see any kind of
error message, but just 'silently' gets wrong results).
the bug is indeed pretty nasty. What happens is, that any namelist line
involving an array index and nested derived types like this
arr(2)%a%b = 1
completely ignores the given array index and silently reads it as 1.
So no matter what you write as index > 1 in a line like
arr(<index>)%a%b = 1
libgfortran always silently reads the index == 1 as
arr(1)%a%b = 1
and sets the first element of arr instead of setting arr(index).
When I hit this (as a gfortran user) it took me quite a while to figure
out whats going on. What makes it even more nasty: This
arr(2)%b = 1
did work (only one level of derived type given).
I'm personally not too affected anymore, because this bug made me writing
my first libgfortran patch ever and since then I use gfortran trunk anyway
But for others the bug is "sort of mean" ...