gdb and g77

[craig@jcb-sc.com]

>  As far as I could tell, the problem is in ffecom_sym_transform(), right
>before and possibly after that 130-line comment.  The procedure that
>generates the code for array references appears to be in another section
>of code, while ffecom_sym_transform() looks like it is packaging symbols
>so that the back end can write the debug information. 

Right, but if ffecom_sym_transform() is giving the back end the wrong
"shape" for multi-dimensional arrays, then surely Toon, at least, would
have noticed the resulting performance degradation!

Given a Fortran declaration like

  REAL A(5,6)

the ordering of elements, in memory, is *supposed* to be:

  A(1,1)
  A(2,1)
  A(3,1)
  A(4,1)
  A(5,1)
  A(1,2)
  A(2,2)
  ...

The back end doesn't care about "row" vs. "column" ordering, however.

In the back end, an array is *always* one-dimensional, but it may be
an array of a type that is, itself, another array.  So the ordering
is whatever it's given by the front end.

(Yes, it is a "C-ish" back end, but it does have a higher-level array
facility than C itself does, insofar that C cannot represent arrays
of arrays -- instead, it represents arrays of pointers to arrays, for
example.)

So the way g77 *should* be 'splaining the above declaration to the back
end is:

  A is a VAR_DECL (or PARM_DECL)
    of type ARRAY
        (6 elements in size)
      of type ARRAY
          (5 elements in size)
        of type REAL

Then, g77 tells the back end about a reference to A(2,1) as:

  ARRAY_REF (ARRAY_REF (A, 1), 2)

So g77 handles all the "column-ordering" stuff.  The back end never
sees it.

If g77 wasn't doing this right, then it'd either be *totally* broken
(which, I think it's safe to say after years of beta-testing, is
not the case!), or both the decl *and* the reference would be set
up the same "wrong" way.

But, if both were *wrong*, then the back end would be laying out
*memory* in the "wrong" way, even though typical array code would
still work.

This "wrong" layout would not only break EQUIVALENCE/COMMON overlapping
of multi-dimensional arrays with single-dimension ones, it'd also
result in much lower performance of code that was running through
arrays element by element using the proper column-ordering convention.

*My* guess, again, without looking at any code (except insofar as I *wrote*
the g77 code, so I'm pretty sure it's correct ;-) is that the problem
is in the back end code to handle writing debugging information.

That code doesn't expect to see "an array of an array" in C.  What
it might be doing is handling it incorrectly in general.  Or, something
I've seen people do, it might be handling it *correctly* in *general*,
then (wrongly) saying "hey, this is Fortran, let's reverse the ordering
of the subscripts, because Fortran is column-ordered".

I'd lean towards 39.999% likelihood of the former, 59.999% likelihood
of the latter, with the remaining being the likelihood of the bug
being somewhere else.

>  I'm not surprised that no one has complained about this.  My experience
>with people who do numerical computing is that they aren't that
>sophisticated when it comes to debugging-- print statements are generally
>what they do.  You can blow them away by attaching to a running process
>with the debugger and printing out the values of variables...

That's probably part of the equation: the other part being, I think
by now everybody knows g77's debuggability is pretty poor in certain
areas.

        tq vm, (burley)