Re: GNU Extension and intrinsics

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

On Thu, Jan 31, 2019 at 01:25:46PM +0000, Mark Eggleston wrote:
> A number of intrinsic functions have two parameters that must match by 
> type and kind such as "dim" and "mod". In addition there are two 
> intrinsics "max" and "min" that also require the parameters to match by 
> type and kind. The documentation for "max" and "min" at 
> https://gcc.gnu.org/onlinedocs/gfortran/Intrinsic-Procedures.html#Intrinsic-Procedures 
> states for the parameters following the first that "As a GNU extension, 
> arguments of different kinds are permitted."
> 
> Using -std=f95 the following error is produced:
> 
> 25 |   write(*,*) max(1_1, 2_4, 6_4)
>     |                      1
> Error: GNU Extension: Different type kinds at (1)
> 
> 
> The same error is also produced for "dim", "mod" and "modulo" but not "sign"
> e.g.:
> 
> 26 |   write(*,*) modulo(17, 5_2)
>     |                        1
> Error: GNU Extension: Different type kinds at (1)
> 
> There is no mention of the GNU extension applying to "dim", "mod" and 
> "modulo". The intrinsic "sign" has its parameter described in the same 
> way as mod so should the GNU Extension also apply to sign?

Pesonally, I would like to remove all of these types of extensions.
That, however, would violate POLA, and I would be dragged out into
some alley and blugeoned by programmers wielding slide rules.

Documentation can always be improved.

> According to the standard (N692 Fortran 90) the type and kind of the 
> return parameter should match that of the first parameter.

Wrong standard.  Minimum should be F95.  Hopefully, everyone is working
from F2018 and checking F95, F2003, and F2008 as needed.

> The GNU Extension is not standard, for dim, mod and modulo the kind of the 
> return type is the higher of the two parameters so the return type for 
> mod(33_2, 5_4) is integer(4) instead of integer(2).

As it is an extension, GNU Fortran can choose the kind.  I suspect
that the larger kind is always selected to avoid possible numerical 
issues.  For integers on 2-compliments hardware, this would likely
be to avoid wrap-around semantics.  For real types, this might avoid
double-rounding issues.

> Comparing with PGI Fortran: its the return type for mod(33_2, 5_4) is 
> integer(2). Oddly PGI Fortran returns integer(4) for mod(67_1, 4_1). PGI 
> Fortran also accepts different types: mod(67_2, 4.0) will
> return an integer(2).

I previously mentioned that my past experience with PGI suggests that 
it may not be a stellar example to hold gfortran against. 

> Should the GNU Extension apply to sign?

Likely.  Looking in check.c (gfc_check_sign), one finds that it calls
same_type_check (), which calls interface.c (gfc_compare_types), which
returns false for mismatch types whereupon same_type_check will issue
an error message.

To get the GNU extension for sign(), one can change intrinsics.c
(add_functions, line 2933) to use gfc_check_a_p instead of
gfc_check_sign.  gfc_check_sign can then probably be reaped. 

> The documentation should be updated to reflect where the GNU Extension 
> applies.

Yes, it should.  For the lurkers on the list, documentation changes
are the simpliest contributions one can make to the gfortran codebase.

> 
> Should the return type always match the type of the first parameter?
> 

I think the answer is 'no'.  It should match the type with the
largest kind type parameter.

> Would it be reasonable to modify the GNU Extension to allow for 
> different types (integer or real) as well as different kinds?

I'm thrilled with the idea of making gfortran a garbage disposal.
As mentioned above, I would like to remove a number of GNU extension
or default -std to -std=f2018.  This then would encourage people
to fix their invalid code, which results in portable code; or,
it will encourage people to use a different compiler.

-- 
Steve