[RFC] Question on gfortran extension

[Steve Kargl]

On Mon, Nov 20, 2006 at 09:33:57AM -0800, Mike Kumbera wrote:
> 
> On Fri, Nov 17, 2006 at 10:21:16PM -0800, Jerry DeLisle wrote:
> > 
> > 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?
> > 
> 
> I think this extension was added by Asher for llnl. The examples
> that failed all had the form:
> 
> integer :: a
> data a /5/
> data a /5/
> print '(3i6)', a
> end
> 
> In these cases we didn't care if the first or last data statment was used.
> 
> gfortran was the first fortran compiler to catch this bug. The compiler 
> generated an ICE on this. I don't care if a warning is issued as the 
> default action. It also doesn't matter if the first or last data statement 
> is used since the code is not officially allowed. 
> 
> Since the all the commercial compilers (intel, pgi, pathscale and xlf)
> take the code, I think we should keep the extension but issue a stern 
> warning. :-) The first step to removing this nonstandard code from all 
> our applications is for us to know it's in there. 

Mike raises a few valid concerns with making this an unforgiving error.
So, against my better judgement, Jerry can you make this a warning in 
normal compilitation and an error with -std=f95.  Which statement takes
precedence can be left in its current order because the behavior is 
outside of the Standard and so it is processor dependent.

 
-- 
Steve