In the gdb.fortran/mixed-lang-stack.exp test when somewhere deep in a
bunch of nested function calls we issue and test a 'info args' command
for the mixed_func_1b function (when in that function's frame).
The signature of the function looks like
subroutine mixed_func_1b(a, b, c, d, e, g)
use type_module
implicit none
integer :: a
real(kind=4) :: b
real(kind=8) :: c
complex(kind=4) :: d
character(len=*) :: e
character(len=:), allocatable :: f
TYPE(MyType) :: g
and usually one would expect arguments a, b, c, d, e, and g to be
emitted here. However, due to some compiler dependent treatment of the
e array the actual output in the test (with gfortran/ifx) is
(gdb) info args
a = 1
b = 2
c = 3
d = (4,5)
e = 'abcdef'
g = ( a = 1.5, b = 2.5 )
_e = 6
where the compiler generated '_e' is emitted as the length of e. While
ifort also generates an additional length argument, the naming (which is
up to the compilers here I think, I could not find anything in the
Fortran standard about this) is different and we see
(gdb) info args
a = 1
b = 2
c = 3
d = (4,5)
e = 'abcdef'
g = ( a = 1.5, b = 2.5 )
.tmp.E.len_V$4a = 6
To make both outputs pass the test, I kept the additional argument for now and
made the regex for the emitted name of the last variable match any
arbitrary name.
Approved-by: Tom Tromey <tom@tromey.com>
set g_val_pattern "\\( a = 1.5, b = 2.5 \\)"
}
+ # The last argument here in info args is compiler generated. It
+ # contains length of the passed array e (we are in mixed_func_1b here).
+ # For gfortran and ifx the compilers conveniently named this '_e',
+ # ifort however prints .tmp.E.len_V$4a. As is seems unreasonable to
+ # test for an artificially created name and as at the same time all
+ # 3 tested compilers emit this argument, we only check for its
+ # existence and its value (6).
set args_pattern [multi_line \
"a = 1" \
"b = 2" \
"d = ${d_pattern}" \
"e = ${e_pattern}" \
"g = ${g_val_pattern}" \
- "_e = 6" ]
+ ".* = 6" ]
gdb_test "info args" $args_pattern \
"info args in frame #7"