f771 assertion failure

[Craig Burley]

>> >>> apsi.f: In subroutine `rffti1':
>> >>> apsi.f:4886: warning:
>> >>>          CALL RFFTI1 (N,WSAVE(N+1),WSAVE(2*N+1))
>> >>>               1
>> >>> apsi.f:4983: (continued):
>> >>>          SUBROUTINE RFFTI1 (N,WA,IFAC)
>> >>>                     2
>> 
>> Not knowing what's going on...but looking at the line numbers brings up
>> a question:  is that a recursive subroutine?
>
>No, it is a forward reference to rffti1.  Though looking at the
>message again, I can see how you get that impression -- the 
>`in subroutine' bit is rather misleading.

Good point.  g77 is due an overhaul in its diagnostics anyway, but
it's not clear to me how to solve this.  The diagnostic pertains
to the SUBROUTINE statement, which is "in" rffti1, but it also
pertains to an earlier CALL, which isn't.  I think just producing
the proper "In" message before the CALL and then "In rffti1:" just
before the SUBROUTINE would be the best approach, but it might not
be worth doing before the rewrite (at which point g77 will stop
outputting the source code in its diagnostics, to be more like gcc).

Other alternatives, like changing the ordering of the output
(which is essentially what gcc does in a similar situation, IIRC),
don't seem *quite* as attractive, but "proper ordering of
diagnostics" is probably a rat-hole anyway.  (E.g. for some people,
the diagnostics should be a report, therefore ordered by most-pertinent-
source-line number as closely as possible; for others, they should
be output as quickly as possible, so one may interrupt a compilation
instead of waiting.  I tend to prefer the latter myself, but I've
tended to use slow machines to compile large codes.  ;-)

>It tells me to use -fno-globals, which is a cookbook answer to
>get rid of the warning, but does not help me understand the 
>consequences of ignoring the warning -- what happens to the bits?
>Does some data conversion take place?  Since Fortran passes by
>reference (always?), where does the (new?) data get put, on the
>stack?  Or does the called function see the bits of the FP number
>as an integer?

I'll look at improving the docs.  It's important to avoid giving
the impression that any behavior is "officially documented",
though.  At the very least, pointing the reader to "Debugging
and Interfacing" would probably allow him to infer what actually
happens in the current implementation, without having any reason
to believe all future g77 implementations will work exactly the
same way...but perhaps more should be said.

        tq vm, (burley)