This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [RFC] Question on gfortran extension
Steve Kargl wrote:
On Fri, Nov 17, 2006 at 10:21:16PM -0800, Jerry DeLisle wrote:
I am wondering if we should keep this extension at all and if so should we
at least warn as default and error on -pedantic and/or -std=fxx?
Also, if we do keep this extension, should we keep the assignment given in
the last data statement rather than the first?
IMH0, I think gfortran should issue an error. The extension should
be removed even if it breaks backwards compatibility. In fact, I'm
coming to the opinion that we (the gfortran developers) should
concentrate on implementing the standards (ie., f95 and f03).
Extensions should be added with caution. Cray pointers and OpenMP
are examples of how extension should be done. That is, a user
must given command line options to permit these features. My recent
unreviewed patch for -fboz-kind is another example where the user
must provide a command line option to disable the F95 interpretation
of a boz-literal constant.
I would agree with this.
There are, I think, a number of "extensions" that amount to -std=legacy
style support for "Your program has a bug, and the other compilers you
use don't complain about it, so you want this compiler not to complain
either, because you can't afford to fix the bug." I think that perhaps
some of these are defensible if the programmer's intent is still clear,
but in this case the programmer's intent is not clear, and so allowing
this essentially amounts to arbitrary behavior, which I don't think is a
good idea.
Yes, I've been in the painful situation of discovering that a large
collection of data was produced by a buggy program. It's tempting to
want to just bury one's head in the sand and leave the bug in place, but
I don't think gfortran should support this sort of "solution"!
- Brooks
P.S. Someone go review Steve's -fboz-kind patch, please! I looked over
it pretty thoroughly and it looks ok to me, but I can't approve it.