[Patch ping]: Testcase for gdb's handling of Fortran's column-firstarray

[Wu Zhou <woodzltc at cn dot ibm dot com>]

Hello maintainers,

Any idea on this testcase?  Is it worthwhile for it to get into GDB 
testsuite?  Maybe in the incoming 6.4 release? Any comments and 
suggestions are highly appreciated!  Thanks.

Regards
- Wu Zhou

P.S: the original patch link is:

http://sources.redhat.com/ml/gdb-patches/2005-11/msg00056.html

On Thu, 3 Nov 2005, Wu Zhou wrote:

> Hi David,
> 
> On Wed, 2 Nov 2005, David Lecomber wrote:
> 
> > 
> > > OK.  With all these said, here is the patch.  I had tested it on FC4, it 
> > > reported no failure.  But however I _did_ found a old gdb (6.1 maybe) 
> > > handle this incorrectly.  So this testcase still make senses.  OK to 
> > > commit?
> > 
> > 
> > Hi Wu
> > 
> > That's what I'd expect, as my patch to fix things went in to GDB 6.2.1
> > (iirc).
> 
> Yes. I see you committed a patch for this in 2004-08-29.  So your patch is 
> far far before this testcase.  :-)
>   
> > 
> > One thing to note is that g77 puts things the wrong way round in the
> > symbol table (but not in the real data).  In the dwarf2 reader we have
> > an explicit fix for this incorrect GNU behaviour, but you will not find
> > the same fix in stabs or dwarf1 -- so on legacy platforms (AIX, Solaris)
> > with g77 you should expect failure with GNU, pass with IBM's XLF and
> > Sun's Forte.  
> > 
> > It's also going to fail on Linux with -gstabs as a parameter for g77.  
> 
> I am not familar with stabs format and also don't have AIX or Solaris at 
> hand to try any test.  But I found it is okay with "-gstabs" option.  
> Don't know why, maybe someone's patch fixed this quietly at some time we 
> don't know.  Here is the session snapshot:
> 
> woodzltc@linux:~/DE/gdb_cvs/src/gdb/testsuite/gdb.fortran> g77 -gstabs -o dim-order-stabs dim-order.f
> woodzltc@linux:~/DE/gdb_cvs/src/gdb/testsuite/gdb.fortran> ~/DE/gdb_cvs/build/gdb/gdb -q ./dim-order-stabs
> Using host libthread_db library "/lib/tls/libthread_db.so.1".
> (gdb) b dim-order.f :36
> Breakpoint 1 at 0x804878b: file dim-order.f, line 36.
> (gdb) r
> Starting program: 
> /home/woodzltc/DE/gdb_cvs/src/gdb/testsuite/gdb.fortran/dim-order-stabs
> 
> Breakpoint 1, MAIN__ () at dim-order.f:36
> 36            call sub(aa)
> Current language:  auto; currently fortran
> (gdb) p aa
> $1 = (( 1, 2, 3) ( 2, 4, 6) ( 3, 6, 9) ( 4, 8, 12) )
> (gdb) p aa(3,2)
> $2 = 6 
> 
> 
> > I've not checked gfortran behaviour -- if it works, it's either because
> > gfortran haven't fixed the original issue, or they changed the
> > expression that we check the 'producer' against before making the swap
> > round (you'll find that in dwarf2readc).
> 
> gfortran has some other problem with the multi-dimension array in dwarf 
> output.  One of it is that it flatten multi-dimension arrays int one 
> dimension ones.  So this testcase doesn't work for gfortran at this time.
> 
> P.S: I opened a PR for this behaviour, here is the link: 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22244
> 
> One of gfortran maintainner also open a meta-bug for all debugging related 
> problems for gfortran, it is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24546
> 
> 
> Regards
> - Wu Zhou
> 
>