re: About the debugging of gfortran arrays

[Feng Wang <wf_cs@yahoo.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312, Size: 2330 bytes --]

--- Wu Zhou <woodzltc@cn.ibm.com>дµÀ:

> Hello all,
> 
> I am trying to use gdb to debug gfortran program and encountered some 
> problems with arrays:
> 
> 1. The first one is about the lower bound.  It seems that gfortran change 
> the lower bound of some arrays to 0 by default (I got this feeling from my 
> experience and I also see this kind of transfer in part of the code in 
> gcc/fortran/trans-type.c. Dunno know whether it apply to all arrays. 
> Anyone could confirm or deny this?  Thanks in advance!)

Yes, all array.

> 
> To handle this, GDB need to make responsive change.  But I have one 
> question here: is this kind of design (change the lower bound of array to 
> zero) indispensible here?  Is it ok to still output the original bounds in
> the 
> debug info?  

IMHO, one dimension array is easy to be changed. But multi-dimension array is
not supported under this structure.

> 
> 2. The second one is about two-dimension array.  In the debuginfo output 
> by gfortran, two-dimension array will be flatten to one-dimension.  Take a 
> look at the following testcase please:
>
[snip] 
> 
> Although there is no problem for the output binary, but it make some 
> trouble for GDB.  So I am thinking of whether there is any solution
> for this in gfortran's side? 
> 
> For example, treat it as one-dimension array in the outputed binary, but
> still output two-dimension one in the debug information.  Maybe others? 
> 
Ok. I think we can build nested array type like C FE and reserve other type
discriptors. But from the explanation in trans-type.c it seems hard to solve
some other problems. This should be comfirmed by maintainers. Paul B, Steven B,
give some comments?

It's not only gdb problem, but also affects performance and optimization on the
tree-level. We lose the dimension infomation and can not get correct data
dependency. This limits many optimizations like loop interchange and loop
distribution, etc.

I think you can file a bug report. See:
http://gcc.gnu.org/bugzilla


Best Regards,
Feng Wang

--
Creative Compiler Research Group,
National University of Defense Technology, China.


	

	
		
___________________________________________________________ 
ÑÅ»¢Ãâ·ÑGÓÊÏ䣭ÖйúµÚÒ»¾øÎÞÀ¬»øÓʼþɧÈų¬´óÓÊÏä
http://cn.mail.yahoo.com/?id=77071