[Patch, Fortran] PR 40881: warn for obsolescent features

[Manfred Schwarb]

-------- Original-Nachricht --------
> Datum: Sun, 02 Aug 2009 06:30:02 -0700
> Von: Tim Prince <n8tm@aol.com>
> An: Manfred Schwarb <manfred99@gmx.ch>
> CC: Janus Weil <janus@gcc.gnu.org>, gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org
> Betreff: Re: [Patch, Fortran] PR 40881: warn for obsolescent features

> Manfred Schwarb wrote:
> 
> > The description in the manual of -std=legacy is:
> > The `legacy' value is equivalent (to `gnu') but without the warnings for
> obsolete extensions.
> > 
> > Note the word "extensions", i.e. support for some old (vendor/compiler)
> > extensions not supported by a particular standards version. That's how 
> > I read this, at least.
> > 
> > For me there is a huge difference beween "extension" and 
> > "language feature", and between "supported", "obsolescent" and
> "deleted".
> > 
> > As long as a feature is supported by a standard, you should not
> > get warnings with default compiler settings, at least for things which
> > are only a style matter and do not bear the danger of unintentional
> > coding errors.
> > 
> > In the "legacy" compartment some obscure features are included which
> > very few people want to use, e.g. real do loops or implicit
> > integer/logical conversion.
> > 
> 
> real do parameters were specified in f77.  You just made a distinction 
> between vendor-specific extensions and former standard syntax, and then 
>   appeared to have changed your mind.  


But real do loops are a deleted feature in fortran 95, isn't it?

I have no problems with warnings about features which are deleted in 
a later language revision.

My points are:
1) "obsolescent features" == "supported features"
2) please no warnings for code styles which are standards conforming in
   any existing fortran standard (at default compiler settings).

This is not about "non-standard"!
In theory it would be even possible that the standards committee
takes some features off the list obsolescent features (though not likely).
So as long as a feature is not deleted, it is _fully_ standards
conforming.


Of course, they were obsoleted on 
> account of their potential for unintentional errors.
> I find warnings about statement functions annoying.  Those could be 
> divided into legacy (usage not permitted by a standard, if the compiler 
> can diagnose it) and obsolescent. I doubt any compiler has tried to make 
> a distinction, except by treating the non-standard usage as an error.
> I don't know whether the non-standard usage influenced the committee in 
> designating statement functions for obsolescence. Since that was done, 
> some changes have been made in the support of external use of functions 
> in CONTAINS, so we have to learn whether PRIVATE applies if we want to 
> get the functionality of statement functions.

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser