This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [RFC] Question on gfortran extension
- From: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- To: Jerry DeLisle <jvdelisle at verizon dot net>
- Cc: Fortran List <fortran at gcc dot gnu dot org>
- Date: Fri, 17 Nov 2006 22:56:06 -0800
- Subject: Re: [RFC] Question on gfortran extension
- References: <455EA65C.1020505@verizon.net>
On Fri, Nov 17, 2006 at 10:21:16PM -0800, Jerry DeLisle wrote:
> Hi all,
>
> In working on PR24978 I am looking at several test cases. Currently the
> following test case is accepted by gfortran as an extension:
>
> integer :: a
> data a /5/
> data a /8/
> print '(3i6)', a
> end
>
> The result is that the variable 'a' is assigned the value 5 because that
> data statement is the last to be resolved even though intuitively one might
> think the last data statement ought to take effect. (Resolution occurs in
> reverse statement order)
>
> This extension really goes against the F95 Standard which does not allow
> duplicate initialization. It is my opinion that this is a dangerous
> extension. As implemented now, it only warns if one specifies -pedantic
> and errors if given -std=f95 or -std=f2003. This can leave users open to
> inadvertent duplicate initialization if they do not use the options.
>
> 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.
--
Steve