Re: [PATCH/RFA] PR gdb/648 (eval.c approval reqd)

[David Lecomber <david at streamline-computing dot com>]

Hi Jim


On Fri, 2004-08-27 at 00:59, Jim Blandy wrote:
> In your original post, you said, "G77 puts things in row-major order".
> It looks to me as if G77 puts the *types* in row-major order (contrary
> to the Dwarf spec, which wants them in the order they appear in source
> code), but it locates the actual arrays in memory in column-major
> order:
[..]
> This shows that varying the leftmost index yields the smallest change
> in element address, which is column-major.  So the arrays are actually
> laid out correctly; it's just the types in the Dwarf 2 info that are
> wrong.

Yes -- I'm in agreement here, although I hadn't actually thought of that
before.  If that weren't the case, then it wouldn't be possible to link
g77 output with other compilers,..

> If that's all correct, then this patch is approved.

Good-o,

> It seems to me that there's a separate bug in f-valprint.c.  The
> output below is incorrect, right?  It's printed as a series of
> columns, not a series of rows.  Or is that what users of a Fortran
> debugger would expect?
> 
>     (gdb) p twodi
>     $1 = (( 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18,
>     19, 20) ( 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32,
>     34, 36, 38, 40) ( 3, 6, 9, 12, 15, 18, 21, 24, 27, 30, 33, 36, 39, 42,
> [..]

A Fortran user would expect this like this, so it's not a bug.  Suppose
a Fortran-er is working with an array of 3-d points, for some finite
element application.  To ensure the x,y,z are in adjacent memory for
better cache behaviour, there'd be an array of REAL(3, 100000) -- which
when printed by GDB will produce a list of points (x, y, z). They'd want
that.

Cheers
David