Re: [PATCH v2 12/16] testsuite, fortran: fix info-types for intel compilers

[Andrew Burgess <aburgess@redhat.com>]

Nils-Christian Kempke <nils-christian.kempke@intel.com> writes:

> This info-types.exp test case had a few issues that this patch fixes.
>
> First, the emitted symbol character(kind=1)/character*1 (different
> compilers use different naming converntions here) which is checkedin the
> test is not actually expected given the test program.  There is no
> variable of that type in the test.  Still, gfortran emits it for every
> Fortran program there is.  The reason is the way gfortran handles Fortran's
> named main program.  It generates a wrapper around the Fortran program
> that is quite similar to a C main function.  This C-like wrapper has
> argc and argv arguments for command line argument passing and the argv
> pointer type has a base type character(kind=1) DIE emitted at CU scope.
>
> Given the program
>
>   program prog
>   end program prog
>
> the degbug info gfortran emits looks somewhat like
>
>    <0><c>: Abbrev Number: 3 (DW_TAG_compile_unit)
>       ...
>    <1><2f>: Abbrev Number: 4 (DW_TAG_subprogram)
>       <30>   DW_AT_external    : 1
>       <30>   DW_AT_name        : (indirect string, ...): main
>       ...
>    <2><51>: Abbrev Number: 1 (DW_TAG_formal_parameter)
>       <52>   DW_AT_name        : (indirect string, ...): argc
>       ...
>    <2><5d>: Abbrev Number: 1 (DW_TAG_formal_parameter)
>       <5e>   DW_AT_name        : (indirect string, ...): argv
>       ...
>       <62>   DW_AT_type        : <0x77>
>       ...
>    <2><6a>: Abbrev Number: 0
>    ...
>    <1><77>: Abbrev Number: 6 (DW_TAG_pointer_type)
>       <78>   DW_AT_byte_size   : 8
>       <79>   DW_AT_type        : <0x7d>
>    <1><7d>: Abbrev Number: 2 (DW_TAG_base_type)
>       <7e>   DW_AT_byte_size   : 1
>       <7f>   DW_AT_encoding    : 8        (unsigned char)
>       <80>   DW_AT_name        : (indirect string, ...): character(kind=1)
>    <1><84>: Abbrev Number: 7 (DW_TAG_subprogram)
>       <85>   DW_AT_name        : (indirect string, ...): prog
>    ...
>
> Ifx and flang do not emit any debug info for a wrapper main method so
> the type is missing here.  There was the possibility of actually adding
> a character*1 type variable to the Fortran executable, but both, ifx and
> gfortran chose to emit this variable's type as a DW_TAG_string_type of
> length one (instead of a character(kind=1), or whatever the respective
> compiler naming convention is).  While string types are printed as
> character*LENGHT in the fortran language part (e.g. when issuing a
> 'ptype') they do not generate any symbols inside GDB.  In read.c it says
>
>    /* These dies have a type, but processing them does not create
>       a symbol or recurse to process the children.  Therefore we can
>       read them on-demand through read_type_die.  */
>
> So they did not add any output to 'info types'.  Only flang did emit a
> character type here.
> As adding a type would have a) not solved the problem for ifx and would
> have b) somehow hidden the curious behavior of gfortran, instead, the
> check for this character type was chagened to optional with the
> check_optional_entry to allow for the symbols's absence and to allow
> flang and ifx to pass this test as well.
>
> Second, the line checked for s1 was hardcoded as 37 in the test.  Given
> that the type is actually defined on line 41 (which is what is emitted by
> ifx) it even seems wrong.  The line check for s1 was changed to actually
> check for 41 and a gfortran bug has been filed here
>
>    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105454
>
> The test is now marked as xfail for gfortran.
>
> Third, the whole test of checking for the 'Type s1' in info types seemed
> questionable.  The type s1 is declared iside the scope of the Fortran
> program info_types_test.  Its DIE however is emitted as a child of the
> whole compilation unit making it visible outside of the program's scope.
> The 'info types' command checks for types stored in the GLOBAL_BLOCK,
> or STATIC_BLOCKm wgucm according to block.h
>
>    The GLOBAL_BLOCK contains all the symbols defined in this compilation
>    whose scope is the entire program linked together.
>    The STATIC_BLOCK contains all the symbols whose scope is the
>    entire compilation excluding other separate compilations.
>
> so for gfortran, the type shows up in the output of 'info types'.  For
> flang and ifx on the other hand this is not the case.  The two compilers
> emit the type (correctly) as a child of the Fortran program, thus not
> adding it to either, the GLOBAL_BLOCK nor the LOCAL_BLOCK.  A bug has
> been opened for the gfortran scoping issue:
>
>    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105454
>
> While the most correct change might have been removing the check for s1,
> the change made here was to only check for this type in case of gfortran
> being used as the compiler, as this check also covers the declaration
> line issue mentioned above.  A comment was added to maybe remove this
> check once the scoping issue is resolved (and it starts to fail with
> newer gfortran versions).  The one used to test these changes was 13.0.
> ---
>  gdb/testsuite/gdb.fortran/info-types.exp | 20 +++++++++++++++++---
>  1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/gdb/testsuite/gdb.fortran/info-types.exp b/gdb/testsuite/gdb.fortran/info-types.exp
> index 9a388dd1a1..527f9fead3 100644
> --- a/gdb/testsuite/gdb.fortran/info-types.exp
> +++ b/gdb/testsuite/gdb.fortran/info-types.exp
> @@ -41,12 +41,26 @@ set real4 [fortran_real4]
>  GDBInfoSymbols::run_command "info types"
>  GDBInfoSymbols::check_header "All defined types:"
>  
> -GDBInfoSymbols::check_entry "${srcfile}" "" "${character1}"
> +GDBInfoSymbols::check_optional_entry "${srcfile}" "" "${character1}"
>  GDBInfoSymbols::check_entry "${srcfile}" "" "${integer4}"
>  GDBInfoSymbols::check_entry "${srcfile}" "" "${logical4}"
>  GDBInfoSymbols::check_entry "${srcfile}" "$decimal" "Type m1t1;"
>  GDBInfoSymbols::check_entry "${srcfile}" "" "${real4}"
> -GDBInfoSymbols::check_entry "${srcfile}" "37" "Type s1;"
> +
> +# The emission of the 'Type s1' at global scope is actually not expected.  The
> +# type is defined inside the Fortran program and thus scoped to it as well.
> +# However, gfortran (13) emits its DIE as a child of the whole cu, while flang
> +# and ifx emit the DIE as a child of the main program info_types_test.  As
> +# 'info types' only checks for types stored in the GLOBAL_BLOCK, or
> +# STATIC_BLOCK we should not expect this type as an output here.  Still, we
> +# leave the test here for now (for gfortarn only) as it also covers a line info
> +# bug (see gcc/105454).  The bug for the type scoping can be found at
> +# gcc/105785.  Should gfortran fix this in some future version this test will
> +# start to fail and should be removed.
> +if { [test_compiler_info {gfortran-*} f90] } {
> +    setup_xfail *-*-* gcc/105454
> +    GDBInfoSymbols::check_entry "${srcfile}" "41" "Type s1;"
> +}
>  
>  return 0
>  
> @@ -62,5 +76,5 @@ gdb_test "info types" \
>  	 "(35:\[\t \]+Type __vtype_mod1_M1t1;" \
>  	 ")?$decimal:\[\t \]+Type m1t1;" \
>  	 "\[\t \]+${real4}" \
> -	 "37:\[\t \]+Type s1;(" \
> +	 "41:\[\t \]+Type s1;(" \
>  	 ".*)?"]

Thanks, this LGTM.

Andrew