[PATCH 1/2] fort_dyn_array: add basic fortran dyn array support

[Walfred Tedeschi <walfred dot tedeschi at intel dot com>]

> Keven Boell <keven.boell@linux.intel.com> writes:
>
>> Fortran provide types whose values may be dynamically allocated
>> or associated with a variable under explicit program control.
>> The purpose of this commit is
>>   * to read allocated/associated DWARF tags and store them in
>>     the dynamic property list of main_type.
>>   * enable GDB to print the value of a dynamic array in Fortran
>>     in case the type is allocated or associated (pointer to
>>     dynamic array).
>>
>> Examples:
>> (gdb) p vla_not_allocated
>> $1 = <not allocated>
>>
>> (gdb) p vla_allocated
>> $1 = (1, 2, 3)
>>
>> (gdb) p vla_ptr_not_associated
>> $1 = <not associated>
>>
>> (gdb) p vla_ptr_associated
>> $1 = (1, 2, 3)
>>
>> Add basic test coverage for most dynamic array use-cases
>> in Fortran.
>> The commit contains the following tests:
>>   * Ensure that values of Fortran dynamic arrays
>>     can be evaluated correctly in various ways and states.
>>   * Ensure that Fortran primitives can be evaluated
>>     correctly when used as a dynamic array.
>>   * Dynamic arrays passed to subroutines and handled
>>     in different ways inside the routine.
>>   * Ensure that the ptype of dynamic arrays in
>>     Fortran can be printed in GDB correctly.
>>   * Ensure that dynamic arrays in different states
>>     (allocated/associated) can be evaluated.
>>   * Dynamic arrays passed to functions and returned from
>>     functions.
>>   * History values of dynamic arrays can be accessed and
>>     printed again with the correct values.
>>   * Dynamic array evaluations using MI protocol.
>>   * Sizeof output of dynamic arrays in various states.
>>
>> The patch was tested using the test suite on Ubuntu 12.04 64bit.
>
> Hi Keven,
> The test cases added by this commit fail on some other OS and targets,
> see this thread, 
https://sourceware.org/ml/gdb-testers/2015-q4/msg02136.html
> can you take a look?
>

Hi Yao, Joel,

I don't think I will be able to fix the failures on the mentioned 
hosts/targets before you
create the branch, as I need to replicate the environment on my end 
first to start investigating.
Therefore I suggest to revert the change for now. Sorry if this caused 
any inconvenience.


Joel and Yao,

Bernhard and I we have investigated the issues reported. Issues were 
reproduced by using the newest GCC.  Looks like the issues are 
independent from the target at first sight.

Issues could be divided into 3 categories:

1.  Issue root causes to GCC 5.x and Fortran "associated" intrinsic. 
Compiler is not reporting the âAssociated property correctly. (see test 
case 1)
Affected tests:
gdb.fortran/vla-ptype.exp: ptype pvla not initialized
gdb.fortran/vla-value.exp: print undefined pvla
gdb.fortran/vla-value.exp: print non-associated &pvla
gdb.fortran/vla-value.exp: print undefined pvla(1,3,8)
gdb.mi/mi-vla-fortran.exp: evaluate not associated vla
gdb.mi/mi-vla-fortran.exp: create local variable pvla2_not_associated
gdb.mi/mi-vla-fortran.exp: info type variable pvla2_not_associated

2.  Test issues. Test take into account that array created is 
initialized by default. Initialization depends on the compiler also 
Fortran standard does not state the need for initialization.
Affected tests:
gdb.mi/mi-vla-fortran.exp: evaluate allocated vla

3.  GCC or GDB error. Breakpoint is completely off, breakpoint on return 
line is triggered before the execution of the functions body. Deeper 
investigation should be done to define the real issue.
Affected tests:
gdb.cp/vla-cxx.exp


Snippets of what is not working properly are presented below:
---------------------

1.
  program vla

  real, target, allocatable :: vla1 (:, :, :)
  real, pointer :: pvla (:, :, :)
  logical :: l
  logical :: is_associated
  integer location
  allocate (vla1 (10,10,10))
  l = allocated(vla1)
  vla1(:, :, :) = 1311

  is_associated = .FALSE.

  is_associated = associated(pvla)   !!! <--  HERE: Compiler reports 
pvla as associated, it should not be.

  location = LOC(pvla)
  write (*,*) "pvla is associated: ", is_associated
  write (*,*) "Location of pvla is: ",location

  pvla => vla1                        ! is associated here!
  l = associated(pvla)



end program vla

We intend to add a GCC defect in bugzilla. Do you agree?

---------------------



2.

Source file: gdb.mi/VLA.F90

  real, pointer :: pvla2 (:, :)

  logical :: l



  allocate (vla1 (5))

  vla1(:) = 0;  	      !!! Missing line: Test consider that array is 
initialized, but standard does not enforce that.

  l = allocated(vla1)



  vla1(:) = 1

  vla1(2) = 42

  vla1(4) = 24


-> We are going to prepare a patch for that.

---------------------
3.
Compile & run: gdb.cp/vlx-cxx

      Execute in GDB

break 48

run

next

             Next shows beginning of âmainâ and not the code where the 
breakpoint was hit.



Reading symbols from ../gdb/testsuite/gdb.cp/vla-cxx...done.

(gdb) b 48

Breakpoint 1 at 0x4005ae: file ../../../gdb/testsuite/gdb.cp/vla-cxx.cc, 
line 48.

(gdb) r

Starting program: ../gdb/testsuite/gdb.cp/vla-cxx



Breakpoint 1, main (argc=1, argv=0x7fffffffda28)

    at ../../../gdb/testsuite/gdb.cp/vla-cxx.cc:48

48             return vla[2];

(gdb) n

36             int z = 3;

(gdb) n

38             int vla[z];



->We will investigate the root cause here. GDB or debug information is 
wrong here.



Thanks and regards,
Bernhard & Fred
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928