[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #33 from jvdelisle at gcc dot gnu dot org 2008-10-29 04:45 --- Subject: Bug 37707 Author: jvdelisle Date: Wed Oct 29 04:44:15 2008 New Revision: 141420 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141420 Log: 2008-10-28 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/37707 Backport from trunk. * io/list_read.c (read_character): Remove code to look ahead in namelist reads to descriminate non-delimited strings from namelist objects. * io/write.c (namelist_write): Delimit character strings with quote or apostrophe, defaulting to quote. Modified: branches/gcc-4_3-branch/libgfortran/ChangeLog branches/gcc-4_3-branch/libgfortran/io/list_read.c branches/gcc-4_3-branch/libgfortran/io/write.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #34 from jvdelisle at gcc dot gnu dot org 2008-10-29 04:47 --- Fixed on 4.3, closing -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #35 from jvdelisle at gcc dot gnu dot org 2008-10-29 04:48 --- Subject: Bug 37707 Author: jvdelisle Date: Wed Oct 29 04:47:20 2008 New Revision: 141421 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141421 Log: 2008-10-28 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/37707 * gfortran.dg/namelist_18.f90: Revise. * gfortran.dg/namelist_55.f90: New test. * gfortran.dg/namelist_56.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_55.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_56.f90 Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_18.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #32 from burnus at gcc dot gnu dot org 2008-10-23 06:18 --- (In reply to comment #31) Fixed on trunk, backport to 4.3? I think it is simple enough to be OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #28 from toon at moene dot indiv dot nluug dot nl 2008-10-22 08:28 --- Jerry, do you think your patch can be applied and this bug closed ? As I wrote, it fixed the original problem from which I constructed the two test cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #29 from jvdelisle at gcc dot gnu dot org 2008-10-23 02:32 --- Subject: Bug 37707 Author: jvdelisle Date: Thu Oct 23 02:31:00 2008 New Revision: 141317 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141317 Log: 2008-10-22 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/37707 * io/list_read.c (read_character): Remove code to look ahead in namelist reads to descriminate non-delimited strings from namelist objects. * io/write.c (namelist_write): Delimit character strings with quote or apostrophe, defaulting to quote. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c trunk/libgfortran/io/write.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #30 from jvdelisle at gcc dot gnu dot org 2008-10-23 02:43 --- Subject: Bug 37707 Author: jvdelisle Date: Thu Oct 23 02:42:36 2008 New Revision: 141318 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141318 Log: 2008-10-22 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/37707 * gfortran.dg/namelist_18.f90: Update test. * gfortran.dg/namelist_55.f90: New test. * gfortran.dg/namelist_56.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/namelist_55.f90 trunk/gcc/testsuite/gfortran.dg/namelist_56.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/namelist_18.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #31 from jvdelisle at gcc dot gnu dot org 2008-10-23 02:50 --- Fixed on trunk, backport to 4.3? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #22 from burnus at gcc dot gnu dot org 2008-10-19 09:44 --- (In reply to comment #19) Warning: CHARACTER expression at (1) is being truncated (222/200) Tobias, you are right - the string is too short - 250 characters should do, however, and I get the same error. How did you provoke the warning (I certainly do not get it by default) ... Well, actually I saw it when I compiled the program with NAG f95 (Initialisation expression for L truncated) which shows this message by default. gfortran shows it with -Wcharacter-truncation or with -Wall (which I used). [Contrary to NAG f95, gfortran shows the warning not only for initialization expressions.] (In reply to comment #21) Toon and Tobias: Please try this attached patch. Looks OK. The only thing I need to determine now is if there is a legacy behaviour we may want to deal with Sunf95 and ifort seem to read -- without quotes -- all alphanumerical characters plus e.g. ยง until the next space/comma (and they treat %'$ special- ignore, end of string/namelist or as error). With NAG f95, g95, openf95, pathf95 and pgf95 one gets always an error message without quotes. With gfortran-4.3 str=test / does not work but str=test,/ does. I think the patch by itself is OK but doing the same as ifort and sunf95 would be also OK. Interesting that this did not come up as issue before. Seemingly no one uses write(...,namelist) with characters (as almost all compiler get this wrong) and seemingly reading a list of characters is also not widely done. @@ -1453,7 +1453,7 @@ namelist_write (st_parameter_dt *dtp) break; default: - dtp-u.p.nml_delim = '\0'; + dtp-u.p.nml_delim = ''; wouldn't it be easier/faster to simply remove the whole switch and use simply dtp-u.p.nml_delim = ''; without special cases for the current delim status? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #23 from jvdelisle at gcc dot gnu dot org 2008-10-19 15:29 --- Subject: Bug 37707 Author: jvdelisle Date: Sun Oct 19 15:28:25 2008 New Revision: 141227 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141227 Log: 2008-10-19 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/37863 Backport from trunk. * io/write_float.def (WRITE_FLOAT): Round to 1.0 correctly. 2008-10-19 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/37707 Backport from trunk. * io/list_read.c (nml_get_obj_data): If the first namelist object rank is greater than zero, call nml_object_read with the first object rather than the sub-object. Modified: branches/gcc-4_3-branch/libgfortran/ChangeLog branches/gcc-4_3-branch/libgfortran/io/list_read.c branches/gcc-4_3-branch/libgfortran/io/write_float.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #24 from jvdelisle at gcc dot gnu dot org 2008-10-19 15:31 --- Subject: Bug 37707 Author: jvdelisle Date: Sun Oct 19 15:30:32 2008 New Revision: 141228 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141228 Log: 2008-10-19 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/37707 * gfortran.dg/namelist_54.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_54.f90 Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #25 from jvdelisle at gcc dot gnu dot org 2008-10-19 15:39 --- (In reply to comment #22) default: - dtp-u.p.nml_delim = '\0'; + dtp-u.p.nml_delim = ''; wouldn't it be easier/faster to simply remove the whole switch and use simply dtp-u.p.nml_delim = ''; without special cases for the current delim status? Yes that would work, but I would like to allow users to use apostrophe if they wish. How about this? dtp-u.p.nml_delim = tmp_delim == DELIM_APOSTROPHE ? '\'' : ''; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #26 from toon at moene dot indiv dot nluug dot nl 2008-10-19 16:11 --- The patch works for my case, Please be careful with the namelist_18,f90 test case - I can't off-hand say whether it's right or (an extension). Cheers, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #27 from jvdelisle at gcc dot gnu dot org 2008-10-19 18:16 --- The namelist_18.f90 test change is because we are now defaulting to a quote delimiter. We do not write a namelist without character string delimiters. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #13 from toon at moene dot indiv dot nluug dot nl 2008-10-18 08:43 --- Unfortunately, while the original test case has been solved, the original problem that led me to file this bug report hasn't been ... Here's a failing example closer to the original source: TYPE geometry INTEGER :: nlon,nlat,nlev,projection INTEGER :: center,subcenter,process REAL:: west,south,east,north REAL:: dlon,dlat REAL:: polat,polon REAL:: lonc,latc REAL:: projlat,projlat2,projlon CHARACTER(LEN=1) :: arakawa ='#' INTEGER :: truncx,truncy ! Spectral truncation INTEGER :: cie ! Flag fort CI (0), CIE gridpoint (1) ! or CIE spectral (-1) INTEGER :: nlat_i,nlon_i ! I length in Y and X direction INTEGER :: nlat_e ,nlon_e ! E length in Y and X direction LOGICAL :: do_geo = .true. END TYPE geometry TYPE shortkey INTEGER :: PPP ! 2. Parameter INTEGER :: NNN ! 12. Gridpoint or spectral field 0 = gridpoint, 1 = spectral INTEGER :: INTPM CHARACTER(LEN=16) :: name END TYPE shortkey INTEGER, PARAMETER :: maxl = 200 ! Maximum number of levels to be read from namelist INTEGER, PARAMETER :: max_atmkey = 10 ! Maximum number of extra fields in the REAL:: ahalf(maxl),bhalf(maxl) TYPE (geometry) :: outgeo ; SAVE outgeo ! Output geometry TYPE (shortkey) :: atmkey(max_atmkey) ; SAVE atmkey TYPE (shortkey) :: mlevkey(max_atmkey) ; SAVE mlevkey character*200 :: l = NAMINTERP atmkey%ppp = 076,058,062,079, atmkey%nnn = 000,000,000,000, atmkey%name ='LIQUID_WATER','SOLID_WATER','SNOW','RAIN', OUTGEO%NLEV=10, AHALF=0.,1.,2.,3.,4.,5.,6.,7.,8.,9., BHALF=0.,1.,2.,3.,4.,5.,6.,7.,8.,9., / namelist /naminterp/outgeo,ahalf,bhalf,atmkey read(l,naminterp) write(6,naminterp) end It yields: At line 40 of file nl4.f90 Fortran runtime error: Cannot match namelist object name 5.6.7.8.9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #14 from toon at moene dot indiv dot nluug dot nl 2008-10-18 08:46 --- Created an attachment (id=16514) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16514action=view) New Failing Example. This a more complicated example that still fails after Jerry's fix for the first example. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #15 from toon at moene dot indiv dot nluug dot nl 2008-10-18 08:47 --- Sorry, source code of new example got mangled; I created an attachment (nl4.f90) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #16 from burnus at gcc dot gnu dot org 2008-10-18 14:33 --- character*200 :: l = NAMINTERP atmkey%ppp = 076,058,062,079, atmkey%nnn = 0 1 Warning: CHARACTER expression at (1) is being truncated (222/200) This namelist poses really a challenge: - NAG f95 gets stuck in an endless loop - g95, gfortran, sunf95, openf95 show run-time error messages - ifort can handle the namelist (but does not support internal I/O) If one adds a / ! after OUTGEO%NLEV=10, gfortran does no longer give a run-time error but if one writes the read namelist, one finds OUTGEO%NLEV=0, whereas ifort has the expected OUTGEO%NLEV=10, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #17 from burnus at gcc dot gnu dot org 2008-10-18 14:53 --- The problem seems to be that atmkey%name = list of quoted strings reads also OUTGEO%NLEV=10 as string. Can you try: open(file where the namelist is, delim='quote') in the real program? That unfortunately does not work for internal I/O as delim= is not allowed in READ statements. Are you sure that that program is valid? If yes, how should the libgfortran know how far it should read? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #18 from burnus at gcc dot gnu dot org 2008-10-18 15:12 --- I think your program is valid. For tag = list of strings in a namelist the quotes are required and delim= is ignored for namelist read/write. See: 10.10.1.3 Namelist group object list items [...] When the next effective item is of type character, the input form consists of a delimited sequence of zero or more rep-char s whose kind type parameter is implied by the kind of the corresponding list item. Such a sequence may be continued from the end of one record to the beginning of the next record, but the end of record shall not occur between a 1 doubled apostrophe in an apostrophe-delimited sequence, nor between a doubled quote in a quote-delimited sequence. The end of the record does not cause a blank or any other character to become part of the sequence. The sequence may be continued on as many records as needed. The characters blank, comma, and slash may appear in such character sequences. NOTE 10.35 A character sequence corresponding to a namelist input item of character type shall be delimited either with apostrophes or with quotes. The delimiter is required to avoid ambiguity between undelimited character sequences and object names. The value of the DELIM= specifier, if any, in the OPEN statement for an external file is ignored during namelist input (9.4.5.6). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #19 from toon at moene dot indiv dot nluug dot nl 2008-10-18 15:33 --- character*200 :: l = NAMINTERP atmkey%ppp = 076,058,062,079, atmkey%nnn = 0 1 Warning: CHARACTER expression at (1) is being truncated (222/200) Tobias, you are right - the string is too short - 250 characters should do, however, and I get the same error. How did you provoke the warning (I certainly do not get it by default) ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2008-10-18 17:46 --- There are a few problems going on here. When writing a namelist with no delim= specified, we should default to a quote. That is trivial. Then, we also need to enable finding a namelist object name vs a character object. The mechanism for that is already in the library code. I think I just need to adjust the condition that invoke it. I will work up the patch. Thanks Tobias for your diagnosis. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2008-10-18 21:48 --- Created an attachment (id=16515) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16515action=view) Proposed patch for this second test case. Toon and Tobias: Please try this attached patch. This fixes actually two different problems not related to the first test case. The standard is clear. We were trying to interpret unquoted strings in namelists by looking ahead to see if there was an '=' to tell us it was a namelist object name and not a character object value. Unquoted character object values are not allowed in namelists. The patch requires modifying namelist_18.f90. The only thing I need to determine now is if there is a legacy behaviour we may want to deal with and of course does this patch fix Toon's problem in the actual application? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2008-10-18 05:25 --- Subject: Bug 37707 Author: jvdelisle Date: Sat Oct 18 05:23:47 2008 New Revision: 141207 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141207 Log: 2008-10-17 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/37707 * io/write_float.def (WRITE_FLOAT): Round to 1.0 correctly. * io/io.h (st_parameter_44): Fix id type declaration. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/io.h trunk/libgfortran/io/write_float.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2008-10-18 05:36 --- Ignore comment #11. I got wrong PR number in Changelog. Should have been 37863. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #7 from dominiq at lps dot ens dot fr 2008-10-09 09:27 --- (In reply to comment #6) On i686-apple-darwin9 I get: [ibook-dhum] f90/bug% gfc pr37707.f90 [ibook-dhum] f90/bug% a.out 87 88 89 97 98 99 NAMLIS A(1)%M= 1, A(1)%N= 5, A(2)%M= 2, A(2)%N= 6, A(3)%M= 89, A(3)%N= 99, / -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #8 from burnus at gcc dot gnu dot org 2008-10-09 13:31 --- (In reply to comment #6) Tobias, should A(3)%M not be 89?? Yes. I realized too late that I pasted the output of a slightly different program, which I used during testing. In any case today's build gives the same output as NAG f95 (excepts that NAG writes the namelist as NAMLIS A = 1 5 2 6 89 99/) and the same output as ifort. [Sidenote: NAG's format works also with gfortran since at least 4.2.] Jerry, I think that your namelist_54.f90 should test the values of A(3) as well as A(1) and A(2) I agree with Paul that A(3)%m and A(3)%n should also be tested. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #6 from pault at gcc dot gnu dot org 2008-10-09 09:15 --- (In reply to comment #1) NAMLIS A(1)%M = 1, A(1)%N = 5, A(2)%M = 2, A(2)%N = 6, A(3)%M = 5, A(3)%N = 99 / Tobias, should A(3)%M not be 89?? Jerry, I think that your namelist_54.f90 should test the values of A(3) as well as A(1) and A(2) Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-10-10 02:11 --- Subject: Bug 37707 Author: jvdelisle Date: Fri Oct 10 02:10:14 2008 New Revision: 141016 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141016 Log: 2008-10-08 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/37707 * gfortran.dg/namelist_54.f90: Revise test, check a(3). Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/namelist_54.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-10-10 02:14 --- This is fixed on trunk. I think I will back port this to 4.3 since the bug does result in failing in valid namelists. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-10-09 02:40 --- The following simple patch fixes this. I will commit under the obvious and simple rule. (Obvious once you spend several hours studying it to see what is going wrong!) Index: io/list_read.c === --- io/list_read.c (revision 140900) +++ io/list_read.c (working copy) @@ -2839,6 +2839,9 @@ get_name: goto nml_err_ret; } + if (first_nl != NULL first_nl-var_rank 0) +nl = first_nl; + if (nml_read_obj (dtp, nl, 0, pprev_nl, nml_err_msg, nml_err_msg_size, clow, chigh) == FAILURE) goto nml_err_ret; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-10-09 04:16 --- Subject: Bug 37707 Author: jvdelisle Date: Thu Oct 9 04:14:48 2008 New Revision: 140997 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140997 Log: 2008-10-08 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/37707 * gfortran.dg/namelist_54.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/namelist_54.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-10-09 04:04 --- Subject: Bug 37707 Author: jvdelisle Date: Thu Oct 9 04:02:35 2008 New Revision: 140995 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140995 Log: 2008-10-08 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/37707 * io/list_read.c (nml_get_obj_data): If the first namelist object rank is greater than zero, call nml_object_read with the first object rather than the sub-object. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #1 from burnus at gcc dot gnu dot org 2008-10-01 21:42 --- Jerry, that sounds like something for you. I think Toon is right and ifort 10.1 prints (using a file as internal I/O does not work): 87 88 89 97 98 99 NAMLIS A(1)%M = 1, A(1)%N = 5, A(2)%M = 2, A(2)%N = 6, A(3)%M = 5, A(3)%N = 99 / -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-10-02 01:46 --- I am investigating. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-10-02 01:46:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
