> Keven Boell 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 = >> >> (gdb) p vla_allocated >> $1 = (1, 2, 3) >> >> (gdb) p vla_ptr_not_associated >> $1 = >> >> (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 &j!z޶owIb֫rnr