Egcs/G77 bug report

[Craig Burley]

>I'm a newbee with G77 and DEC-Alphas.  This is my first bug report so 
>please forgive me if I'm not following the proper protocol.  I'm running
>a proprietary code named GASP on a Microway AlphaPC 164LX.  NASA is
>allowed access to the source code (requiring nondisclosure) by GASP's
>owners.   The following is the platform data:
[...]

Thanks for the bug report.  Offhand, it looks like it requires
"real work", probably on the part of someone who has full access
to the source code, like yourself (I assume).  Other than having
to (necessarily) omit much of the source code, you did quite a
decent job of submitting the bug report for a "newbee" (though
you misspelled that -- it's "newbie" ;-).

I suggest you read the g77 docs even more than you clearly already
have and learn how to print out the values of the relevant dummy
variables, for example, to learn whether `iqf0', `ioffset', `i1',
`i2', `ne', `i3', and the relevant calculations are in range for
the array/function accesses surrounding the crashpoint.  (In the
C language mode, "p *i1" should, for example, work in many cases,
but not always.)

However, egcs/g77 (1.0.2) does have a *known* bug involving
negative array dimensions (maybe just negative subscripts in
references to such, I forget), IIRC, but I think this shows up
only for assumed-size arrays (e.g. "REAL A(-1:*)"), which `bc3'
appears to not be employing.

Typically, bugs like this turn out to be bugs (e.g. portability
problems) in the Fortran code, not the compiler.

Having said that, Alpha support definitely involves bleeding-
edge (or at least leading-edge) gcc/egcs/g77 work on an ongoing
basis for now, so it's more likely you've hit on a compiler bug
than if you'd seen this behavior on a Pentium, Solaris, AIX,
or other such (32-bit) system.  (I'd still learn towards a
bug in the Fortran code, though.)

I'm afraid that, without access at the moment to a working Alpha
(I have a non-working one for the moment ;-), and *especially*
without access to the complete source code (so as to debug the
program when it crashes), it's unrealistic for me to suggest
what the bug is, or how to fix it, beyond the usual advice given
in the g77 docs, on comp.lang.fortran (about SEGV's and what
they mean), etc.

And I'd guess that goes for most of the people on this list.

Especially, what we're really supposed to be doing here is responding
to specific bug reports about code *generation* in cases like this,
that is, reports that say "the code does a multiply here but the
assembler code shows the compiler generates an add" or similar.

In some cases that level of detail isn't needed, because it's clear
from the (usually complete) program what is supposed to happen vs.
what is happening, but that's not the case for your code -- SEGV's
are, in fact, *supposed* to happen it lots of cases involving bad
Fortran code on Alpha systems!

Since you haven't quite gotten to the point of being able to clearly
identify a code-generation problem, and since that's almost certainly
going to be what is involved *if* the problem is in the compiler,
not the code, we probably can't be of much help at this point.

(Still, in the g77 community, we often *try*, when it looks
straightforward enough, to help users make the leap from "my
program does something wrong when it is run" to either "here's
the bug in your program" or "there's a bug in the compiler, here's
the bad code it generates" by doing our own investigating.  Most
often, that results in the former response, not the latter, which
is why we ask users to do that for us, so as to leave us more time
to work on the compiler instead of various users' code.)

        tq vm, (burley)