Re: What does GFC_STD_F77 do?

[Janne Blomqvist <jblomqvi at cc dot hut dot fi>]

On Wed, Jan 26, 2005 at 06:18:56PM -0800, Steve Kargl wrote:
> 
>        program costest
>        complex(4) z4
>        complex(8) z8
>        z4 = (1.e0,1.e0)
>        z8 = (1.d0,1.d0)
>        z4 = cos(z4)
>        z8 = cos(z8)
>        end
> 
> 
> troutmask:sgk[201] gfc -o d d.f
> troutmask:sgk[202] gfc -o d -std=f77 d.f
> f951: error: unrecognized command line option "-std=f77"

Hmm, as the one who created the GFC_STD_F77 thing, I guess I'm
qualified to explain... ;-)

The point is that gfortran needs to distinguish between intrinsics
belonging to different standard versions, which is done using these
GFC_STD_* bitmap flags. These flags however have no direct
correspondence with the -std=xyz command-line options. IIRC in
options.c you can find how the various -std=xyz options are mapped to
the GFC_STD_* flags. Thus a "complete" standard is a combination of
many GFC_STD_XYZ flags. For example, -std=f95 means that

option_t.allow_std = GFC_STD_F77 | GFC_STD_F95 | GFC_STD_F95_OBS;

or something along those lines (I don't have the sources in front of
me right now, sorry). So, GFC_STD_F77 means that the intrinsic marked
with it belongs fo the F77 standard. However, since F95 includes most
of F77, GFC_STD_F95 can't mean any intrinsic belonging to F95 (since
most are already marked with GFC_STD_F77), but rather an intrinsic
that was added to either F90 or F95.

> troutmask:sgk[203] gfc -o d -std=f95 d.f
>  In file d.f:7
> 
>        z8 = cos(z8)                                                     
>                1
> Error: Type of argument 'x' in call to 'cos' at (1) should be REAL(4), not COMPLEX(8)
> troutmask:sgk[204] gfc -o d -std=gnu d.f
> 
> This is clearly not good.

Hmm, whether that is a real bug or only a case of being overly anal
can be debated. ;-) AFAIK, F95 does not define sqrt for complex
arguments (it's a G77 extension), so technically it's correct to
abort. Whether it's practical and reasonable is another question.

One possible solution could be to create a command-line option
-freally-strict-std or something like that, and do the above thing
only if that flag is used? This could be implemented e.g. by including
a check for that option in the make_generic function that is used to
add a set of intrinsics under a single generic name. 

Well, as I proposed the fix described above, I guess I'm obliged to
volunteer to do it. Unless Steve or somebody else has a better idea?

-- 
Janne Blomqvist