Re: Problems with gcc, g77 on Linux Alpha

[craig at jcb-sc dot com]

>Reading specs from /usr/lib/gcc-lib/alpha-redhat-linux/egcs-2.91.66/specs
>gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)

Upgrade to GCC 2.95, aka EGCS 1.2.  See <http://gcc.gnu.org/> for
lotsa important info!  (Note I'm using the new address for reporting
bugs, which also changed between EGCS 1.1.2 and GCC 2.95.)

>I have found two relatively sever problems here. First, the exp function
>in libm seems to think that 
>
>    exp(-709.) 
>
>is a Floating Point Exception instead of 0. Now, I have coded around this
>problem in my code, but now I am getting the error from the GL library
>when using fog. This seems to attack everywhere.

Hmm, I think that is Somebody Else's Problem, but am not sure.  g77 doesn't
include its own libm...though perhaps the gcc back end is open-coding
this.

>    The second problem is again quite painful. I am using a Fortran
>common block as a memory device:
>
>    integer a
>    common/mem/a(2)
>
>..
>    p = malloc(size)
>    q = p - loc(a(1))
>..
>    a(q+50) = ...
>
>As best as I can tell you are using integer*4 for relative addressing.
>My code has been working correctly on many machines for years, so I 
>do not have a "simple bug".

I gather you omitted an "integer*8 q" specification statement somewhere?

>The attached program shows both of these problems.

I don't read attachments yet, but I think the problem with the array
addressing is fixed in 2.95.  (The g77 in that version is known
as g77 0.5.25, by the way.)

>I have not figures out precisely what you are doing, but looking at 
>the samples program, my guess is that therefore assume you are using 
>4 byte integers for addressing array elements. I agree that this should 
>suffice, but you are the guys that allocate the space and I must deal with
>it. I cannot, however, without 8 byte relative addresses.

No, g77 doesn't allocate the space, AFAIK -- your code is doing it.

But, on Alphas for example, g77 used to treat A(Q) where Q is INTEGER*8
by smashing Q into an INTEGER*4 first.  It no longer does that.  The
change was made specifically to accommodate code using array indexing
like that as a (not strictly standard or portable, but popular and
usually quite workable) workaround for the lack of support for POINTER
and dynamic memory allocation in the language.

>Finally, is there an elegant way to use my own functions as replacements
>to those in libm? It seems that most of the routines in libf2c are 
>no longer used.

Some of them are open-coded, or inlined.  g77's open-coding happens
in gcc/f/com.c.  gcc's is strewn throughout a few places in the gcc/
subdirectory of GCC 2.95.

Don't get too involved in trying to fix these things without upgrading
first, is my recommendation.

BTW, some of the issues you raise are addressed on my g77 web page,
as well as the other URL I listed above.  My g77 web page is at
<http://world.std.com/~burley/g77.html>.

        tq vm, (burley)