* [PATCH 01/18] gdb/testsuite: remove F77_FOR_TARGET support
2022-05-10 14:24 [PATCH 00/18] Fortran compiler identification and ifx testsuite support Nils-Christian Kempke
@ 2022-05-10 14:24 ` Nils-Christian Kempke
2022-05-10 14:24 ` [PATCH 02/18] gdb/testsuite: Use -module option for Intel Fortran compilers Nils-Christian Kempke
` (17 subsequent siblings)
18 siblings, 0 replies; 39+ messages in thread
From: Nils-Christian Kempke @ 2022-05-10 14:24 UTC (permalink / raw)
To: gdb-patches; +Cc: aburgess, JiniSusan.George, Nils-Christian Kempke
The last uses of the F77_FOR_TARGET via passing f77 to GDB's compile
procedure were removed in this commit
commit 0ecee54cfd04a60e7ca61ae07c72b20e21390257
Author: Tom Tromey <tromey@redhat.com>
Date: Wed Jun 29 17:50:47 2011 +0000
over 10 years ago. The last .f files in the testsuite by now are all
being compiled by passing 'f90' to the GDB compile, thus only actually
using F90_FOR_TARGET (array-element.f, block-data.f, subarray.f).
Gfortran in this case is backwards compatible with most f77 code as
claimed on gcc.gnu.org/fortran.
The reason we'd like to get rid of this now is, that we'll be
implementing a Fortran compiler identification mechanism, similar to the
C/Cpp existing ones. It would be using the Fortran preprocessor macro
defines to identify the Fortran compiler version at hand. We found it
inconsequent to only implement this for f90 but, on the other hand, f77
seems deprecated. So, with this commit we remove the remaining lines for
its support.
---
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/lib/future.exp | 21 +--------------------
gdb/testsuite/lib/gdb.exp | 14 ++++----------
5 files changed, 5 insertions(+), 37 deletions(-)
diff --git a/gdb/testsuite/boards/cc-with-tweaks.exp b/gdb/testsuite/boards/cc-with-tweaks.exp
index b7ff98fba9..fe5b9eee27 100644
--- a/gdb/testsuite/boards/cc-with-tweaks.exp
+++ b/gdb/testsuite/boards/cc-with-tweaks.exp
@@ -44,7 +44,6 @@ set found_gcc [find_gcc]
set found_gxx [find_g++]
set found_gnatmake [find_gnatmake]
set found_f90 [find_gfortran]
-set found_f77 [find_g77]
set_board_info compiler "$found_gcc"
set contrib_dir [file normalize $srcdir/../contrib]
@@ -64,10 +63,6 @@ if ![info exists F90_FOR_TARGET] {
set F90_FOR_TARGET "$found_f90"
}
set F90_FOR_TARGET "$contrib_dir/cc-with-tweaks.sh $CC_WITH_TWEAKS_FLAGS $F90_FOR_TARGET"
-if ![info exists F77_FOR_TARGET] {
- set F77_FOR_TARGET "$found_f77"
-}
-set F77_FOR_TARGET "$contrib_dir/cc-with-tweaks.sh $CC_WITH_TWEAKS_FLAGS $F77_FOR_TARGET"
set env(GDB) \
[cached_file gdb.sh "$GDB $INTERNAL_GDBFLAGS $GDBFLAGS \"\$@\"" 1]
diff --git a/gdb/testsuite/boards/debug-types.exp b/gdb/testsuite/boards/debug-types.exp
index f04a733ac2..1c4982225d 100644
--- a/gdb/testsuite/boards/debug-types.exp
+++ b/gdb/testsuite/boards/debug-types.exp
@@ -29,7 +29,6 @@ set found_gcc [find_gcc]
set found_gxx [find_g++]
set found_gnatmake [find_gnatmake]
set found_f90 [find_gfortran]
-set found_f77 [find_g77]
set_board_info compiler "$found_gcc"
# The -fdebug-types-section switch only has an effect with DWARF version 4.
diff --git a/gdb/testsuite/boards/gold-gdb-index.exp b/gdb/testsuite/boards/gold-gdb-index.exp
index 30d2d8b329..f62f489266 100644
--- a/gdb/testsuite/boards/gold-gdb-index.exp
+++ b/gdb/testsuite/boards/gold-gdb-index.exp
@@ -29,7 +29,6 @@ set found_gcc [find_gcc]
set found_gxx [find_g++]
set found_gnatmake [find_gnatmake]
set found_f90 [find_gfortran]
-set found_f77 [find_g77]
set_board_info compiler "$found_gcc"
set opts [list]
diff --git a/gdb/testsuite/lib/future.exp b/gdb/testsuite/lib/future.exp
index 2d68498623..36dd611d61 100644
--- a/gdb/testsuite/lib/future.exp
+++ b/gdb/testsuite/lib/future.exp
@@ -246,18 +246,6 @@ proc gdb_default_target_compile_1 {source destfile type options} {
}
}
- if { $i == "f77" } {
- set compiler_type "f77"
- if {[board_info $dest exists f77flags]} {
- append add_flags " [target_info f77flags]"
- }
- if {[board_info $dest exists f77compiler]} {
- set compiler [target_info f77compiler]
- } else {
- set compiler [find_g77]
- }
- }
-
if { $i == "f90" } {
set compiler_type "f90"
if {[board_info $dest exists f90flags]} {
@@ -359,7 +347,6 @@ proc gdb_default_target_compile_1 {source destfile type options} {
global CC_FOR_TARGET
global CXX_FOR_TARGET
global D_FOR_TARGET
- global F77_FOR_TARGET
global F90_FOR_TARGET
global GNATMAKE_FOR_TARGET
global GO_FOR_TARGET
@@ -390,12 +377,6 @@ proc gdb_default_target_compile_1 {source destfile type options} {
}
}
- if {[info exists F77_FOR_TARGET]} {
- if { $compiler_type == "f77" } {
- set compiler $F77_FOR_TARGET
- }
- }
-
if {[info exists F90_FOR_TARGET]} {
if { $compiler_type == "f90" } {
set compiler $F90_FOR_TARGET
@@ -646,7 +627,7 @@ proc gdb_default_target_compile {source destfile type options} {
set need_local_lang 0
}
- if { $i == "f77" || $i == "f90" } {
+ if { $i == "f90" } {
set need_local_lang [info exists use_gdb_compile(fortran)]
}
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 47cb2b2367..75e2d5a697 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -4363,8 +4363,8 @@ set gdb_saved_set_unbuffered_mode_obj ""
# - ldflags=flag: Add FLAG to the linker flags.
# - incdir=path: Add PATH to the searched include directories.
# - libdir=path: Add PATH to the linker searched directories.
-# - ada, c++, f77, f90, go, rust: Compile the file as Ada, C++,
-# Fortran 77, Fortran 90, Go or Rust.
+# - ada, c++, f90, go, rust: Compile the file as Ada, C++,
+# Fortran 90, Go or Rust.
# - debug: Build with debug information.
# - optimize: Build with optimization.
@@ -4397,7 +4397,6 @@ proc gdb_compile {source dest type options} {
if {[lsearch -exact $options getting_compiler_info] == -1
&& [lsearch -exact $options rust] == -1
&& [lsearch -exact $options ada] == -1
- && [lsearch -exact $options f77] == -1
&& [lsearch -exact $options f90] == -1
&& [lsearch -exact $options go] == -1
&& [test_compiler_info "clang-*"]} {
@@ -4426,8 +4425,7 @@ proc gdb_compile {source dest type options} {
# Place (and look for) Fortran `.mod` files in the output
# directory for this specific test.
- if {[lsearch -exact $options f77] != -1 \
- || [lsearch -exact $options f90] != -1 } {
+ if { [lsearch -exact $options f90] != -1 } {
# Fortran compile.
set mod_path [standard_output_file ""]
if [test_compiler_info "gcc-*"] {
@@ -4668,11 +4666,7 @@ proc gdb_compile {source dest type options} {
}
if {[lsearch $options quiet] < 0} {
- # We shall update this on a per language basis, to avoid
- # changing the entire testsuite in one go.
- if {[lsearch $options f77] >= 0} {
- gdb_compile_test $source $result
- } elseif { $result != "" } {
+ if { $result != "" } {
clone_output "gdb compile failed, $result"
}
}
--
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
^ permalink raw reply [flat|nested] 39+ messages in thread* [PATCH 02/18] gdb/testsuite: Use -module option for Intel Fortran compilers
2022-05-10 14:24 [PATCH 00/18] Fortran compiler identification and ifx testsuite support Nils-Christian Kempke
2022-05-10 14:24 ` [PATCH 01/18] gdb/testsuite: remove F77_FOR_TARGET support Nils-Christian Kempke
@ 2022-05-10 14:24 ` Nils-Christian Kempke
2022-05-10 14:24 ` [PATCH 03/18] gdb/testsuite: Fix fortran types for Intel compilers Nils-Christian Kempke
` (16 subsequent siblings)
18 siblings, 0 replies; 39+ messages in thread
From: Nils-Christian Kempke @ 2022-05-10 14:24 UTC (permalink / raw)
To: gdb-patches; +Cc: aburgess, JiniSusan.George, Abdul Basit Ijaz
From: Abdul Basit Ijaz <abdul.b.ijaz@intel.com>
The '-J' option is not supported in Intel compilers (ifx and ifort).
The Intel version of the flag is '-module' which serves the same purpose.
---
gdb/testsuite/lib/gdb.exp | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 75e2d5a697..a6f2d847a5 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -4424,12 +4424,16 @@ proc gdb_compile {source dest type options} {
}
# Place (and look for) Fortran `.mod` files in the output
- # directory for this specific test.
+ # 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 } {
# Fortran compile.
set mod_path [standard_output_file ""]
if [test_compiler_info "gcc-*"] {
lappend new_options "additional_flags=-J${mod_path}"
+ } elseif { [test_compiler_info {icc-*}]
+ || [test_compiler_info {intel-*}] } {
+ lappend new_options "additional_flags=-module ${mod_path}"
}
}
--
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
^ permalink raw reply [flat|nested] 39+ messages in thread* [PATCH 03/18] gdb/testsuite: Fix fortran types for Intel compilers.
2022-05-10 14:24 [PATCH 00/18] Fortran compiler identification and ifx testsuite support Nils-Christian Kempke
2022-05-10 14:24 ` [PATCH 01/18] gdb/testsuite: remove F77_FOR_TARGET support Nils-Christian Kempke
2022-05-10 14:24 ` [PATCH 02/18] gdb/testsuite: Use -module option for Intel Fortran compilers Nils-Christian Kempke
@ 2022-05-10 14:24 ` Nils-Christian Kempke
2022-05-11 9:49 ` Andrew Burgess
2022-05-10 14:24 ` [PATCH 04/18] gdb/testsuite: add local variable for passing 'getting_compiler_info' to gdb_compile Nils-Christian Kempke
` (15 subsequent siblings)
18 siblings, 1 reply; 39+ messages in thread
From: Nils-Christian Kempke @ 2022-05-10 14:24 UTC (permalink / raw)
To: gdb-patches
Cc: aburgess, JiniSusan.George, Felix Willgerodt, Abdul Basit Ijaz,
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. There was not yet a way to handle the print for
variable length strings to this commit introduces fortran_integerN as
well.
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
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: [PATCH 03/18] gdb/testsuite: Fix fortran types for Intel compilers.
2022-05-10 14:24 ` [PATCH 03/18] gdb/testsuite: Fix fortran types for Intel compilers Nils-Christian Kempke
@ 2022-05-11 9:49 ` Andrew Burgess
2022-05-11 9:57 ` Kempke, Nils-Christian
0 siblings, 1 reply; 39+ messages in thread
From: Andrew Burgess @ 2022-05-11 9:49 UTC (permalink / raw)
To: Nils-Christian Kempke, gdb-patches; +Cc: JiniSusan.George, Abdul Basit Ijaz
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.
The change itself looks fine, but I don't understand the following:
> There was not yet a way to handle the print for
> variable length strings to this commit introduces fortran_integerN as
> well.
I suspect there's just a little context missing behind this.
Thanks,
Andrew
>
> 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
^ permalink raw reply [flat|nested] 39+ messages in thread* RE: [PATCH 03/18] gdb/testsuite: Fix fortran types for Intel compilers.
2022-05-11 9:49 ` Andrew Burgess
@ 2022-05-11 9:57 ` Kempke, Nils-Christian
0 siblings, 0 replies; 39+ messages in thread
From: Kempke, Nils-Christian @ 2022-05-11 9:57 UTC (permalink / raw)
To: Andrew Burgess, gdb-patches
> -----Original Message-----
> From: Andrew Burgess <aburgess@redhat.com>
> Sent: Wednesday, May 11, 2022 11:50 AM
> 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 03/18] 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.
>
> The change itself looks fine, but I don't understand the following:
>
> > There was not yet a way to handle the print for
> > variable length strings to this commit introduces fortran_integerN as
> > well.
>
> I suspect there's just a little context missing behind this.
Ah, yes. This is just a leftover in the commit message.. It should not be there anymore.
There was an obsolete change in this commit earlier, I removed it but it appears that
I forgot to remove the part from the commit message.
I changed it locally and removed that line.
> Thanks,
> Andrew
>
>
> >
> > 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
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* [PATCH 04/18] gdb/testsuite: add local variable for passing 'getting_compiler_info' to gdb_compile
2022-05-10 14:24 [PATCH 00/18] Fortran compiler identification and ifx testsuite support Nils-Christian Kempke
` (2 preceding siblings ...)
2022-05-10 14:24 ` [PATCH 03/18] gdb/testsuite: Fix fortran types for Intel compilers Nils-Christian Kempke
@ 2022-05-10 14:24 ` Nils-Christian Kempke
2022-05-11 10:10 ` Andrew Burgess
2022-05-10 14:24 ` [PATCH 05/18] gdb/testsuite: add Fortran compiler identification to GDB Nils-Christian Kempke
` (14 subsequent siblings)
18 siblings, 1 reply; 39+ messages in thread
From: Nils-Christian Kempke @ 2022-05-10 14:24 UTC (permalink / raw)
To: gdb-patches; +Cc: aburgess, JiniSusan.George, Nils-Christian Kempke
The procedure gdb_compile used to query 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
figure out the current compiler version via the 'getting_compiler_info'
options 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 queried its options for
this setting.
In the procedure, there was already a variable 'getting_compiler_info'.
It was set to the result of the above lsearch, but 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 0 or 1 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 | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index a6f2d847a5..639a0cd1be 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -4378,6 +4378,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 0
+ } else {
+ set getting_compiler_info 1
+ }
+
# Add platform-specific options if a shared library was specified using
# "shlib=librarypath" in OPTIONS.
set new_options {}
@@ -4394,7 +4401,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 == 0
&& [lsearch -exact $options rust] == -1
&& [lsearch -exact $options ada] == -1
&& [lsearch -exact $options f90] == -1
@@ -4405,7 +4412,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 == 0
&& [lsearch -exact $options c++] != -1
&& [string match *.c $source] != 0 } {
@@ -4426,7 +4433,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 == 0 && [lsearch -exact $options f90] != -1 } {
# Fortran compile.
set mod_path [standard_output_file ""]
if [test_compiler_info "gcc-*"] {
@@ -4439,7 +4446,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"} {
@@ -4471,8 +4477,8 @@ 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 treated in the very
+ # beginning of this procedure. Do not append it to new_options.
} elseif {[regexp "^text_segment=(.*)" $opt dummy_var addr]} {
if { [linker_supports_Ttext_segment_flag] } {
# For GNU ld.
--
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
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: [PATCH 04/18] gdb/testsuite: add local variable for passing 'getting_compiler_info' to gdb_compile
2022-05-10 14:24 ` [PATCH 04/18] gdb/testsuite: add local variable for passing 'getting_compiler_info' to gdb_compile Nils-Christian Kempke
@ 2022-05-11 10:10 ` Andrew Burgess
2022-05-11 14:24 ` Kempke, Nils-Christian
0 siblings, 1 reply; 39+ messages in thread
From: Andrew Burgess @ 2022-05-11 10:10 UTC (permalink / raw)
To: Nils-Christian Kempke, gdb-patches; +Cc: JiniSusan.George
I think the subject would be better as 'move local variable ....etc...'
Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org>
writes:
> The procedure gdb_compile used to query 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
> figure out the current compiler version via the 'getting_compiler_info'
> options 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 queried its options for
> this setting.
>
> In the procedure, there was already a variable 'getting_compiler_info'.
> It was set to the result of the above lsearch, but 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.
Am I correct that this is just a clean up? And doesn't fix an actual
bug? That's not a problem, and I think this is a good cleanup, I just
wasn't 100% sure after reading the above.
> It is set to 0 or 1 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.
You can actually use 'true' and 'false' in tcl, and just treat the
variable as a boolean, so....
> ---
> gdb/testsuite/lib/gdb.exp | 18 ++++++++++++------
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
> index a6f2d847a5..639a0cd1be 100644
> --- a/gdb/testsuite/lib/gdb.exp
> +++ b/gdb/testsuite/lib/gdb.exp
> @@ -4378,6 +4378,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 0
set getting_compiler_info false
> + } else {
> + set getting_compiler_info 1
set getting_compiler_info true
> + }
> +
> # Add platform-specific options if a shared library was specified using
> # "shlib=librarypath" in OPTIONS.
> set new_options {}
> @@ -4394,7 +4401,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 == 0
if {!$getting_compiler_info
&& .... etc ....
Which I think makes it clearer that this is a boolean flag.
> && [lsearch -exact $options rust] == -1
> && [lsearch -exact $options ada] == -1
> && [lsearch -exact $options f90] == -1
> @@ -4405,7 +4412,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 == 0
> && [lsearch -exact $options c++] != -1
> && [string match *.c $source] != 0 } {
>
> @@ -4426,7 +4433,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 == 0 && [lsearch -exact $options f90] != -1 } {
> # Fortran compile.
> set mod_path [standard_output_file ""]
> if [test_compiler_info "gcc-*"] {
> @@ -4439,7 +4446,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"} {
> @@ -4471,8 +4477,8 @@ 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 treated in the very
> + # beginning of this procedure. Do not append it to new_options.
I think this comment should be reworded as:
# 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.
Thanks,
Andrew
> } elseif {[regexp "^text_segment=(.*)" $opt dummy_var addr]} {
> if { [linker_supports_Ttext_segment_flag] } {
> # For GNU ld.
> --
> 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
^ permalink raw reply [flat|nested] 39+ messages in thread* RE: [PATCH 04/18] gdb/testsuite: add local variable for passing 'getting_compiler_info' to gdb_compile
2022-05-11 10:10 ` Andrew Burgess
@ 2022-05-11 14:24 ` Kempke, Nils-Christian
0 siblings, 0 replies; 39+ messages in thread
From: Kempke, Nils-Christian @ 2022-05-11 14:24 UTC (permalink / raw)
To: Andrew Burgess, gdb-patches
> -----Original Message-----
> From: Andrew Burgess <aburgess@redhat.com>
> Sent: Wednesday, May 11, 2022 12:11 PM
> To: Kempke, Nils-Christian <nils-christian.kempke@intel.com>; gdb-
> patches@sourceware.org
> Cc: JiniSusan.George@amd.com
> Subject: Re: [PATCH 04/18] gdb/testsuite: add local variable for passing
> 'getting_compiler_info' to gdb_compile
>
>
> I think the subject would be better as 'move local variable ....etc...'
Yes, for sure. It is now
'gdb/testsuite: move getting_compiler_info to front of gdb_compile'
>
> Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org>
> writes:
>
> > The procedure gdb_compile used to query 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
> > figure out the current compiler version via the 'getting_compiler_info'
> > options 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 queried its options for
> > this setting.
> >
> > In the procedure, there was already a variable 'getting_compiler_info'.
> > It was set to the result of the above lsearch, but 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.
>
> Am I correct that this is just a clean up? And doesn't fix an actual
> bug? That's not a problem, and I think this is a good cleanup, I just
> wasn't 100% sure after reading the above.
Yes, also correct. I'll change the commit message a bit to make this more clear.
> > It is set to 0 or 1 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.
>
> You can actually use 'true' and 'false' in tcl, and just treat the
> variable as a boolean, so....
>
> > ---
> > gdb/testsuite/lib/gdb.exp | 18 ++++++++++++------
> > 1 file changed, 12 insertions(+), 6 deletions(-)
> >
> > diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
> > index a6f2d847a5..639a0cd1be 100644
> > --- a/gdb/testsuite/lib/gdb.exp
> > +++ b/gdb/testsuite/lib/gdb.exp
> > @@ -4378,6 +4378,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 0
>
> set getting_compiler_info false
>
> > + } else {
> > + set getting_compiler_info 1
>
> set getting_compiler_info true
>
> > + }
> > +
> > # Add platform-specific options if a shared library was specified using
> > # "shlib=librarypath" in OPTIONS.
> > set new_options {}
> > @@ -4394,7 +4401,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 == 0
>
> if {!$getting_compiler_info
> && .... etc ....
>
> Which I think makes it clearer that this is a boolean flag.
Yes that is true. Thanks for pointing it out, I did not know this.
Done for v2.
>
>
> > && [lsearch -exact $options rust] == -1
> > && [lsearch -exact $options ada] == -1
> > && [lsearch -exact $options f90] == -1
> > @@ -4405,7 +4412,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 == 0
> > && [lsearch -exact $options c++] != -1
> > && [string match *.c $source] != 0 } {
> >
> > @@ -4426,7 +4433,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 == 0 && [lsearch -exact $options f90] != -1 } {
> > # Fortran compile.
> > set mod_path [standard_output_file ""]
> > if [test_compiler_info "gcc-*"] {
> > @@ -4439,7 +4446,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"} {
> > @@ -4471,8 +4477,8 @@ 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 treated in the very
> > + # beginning of this procedure. Do not append it to new_options.
>
> I think this comment should be reworded as:
>
> # 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.
Done for v2.
Thanks for reviewing!
Nils
>
> Thanks,
> Andrew
>
>
> > } elseif {[regexp "^text_segment=(.*)" $opt dummy_var addr]} {
> > if { [linker_supports_Ttext_segment_flag] } {
> > # For GNU ld.
> > --
> > 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
^ permalink raw reply [flat|nested] 39+ messages in thread
* [PATCH 05/18] gdb/testsuite: add Fortran compiler identification to GDB
2022-05-10 14:24 [PATCH 00/18] Fortran compiler identification and ifx testsuite support Nils-Christian Kempke
` (3 preceding siblings ...)
2022-05-10 14:24 ` [PATCH 04/18] gdb/testsuite: add local variable for passing 'getting_compiler_info' to gdb_compile Nils-Christian Kempke
@ 2022-05-10 14:24 ` Nils-Christian Kempke
2022-05-10 14:24 ` [PATCH 06/18] gdb/testsuite: rename intel next gen c/cpp compilers Nils-Christian Kempke
` (13 subsequent siblings)
18 siblings, 0 replies; 39+ messages in thread
From: Nils-Christian Kempke @ 2022-05-10 14:24 UTC (permalink / raw)
To: gdb-patches
Cc: aburgess, JiniSusan.George, Cristian Sandu, Nils-Christian Kempke
From: Cristian Sandu <cristian.sandu@intel.com>
This commit adds a separate Fortran compiler identification mechanism to
the testsuite, similar to the existing one for C/C++. Before this
change, the options and version for the Fortran compiler specified when
running the testsuite with F90_FOR_TARGET set, was detected via its
respective C compiler. So running the testsuite as
make check TEST=gdb.fortran/*.exp CC_FOR_TARGET=gcc F90_FOR_TARGET=ifx
or even
make check TEST=gdb.fortran/*.exp F90_FOR_TARGET=ifx
would use the gcc compiler inside the procedures get_compiler_info and
test_compiler_info to identify compiler flags and the compiler version.
This could sometimes lead to unpredictable outputs. It also limited
testsuite execution to combinations where C and Fortran compiler would
come from the same family of compiers (gcc/gfortran, icc/ifort, icx/ifx,
clang/flang ..). This commit enables GDB to detect C and Fortran
compilers independently of each other.
As most/nearly all Fortran compilers have a mechanism for preprocessing
files in a C like fashion we added the exact same meachnism that already
existed for C/CXX. We let GDB preprocess a file with the compilers
Fortran preprocessor and evaluate the preprocessor defined macros in that
file.
This enables GDB to properly run heterogeneous combinations of C and
Fortran compilers such as
CC_FOR_TARGET='gcc' and F90_FOR_TARGET='ifort'
or enables one to run the testsuite without specifying a C compiler as in
make check TESTS=gdb.fortran/*.exp F90_FOR_TARGET='ifx'
make check TESTS=gdb.fortran/*.exp F90_FOR_TARGET='flang'
On the other hand this also requires one to always specify a
identification mechanism for Fortran compilers in the compiler.F90 file.
We added identification for GFORTRAN, FLANG (CLASSIC and LLVM) IFX,
IFORT, and ARMFLANG for now.
Classic and LLVM flang were each tested with their latest releases on
their respective release pages. Both get recognized by the new compiler
identification and we introduced the two names flang-classic and
flang-llvm to distinguish the two. While LLVM flang is not quite mature
enough yet for running the testsuite we still thought it would be a good
idea to include it already. For this we added a case for the fortran_main
procedure. LLVM flang uses 'MAIN__' as opposed to classic flang which
uses 'MAIN_' here.
We did not have the possibility to test ARMFLANG - the versioning scheme
here was extracted from its latest online documentation.
We changed the test_compiler_info procedure to take another optional
argument, the language string, which will be passed though to the
get_compiler_info procedure. Passing 'f90' or 'c++' here will then
trigger the C++/Fortran compiler identification within
get_compiler_info. The latter procedure was extended to also handle
the 'f90' argument (similarly to the already existing 'c++' one).
Co-authored-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
---
gdb/testsuite/gdb.fortran/assumedrank.exp | 6 +-
.../gdb.fortran/class-allocatable-array.exp | 4 +-
.../gdb.fortran/derived-type-striding.exp | 2 +-
gdb/testsuite/gdb.fortran/library-module.exp | 2 +-
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/fortran.exp | 100 +++++++++---------
gdb/testsuite/lib/gdb.exp | 24 +++--
11 files changed, 150 insertions(+), 70 deletions(-)
create mode 100644 gdb/testsuite/lib/compiler.F90
diff --git a/gdb/testsuite/gdb.fortran/assumedrank.exp b/gdb/testsuite/gdb.fortran/assumedrank.exp
index e9429b44a9..37bb825d16 100644
--- a/gdb/testsuite/gdb.fortran/assumedrank.exp
+++ b/gdb/testsuite/gdb.fortran/assumedrank.exp
@@ -21,8 +21,8 @@ standard_testfile ".f90"
load_lib fortran.exp
# Only gcc version >=11 supports assumed rank arrays.
-if { [test_compiler_info gcc*] &&
- ![test_compiler_info {gcc-1[1-9]-*}]} {
+if { [test_compiler_info {gfortran-*} f90] &&
+ ![test_compiler_info {gfortran-1[1-9]-*} f90] } {
untested "compiler does not support assumed rank"
return -1
}
@@ -59,7 +59,7 @@ while { $test_count < 500 } {
}
# Currently, flang does not support rank0.
- if {$test_count == 1 && [test_compiler_info {clang-*}]} {
+ if { $test_count == 1 && [test_compiler_info {flang-*} f90] } {
unsupported "compiler does not support rank 0"
continue
}
diff --git a/gdb/testsuite/gdb.fortran/class-allocatable-array.exp b/gdb/testsuite/gdb.fortran/class-allocatable-array.exp
index 3e92f804b1..30bdcb0165 100644
--- a/gdb/testsuite/gdb.fortran/class-allocatable-array.exp
+++ b/gdb/testsuite/gdb.fortran/class-allocatable-array.exp
@@ -37,8 +37,8 @@ gdb_continue_to_breakpoint "Break Here"
# different names, or maybe a completely different approach, for
# representing class like structures. The following tests are
# cetainly going to fail.
-# Hence the test case is modified for clang.
-if {[test_compiler_info {clang-*}]} {
+# Hence the test case is modified for flang.
+if { [test_compiler_info {flang-*} f90] } {
gdb_test "print this" " = \\( a = 0, b = \\(\\(1, 2, 3\\) \\(4, 5, 6\\)\\) \\)"
gdb_test "print this%a" " = 0"
gdb_test "print this%b" " = \\(\\(1, 2, 3\\) \\(4, 5, 6\\)\\)"
diff --git a/gdb/testsuite/gdb.fortran/derived-type-striding.exp b/gdb/testsuite/gdb.fortran/derived-type-striding.exp
index 5975e04541..5cc0137973 100644
--- a/gdb/testsuite/gdb.fortran/derived-type-striding.exp
+++ b/gdb/testsuite/gdb.fortran/derived-type-striding.exp
@@ -22,7 +22,7 @@ standard_testfile ".f90"
# Unfortunately recent versions of GCC broke the stride information in
# the DEBUG so tests in this file will fail.
-set gcc_with_broken_stride [test_compiler_info {gcc-[89]-*}]
+set gcc_with_broken_stride [test_compiler_info {gfortran-[89]-*} f90]
if {[prepare_for_testing ${testfile}.exp ${testfile} ${srcfile} \
{debug f90}]} {
diff --git a/gdb/testsuite/gdb.fortran/library-module.exp b/gdb/testsuite/gdb.fortran/library-module.exp
index 284bcf1e8d..c9774d081b 100644
--- a/gdb/testsuite/gdb.fortran/library-module.exp
+++ b/gdb/testsuite/gdb.fortran/library-module.exp
@@ -22,7 +22,7 @@ set srclibfile ${testfile}-lib.f90
set libfile [standard_output_file ${testfile}-lib.so]
# Required for -fPIC by gdb_compile_shlib.
-if [get_compiler_info] {
+if { [get_compiler_info f90] } {
warning "Could not get compiler info"
return -1
}
diff --git a/gdb/testsuite/gdb.fortran/namelist.exp b/gdb/testsuite/gdb.fortran/namelist.exp
index d6263e12fe..c875ee1567 100644
--- a/gdb/testsuite/gdb.fortran/namelist.exp
+++ b/gdb/testsuite/gdb.fortran/namelist.exp
@@ -37,7 +37,7 @@ set int [fortran_int4]
gdb_breakpoint [gdb_get_line_number "Display namelist"]
gdb_continue_to_breakpoint "Display namelist"
-if {[test_compiler_info {gcc-*}]} {
+if { [test_compiler_info {gfortran-*} f90] } {
gdb_test "ptype nml" \
"type = Type nml\r\n *$int :: a\r\n *$int :: b\r\n *End Type nml"
gdb_test "print nml" \
diff --git a/gdb/testsuite/gdb.fortran/nested-funcs-2.exp b/gdb/testsuite/gdb.fortran/nested-funcs-2.exp
index 6009cb65c5..f21dd01c5f 100644
--- a/gdb/testsuite/gdb.fortran/nested-funcs-2.exp
+++ b/gdb/testsuite/gdb.fortran/nested-funcs-2.exp
@@ -68,7 +68,8 @@ proc do_bp_tests {with_src_prefix_p with_nest_prefix_p} {
# mangling.
proc get_linkage_name_pattern {symbol_name} {
- if { [test_compiler_info icc*] || [test_compiler_info intel*]} {
+ if { [test_compiler_info {ifort-*} f90]
+ || [test_compiler_info {ifx-*} f90] } {
return "\(?:.*_\)?${symbol_name}_?"
} else {
return ${symbol_name}
diff --git a/gdb/testsuite/gdb.fortran/ptype-on-functions.exp b/gdb/testsuite/gdb.fortran/ptype-on-functions.exp
index 8e0bb710f6..021ad83ff1 100644
--- a/gdb/testsuite/gdb.fortran/ptype-on-functions.exp
+++ b/gdb/testsuite/gdb.fortran/ptype-on-functions.exp
@@ -40,7 +40,7 @@ set integer8 [fortran_int8]
# https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html ).
set stringlen ($integer8|$integer4)
-if {[test_compiler_info {clang-*}]} {
+if { [test_compiler_info {flang-*} f90] } {
set some_module_class_type "Type number"
set some_module_aux_info ", $integer8 \\(10\\)"
} else {
@@ -61,7 +61,7 @@ gdb_test "ptype say_numbers" \
"type = void \\($integer4, $integer4, $integer4\\)"
set fun_ptr_arg "$integer4"
-if {[test_compiler_info {gcc-*}]} {
+if { [test_compiler_info {gfortran-*} f90] } {
set fun_ptr_arg "REF TO -> \\( ${fun_ptr_arg} \\)"
}
@@ -72,7 +72,7 @@ gdb_test "ptype say_string" \
"type = void \\(character\[^,\]+, $stringlen\\)"
set say_array_artificial_first_arg ""
-if {[test_compiler_info {clang-*}]} {
+if { [test_compiler_info {flang-*} f90] } {
set say_array_artificial_first_arg "$integer8, "
}
diff --git a/gdb/testsuite/gdb.fortran/vla-type.exp b/gdb/testsuite/gdb.fortran/vla-type.exp
index 4ec68c4760..fc8494fe36 100755
--- a/gdb/testsuite/gdb.fortran/vla-type.exp
+++ b/gdb/testsuite/gdb.fortran/vla-type.exp
@@ -33,7 +33,7 @@ set int [fortran_int4]
# Check if not allocated VLA in type does not break
# the debugger when accessing it.
# break main for Flang compiler already breaks here
-if ![test_compiler_info "clang-*"] {
+if { ![test_compiler_info {flang-*} f90] } {
gdb_breakpoint [gdb_get_line_number "before-allocated"]
gdb_continue_to_breakpoint "before-allocated"
}
diff --git a/gdb/testsuite/lib/compiler.F90 b/gdb/testsuite/lib/compiler.F90
new file mode 100644
index 0000000000..71cf3d2c2b
--- /dev/null
+++ b/gdb/testsuite/lib/compiler.F90
@@ -0,0 +1,69 @@
+/* Copyright 2022 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+set compiler_info "unknown"
+
+#if defined (__GFORTRAN__)
+set compiler_info [join {gfortran __GNUC__ __GNUC_MINOR__ __GNUC_PATCHLEVEL__} -]
+#endif
+
+/* ARM seems to not define a patch version. */
+#if defined (__ARM_LINUX_COMPILER__)
+set compiler_info [join {armflang __armclang_major__ __armclang_minor__ 0} -]
+#endif
+
+/* Classic flang and LLVM flang emit their respective macros differently. */
+
+/* LLVM flang complains about non Fortran tokens so we do not use "{" here. */
+#if defined (__flang__)
+set major __flang_major__
+set minor __flang_minor__
+set patch __flang_patchlevel__
+set compiler_info [join "flang-llvm $major $minor $patch" -]
+#endif
+
+/* Classic Flang. */
+#if defined (__FLANG)
+set compiler_info [join {flang-classic __FLANG_MAJOR__ __FLANG_MINOR__ __FLANG_PATCHLEVEL__} -]
+#endif
+
+/* Intel LLVM emits a string like 20220100 with version 2021.2.0 and higher. */
+#if defined (__INTEL_LLVM_COMPILER)
+set major [string range __INTEL_LLVM_COMPILER 0 3]
+set minor [string range __INTEL_LLVM_COMPILER 4 5]
+set patch [string range __INTEL_LLVM_COMPILER 6 7]
+set compiler_info [join "ifx $major $minor $patch" -]
+#elif defined (__INTEL_COMPILER)
+/* Starting with 2021 the ifort versioning scheme changed. Before, Intel ifort
+ would define its version as e.g. 19.0.0 or rather __INTEL_COMPILER would be
+ emitted as 1900. With 2021 the versioning became e.g. 2021.1 defined in
+ __INTEL_COMPILER.__INTEL_COMPILER_UPDATE. No patch is emitted since the
+ change. This compiler identification might not work with ifort versions
+ smaller than 10. */
+#if (__INTEL_COMPILER < 2021)
+set major [string range __INTEL_COMPILER 0 1]
+set minor [string range __INTEL_COMPILER 2 2]
+#if defined (__INTEL_COMPILER_UPDATE)
+set patch __INTEL_COMPILER_UPDATE
+#else
+set patch [string range __INTEL_COMPILER 3 3]
+#endif
+#else
+set major __INTEL_COMPILER
+set minor __INTEL_COMPILER_UPDATE
+set patch 0
+#endif
+set compiler_info [join "ifort $major $minor $patch" -]
+#endif
diff --git a/gdb/testsuite/lib/fortran.exp b/gdb/testsuite/lib/fortran.exp
index 9531d393a1..9ee4208fb8 100644
--- a/gdb/testsuite/lib/fortran.exp
+++ b/gdb/testsuite/lib/fortran.exp
@@ -30,15 +30,15 @@ proc set_lang_fortran {} {
}
proc fortran_int4 {} {
- if {[test_compiler_info {gcc-4-[012]-*}]} {
+ if {[test_compiler_info {gfortran-4-[012]-*} f90]} {
return "int4"
- } elseif {[test_compiler_info {gcc-*}]} {
+ } elseif {[test_compiler_info {gfortran-*} f90]} {
return "integer\\(kind=4\\)"
- } elseif {[test_compiler_info {clang-*}]} {
+ } elseif {[test_compiler_info {flang-*} f90]} {
return "integer"
- } elseif {[test_compiler_info {icc-*}]} {
+ } elseif {[test_compiler_info {ifort-*} f90]} {
return "INTEGER\\(4\\)"
- } elseif {[test_compiler_info {intel-*}]} {
+ } elseif {[test_compiler_info {ifx-*} f90]} {
return "INTEGER\\*4"
} else {
return "unknown"
@@ -46,15 +46,15 @@ proc fortran_int4 {} {
}
proc fortran_int8 {} {
- if {[test_compiler_info {gcc-4-[012]-*}]} {
+ if {[test_compiler_info {gfortran-4-[012]-*} f90]} {
return "int8"
- } elseif {[test_compiler_info {gcc-*}]} {
+ } elseif {[test_compiler_info {gfortran-*} f90]} {
return "integer\\(kind=8\\)"
- } elseif {[test_compiler_info {clang-*}]} {
+ } elseif {[test_compiler_info {flang-*} f90]} {
return "integer\\*8"
- } elseif {[test_compiler_info {icc-*}]} {
+ } elseif {[test_compiler_info {ifort-*} f90]} {
return "INTEGER\\(8\\)"
- } elseif {[test_compiler_info {intel-*}]} {
+ } elseif {[test_compiler_info {ifx-*} f90]} {
return "INTEGER\\*8"
} else {
return "unknown"
@@ -62,15 +62,15 @@ proc fortran_int8 {} {
}
proc fortran_real4 {} {
- if {[test_compiler_info {gcc-4-[012]-*}]} {
+ if {[test_compiler_info {gfortran-4-[012]-*} f90]} {
return "real4"
- } elseif {[test_compiler_info {gcc-*}]} {
+ } elseif {[test_compiler_info {gfortran-*} f90]} {
return "real\\(kind=4\\)"
- } elseif {[test_compiler_info {clang-*}]} {
+ } elseif {[test_compiler_info {flang-*} f90]} {
return "real"
- } elseif {[test_compiler_info {icc-*}]} {
+ } elseif {[test_compiler_info {ifort-*} f90]} {
return "REAL\\(4\\)"
- } elseif {[test_compiler_info {intel-*}]} {
+ } elseif {[test_compiler_info {ifx-*} f90]} {
return "REAL\\*4"
} else {
return "unknown"
@@ -78,15 +78,15 @@ proc fortran_real4 {} {
}
proc fortran_real8 {} {
- if {[test_compiler_info {gcc-4-[012]-*}]} {
+ if {[test_compiler_info {gfortran-4-[012]-*} f90]} {
return "real8"
- } elseif {[test_compiler_info {gcc-*}]} {
+ } elseif {[test_compiler_info {gfortran-*} f90]} {
return "real\\(kind=8\\)"
- } elseif {[test_compiler_info {clang-*}]} {
+ } elseif {[test_compiler_info {flang-*} f90]} {
return "double precision"
- } elseif {[test_compiler_info {icc-*}]} {
+ } elseif {[test_compiler_info {ifort-*} f90]} {
return "REAL\\(8\\)"
- } elseif {[test_compiler_info {intel-*}]} {
+ } elseif {[test_compiler_info {ifx-*} f90]} {
return "REAL\\*8"
} else {
return "unknown"
@@ -94,15 +94,15 @@ proc fortran_real8 {} {
}
proc fortran_complex4 {} {
- if {[test_compiler_info {gcc-4-[012]-*}]} {
+ if {[test_compiler_info {gfortran-4-[012]-*} f90]} {
return "complex4"
- } elseif {[test_compiler_info {gcc-*}]} {
+ } elseif {[test_compiler_info {gfortran-*} f90]} {
return "complex\\(kind=4\\)"
- } elseif {[test_compiler_info {clang-*}]} {
+ } elseif {[test_compiler_info {flang-*} f90]} {
return "complex"
- } elseif {[test_compiler_info {icc-*}]} {
+ } elseif {[test_compiler_info {ifort-*} f90]} {
return "COMPLEX\\(4\\)"
- } elseif {[test_compiler_info {intel-*}]} {
+ } elseif {[test_compiler_info {ifx-*} f90]} {
return "COMPLEX\\*8"
} else {
return "unknown"
@@ -110,15 +110,15 @@ proc fortran_complex4 {} {
}
proc fortran_complex8 {} {
- if {[test_compiler_info {gcc-4-[012]-*}]} {
+ if {[test_compiler_info {gfortran-4-[012]-*} f90]} {
return "complex8"
- } elseif {[test_compiler_info {gcc-*}]} {
+ } elseif {[test_compiler_info {gfortran-*} f90]} {
return "complex\\(kind=8\\)"
- } elseif {[test_compiler_info {clang-*}]} {
+ } elseif {[test_compiler_info {flang-*} f90]} {
return "double complex"
- } elseif {[test_compiler_info {icc-*}]} {
+ } elseif {[test_compiler_info {ifort-*} f90]} {
return "COMPLEX\\(8\\)"
- } elseif {[test_compiler_info {intel-*}]} {
+ } elseif {[test_compiler_info {ifx-*} f90]} {
return "COMPLEX\\*16"
} else {
return "unknown"
@@ -126,15 +126,15 @@ proc fortran_complex8 {} {
}
proc fortran_complex16 {} {
- if {[test_compiler_info {gcc-4-[012]-*}]} {
+ if {[test_compiler_info {gfortran-4-[012]-*} f90]} {
return "complex16"
- } elseif {[test_compiler_info {gcc-*}]} {
+ } elseif {[test_compiler_info {gfortran-*} f90]} {
return "complex\\(kind=16\\)"
- } elseif {[test_compiler_info {clang-*}]} {
+ } elseif {[test_compiler_info {flang-*} f90]} {
return "quad complex"
- } elseif {[test_compiler_info {icc-*}]} {
+ } elseif {[test_compiler_info {ifort-*} f90]} {
return "COMPLEX\\(16\\)"
- } elseif {[test_compiler_info {intel-*}]} {
+ } elseif {[test_compiler_info {ifx-*} f90]} {
return "COMPLEX\\*32"
} else {
return "unknown"
@@ -142,15 +142,15 @@ proc fortran_complex16 {} {
}
proc fortran_logical4 {} {
- if {[test_compiler_info {gcc-4-[012]-*}]} {
+ if {[test_compiler_info {gfortran-4-[012]-*} f90]} {
return "logical4"
- } elseif {[test_compiler_info {gcc-*}]} {
+ } elseif {[test_compiler_info {gfortran-*} f90]} {
return "logical\\(kind=4\\)"
- } elseif {[test_compiler_info {clang-*}]} {
+ } elseif {[test_compiler_info {flang-*} f90]} {
return "logical"
- } elseif {[test_compiler_info {icc-*}]} {
+ } elseif {[test_compiler_info {ifort-*} f90]} {
return "LOGICAL\\(4\\)"
- } elseif {[test_compiler_info {intel-*}]} {
+ } elseif {[test_compiler_info {ifx-*} f90]} {
return "LOGICAL\\*4"
} else {
return "unknown"
@@ -158,15 +158,15 @@ proc fortran_logical4 {} {
}
proc fortran_character1 {} {
- if {[test_compiler_info {gcc-4-[012]-*}]} {
+ if {[test_compiler_info {gfortran-4-[012]-*} f90]} {
return "character1"
- } elseif {[test_compiler_info {gcc-*}]} {
+ } elseif {[test_compiler_info {gfortran-*} f90]} {
return "character\\(kind=1\\)"
- } elseif {[test_compiler_info {clang-*}]} {
+ } elseif {[test_compiler_info {flang-*} f90]} {
return "character"
- } elseif {[test_compiler_info {icc-*}]} {
+ } elseif {[test_compiler_info {ifort-*} f90]} {
return "CHARACTER\\(1\\)"
- } elseif {[test_compiler_info {intel-*}]} {
+ } elseif {[test_compiler_info {ifx-*} f90]} {
return "CHARACTER\\*1"
} else {
return "unknown"
@@ -176,12 +176,12 @@ proc fortran_character1 {} {
# Return name of the main procedure based on the compiler version.
proc fortran_main {} {
- if {[test_compiler_info {gcc-4-[012]-*}]
- || [test_compiler_info {gcc-*}]
- || [test_compiler_info {icc-*}]
- || [test_compiler_info {intel-*}]} {
+ if {[test_compiler_info {gfortran-*} f90]
+ || [test_compiler_info {ifort-*} f90]
+ || [test_compiler_info {ifx-*} f90]
+ || [test_compiler_info {flang-llvm-*} f90]} {
return "MAIN__"
- } elseif {[test_compiler_info {clang-*}]} {
+ } elseif {[test_compiler_info {flang-classic-*} f90]} {
return "MAIN_"
} else {
return "unknown"
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 639a0cd1be..b8e61d846d 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -4072,14 +4072,14 @@ set gcc_compiled 0
# -- chastain 2004-01-06
proc get_compiler_info {{arg ""}} {
- # For compiler.c and compiler.cc
+ # For compiler.c, compiler.cc and compiler.F90.
global srcdir
# I am going to play with the log to keep noise out.
global outdir
global tool
- # These come from compiler.c or compiler.cc
+ # These come from compiler.c, compiler.cc or compiler.F90.
global compiler_info
# Legacy global data symbols.
@@ -4094,6 +4094,8 @@ proc get_compiler_info {{arg ""}} {
set ifile "${srcdir}/lib/compiler.c"
if { $arg == "c++" } {
set ifile "${srcdir}/lib/compiler.cc"
+ } elseif { $arg == "f90" } {
+ set ifile "${srcdir}/lib/compiler.F90"
}
# Run $ifile through the right preprocessor.
@@ -4124,6 +4126,10 @@ proc get_compiler_info {{arg ""}} {
# eval this line
verbose "get_compiler_info: $cppline" 2
eval "$cppline"
+ } elseif { [ regexp "flang.*warning.*'-fdiagnostics-color=never'" "$cppline"] } {
+ # Both flang preprocessors (llvm flang and classic flang) print a
+ # warning for the unused -fdiagnostics-color=never, so we skip this
+ # output line here.
} else {
# unknown line
verbose -log "get_compiler_info: $cppline"
@@ -4161,9 +4167,9 @@ proc get_compiler_info {{arg ""}} {
# Otherwise the argument is a glob-style expression to match against
# compiler_info.
-proc test_compiler_info { {compiler ""} } {
+proc test_compiler_info { {compiler ""} {language ""} } {
global compiler_info
- get_compiler_info
+ get_compiler_info $language
# If no arg, return the compiler_info string.
if [string match "" $compiler] {
@@ -4436,10 +4442,10 @@ proc gdb_compile {source dest type options} {
if { $getting_compiler_info == 0 && [lsearch -exact $options f90] != -1 } {
# Fortran compile.
set mod_path [standard_output_file ""]
- if [test_compiler_info "gcc-*"] {
+ if { [test_compiler_info {gfortran-*} f90] } {
lappend new_options "additional_flags=-J${mod_path}"
- } elseif { [test_compiler_info {icc-*}]
- || [test_compiler_info {intel-*}] } {
+ } elseif { [test_compiler_info {ifort-*} f90]
+ || [test_compiler_info {ifx-*} f90] } {
lappend new_options "additional_flags=-module ${mod_path}"
}
}
@@ -4735,6 +4741,8 @@ proc gdb_compile_shlib_1 {sources dest options} {
set info_options ""
if { [lsearch -exact $options "c++"] >= 0 } {
set info_options "c++"
+ } elseif { [lsearch -exact $options "f90"] >= 0 } {
+ set info_options "f90"
}
if [get_compiler_info ${info_options}] {
return -1
@@ -6922,6 +6930,8 @@ proc build_executable_from_specs {testname executable options args} {
set info_options ""
if { [lsearch -exact $options "c++"] >= 0 } {
set info_options "c++"
+ } elseif { [lsearch -exact $options "f90"] >= 0 } {
+ set info_options "f90"
}
if [get_compiler_info ${info_options}] {
return -1
--
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
^ permalink raw reply [flat|nested] 39+ messages in thread* [PATCH 06/18] gdb/testsuite: rename intel next gen c/cpp compilers
2022-05-10 14:24 [PATCH 00/18] Fortran compiler identification and ifx testsuite support Nils-Christian Kempke
` (4 preceding siblings ...)
2022-05-10 14:24 ` [PATCH 05/18] gdb/testsuite: add Fortran compiler identification to GDB Nils-Christian Kempke
@ 2022-05-10 14:24 ` Nils-Christian Kempke
2022-05-11 11:23 ` Andrew Burgess
2022-05-10 14:24 ` [PATCH 07/18] gdb/testsuite: disable charset.exp for intel compilers Nils-Christian Kempke
` (12 subsequent siblings)
18 siblings, 1 reply; 39+ messages in thread
From: Nils-Christian Kempke @ 2022-05-10 14:24 UTC (permalink / raw)
To: gdb-patches; +Cc: aburgess, JiniSusan.George, 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-*'.
---
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
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: [PATCH 06/18] gdb/testsuite: rename intel next gen c/cpp compilers
2022-05-10 14:24 ` [PATCH 06/18] gdb/testsuite: rename intel next gen c/cpp compilers Nils-Christian Kempke
@ 2022-05-11 11:23 ` Andrew Burgess
2022-05-11 14:28 ` Kempke, Nils-Christian
0 siblings, 1 reply; 39+ messages in thread
From: Andrew Burgess @ 2022-05-11 11:23 UTC (permalink / raw)
To: Nils-Christian Kempke, gdb-patches; +Cc: JiniSusan.George
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-*'.
I think it is worth mentioning here that the intel-* pattern is not
(currently) checked for in any compiler_info check. My first thought
when I saw this was that you'd surely forgotten to update the patterns
within the testsuite...
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
^ permalink raw reply [flat|nested] 39+ messages in thread* RE: [PATCH 06/18] gdb/testsuite: rename intel next gen c/cpp compilers
2022-05-11 11:23 ` Andrew Burgess
@ 2022-05-11 14:28 ` Kempke, Nils-Christian
0 siblings, 0 replies; 39+ messages in thread
From: Kempke, Nils-Christian @ 2022-05-11 14:28 UTC (permalink / raw)
To: Andrew Burgess, gdb-patches
> -----Original Message-----
> From: Andrew Burgess <aburgess@redhat.com>
> Sent: Wednesday, May 11, 2022 1:23 PM
> To: Kempke, Nils-Christian <nils-christian.kempke@intel.com>; gdb-
> patches@sourceware.org
> Cc: JiniSusan.George@amd.com
> Subject: Re: [PATCH 06/18] gdb/testsuite: rename intel next gen c/cpp
> compilers
>
> 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-*'.
>
> I think it is worth mentioning here that the intel-* pattern is not
> (currently) checked for in any compiler_info check. My first thought
> when I saw this was that you'd surely forgotten to update the patterns
> within the testsuite...
Yes that is true. I think we have a few internal usages but non actually
visible in the testsuite.
Done for v2.
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* [PATCH 07/18] gdb/testsuite: disable charset.exp for intel compilers
2022-05-10 14:24 [PATCH 00/18] Fortran compiler identification and ifx testsuite support Nils-Christian Kempke
` (5 preceding siblings ...)
2022-05-10 14:24 ` [PATCH 06/18] gdb/testsuite: rename intel next gen c/cpp compilers Nils-Christian Kempke
@ 2022-05-10 14:24 ` Nils-Christian Kempke
2022-05-10 14:24 ` [PATCH 08/18] testsuite, fortran: make print-formatted.exp more robust Nils-Christian Kempke
` (11 subsequent siblings)
18 siblings, 0 replies; 39+ messages in thread
From: Nils-Christian Kempke @ 2022-05-10 14:24 UTC (permalink / raw)
To: gdb-patches; +Cc: aburgess, JiniSusan.George, Nils-Christian Kempke
The test specifically tests for the Fortran CHARACTER(KIND=4) which is
not available in ifx/ifort.
Since the other characters are also printed elsewhere, we disable this
test for the unsupported compilers.
---
gdb/testsuite/gdb.fortran/charset.exp | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/gdb/testsuite/gdb.fortran/charset.exp b/gdb/testsuite/gdb.fortran/charset.exp
index b462124e02..e8f834adb6 100644
--- a/gdb/testsuite/gdb.fortran/charset.exp
+++ b/gdb/testsuite/gdb.fortran/charset.exp
@@ -21,6 +21,11 @@ if { [skip_fortran_tests] } { return -1 }
standard_testfile .f90
load_lib fortran.exp
+# Ifx, and ifort do not support kind=4 for CHARACTER.
+if { [test_compiler_info {ifx-*} f90] || [test_compiler_info {ifort-*} f90] } {
+ return -1
+}
+
if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile} {debug additional_flags=-fbackslash f90}] } {
return -1
}
--
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
^ permalink raw reply [flat|nested] 39+ messages in thread* [PATCH 08/18] testsuite, fortran: make print-formatted.exp more robust
2022-05-10 14:24 [PATCH 00/18] Fortran compiler identification and ifx testsuite support Nils-Christian Kempke
` (6 preceding siblings ...)
2022-05-10 14:24 ` [PATCH 07/18] gdb/testsuite: disable charset.exp for intel compilers Nils-Christian Kempke
@ 2022-05-10 14:24 ` Nils-Christian Kempke
2022-05-11 11:32 ` Andrew Burgess
2022-05-10 14:24 ` [PATCH 09/18] testsuite, fortran: add required external keyword Nils-Christian Kempke
` (10 subsequent siblings)
18 siblings, 1 reply; 39+ messages in thread
From: Nils-Christian Kempke @ 2022-05-10 14:24 UTC (permalink / raw)
To: gdb-patches; +Cc: aburgess, JiniSusan.George, Nils-Christian Kempke
The test was written in a way that assumed, that going to main and
issuing a single next command would automatically end up after the
assign statement for ii. This was true for gfortran and ifort, but not
for ifx leading to a failed test. For ifx, GDB actually was at
the assign statment (not past it) and printing 'ii' there would lead to
GDB displaying it as 0 (instead of 10), failing the test.
I changed this to become more robust and added a line past the
assignment with a comment, as is commonly done all over the testsuite.
After this change the test passes for all, gfortran/ifort/ifx/flang.
---
gdb/testsuite/gdb.fortran/print-formatted.exp | 3 ++-
gdb/testsuite/gdb.fortran/print-formatted.f90 | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/gdb/testsuite/gdb.fortran/print-formatted.exp b/gdb/testsuite/gdb.fortran/print-formatted.exp
index eaeca1ede2..59b7148852 100644
--- a/gdb/testsuite/gdb.fortran/print-formatted.exp
+++ b/gdb/testsuite/gdb.fortran/print-formatted.exp
@@ -29,7 +29,8 @@ if { ![fortran_runto_main] } {
return -1
}
-gdb_test "next" ".*" "go to the end of the program"
+gdb_breakpoint [gdb_get_line_number "End of program"]
+gdb_continue_to_breakpoint "End of program" ".*End of program.*"
gdb_test "set output-radix 16" \
"Output radix now set to decimal 16, hex 10, octal 20." \
diff --git a/gdb/testsuite/gdb.fortran/print-formatted.f90 b/gdb/testsuite/gdb.fortran/print-formatted.f90
index 63048032b1..f37fdafe97 100644
--- a/gdb/testsuite/gdb.fortran/print-formatted.f90
+++ b/gdb/testsuite/gdb.fortran/print-formatted.f90
@@ -17,4 +17,5 @@ program printformatted
integer :: ii
ii = 10
+ print *, ii ! End of program.
end program printformatted
--
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
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: [PATCH 08/18] testsuite, fortran: make print-formatted.exp more robust
2022-05-10 14:24 ` [PATCH 08/18] testsuite, fortran: make print-formatted.exp more robust Nils-Christian Kempke
@ 2022-05-11 11:32 ` Andrew Burgess
2022-05-11 14:32 ` Kempke, Nils-Christian
0 siblings, 1 reply; 39+ messages in thread
From: Andrew Burgess @ 2022-05-11 11:32 UTC (permalink / raw)
To: Nils-Christian Kempke, gdb-patches; +Cc: JiniSusan.George
Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org>
writes:
> The test was written in a way that assumed, that going to main and
> issuing a single next command would automatically end up after the
> assign statement for ii. This was true for gfortran and ifort, but not
> for ifx leading to a failed test. For ifx, GDB actually was at
> the assign statment (not past it) and printing 'ii' there would lead to
> GDB displaying it as 0 (instead of 10), failing the test.
>
> I changed this to become more robust and added a line past the
> assignment with a comment, as is commonly done all over the testsuite.
>
> After this change the test passes for all, gfortran/ifort/ifx/flang.
I have no problem with this change, the point of the test is clearly the
print formatting rather than the behaviour of 'next'.
That said, isn't the behaviour for ifx indicating a bug in the generated
debug info? The program only has the single 'ii = 10' statement, so
surely when we run to main, that's where we should stop? Then 'next'
should move past that line?
If you agree then it might be worth mentioning that this is working
around the compiler bug.
Thanks,
Andrew
> ---
> gdb/testsuite/gdb.fortran/print-formatted.exp | 3 ++-
> gdb/testsuite/gdb.fortran/print-formatted.f90 | 1 +
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/gdb/testsuite/gdb.fortran/print-formatted.exp b/gdb/testsuite/gdb.fortran/print-formatted.exp
> index eaeca1ede2..59b7148852 100644
> --- a/gdb/testsuite/gdb.fortran/print-formatted.exp
> +++ b/gdb/testsuite/gdb.fortran/print-formatted.exp
> @@ -29,7 +29,8 @@ if { ![fortran_runto_main] } {
> return -1
> }
>
> -gdb_test "next" ".*" "go to the end of the program"
> +gdb_breakpoint [gdb_get_line_number "End of program"]
> +gdb_continue_to_breakpoint "End of program" ".*End of program.*"
>
> gdb_test "set output-radix 16" \
> "Output radix now set to decimal 16, hex 10, octal 20." \
> diff --git a/gdb/testsuite/gdb.fortran/print-formatted.f90 b/gdb/testsuite/gdb.fortran/print-formatted.f90
> index 63048032b1..f37fdafe97 100644
> --- a/gdb/testsuite/gdb.fortran/print-formatted.f90
> +++ b/gdb/testsuite/gdb.fortran/print-formatted.f90
> @@ -17,4 +17,5 @@ program printformatted
> integer :: ii
>
> ii = 10
> + print *, ii ! End of program.
> end program printformatted
> --
> 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
^ permalink raw reply [flat|nested] 39+ messages in thread* RE: [PATCH 08/18] testsuite, fortran: make print-formatted.exp more robust
2022-05-11 11:32 ` Andrew Burgess
@ 2022-05-11 14:32 ` Kempke, Nils-Christian
0 siblings, 0 replies; 39+ messages in thread
From: Kempke, Nils-Christian @ 2022-05-11 14:32 UTC (permalink / raw)
To: Andrew Burgess, gdb-patches
> -----Original Message-----
> From: Andrew Burgess <aburgess@redhat.com>
> Sent: Wednesday, May 11, 2022 1:32 PM
> To: Kempke, Nils-Christian <nils-christian.kempke@intel.com>; gdb-
> patches@sourceware.org
> Cc: JiniSusan.George@amd.com
> Subject: Re: [PATCH 08/18] testsuite, fortran: make print-formatted.exp
> more robust
>
> Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org>
> writes:
>
> > The test was written in a way that assumed, that going to main and
> > issuing a single next command would automatically end up after the
> > assign statement for ii. This was true for gfortran and ifort, but not
> > for ifx leading to a failed test. For ifx, GDB actually was at
> > the assign statment (not past it) and printing 'ii' there would lead to
> > GDB displaying it as 0 (instead of 10), failing the test.
> >
> > I changed this to become more robust and added a line past the
> > assignment with a comment, as is commonly done all over the testsuite.
> >
> > After this change the test passes for all, gfortran/ifort/ifx/flang.
>
> I have no problem with this change, the point of the test is clearly the
> print formatting rather than the behaviour of 'next'.
>
> That said, isn't the behaviour for ifx indicating a bug in the generated
> debug info? The program only has the single 'ii = 10' statement, so
> surely when we run to main, that's where we should stop? Then 'next'
> should move past that line?
>
> If you agree then it might be worth mentioning that this is working
> around the compiler bug.
>
You are completely right here. We also think this is an ifx bug. In this light,
I would rather like to drop this patch from this series. We'll instead work on
fixing this bug in ifx.
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* [PATCH 09/18] testsuite, fortran: add required external keyword
2022-05-10 14:24 [PATCH 00/18] Fortran compiler identification and ifx testsuite support Nils-Christian Kempke
` (7 preceding siblings ...)
2022-05-10 14:24 ` [PATCH 08/18] testsuite, fortran: make print-formatted.exp more robust Nils-Christian Kempke
@ 2022-05-10 14:24 ` Nils-Christian Kempke
2022-05-10 14:24 ` [PATCH 10/18] testsuite, fortran: add compiler dependent types to dynamic-ptype-whatis Nils-Christian Kempke
` (9 subsequent siblings)
18 siblings, 0 replies; 39+ messages in thread
From: Nils-Christian Kempke @ 2022-05-10 14:24 UTC (permalink / raw)
To: gdb-patches; +Cc: aburgess, JiniSusan.George, Nils-Christian Kempke
Currenlty, ifx/ifort cannot compile the given executable as it is not
valid Fortran. It is missing the external keyword on the
no_arg_subroutine. Gfortran compiles the example but this is actually
a bug and there is an open gcc ticket for this here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50377
Adding the keyword does not change the gfortran compiling of the example.
It will, however, prevent a future fail once 50377 has been addressed.
---
gdb/testsuite/gdb.fortran/function-calls.f90 | 1 +
1 file changed, 1 insertion(+)
diff --git a/gdb/testsuite/gdb.fortran/function-calls.f90 b/gdb/testsuite/gdb.fortran/function-calls.f90
index b56c5c97f7..e9c8c44afd 100644
--- a/gdb/testsuite/gdb.fortran/function-calls.f90
+++ b/gdb/testsuite/gdb.fortran/function-calls.f90
@@ -198,6 +198,7 @@ program function_calls
type(cart_nd) :: c_nd
type(nested_cart_3d) :: nested_c
character(40) :: returned_string, returned_string_debugger
+ external no_arg_subroutine
real8 = 3.00
real4 = 9.3
integer_array = 17
--
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
^ permalink raw reply [flat|nested] 39+ messages in thread* [PATCH 10/18] testsuite, fortran: add compiler dependent types to dynamic-ptype-whatis
2022-05-10 14:24 [PATCH 00/18] Fortran compiler identification and ifx testsuite support Nils-Christian Kempke
` (8 preceding siblings ...)
2022-05-10 14:24 ` [PATCH 09/18] testsuite, fortran: add required external keyword Nils-Christian Kempke
@ 2022-05-10 14:24 ` Nils-Christian Kempke
2022-05-10 14:24 ` [PATCH 11/18] testsuite, fortran: Add '-debug-parameters all' when compiling with ifx Nils-Christian Kempke
` (8 subsequent siblings)
18 siblings, 0 replies; 39+ messages in thread
From: Nils-Christian Kempke @ 2022-05-10 14:24 UTC (permalink / raw)
To: gdb-patches; +Cc: aburgess, JiniSusan.George, Nils-Christian Kempke
The test was earlier not using the compiler dependent type print system
in fortran.exp. I changed this. It should generally improve the test
performance for different compilers. For ifx and gfortran I do not see
any failures.
---
.../gdb.fortran/dynamic-ptype-whatis.exp | 79 ++++++++++---------
1 file changed, 41 insertions(+), 38 deletions(-)
diff --git a/gdb/testsuite/gdb.fortran/dynamic-ptype-whatis.exp b/gdb/testsuite/gdb.fortran/dynamic-ptype-whatis.exp
index 7367b1d46b..f0463f4f62 100644
--- a/gdb/testsuite/gdb.fortran/dynamic-ptype-whatis.exp
+++ b/gdb/testsuite/gdb.fortran/dynamic-ptype-whatis.exp
@@ -34,62 +34,65 @@ if {![fortran_runto_main]} {
gdb_breakpoint [gdb_get_line_number "Break Here"]
gdb_continue_to_breakpoint "Break Here"
-gdb_test "whatis var1" "type = real\\(kind=4\\) \\(3\\)"
-gdb_test "whatis var2" "type = real\\(kind=4\\), allocatable \\(4\\)"
+set real4 [fortran_real4]
+set int4 [fortran_int4]
+
+gdb_test "whatis var1" "type = ${real4} \\(3\\)"
+gdb_test "whatis var2" "type = ${real4}, allocatable \\(4\\)"
gdb_test "whatis var3" "type = Type type1"
gdb_test "whatis var4" "type = Type type2"
gdb_test "whatis var5" "type = Type type3"
gdb_test "whatis var6" "type = Type type4"
gdb_test "whatis var7" "type = Type type5"
-gdb_test "ptype var1" "type = real\\(kind=4\\) \\(3\\)"
-gdb_test "ptype var2" "type = real\\(kind=4\\), allocatable \\(4\\)"
+gdb_test "ptype var1" "type = ${real4} \\(3\\)"
+gdb_test "ptype var2" "type = ${real4}, allocatable \\(4\\)"
gdb_test "ptype var3" \
[ multi_line "type = Type type1" \
- " integer\\(kind=4\\) :: spacer" \
- " integer\\(kind=4\\) :: t1_i" \
+ " ${int4} :: spacer" \
+ " ${int4} :: t1_i" \
"End Type type1" ]
gdb_test "ptype var4" \
[multi_line "type = Type type2" \
- " integer\\(kind=4\\) :: spacer" \
+ " ${int4} :: spacer" \
" Type type1, allocatable :: t2_array\\(3\\)" \
"End Type type2"]
gdb_test "ptype var5" \
[ multi_line "type = Type type3" \
- " integer\\(kind=4\\) :: spacer" \
+ " ${int4} :: spacer" \
" Type type1 :: t3_array\\(3\\)"\
"End Type type3" ]
gdb_test "ptype var6" \
[ multi_line "type = Type type4" \
- " integer\\(kind=4\\) :: spacer" \
+ " ${int4} :: spacer" \
" Type type2, allocatable :: t4_array\\(3\\)" \
"End Type type4" ]
gdb_test "ptype var7" \
[ multi_line "type = Type type5" \
- " integer\\(kind=4\\) :: spacer" \
+ " ${int4} :: spacer" \
" Type type2 :: t5_array\\(4\\)" \
"End Type type5" ]
-gdb_test "whatis var3%t1_i" "type = integer\\(kind=4\\)"
+gdb_test "whatis var3%t1_i" "type = ${int4}"
gdb_test "whatis var4%t2_array" "type = Type type1, allocatable \\(3\\)"
gdb_test "whatis var5%t3_array" "type = Type type1 \\(3\\)"
gdb_test "whatis var6%t4_array" "type = Type type2, allocatable \\(3\\)"
gdb_test "whatis var7%t5_array" "type = Type type2 \\(4\\)"
-gdb_test "ptype var3%t1_i" "type = integer\\(kind=4\\)"
+gdb_test "ptype var3%t1_i" "type = ${int4}"
gdb_test "ptype var4%t2_array" [ multi_line "type = Type type1" \
- " integer\\(kind=4\\) :: spacer" \
- " integer\\(kind=4\\) :: t1_i" \
+ " ${int4} :: spacer" \
+ " ${int4} :: t1_i" \
"End Type type1, allocatable \\(3\\)" ]
gdb_test "ptype var5%t3_array" [ multi_line "type = Type type1" \
- " integer\\(kind=4\\) :: spacer" \
- " integer\\(kind=4\\) :: t1_i" \
+ " ${int4} :: spacer" \
+ " ${int4} :: t1_i" \
"End Type type1 \\(3\\)" ]
gdb_test "ptype var6%t4_array" \
[ multi_line "type = Type type2" \
- " integer\\(kind=4\\) :: spacer" \
+ " ${int4} :: spacer" \
" Type type1, allocatable :: t2_array\\(:\\)" \
"End Type type2, allocatable \\(3\\)" ]
gdb_test "ptype var7%t5_array" \
[ multi_line "type = Type type2" \
- " integer\\(kind=4\\) :: spacer" \
+ " ${int4} :: spacer" \
" Type type1, allocatable :: t2_array\\(:\\)" \
"End Type type2 \\(4\\)" ]
gdb_test "whatis var4%t2_array(1)" "type = Type type1"
@@ -98,41 +101,41 @@ gdb_test "whatis var6%t4_array(1)" "type = Type type2"
gdb_test "whatis var7%t5_array(1)" "type = Type type2"
gdb_test "ptype var4%t2_array(1)" \
[ multi_line "type = Type type1" \
- " integer\\(kind=4\\) :: spacer" \
- " integer\\(kind=4\\) :: t1_i" \
+ " ${int4} :: spacer" \
+ " ${int4} :: t1_i" \
"End Type type1" ]
gdb_test "ptype var5%t3_array(1)" \
[ multi_line "type = Type type1" \
- " integer\\(kind=4\\) :: spacer" \
- " integer\\(kind=4\\) :: t1_i" \
+ " ${int4} :: spacer" \
+ " ${int4} :: t1_i" \
"End Type type1" ]
gdb_test "ptype var6%t4_array(1)" \
[ multi_line "type = Type type2" \
- " integer\\(kind=4\\) :: spacer" \
+ " ${int4} :: spacer" \
" Type type1, allocatable :: t2_array\\(2\\)" \
"End Type type2" ]
gdb_test "ptype var7%t5_array(1)" \
[ multi_line "type = Type type2" \
- " integer\\(kind=4\\) :: spacer" \
+ " ${int4} :: spacer" \
" Type type1, allocatable :: t2_array\\(2\\)" \
"End Type type2" ]
-gdb_test "whatis var4%t2_array(1)%t1_i" "type = integer\\(kind=4\\)"
-gdb_test "whatis var5%t3_array(1)%t1_i" "type = integer\\(kind=4\\)"
+gdb_test "whatis var4%t2_array(1)%t1_i" "type = ${int4}"
+gdb_test "whatis var5%t3_array(1)%t1_i" "type = ${int4}"
gdb_test "whatis var6%t4_array(1)%t2_array" \
"type = Type type1, allocatable \\(2\\)"
gdb_test "whatis var7%t5_array(1)%t2_array" \
"type = Type type1, allocatable \\(2\\)"
-gdb_test "ptype var4%t2_array(1)%t1_i" "type = integer\\(kind=4\\)"
-gdb_test "ptype var5%t3_array(1)%t1_i" "type = integer\\(kind=4\\)"
+gdb_test "ptype var4%t2_array(1)%t1_i" "type = ${int4}"
+gdb_test "ptype var5%t3_array(1)%t1_i" "type = ${int4}"
gdb_test "ptype var6%t4_array(1)%t2_array" \
[ multi_line "type = Type type1" \
- " integer\\(kind=4\\) :: spacer" \
- " integer\\(kind=4\\) :: t1_i" \
+ " ${int4} :: spacer" \
+ " ${int4} :: t1_i" \
"End Type type1, allocatable \\(2\\)" ]
gdb_test "ptype var7%t5_array(1)%t2_array" \
[ multi_line "type = Type type1" \
- " integer\\(kind=4\\) :: spacer" \
- " integer\\(kind=4\\) :: t1_i" \
+ " ${int4} :: spacer" \
+ " ${int4} :: t1_i" \
"End Type type1, allocatable \\(2\\)" ]
gdb_test "whatis var6%t4_array(1)%t2_array(1)" \
"type = Type type1"
@@ -141,18 +144,18 @@ gdb_test "whatis var7%t5_array(1)%t2_array(1)" \
gdb_test "ptype var6%t4_array(1)%t2_array(1)" \
[ multi_line \
"type = Type type1" \
- " integer\\(kind=4\\) :: spacer" \
- " integer\\(kind=4\\) :: t1_i" \
+ " ${int4} :: spacer" \
+ " ${int4} :: t1_i" \
"End Type type1" ]
gdb_test "ptype var7%t5_array(1)%t2_array(1)" \
[ multi_line \
"type = Type type1" \
- " integer\\(kind=4\\) :: spacer" \
- " integer\\(kind=4\\) :: t1_i" \
+ " ${int4} :: spacer" \
+ " ${int4} :: t1_i" \
"End Type type1" ]
gdb_test "ptype var8%ptr_1%t2_array" \
[ multi_line \
"type = Type type1" \
- " integer\\(kind=4\\) :: spacer" \
- " integer\\(kind=4\\) :: t1_i" \
+ " ${int4} :: spacer" \
+ " ${int4} :: t1_i" \
"End Type type1, allocatable \\(3\\)" ]
--
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
^ permalink raw reply [flat|nested] 39+ messages in thread* [PATCH 11/18] testsuite, fortran: Add '-debug-parameters all' when compiling with ifx
2022-05-10 14:24 [PATCH 00/18] Fortran compiler identification and ifx testsuite support Nils-Christian Kempke
` (9 preceding siblings ...)
2022-05-10 14:24 ` [PATCH 10/18] testsuite, fortran: add compiler dependent types to dynamic-ptype-whatis Nils-Christian Kempke
@ 2022-05-10 14:24 ` Nils-Christian Kempke
2022-05-11 11:56 ` Andrew Burgess
2022-05-10 14:24 ` [PATCH 12/18] testsuite/lib: add check_optional_entry for GDBInfoSymbols Nils-Christian Kempke
` (7 subsequent siblings)
18 siblings, 1 reply; 39+ messages in thread
From: Nils-Christian Kempke @ 2022-05-10 14:24 UTC (permalink / raw)
To: gdb-patches; +Cc: aburgess, JiniSusan.George, Nils-Christian Kempke
In order for ifx 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-* specific flags in gdb.exp.
---
gdb/testsuite/lib/gdb.exp | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index b8e61d846d..e799312c12 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -4439,6 +4439,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, ifx needs the -debug-parameters all flag set to emit
+ # debug info for all parameters in modules.
if { $getting_compiler_info == 0 && [lsearch -exact $options f90] != -1 } {
# Fortran compile.
set mod_path [standard_output_file ""]
@@ -4447,6 +4449,9 @@ 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}"
+ if { [test_compiler_info {ifx-*} f90] } {
+ 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
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: [PATCH 11/18] testsuite, fortran: Add '-debug-parameters all' when compiling with ifx
2022-05-10 14:24 ` [PATCH 11/18] testsuite, fortran: Add '-debug-parameters all' when compiling with ifx Nils-Christian Kempke
@ 2022-05-11 11:56 ` Andrew Burgess
2022-05-11 14:36 ` Kempke, Nils-Christian
0 siblings, 1 reply; 39+ messages in thread
From: Andrew Burgess @ 2022-05-11 11:56 UTC (permalink / raw)
To: Nils-Christian Kempke, gdb-patches
Cc: JiniSusan.George, Nils-Christian Kempke
Nils-Christian Kempke <nils-christian.kempke@intel.com> writes:
> In order for ifx 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-* specific flags in gdb.exp.
> ---
> gdb/testsuite/lib/gdb.exp | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
> index b8e61d846d..e799312c12 100644
> --- a/gdb/testsuite/lib/gdb.exp
> +++ b/gdb/testsuite/lib/gdb.exp
> @@ -4439,6 +4439,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, ifx needs the -debug-parameters all flag set to emit
I think you should place quotes around the "-debug-parameters all" to
indicate that the "all" is part of the flag, or, just drop the "all", we
can see what -debug-parameters is set too by looking below.
This is fine with that change.
Thanks,
Andrew
> + # debug info for all parameters in modules.
> if { $getting_compiler_info == 0 && [lsearch -exact $options f90] != -1 } {
> # Fortran compile.
> set mod_path [standard_output_file ""]
> @@ -4447,6 +4449,9 @@ 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}"
> + if { [test_compiler_info {ifx-*} f90] } {
> + 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
^ permalink raw reply [flat|nested] 39+ messages in thread* RE: [PATCH 11/18] testsuite, fortran: Add '-debug-parameters all' when compiling with ifx
2022-05-11 11:56 ` Andrew Burgess
@ 2022-05-11 14:36 ` Kempke, Nils-Christian
0 siblings, 0 replies; 39+ messages in thread
From: Kempke, Nils-Christian @ 2022-05-11 14:36 UTC (permalink / raw)
To: Andrew Burgess, gdb-patches
> -----Original Message-----
> From: Andrew Burgess <aburgess@redhat.com>
> Sent: Wednesday, May 11, 2022 1:57 PM
> To: Kempke, Nils-Christian <nils-christian.kempke@intel.com>; gdb-
> patches@sourceware.org
> Cc: JiniSusan.George@amd.com; Kempke, Nils-Christian <nils-
> christian.kempke@intel.com>
> Subject: Re: [PATCH 11/18] testsuite, fortran: Add '-debug-parameters all'
> when compiling with ifx
>
> Nils-Christian Kempke <nils-christian.kempke@intel.com> writes:
>
> > In order for ifx 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-* specific flags in gdb.exp.
> > ---
> > gdb/testsuite/lib/gdb.exp | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
> > index b8e61d846d..e799312c12 100644
> > --- a/gdb/testsuite/lib/gdb.exp
> > +++ b/gdb/testsuite/lib/gdb.exp
> > @@ -4439,6 +4439,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, ifx needs the -debug-parameters all flag set to emit
>
> I think you should place quotes around the "-debug-parameters all" to
> indicate that the "all" is part of the flag, or, just drop the "all", we
> can see what -debug-parameters is set too by looking below.
>
> This is fine with that change.
Yes, I dropped it. Done in v2.
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* [PATCH 12/18] testsuite/lib: add check_optional_entry for GDBInfoSymbols
2022-05-10 14:24 [PATCH 00/18] Fortran compiler identification and ifx testsuite support Nils-Christian Kempke
` (10 preceding siblings ...)
2022-05-10 14:24 ` [PATCH 11/18] testsuite, fortran: Add '-debug-parameters all' when compiling with ifx Nils-Christian Kempke
@ 2022-05-10 14:24 ` Nils-Christian Kempke
2022-05-10 14:24 ` [PATCH 13/18] testsuite, fortran: fix info-types for intel compilers Nils-Christian Kempke
` (6 subsequent siblings)
18 siblings, 0 replies; 39+ messages in thread
From: Nils-Christian Kempke @ 2022-05-10 14:24 UTC (permalink / raw)
To: gdb-patches; +Cc: aburgess, JiniSusan.George, Nils-Christian Kempke
There was already a similar functionality for the GDBInfoModuleSymbols.
This just extends the GDBInfoSymbols. We will use this feature in a
later commit to make a testcase less GNU specific and more flexible for
other compilers.
Namely, in gdb.fortran/info-types.exp currenlty
GDBInfoSymbols::check_entry is used to verify and test the output of the
info symbols command. The test, however was written with gfortran as a
basis and some of the tests are not fair with e.g. ifx and ifort as
they test for symbols that are not actually required to be emitted. The
lines
GDBInfoSymbols::check_entry "${srcfile}" "" "${character1}"
and
GDBInfoSymbols::check_entry "${srcfile}" "37" "Type s1;"
check for types that are either not used in the source file (character1)
or should not be emitted by the compiler at global scope (s1) thus no
appearing in the info symbols command. In order to fix this we will
later use the newly introduced check_optional_entry over check_entry.
---
gdb/testsuite/lib/sym-info-cmds.exp | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/gdb/testsuite/lib/sym-info-cmds.exp b/gdb/testsuite/lib/sym-info-cmds.exp
index f0272a0334..ce878f0d50 100644
--- a/gdb/testsuite/lib/sym-info-cmds.exp
+++ b/gdb/testsuite/lib/sym-info-cmds.exp
@@ -163,6 +163,16 @@ namespace eval GDBInfoSymbols {
gdb_assert {[regexp -- $pattern $_header]} $testname
}
+ # Call check_entry_1 with OPTIONAL == 0.
+ proc check_entry { filename lineno text { testname "" } } {
+ check_entry_1 $filename $lineno $text 0 $testname
+ }
+
+ # Call check_entry_1 with OPTIONAL == 1.
+ proc check_optional_entry { filename lineno text { testname "" } } {
+ check_entry_1 $filename $lineno $text 1 $testname
+ }
+
# Check that we have an entry in _entries matching FILENAME,
# LINENO, and TEXT. If LINENO is the empty string it is replaced
# with the string NONE in order to match a similarly missing line
@@ -174,7 +184,7 @@ namespace eval GDBInfoSymbols {
# If a matching entry is found then it is removed from the
# _entries list, this allows us to check for duplicates using the
# check_no_entry call.
- proc check_entry { filename lineno text { testname "" } } {
+ proc check_entry_1 { filename lineno text optional testname } {
variable _entries
variable _last_command
@@ -209,7 +219,11 @@ namespace eval GDBInfoSymbols {
}
set _entries $new_entries
- gdb_assert { $found_match } $testname
+ if { $optional && ! $found_match } {
+ unsupported $testname
+ } else {
+ gdb_assert { $found_match } $testname
+ }
}
# Check that there is no entry in the _entries list matching
--
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
^ permalink raw reply [flat|nested] 39+ messages in thread* [PATCH 13/18] testsuite, fortran: fix info-types for intel compilers
2022-05-10 14:24 [PATCH 00/18] Fortran compiler identification and ifx testsuite support Nils-Christian Kempke
` (11 preceding siblings ...)
2022-05-10 14:24 ` [PATCH 12/18] testsuite/lib: add check_optional_entry for GDBInfoSymbols Nils-Christian Kempke
@ 2022-05-10 14:24 ` Nils-Christian Kempke
2022-05-11 12:06 ` Andrew Burgess
2022-05-10 14:24 ` [PATCH 14/18] testsuite, fortran: Add type info of formal parameter for Intel compilers Nils-Christian Kempke
` (5 subsequent siblings)
18 siblings, 1 reply; 39+ messages in thread
From: Nils-Christian Kempke @ 2022-05-10 14:24 UTC (permalink / raw)
To: gdb-patches; +Cc: aburgess, JiniSusan.George, Nils-Christian Kempke
First, the emitted symbol character*1 which is checked in the test
is not even referenced as a type in the compiled examples. It seems
to be a gfortran specific check for some type that gets emitted always.
I changed the test to use check_optional_entry here to allow the
symbol's absence.
Second, the line checked for s1 was hardcoded in the test. Given that
the type is actually defined on line 41 (which is what is emitted by
ifx) it even seems wrong. I changed the line check for s1 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 test was checking for s1 to be emitted by info types. This
would mean that the type is put into compilation unit scope in the DWARF
but, as it is local to the main program this is actually not expected
and gfortran specific.
Since I already added the xfail for gfortran here, I opted to also make
this check gfortran specific.
---
gdb/testsuite/gdb.fortran/info-types.exp | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/gdb/testsuite/gdb.fortran/info-types.exp b/gdb/testsuite/gdb.fortran/info-types.exp
index 67fe4d79c5..06770aada1 100644
--- a/gdb/testsuite/gdb.fortran/info-types.exp
+++ b/gdb/testsuite/gdb.fortran/info-types.exp
@@ -41,12 +41,16 @@ 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;"
+
+if { [test_compiler_info {gfortran-*} f90] } {
+ setup_xfail *-*-* gcc/105454
+ GDBInfoSymbols::check_entry "${srcfile}" "41" "Type s1;"
+}
return 0
@@ -62,5 +66,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
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: [PATCH 13/18] testsuite, fortran: fix info-types for intel compilers
2022-05-10 14:24 ` [PATCH 13/18] testsuite, fortran: fix info-types for intel compilers Nils-Christian Kempke
@ 2022-05-11 12:06 ` Andrew Burgess
2022-05-11 15:20 ` Kempke, Nils-Christian
0 siblings, 1 reply; 39+ messages in thread
From: Andrew Burgess @ 2022-05-11 12:06 UTC (permalink / raw)
To: Nils-Christian Kempke, gdb-patches
Cc: JiniSusan.George, Nils-Christian Kempke
Nils-Christian Kempke <nils-christian.kempke@intel.com> writes:
> First, the emitted symbol character*1 which is checked in the test
> is not even referenced as a type in the compiled examples. It seems
> to be a gfortran specific check for some type that gets emitted always.
> I changed the test to use check_optional_entry here to allow the
> symbol's absence.
>
> Second, the line checked for s1 was hardcoded in the test. Given that
> the type is actually defined on line 41 (which is what is emitted by
> ifx) it even seems wrong. I changed the line check for s1 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 test was checking for s1 to be emitted by info types. This
> would mean that the type is put into compilation unit scope in the DWARF
> but, as it is local to the main program this is actually not expected
> and gfortran specific.
> Since I already added the xfail for gfortran here, I opted to also make
> this check gfortran specific.
> ---
> gdb/testsuite/gdb.fortran/info-types.exp | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/gdb/testsuite/gdb.fortran/info-types.exp b/gdb/testsuite/gdb.fortran/info-types.exp
> index 67fe4d79c5..06770aada1 100644
> --- a/gdb/testsuite/gdb.fortran/info-types.exp
> +++ b/gdb/testsuite/gdb.fortran/info-types.exp
> @@ -41,12 +41,16 @@ 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}"
Could we not just add a reference to character*1 type? I'm happy to
take this change, but just adding a use might make a stronger test?
> 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;"
> +
> +if { [test_compiler_info {gfortran-*} f90] } {
> + setup_xfail *-*-* gcc/105454
> + GDBInfoSymbols::check_entry "${srcfile}" "41" "Type s1;"
> +}
Shouldn't the GDBInfoSymbols::check_entry call be outside of the if
block? I think, with your change, the test will _only_ be run on
gfortran, which is not what you wanted.
Thanks,
Andrew
>
> return 0
>
> @@ -62,5 +66,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
^ permalink raw reply [flat|nested] 39+ messages in thread* RE: [PATCH 13/18] testsuite, fortran: fix info-types for intel compilers
2022-05-11 12:06 ` Andrew Burgess
@ 2022-05-11 15:20 ` Kempke, Nils-Christian
2022-05-11 16:43 ` Kempke, Nils-Christian
2022-05-30 10:32 ` Andrew Burgess
0 siblings, 2 replies; 39+ messages in thread
From: Kempke, Nils-Christian @ 2022-05-11 15:20 UTC (permalink / raw)
To: Andrew Burgess, gdb-patches
> -----Original Message-----
> From: Andrew Burgess <aburgess@redhat.com>
> Sent: Wednesday, May 11, 2022 2:06 PM
> To: Kempke, Nils-Christian <nils-christian.kempke@intel.com>; gdb-
> patches@sourceware.org
> Cc: JiniSusan.George@amd.com; Kempke, Nils-Christian <nils-
> christian.kempke@intel.com>
> Subject: Re: [PATCH 13/18] testsuite, fortran: fix info-types for intel
> compilers
>
> Nils-Christian Kempke <nils-christian.kempke@intel.com> writes:
>
> > First, the emitted symbol character*1 which is checked in the test
> > is not even referenced as a type in the compiled examples. It seems
> > to be a gfortran specific check for some type that gets emitted always.
> > I changed the test to use check_optional_entry here to allow the
> > symbol's absence.
> >
> > Second, the line checked for s1 was hardcoded in the test. Given that
> > the type is actually defined on line 41 (which is what is emitted by
> > ifx) it even seems wrong. I changed the line check for s1 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 test was checking for s1 to be emitted by info types. This
> > would mean that the type is put into compilation unit scope in the DWARF
> > but, as it is local to the main program this is actually not expected
> > and gfortran specific.
> > Since I already added the xfail for gfortran here, I opted to also make
> > this check gfortran specific.
> > ---
> > gdb/testsuite/gdb.fortran/info-types.exp | 10 +++++++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/gdb/testsuite/gdb.fortran/info-types.exp
> b/gdb/testsuite/gdb.fortran/info-types.exp
> > index 67fe4d79c5..06770aada1 100644
> > --- a/gdb/testsuite/gdb.fortran/info-types.exp
> > +++ b/gdb/testsuite/gdb.fortran/info-types.exp
> > @@ -41,12 +41,16 @@ 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}"
>
> Could we not just add a reference to character*1 type? I'm happy to
> take this change, but just adding a use might make a stronger test?
Yes, I'll do that. It is true, there will be a bit more coverage.
> > 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;"
> > +
> > +if { [test_compiler_info {gfortran-*} f90] } {
> > + setup_xfail *-*-* gcc/105454
> > + GDBInfoSymbols::check_entry "${srcfile}" "41" "Type s1;"
> > +}
>
> Shouldn't the GDBInfoSymbols::check_entry call be outside of the if
> block? I think, with your change, the test will _only_ be run on
> gfortran, which is not what you wanted.
Mh - so actually this is what I wanted. In my opinion emitting s1 here
is actually not expected. The type s1 is defined inside the Fortran program.
E.g. ifx also emits it as a child of the program - limiting its scope to that.
Gfortran on the other hand emits it at global CU scope (so not as a child of
the program info_types_test). I think the fact that this type is visible via info
types is not correct here. But, since this emission is also buggy I did not want
to delete the test in order to somehow keep track of this line bug.
So I changed the test to only test for this type when ran with gfortran.
My baseline assumption here is, that gdb in the test only prints types in the
'info types' command that are defined at CU DWARF scope. At least it looks
like this when compiling with ifx (which, as said, emits the Type s1 as a child
of the program info_types_test).
When checking this compiled with ifx I see in the DWARF
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<1><1d5>: Abbrev Number: 12 (DW_TAG_subprogram)
<1d6> DW_AT_low_pc : 0x4055b0
<1de> DW_AT_high_pc : 0x42
<1e2> DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6 (rbp))
<1e4> DW_AT_linkage_name: (indirect string, offset: 0x224): MAIN__
<1e8> DW_AT_name : (indirect string, offset: 0x22b): info_types_test
<1ec> DW_AT_decl_file : 1
<1ed> DW_AT_decl_line : 37
<1ee> DW_AT_external : 1
<1ee> DW_AT_main_subprogram: 1
...
<2><239>: Abbrev Number: 14 (DW_TAG_structure_type)
<23a> DW_AT_name : (indirect string, offset: 0x1d4): s1
<23e> DW_AT_byte_size : 4
<23f> DW_AT_decl_file : 1
<240> DW_AT_decl_line : 41
<3><241>: Abbrev Number: 15 (DW_TAG_member)
<242> DW_AT_name : (indirect string, offset: 0x207): a
<246> DW_AT_type : <0x1ce>
<24a> DW_AT_decl_file : 1
<24b> DW_AT_decl_line : 41
<24c> DW_AT_data_member_location: 0
<24d> DW_AT_accessibility: 1 (public)
<3><24e>: Abbrev Number: 0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
So s1 is being emitted but as a child of MAIN__. With gfortran on the other
hand I get
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<1><2ec>: Abbrev Number: 18 (DW_TAG_structure_type)
<2ed> DW_AT_name : s1
<2f0> DW_AT_byte_size : 4
<2f1> DW_AT_decl_file : 1
<2f2> DW_AT_decl_line : 37
<2f3> DW_AT_sibling : <0x302>
<2><2f7>: Abbrev Number: 4 (DW_TAG_member)
<2f8> DW_AT_name : a
<2fa> DW_AT_decl_file : 1
<2fb> DW_AT_decl_line : 42
<2fc> DW_AT_type : <0x2bf>
<300> DW_AT_data_member_location: 0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
emitted as a child of the whole compile unit.
It might be, that this is actually not the expected behavior of GDB here.
But it seems, that types defined as children of subroutines will not be
displayed by 'info types'.
Similarly, I looked at this in c++ and we have the same here: Compiling
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
int main (int argc, char *argv[])
{
struct test {};
test a;
return 0;
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
With gcc -O0 -g (version 9.4.0) will emit DWARF like:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
<2e> DW_AT_external : 1
<2e> DW_AT_name : (indirect string, offset: 0xb4): main
<32> DW_AT_decl_file : 1
<33> DW_AT_decl_line : 1
<34> DW_AT_decl_column : 5
<35> DW_AT_type : <0xf7>
<39> DW_AT_low_pc : 0x1129
<41> DW_AT_high_pc : 0x16
<49> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<4b> DW_AT_GNU_all_call_sites: 1
<4b> DW_AT_sibling : <0xf7>
<2><4f>: Abbrev Number: 3 (DW_TAG_formal_parameter)
...
<2><6d>: Abbrev Number: 4 (DW_TAG_structure_type)
<6e> DW_AT_name : (indirect string, offset: 0xf): test
<72> DW_AT_byte_size : 1
<73> DW_AT_decl_file : 1
<74> DW_AT_decl_line : 3
<75> DW_AT_decl_column : 10
<76> DW_AT_sibling : <0xe9>
<3><7a>: Abbrev Number: 5 (DW_TAG_subprogram)
...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
So the type of test is not emitted at CU level, but as a child of main.
Doing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(gdb) info types
All defined types:
File ./c.cpp:
char
int
(gdb) start
...
6 return 0;
(gdb) info types test
All types matching regular expression "test":
(gdb)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
will also not emit the type.
So either this is wrong in GDB - or the emission of the type at global level
is not quite correct here and should not even be tested.
I see that my commit message does not quite cover all this though.
But what do you think?
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
^ permalink raw reply [flat|nested] 39+ messages in thread* RE: [PATCH 13/18] testsuite, fortran: fix info-types for intel compilers
2022-05-11 15:20 ` Kempke, Nils-Christian
@ 2022-05-11 16:43 ` Kempke, Nils-Christian
2022-05-30 10:33 ` Andrew Burgess
2022-05-30 10:32 ` Andrew Burgess
1 sibling, 1 reply; 39+ messages in thread
From: Kempke, Nils-Christian @ 2022-05-11 16:43 UTC (permalink / raw)
To: Kempke, Nils-Christian, Andrew Burgess, gdb-patches
> -----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, May 11, 2022 5:20 PM
> To: Andrew Burgess <aburgess@redhat.com>; gdb-
> patches@sourceware.org
> Subject: RE: [PATCH 13/18] testsuite, fortran: fix info-types for intel
> compilers
>
> > -----Original Message-----
> > From: Andrew Burgess <aburgess@redhat.com>
> > Sent: Wednesday, May 11, 2022 2:06 PM
> > To: Kempke, Nils-Christian <nils-christian.kempke@intel.com>; gdb-
> > patches@sourceware.org
> > Cc: JiniSusan.George@amd.com; Kempke, Nils-Christian <nils-
> > christian.kempke@intel.com>
> > Subject: Re: [PATCH 13/18] testsuite, fortran: fix info-types for intel
> > compilers
> >
> > Nils-Christian Kempke <nils-christian.kempke@intel.com> writes:
> >
> > > First, the emitted symbol character*1 which is checked in the test
> > > is not even referenced as a type in the compiled examples. It seems
> > > to be a gfortran specific check for some type that gets emitted always.
> > > I changed the test to use check_optional_entry here to allow the
> > > symbol's absence.
> > >
> > > Second, the line checked for s1 was hardcoded in the test. Given that
> > > the type is actually defined on line 41 (which is what is emitted by
> > > ifx) it even seems wrong. I changed the line check for s1 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 test was checking for s1 to be emitted by info types. This
> > > would mean that the type is put into compilation unit scope in the
> DWARF
> > > but, as it is local to the main program this is actually not expected
> > > and gfortran specific.
> > > Since I already added the xfail for gfortran here, I opted to also make
> > > this check gfortran specific.
> > > ---
> > > gdb/testsuite/gdb.fortran/info-types.exp | 10 +++++++---
> > > 1 file changed, 7 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/gdb/testsuite/gdb.fortran/info-types.exp
> > b/gdb/testsuite/gdb.fortran/info-types.exp
> > > index 67fe4d79c5..06770aada1 100644
> > > --- a/gdb/testsuite/gdb.fortran/info-types.exp
> > > +++ b/gdb/testsuite/gdb.fortran/info-types.exp
> > > @@ -41,12 +41,16 @@ 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}"
> >
> > Could we not just add a reference to character*1 type? I'm happy to
> > take this change, but just adding a use might make a stronger test?
>
> Yes, I'll do that. It is true, there will be a bit more coverage.
>
> > > 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;"
> > > +
> > > +if { [test_compiler_info {gfortran-*} f90] } {
> > > + setup_xfail *-*-* gcc/105454
> > > + GDBInfoSymbols::check_entry "${srcfile}" "41" "Type s1;"
> > > +}
> >
> > Shouldn't the GDBInfoSymbols::check_entry call be outside of the if
> > block? I think, with your change, the test will _only_ be run on
> > gfortran, which is not what you wanted.
>
> Mh - so actually this is what I wanted. In my opinion emitting s1 here
> is actually not expected. The type s1 is defined inside the Fortran program.
> E.g. ifx also emits it as a child of the program - limiting its scope to that.
>
> Gfortran on the other hand emits it at global CU scope (so not as a child of
> the program info_types_test). I think the fact that this type is visible via info
> types is not correct here. But, since this emission is also buggy I did not want
> to delete the test in order to somehow keep track of this line bug.
>
> So I changed the test to only test for this type when ran with gfortran.
>
> My baseline assumption here is, that gdb in the test only prints types in the
> 'info types' command that are defined at CU DWARF scope. At least it looks
> like this when compiling with ifx (which, as said, emits the Type s1 as a child
> of the program info_types_test).
>
> When checking this compiled with ifx I see in the DWARF
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> <1><1d5>: Abbrev Number: 12 (DW_TAG_subprogram)
> <1d6> DW_AT_low_pc : 0x4055b0
> <1de> DW_AT_high_pc : 0x42
> <1e2> DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6 (rbp))
> <1e4> DW_AT_linkage_name: (indirect string, offset: 0x224): MAIN__
> <1e8> DW_AT_name : (indirect string, offset: 0x22b): info_types_test
> <1ec> DW_AT_decl_file : 1
> <1ed> DW_AT_decl_line : 37
> <1ee> DW_AT_external : 1
> <1ee> DW_AT_main_subprogram: 1
> ...
> <2><239>: Abbrev Number: 14 (DW_TAG_structure_type)
> <23a> DW_AT_name : (indirect string, offset: 0x1d4): s1
> <23e> DW_AT_byte_size : 4
> <23f> DW_AT_decl_file : 1
> <240> DW_AT_decl_line : 41
> <3><241>: Abbrev Number: 15 (DW_TAG_member)
> <242> DW_AT_name : (indirect string, offset: 0x207): a
> <246> DW_AT_type : <0x1ce>
> <24a> DW_AT_decl_file : 1
> <24b> DW_AT_decl_line : 41
> <24c> DW_AT_data_member_location: 0
> <24d> DW_AT_accessibility: 1 (public)
> <3><24e>: Abbrev Number: 0
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> So s1 is being emitted but as a child of MAIN__. With gfortran on the other
> hand I get
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> <1><2ec>: Abbrev Number: 18 (DW_TAG_structure_type)
> <2ed> DW_AT_name : s1
> <2f0> DW_AT_byte_size : 4
> <2f1> DW_AT_decl_file : 1
> <2f2> DW_AT_decl_line : 37
> <2f3> DW_AT_sibling : <0x302>
> <2><2f7>: Abbrev Number: 4 (DW_TAG_member)
> <2f8> DW_AT_name : a
> <2fa> DW_AT_decl_file : 1
> <2fb> DW_AT_decl_line : 42
> <2fc> DW_AT_type : <0x2bf>
> <300> DW_AT_data_member_location: 0
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> emitted as a child of the whole compile unit.
>
> It might be, that this is actually not the expected behavior of GDB here.
> But it seems, that types defined as children of subroutines will not be
> displayed by 'info types'.
>
> Similarly, I looked at this in c++ and we have the same here: Compiling
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> int main (int argc, char *argv[])
> {
> struct test {};
>
> test a;
> return 0;
> }
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> With gcc -O0 -g (version 9.4.0) will emit DWARF like:
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> <1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
> <2e> DW_AT_external : 1
> <2e> DW_AT_name : (indirect string, offset: 0xb4): main
> <32> DW_AT_decl_file : 1
> <33> DW_AT_decl_line : 1
> <34> DW_AT_decl_column : 5
> <35> DW_AT_type : <0xf7>
> <39> DW_AT_low_pc : 0x1129
> <41> DW_AT_high_pc : 0x16
> <49> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
> <4b> DW_AT_GNU_all_call_sites: 1
> <4b> DW_AT_sibling : <0xf7>
> <2><4f>: Abbrev Number: 3 (DW_TAG_formal_parameter)
> ...
> <2><6d>: Abbrev Number: 4 (DW_TAG_structure_type)
> <6e> DW_AT_name : (indirect string, offset: 0xf): test
> <72> DW_AT_byte_size : 1
> <73> DW_AT_decl_file : 1
> <74> DW_AT_decl_line : 3
> <75> DW_AT_decl_column : 10
> <76> DW_AT_sibling : <0xe9>
> <3><7a>: Abbrev Number: 5 (DW_TAG_subprogram)
> ...
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> So the type of test is not emitted at CU level, but as a child of main.
> Doing
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> (gdb) info types
> All defined types:
>
> File ./c.cpp:
> char
> int
> (gdb) start
> ...
> 6 return 0;
> (gdb) info types test
> All types matching regular expression "test":
> (gdb)
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> will also not emit the type.
>
> So either this is wrong in GDB - or the emission of the type at global level
> is not quite correct here and should not even be tested.
>
> I see that my commit message does not quite cover all this though.
> But what do you think?
>
> Thanks,
> Nils
>
I dug into this a bit more .. It seems indeed that the symbols are only
searched at a global level. In symtab.c:add_matching_symbols which is
called as a result of e.g. 'info types' we only search the symbols put into
either the block GLOBAL_BLOCK, or STATIC_BLOCK.
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 indeed, I would not expect these local symbols to appear when typing
'info symbols'/'info types' in GDB.
So, I think the emission of s1 in 'info types' when compiled with gfortran
Is wrong (and likely this should also become a GCC/gfortran bug). It does not
happen with ifx or flang.
About the second comment on this patch:
> > > -GDBInfoSymbols::check_entry "${srcfile}" "" "${character1}"
> > > +GDBInfoSymbols::check_optional_entry "${srcfile}" "" "${character1}"
> >
> > Could we not just add a reference to character*1 type? I'm happy to
> > take this change, but just adding a use might make a stronger test?
>
> Yes, I'll do that. It is true, there will be a bit more coverage.
It is actually difficult to do this. I added this line to the test (in this case to
the program info_types_test):
character(kind=1) :: d = 'c'
Adding a character to the executable and compiling it with ifx or gfortran
will not trigger the emission of an additional type though. In fact, neither,
gfortran, nor ifx emit the type of variable d as ${character1}, e.g. character*1:
gfortran this type is described as
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<2><32e>: Abbrev Number: 21 (DW_TAG_variable)
<32f> DW_AT_name : d
<331> DW_AT_decl_file : 1
<332> DW_AT_decl_line : 45
<333> DW_AT_type : <0x365>
...
<1><365>: Abbrev Number: 25 (DW_TAG_string_type)
<366> DW_AT_byte_size : 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
and IFX
will describe the character type not with a
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<2><24f>: Abbrev Number: 13 (DW_TAG_variable)
<250> DW_AT_name : (indirect string, offset: 0x1f7): d
<254> DW_AT_type : <0x286>
<258> DW_AT_decl_file : 1
<259> DW_AT_decl_line : 45
<25a> DW_AT_location : 9 byte block: 3 a0 f3 48 0 0 0 0 0 (DW_OP_addr: 48f3a0)
<264> DW_AT_linkage_name: (indirect string, offset: 0x205): info_types_test_$D
...
<1><286>: Abbrev Number: 18 (DW_TAG_string_type)
<287> DW_AT_name : (indirect string, offset: 0x1f9): CHARACTER_0
<28b> DW_AT_byte_size : 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I also tried lines like
character*1 :: d = 'c'
and
character :: d = 'c'
but all three were emitted as the same string_type in DWARF.
So, to conclude, I do not even know whether it is possible to
actually get gfortran to emit a type called character*1 naturally..
The only place within the Fortran testsuite where a check for
the compiler dependent type fortran_character1 exists is info-types.
The problem with the emission as DW_TAG_string_type is that this will not
make GDB generate a symbol for the type - 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 for this part, I think the type should not be emitted at all. I do also not think
that it is wrong DWARF to emit the character*1 as a string_type of length 1.
Btw. when printing the type in gdb this is hidden as Fortran string types
are printed as character*DW_AT_byte_size, so for ifx or gfortran we get
(gdb) ptype d
type = character*1
I lastly checked this with flang and here, finally, we get a character base type
emitted as
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<2><29b>: Abbrev Number: 16 (DW_TAG_variable)
<29c> DW_AT_name : (indirect string, offset: 0x1b9): d
<2a0> DW_AT_type : <0x372>
...
<1><372>: Abbrev Number: 10 (DW_TAG_base_type)
<373> DW_AT_name : (indirect string, offset: 0x1ad): character
<377> DW_AT_encoding : 5 (signed)
<378> DW_AT_byte_size : 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
which, rightfully, made GDB emit a type called 'character' in the 'info types'.
I think we should keep the check for the character type optional, even when
adding a line that actually uses it to the test (as only flang DWARF emits it).
The other alternative is to remove this check completely which I also think is ok.
There should be a gfortran bug filed about the emission of this character*1, too though.
Cheers,
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
^ permalink raw reply [flat|nested] 39+ messages in thread* RE: [PATCH 13/18] testsuite, fortran: fix info-types for intel compilers
2022-05-11 16:43 ` Kempke, Nils-Christian
@ 2022-05-30 10:33 ` Andrew Burgess
0 siblings, 0 replies; 39+ messages in thread
From: Andrew Burgess @ 2022-05-30 10:33 UTC (permalink / raw)
To: Kempke, Nils-Christian, Kempke, Nils-Christian, gdb-patches
"Kempke, Nils-Christian" <nils-christian.kempke@intel.com> writes:
>> -----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, May 11, 2022 5:20 PM
>> To: Andrew Burgess <aburgess@redhat.com>; gdb-
>> patches@sourceware.org
>> Subject: RE: [PATCH 13/18] testsuite, fortran: fix info-types for intel
>> compilers
>>
>> > -----Original Message-----
>> > From: Andrew Burgess <aburgess@redhat.com>
>> > Sent: Wednesday, May 11, 2022 2:06 PM
>> > To: Kempke, Nils-Christian <nils-christian.kempke@intel.com>; gdb-
>> > patches@sourceware.org
>> > Cc: JiniSusan.George@amd.com; Kempke, Nils-Christian <nils-
>> > christian.kempke@intel.com>
>> > Subject: Re: [PATCH 13/18] testsuite, fortran: fix info-types for intel
>> > compilers
>> >
>> > Nils-Christian Kempke <nils-christian.kempke@intel.com> writes:
>> >
>> > > First, the emitted symbol character*1 which is checked in the test
>> > > is not even referenced as a type in the compiled examples. It seems
>> > > to be a gfortran specific check for some type that gets emitted always.
>> > > I changed the test to use check_optional_entry here to allow the
>> > > symbol's absence.
>> > >
>> > > Second, the line checked for s1 was hardcoded in the test. Given that
>> > > the type is actually defined on line 41 (which is what is emitted by
>> > > ifx) it even seems wrong. I changed the line check for s1 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 test was checking for s1 to be emitted by info types. This
>> > > would mean that the type is put into compilation unit scope in the
>> DWARF
>> > > but, as it is local to the main program this is actually not expected
>> > > and gfortran specific.
>> > > Since I already added the xfail for gfortran here, I opted to also make
>> > > this check gfortran specific.
>> > > ---
>> > > gdb/testsuite/gdb.fortran/info-types.exp | 10 +++++++---
>> > > 1 file changed, 7 insertions(+), 3 deletions(-)
>> > >
>> > > diff --git a/gdb/testsuite/gdb.fortran/info-types.exp
>> > b/gdb/testsuite/gdb.fortran/info-types.exp
>> > > index 67fe4d79c5..06770aada1 100644
>> > > --- a/gdb/testsuite/gdb.fortran/info-types.exp
>> > > +++ b/gdb/testsuite/gdb.fortran/info-types.exp
>> > > @@ -41,12 +41,16 @@ 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}"
>> >
>> > Could we not just add a reference to character*1 type? I'm happy to
>> > take this change, but just adding a use might make a stronger test?
>>
>> Yes, I'll do that. It is true, there will be a bit more coverage.
>>
>> > > 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;"
>> > > +
>> > > +if { [test_compiler_info {gfortran-*} f90] } {
>> > > + setup_xfail *-*-* gcc/105454
>> > > + GDBInfoSymbols::check_entry "${srcfile}" "41" "Type s1;"
>> > > +}
>> >
>> > Shouldn't the GDBInfoSymbols::check_entry call be outside of the if
>> > block? I think, with your change, the test will _only_ be run on
>> > gfortran, which is not what you wanted.
>>
>> Mh - so actually this is what I wanted. In my opinion emitting s1 here
>> is actually not expected. The type s1 is defined inside the Fortran program.
>> E.g. ifx also emits it as a child of the program - limiting its scope to that.
>>
>> Gfortran on the other hand emits it at global CU scope (so not as a child of
>> the program info_types_test). I think the fact that this type is visible via info
>> types is not correct here. But, since this emission is also buggy I did not want
>> to delete the test in order to somehow keep track of this line bug.
>>
>> So I changed the test to only test for this type when ran with gfortran.
>>
>> My baseline assumption here is, that gdb in the test only prints types in the
>> 'info types' command that are defined at CU DWARF scope. At least it looks
>> like this when compiling with ifx (which, as said, emits the Type s1 as a child
>> of the program info_types_test).
>>
>> When checking this compiled with ifx I see in the DWARF
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> <1><1d5>: Abbrev Number: 12 (DW_TAG_subprogram)
>> <1d6> DW_AT_low_pc : 0x4055b0
>> <1de> DW_AT_high_pc : 0x42
>> <1e2> DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6 (rbp))
>> <1e4> DW_AT_linkage_name: (indirect string, offset: 0x224): MAIN__
>> <1e8> DW_AT_name : (indirect string, offset: 0x22b): info_types_test
>> <1ec> DW_AT_decl_file : 1
>> <1ed> DW_AT_decl_line : 37
>> <1ee> DW_AT_external : 1
>> <1ee> DW_AT_main_subprogram: 1
>> ...
>> <2><239>: Abbrev Number: 14 (DW_TAG_structure_type)
>> <23a> DW_AT_name : (indirect string, offset: 0x1d4): s1
>> <23e> DW_AT_byte_size : 4
>> <23f> DW_AT_decl_file : 1
>> <240> DW_AT_decl_line : 41
>> <3><241>: Abbrev Number: 15 (DW_TAG_member)
>> <242> DW_AT_name : (indirect string, offset: 0x207): a
>> <246> DW_AT_type : <0x1ce>
>> <24a> DW_AT_decl_file : 1
>> <24b> DW_AT_decl_line : 41
>> <24c> DW_AT_data_member_location: 0
>> <24d> DW_AT_accessibility: 1 (public)
>> <3><24e>: Abbrev Number: 0
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> So s1 is being emitted but as a child of MAIN__. With gfortran on the other
>> hand I get
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> <1><2ec>: Abbrev Number: 18 (DW_TAG_structure_type)
>> <2ed> DW_AT_name : s1
>> <2f0> DW_AT_byte_size : 4
>> <2f1> DW_AT_decl_file : 1
>> <2f2> DW_AT_decl_line : 37
>> <2f3> DW_AT_sibling : <0x302>
>> <2><2f7>: Abbrev Number: 4 (DW_TAG_member)
>> <2f8> DW_AT_name : a
>> <2fa> DW_AT_decl_file : 1
>> <2fb> DW_AT_decl_line : 42
>> <2fc> DW_AT_type : <0x2bf>
>> <300> DW_AT_data_member_location: 0
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> emitted as a child of the whole compile unit.
>>
>> It might be, that this is actually not the expected behavior of GDB here.
>> But it seems, that types defined as children of subroutines will not be
>> displayed by 'info types'.
>>
>> Similarly, I looked at this in c++ and we have the same here: Compiling
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> int main (int argc, char *argv[])
>> {
>> struct test {};
>>
>> test a;
>> return 0;
>> }
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> With gcc -O0 -g (version 9.4.0) will emit DWARF like:
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> <1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
>> <2e> DW_AT_external : 1
>> <2e> DW_AT_name : (indirect string, offset: 0xb4): main
>> <32> DW_AT_decl_file : 1
>> <33> DW_AT_decl_line : 1
>> <34> DW_AT_decl_column : 5
>> <35> DW_AT_type : <0xf7>
>> <39> DW_AT_low_pc : 0x1129
>> <41> DW_AT_high_pc : 0x16
>> <49> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
>> <4b> DW_AT_GNU_all_call_sites: 1
>> <4b> DW_AT_sibling : <0xf7>
>> <2><4f>: Abbrev Number: 3 (DW_TAG_formal_parameter)
>> ...
>> <2><6d>: Abbrev Number: 4 (DW_TAG_structure_type)
>> <6e> DW_AT_name : (indirect string, offset: 0xf): test
>> <72> DW_AT_byte_size : 1
>> <73> DW_AT_decl_file : 1
>> <74> DW_AT_decl_line : 3
>> <75> DW_AT_decl_column : 10
>> <76> DW_AT_sibling : <0xe9>
>> <3><7a>: Abbrev Number: 5 (DW_TAG_subprogram)
>> ...
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> So the type of test is not emitted at CU level, but as a child of main.
>> Doing
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> (gdb) info types
>> All defined types:
>>
>> File ./c.cpp:
>> char
>> int
>> (gdb) start
>> ...
>> 6 return 0;
>> (gdb) info types test
>> All types matching regular expression "test":
>> (gdb)
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> will also not emit the type.
>>
>> So either this is wrong in GDB - or the emission of the type at global level
>> is not quite correct here and should not even be tested.
>>
>> I see that my commit message does not quite cover all this though.
>> But what do you think?
>>
>> Thanks,
>> Nils
>>
>
> I dug into this a bit more .. It seems indeed that the symbols are only
> searched at a global level. In symtab.c:add_matching_symbols which is
> called as a result of e.g. 'info types' we only search the symbols put into
> either the block GLOBAL_BLOCK, or STATIC_BLOCK.
>
> 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 indeed, I would not expect these local symbols to appear when typing
> 'info symbols'/'info types' in GDB.
>
> So, I think the emission of s1 in 'info types' when compiled with gfortran
> Is wrong (and likely this should also become a GCC/gfortran bug). It does not
> happen with ifx or flang.
>
> About the second comment on this patch:
>
>> > > -GDBInfoSymbols::check_entry "${srcfile}" "" "${character1}"
>> > > +GDBInfoSymbols::check_optional_entry "${srcfile}" "" "${character1}"
>> >
>> > Could we not just add a reference to character*1 type? I'm happy to
>> > take this change, but just adding a use might make a stronger test?
>>
>> Yes, I'll do that. It is true, there will be a bit more coverage.
>
> It is actually difficult to do this. I added this line to the test (in this case to
> the program info_types_test):
>
> character(kind=1) :: d = 'c'
>
> Adding a character to the executable and compiling it with ifx or gfortran
> will not trigger the emission of an additional type though. In fact, neither,
> gfortran, nor ifx emit the type of variable d as ${character1}, e.g. character*1:
>
> gfortran this type is described as
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> <2><32e>: Abbrev Number: 21 (DW_TAG_variable)
> <32f> DW_AT_name : d
> <331> DW_AT_decl_file : 1
> <332> DW_AT_decl_line : 45
> <333> DW_AT_type : <0x365>
> ...
> <1><365>: Abbrev Number: 25 (DW_TAG_string_type)
> <366> DW_AT_byte_size : 1
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> and IFX
> will describe the character type not with a
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> <2><24f>: Abbrev Number: 13 (DW_TAG_variable)
> <250> DW_AT_name : (indirect string, offset: 0x1f7): d
> <254> DW_AT_type : <0x286>
> <258> DW_AT_decl_file : 1
> <259> DW_AT_decl_line : 45
> <25a> DW_AT_location : 9 byte block: 3 a0 f3 48 0 0 0 0 0 (DW_OP_addr: 48f3a0)
> <264> DW_AT_linkage_name: (indirect string, offset: 0x205): info_types_test_$D
> ...
> <1><286>: Abbrev Number: 18 (DW_TAG_string_type)
> <287> DW_AT_name : (indirect string, offset: 0x1f9): CHARACTER_0
> <28b> DW_AT_byte_size : 1
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> I also tried lines like
>
> character*1 :: d = 'c'
>
> and
>
> character :: d = 'c'
>
> but all three were emitted as the same string_type in DWARF.
> So, to conclude, I do not even know whether it is possible to
> actually get gfortran to emit a type called character*1 naturally..
>
> The only place within the Fortran testsuite where a check for
> the compiler dependent type fortran_character1 exists is info-types.
> The problem with the emission as DW_TAG_string_type is that this will not
> make GDB generate a symbol for the type - 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 for this part, I think the type should not be emitted at all. I do also not think
> that it is wrong DWARF to emit the character*1 as a string_type of length 1.
> Btw. when printing the type in gdb this is hidden as Fortran string types
> are printed as character*DW_AT_byte_size, so for ifx or gfortran we get
>
> (gdb) ptype d
> type = character*1
>
> I lastly checked this with flang and here, finally, we get a character base type
> emitted as
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> <2><29b>: Abbrev Number: 16 (DW_TAG_variable)
> <29c> DW_AT_name : (indirect string, offset: 0x1b9): d
> <2a0> DW_AT_type : <0x372>
> ...
> <1><372>: Abbrev Number: 10 (DW_TAG_base_type)
> <373> DW_AT_name : (indirect string, offset: 0x1ad): character
> <377> DW_AT_encoding : 5 (signed)
> <378> DW_AT_byte_size : 1
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> which, rightfully, made GDB emit a type called 'character' in the 'info types'.
>
> I think we should keep the check for the character type optional, even when
> adding a line that actually uses it to the test (as only flang DWARF emits it).
> The other alternative is to remove this check completely which I also think is ok.
>
> There should be a gfortran bug filed about the emission of this
> character*1, too though.
Thanks for all the work you've done looking into this. Given what
you've said, then I'm happy with your original change.
Thanks,
Andrew
^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: [PATCH 13/18] testsuite, fortran: fix info-types for intel compilers
2022-05-11 15:20 ` Kempke, Nils-Christian
2022-05-11 16:43 ` Kempke, Nils-Christian
@ 2022-05-30 10:32 ` Andrew Burgess
1 sibling, 0 replies; 39+ messages in thread
From: Andrew Burgess @ 2022-05-30 10:32 UTC (permalink / raw)
To: Kempke, Nils-Christian, gdb-patches
"Kempke, Nils-Christian via Gdb-patches" <gdb-patches@sourceware.org>
writes:
>> -----Original Message-----
>> From: Andrew Burgess <aburgess@redhat.com>
>> Sent: Wednesday, May 11, 2022 2:06 PM
>> To: Kempke, Nils-Christian <nils-christian.kempke@intel.com>; gdb-
>> patches@sourceware.org
>> Cc: JiniSusan.George@amd.com; Kempke, Nils-Christian <nils-
>> christian.kempke@intel.com>
>> Subject: Re: [PATCH 13/18] testsuite, fortran: fix info-types for intel
>> compilers
>>
>> Nils-Christian Kempke <nils-christian.kempke@intel.com> writes:
>>
>> > First, the emitted symbol character*1 which is checked in the test
>> > is not even referenced as a type in the compiled examples. It seems
>> > to be a gfortran specific check for some type that gets emitted always.
>> > I changed the test to use check_optional_entry here to allow the
>> > symbol's absence.
>> >
>> > Second, the line checked for s1 was hardcoded in the test. Given that
>> > the type is actually defined on line 41 (which is what is emitted by
>> > ifx) it even seems wrong. I changed the line check for s1 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 test was checking for s1 to be emitted by info types. This
>> > would mean that the type is put into compilation unit scope in the DWARF
>> > but, as it is local to the main program this is actually not expected
>> > and gfortran specific.
>> > Since I already added the xfail for gfortran here, I opted to also make
>> > this check gfortran specific.
>> > ---
>> > gdb/testsuite/gdb.fortran/info-types.exp | 10 +++++++---
>> > 1 file changed, 7 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/gdb/testsuite/gdb.fortran/info-types.exp
>> b/gdb/testsuite/gdb.fortran/info-types.exp
>> > index 67fe4d79c5..06770aada1 100644
>> > --- a/gdb/testsuite/gdb.fortran/info-types.exp
>> > +++ b/gdb/testsuite/gdb.fortran/info-types.exp
>> > @@ -41,12 +41,16 @@ 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}"
>>
>> Could we not just add a reference to character*1 type? I'm happy to
>> take this change, but just adding a use might make a stronger test?
>
> Yes, I'll do that. It is true, there will be a bit more coverage.
>
>> > 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;"
>> > +
>> > +if { [test_compiler_info {gfortran-*} f90] } {
>> > + setup_xfail *-*-* gcc/105454
>> > + GDBInfoSymbols::check_entry "${srcfile}" "41" "Type s1;"
>> > +}
>>
>> Shouldn't the GDBInfoSymbols::check_entry call be outside of the if
>> block? I think, with your change, the test will _only_ be run on
>> gfortran, which is not what you wanted.
>
> Mh - so actually this is what I wanted. In my opinion emitting s1 here
> is actually not expected. The type s1 is defined inside the Fortran program.
> E.g. ifx also emits it as a child of the program - limiting its scope to that.
>
> Gfortran on the other hand emits it at global CU scope (so not as a child of
> the program info_types_test). I think the fact that this type is visible via info
> types is not correct here. But, since this emission is also buggy I did not want
> to delete the test in order to somehow keep track of this line bug.
>
> So I changed the test to only test for this type when ran with gfortran.
>
> My baseline assumption here is, that gdb in the test only prints types in the
> 'info types' command that are defined at CU DWARF scope. At least it looks
> like this when compiling with ifx (which, as said, emits the Type s1 as a child
> of the program info_types_test).
>
> When checking this compiled with ifx I see in the DWARF
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> <1><1d5>: Abbrev Number: 12 (DW_TAG_subprogram)
> <1d6> DW_AT_low_pc : 0x4055b0
> <1de> DW_AT_high_pc : 0x42
> <1e2> DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6 (rbp))
> <1e4> DW_AT_linkage_name: (indirect string, offset: 0x224): MAIN__
> <1e8> DW_AT_name : (indirect string, offset: 0x22b): info_types_test
> <1ec> DW_AT_decl_file : 1
> <1ed> DW_AT_decl_line : 37
> <1ee> DW_AT_external : 1
> <1ee> DW_AT_main_subprogram: 1
> ...
> <2><239>: Abbrev Number: 14 (DW_TAG_structure_type)
> <23a> DW_AT_name : (indirect string, offset: 0x1d4): s1
> <23e> DW_AT_byte_size : 4
> <23f> DW_AT_decl_file : 1
> <240> DW_AT_decl_line : 41
> <3><241>: Abbrev Number: 15 (DW_TAG_member)
> <242> DW_AT_name : (indirect string, offset: 0x207): a
> <246> DW_AT_type : <0x1ce>
> <24a> DW_AT_decl_file : 1
> <24b> DW_AT_decl_line : 41
> <24c> DW_AT_data_member_location: 0
> <24d> DW_AT_accessibility: 1 (public)
> <3><24e>: Abbrev Number: 0
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> So s1 is being emitted but as a child of MAIN__. With gfortran on the other
> hand I get
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> <1><2ec>: Abbrev Number: 18 (DW_TAG_structure_type)
> <2ed> DW_AT_name : s1
> <2f0> DW_AT_byte_size : 4
> <2f1> DW_AT_decl_file : 1
> <2f2> DW_AT_decl_line : 37
> <2f3> DW_AT_sibling : <0x302>
> <2><2f7>: Abbrev Number: 4 (DW_TAG_member)
> <2f8> DW_AT_name : a
> <2fa> DW_AT_decl_file : 1
> <2fb> DW_AT_decl_line : 42
> <2fc> DW_AT_type : <0x2bf>
> <300> DW_AT_data_member_location: 0
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> emitted as a child of the whole compile unit.
>
> It might be, that this is actually not the expected behavior of GDB here.
> But it seems, that types defined as children of subroutines will not be
> displayed by 'info types'.
>
> Similarly, I looked at this in c++ and we have the same here: Compiling
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> int main (int argc, char *argv[])
> {
> struct test {};
>
> test a;
> return 0;
> }
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> With gcc -O0 -g (version 9.4.0) will emit DWARF like:
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> <1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
> <2e> DW_AT_external : 1
> <2e> DW_AT_name : (indirect string, offset: 0xb4): main
> <32> DW_AT_decl_file : 1
> <33> DW_AT_decl_line : 1
> <34> DW_AT_decl_column : 5
> <35> DW_AT_type : <0xf7>
> <39> DW_AT_low_pc : 0x1129
> <41> DW_AT_high_pc : 0x16
> <49> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
> <4b> DW_AT_GNU_all_call_sites: 1
> <4b> DW_AT_sibling : <0xf7>
> <2><4f>: Abbrev Number: 3 (DW_TAG_formal_parameter)
> ...
> <2><6d>: Abbrev Number: 4 (DW_TAG_structure_type)
> <6e> DW_AT_name : (indirect string, offset: 0xf): test
> <72> DW_AT_byte_size : 1
> <73> DW_AT_decl_file : 1
> <74> DW_AT_decl_line : 3
> <75> DW_AT_decl_column : 10
> <76> DW_AT_sibling : <0xe9>
> <3><7a>: Abbrev Number: 5 (DW_TAG_subprogram)
> ...
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> So the type of test is not emitted at CU level, but as a child of main.
> Doing
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> (gdb) info types
> All defined types:
>
> File ./c.cpp:
> char
> int
> (gdb) start
> ...
> 6 return 0;
> (gdb) info types test
> All types matching regular expression "test":
> (gdb)
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> will also not emit the type.
>
> So either this is wrong in GDB - or the emission of the type at global level
> is not quite correct here and should not even be tested.
>
> I see that my commit message does not quite cover all this though.
> But what do you think?
Sorry for the delay in replying.
Thanks for the excellent description, this makes it much clearer what's
going on, and I'm happy with the test remaining gfortran only.
It would probably be worth adding at least some of this description to
the commit message, and an abridged summary as a comment in the .exp
file. My thinking is, that at some point, gfortran might be "fixed" so
the type is not emitted at the global scope. When that happens, and the
test starts to fail, it will save someone time if there's a comment
saying that the emission of this type is probably not correct, and that
future gfortran versions might decide not to emit this at all.
Thanks,
Andrew
>
> 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
^ permalink raw reply [flat|nested] 39+ messages in thread
* [PATCH 14/18] testsuite, fortran: Add type info of formal parameter for Intel compilers.
2022-05-10 14:24 [PATCH 00/18] Fortran compiler identification and ifx testsuite support Nils-Christian Kempke
` (12 preceding siblings ...)
2022-05-10 14:24 ` [PATCH 13/18] testsuite, fortran: fix info-types for intel compilers Nils-Christian Kempke
@ 2022-05-10 14:24 ` Nils-Christian Kempke
2022-05-10 14:24 ` [PATCH 15/18] testsuite, fortran: allow additional completions in module.exp Nils-Christian Kempke
` (4 subsequent siblings)
18 siblings, 0 replies; 39+ messages in thread
From: Nils-Christian Kempke @ 2022-05-10 14:24 UTC (permalink / raw)
To: gdb-patches; +Cc: aburgess, JiniSusan.George, Nils-Christian Kempke
The type info emitted by ifx and ifort is different for
some_module::get_number and some_module::set_number. A new case is
added for the Intel compilers to remove false FAILs in the test.
---
gdb/testsuite/gdb.fortran/ptype-on-functions.exp | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/gdb/testsuite/gdb.fortran/ptype-on-functions.exp b/gdb/testsuite/gdb.fortran/ptype-on-functions.exp
index 021ad83ff1..f97bff957b 100644
--- a/gdb/testsuite/gdb.fortran/ptype-on-functions.exp
+++ b/gdb/testsuite/gdb.fortran/ptype-on-functions.exp
@@ -43,6 +43,12 @@ set stringlen ($integer8|$integer4)
if { [test_compiler_info {flang-*} f90] } {
set some_module_class_type "Type number"
set some_module_aux_info ", $integer8 \\(10\\)"
+} elseif { [test_compiler_info {ifx-*} f90]
+ || [test_compiler_info {ifort-*} f90] } {
+ # Ifx/ifort debug info reveals the implicit Fortran pass by reference for
+ # function arguments.
+ set some_module_class_type "PTR TO -> \\( Type number \\)"
+ set some_module_aux_info ""
} else {
set some_module_class_type "Type __class_some_module_Number(_t)?"
set some_module_aux_info ""
--
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
^ permalink raw reply [flat|nested] 39+ messages in thread* [PATCH 15/18] testsuite, fortran: allow additional completions in module.exp
2022-05-10 14:24 [PATCH 00/18] Fortran compiler identification and ifx testsuite support Nils-Christian Kempke
` (13 preceding siblings ...)
2022-05-10 14:24 ` [PATCH 14/18] testsuite, fortran: Add type info of formal parameter for Intel compilers Nils-Christian Kempke
@ 2022-05-10 14:24 ` Nils-Christian Kempke
2022-05-10 14:24 ` [PATCH 16/18] gdb, testsuite, fortran: fix double free in mixed-lang-stack.exp Nils-Christian Kempke
` (3 subsequent siblings)
18 siblings, 0 replies; 39+ messages in thread
From: Nils-Christian Kempke @ 2022-05-10 14:24 UTC (permalink / raw)
To: gdb-patches; +Cc: aburgess, JiniSusan.George, Nils-Christian Kempke
For ifort, ifx, and flang the tests "complete modm" and "complete
modmany" fail. This is because all three emit additional completion
suggestions. These additional suggestions have their origin in symbols
emitted by the compilers which can also be completed from the respective
incomplete word (modm or modmany). For this specific example gfortran
does not emit any additional symbols.
For example, in this test the linkage name for var_a in ifx is
"modmany_mp_var_a_" while gfortran uses "__modmany_MOD_var_a" instead.
Since modmany_mp_var_a can be completed from modm and also modmany they
will get displayed, while gfortran's symbol starts with "__" and thus will
be ignored (it cannot be a completion of a word starting with "m").
Similar things happen in flang and ifort. Some example output is shown
below:
FLANG
(gdb) complete p modm
p modmany
p modmany::var_a
p modmany::var_b
p modmany::var_c
p modmany::var_i
p modmany_
IFX/IFORT
(gdb) complete p modm
p modmany
p modmany._
p modmany::var_a
p modmany::var_b
p modmany::var_c
p modmany::var_i
p modmany_mp_var_a_
p modmany_mp_var_b_
p modmany_mp_var_c_
p modmany_mp_var_i_
GFORTRAN
(gdb) complete p modm
p modmany
p modmany::var_a
p modmany::var_b
p modmany::var_c
p modmany::var_i
I want to emphasize: for Fortran (and also C/C++) the complete command
does not actually check whether its suggestions make sense - all it does
is look for any symbol (in the minimal symbols, partial symbols etc.)
that a given substring can be completed to (meaning that the given substring
is the beginning of the symbol). One can easily produce a similar
output for the gfortran compiled executable. For this look at the
slightly modified "complete p mod" in gfortran:
(gdb) complete p mod
p mod1
p mod1::var_const
...
p mod_1.c
p modcounter
p mode_t
p modf
...
p modify_ldt
p modmany
p modmany::var_a
p modmany::var_b
p modmany::var_c
p modmany::var_i
p module
p module.f90
p module_entry
p moduse
p moduse::var_x
p moduse::var_y
Many of the displayed symbols do not actually work with print:
(gdb) p mode_t
Attempt to use a type name as an expression
(gdb) p mod_1.c
No symbol "mod_1" in current context.
(gdb)
I think that in the given test the output for gfortran only looks nice
"by chance" rather than is actually expected. Expected is any output
that also contains the completions
p modmany
p modmany::var_a
p modmany::var_b
p modmany::var_c
p modmany::var_i
while anythings else can be displayed as well (depending on the
compiler and its emitted symbols).
This, I'd consider all three outputs as valid and expected - one is just
somewhat lucky that gfortran does not produce any additional symbols that
got matched.
The given patch improves test performance for all three compilers
by allowing additional suggested completions inbetween and after
the two given blocks in the test. I did not allow additional print
within the modmany_list block since the output is ordered alphabetically
and there should normally not appear any additional symbols there.
For flang/ifx/ifort I each see 2 failures less (which are exactly the two
complete tests).
As a side note and since I mentioned C++ in the beginning: I also tried
the gdb.cp/completion.exp. The output seems a bit more reasonable,
mainly since C++ actually has a demangler in place and linkage symbols
do not appear in the output of complete. Still, with a poor enough
to-be-completed string one can easily produce similar results:
(gdb) complete p t
...
p typeinfo name for void
p typeinfo name for void const*
p typeinfo name for void*
p typeinfo name for wchar_t
p typeinfo name for wchar_t const*
p typeinfo name for wchar_t*
p t *** List may be truncated, max-completions reached. ***
(gdb) p typeinfo name for void*
No symbol "typeinfo" in current context.
(gdb) complete p B
p BACK_SLASH
p BUF_FIRST
p BUF_LAST
...
p Base
p Base::Base()
p Base::get_foo()
p bad_key_err
p buf
p buffer
p buffer_size
p buflen
p bufsize
p build_charclass.isra
(gdb) p bad_key_err
No symbol "bad_key_err" in current context.
(compiled with gcc/g++ and breaking at main).
This patch is only about making the referenced test more 'fair' for the
other compilers. Generally, I find the behavior of complete a bit
confusing and maybe one wants to change this at some point but this
would be a bigger task.
---
gdb/testsuite/gdb.fortran/module.exp | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gdb/testsuite/gdb.fortran/module.exp b/gdb/testsuite/gdb.fortran/module.exp
index b00122a037..1895a20079 100644
--- a/gdb/testsuite/gdb.fortran/module.exp
+++ b/gdb/testsuite/gdb.fortran/module.exp
@@ -118,9 +118,10 @@ gdb_test "print var_z" " = 31" "print var_x value 31"
gdb_test "ptype modmany" "type = module modmany"
proc complete {expr list} {
+ set n_lines "\(?:\\r\\n.*\)*"
set cmd "complete p $expr"
- set expect [join [concat [list $cmd] $list] "\r\np "]
- gdb_test $cmd $expect "complete $expr"
+ set expect [join [concat [list $cmd] $list] $n_lines]
+ gdb_test $cmd "$expect$n_lines" "complete $expr"
}
set modmany_list {modmany::var_a modmany::var_b modmany::var_c modmany::var_i}
complete "modm" "modmany $modmany_list"
--
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
^ permalink raw reply [flat|nested] 39+ messages in thread* [PATCH 16/18] gdb, testsuite, fortran: fix double free in mixed-lang-stack.exp
2022-05-10 14:24 [PATCH 00/18] Fortran compiler identification and ifx testsuite support Nils-Christian Kempke
` (14 preceding siblings ...)
2022-05-10 14:24 ` [PATCH 15/18] testsuite, fortran: allow additional completions in module.exp Nils-Christian Kempke
@ 2022-05-10 14:24 ` Nils-Christian Kempke
2022-05-10 14:24 ` [PATCH 17/18] gdb, testsuite, fortran: fixup mixed-lang-stack for Intel/LLVM compilers Nils-Christian Kempke
` (2 subsequent siblings)
18 siblings, 0 replies; 39+ messages in thread
From: Nils-Christian Kempke @ 2022-05-10 14:24 UTC (permalink / raw)
To: gdb-patches; +Cc: aburgess, JiniSusan.George, Nils-Christian Kempke
While testing mixed-lang-stack I realized that valgrind actually
complained about a double free in the test.
All done
==2503051==
==2503051== HEAP SUMMARY:
==2503051== in use at exit: 0 bytes in 0 blocks
==2503051== total heap usage: 26 allocs, 27 frees, 87,343 bytes allocated
==2503051==
==2503051== All heap blocks were freed -- no leaks are possible
==2503051==
==2503051== For lists of detected and suppressed errors, rerun with: -s
==2503051== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Reason for this is that in mixed-lang-stack.cpp in mixed_func_1f an
object "derived_type obj" goes on the stack which is then passed-by-value
(so copied) to mixed_func_1g. The default copy-ctor will be called but,
since derived_type contains a heap allocated string and the copy
constructor is not implemented it will only be able to shallow copy the
object. Right after each of the functions the object gets freed - on the
other hand the d'tor of derived_type actually is implemented and calls
free on the heap allocated string which leads to a double free. Instead
of obeying the rule of 3/5 I just got rid of all that since it does not
serve the test. The string is now just a const char* = ".." object
member.
---
gdb/testsuite/gdb.fortran/mixed-lang-stack.cpp | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/gdb/testsuite/gdb.fortran/mixed-lang-stack.cpp b/gdb/testsuite/gdb.fortran/mixed-lang-stack.cpp
index 39ff6c201f..b5ae7dac0a 100644
--- a/gdb/testsuite/gdb.fortran/mixed-lang-stack.cpp
+++ b/gdb/testsuite/gdb.fortran/mixed-lang-stack.cpp
@@ -26,17 +26,7 @@ class base_one
class base_two
{
public:
- base_two ()
- {
- string = strdup ("Something in C++");
- }
-
- ~base_two ()
- {
- free (string);
- }
-
- char *string = nullptr;
+ const char *string = "Something in C++";
float val = 3.5;
};
--
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
^ permalink raw reply [flat|nested] 39+ messages in thread* [PATCH 17/18] gdb, testsuite, fortran: fixup mixed-lang-stack for Intel/LLVM compilers
2022-05-10 14:24 [PATCH 00/18] Fortran compiler identification and ifx testsuite support Nils-Christian Kempke
` (15 preceding siblings ...)
2022-05-10 14:24 ` [PATCH 16/18] gdb, testsuite, fortran: fix double free in mixed-lang-stack.exp Nils-Christian Kempke
@ 2022-05-10 14:24 ` Nils-Christian Kempke
2022-05-10 14:24 ` [PATCH 18/18] gdb/testsuite: fixup common-block.exp for intel compilers Nils-Christian Kempke
2022-05-11 13:32 ` [PATCH 00/18] Fortran compiler identification and ifx testsuite support Andrew Burgess
18 siblings, 0 replies; 39+ messages in thread
From: Nils-Christian Kempke @ 2022-05-10 14:24 UTC (permalink / raw)
To: gdb-patches; +Cc: aburgess, JiniSusan.George, Nils-Christian Kempke
When value-printing a pointer within GDB by default GDB will look for
defined symbols residing at the address of the pointer. For the given
test the Intel/LLVM compiler stacks both display a symbol associated
with a printed pointer while the gnu stack does not. This leads to
failures in the test when running the test with CC_FOR_TARGET='clang'
CXX_FOR_TARGET='clang' F90_FOR_TARGET='flang'"
(gdb) b 37
(gdb) r
(gdb) f 6
(gdb) info args
a = 1
b = 2
c = 3
d = 4 + 5i
f = 0x419ed0 "abcdef"
g = 0x4041a0 <.BSS4>
or CC_FOR_TARGET='icx' CXX_FOR_TARGET='icpx' F90_FOR_TARGET='ifx'"
(gdb) b 37
(gdb) r
(gdb) f 6
(gdb) info args
a = 1
b = 2
c = 3
d = 4 + 5i
f = 0x52eee0 "abcdef"
g = 0x4ca210 <mixed_func_1a_$OBJ>
For the compiled binary the Intel/LLVM compilers both decide to move the
local variable g into the .bss section of their executable. The gnu
stack will keep the variable locally on the stack and not define a
symbol for it.
Since the behavior for Intel/LLVM is actually expected I adapted the
testcase at this point to be a bit more allowing for other outputs.
I added the optional "<SYMBOLNAME>" to the regex testing for g.
The given changes reduce the test fails for Intel/LLVM stack by 4 each.
---
.../gdb.fortran/mixed-lang-stack.exp | 21 ++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/gdb/testsuite/gdb.fortran/mixed-lang-stack.exp b/gdb/testsuite/gdb.fortran/mixed-lang-stack.exp
index eace4d439b..5bed3be869 100644
--- a/gdb/testsuite/gdb.fortran/mixed-lang-stack.exp
+++ b/gdb/testsuite/gdb.fortran/mixed-lang-stack.exp
@@ -129,22 +129,29 @@ proc run_tests { lang } {
set f_pattern "$hex \"abcdef\""
}
+ # When value-printing pointers in GDB, GDB will try and look for any
+ # associated symbol and print it after the pointer as "<SYMBOL>". For
+ # this test Intel and LLVM compilers move g to the .bss section, thus
+ # creating a symbol, while the GNU compiler stack keeps g purely on the
+ # stack.
+ set g_pattern "$hex\( <\[^\r\n\]+>\)?"
+
set args_pattern [multi_line \
"a = 1" \
"b = 2" \
"c = 3" \
"d = ${d_pattern}" \
"f = ${f_pattern}" \
- "g = $hex" ]
+ "g = ${g_pattern}" ]
gdb_test "info args" $args_pattern \
"info args in frame #6"
if { $lang == "fortran" } {
- set g_pattern " = \\( a = 1\\.5, b = 2\\.5 \\)"
+ set g_val_pattern " = \\( a = 1\\.5, b = 2\\.5 \\)"
} else {
- set g_pattern " = \\{a = 1\\.5, b = 2\\.5\\}"
+ set g_val_pattern " = \\{a = 1\\.5, b = 2\\.5\\}"
}
- gdb_test "print *g" "${g_pattern}" \
+ gdb_test "print *g" "${g_val_pattern}" \
"print object pointed to by g"
gdb_test "up" "#7\\s+$hex in mixed_func_1b .*" \
@@ -155,11 +162,11 @@ proc run_tests { lang } {
if { $lang == "c" || $lang == "c++" } {
set d_pattern "4 \\+ 5i"
set e_pattern "\"abcdef\""
- set g_pattern "\{a = 1.5, b = 2.5\}"
+ set g_val_pattern "\{a = 1.5, b = 2.5\}"
} else {
set d_pattern "\\(4,5\\)"
set e_pattern "'abcdef'"
- set g_pattern "\\( a = 1.5, b = 2.5 \\)"
+ set g_val_pattern "\\( a = 1.5, b = 2.5 \\)"
}
set args_pattern [multi_line \
@@ -168,7 +175,7 @@ proc run_tests { lang } {
"c = 3" \
"d = ${d_pattern}" \
"e = ${e_pattern}" \
- "g = ${g_pattern}" \
+ "g = ${g_val_pattern}" \
"_e = 6" ]
gdb_test "info args" $args_pattern \
--
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
^ permalink raw reply [flat|nested] 39+ messages in thread* [PATCH 18/18] gdb/testsuite: fixup common-block.exp for intel compilers
2022-05-10 14:24 [PATCH 00/18] Fortran compiler identification and ifx testsuite support Nils-Christian Kempke
` (16 preceding siblings ...)
2022-05-10 14:24 ` [PATCH 17/18] gdb, testsuite, fortran: fixup mixed-lang-stack for Intel/LLVM compilers Nils-Christian Kempke
@ 2022-05-10 14:24 ` Nils-Christian Kempke
2022-05-11 13:29 ` Andrew Burgess
2022-05-11 13:32 ` [PATCH 00/18] Fortran compiler identification and ifx testsuite support Andrew Burgess
18 siblings, 1 reply; 39+ messages in thread
From: Nils-Christian Kempke @ 2022-05-10 14:24 UTC (permalink / raw)
To: gdb-patches; +Cc: aburgess, JiniSusan.George, 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 ac39a4a575..fc38b8d772 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 "ix_x = 11\r\niy_y = 22\r\niz_z = 33\r\nix = 1\r\niy = 2\r\niz = 3.*$gdb_prompt $" {
+ pass $gdb_test_name
+ }
+ # ifx/ifort
+ -re "ix = 1\r\niy = 2\r\niz = 3\r\nix_x = 11\r\niy_y = 22\r\niz_z = 33.*$gdb_prompt $" {
+ pass $gdb_test_name
+ }
+}
+
+gdb_test_multiple "info common" "info common out" {
+ # gfortran
+ -re "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.*$gdb_prompt $" {
+ pass $gdb_test_name
+ }
+ # ifx/ifort
+ -re "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.*$gdb_prompt $" {
+ 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 "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.*$gdb_prompt $" {
+ pass $gdb_test_name
+ }
+ # ifx
+ -re "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.*$gdb_prompt $" {
+ pass $gdb_test_name
+ }
+ # ifort
+ -re "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.*$gdb_prompt $" {
+ 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
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: [PATCH 18/18] gdb/testsuite: fixup common-block.exp for intel compilers
2022-05-10 14:24 ` [PATCH 18/18] gdb/testsuite: fixup common-block.exp for intel compilers Nils-Christian Kempke
@ 2022-05-11 13:29 ` Andrew Burgess
2022-05-11 15:31 ` Kempke, Nils-Christian
0 siblings, 1 reply; 39+ messages in thread
From: Andrew Burgess @ 2022-05-11 13:29 UTC (permalink / raw)
To: Nils-Christian Kempke, gdb-patches
Cc: JiniSusan.George, Nils-Christian Kempke
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.
> ---
> 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 ac39a4a575..fc38b8d772 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 "ix_x = 11\r\niy_y = 22\r\niz_z = 33\r\nix = 1\r\niy = 2\r\niz = 3.*$gdb_prompt $" {
> + pass $gdb_test_name
> + }
You can use:
-re -wrap "ix_x = 11\r\niy_y = 22\r\niz_z = 33\r\nix = 1\r\niy = 2\r\niz = 3" {
...
}
to avoid having to add the $gdb_prompt in all of these tests.
Thanks,
Andrew
> + # ifx/ifort
> + -re "ix = 1\r\niy = 2\r\niz = 3\r\nix_x = 11\r\niy_y = 22\r\niz_z = 33.*$gdb_prompt $" {
> + pass $gdb_test_name
> + }
> +}
> +
> +gdb_test_multiple "info common" "info common out" {
> + # gfortran
> + -re "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.*$gdb_prompt $" {
> + pass $gdb_test_name
> + }
> + # ifx/ifort
> + -re "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.*$gdb_prompt $" {
> + 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 "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.*$gdb_prompt $" {
> + pass $gdb_test_name
> + }
> + # ifx
> + -re "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.*$gdb_prompt $" {
> + pass $gdb_test_name
> + }
> + # ifort
> + -re "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.*$gdb_prompt $" {
> + 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
^ permalink raw reply [flat|nested] 39+ messages in thread* RE: [PATCH 18/18] gdb/testsuite: fixup common-block.exp for intel compilers
2022-05-11 13:29 ` Andrew Burgess
@ 2022-05-11 15:31 ` Kempke, Nils-Christian
2022-05-16 6:36 ` George, Jini Susan
0 siblings, 1 reply; 39+ messages in thread
From: Kempke, Nils-Christian @ 2022-05-11 15:31 UTC (permalink / raw)
To: Andrew Burgess, gdb-patches
> -----Original Message-----
> From: Andrew Burgess <aburgess@redhat.com>
> Sent: Wednesday, May 11, 2022 3:29 PM
> To: Kempke, Nils-Christian <nils-christian.kempke@intel.com>; gdb-
> patches@sourceware.org
> Cc: JiniSusan.George@amd.com; Kempke, Nils-Christian <nils-
> christian.kempke@intel.com>
> Subject: Re: [PATCH 18/18] gdb/testsuite: fixup common-block.exp for intel
> compilers
>
> 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.
> > ---
> > 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 ac39a4a575..fc38b8d772 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 "ix_x = 11\r\niy_y = 22\r\niz_z = 33\r\nix = 1\r\niy = 2\r\niz =
> 3.*$gdb_prompt $" {
> > + pass $gdb_test_name
> > + }
>
> You can use:
>
> -re -wrap "ix_x = 11\r\niy_y = 22\r\niz_z = 33\r\nix = 1\r\niy = 2\r\niz = 3" {
> ...
> }
>
> to avoid having to add the $gdb_prompt in all of these tests.
>
> Thanks,
> Andrew
Thanks! That is more convenient indeed.
Changed in v2.
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
^ permalink raw reply [flat|nested] 39+ messages in thread* RE: [PATCH 18/18] gdb/testsuite: fixup common-block.exp for intel compilers
2022-05-11 15:31 ` Kempke, Nils-Christian
@ 2022-05-16 6:36 ` George, Jini Susan
2022-05-16 7:59 ` Kempke, Nils-Christian
0 siblings, 1 reply; 39+ messages in thread
From: George, Jini Susan @ 2022-05-16 6:36 UTC (permalink / raw)
To: Kempke, Nils-Christian, gdb-patches
[Public]
Thanks for your patches, Nils, Cristian, Abdul, Felix -- these are extremely helpful. I have tried your patches with AMD AOCC flang and these boost up the fortran tests pass rate for flang also hugely.
A very minor suggestion:
gdb.fortran/common-block.exp (lines 62 and 73): it would be great if you could add flang also along with ifx/ifort in the comments.
Thanks,
Jini.
>>-----Original Message-----
>>From: Gdb-patches <gdb-patches-
>>bounces+jigeorge=amd.com@sourceware.org> On Behalf Of Kempke, Nils-
>>Christian via Gdb-patches
>>Sent: Wednesday, May 11, 2022 9:02 PM
>>To: Andrew Burgess <aburgess@redhat.com>; gdb-patches@sourceware.org
>>Subject: RE: [PATCH 18/18] gdb/testsuite: fixup common-block.exp for intel
>>compilers
>>
>>[CAUTION: External Email]
>>
>>> -----Original Message-----
>>> From: Andrew Burgess <aburgess@redhat.com>
>>> Sent: Wednesday, May 11, 2022 3:29 PM
>>> To: Kempke, Nils-Christian <nils-christian.kempke@intel.com>; gdb-
>>> patches@sourceware.org
>>> Cc: JiniSusan.George@amd.com; Kempke, Nils-Christian <nils-
>>> christian.kempke@intel.com>
>>> Subject: Re: [PATCH 18/18] gdb/testsuite: fixup common-block.exp for
>>> intel compilers
>>>
>>> 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.
>>> > ---
>>> > 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 ac39a4a575..fc38b8d772 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 "ix_x = 11\r\niy_y = 22\r\niz_z = 33\r\nix = 1\r\niy =
>>> > +2\r\niz =
>>> 3.*$gdb_prompt $" {
>>> > + pass $gdb_test_name
>>> > + }
>>>
>>> You can use:
>>>
>>> -re -wrap "ix_x = 11\r\niy_y = 22\r\niz_z = 33\r\nix = 1\r\niy = 2\r\niz = 3" {
>>> ...
>>> }
>>>
>>> to avoid having to add the $gdb_prompt in all of these tests.
>>>
>>> Thanks,
>>> Andrew
>>
>>Thanks! That is more convenient indeed.
>>Changed in v2.
>>
>>Nils
>>
>>Intel Deutschland GmbH
>>Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
>>Tel: +49 89 99 8853-0,
>>https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.int
>>el.de%2F&data=05%7C01%7CJiniSusan.George%40amd.com%7C386b8a27
>>b41c4c31135e08da3363612b%7C3dd8961fe4884e608e11a82d994e183d%7C0%
>>7C0%7C637878799180300920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
>>jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
>>%7C&sdata=iahWHgSrYwg0K1Fb6%2Fm%2B49ZdPwxx%2F9sGZP1oUc09Z7
>>4%3D&reserved=0
>><https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.in
>>tel.de%2F&data=05%7C01%7CJiniSusan.George%40amd.com%7C386b8a2
>>7b41c4c31135e08da3363612b%7C3dd8961fe4884e608e11a82d994e183d%7C0
>>%7C0%7C637878799180300920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
>>wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
>>%7C%7C&sdata=iahWHgSrYwg0K1Fb6%2Fm%2B49ZdPwxx%2F9sGZP1oUc
>>09Z74%3D&reserved=0>
>>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
^ permalink raw reply [flat|nested] 39+ messages in thread* RE: [PATCH 18/18] gdb/testsuite: fixup common-block.exp for intel compilers
2022-05-16 6:36 ` George, Jini Susan
@ 2022-05-16 7:59 ` Kempke, Nils-Christian
0 siblings, 0 replies; 39+ messages in thread
From: Kempke, Nils-Christian @ 2022-05-16 7:59 UTC (permalink / raw)
To: George, Jini Susan, gdb-patches
> -----Original Message-----
> From: George, Jini Susan <JiniSusan.George@amd.com>
> Sent: Monday, May 16, 2022 8:37 AM
> To: Kempke, Nils-Christian <nils-christian.kempke@intel.com>; gdb-
> patches@sourceware.org
> Subject: RE: [PATCH 18/18] gdb/testsuite: fixup common-block.exp for intel
> compilers
>
> [Public]
>
> Thanks for your patches, Nils, Cristian, Abdul, Felix -- these are extremely
> helpful. I have tried your patches with AMD AOCC flang and these boost up
> the fortran tests pass rate for flang also hugely.
>
Thanks for checking!
> A very minor suggestion:
>
> gdb.fortran/common-block.exp (lines 62 and 73): it would be great if you
> could add flang also along with ifx/ifort in the comments.
Done for v2.
Thanks,
Nils
> Thanks,
> Jini.
>
>
> >>-----Original Message-----
> >>From: Gdb-patches <gdb-patches-
> >>bounces+jigeorge=amd.com@sourceware.org> On Behalf Of Kempke,
> Nils-
> >>Christian via Gdb-patches
> >>Sent: Wednesday, May 11, 2022 9:02 PM
> >>To: Andrew Burgess <aburgess@redhat.com>; gdb-
> patches@sourceware.org
> >>Subject: RE: [PATCH 18/18] gdb/testsuite: fixup common-block.exp for
> intel
> >>compilers
> >>
> >>[CAUTION: External Email]
> >>
> >>> -----Original Message-----
> >>> From: Andrew Burgess <aburgess@redhat.com>
> >>> Sent: Wednesday, May 11, 2022 3:29 PM
> >>> To: Kempke, Nils-Christian <nils-christian.kempke@intel.com>; gdb-
> >>> patches@sourceware.org
> >>> Cc: JiniSusan.George@amd.com; Kempke, Nils-Christian <nils-
> >>> christian.kempke@intel.com>
> >>> Subject: Re: [PATCH 18/18] gdb/testsuite: fixup common-block.exp for
> >>> intel compilers
> >>>
> >>> 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.
> >>> > ---
> >>> > 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 ac39a4a575..fc38b8d772 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 "ix_x = 11\r\niy_y = 22\r\niz_z = 33\r\nix = 1\r\niy =
> >>> > +2\r\niz =
> >>> 3.*$gdb_prompt $" {
> >>> > + pass $gdb_test_name
> >>> > + }
> >>>
> >>> You can use:
> >>>
> >>> -re -wrap "ix_x = 11\r\niy_y = 22\r\niz_z = 33\r\nix = 1\r\niy = 2\r\niz =
> 3" {
> >>> ...
> >>> }
> >>>
> >>> to avoid having to add the $gdb_prompt in all of these tests.
> >>>
> >>> Thanks,
> >>> Andrew
> >>
> >>Thanks! That is more convenient indeed.
> >>Changed in v2.
> >>
> >>Nils
> >>
> >>Intel Deutschland GmbH
> >>Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> >>Tel: +49 89 99 8853-0,
> >>https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw
> ww.int
> >>el.de%2F&data=05%7C01%7CJiniSusan.George%40amd.com%7C386b
> 8a27
> >>b41c4c31135e08da3363612b%7C3dd8961fe4884e608e11a82d994e183d%7C
> 0%
> >>7C0%7C637878799180300920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wL
> >>jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7
> C%7C
> >>%7C&sdata=iahWHgSrYwg0K1Fb6%2Fm%2B49ZdPwxx%2F9sGZP1oU
> c09Z7
> >>4%3D&reserved=0
> >><https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw
> ww.in
> >>tel.de%2F&data=05%7C01%7CJiniSusan.George%40amd.com%7C386
> b8a2
> >>7b41c4c31135e08da3363612b%7C3dd8961fe4884e608e11a82d994e183d%7
> C0
> >>%7C0%7C637878799180300920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4
> >>wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> %7C
> >>%7C%7C&sdata=iahWHgSrYwg0K1Fb6%2Fm%2B49ZdPwxx%2F9sGZP
> 1oUc
> >>09Z74%3D&reserved=0>
> >>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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 00/18] Fortran compiler identification and ifx testsuite support
2022-05-10 14:24 [PATCH 00/18] Fortran compiler identification and ifx testsuite support Nils-Christian Kempke
` (17 preceding siblings ...)
2022-05-10 14:24 ` [PATCH 18/18] gdb/testsuite: fixup common-block.exp for intel compilers Nils-Christian Kempke
@ 2022-05-11 13:32 ` Andrew Burgess
18 siblings, 0 replies; 39+ messages in thread
From: Andrew Burgess @ 2022-05-11 13:32 UTC (permalink / raw)
To: Nils-Christian Kempke, gdb-patches; +Cc: JiniSusan.George
Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org>
writes:
> Hi all,
>
> this series is a collection of patches we have prepared that was
> targeted at improving the overall passrate of the Intel ifx compiler
> within the Fortran testsuite. It also includes a new way for the
> testsuite to identify the Fortran compilers and their version.
Thanks for doing all this.
I've looked through all these patches, and everything looks good to me.
There's a few minor issues I spotted, I've sent emails about those,
everything else in this series is approved.
Thanks,
Andrew
>
>
> There are a few places in the gdb.fortran part of the testsuite that
> needed to be adapted for ifx. Some of these changes make the
> testsuite a bit less taylored to the gfortran specifics. Some of the
> changes fix flags and such to better support running the testsuite
> with ifx.
>
> While doing this and after initially submitting a patch here
>
> https://sourceware.org/pipermail/gdb-patches/2021-December/184612.html
>
> and in the follow-up discussion here
>
> https://sourceware.org/pipermail/gdb-patches/2022-January/185064.html
>
> we decided to change the testsuite a bit more and add a Frotran specific
> compiler identification to the Fortran testsuite.
>
> Generally, the procedures test_compiler_info and get_compiler_info are
> used in the testsuite to detect a certain compiler (e.g. gcc-*). This
> info is then used to set certain flags/kfails etc.
>
> The procedure get_compiler_info would, upon calling it, take the files
> compiler.c/compiler.cc (depending on wether or not the c++ option was
> passed to them) and run them through the respective C/CXX preprocessors
> of the compiler given via CC_FOR_TARGET/CXX_FOR_TARGET (or gcc/gfortran
> if these were not set). It would detect compiler specific macro
> definitions and retrun the compiler used, as well as its version in a
> string. As there was no separate option available for Fortran, using
> get_compiler_info inside a Fortran test would always default to the C
> compiler detection and return the version and name of the C compiler
> defined in CC_FOR_TARGET (or gcc if none was set).
>
> This meant, that running the testsuite while defining a F90_FOR_TARGET
> would, in order to set the right flags and kfails within the testsuite
> run, require one to also set the CC_FOR_TARGET to the C compiler that
> would 'correspond' to the Fortran one. So F90_FOR_TARGET=ifx would
> require CC_FOR_TARGET=icx, flang would require clang and so on.
> Running the Fortran testsuite with only F90_FOR_TARGET=ifx would be the
> equivalent of setting CC_FOR_TARGET=gcc. The test_compiler_info would
> return gcc-* in this case and compiler specific settings not be applied.
> Especially, this made it impossible to run heterogenous combinations of
> C and Fortran compilers and still have all flags/kfails setup correctly.
>
> In order to improve this (and the rest of our patches are base on this)
> we added a new option to get/test_compiler_info: 'f90'. We added a
> Fortran compiler identification mechanism similar to the existing C/CXX
> ones by adding the file compiler.F90. Similar to C/CXX, the Fortran
> compiler detection preprocesses the compiler.F90 file and, depending on
> the macros defined by the compiler, will return the Fortran compiler
> name and version.
>
> We want to note here, that preprocessing is not part of the Fortran
> standard. It was used here as it seems to be common for most compilers
> to have this feature in place (in fact, we don't know of any modern
> Fortran compilers that don't have it).
>
> We added detection for gfortran, ifx, ifort, classic flang, llvm flang,
> and armflang. While we tested the detection for all compilers with
> their latest available versions, we could not test the armflang compiler
> identification. We would kindly ask someone from arm (and I'll cc
> someone in this patch who I've written mails with before) to test these
> detection changes for us. They were extracted from the latest online
> armflang documentation.
>
> At last, when adding the Fortran compiler identification we were faced
> with the problem of properly maintaining F77_FOR_TARGET. We think, this
> feature is not maintained anymore and the last usage of it was removed
> many years ago. Thus, we decided to remove F77_FOR_TARGET from the
> testsuite.
>
> All these changes were tested for regressions on a x86_64 Ubunut20.04
> machine running the boards unix, unix/-m32, native-gdbserver, and
> native-extended-gdbserver (-m32 is acually only properly supported for
> gfortran and ifort as far as we know).
>
> This series did not show any regressions but imporves the testsuite
> support for ifx significantly (in some places also for ifort and flang).
>
> We're looking forward to 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 (15):
> gdb/testsuite: remove F77_FOR_TARGET support
> gdb/testsuite: add local variable for passing 'getting_compiler_info'
> to gdb_compile
> gdb/testsuite: rename intel next gen c/cpp compilers
> gdb/testsuite: disable charset.exp for intel compilers
> testsuite, fortran: make print-formatted.exp more robust
> testsuite, fortran: add required external keyword
> testsuite, fortran: add compiler dependent types to
> dynamic-ptype-whatis
> testsuite, fortran: Add '-debug-parameters all' when compiling with
> ifx
> testsuite/lib: add check_optional_entry for GDBInfoSymbols
> testsuite, fortran: fix info-types for intel compilers
> testsuite, fortran: Add type info of formal parameter 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 | 10 +-
> 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/testsuite/gdb.fortran/print-formatted.exp | 3 +-
> gdb/testsuite/gdb.fortran/print-formatted.f90 | 1 +
> .../gdb.fortran/ptype-on-functions.exp | 12 ++-
> 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 | 61 +++++++----
> gdb/testsuite/lib/sym-info-cmds.exp | 18 +++-
> 28 files changed, 317 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
^ permalink raw reply [flat|nested] 39+ messages in thread