Report : ======== Using built-in specs. Target: powerpc-apple-darwin9.8.0 Configured with: ./configure Thread model: posix gcc version 4.4.3 (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.5.8' '-v' '-save-temps' '-c' /usr/local/libexec/gcc/powerpc-apple-darwin9.8.0/4.4.3/f951 prog.f90 -fPIC -quiet -dumpbase prog.f90 -mmacosx-version-min=10.5.8 -auxbase prog -version -fintrinsic-modules-path /usr/local/lib/gcc/powerpc-apple-darwin9.8.0/4.4.3/finclude -o prog.s GNU Fortran (GCC) version 4.4.3 (powerpc-apple-darwin9.8.0) compiled by GNU C version 4.4.3, GMP version 5.0.1, MPFR version 2.4.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 prog.f90:3.17: NAMELIST/TOTO/TAB 1 Error: NAMELIST attribute conflicts with ALLOCATABLE attribute in 'tab' at (1) ======== Test file : ======== PROGRAM MAIN REAL, DIMENSION(:), ALLOCATABLE :: TAB NAMELIST/TOTO/TAB END PROGRAM MAIN ======== It should work with F2003 new features.
Yes indeed! Section 5.4 of F2003 removes most of the restrictions for namelist-group-objects. Ifort 11.1 does the right thing with your testcase. Thanks for the report. Paul
> NAMELIST/TOTO/TAB > 1 > Error: NAMELIST attribute conflicts with ALLOCATABLE attribute in 'tab' at (1) > ======== > > Test file : > ======== > PROGRAM MAIN > REAL, DIMENSION(:), ALLOCATABLE :: TAB > NAMELIST/TOTO/TAB > END PROGRAM MAIN > ======== > > It should work with F2003 new features. Interesting. I can't find a passage in the F2003 standard that specifically allows this form. I do find a passage that indicates that it is not allowed. In section 5.4: A namelist group object shall either be accessed by use or host association or shall have its type, type parameters, and shape specified by previous specification statements ... In your code, the shape of the array has not been specified by a previous specification statement. OTOH, I do find in 9.5.3.6, Every allocatable namelist-group-object in the namelist group shall be allocated and every namelist-group-object that is a pointer shall be associated with a target. which suggests that the form is legal.
I've posted a question to c.l.f about this code. I believe the language of the standard is contradictory and as such the code can be interpreted as illegal or legal. http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/76b23c9927b52161#
(In reply to comment #3) > I've posted a question to c.l.f about this code. I > believe the language of the standard is contradictory > and as such the code can be interpreted as illegal or > legal. > > http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/76b23c9927b52161# > Into the final committee draft J3/03-007R2, section 5.4, I found : C574 (R553) A namelist-group-object shall not be an assumed-size array. It was not the case in F95.
(In reply to comment #4) > (In reply to comment #3) > > I've posted a question to c.l.f about this code. I > > believe the language of the standard is contradictory > > and as such the code can be interpreted as illegal or > > legal. > > > > http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/76b23c9927b52161# > > > > Into the final committee draft J3/03-007R2, section 5.4, I found : > > C574 (R553) A namelist-group-object shall not be an assumed-size array. > > It was not the case in F95. > Your code doesn't contain an assumed-sized array. -- steve
What is this? REAL, DIMENSION(:), ALLOCATABLE :: TAB If not assumed size? Also, assuming it is something else, would it be invalid to use the namelist anywhere if TAB has not been allocated before it is used?
(In reply to comment #6) > What is this? > > REAL, DIMENSION(:), ALLOCATABLE :: TAB > > If not assumed size? > > Also, assuming it is something else, would it be invalid to use the namelist > anywhere if TAB has not been allocated before it is used? > It's a deferred-shape array. 5.1.2.5.3 Deferred-shape array A deferred-shape array is an allocatable array or an array pointer. 5.1.2.5.4 Assumed-size array An assumed-size array is a dummy argument array whose size is assumed from that of an associated actual argument.
(In reply to comment #6) > > Also, assuming it is something else, would it be invalid to use the namelist > anywhere if TAB has not been allocated before it is used? > I forgot to reply to this part. See comment #2 where I quote 9.5.3.6 form F2003.
After reading the thread on clf, its still not very clear. The wording is less then perfect, but thinking out of the box I suppose it would be reasonable to allow it in the namelist as long as the array gets allocated before it is actually used for example, in a namelist READ or WRITE. It should be on the programmer to do that correctly though.
(NAG f95 v5.1 and g95 reject it unconditionally; ifort allows it by default but rejects it with -stand f95 or -stand f03.) I think one should really send a interpretation request. A patch would be the following. What about POINTERs? Index: symbol.c =================================================================== --- symbol.c (Revision 156815) +++ symbol.c @@ -389,2 +389,10 @@ check_conflict (symbol_attribute *attr, + if (attr->in_namelist && attr->allocatable) + { + a1 = in_namelist; + a2 = allocatable; + standard = GFC_STD_F2003; + goto conflict_std; + } + /* Check for attributes not allowed in a BLOCK DATA. */ @@ -493,3 +501,2 @@ check_conflict (symbol_attribute *attr, conf (in_namelist, pointer); - conf (in_namelist, allocatable);
Replying to myself (comment #10): > I think one should really send a interpretation request. I have now created one and sent it to Van. > What about POINTERs? Pointers seem to be treated similarly to allocatables. (I should have read the standard first). > A patch would be the following. It of cause fails (ICE) for WRITE(*,nml=...) as the front end creates: _gfortran_st_set_nml_var_dim (&dt_parm.1, 0, ); ^^^
(In reply to comment #10) > (NAG f95 v5.1 and g95 reject it unconditionally; ifort allows it by default but > rejects it with -stand f95 or -stand f03.) > > I think one should really send a interpretation request. I already contacted Dan Nagle. I'll write up the issue today and send it to whom. > > A patch would be the following. What about POINTERs? > See comment #2. > Index: symbol.c > =================================================================== > --- symbol.c (Revision 156815) > +++ symbol.c > @@ -389,2 +389,10 @@ check_conflict (symbol_attribute *attr, > > + if (attr->in_namelist && attr->allocatable) > + { > + a1 = in_namelist; > + a2 = allocatable; > + standard = GFC_STD_F2003; > + goto conflict_std; > + } > + > /* Check for attributes not allowed in a BLOCK DATA. */ > @@ -493,3 +501,2 @@ check_conflict (symbol_attribute *attr, > conf (in_namelist, pointer); > - conf (in_namelist, allocatable); > This isn't sufficient. See comment #2. During a namelist read/write, gfortran needs to check that the allocatable array is allocated and that a pointer is associated with a target.
(In reply to comment #11) > Replying to myself (comment #10): > > I think one should really send a interpretation request. > > I have now created one and sent it to Van. > Did you include the language from F2008 that make this clearly nonconforming code? > > What about POINTERs? > Pointers seem to be treated similarly to allocatables. (I should have read the > standard first). Or comment #2. > > > A patch would be the following. > > It of cause fails (ICE) for WRITE(*,nml=...) as the front end creates: > _gfortran_st_set_nml_var_dim (&dt_parm.1, 0, ); > ^^^ > I've removed the reject-valid keyword, because until an official intrep is given there is conflicting language in the standard.
Created attachment 19899 [details] Draft patch - misses modifications to nml_get_addr_expr The current standard is weird: allocatables/pointers/automatic/non-const-shape dummy arrays are valid - but only via host/use association. Thus, I postpone this until there is an official reply from J3/WG5. I attach a draft patch in order to make sure it won't get lost. The patch goes past the compile-time check and also past the ICE; however, it does not work as nml_get_addr_expr needs to be modified. One needs to pass the address of the array data, i.e. &(array_descriptor.data) rather than &array_descriptor - which should be done in nml_get_addr_expr. Note: nml_get_addr_expr's "array_flagged" remains zero for array descriptors. trans-array.c's gfc_conv_array_data might be a function, which one could use.
See also: http://j3-fortran.org/pipermail/j3/2010-February/003401.html where Van and Malcolm agreed that changes should be done.
Interpretation request for the June J3 meeting: http://j3-fortran.org/doc/meeting/192/10-146.txt Proposed edit is to allow ALLOCATABLEs.
Any further direction on this?
(In reply to comment #16) > Interpretation request for the June J3 meeting: > http://j3-fortran.org/doc/meeting/192/10-146.txt > Proposed edit is to allow ALLOCATABLEs. (In reply to comment #17) > Any further direction on this? Updated IR: http://j3-fortran.org/doc/meeting/192/10-146r1.txt Status at the meeting: http://j3-fortran.org/doc/meeting/193/10-198.txt > 0. List of papers passed at meeting #192 > > The interpretations passed by this meeting were: > [...] F08/0002 == 10-146r1 [...]
Related: PR 47339
Hi, so, I am bit lost, "bug" is resolved or not ? Correction available with next version of gcc ? Thanks, Xavier
It is not resolved because we are waiting for an interpretation from the Fortran standards committee on whether the test case is valid or invalid Fortran. If invalid, then we need to give an error, if valid, we need to make sure it works correctly. Unfortunately, this PR is in a waiting state.
(In reply to comment #20) > so, I am bit lost, "bug" is resolved or not ? > Correction available with next version of gcc ? No the bug (or problem report, PR) is not yet resolved. But PR 47339 contains an almost ready patch, which fixes this issue (and some more namelist-related issues). The patch will likely be submitted soon.
(In reply to comment #21) > It is not resolved because we are waiting for an interpretation from the > Fortran standards committee on whether the test case is valid or invalid > Fortran. Cf. comment 17: The J3 agreed that it is a bug in the standard and agreed on the proposed change, which solves the ambiguity in the standard and allows such namelists. The next step is to get passed a WG5 ballot. Finally, the change will be released as Corrigendum 1 to Fortran 2008. While it could be still rejected, the changes for a rejection are quite low. Thus, I went ahead and implemented it. (cf. attachment 23080 [details] of PR 47339). Xavier: You do not have to wait for a new release, you could fetch the patch and build GCC/gfortran your self. Alternatively, when the patch is committed, you can get nightly builds. Both is described at http://gcc.gnu.org/wiki/GFortranBinaries
Author: burnus Date: Wed Jan 26 10:12:47 2011 New Revision: 169282 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169282 Log: 2011-01-26 Tobias Burnus <burnus@net-b.de> PR fortran/47339 PR fortran/43062 * match.c (gfc_match_namelist): Allow assumed-length characters. * resolve.c (resolve_fl_namelist): Adapt and add error messages. * symbol.c (check_conflict): Allow allocatables in NML for * F2003. * trans-io.c (nml_get_addr_expr,transfer_namelist_element): Changes due to that change. 2011-01-26 Tobias Burnus <burnus@net-b.de> PR fortran/47339 PR fortran/43062 * fortran.dg/namelist_69.f90: New test. * fortran.dg/namelist_70.f90: New test. * fortran.dg/namelist_assumed_char.f90: Modify dg-error, augment * test. * fortran.dg/namelist_3.f90: Adapt test. * fortran.dg/namelist_34.f90: Ditto. * fortran.dg/namelist_35.f90: Ditto. * fortran.dg/namelist_5.f90: Ditto. * fortran.dg/namelist_63.f90: Ditto. * gfortran.dg/alloc_comp_constraint_1.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/namelist_69.f90 trunk/gcc/testsuite/gfortran.dg/namelist_70.f90 Modified: trunk/gcc/fortran/match.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/gfortran.dg/alloc_comp_constraint_1.f90 trunk/gcc/testsuite/gfortran.dg/namelist_3.f90 trunk/gcc/testsuite/gfortran.dg/namelist_34.f90 trunk/gcc/testsuite/gfortran.dg/namelist_35.f90 trunk/gcc/testsuite/gfortran.dg/namelist_5.f90 trunk/gcc/testsuite/gfortran.dg/namelist_63.f90 trunk/gcc/testsuite/gfortran.dg/namelist_assumed_char.f90
FIXED on the trunk (4.6). Thanks for the report Xavier!
Thanks for your work. Question : I tried to build my own version, but i did not succeed. (1) gcc-4.5.2 : ok (2) gcc-4.5.2 + modified/added files from trunk (4.6) : compilation error on file match.c (3) gcc-4.6 (from trunk) : some errors... (I don't remerber) Is it normal that test (2) did not work ? Do i need to modify directly files related to this bug report ?
(In reply to comment #26) > Question : I tried to build my own version, but i did not succeed. > (1) gcc-4.5.2 : ok > (2) gcc-4.5.2 + modified/added files from trunk (4.6) : compilation error on > file match.c > Is it normal that test (2) did not work ? Well, it is not surprising that just applying 4.6 patches do not work on 4.5. After all, one year of development is a lot. During that year the following, user-visible changes were done for Fortran: http://gcc.gnu.org/gcc-4.6/changes.html#fortran Thus, the chance that a patch applies without any changes to an older version is relatively low. > Do i need to modify directly files related to this bug report ? Well, if applying the patch does not work and if you want to use 4.5, you seemingly have to. I assume that the changes to match.c are not difficult, but I have not tried it - and I do not plan to do so. > (3) gcc-4.6 (from trunk) : some errors... (I don't remerber) Without error message, it is difficult to help (and this bug report is the wrong forum*). However, you could also try to use the nightly builds, which are available at http://gcc.gnu.org/wiki/GFortranBinaries * Mailing list, cf. http://gcc.gnu.org/lists.html try gcc-help@ or fortran@ but first glance at the instructions at http://gcc.gnu.org/install/
I tried again to build gcc 4.6 (from svn) and i succeeded. The patch works fine. Thanks.
Author: dnovillo Date: Wed Feb 2 17:52:14 2011 New Revision: 169614 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169614 Log: 2011-01-26 Tobias Burnus <burnus@net-b.de> PR fortran/47339 PR fortran/43062 * match.c (gfc_match_namelist): Allow assumed-length characters. * resolve.c (resolve_fl_namelist): Adapt and add error messages. * symbol.c (check_conflict): Allow allocatables in NML for * F2003. * trans-io.c (nml_get_addr_expr,transfer_namelist_element): Changes due to that change. 2011-01-26 Tobias Burnus <burnus@net-b.de> PR fortran/47339 PR fortran/43062 * fortran.dg/namelist_69.f90: New test. * fortran.dg/namelist_70.f90: New test. * fortran.dg/namelist_assumed_char.f90: Modify dg-error, augment * test. * fortran.dg/namelist_3.f90: Adapt test. * fortran.dg/namelist_34.f90: Ditto. * fortran.dg/namelist_35.f90: Ditto. * fortran.dg/namelist_5.f90: Ditto. * fortran.dg/namelist_63.f90: Ditto. * gfortran.dg/alloc_comp_constraint_1.f90: Ditto. Added: branches/google/integration/gcc/testsuite/gfortran.dg/namelist_69.f90 branches/google/integration/gcc/testsuite/gfortran.dg/namelist_70.f90 Modified: branches/google/integration/gcc/fortran/match.c branches/google/integration/gcc/fortran/resolve.c branches/google/integration/gcc/fortran/symbol.c branches/google/integration/gcc/fortran/trans-io.c branches/google/integration/gcc/testsuite/gfortran.dg/alloc_comp_constraint_1.f90 branches/google/integration/gcc/testsuite/gfortran.dg/namelist_3.f90 branches/google/integration/gcc/testsuite/gfortran.dg/namelist_34.f90 branches/google/integration/gcc/testsuite/gfortran.dg/namelist_35.f90 branches/google/integration/gcc/testsuite/gfortran.dg/namelist_5.f90 branches/google/integration/gcc/testsuite/gfortran.dg/namelist_63.f90 branches/google/integration/gcc/testsuite/gfortran.dg/namelist_assumed_char.f90