This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [gfortran] Patch for PR 17590: Tagging intrinsics with standard version
- From: Paul Brook <paul at codesourcery dot com>
- To: fortran at gcc dot gnu dot org
- Cc: Janne Blomqvist <jblomqvi at cc dot hut dot fi>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 8 Oct 2004 12:51:34 +0100
- Subject: Re: [gfortran] Patch for PR 17590: Tagging intrinsics with standard version
- Organization: CodeSourcery
- References: <20040922194430.GA12720@vipunen.hut.fi> <200410031531.49444.paul@codesourcery.com> <20041008090353.GA21156@cc.hut.fi>
On Friday 08 October 2004 10:03, Janne Blomqvist wrote:
> On Sun, Oct 03, 2004 at 03:31:49PM +0100, Paul Brook wrote:
> > On Wednesday 22 September 2004 20:44, Janne Blomqvist wrote:
> > > Hello,
> > >
> > > The following patch tags all intrinsic subroutines and functions with
> > > a standard version, and prints out error or warning messages if an
> > > intrinsic does not exist in the standard the user has chosen (via the
> > > -std flag). The intrinsics are flagged as belonging to either F77,
> > > F95, F2003 or GNU. The available choices for the user has not changed
> > > e.g. they are default (basically F95 + GNU extensions), f95, f2003 or
> > > gnu (everything we have).
> >
> > Wouldn't it be better to ignore the intrinsic if it doesn't belong to the
> > selected standard?
> >
> > I would expect --std=f95 to allow the user to define and call user
> > functions with the same name as (nonstandard) intrinsics. We resolve
> > intrinsics to special names, so the user would still get link errors if
> > they tried to use nonstandard intrinsics.
> >
> > An option to warn/error about nonstandard intrinsics would probably be a
> > good idea, but I don't think it should be directly tied to --std=.
>
> I see your point, and I guess you're right.
>
> I'm thinking that it would be relatively straightforward to implement
> it such that add_sym calls some standard version checking function (to
> be implemented, but ought to be simple), and if the intrinsic that
> we're trying to add doesn't belong to that standard, simply return
> i.e. don't add the intrinsic to the symbol list?
Yes.
> The warn/error thing could be implemented largely as it is now,
> i.e. add all symbols and warn/abort if we find a nonstandard
> one. However, I'm not familiar with adding a new option to the driver,
> so I might leave this for a later patch?
Ok. If you submit a patch with the warnings conditional on some global
variable, I can wire it up to the options machinery.
> I'll try to fix something up later today or during the weekend.
Thanks.
Paul