Recently, I've been testing gfortran builds of some molecular dynamics code; AMBER (http://amber.scripps.edu/) and found a strange quirk in the READ function when using namelists. I'm not sure if this is a bug; but the behaviour is inconsistent with other F90 compilers. The host system is i686 Fedora Core 5 running gcc-gfortran 4.1.1 ( gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)). From my testing, I've managaged to generate the following testcase: program main integer ihp(2,2) NAMELIST /test/ ihp open(UNIT=22, STATUS='scratch') write (22, '(a)') & "&test", & "ihp(1,1) = 2*1", & "ihp(1,2) = 2", & "/" rewind (22) READ (UNIT=22, NML=test) print *,ihp end program main With gfortran, the following error is returned on execution: $ gfortran ./test.f90 -o ./test ; ./test At line 16 of file ./test.f90 Fortran runtime error: Repeat count too large for namelist object ihp But, if the code is compiled with ifort 9.0.033: $ ifort ./test.f90 -o ./test ; ./test 1 1 2 0 The "expected" behaviour is seen.
Subject: Re: New: Namelist issues when reading in asterisk preceeded arrays With gfortran 4.3 I get: $ ./a.out 1 1 2 10922 The last element is odd because gfortran does not initialize variables. So evidently we have fixed this one already. I seem to recall some fixes that I did for namelist, I have not ported these to 4.1 I suspect. Regards, Jerry
Thank you Jerry for the testing. How does one ascertain if this bug warrants backporting to 4.1?
(In reply to comment #2) > Thank you Jerry for the testing. How does one ascertain if this bug warrants > backporting to 4.1? > If this is a regression with respect to a previous version of gfortran, then a backport is warranted. In this instances, I believe, that it isn't a regression and should not be backported because of the potential to cause collateral regressions. In fact, the 4.1 branch is currently FUBAR because a back port has caused a regression. You'ld better served by installing a newer gfortran from the wiki.
Subject: Re: Namelist issues when reading in asterisk preceeded arrays 4.2 is in pre-release stage now. It is usually not too difficult to build it yourself. You could consider downloading the source, build, and install. Otherwise, I have to track down the patch and see if I can backport it. Then there is no guarantee that your distribution will release 4.1 next rev before 4.2 is out..... I will see if I can locate the patch and see what this will take for me to do. It will be a few days, time is running thin with Christmas coming up and all. :) Cheers, Jerry
Ok, I'll grab the 4.2 pre-release and start playing with that. Once again, thanks for the help. Mark
> "&test", & > "ihp(1,1) = 2*1", & > "ihp(1,2) = 2", & > "/" > READ (UNIT=22, NML=test) I think the result is *not* well defined: ihp(1,1) = 2*1 does make sense - one cannot assign 2 values to ihp(1,1). I think what meant is: ihp(1:2,1) = 2*1 I think therefore the result is implementation dependent and the error "Fortran runtime error: Repeat count too large for namelist object ihp" is correct, though not necessarily the best choice. NAG f95 for instance writes: 1 * 2 * whereas ifort/g95/gfortran/sunf95: 1 1 2 * (* = uninitialized value; some compiler preinitialize them with zero.) > I have not ported these to 4.1 I suspect. Using "4.1.2 20061115 (prerelease) (SUSE Linux)" I get the same result as with gfortran 4.3, I think therefore that the patch has already been backported.
Subject: Re: Namelist issues when reading in asterisk preceeded arrays Thanks for checking the latest 4.1, I just updated my 4.1 branch last night and I had not had a chance to check it. Also, the namelist I/O predates the existence of array triplet notation. It is common to interpret ihp(1,1) = 2*1 to mean fill out the array from that starting element. You will see that if you compile the example with -pedantic that you will get: $./a.out At line 16 of file name.f90 Fortran runtime warning: Non-standard expanded namelist read. With -std=f95 we throw a runtime error. gfortran knows its not standard. ;) (I implemented that feature after much discussion on the list.)
Already fixed *** This bug has been marked as a duplicate of 24459 ***