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] PR30481 Accepts namelist-group object with assumed character length


Tobias Burnus wrote:
Brooks Moses wrote:
I seem to recall a discussion of this on comp.lang.fortran recently,
where it was mentioned that this restriction was a F95 thing that was
relaxed in F2003.  Unfortunately, I can't seem to find the comment
again, but it looks to me like the language in the standard does relax
the restriction.

The thread which lead to the bug report is at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/75b797b2d4257f74 but there I cannot find anything about a relaxation in Fortran 2003.

Thanks very much for tracking that down!


And Fortran 2003:

"5.4 NAMELIST statement"
"C574 (R553) A namelist-group-object shall not be an assumed-size array."
"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 or the procedure heading in the same scoping unit or
by the implicit typing rules in effect for the scoping unit. If a namelist
group object is typed by the implicit typing rules, its appearance in any
subsequent type declaration statement shall confirm the implied type and type
parameters."

I have actually some problems in fully understanding the Fortran 2003 text.

How I'd look at it is to eliminate all the parts that are irrelevant to this case, and it actually does help sometimes to actually write it out -- think of it as manually evaluating the parts of the "and" and "or" clauses that can be constant-folded. :)


This isn't accessed by use or host association, so that's out. The type and shape are irrelevant to this, so we can ignore those, leaving only type parameters (of which character length is one). Implicit typing rules don't affect type parameters, so that clause and the last sentence are irrelevant. That leaves:

"A namelist group object shall ... or have its ... type parameters ... specified by previous specification statements or the procedure heading in the same scoping unit...."

That leaves us with the question of whether the "LEN=*" in the specification statement counts as specifying the type parameter or not.

And, in this case, I am personally not at all sure, so that leaves me no better off than before I started writing all this analysis.

Note that Richard Main wrote in that thread:
"I'll also note that I don't see any big reason why the standard
couldn't be extended to allow this in the future. When Namelist was
added to the standard (in f90), it was done in a pretty conservative and
minimalist fashion in several regards. In my personal judgement, this
particular restriction was probably overkill in that I wouldn't expect
it to be hard to implement in
most compilers."

Given that he knows the standard pretty well, it indicates that it might
indeed be still not allowed in F2003.

Indeed -- that's how I read it, and I'll defer to his judgement. This is certainly the bit of discussion that I was remembering earlier, but apparently I misremembered the conclusion that he drew.


If that's true, I'd suggest that this should be a -std=f95 thing, not
an absolute error.

If it is true, then yes. Otherwise: Explicit error or legacy?

Not legacy; we have no indication that any legacy codes use this feature, so far as I know.


If I believed in using GNU extensions to do useful things, such that we were continuing the G77 tradition of defining a "GNU Fortran" language that was "better" than the standardized form, I'd consider this a strong candidate for such an extension. However, we seem to be leaning much more towards encouraging the use of portable code and not adding new extensions, so it probably shouldn't be a GNU extension either.

Thus, an absolute error it is, I'd say.

Again, thank you muchly for the detailed answer to my rather vague comment!

- Brooks


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