On Tue, 16 Aug 2005, Peter W. Draper wrote:
> On Fri, 12 Aug 2005, Tim Jenness wrote:
>
>> I'm trying to get starlink built on my Mac with g95. It's going okay (the
>> libtool breakage is annoying but still...) but I see that GENERIC doesn't
>> do the test fo hex notation and so fails because g95 prefers X'' to ''X
>> and also doesn't have IZEXT. Before I add the tests to generic...
>>
>> Looking into this I noted a number of oddities:
>>
>> 1. I think Peter's hex test should go into the standard Fortran autoconf
>> macros. It does seem to be useful. Peter: Can you add it to
>> fortran.m4? You may want to add it to Norman's dev branch as well if
>> Norman agrees.
>
> Tim,
>
> OK, I've implemented three new macros:
>
> AC_FC_HAVE_BOZ, to check if standard f95 integer BOZ constants are
> supported
> AC_FC_HAVE_TYPELESS_BOZ, to check if these are extended to allow for
> typeless assignments
> AC_FC_HAVE_OLD_TYPELESS_BOZ, to check if the current usage is
> supported (that's typeless 'xxxx'X style)
Thanks. Whilst building kaplibs I noticed that g95 X'' style numbers seem
to be typeless since
IF ( MYREAL .LT. VAL__MINI )
doesn't work how you expect, the VAL__MINI is treated as a REAL in this
context. I needed to fix it with
IF ( MYREAL .LT. NUM_ITOR(VAL__MINI) )
[and 2 other kaplibs routines before KAPPA would display an image]
>
> and a
>
> AC_FC_HAVE_PERCENTLOC, to check if %LOC is supported (the fallback
> being to use plain LOC)
>
> I'll commit these to the HEAD branch if no one objects.
Yes please. I need the BOZ tests for Figaro.
> Don't know the real answer to this one (goes back too far, Malcolm may
> remember), but I've always assumed DCV predates PRM (note that it only
> does the difficult unsigned conversions), so we've been moving from DCV to
> PRM for a couple of decades now (bit like the non-NDF KAPPA tasks saga)...
>
> As for replacing it directly with PRM calls, I've just looked at the code,
> it uses a brutal STOP when there's an overflow (so doesn't belong in an
> ADAM task, period). Maybe time for this lot to just die, unless anyone
> knows of a legitimate use for that nastiness (realtime?).
>
I'll vote for removal. The alternative is to FPP it all so that the BOZ
constants can be fixed up. INCLUDE files can't INCLUDE other INCLUDE files
in fortran so my attempt to directly subvert with PRM failed unless I
pre-include the whole lot.
PS Did you know that g95 pre-processes include files as well as the source
file? This is not what g77 and gfortran do...
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|