g77 problem

[Craig Burley]

[<egcs-bugs@cygnus.com> is now the proper bug-reporting address, which
is a change since egcs 1.0 first came out, FYI.]

>       SCTT=DEXP(-SCT1)
>       SCT3=DEXP(-SCT1)
>       print "(3F20.10)",SCT1,SCTT,SCT3
>       STOP
>
>which is producing
>
>        1.9546141298                 NaN        0.1416191127
>
>i.e. DEXP is returning NaN the first time it is called, with a valid
>argument?  Is this a known problem, if it is is there a fix.  Might
>this be a problem somewhere else in the code, if so how can I
>diagnose the problem.
>
>I tried to reduce the problem to a smaller size (the code is about 40k
>lines of F77), but so far I have been unable to get a shorter test
>progam to fail!!

As the bug-reporting documentation in egcs says (or should say), don't
worry much about cutting down a problem size in general.

However, there are times when it is necessary to do so, such as when
you don't have permission of the copyright holder to send the code to
us, or when the behavior of the program is sufficiently complex that
we're unlikely to be able to quickly spot the problem even if we
*can* reproduce it.

I'm not sure whether you might have either of those problems.

In any case, you have an easy out for now -- you can try egcs 1.1
when it comes out, perhaps even a pre-release snapshot.  The snapshots
are getting quite stable because we're in a feature-freeze, testing
them, so the usual dizzying pace of changes is quite slow (in the
1.1 branch, from which the ftp-able snapshots are made, anyway).

Another approach people sometimes use is to track the problem down
in assembler mode, looking at both the generated code (where problems
can sometimes be spotted) and the actual contents of registers and
memory to "see" more detail than the HLL mode of the debugger normally
shows.

Sometimes in combination with the above, people also use the -S option
to produce the assembler code instead of an object file, and even the
-dA option (look it up under -d!) to dump all the internal compiler RTL
to see where the RTL might have gone wrong (though that requires a
learning curve not unlike learning assembler to do the other approaches,
frankly ;-).  Once you spot where the RTL goes wrong, you've got a
near-smoking-gun in terms of a portion of source code in gcc that
probably has the bug (or at least manifests some earlier bug).

        tq vm, (burley)