[PATCH v2 00/16] Fortran compiler identification and ifx testsuite support

[PATCH v2 00/16] Fortran compiler identification and ifx testsuite support

[Nils-Christian Kempke]

Hi,

V1 of this series can be found here:

  https://sourceware.org/pipermail/gdb-patches/2022-May/188904.html

Changes since v1:

  * Patch 03: There were some leftovers in the commit message from an
  earlier version of the patch - these have been removed.

  * Patch 04: The commit message has been renamed and a comment been
  adapted according to Andrew's feedback.  The getting_compiler_info
  variable now also uses actual bool values.

  * Patch 06: The commit message has been adapted and now says that
  the intel C compiler names have not yet been used in the testsuite (to
  avoid confusion as to why there are no changes done in the testsuite).

  * Patch 08: This patch has been dropped, instead an ifx bug was filed.
  So from now on the patch numbers will be off by 1.

  * Patch 11 (now 10): The comment has been reworded and
    'need the -debug-parameters all flag set to emit'
  now reads
    'need the -debug-parameters flag set to emit' 
  Also, not only ifx but also ifort requires the flag so it is now added
  for both compilers.

  * Patch 13 (now 12): I added a comment to the patch as well as made
  the commit message a lot more elaborate (after some online
  discussion).

  * Patch 14: This patch has been dropped for now as we are claifying
  whether ifx should change its debug output.  The patch numbers will
  now be off by 2. 

  * Patch 18 (now 16): The '-wrap' is now used here instead of adding
  the $gdb_prompt in test_multiple.  Also, flang was added to the
  comments.

Patch 01, 02, 05, 07, 09 (now 08), 10 (now 09), 12 (now 11), 15 (now 13),
16 (now 14), and 17 (now 15) had been approved before and were not
changed/included here.

I am happy about any feedback.

Cheers,

Nils

Abdul Basit Ijaz (1):
  gdb/testsuite: Use -module option for Intel Fortran compilers

Cristian Sandu (1):
  gdb/testsuite: add Fortran compiler identification to GDB

Felix Willgerodt (1):
  gdb/testsuite: Fix fortran types for Intel compilers.

Nils-Christian Kempke (13):
  gdb/testsuite: remove F77_FOR_TARGET support
  gdb/testsuite: move getting_compiler_info to front of gdb_compile
  gdb/testsuite: rename intel next gen c/cpp compilers
  gdb/testsuite: disable charset.exp for intel compilers
  testsuite, fortran: add required external keyword
  testsuite, fortran: add compiler dependent types to
    dynamic-ptype-whatis
  testsuite, fortran: Add '-debug-parameters all' when using ifx/ifort
  testsuite/lib: add check_optional_entry for GDBInfoSymbols
  testsuite, fortran: fix info-types for intel compilers
  testsuite, fortran: allow additional completions in module.exp
  gdb, testsuite, fortran: fix double free in mixed-lang-stack.exp
  gdb, testsuite, fortran: fixup mixed-lang-stack for Intel/LLVM
    compilers
  gdb/testsuite: fixup common-block.exp for intel compilers

 gdb/testsuite/boards/cc-with-tweaks.exp       |   5 -
 gdb/testsuite/boards/debug-types.exp          |   1 -
 gdb/testsuite/boards/gold-gdb-index.exp       |   1 -
 gdb/testsuite/gdb.fortran/assumedrank.exp     |   6 +-
 gdb/testsuite/gdb.fortran/charset.exp         |   5 +
 .../gdb.fortran/class-allocatable-array.exp   |   4 +-
 gdb/testsuite/gdb.fortran/common-block.exp    |  38 ++++++-
 .../gdb.fortran/derived-type-striding.exp     |   2 +-
 .../gdb.fortran/dynamic-ptype-whatis.exp      |  79 +++++++-------
 gdb/testsuite/gdb.fortran/function-calls.f90  |   1 +
 gdb/testsuite/gdb.fortran/info-types.exp      |  20 +++-
 gdb/testsuite/gdb.fortran/library-module.exp  |   2 +-
 .../gdb.fortran/mixed-lang-stack.cpp          |  12 +--
 .../gdb.fortran/mixed-lang-stack.exp          |  21 ++--
 gdb/testsuite/gdb.fortran/module.exp          |   5 +-
 gdb/testsuite/gdb.fortran/namelist.exp        |   2 +-
 gdb/testsuite/gdb.fortran/nested-funcs-2.exp  |   3 +-
 .../gdb.fortran/ptype-on-functions.exp        |   6 +-
 gdb/testsuite/gdb.fortran/vla-type.exp        |   2 +-
 gdb/testsuite/lib/compiler.F90                |  69 ++++++++++++
 gdb/testsuite/lib/compiler.c                  |   2 +-
 gdb/testsuite/lib/compiler.cc                 |   2 +-
 gdb/testsuite/lib/fortran.exp                 | 100 +++++++++++-------
 gdb/testsuite/lib/future.exp                  |  21 +---
 gdb/testsuite/lib/gdb.exp                     |  62 +++++++----
 gdb/testsuite/lib/sym-info-cmds.exp           |  18 +++-
 26 files changed, 318 insertions(+), 171 deletions(-)
 create mode 100644 gdb/testsuite/lib/compiler.F90

-- 
2.25.1

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

[PATCH v2 03/16] gdb/testsuite: Fix fortran types for Intel compilers.

[Nils-Christian Kempke]

From: Felix Willgerodt <felix.willgerodt@intel.com>

Newer Intel compilers emit their dwarf type name in a slightly different
format.  Therefore, this needs adjustment to make more tests pass in the
Fortran testsuite.

Co-authored-by: Abdul Basit Ijaz <abdul.b.ijaz@intel.com>
Co-authored-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
---
 gdb/testsuite/lib/fortran.exp | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/gdb/testsuite/lib/fortran.exp b/gdb/testsuite/lib/fortran.exp
index a97c6eeb4e..9531d393a1 100644
--- a/gdb/testsuite/lib/fortran.exp
+++ b/gdb/testsuite/lib/fortran.exp
@@ -38,6 +38,8 @@ proc fortran_int4 {} {
 	return "integer"
     } elseif {[test_compiler_info {icc-*}]} {
 	return "INTEGER\\(4\\)"
+    } elseif {[test_compiler_info {intel-*}]} {
+	return "INTEGER\\*4"
     } else {
 	return "unknown"
     }
@@ -52,6 +54,8 @@ proc fortran_int8 {} {
 	return "integer\\*8"
     } elseif {[test_compiler_info {icc-*}]} {
 	return "INTEGER\\(8\\)"
+    } elseif {[test_compiler_info {intel-*}]} {
+	return "INTEGER\\*8"
     } else {
 	return "unknown"
     }
@@ -66,6 +70,8 @@ proc fortran_real4 {} {
 	return "real"
     } elseif {[test_compiler_info {icc-*}]} {
 	return "REAL\\(4\\)"
+    } elseif {[test_compiler_info {intel-*}]} {
+	return "REAL\\*4"
     } else {
 	return "unknown"
     }
@@ -80,6 +86,8 @@ proc fortran_real8 {} {
 	return "double precision"
     } elseif {[test_compiler_info {icc-*}]} {
 	return "REAL\\(8\\)"
+    } elseif {[test_compiler_info {intel-*}]} {
+	return "REAL\\*8"
     } else {
 	return "unknown"
     }
@@ -94,6 +102,8 @@ proc fortran_complex4 {} {
 	return "complex"
     } elseif {[test_compiler_info {icc-*}]} {
 	return "COMPLEX\\(4\\)"
+    } elseif {[test_compiler_info {intel-*}]} {
+	return "COMPLEX\\*8"
     } else {
 	return "unknown"
     }
@@ -108,6 +118,8 @@ proc fortran_complex8 {} {
 	return "double complex"
     } elseif {[test_compiler_info {icc-*}]} {
 	return "COMPLEX\\(8\\)"
+    } elseif {[test_compiler_info {intel-*}]} {
+	return "COMPLEX\\*16"
     } else {
 	return "unknown"
     }
@@ -122,6 +134,8 @@ proc fortran_complex16 {} {
 	return "quad complex"
     } elseif {[test_compiler_info {icc-*}]} {
 	return "COMPLEX\\(16\\)"
+    } elseif {[test_compiler_info {intel-*}]} {
+	return "COMPLEX\\*32"
     } else {
 	return "unknown"
     }
@@ -136,6 +150,8 @@ proc fortran_logical4 {} {
 	return "logical"
     } elseif {[test_compiler_info {icc-*}]} {
 	return "LOGICAL\\(4\\)"
+    } elseif {[test_compiler_info {intel-*}]} {
+	return "LOGICAL\\*4"
     } else {
 	return "unknown"
     }
@@ -150,6 +166,8 @@ proc fortran_character1 {} {
 	return "character"
     } elseif {[test_compiler_info {icc-*}]} {
 	return "CHARACTER\\(1\\)"
+    } elseif {[test_compiler_info {intel-*}]} {
+	return "CHARACTER\\*1"
     } else {
 	return "unknown"
     }
-- 
2.25.1

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

[PATCH v2 04/16] gdb/testsuite: move getting_compiler_info to front of gdb_compile

[Nils-Christian Kempke]

The procedure gdb_compile queries its options via

   [lsearch -exact $options getting_compiler_info]

to check whether or not it was called in with the option
getting_compiler_info.  If it was called with this option it would
preprocess some test input to try and figure out the actual compiler
version of the compiler used.  While doing this we cannot again try to
figure out the current compiler version via the 'getting_compiler_info'
option as this would cause infinite recursion.  As some parts of the
procedure do recursively test for the compiler version to e.g. set
certain flags, at several places gdb_compile there are checks for the
getting_compiler_info option needed.

In the procedure, there was already a variable 'getting_compiler_info'
which was set to the result of the 'lsearch' query and used instead of
again and again looking for getting_compiler_info in the procedure
options.  But, this variable was actually set too late within the code.
This lead to a mixture of querying 'getting_compiler_info' or
doing an lserach on the options passed to the procedure.

