This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch, fortran, backport, 4.8] PR51825 - Fortran runtime error: Cannot match namelist object name


On Sat, 13 Apr 2013 10:29:26 +0200, Janus Weil <janus@gcc.gnu.org> wrote:

Hi Tilo,

I would like to backport the fix for PR51825 I posted here

http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00316.html

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).

Hi Janus,

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" ...


Regards,

	Tilo


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]