PR30947 - resolving ALARM

Brooks Moses brooks.moses@codesourcery.com
Thu Mar 8 01:18:00 GMT 2007


Daniel Franke wrote:
> I spent this evening feeling my way around iresolve.c and trans-intrinsic.c to 
> figure out how to fix the code that is generated for ALARM. It happens, that 
> the intent(out) value of the STATUS argument is lost:
[...]
>     D.1003 = (int4) sec;
>     D.1004 = (int4) h;
>     D.1005 = (int4) stat;
>     _gfortran_alarm_sub_int (&D.1003, &D.1004, &D.1005);
>   }
> [snip]
> 
> The first attempt was to find a way to add a line as 
>     stat = (int1) D.1005;
> which would solve the issue ...

That would, I believe, be a good long-term thing to have in the toolbox 
in general.  Also probably more complicated to implement.

> OTOH, I learned that there are two schools in the overall list of intrinsics: 
> gfc_convert_type everything or not at all. For example, the bessel family 
> take their arguments "as is", without any casting prior to calling the 
> builtin functions. 

As I mentioned in another thread, I think that there _should_ be a 
distinct difference between how this sort of thing is handled in 
arithmetic functions like the bessel family, compared to how it's 
handled in system functions like ALARM and whatnot.  Or, more 
accurately, they need not be different, but there shouldn't be an 
assumption that they're the same.

By and large, I'm in favor of having arithmetic functions take their 
arguments "as is", and system functions do casting unless (as with 
things that can overflow an INTEGER(4)) there's a good reason not to. 
The subroutines with INTENT(OUT) arguments are a flaw in this grand 
scheme, though.

> Thus, removing any casts from iresolve.c(gfc_resolve_alarm_sub) results in 
> this code:
> 
> [snip]
>   static int4 h = 1;
>   static int1 sec = 2;
>   static int2 stat = -1;
> 
>   _gfortran_set_std (68, 127, 0);
>   _gfortran_alarm_sub_int (&sec, &h, &stat);
> [snip]
> 
> This seems to work with any (integer) input type for sec and stat. The 
> question is whether this solution is acceptable? 

My guess is that this will break on big-endian machines, or with int8, 
or some combination thereof.  You're passing an integer of one kind and 
storage size to a subroutine expecting another, and it's just luck 
(albeit fairly common luck) that it happens to work.

The standard solution is to cast the INTENT(IN) arguments, and write 
multiple versions of the _gfortran_alarm_sub_int subroutine for each 
kind of the INTENT(OUT) argument.

> Index: gcc/fortran/intrinsic.texi
> ===================================================================
> --- gcc/fortran/intrinsic.texi	(revision 122640)
> +++ gcc/fortran/intrinsic.texi	(working copy)
> @@ -782,12 +782,16 @@
>  @table @asis
>  @item @emph{Description}:
>  @code{ALARM(SECONDS, HANDLER [, STATUS])} causes external subroutine @var{HANDLER}
> -to be executed after a delay of @var{SECONDS} by using @code{alarm(1)} to
> +to be executed after a delay of @var{SECONDS} by using @code{alarm(2)} to
>  set up a signal and @code{signal(2)} to catch it. If @var{STATUS} is
>  supplied, it will be returned with the number of seconds remaining until
>  any previously scheduled alarm was due to be delivered, or zero if there
>  was no previously scheduled alarm.
>  
> +The @code{HANDLER} may either a @code{SUBROUTINE}, a @code{INTEGER FUNCTION} or
> +an @code{INTEGER} scalar. The scalar values may be either @code{SIG_IGN=1} to
> +ignore the alarm generated or @code{SIG_DFL=0} to set the default action.
> +
>  @item @emph{Standard}:
>  GNU extension
>  

On the other hand, this change seems independent.  Assuming that you've 
tested to make sure that our ALARM implementation actually conforms to 
that added paragraph in practice, I think that this should be committed 
to trunk and 4.2.

(Note that that should be "an @code{INTEGER FUNCTION", though.)

Right now, for 4.2, I think the right answer is to remove the cast on 
STATUS, document that it must be an INTEGER(4), and add code to the 
appropriate gfc_check function to test for that.  Anything else strikes 
me as too risky at this late date.

Thanks for looking at this!
- Brooks



More information about the Gcc-patches mailing list