I found this inconsistent and instead moved the variable
getting_compiler_info to the front of the procedure.  It is set to true
or false depending on whether or not the argument is found in the
procedure's options (just as before) and queried instead of doing an
lsearch on the procedure options in the rest of the procedure.
---
 gdb/testsuite/lib/gdb.exp | 21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 6fbf74442c..381367ee6c 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -4412,6 +4412,13 @@ proc gdb_compile {source dest type options} {
 
     set outdir [file dirname $dest]
 
+    # If this is set, calling test_compiler_info will cause recursion.
+    if { [lsearch -exact $options getting_compiler_info] == -1 } {
+	set getting_compiler_info false
+    } else {
+	set getting_compiler_info true
+    }
+
     # Add platform-specific options if a shared library was specified using
     # "shlib=librarypath" in OPTIONS.
     set new_options {}
@@ -4428,7 +4435,7 @@ proc gdb_compile {source dest type options} {
     # default, unless you pass -Wno-unknown-warning-option as well.
     # We do that here, so that individual testcases don't have to
     # worry about it.
-    if {[lsearch -exact $options getting_compiler_info] == -1
+    if {!$getting_compiler_info
 	&& [lsearch -exact $options rust] == -1
 	&& [lsearch -exact $options ada] == -1
 	&& [lsearch -exact $options f90] == -1
@@ -4439,7 +4446,7 @@ proc gdb_compile {source dest type options} {
 
     # Treating .c input files as C++ is deprecated in Clang, so
     # explicitly force C++ language.
-    if { [lsearch -exact $options getting_compiler_info] == -1
+    if { !$getting_compiler_info
 	 && [lsearch -exact $options c++] != -1
 	 && [string match *.c $source] != 0 } {
 
@@ -4460,7 +4467,7 @@ proc gdb_compile {source dest type options} {
     # Place (and look for) Fortran `.mod` files in the output
     # directory for this specific test.  For Intel compilers the -J
     # option is not supported so instead use the -module flag.
-    if { [lsearch -exact $options f90] != -1 } {
+    if { !$getting_compiler_info && [lsearch -exact $options f90] != -1 } {
 	# Fortran compile.
 	set mod_path [standard_output_file ""]
 	if [test_compiler_info "gcc-*"] {
@@ -4473,7 +4480,6 @@ proc gdb_compile {source dest type options} {
 
     set shlib_found 0
     set shlib_load 0
-    set getting_compiler_info 0
     foreach opt $options {
         if {[regexp {^shlib=(.*)} $opt dummy_var shlib_name]
 	    && $type == "executable"} {
@@ -4505,8 +4511,9 @@ proc gdb_compile {source dest type options} {
 	} elseif { $opt == "shlib_load" && $type == "executable" } {
 	    set shlib_load 1
 	} elseif { $opt == "getting_compiler_info" } {
-	    # If this is set, calling test_compiler_info will cause recursion.
-	    set getting_compiler_info 1
+	    # Ignore this setting here as it has been handled earlier in this
+	    # procedure.  Do not append it to new_options as this will cause
+	    # recursion.
         } elseif {[regexp "^text_segment=(.*)" $opt dummy_var addr]} {
             if { [linker_supports_Ttext_segment_flag] } {
                 # For GNU ld.
@@ -4529,7 +4536,7 @@ proc gdb_compile {source dest type options} {
     # DWARF line numbering.
     # See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88432
     # This option defaults to on for Debian/Ubuntu.
-    if { $getting_compiler_info == 0
+    if { !$getting_compiler_info
 	 && [test_compiler_info {gcc-*-*}]
 	 && !([test_compiler_info {gcc-[0-3]-*}]
 	      || [test_compiler_info {gcc-4-0-*}])
-- 
2.25.1

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

[PATCH v2 06/16] gdb/testsuite: rename intel next gen c/cpp compilers

[Nils-Christian Kempke]

The name for icx and icpx in the testsuite was earlier set to 'intel-*'
by the compiler identification.  This commit changes this to 'icx-*'.

Note, that currently these names are not used within the testsuite so no
tests have to be adapted here.
---
 gdb/testsuite/lib/compiler.c  | 2 +-
 gdb/testsuite/lib/compiler.cc | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gdb/testsuite/lib/compiler.c b/gdb/testsuite/lib/compiler.c
index 451cae3831..86140f8c0e 100644
--- a/gdb/testsuite/lib/compiler.c
+++ b/gdb/testsuite/lib/compiler.c
@@ -75,5 +75,5 @@ set total_length [string length __clang_version__]
 set version_start_index [string last "(" __clang_version__]
 set version_string [string range __clang_version__ $version_start_index+5 $total_length-2]
 set version_updated_string [string map {. -} $version_string]
-set compiler_info "intel-$version_updated_string"
+set compiler_info "icx-$version_updated_string"
 #endif
diff --git a/gdb/testsuite/lib/compiler.cc b/gdb/testsuite/lib/compiler.cc
index 1dfefee057..a52e81c2e3 100755
--- a/gdb/testsuite/lib/compiler.cc
+++ b/gdb/testsuite/lib/compiler.cc
@@ -63,5 +63,5 @@ set total_length [string length __clang_version__]
 set version_start_index [string last "(" __clang_version__]
 set version_string [string range __clang_version__ $version_start_index+5 $total_length-2]
 set version_updated_string [string map {. -} $version_string]
-set compiler_info "intel-$version_updated_string"
+set compiler_info "icx-$version_updated_string"
 #endif
-- 
2.25.1

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

[PATCH v2 10/16] testsuite, fortran: Add '-debug-parameters all' when using ifx/ifort

[Nils-Christian Kempke]

In order for ifx and ifort to emit all debug entries, even for unused
parameters in modules we have to define the '-debug-parameters all' flag.

This commit adds it to the ifx-*/ifort-* specific flags in gdb.exp.
---
 gdb/testsuite/lib/gdb.exp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 87f0a36fe7..402450152a 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -4473,6 +4473,8 @@ proc gdb_compile {source dest type options} {
     # Place (and look for) Fortran `.mod` files in the output
     # directory for this specific test.  For Intel compilers the -J
     # option is not supported so instead use the -module flag.
+    # Additionally, Intel compilers need the -debug-parameters flag set to
+    # emit debug info for all parameters in modules.
     if { !$getting_compiler_info && [lsearch -exact $options f90] != -1 } {
 	# Fortran compile.
 	set mod_path [standard_output_file ""]
@@ -4481,6 +4483,7 @@ proc gdb_compile {source dest type options} {
 	} elseif { [test_compiler_info {ifort-*} f90]
 		   || [test_compiler_info {ifx-*} f90] } {
 	    lappend new_options "additional_flags=-module ${mod_path}"
+	    lappend new_options "additional_flags=-debug-parameters all"
 	}
     }
 
-- 
2.25.1

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

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

[Nils-Christian Kempke]

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;(" \
 	 ".*)?"]
-- 
2.25.1

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

[PATCH v2 16/16] gdb/testsuite: fixup common-block.exp for intel compilers

[Nils-Christian Kempke]

The order in which the variables in info common and info locals are
displayed is compiler (and dwarf) dependent.  While all symbols should
be displayed the order is not fixed.

I added a gdb_test_multiple that lets ifx and ifort pass in cases where
only the order differs.
---
 gdb/testsuite/gdb.fortran/common-block.exp | 38 ++++++++++++++++++++--
 1 file changed, 35 insertions(+), 3 deletions(-)

diff --git a/gdb/testsuite/gdb.fortran/common-block.exp b/gdb/testsuite/gdb.fortran/common-block.exp
index e6555f536d..e8d7c22213 100644
--- a/gdb/testsuite/gdb.fortran/common-block.exp
+++ b/gdb/testsuite/gdb.fortran/common-block.exp
@@ -54,8 +54,27 @@ gdb_test "whatis fo_o$suffix" "No symbol \"fo_o$suffix\" in current context."
 gdb_test "ptype fo_o$suffix" "No symbol \"fo_o$suffix\" in current context."
 gdb_test "p fo_o$suffix" "No symbol \"fo_o$suffix\" in current context."
 
-gdb_test "info locals" "ix_x = 11\r\niy_y = 22\r\niz_z = 33\r\nix = 1\r\niy = 2\r\niz = 3" "info locals out"
-gdb_test "info common" "Contents of F77 COMMON block 'fo_o':\r\nix_x = 11\r\niy_y = 22\r\niz_z = 33\r\n\r\nContents of F77 COMMON block 'foo':\r\nix = 1\r\niy = 2\r\niz = 3" "info common out"
+gdb_test_multiple "info locals" "info locals out" {
+    # gfortran
+    -re -wrap "ix_x = 11\r\niy_y = 22\r\niz_z = 33\r\nix = 1\r\niy = 2\r\niz = 3" {
+	pass $gdb_test_name
+    }
+    # ifx/ifort/flang
+    -re -wrap "ix = 1\r\niy = 2\r\niz = 3\r\nix_x = 11\r\niy_y = 22\r\niz_z = 33" {
+	pass $gdb_test_name
+    }
+}
+
+gdb_test_multiple "info common" "info common out" {
+    # gfortran
+    -re -wrap "Contents of F77 COMMON block 'fo_o':\r\nix_x = 11\r\niy_y = 22\r\niz_z = 33\r\n\r\nContents of F77 COMMON block 'foo':\r\nix = 1\r\niy = 2\r\niz = 3" {
+	pass $gdb_test_name
+    }
+    # ifx/ifort/flang
+    -re -wrap "Contents of F77 COMMON block 'foo_?':\r\nix = 1\r\niy = 2\r\niz = 3\r\n\r\nContents of F77 COMMON block 'fo_o_?':\r\nix_x = 11\r\niy_y = 22\r\niz_z = 33" {
+	pass $gdb_test_name
+    }
+}
 
 gdb_test "ptype ix" "type = $int4" "ptype ix out"
 gdb_test "ptype iy" "type = $real4" "ptype iy out"
@@ -81,7 +100,20 @@ gdb_test "whatis fo_o$suffix" "No symbol \"fo_o$suffix\" in current context." "w
 gdb_test "ptype fo_o$suffix" "No symbol \"fo_o$suffix\" in current context." "ptype fo_o$suffix in"
 gdb_test "p fo_o$suffix" "No symbol \"fo_o$suffix\" in current context." "p fo_o$suffix in"
 
-gdb_test "info locals" "ix = 11\r\niy2 = 22\r\niz = 33\r\nix_x = 1\r\niy_y = 2\r\niz_z2 = 3\r\niy = 5\r\niz_z = 55" "info locals in"
+gdb_test_multiple "info locals" "info locals in" {
+    # gfortran
+    -re -wrap "ix = 11\r\niy2 = 22\r\niz = 33\r\nix_x = 1\r\niy_y = 2\r\niz_z2 = 3\r\niy = 5\r\niz_z = 55" {
+	pass $gdb_test_name
+    }
+    # ifx
+    -re -wrap "ix = 11\r\niy2 = 22\r\niz = 33\r\nix_x = 1\r\niy_y = 2\r\niz_z2 = 3\r\niz_z = 55\r\niy = 5" {
+	pass $gdb_test_name
+    }
+    # ifort
+    -re -wrap "iz_z = 55\r\niy = 5\r\nix = 11\r\niy2 = 22\r\niz = 33\r\nix_x = 1\r\niy_y = 2\r\niz_z2 = 3" {
+	pass $gdb_test_name
+    }
+}
 gdb_test "info common" "Contents of F77 COMMON block 'fo_o':\r\nix = 11\r\niy2 = 22\r\niz = 33\r\n\r\nContents of F77 COMMON block 'foo':\r\nix_x = 1\r\niy_y = 2\r\niz_z2 = 3" "info common in"
 
 gdb_test "ptype ix" "type = $int4" "ptype ix in"
-- 
2.25.1

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [PATCH v2 03/16] gdb/testsuite: Fix fortran types for Intel compilers.

[Andrew Burgess]

Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org>
writes:

> From: Felix Willgerodt <felix.willgerodt@intel.com>
>
> Newer Intel compilers emit their dwarf type name in a slightly different
> format.  Therefore, this needs adjustment to make more tests pass in the
> Fortran testsuite.
>
> Co-authored-by: Abdul Basit Ijaz <abdul.b.ijaz@intel.com>
> Co-authored-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
> ---
>  gdb/testsuite/lib/fortran.exp | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)

LGTM.

Thanks,
Andrew

>
> diff --git a/gdb/testsuite/lib/fortran.exp b/gdb/testsuite/lib/fortran.exp
> index a97c6eeb4e..9531d393a1 100644
> --- a/gdb/testsuite/lib/fortran.exp
> +++ b/gdb/testsuite/lib/fortran.exp
> @@ -38,6 +38,8 @@ proc fortran_int4 {} {
>  	return "integer"
>      } elseif {[test_compiler_info {icc-*}]} {
>  	return "INTEGER\\(4\\)"
> +    } elseif {[test_compiler_info {intel-*}]} {
> +	return "INTEGER\\*4"
>      } else {
>  	return "unknown"
>      }
> @@ -52,6 +54,8 @@ proc fortran_int8 {} {
>  	return "integer\\*8"
>      } elseif {[test_compiler_info {icc-*}]} {
>  	return "INTEGER\\(8\\)"
> +    } elseif {[test_compiler_info {intel-*}]} {
> +	return "INTEGER\\*8"
>      } else {
>  	return "unknown"
>      }
> @@ -66,6 +70,8 @@ proc fortran_real4 {} {
>  	return "real"
>      } elseif {[test_compiler_info {icc-*}]} {
>  	return "REAL\\(4\\)"
> +    } elseif {[test_compiler_info {intel-*}]} {
> +	return "REAL\\*4"
>      } else {
>  	return "unknown"
>      }
> @@ -80,6 +86,8 @@ proc fortran_real8 {} {
>  	return "double precision"
>      } elseif {[test_compiler_info {icc-*}]} {
>  	return "REAL\\(8\\)"
> +    } elseif {[test_compiler_info {intel-*}]} {
> +	return "REAL\\*8"
>      } else {
>  	return "unknown"
>      }
> @@ -94,6 +102,8 @@ proc fortran_complex4 {} {
>  	return "complex"
>      } elseif {[test_compiler_info {icc-*}]} {
>  	return "COMPLEX\\(4\\)"
> +    } elseif {[test_compiler_info {intel-*}]} {
> +	return "COMPLEX\\*8"
>      } else {
>  	return "unknown"
>      }
> @@ -108,6 +118,8 @@ proc fortran_complex8 {} {
>  	return "double complex"
>      } elseif {[test_compiler_info {icc-*}]} {
>  	return "COMPLEX\\(8\\)"
> +    } elseif {[test_compiler_info {intel-*}]} {
> +	return "COMPLEX\\*16"
>      } else {
>  	return "unknown"
>      }
> @@ -122,6 +134,8 @@ proc fortran_complex16 {} {
>  	return "quad complex"
>      } elseif {[test_compiler_info {icc-*}]} {
>  	return "COMPLEX\\(16\\)"
> +    } elseif {[test_compiler_info {intel-*}]} {
> +	return "COMPLEX\\*32"
>      } else {
>  	return "unknown"
>      }
> @@ -136,6 +150,8 @@ proc fortran_logical4 {} {
>  	return "logical"
>      } elseif {[test_compiler_info {icc-*}]} {
>  	return "LOGICAL\\(4\\)"
> +    } elseif {[test_compiler_info {intel-*}]} {
> +	return "LOGICAL\\*4"
>      } else {
>  	return "unknown"
>      }
> @@ -150,6 +166,8 @@ proc fortran_character1 {} {
>  	return "character"
>      } elseif {[test_compiler_info {icc-*}]} {
>  	return "CHARACTER\\(1\\)"
> +    } elseif {[test_compiler_info {intel-*}]} {
> +	return "CHARACTER\\*1"
>      } else {
>  	return "unknown"
>      }
> -- 
> 2.25.1
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [PATCH v2 06/16] gdb/testsuite: rename intel next gen c/cpp compilers

[Andrew Burgess]

Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org>
writes:

> The name for icx and icpx in the testsuite was earlier set to 'intel-*'
> by the compiler identification.  This commit changes this to 'icx-*'.
>
> Note, that currently these names are not used within the testsuite so no
> tests have to be adapted here.

LGTM.

Thanks,
Andrew

> ---
>  gdb/testsuite/lib/compiler.c  | 2 +-
>  gdb/testsuite/lib/compiler.cc | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gdb/testsuite/lib/compiler.c b/gdb/testsuite/lib/compiler.c
> index 451cae3831..86140f8c0e 100644
> --- a/gdb/testsuite/lib/compiler.c
> +++ b/gdb/testsuite/lib/compiler.c
> @@ -75,5 +75,5 @@ set total_length [string length __clang_version__]
>  set version_start_index [string last "(" __clang_version__]
>  set version_string [string range __clang_version__ $version_start_index+5 $total_length-2]
>  set version_updated_string [string map {. -} $version_string]
> -set compiler_info "intel-$version_updated_string"
> +set compiler_info "icx-$version_updated_string"
>  #endif
> diff --git a/gdb/testsuite/lib/compiler.cc b/gdb/testsuite/lib/compiler.cc
> index 1dfefee057..a52e81c2e3 100755
> --- a/gdb/testsuite/lib/compiler.cc
> +++ b/gdb/testsuite/lib/compiler.cc
> @@ -63,5 +63,5 @@ set total_length [string length __clang_version__]
>  set version_start_index [string last "(" __clang_version__]
>  set version_string [string range __clang_version__ $version_start_index+5 $total_length-2]
>  set version_updated_string [string map {. -} $version_string]
> -set compiler_info "intel-$version_updated_string"
> +set compiler_info "icx-$version_updated_string"
>  #endif
> -- 
> 2.25.1
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928

RE: [PATCH v2 03/16] gdb/testsuite: Fix fortran types for Intel compilers.

[Kempke, Nils-Christian]

Hi Andrew,

thanks for reviewing.

I might have pushed this series by mistake - I saw your comment and somehow read it as a comment for the whole series (v2)..

Sorry for that .. We should likely revert it in this case and finish the reviewing first...


Best,
Nils

> -----Original Message-----
> From: Andrew Burgess <aburgess@redhat.com>
> Sent: Tuesday, May 31, 2022 4:16 PM
> To: Kempke, Nils-Christian <nils-christian.kempke@intel.com>; gdb-
> patches@sourceware.org
> Cc: JiniSusan.George@amd.com; Ijaz, Abdul B <abdul.b.ijaz@intel.com>
> Subject: Re: [PATCH v2 03/16] gdb/testsuite: Fix fortran types for Intel
> compilers.
> 
> Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org>
> writes:
> 
> > From: Felix Willgerodt <felix.willgerodt@intel.com>
> >
> > Newer Intel compilers emit their dwarf type name in a slightly different
> > format.  Therefore, this needs adjustment to make more tests pass in the
> > Fortran testsuite.
> >
> > Co-authored-by: Abdul Basit Ijaz <abdul.b.ijaz@intel.com>
> > Co-authored-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
> > ---
> >  gdb/testsuite/lib/fortran.exp | 18 ++++++++++++++++++
> >  1 file changed, 18 insertions(+)
> 
> LGTM.
> 
> Thanks,
> Andrew
> 
> >
> > diff --git a/gdb/testsuite/lib/fortran.exp b/gdb/testsuite/lib/fortran.exp
> > index a97c6eeb4e..9531d393a1 100644
> > --- a/gdb/testsuite/lib/fortran.exp
> > +++ b/gdb/testsuite/lib/fortran.exp
> > @@ -38,6 +38,8 @@ proc fortran_int4 {} {
> >  	return "integer"
> >      } elseif {[test_compiler_info {icc-*}]} {
> >  	return "INTEGER\\(4\\)"
> > +    } elseif {[test_compiler_info {intel-*}]} {
> > +	return "INTEGER\\*4"
> >      } else {
> >  	return "unknown"
> >      }
> > @@ -52,6 +54,8 @@ proc fortran_int8 {} {
> >  	return "integer\\*8"
> >      } elseif {[test_compiler_info {icc-*}]} {
> >  	return "INTEGER\\(8\\)"
> > +    } elseif {[test_compiler_info {intel-*}]} {
> > +	return "INTEGER\\*8"
> >      } else {
> >  	return "unknown"
> >      }
> > @@ -66,6 +70,8 @@ proc fortran_real4 {} {
> >  	return "real"
> >      } elseif {[test_compiler_info {icc-*}]} {
> >  	return "REAL\\(4\\)"
> > +    } elseif {[test_compiler_info {intel-*}]} {
> > +	return "REAL\\*4"
> >      } else {
> >  	return "unknown"
> >      }
> > @@ -80,6 +86,8 @@ proc fortran_real8 {} {
> >  	return "double precision"
> >      } elseif {[test_compiler_info {icc-*}]} {
> >  	return "REAL\\(8\\)"
> > +    } elseif {[test_compiler_info {intel-*}]} {
> > +	return "REAL\\*8"
> >      } else {
> >  	return "unknown"
> >      }
> > @@ -94,6 +102,8 @@ proc fortran_complex4 {} {
> >  	return "complex"
> >      } elseif {[test_compiler_info {icc-*}]} {
> >  	return "COMPLEX\\(4\\)"
> > +    } elseif {[test_compiler_info {intel-*}]} {
> > +	return "COMPLEX\\*8"
> >      } else {
> >  	return "unknown"
> >      }
> > @@ -108,6 +118,8 @@ proc fortran_complex8 {} {
> >  	return "double complex"
> >      } elseif {[test_compiler_info {icc-*}]} {
> >  	return "COMPLEX\\(8\\)"
> > +    } elseif {[test_compiler_info {intel-*}]} {
> > +	return "COMPLEX\\*16"
> >      } else {
> >  	return "unknown"
> >      }
> > @@ -122,6 +134,8 @@ proc fortran_complex16 {} {
> >  	return "quad complex"
> >      } elseif {[test_compiler_info {icc-*}]} {
> >  	return "COMPLEX\\(16\\)"
> > +    } elseif {[test_compiler_info {intel-*}]} {
> > +	return "COMPLEX\\*32"
> >      } else {
> >  	return "unknown"
> >      }
> > @@ -136,6 +150,8 @@ proc fortran_logical4 {} {
> >  	return "logical"
> >      } elseif {[test_compiler_info {icc-*}]} {
> >  	return "LOGICAL\\(4\\)"
> > +    } elseif {[test_compiler_info {intel-*}]} {
> > +	return "LOGICAL\\*4"
> >      } else {
> >  	return "unknown"
> >      }
> > @@ -150,6 +166,8 @@ proc fortran_character1 {} {
> >  	return "character"
> >      } elseif {[test_compiler_info {icc-*}]} {
> >  	return "CHARACTER\\(1\\)"
> > +    } elseif {[test_compiler_info {intel-*}]} {
> > +	return "CHARACTER\\*1"
> >      } else {
> >  	return "unknown"
> >      }
> > --
> > 2.25.1
> >
> > Intel Deutschland GmbH
> > Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> > Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
> > Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
> > Chairperson of the Supervisory Board: Nicole Lau
> > Registered Office: Munich
> > Commercial Register: Amtsgericht Muenchen HRB 186928

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [PATCH v2 04/16] gdb/testsuite: move getting_compiler_info to front of gdb_compile

[Andrew Burgess]

Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org>
writes:

> The procedure gdb_compile queries its options via
>
>    [lsearch -exact $options getting_compiler_info]
>
> to check whether or not it was called in with the option
> getting_compiler_info.  If it was called with this option it would
> preprocess some test input to try and figure out the actual compiler
> version of the compiler used.  While doing this we cannot again try to
> figure out the current compiler version via the 'getting_compiler_info'
> option as this would cause infinite recursion.  As some parts of the
> procedure do recursively test for the compiler version to e.g. set
> certain flags, at several places gdb_compile there are checks for the
> getting_compiler_info option needed.
>
> In the procedure, there was already a variable 'getting_compiler_info'
> which was set to the result of the 'lsearch' query and used instead of
> again and again looking for getting_compiler_info in the procedure
> options.  But, this variable was actually set too late within the code.
> This lead to a mixture of querying 'getting_compiler_info' or
> doing an lserach on the options passed to the procedure.
>
> I found this inconsistent and instead moved the variable
> getting_compiler_info to the front of the procedure.  It is set to true
> or false depending on whether or not the argument is found in the
> procedure's options (just as before) and queried instead of doing an
> lsearch on the procedure options in the rest of the procedure.

LGTM.

Thanks,
Andrew

> ---
>  gdb/testsuite/lib/gdb.exp | 21 ++++++++++++++-------
>  1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
> index 6fbf74442c..381367ee6c 100644
> --- a/gdb/testsuite/lib/gdb.exp
> +++ b/gdb/testsuite/lib/gdb.exp
> @@ -4412,6 +4412,13 @@ proc gdb_compile {source dest type options} {
>  
>      set outdir [file dirname $dest]
>  
> +    # If this is set, calling test_compiler_info will cause recursion.
> +    if { [lsearch -exact $options getting_compiler_info] == -1 } {
> +	set getting_compiler_info false
> +    } else {
> +	set getting_compiler_info true
> +    }
> +
>      # Add platform-specific options if a shared library was specified using
>      # "shlib=librarypath" in OPTIONS.
>      set new_options {}
> @@ -4428,7 +4435,7 @@ proc gdb_compile {source dest type options} {
>      # default, unless you pass -Wno-unknown-warning-option as well.
>      # We do that here, so that individual testcases don't have to
>      # worry about it.
> -    if {[lsearch -exact $options getting_compiler_info] == -1
> +    if {!$getting_compiler_info
>  	&& [lsearch -exact $options rust] == -1
>  	&& [lsearch -exact $options ada] == -1
>  	&& [lsearch -exact $options f90] == -1
> @@ -4439,7 +4446,7 @@ proc gdb_compile {source dest type options} {
>  
>      # Treating .c input files as C++ is deprecated in Clang, so
>      # explicitly force C++ language.
> -    if { [lsearch -exact $options getting_compiler_info] == -1
> +    if { !$getting_compiler_info
>  	 && [lsearch -exact $options c++] != -1
>  	 && [string match *.c $source] != 0 } {
>  
> @@ -4460,7 +4467,7 @@ proc gdb_compile {source dest type options} {
>      # Place (and look for) Fortran `.mod` files in the output
>      # directory for this specific test.  For Intel compilers the -J
>      # option is not supported so instead use the -module flag.
> -    if { [lsearch -exact $options f90] != -1 } {
> +    if { !$getting_compiler_info && [lsearch -exact $options f90] != -1 } {
>  	# Fortran compile.
>  	set mod_path [standard_output_file ""]
>  	if [test_compiler_info "gcc-*"] {
> @@ -4473,7 +4480,6 @@ proc gdb_compile {source dest type options} {
>  
>      set shlib_found 0
>      set shlib_load 0
> -    set getting_compiler_info 0
>      foreach opt $options {
>          if {[regexp {^shlib=(.*)} $opt dummy_var shlib_name]
>  	    && $type == "executable"} {
> @@ -4505,8 +4511,9 @@ proc gdb_compile {source dest type options} {
>  	} elseif { $opt == "shlib_load" && $type == "executable" } {
>  	    set shlib_load 1
>  	} elseif { $opt == "getting_compiler_info" } {
> -	    # If this is set, calling test_compiler_info will cause recursion.
> -	    set getting_compiler_info 1
> +	    # Ignore this setting here as it has been handled earlier in this
> +	    # procedure.  Do not append it to new_options as this will cause
> +	    # recursion.
>          } elseif {[regexp "^text_segment=(.*)" $opt dummy_var addr]} {
>              if { [linker_supports_Ttext_segment_flag] } {
>                  # For GNU ld.
> @@ -4529,7 +4536,7 @@ proc gdb_compile {source dest type options} {
>      # DWARF line numbering.
>      # See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88432
>      # This option defaults to on for Debian/Ubuntu.
> -    if { $getting_compiler_info == 0
> +    if { !$getting_compiler_info
>  	 && [test_compiler_info {gcc-*-*}]
>  	 && !([test_compiler_info {gcc-[0-3]-*}]
>  	      || [test_compiler_info {gcc-4-0-*}])
> -- 
> 2.25.1
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [PATCH v2 10/16] testsuite, fortran: Add '-debug-parameters all' when using ifx/ifort

[Andrew Burgess]

Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org>
writes:

> In order for ifx and ifort to emit all debug entries, even for unused
> parameters in modules we have to define the '-debug-parameters all' flag.
>
> This commit adds it to the ifx-*/ifort-* specific flags in gdb.exp.

LGTM.

Thanks,
Andrew


> ---
>  gdb/testsuite/lib/gdb.exp | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
> index 87f0a36fe7..402450152a 100644
> --- a/gdb/testsuite/lib/gdb.exp
> +++ b/gdb/testsuite/lib/gdb.exp
> @@ -4473,6 +4473,8 @@ proc gdb_compile {source dest type options} {
>      # Place (and look for) Fortran `.mod` files in the output
>      # directory for this specific test.  For Intel compilers the -J
>      # option is not supported so instead use the -module flag.
> +    # Additionally, Intel compilers need the -debug-parameters flag set to
> +    # emit debug info for all parameters in modules.
>      if { !$getting_compiler_info && [lsearch -exact $options f90] != -1 } {
>  	# Fortran compile.
>  	set mod_path [standard_output_file ""]
> @@ -4481,6 +4483,7 @@ proc gdb_compile {source dest type options} {
>  	} elseif { [test_compiler_info {ifort-*} f90]
>  		   || [test_compiler_info {ifx-*} f90] } {
>  	    lappend new_options "additional_flags=-module ${mod_path}"
> +	    lappend new_options "additional_flags=-debug-parameters all"
>  	}
>      }
>  
> -- 
> 2.25.1
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928

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

[Andrew Burgess]

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

Re: [PATCH v2 16/16] gdb/testsuite: fixup common-block.exp for intel compilers

[Andrew Burgess]

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

> The order in which the variables in info common and info locals are
> displayed is compiler (and dwarf) dependent.  While all symbols should
> be displayed the order is not fixed.
>
> I added a gdb_test_multiple that lets ifx and ifort pass in cases where
> only the order differs.

LGTM.

Thanks,
Andrew

> ---
>  gdb/testsuite/gdb.fortran/common-block.exp | 38 ++++++++++++++++++++--
>  1 file changed, 35 insertions(+), 3 deletions(-)
>
> diff --git a/gdb/testsuite/gdb.fortran/common-block.exp b/gdb/testsuite/gdb.fortran/common-block.exp
> index e6555f536d..e8d7c22213 100644
> --- a/gdb/testsuite/gdb.fortran/common-block.exp
> +++ b/gdb/testsuite/gdb.fortran/common-block.exp
> @@ -54,8 +54,27 @@ gdb_test "whatis fo_o$suffix" "No symbol \"fo_o$suffix\" in current context."
>  gdb_test "ptype fo_o$suffix" "No symbol \"fo_o$suffix\" in current context."
>  gdb_test "p fo_o$suffix" "No symbol \"fo_o$suffix\" in current context."
>  
> -gdb_test "info locals" "ix_x = 11\r\niy_y = 22\r\niz_z = 33\r\nix = 1\r\niy = 2\r\niz = 3" "info locals out"
> -gdb_test "info common" "Contents of F77 COMMON block 'fo_o':\r\nix_x = 11\r\niy_y = 22\r\niz_z = 33\r\n\r\nContents of F77 COMMON block 'foo':\r\nix = 1\r\niy = 2\r\niz = 3" "info common out"
> +gdb_test_multiple "info locals" "info locals out" {
> +    # gfortran
> +    -re -wrap "ix_x = 11\r\niy_y = 22\r\niz_z = 33\r\nix = 1\r\niy = 2\r\niz = 3" {
> +	pass $gdb_test_name
> +    }
> +    # ifx/ifort/flang
> +    -re -wrap "ix = 1\r\niy = 2\r\niz = 3\r\nix_x = 11\r\niy_y = 22\r\niz_z = 33" {
> +	pass $gdb_test_name
> +    }
> +}
> +
> +gdb_test_multiple "info common" "info common out" {
> +    # gfortran
> +    -re -wrap "Contents of F77 COMMON block 'fo_o':\r\nix_x = 11\r\niy_y = 22\r\niz_z = 33\r\n\r\nContents of F77 COMMON block 'foo':\r\nix = 1\r\niy = 2\r\niz = 3" {
> +	pass $gdb_test_name
> +    }
> +    # ifx/ifort/flang
> +    -re -wrap "Contents of F77 COMMON block 'foo_?':\r\nix = 1\r\niy = 2\r\niz = 3\r\n\r\nContents of F77 COMMON block 'fo_o_?':\r\nix_x = 11\r\niy_y = 22\r\niz_z = 33" {
> +	pass $gdb_test_name
> +    }
> +}
>  
>  gdb_test "ptype ix" "type = $int4" "ptype ix out"
>  gdb_test "ptype iy" "type = $real4" "ptype iy out"
> @@ -81,7 +100,20 @@ gdb_test "whatis fo_o$suffix" "No symbol \"fo_o$suffix\" in current context." "w
>  gdb_test "ptype fo_o$suffix" "No symbol \"fo_o$suffix\" in current context." "ptype fo_o$suffix in"
>  gdb_test "p fo_o$suffix" "No symbol \"fo_o$suffix\" in current context." "p fo_o$suffix in"
>  
> -gdb_test "info locals" "ix = 11\r\niy2 = 22\r\niz = 33\r\nix_x = 1\r\niy_y = 2\r\niz_z2 = 3\r\niy = 5\r\niz_z = 55" "info locals in"
> +gdb_test_multiple "info locals" "info locals in" {
> +    # gfortran
> +    -re -wrap "ix = 11\r\niy2 = 22\r\niz = 33\r\nix_x = 1\r\niy_y = 2\r\niz_z2 = 3\r\niy = 5\r\niz_z = 55" {
> +	pass $gdb_test_name
> +    }
> +    # ifx
> +    -re -wrap "ix = 11\r\niy2 = 22\r\niz = 33\r\nix_x = 1\r\niy_y = 2\r\niz_z2 = 3\r\niz_z = 55\r\niy = 5" {
> +	pass $gdb_test_name
> +    }
> +    # ifort
> +    -re -wrap "iz_z = 55\r\niy = 5\r\nix = 11\r\niy2 = 22\r\niz = 33\r\nix_x = 1\r\niy_y = 2\r\niz_z2 = 3" {
> +	pass $gdb_test_name
> +    }
> +}
>  gdb_test "info common" "Contents of F77 COMMON block 'fo_o':\r\nix = 11\r\niy2 = 22\r\niz = 33\r\n\r\nContents of F77 COMMON block 'foo':\r\nix_x = 1\r\niy_y = 2\r\niz_z2 = 3" "info common in"
>  
>  gdb_test "ptype ix" "type = $int4" "ptype ix in"
> -- 
> 2.25.1
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [PATCH v2 00/16] Fortran compiler identification and ifx testsuite support

[Andrew Burgess]

Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org>
writes:

> Hi,
>
> V1 of this series can be found here:
>
>   https://sourceware.org/pipermail/gdb-patches/2022-May/188904.html
>
> Changes since v1:
>
>   * Patch 03: There were some leftovers in the commit message from an
>   earlier version of the patch - these have been removed.
>
>   * Patch 04: The commit message has been renamed and a comment been
>   adapted according to Andrew's feedback.  The getting_compiler_info
>   variable now also uses actual bool values.
>
>   * Patch 06: The commit message has been adapted and now says that
>   the intel C compiler names have not yet been used in the testsuite (to
>   avoid confusion as to why there are no changes done in the testsuite).
>
>   * Patch 08: This patch has been dropped, instead an ifx bug was filed.
>   So from now on the patch numbers will be off by 1.
>
>   * Patch 11 (now 10): The comment has been reworded and
>     'need the -debug-parameters all flag set to emit'
>   now reads
>     'need the -debug-parameters flag set to emit' 
>   Also, not only ifx but also ifort requires the flag so it is now added
>   for both compilers.
>
>   * Patch 13 (now 12): I added a comment to the patch as well as made
>   the commit message a lot more elaborate (after some online
>   discussion).
>
>   * Patch 14: This patch has been dropped for now as we are claifying
>   whether ifx should change its debug output.  The patch numbers will
>   now be off by 2. 
>
>   * Patch 18 (now 16): The '-wrap' is now used here instead of adding
>   the $gdb_prompt in test_multiple.  Also, flang was added to the
>   comments.
>
> Patch 01, 02, 05, 07, 09 (now 08), 10 (now 09), 12 (now 11), 15 (now 13),
> 16 (now 14), and 17 (now 15) had been approved before and were not
> changed/included here.

I've approved all these patches now.

For me I would have preferred to see the complete set of patches
included each time the series is reposted, it makes it easier to apply
the patches.  Though I do also appreciate you commenting about which
patches have changed, and what the changes were.

Thanks,
Andrew


>
> I am happy about any feedback.
>
> Cheers,
>
> Nils
>
> Abdul Basit Ijaz (1):
>   gdb/testsuite: Use -module option for Intel Fortran compilers
>
> Cristian Sandu (1):
>   gdb/testsuite: add Fortran compiler identification to GDB
>
> Felix Willgerodt (1):
>   gdb/testsuite: Fix fortran types for Intel compilers.
>
> Nils-Christian Kempke (13):
>   gdb/testsuite: remove F77_FOR_TARGET support
>   gdb/testsuite: move getting_compiler_info to front of gdb_compile
>   gdb/testsuite: rename intel next gen c/cpp compilers
>   gdb/testsuite: disable charset.exp for intel compilers
>   testsuite, fortran: add required external keyword
>   testsuite, fortran: add compiler dependent types to
>     dynamic-ptype-whatis
>   testsuite, fortran: Add '-debug-parameters all' when using ifx/ifort
>   testsuite/lib: add check_optional_entry for GDBInfoSymbols
>   testsuite, fortran: fix info-types for intel compilers
>   testsuite, fortran: allow additional completions in module.exp
>   gdb, testsuite, fortran: fix double free in mixed-lang-stack.exp
>   gdb, testsuite, fortran: fixup mixed-lang-stack for Intel/LLVM
>     compilers
>   gdb/testsuite: fixup common-block.exp for intel compilers
>
>  gdb/testsuite/boards/cc-with-tweaks.exp       |   5 -
>  gdb/testsuite/boards/debug-types.exp          |   1 -
>  gdb/testsuite/boards/gold-gdb-index.exp       |   1 -
>  gdb/testsuite/gdb.fortran/assumedrank.exp     |   6 +-
>  gdb/testsuite/gdb.fortran/charset.exp         |   5 +
>  .../gdb.fortran/class-allocatable-array.exp   |   4 +-
>  gdb/testsuite/gdb.fortran/common-block.exp    |  38 ++++++-
>  .../gdb.fortran/derived-type-striding.exp     |   2 +-
>  .../gdb.fortran/dynamic-ptype-whatis.exp      |  79 +++++++-------
>  gdb/testsuite/gdb.fortran/function-calls.f90  |   1 +
>  gdb/testsuite/gdb.fortran/info-types.exp      |  20 +++-
>  gdb/testsuite/gdb.fortran/library-module.exp  |   2 +-
>  .../gdb.fortran/mixed-lang-stack.cpp          |  12 +--
>  .../gdb.fortran/mixed-lang-stack.exp          |  21 ++--
>  gdb/testsuite/gdb.fortran/module.exp          |   5 +-
>  gdb/testsuite/gdb.fortran/namelist.exp        |   2 +-
>  gdb/testsuite/gdb.fortran/nested-funcs-2.exp  |   3 +-
>  .../gdb.fortran/ptype-on-functions.exp        |   6 +-
>  gdb/testsuite/gdb.fortran/vla-type.exp        |   2 +-
>  gdb/testsuite/lib/compiler.F90                |  69 ++++++++++++
>  gdb/testsuite/lib/compiler.c                  |   2 +-
>  gdb/testsuite/lib/compiler.cc                 |   2 +-
>  gdb/testsuite/lib/fortran.exp                 | 100 +++++++++++-------
>  gdb/testsuite/lib/future.exp                  |  21 +---
>  gdb/testsuite/lib/gdb.exp                     |  62 +++++++----
>  gdb/testsuite/lib/sym-info-cmds.exp           |  18 +++-
>  26 files changed, 318 insertions(+), 171 deletions(-)
>  create mode 100644 gdb/testsuite/lib/compiler.F90
>
> -- 
> 2.25.1
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928

RE: [PATCH v2 00/16] Fortran compiler identification and ifx testsuite support

[Kempke, Nils-Christian]

> -----Original Message-----
> From: Andrew Burgess <aburgess@redhat.com>
> Sent: Tuesday, May 31, 2022 6:14 PM
> To: Kempke, Nils-Christian <nils-christian.kempke@intel.com>; gdb-
> patches@sourceware.org
> Cc: JiniSusan.George@amd.com
> Subject: Re: [PATCH v2 00/16] Fortran compiler identification and ifx testsuite
> support
> 
> Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org>
> writes:
> 
> > Hi,
> >
> > V1 of this series can be found here:
> >
> >   https://sourceware.org/pipermail/gdb-patches/2022-May/188904.html
> >
> > Changes since v1:
> >
> >   * Patch 03: There were some leftovers in the commit message from an
> >   earlier version of the patch - these have been removed.
> >
> >   * Patch 04: The commit message has been renamed and a comment been
> >   adapted according to Andrew's feedback.  The getting_compiler_info
> >   variable now also uses actual bool values.
> >
> >   * Patch 06: The commit message has been adapted and now says that
> >   the intel C compiler names have not yet been used in the testsuite (to
> >   avoid confusion as to why there are no changes done in the testsuite).
> >
> >   * Patch 08: This patch has been dropped, instead an ifx bug was filed.
> >   So from now on the patch numbers will be off by 1.
> >
> >   * Patch 11 (now 10): The comment has been reworded and
> >     'need the -debug-parameters all flag set to emit'
> >   now reads
> >     'need the -debug-parameters flag set to emit'
> >   Also, not only ifx but also ifort requires the flag so it is now added
> >   for both compilers.
> >
> >   * Patch 13 (now 12): I added a comment to the patch as well as made
> >   the commit message a lot more elaborate (after some online
> >   discussion).
> >
> >   * Patch 14: This patch has been dropped for now as we are claifying
> >   whether ifx should change its debug output.  The patch numbers will
> >   now be off by 2.
> >
> >   * Patch 18 (now 16): The '-wrap' is now used here instead of adding
> >   the $gdb_prompt in test_multiple.  Also, flang was added to the
> >   comments.
> >
> > Patch 01, 02, 05, 07, 09 (now 08), 10 (now 09), 12 (now 11), 15 (now 13),
> > 16 (now 14), and 17 (now 15) had been approved before and were not
> > changed/included here.
> 
> I've approved all these patches now.
> 
> For me I would have preferred to see the complete set of patches
> included each time the series is reposted, it makes it easier to apply
> the patches.  Though I do also appreciate you commenting about which
> patches have changed, and what the changes were.
> 
> Thanks,
> Andrew

Thanks for the review!

I see, yes.. - I remember someone telling me that I need not resubmit some patches,
so I thought this was the standard way.

I'll submit the whole series again next time.

Thanks again,

Nils
 
> 
> 
> >
> > I am happy about any feedback.
> >
> > Cheers,
> >
> > Nils
> >
> > Abdul Basit Ijaz (1):
> >   gdb/testsuite: Use -module option for Intel Fortran compilers
> >
> > Cristian Sandu (1):
> >   gdb/testsuite: add Fortran compiler identification to GDB
> >
> > Felix Willgerodt (1):
> >   gdb/testsuite: Fix fortran types for Intel compilers.
> >
> > Nils-Christian Kempke (13):
> >   gdb/testsuite: remove F77_FOR_TARGET support
> >   gdb/testsuite: move getting_compiler_info to front of gdb_compile
> >   gdb/testsuite: rename intel next gen c/cpp compilers
> >   gdb/testsuite: disable charset.exp for intel compilers
> >   testsuite, fortran: add required external keyword
> >   testsuite, fortran: add compiler dependent types to
> >     dynamic-ptype-whatis
> >   testsuite, fortran: Add '-debug-parameters all' when using ifx/ifort
> >   testsuite/lib: add check_optional_entry for GDBInfoSymbols
> >   testsuite, fortran: fix info-types for intel compilers
> >   testsuite, fortran: allow additional completions in module.exp
> >   gdb, testsuite, fortran: fix double free in mixed-lang-stack.exp
> >   gdb, testsuite, fortran: fixup mixed-lang-stack for Intel/LLVM
> >     compilers
> >   gdb/testsuite: fixup common-block.exp for intel compilers
> >
> >  gdb/testsuite/boards/cc-with-tweaks.exp       |   5 -
> >  gdb/testsuite/boards/debug-types.exp          |   1 -
> >  gdb/testsuite/boards/gold-gdb-index.exp       |   1 -
> >  gdb/testsuite/gdb.fortran/assumedrank.exp     |   6 +-
> >  gdb/testsuite/gdb.fortran/charset.exp         |   5 +
> >  .../gdb.fortran/class-allocatable-array.exp   |   4 +-
> >  gdb/testsuite/gdb.fortran/common-block.exp    |  38 ++++++-
> >  .../gdb.fortran/derived-type-striding.exp     |   2 +-
> >  .../gdb.fortran/dynamic-ptype-whatis.exp      |  79 +++++++-------
> >  gdb/testsuite/gdb.fortran/function-calls.f90  |   1 +
> >  gdb/testsuite/gdb.fortran/info-types.exp      |  20 +++-
> >  gdb/testsuite/gdb.fortran/library-module.exp  |   2 +-
> >  .../gdb.fortran/mixed-lang-stack.cpp          |  12 +--
> >  .../gdb.fortran/mixed-lang-stack.exp          |  21 ++--
> >  gdb/testsuite/gdb.fortran/module.exp          |   5 +-
> >  gdb/testsuite/gdb.fortran/namelist.exp        |   2 +-
> >  gdb/testsuite/gdb.fortran/nested-funcs-2.exp  |   3 +-
> >  .../gdb.fortran/ptype-on-functions.exp        |   6 +-
> >  gdb/testsuite/gdb.fortran/vla-type.exp        |   2 +-
> >  gdb/testsuite/lib/compiler.F90                |  69 ++++++++++++
> >  gdb/testsuite/lib/compiler.c                  |   2 +-
> >  gdb/testsuite/lib/compiler.cc                 |   2 +-
> >  gdb/testsuite/lib/fortran.exp                 | 100 +++++++++++-------
> >  gdb/testsuite/lib/future.exp                  |  21 +---
> >  gdb/testsuite/lib/gdb.exp                     |  62 +++++++----
> >  gdb/testsuite/lib/sym-info-cmds.exp           |  18 +++-
> >  26 files changed, 318 insertions(+), 171 deletions(-)
> >  create mode 100644 gdb/testsuite/lib/compiler.F90
> >
> > --
> > 2.25.1
> >
> > Intel Deutschland GmbH
> > Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> > Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
> > Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
> > Chairperson of the Supervisory Board: Nicole Lau
> > Registered Office: Munich
> > Commercial Register: Amtsgericht Muenchen HRB 186928

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [PATCH v2 00/16] Fortran compiler identification and ifx testsuite support

[Tom de Vries]

On 5/31/22 18:14, Andrew Burgess via Gdb-patches wrote:
> Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org>
> writes:
> 
>> Hi,
>>
>> V1 of this series can be found here:
>>
>>    https://sourceware.org/pipermail/gdb-patches/2022-May/188904.html
>>
>> Changes since v1:
>>
>>    * Patch 03: There were some leftovers in the commit message from an
>>    earlier version of the patch - these have been removed.
>>
>>    * Patch 04: The commit message has been renamed and a comment been
>>    adapted according to Andrew's feedback.  The getting_compiler_info
>>    variable now also uses actual bool values.
>>
>>    * Patch 06: The commit message has been adapted and now says that
>>    the intel C compiler names have not yet been used in the testsuite (to
>>    avoid confusion as to why there are no changes done in the testsuite).
>>
>>    * Patch 08: This patch has been dropped, instead an ifx bug was filed.
>>    So from now on the patch numbers will be off by 1.
>>
>>    * Patch 11 (now 10): The comment has been reworded and
>>      'need the -debug-parameters all flag set to emit'
>>    now reads
>>      'need the -debug-parameters flag set to emit'
>>    Also, not only ifx but also ifort requires the flag so it is now added
>>    for both compilers.
>>
>>    * Patch 13 (now 12): I added a comment to the patch as well as made
>>    the commit message a lot more elaborate (after some online
>>    discussion).
>>
>>    * Patch 14: This patch has been dropped for now as we are claifying
>>    whether ifx should change its debug output.  The patch numbers will
>>    now be off by 2.
>>
>>    * Patch 18 (now 16): The '-wrap' is now used here instead of adding
>>    the $gdb_prompt in test_multiple.  Also, flang was added to the
>>    comments.
>>
>> Patch 01, 02, 05, 07, 09 (now 08), 10 (now 09), 12 (now 11), 15 (now 13),
>> 16 (now 14), and 17 (now 15) had been approved before and were not
>> changed/included here.
> 
> I've approved all these patches now.
> 
> For me I would have preferred to see the complete set of patches
> included each time the series is reposted, it makes it easier to apply
> the patches.  Though I do also appreciate you commenting about which
> patches have changed, and what the changes were.
> 

Hi,

I'm seeing regressions with check-read1 (haven't tried native yet), I'm 
guessing because of this patch series:
...
FAIL: gdb.fortran/allocated.exp: gdb_breakpoint: set breakpoint at unknown
FAIL: gdb.fortran/array-bounds-high.exp: gdb_breakpoint: set breakpoint 
at unknown
ERROR: Could not run to main.
FAIL: gdb.fortran/array-bounds.exp: gdb_breakpoint: set breakpoint at 
unknown
ERROR: Could not run to main.
FAIL: gdb.fortran/array-indices.exp: gdb_breakpoint: set breakpoint at 
unknown
ERROR: Could not run to main.
FAIL: gdb.fortran/array-indices.exp: gdb_breakpoint: set breakpoint at 
unknown
ERROR: Could not run to main.
FAIL: gdb.fortran/array-no-bounds.exp: gdb_breakpoint: set breakpoint at 
unknown
ERROR: Could not run to main.
FAIL: gdb.fortran/array-repeat.exp: gdb_breakpoint: set breakpoint at 
unknown
ERROR: Could not run to main.
FAIL: gdb.fortran/array-repeat.exp: gdb_breakpoint: set breakpoint at 
unknown
ERROR: Could not run to main.
FAIL: gdb.fortran/array-slices-bad.exp: gdb_breakpoint: set breakpoint 
at unknown
FAIL: gdb.fortran/array-slices-sub-slices.exp: gdb_breakpoint: set 
breakpoint at unknown
FAIL: gdb.fortran/array-slices.exp: repack=on: gdb_breakpoint: set 
breakpoint at unknown
FAIL: gdb.fortran/array-slices.exp: repack=off: gdb_breakpoint: set 
breakpoint at unknown
FAIL: gdb.fortran/associated.exp: gdb_breakpoint: set breakpoint at unknown
FAIL: gdb.fortran/assumedrank.exp: gdb_breakpoint: set breakpoint at unknown
FAIL: gdb.fortran/block-data.exp: gdb_breakpoint: set breakpoint at unknown
FAIL: gdb.fortran/call-no-debug.exp: gdb_breakpoint: set breakpoint at 
unknown
FAIL: gdb.fortran/charset.exp: gdb_breakpoint: set breakpoint at unknown
ERROR: Couldn't run to main
FAIL: gdb.fortran/class-allocatable-array.exp: gdb_breakpoint: set 
breakpoint at unknown
FAIL: gdb.fortran/common-block.exp: gdb_breakpoint: set breakpoint at 
unknown
ERROR: couldn't run to main
FAIL: gdb.fortran/completion.exp: gdb_breakpoint: set breakpoint at unknown
FAIL: gdb.fortran/complex.exp: gdb_breakpoint: set breakpoint at unknown
ERROR: Couldn't run to main
FAIL: gdb.fortran/debug-expr.exp: gdb_breakpoint: set breakpoint at unknown
FAIL: gdb.fortran/derived-type-function.exp: gdb_breakpoint: set 
breakpoint at unknown
ERROR: couldn't run to main
FAIL: gdb.fortran/derived-type.exp: gdb_breakpoint: set breakpoint at 
unknown
ERROR: couldn't run to main
FAIL: gdb.fortran/dynamic-ptype-whatis.exp: gdb_breakpoint: set 
breakpoint at unknown
ERROR: Could not run to main.
FAIL: gdb.fortran/info-modules.exp: gdb_breakpoint: set breakpoint at 
unknown
ERROR: Could not run to main.
FAIL: gdb.fortran/info-types.exp: gdb_breakpoint: set breakpoint at unknown
ERROR: Could not run to main.
FAIL: gdb.fortran/intrinsics.exp: gdb_breakpoint: set breakpoint at unknown
ERROR: Could not run to main.
FAIL: gdb.fortran/intvar-array.exp: gdb_breakpoint: set breakpoint at 
unknown
FAIL: gdb.fortran/intvar-dynamic-types.exp: gdb_breakpoint: set 
breakpoint at unknown
FAIL: gdb.fortran/lbound-ubound.exp: gdb_breakpoint: set breakpoint at 
unknown
FAIL: gdb.fortran/library-module.exp: gdb_breakpoint: set breakpoint at 
unknown
ERROR: couldn't run to main
FAIL: gdb.fortran/logical.exp: gdb_breakpoint: set breakpoint at unknown
ERROR: Could not run to main.
FAIL: gdb.fortran/max-depth.exp: gdb_breakpoint: set breakpoint at unknown
ERROR: Could not run to main.
FAIL: gdb.fortran/module.exp: gdb_breakpoint: set breakpoint at unknown
ERROR: couldn't run to main
FAIL: gdb.fortran/multi-dim.exp: gdb_breakpoint: set breakpoint at unknown
ERROR: Couldn't run to main
FAIL: gdb.fortran/namelist.exp: gdb_breakpoint: set breakpoint at unknown
ERROR: couldn't run to main
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=0: nest_prefix=0: 
increment: whatis increment
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=0: nest_prefix=0: 
increment: ptype increment
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=0: nest_prefix=0: 
increment_program_global: whatis increment_program_global
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=0: nest_prefix=0: 
increment_program_global: ptype increment_program_global
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=0: nest_prefix=1: 
before start: whatis contains_keyword::increment
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=0: nest_prefix=1: 
before start: ptype contains_keyword::increment
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=0: nest_prefix=1: 
before start: print contains_keyword::increment
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=0: nest_prefix=1: 
before start: whatis contains_keyword::increment_program_global
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=0: nest_prefix=1: 
before start: ptype contains_keyword::increment_program_global
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=0: nest_prefix=1: 
before start: print contains_keyword::increment_program_global
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=0: nest_prefix=1: 
increment: whatis contains_keyword::increment
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=0: nest_prefix=1: 
increment: ptype contains_keyword::increment
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=0: nest_prefix=1: 
increment_program_global: whatis contains_keyword::increment_program_global
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=0: nest_prefix=1: 
increment_program_global: ptype contains_keyword::increment_program_global
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=1: nest_prefix=0: 
increment: whatis increment
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=1: nest_prefix=0: 
increment: ptype increment
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=1: nest_prefix=0: 
increment_program_global: whatis increment_program_global
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=1: nest_prefix=0: 
increment_program_global: ptype increment_program_global
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=1: nest_prefix=1: 
before start: whatis contains_keyword::increment
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=1: nest_prefix=1: 
before start: ptype contains_keyword::increment
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=1: nest_prefix=1: 
before start: print contains_keyword::increment
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=1: nest_prefix=1: 
before start: whatis contains_keyword::increment_program_global
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=1: nest_prefix=1: 
before start: ptype contains_keyword::increment_program_global
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=1: nest_prefix=1: 
before start: print contains_keyword::increment_program_global
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=1: nest_prefix=1: 
increment: whatis contains_keyword::increment
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=1: nest_prefix=1: 
increment: ptype contains_keyword::increment
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=1: nest_prefix=1: 
increment_program_global: whatis contains_keyword::increment_program_global
FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=1: nest_prefix=1: 
increment_program_global: ptype contains_keyword::increment_program_global
FAIL: gdb.fortran/nested-funcs.exp: gdb_breakpoint: set breakpoint at 
unknown
ERROR: couldn't run to main
FAIL: gdb.fortran/oop_extend_type.exp: gdb_breakpoint: set breakpoint at 
unknown
ERROR: could not run to main
FAIL: gdb.fortran/pointer-to-pointer.exp: gdb_breakpoint: set breakpoint 
at unknown
FAIL: gdb.fortran/print-formatted.exp: gdb_breakpoint: set breakpoint at 
unknown
FAIL: gdb.fortran/print_type.exp: gdb_breakpoint: set breakpoint at unknown
FAIL: gdb.fortran/printing-types.exp: gdb_breakpoint: set breakpoint at 
unknown
FAIL: gdb.fortran/ptr-indentation.exp: gdb_breakpoint: set breakpoint at 
unknown
FAIL: gdb.fortran/ptype-on-functions.exp: gdb_breakpoint: set breakpoint 
at unknown
ERROR: couldn't run to main
FAIL: gdb.fortran/rank.exp: gdb_breakpoint: set breakpoint at unknown
FAIL: gdb.fortran/shape.exp: gdb_breakpoint: set breakpoint at unknown
FAIL: gdb.fortran/size.exp: gdb_breakpoint: set breakpoint at unknown
FAIL: gdb.fortran/subarray.exp: gdb_breakpoint: set breakpoint at unknown
ERROR: couldn't run to main
FAIL: gdb.fortran/vla-alloc-assoc.exp: gdb_breakpoint: set breakpoint at 
unknown
FAIL: gdb.fortran/vla-datatypes.exp: gdb_breakpoint: set breakpoint at 
unknown
FAIL: gdb.fortran/vla-history.exp: gdb_breakpoint: set breakpoint at unknown
FAIL: gdb.fortran/vla-ptr-info.exp: gdb_breakpoint: set breakpoint at 
unknown
FAIL: gdb.fortran/vla-ptype-sub.exp: gdb_breakpoint: set breakpoint at 
unknown
FAIL: gdb.fortran/vla-ptype.exp: gdb_breakpoint: set breakpoint at unknown
FAIL: gdb.fortran/vla-sizeof.exp: gdb_breakpoint: set breakpoint at unknown
FAIL: gdb.fortran/vla-type.exp: gdb_breakpoint: set breakpoint at unknown
FAIL: gdb.fortran/vla-value-sub-arbitrary.exp: gdb_breakpoint: set 
breakpoint at unknown
FAIL: gdb.fortran/vla-value-sub-finish.exp: gdb_breakpoint: set 
breakpoint at unknown
FAIL: gdb.fortran/vla-value-sub.exp: gdb_breakpoint: set breakpoint at 
unknown
FAIL: gdb.fortran/vla-value.exp: gdb_breakpoint: set breakpoint at unknown
FAIL: gdb.fortran/whatis_type.exp: gdb_breakpoint: set breakpoint at unknown
FAIL: gdb.mi/mi-fortran-modules.exp: -symbol-info-module-variables
FAIL: gdb.mi/mi-var-child-f.exp: get children of array (unexpected output)
FAIL: gdb.mi/mi-var-child-f.exp: get grandchildren of array (children of 
first element of second index) (unexpected output)
FAIL: gdb.mi/mi-vla-fortran.exp: create local variable 
vla1_not_allocated (unexpected output)
FAIL: gdb.mi/mi-vla-fortran.exp: info type variable vla1_not_allocated 
(unexpected output)
FAIL: gdb.mi/mi-vla-fortran.exp: create local variable vla1_allocated 
(unexpected output)
FAIL: gdb.mi/mi-vla-fortran.exp: info type variable vla1_allocated 
(unexpected output)
FAIL: gdb.mi/mi-vla-fortran.exp: get children of vla1_allocated 
(unexpected output)
FAIL: gdb.mi/mi-vla-fortran.exp: create local variable 
pvla2_not_associated (unexpected output)
FAIL: gdb.mi/mi-vla-fortran.exp: info type variable pvla2_not_associated 
(unexpected output)
FAIL: gdb.mi/mi-vla-fortran.exp: create local variable pvla2_associated 
(unexpected output)
FAIL: gdb.mi/mi-vla-fortran.exp: info type variable pvla2_associated 
(unexpected output)
...

Thanks,
- Tom

Re: [PATCH v2 00/16] Fortran compiler identification and ifx testsuite support

[Tom de Vries]

On 5/31/22 21:33, Tom de Vries via Gdb-patches wrote:
> I'm seeing regressions with check-read1 (haven't tried native yet), I'm 
> guessing because of this patch series:
> ...
> FAIL: gdb.fortran/allocated.exp: gdb_breakpoint: set breakpoint at unknown

I could reproduce this with native, but only when running the entire 
testsuite, not just the test-case.

This looks like problems due to the caching of compiler_info, which 
doesn't take the language argument of proc get_compiler_info into account.

So, if I run the entire test suite, compiler_info is set to gcc-7-5-0 
and stays that way due to the caching, and because of this series gcc is 
no longer matched in proc fortran_main, so we run into FAILs.

Thanks,
- Tom

Re: [PATCH v2 00/16] Fortran compiler identification and ifx testsuite support

[Tom de Vries]

On 6/1/22 06:54, Tom de Vries wrote:
> On 5/31/22 21:33, Tom de Vries via Gdb-patches wrote:
>> I'm seeing regressions with check-read1 (haven't tried native yet), 
>> I'm guessing because of this patch series:
>> ...
>> FAIL: gdb.fortran/allocated.exp: gdb_breakpoint: set breakpoint at 
>> unknown
> 
> I could reproduce this with native, but only when running the entire 
> testsuite, not just the test-case.
> 
> This looks like problems due to the caching of compiler_info, which 
> doesn't take the language argument of proc get_compiler_info into account.
> 

That's confirmed.  I did a run with caching disabled, and these FAILs 
disappeared.

Thanks,
- Tom

> So, if I run the entire test suite, compiler_info is set to gcc-7-5-0 
> and stays that way due to the caching, and because of this series gcc is 
> no longer matched in proc fortran_main, so we run into FAILs.
> 
> Thanks,
> - Tom

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

[Tom de Vries]

On 5/31/22 18:06, Andrew Burgess via Gdb-patches wrote:
> Nils-Christian Kempke <nils-christian.kempke@intel.com> writes:
> 
>> This info-types.exp test case had a few issues that this patch fixes.
>>

I'm seeing this regression:
...
Running 
/home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.fortran/info-types.exp 
...
gdb compile failed, 
/home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.fortran/info-types.f90:47:13:

    type (m1t1) :: var_b
              1
Error: Derived type 'm1t1' at (1) is being used before it is defined
/home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.fortran/info-types.f90:50:8:

    var_b%b = 2
         1
Error: Symbol 'var_b' at (1) has no IMPLICIT type
UNTESTED: gdb.fortran/info-types.exp: failed to prepare
...

Likewise for a few other test-cases that use the same source.

Thanks,
- Tom

RE: [PATCH v2 00/16] Fortran compiler identification and ifx testsuite support

[Kempke, Nils-Christian]

> -----Original Message-----
> From: Tom de Vries <tdevries@suse.de>
> Sent: Wednesday, June 1, 2022 7:14 AM
> To: Andrew Burgess <aburgess@redhat.com>; Kempke, Nils-Christian <nils-
> christian.kempke@intel.com>; gdb-patches@sourceware.org
> Cc: JiniSusan.George@amd.com
> Subject: Re: [PATCH v2 00/16] Fortran compiler identification and ifx testsuite
> support
> 
> On 6/1/22 06:54, Tom de Vries wrote:
> > On 5/31/22 21:33, Tom de Vries via Gdb-patches wrote:
> >> I'm seeing regressions with check-read1 (haven't tried native yet),
> >> I'm guessing because of this patch series:
> >> ...
> >> FAIL: gdb.fortran/allocated.exp: gdb_breakpoint: set breakpoint at
> >> unknown
> >
> > I could reproduce this with native, but only when running the entire
> > testsuite, not just the test-case.
> >
> > This looks like problems due to the caching of compiler_info, which
> > doesn't take the language argument of proc get_compiler_info into
> account.
> >
> 
> That's confirmed.  I did a run with caching disabled, and these FAILs
> disappeared.
> 
> Thanks,
> - Tom
> 
> > So, if I run the entire test suite, compiler_info is set to gcc-7-5-0
> > and stays that way due to the caching, and because of this series gcc is
> > no longer matched in proc fortran_main, so we run into FAILs.
> >
> > Thanks,
> > - Tom

Hi,

Sorry for this, I could not see any of these regressions in our CI nor in the runs
I did manually. I assume something is different in the way I am running the
Testsuite. I thought the caching would only ever happen for each individual
test rather than multiple ones. But apparently there is a way this can be done
cached over different tests?

I/CI ran the testsuite like

  make check TESTS="gdb.*/*.exp" FORCE_PARALLEL='1' -j $(nproc --ignore 1)

as well as

  make check TESTS="gdb.*/*.exp" RUNTESTFLAGS='--target_board="unix" \
    CC_FOR_TARGET='gcc' CXX_FOR_TARGET='gcc' \
    F90_FOR_TARGET="gfortran"' FORCE_PARALLEL='1' -j $(nproc --ignore 1)

(and then the same for unix/-m32, and native-gdbserver and
native-extended-gdbserver)

and

  make check -j $(nproc --ignore 1)

I assume I am somewhat running the testsuite differently.

Could you tell me how to run the testsuite instead?

Thanks,
Nils
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

RE: [PATCH v2 00/16] Fortran compiler identification and ifx testsuite support

[Kempke, Nils-Christian]

> -----Original Message-----
> From: Gdb-patches <gdb-patches-bounces+nils-
> christian.kempke=intel.com@sourceware.org> On Behalf Of Kempke, Nils-
> Christian via Gdb-patches
> Sent: Wednesday, June 1, 2022 8:44 AM
> To: Tom de Vries <tdevries@suse.de>; Andrew Burgess
> <aburgess@redhat.com>; gdb-patches@sourceware.org
> Cc: JiniSusan.George@amd.com
> Subject: RE: [PATCH v2 00/16] Fortran compiler identification and ifx testsuite
> support
> 
> > -----Original Message-----
> > From: Tom de Vries <tdevries@suse.de>
> > Sent: Wednesday, June 1, 2022 7:14 AM
> > To: Andrew Burgess <aburgess@redhat.com>; Kempke, Nils-Christian
> <nils-
> > christian.kempke@intel.com>; gdb-patches@sourceware.org
> > Cc: JiniSusan.George@amd.com
> > Subject: Re: [PATCH v2 00/16] Fortran compiler identification and ifx
> testsuite
> > support
> >
> > On 6/1/22 06:54, Tom de Vries wrote:
> > > On 5/31/22 21:33, Tom de Vries via Gdb-patches wrote:
> > >> I'm seeing regressions with check-read1 (haven't tried native yet),
> > >> I'm guessing because of this patch series:
> > >> ...
> > >> FAIL: gdb.fortran/allocated.exp: gdb_breakpoint: set breakpoint at
> > >> unknown
> > >
> > > I could reproduce this with native, but only when running the entire
> > > testsuite, not just the test-case.
> > >
> > > This looks like problems due to the caching of compiler_info, which
> > > doesn't take the language argument of proc get_compiler_info into
> > account.
> > >
> >
> > That's confirmed.  I did a run with caching disabled, and these FAILs
> > disappeared.
> >
> > Thanks,
> > - Tom
> >
> > > So, if I run the entire test suite, compiler_info is set to gcc-7-5-0
> > > and stays that way due to the caching, and because of this series gcc is
> > > no longer matched in proc fortran_main, so we run into FAILs.
> > >
> > > Thanks,
> > > - Tom
> 
> Hi,
> 
> Sorry for this, I could not see any of these regressions in our CI nor in the
> runs
> I did manually. I assume something is different in the way I am running the
> Testsuite. I thought the caching would only ever happen for each individual
> test rather than multiple ones. But apparently there is a way this can be done
> cached over different tests?
> 
> I/CI ran the testsuite like
> 
>   make check TESTS="gdb.*/*.exp" FORCE_PARALLEL='1' -j $(nproc --ignore
> 1)
> 
> as well as
> 
>   make check TESTS="gdb.*/*.exp" RUNTESTFLAGS='--target_board="unix" \
>     CC_FOR_TARGET='gcc' CXX_FOR_TARGET='gcc' \
>     F90_FOR_TARGET="gfortran"' FORCE_PARALLEL='1' -j $(nproc --ignore 1)
> 
> (and then the same for unix/-m32, and native-gdbserver and
> native-extended-gdbserver)
> 
> and
> 
>   make check -j $(nproc --ignore 1)
> 
> I assume I am somewhat running the testsuite differently.
> 
> Could you tell me how to run the testsuite instead?
> 
> Thanks,
> Nils

Ok, so apparently running the testsuite in any kind of parallel mode disables this
caching?

I can reproduce these with plain

  make check

Sorry for missing this. I'll try an push a patch to fix this - not sure if we should
revert until then as the series seems to cause regressions on all of the Fortran
testsuite...


Thanks,
Nils
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [PATCH v2 00/16] Fortran compiler identification and ifx testsuite support

[Tom de Vries]

On 6/1/22 09:10, Kempke, Nils-Christian wrote:
> 
> 
>> -----Original Message-----
>> From: Gdb-patches <gdb-patches-bounces+nils-
>> christian.kempke=intel.com@sourceware.org> On Behalf Of Kempke, Nils-
>> Christian via Gdb-patches
>> Sent: Wednesday, June 1, 2022 8:44 AM
>> To: Tom de Vries <tdevries@suse.de>; Andrew Burgess
>> <aburgess@redhat.com>; gdb-patches@sourceware.org
>> Cc: JiniSusan.George@amd.com
>> Subject: RE: [PATCH v2 00/16] Fortran compiler identification and ifx testsuite
>> support
>>
>>> -----Original Message-----
>>> From: Tom de Vries <tdevries@suse.de>
>>> Sent: Wednesday, June 1, 2022 7:14 AM
>>> To: Andrew Burgess <aburgess@redhat.com>; Kempke, Nils-Christian
>> <nils-
>>> christian.kempke@intel.com>; gdb-patches@sourceware.org
>>> Cc: JiniSusan.George@amd.com
>>> Subject: Re: [PATCH v2 00/16] Fortran compiler identification and ifx
>> testsuite
>>> support
>>>
>>> On 6/1/22 06:54, Tom de Vries wrote:
>>>> On 5/31/22 21:33, Tom de Vries via Gdb-patches wrote:
>>>>> I'm seeing regressions with check-read1 (haven't tried native yet),
>>>>> I'm guessing because of this patch series:
>>>>> ...
>>>>> FAIL: gdb.fortran/allocated.exp: gdb_breakpoint: set breakpoint at
>>>>> unknown
>>>>
>>>> I could reproduce this with native, but only when running the entire
>>>> testsuite, not just the test-case.
>>>>
>>>> This looks like problems due to the caching of compiler_info, which
>>>> doesn't take the language argument of proc get_compiler_info into
>>> account.
>>>>
>>>
>>> That's confirmed.  I did a run with caching disabled, and these FAILs
>>> disappeared.
>>>
>>> Thanks,
>>> - Tom
>>>
>>>> So, if I run the entire test suite, compiler_info is set to gcc-7-5-0
>>>> and stays that way due to the caching, and because of this series gcc is
>>>> no longer matched in proc fortran_main, so we run into FAILs.
>>>>
>>>> Thanks,
>>>> - Tom
>>
>> Hi,
>>
>> Sorry for this, I could not see any of these regressions in our CI nor in the
>> runs
>> I did manually. I assume something is different in the way I am running the
>> Testsuite. I thought the caching would only ever happen for each individual
>> test rather than multiple ones. But apparently there is a way this can be done
>> cached over different tests?
>>
>> I/CI ran the testsuite like
>>
>>    make check TESTS="gdb.*/*.exp" FORCE_PARALLEL='1' -j $(nproc --ignore
>> 1)
>>
>> as well as
>>
>>    make check TESTS="gdb.*/*.exp" RUNTESTFLAGS='--target_board="unix" \
>>      CC_FOR_TARGET='gcc' CXX_FOR_TARGET='gcc' \
>>      F90_FOR_TARGET="gfortran"' FORCE_PARALLEL='1' -j $(nproc --ignore 1)
>>
>> (and then the same for unix/-m32, and native-gdbserver and
>> native-extended-gdbserver)
>>
>> and
>>
>>    make check -j $(nproc --ignore 1)
>>
>> I assume I am somewhat running the testsuite differently.
>>
>> Could you tell me how to run the testsuite instead?
>>
>> Thanks,
>> Nils
> 
> Ok, so apparently running the testsuite in any kind of parallel mode disables this
> caching?
> 

I don't think it's that.

But if there's an error in caching, the first invocation becomes 
significant, and with parallel testing each parallel instance does its 
own first invocation, so it's possible that you get different results 
between parallel and non-parallel.

> I can reproduce these with plain
> 
>    make check
> 
> Sorry for missing this. I'll try an push a patch to fix this - not sure if we should
> revert until then as the series seems to cause regressions on all of the Fortran
> testsuite...

No problem of course, it happens.

I suppose the thing we really want to fix is the caching which needs to 
be made language-specific.

But I imagine some simple workaround like this:
...
diff --git a/gdb/testsuite/lib/fortran.exp b/gdb/testsuite/lib/fortran.exp
index 9ee4208fb88..aa3882794a9 100644
--- a/gdb/testsuite/lib/fortran.exp
+++ b/gdb/testsuite/lib/fortran.exp
@@ -177,6 +177,7 @@ proc fortran_character1 {} {

  proc fortran_main {} {
      if {[test_compiler_info {gfortran-*} f90]
+       || [test_compiler_info {gcc-*} f90]
         || [test_compiler_info {ifort-*} f90]
         || [test_compiler_info {ifx-*} f90]
         || [test_compiler_info {flang-llvm-*} f90]} {
...
will already take care of the regressions.

Thanks,
- Tom

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

[Kempke, Nils-Christian]

> -----Original Message-----
> From: Tom de Vries <tdevries@suse.de>
> Sent: Wednesday, June 1, 2022 7:25 AM
> To: Andrew Burgess <aburgess@redhat.com>; Kempke, Nils-Christian <nils-
> christian.kempke@intel.com>; gdb-patches@sourceware.org
> Cc: JiniSusan.George@amd.com
> Subject: Re: [PATCH v2 12/16] testsuite, fortran: fix info-types for intel
> compilers
> 
> On 5/31/22 18:06, Andrew Burgess via Gdb-patches wrote:
> > Nils-Christian Kempke <nils-christian.kempke@intel.com> writes:
> >
> >> This info-types.exp test case had a few issues that this patch fixes.
> >>
> 
> I'm seeing this regression:
> ...
> Running
> /home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.fortran/info-
> types.exp
> ...
> gdb compile failed,
> /home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.fortran/info-
> types.f90:47:13:
> 
>     type (m1t1) :: var_b
>               1
> Error: Derived type 'm1t1' at (1) is being used before it is defined
> /home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.fortran/info-
> types.f90:50:8:
> 
>     var_b%b = 2
>          1
> Error: Symbol 'var_b' at (1) has no IMPLICIT type
> UNTESTED: gdb.fortran/info-types.exp: failed to prepare
> ...
> 
> Likewise for a few other test-cases that use the same source.
> 
> Thanks,
> - Tom

Hi Tom,

Sorry for this, too. I did not change the executable - nor the actual
compilation of it I think but this must be the source of the regressions.

I made one of the checks in the info-types.exp file optional, but that does
not really explain the problems you are seeing..

I cannot reproduce this currently. I assume this is from a native run? Does
this also happen in the tests when ran individually? Or is this failure related
to the regressions seen because of the compiler_info caching?

Thanks,
Nils
 
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

RE: [PATCH v2 00/16] Fortran compiler identification and ifx testsuite support

[Kempke, Nils-Christian]

> -----Original Message-----
> From: Tom de Vries <tdevries@suse.de>
> Sent: Wednesday, June 1, 2022 9:32 AM
> To: Kempke, Nils-Christian <nils-christian.kempke@intel.com>; Andrew
> Burgess <aburgess@redhat.com>; gdb-patches@sourceware.org
> Cc: JiniSusan.George@amd.com
> Subject: Re: [PATCH v2 00/16] Fortran compiler identification and ifx testsuite
> support
> 
> On 6/1/22 09:10, Kempke, Nils-Christian wrote:
> >
> >
> >> -----Original Message-----
> >> From: Gdb-patches <gdb-patches-bounces+nils-
> >> christian.kempke=intel.com@sourceware.org> On Behalf Of Kempke,
> Nils-
> >> Christian via Gdb-patches
> >> Sent: Wednesday, June 1, 2022 8:44 AM
> >> To: Tom de Vries <tdevries@suse.de>; Andrew Burgess
> >> <aburgess@redhat.com>; gdb-patches@sourceware.org
> >> Cc: JiniSusan.George@amd.com
> >> Subject: RE: [PATCH v2 00/16] Fortran compiler identification and ifx
> testsuite
> >> support
> >>
> >>> -----Original Message-----
> >>> From: Tom de Vries <tdevries@suse.de>
> >>> Sent: Wednesday, June 1, 2022 7:14 AM
> >>> To: Andrew Burgess <aburgess@redhat.com>; Kempke, Nils-Christian
> >> <nils-
> >>> christian.kempke@intel.com>; gdb-patches@sourceware.org
> >>> Cc: JiniSusan.George@amd.com
> >>> Subject: Re: [PATCH v2 00/16] Fortran compiler identification and ifx
> >> testsuite
> >>> support
> >>>
> >>> On 6/1/22 06:54, Tom de Vries wrote:
> >>>> On 5/31/22 21:33, Tom de Vries via Gdb-patches wrote:
> >>>>> I'm seeing regressions with check-read1 (haven't tried native yet),
> >>>>> I'm guessing because of this patch series:
> >>>>> ...
> >>>>> FAIL: gdb.fortran/allocated.exp: gdb_breakpoint: set breakpoint at
> >>>>> unknown
> >>>>
> >>>> I could reproduce this with native, but only when running the entire
> >>>> testsuite, not just the test-case.
> >>>>
> >>>> This looks like problems due to the caching of compiler_info, which
> >>>> doesn't take the language argument of proc get_compiler_info into
> >>> account.
> >>>>
> >>>
> >>> That's confirmed.  I did a run with caching disabled, and these FAILs
> >>> disappeared.
> >>>
> >>> Thanks,
> >>> - Tom
> >>>
> >>>> So, if I run the entire test suite, compiler_info is set to gcc-7-5-0
> >>>> and stays that way due to the caching, and because of this series gcc is
> >>>> no longer matched in proc fortran_main, so we run into FAILs.
> >>>>
> >>>> Thanks,
> >>>> - Tom
> >>
> >> Hi,
> >>
> >> Sorry for this, I could not see any of these regressions in our CI nor in the
> >> runs
> >> I did manually. I assume something is different in the way I am running
> the
> >> Testsuite. I thought the caching would only ever happen for each
> individual
> >> test rather than multiple ones. But apparently there is a way this can be
> done
> >> cached over different tests?
> >>
> >> I/CI ran the testsuite like
> >>
> >>    make check TESTS="gdb.*/*.exp" FORCE_PARALLEL='1' -j $(nproc --
> ignore
> >> 1)
> >>
> >> as well as
> >>
> >>    make check TESTS="gdb.*/*.exp" RUNTESTFLAGS='--
> target_board="unix" \
> >>      CC_FOR_TARGET='gcc' CXX_FOR_TARGET='gcc' \
> >>      F90_FOR_TARGET="gfortran"' FORCE_PARALLEL='1' -j $(nproc --ignore
> 1)
> >>
> >> (and then the same for unix/-m32, and native-gdbserver and
> >> native-extended-gdbserver)
> >>
> >> and
> >>
> >>    make check -j $(nproc --ignore 1)
> >>
> >> I assume I am somewhat running the testsuite differently.
> >>
> >> Could you tell me how to run the testsuite instead?
> >>
> >> Thanks,
> >> Nils
> >
> > Ok, so apparently running the testsuite in any kind of parallel mode
> disables this
> > caching?
> >
> 
> I don't think it's that.
> 
> But if there's an error in caching, the first invocation becomes
> significant, and with parallel testing each parallel instance does its
> own first invocation, so it's possible that you get different results
> between parallel and non-parallel.
> 
> > I can reproduce these with plain
> >
> >    make check
> >
> > Sorry for missing this. I'll try an push a patch to fix this - not sure if we
> should
> > revert until then as the series seems to cause regressions on all of the
> Fortran
> > testsuite...
> 
> No problem of course, it happens.
> 
> I suppose the thing we really want to fix is the caching which needs to
> be made language-specific.
> 
> But I imagine some simple workaround like this:
> ...
> diff --git a/gdb/testsuite/lib/fortran.exp b/gdb/testsuite/lib/fortran.exp
> index 9ee4208fb88..aa3882794a9 100644
> --- a/gdb/testsuite/lib/fortran.exp
> +++ b/gdb/testsuite/lib/fortran.exp
> @@ -177,6 +177,7 @@ proc fortran_character1 {} {
> 
>   proc fortran_main {} {
>       if {[test_compiler_info {gfortran-*} f90]
> +       || [test_compiler_info {gcc-*} f90]
>          || [test_compiler_info {ifort-*} f90]
>          || [test_compiler_info {ifx-*} f90]
>          || [test_compiler_info {flang-llvm-*} f90]} {
> ...
> will already take care of the regressions.

It will take care of a bunch (all the runto_main ones) but there are the compiler
dependent output names for Fortran intrinsic types as well. Basically all the
checks in fortran.exp would need this fallback.

Also, there exist compiler dependent tests and KFAILs in the gdb.fortran
testsuite which would fail to identify the compiler correctly.
 
I have prepared two patches that make the compiler info caching language
specific. I am not sure whether these fix all regressions seen but I'll post
them (after checking for regressions) and hope these fix all problems seen
with this series.

Thanks,
Nils

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

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

[Tom de Vries]

On 6/1/22 11:21, Kempke, Nils-Christian wrote:
> 
> 
>> -----Original Message-----
>> From: Tom de Vries <tdevries@suse.de>
>> Sent: Wednesday, June 1, 2022 7:25 AM
>> To: Andrew Burgess <aburgess@redhat.com>; Kempke, Nils-Christian <nils-
>> christian.kempke@intel.com>; gdb-patches@sourceware.org
>> Cc: JiniSusan.George@amd.com
>> Subject: Re: [PATCH v2 12/16] testsuite, fortran: fix info-types for intel
>> compilers
>>
>> On 5/31/22 18:06, Andrew Burgess via Gdb-patches wrote:
>>> Nils-Christian Kempke <nils-christian.kempke@intel.com> writes:
>>>
>>>> This info-types.exp test case had a few issues that this patch fixes.
>>>>
>>
>> I'm seeing this regression:
>> ...
>> Running
>> /home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.fortran/info-
>> types.exp
>> ...
>> gdb compile failed,
>> /home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.fortran/info-
>> types.f90:47:13:
>>
>>      type (m1t1) :: var_b
>>                1
>> Error: Derived type 'm1t1' at (1) is being used before it is defined
>> /home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.fortran/info-
>> types.f90:50:8:
>>
>>      var_b%b = 2
>>           1
>> Error: Symbol 'var_b' at (1) has no IMPLICIT type
>> UNTESTED: gdb.fortran/info-types.exp: failed to prepare
>> ...
>>
>> Likewise for a few other test-cases that use the same source.
>>
>> Thanks,
>> - Tom
> 
> Hi Tom,
> 
> Sorry for this, too. I did not change the executable - nor the actual
> compilation of it I think but this must be the source of the regressions.
> 
> I made one of the checks in the info-types.exp file optional, but that does
> not really explain the problems you are seeing..
> 
> I cannot reproduce this currently. I assume this is from a native run? Does
> this also happen in the tests when ran individually? Or is this failure related
> to the regressions seen because of the compiler_info caching?
> 

Hi Nils,

I've not been able to reproduce this anymore.

I'm gonna assume that this was due to an incorrect temporary fix I was 
trying out.

I currently just have a patch in my master-local branch that disables 
compiler_info caching, and that seems to work fine.

Sorry for the noise.

Thanks,
- Tom