This is the mail archive of the 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: [gfortran] Add new -std=legacy command line option

--- Janne Blomqvist <> 写道:
> On Sat, May 28, 2005 at 01:59:22PM -0600, Roger Sayle wrote:
> > 
> > The following patch refines the semantics of gfortran's extensions
> > into two categories; GFC_STD_GNU for useful functionality not defined
> > in any official fortran standard (i.e. stuff we're proud of) and
> > GFC_STD_LEGACY for functionality we're forced to support for backward
> > compatibility with other compilers and crusty dusty-deck fortran
> > (i.e. the stuff we're embarassed by).
> > 
> > Making this distiction allows us to fine-tune the default behaviour
> > of gfortran, to accept both kinds of extensions but to warn about
> > the latter.  This is the behaviour of -std=gnu.  As an enhancement
> > to shut up these warnings, I've also added -std=legacy which makes
> > a best effort to compile whatever it can without warnings.  I've
> > also allowed -pedantic to pretty much undo -std=legacy warning wise,
> > and effectively "-std=legacy -pedantic" is equivalent to "-std=gnu".
> I like the general idea. Perhaps I would personally have chosen
> GFC_STD_DUSTY, but I guess _LEGACY is just as good and working code
> beats talk any day. ;-)
> > Although there are no users of this infrastructure yet, it should
> > resolve the LOGICAL <-> INTEGER conversion issue to everyone's
> > staisfaction and allow extensions such as using real numbers to
> > index arrays, or omitting commas to reclassified as GFC_STD_LEGACY.
> > These are really things that warning about, and writers of new code
> > should be exposed to these warnings even without specifying
> > -pedantic or -std=f95.
> I think stuff like Hollerith would be well suited for GFC_STD_LEGACY
> as well (wasn't there a patch to add Hollerith support a few days
> ago?).
I think the Hollerith constant is different. When people use Hollerith
constants, they are clear that this statement should be supported by the
compiler. I mean the compiler should not accept user's error and meanwhile
should not reject user's intention. LOGICAL <-> INTEGER conversion may be the
error of the programmer (e.g. typo error). But Hollerith constant will not. I
think it had better be the proud of gnu. Haha... :-)

Best Regards,
Feng Wang

Creative Compiler Research Group,
National University of Defense Technology, China.

Do You Yahoo!?

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