PR30947 - resolving ALARM

[Brooks Moses]

Daniel Franke wrote:
> As suggested by Brooks, attached patch adds a check to ensure that the status 
> argument of ALARM is of default integer kind (not INTEGER(4), as this is more 
> consistent with other implementations). Accordingly, the conversion of status 
> argument in iresolve.c was removed. Further, the documentation was changed to 
> match Brooks' recommendation.

Unfortunately, checking for default integer kind means that, under 
-fdefault-integer=8, you're still passing a kind=8 integer to a library 
function that expects kind=4.

Thus, to make this work right, you'll still need to implement alarm_sub4 
and alarm_sub8 library functions (along with alarm_sub_int4 and 
alarm_sub_int8), and have gfc_resolve_alarm_sub call the appropriate one 
depending on the kind of the STATUS argument.  This is what the other 
intrinsics that use default-integer-only arguments do.

I don't think it's unreasonable to limit things to INTEGER(4) regardless 
of the -fdefault-integer flag state, for now, since that's at least the 
documented behavior of some of the other intrinsics.  We can broaden 
that to "default integer" and add the library functions and so forth 
after the 4.2.0 release.

On the other hand, there is the important point that we don't want to 
intentionally document one interface when we're going to later implement 
something incompatible with it.  So maybe the right thing to do here is 
to simply go with what you've got now, file a PR noting the type 
mismatch in the function call for the -fdefault-integer=8 case, and work 
on fixing it post-release.

- Brooks