[PATCH 0/4] Adapt Fortran testsuite for ifort

[PATCH 0/4] Adapt Fortran testsuite for ifort

[Nils-Christian Kempke]

Hi,

there were a few places in the testsuite where ifort's behavior was
FAILing the tests and where I think this is not the result of an ifort
bug but rather of a testsuite not forgiving enough.

The attached patches should not change the behavior for any other
compiler, and I could not find any regressions with gfortran/ifx (tested
with unix, unix/m32, native-gdbserver and native-extended-gdbserver).

For ifort this series improves testsuite performance if compared to the
current master:

master before series:

                === gdb Summary ===

  # of expected passes            5771
  # of unexpected failures        238
  # of unknown successes          1
  # of known failures             1
  # of untested testcases         1
  # of unresolved testcases       3
  # of unsupported tests          5
  # of duplicate test names       3

master after series:

                === gdb Summary ===

  # of expected passes            5847
  # of unexpected failures        161
  # of known failures             1
  # of untested testcases         1
  # of unresolved testcases       3
  # of unsupported tests          5
  # of duplicate test names       3


Any feedback is appreciated,

Cheers,
Nils

Nils-Christian Kempke (4):
  testsuite, fortran: make mixed-lang-stack less compiler dependent
  testsuite, fortran: Remove self assignment non-statements
  testsuite, fortran: adapt tests for ifort's 'start' behavior
  testsuite, fortran: make kfail gfortran specific

 gdb/testsuite/gdb.fortran/array-slices-bad.exp    |  5 ++++-
 gdb/testsuite/gdb.fortran/function-calls.exp      |  4 +++-
 gdb/testsuite/gdb.fortran/library-module-lib.f90  |  2 +-
 gdb/testsuite/gdb.fortran/library-module-main.f90 |  2 +-
 gdb/testsuite/gdb.fortran/mixed-lang-stack.exp    |  9 ++++++++-
 gdb/testsuite/gdb.fortran/module.f90              | 11 ++++++-----
 gdb/testsuite/gdb.fortran/vla-type.exp            |  5 +++--
 7 files changed, 26 insertions(+), 12 deletions(-)

-- 
2.25.1

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

[PATCH 1/4] testsuite, fortran: make mixed-lang-stack less compiler dependent

[Nils-Christian Kempke]

In the gdb.fortran/mixed-lang-stack.exp test when somewhere deep in a
bunch of nested function calls we issue and test a 'info args' command
for the mixed_func_1b function (when in that function's frame).

The signature of the function looks like

  subroutine mixed_func_1b(a, b, c, d, e, g)
    use type_module
    implicit none

    integer :: a
    real(kind=4) :: b
    real(kind=8) :: c
    complex(kind=4) :: d
    character(len=*) :: e
    character(len=:), allocatable :: f
    TYPE(MyType) :: g

and usually one would expect arguments a, b, c, d, e, and g to be
emitted here.  However, due to some compiler dependent treatment of the
e array the actual output in the test (with gfortran/ifx) is

  (gdb) info args
  a = 1
  b = 2
  c = 3
  d = (4,5)
  e = 'abcdef'
  g = ( a = 1.5, b = 2.5 )
  _e = 6

where the compiler generated '_e' is emitted as the length of e.  While
ifort also generates an additional length argument, the naming (which is
up to the compilers here I think, I could not find anything in the
Fortran standard about this) is different and we see

  (gdb) info args
  a = 1
  b = 2
  c = 3
  d = (4,5)
  e = 'abcdef'
  g = ( a = 1.5, b = 2.5 )
  .tmp.E.len_V$4a = 6

To make both outputs pass the test, I kept the additional argument for now and
made the regex for the emitted name of the last variable match any
arbitrary name.
---
 gdb/testsuite/gdb.fortran/mixed-lang-stack.exp | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.fortran/mixed-lang-stack.exp b/gdb/testsuite/gdb.fortran/mixed-lang-stack.exp
index 5bed3be869..f8ff3bd5f5 100644
--- a/gdb/testsuite/gdb.fortran/mixed-lang-stack.exp
+++ b/gdb/testsuite/gdb.fortran/mixed-lang-stack.exp
@@ -169,6 +169,13 @@ proc run_tests { lang } {
 	    set g_val_pattern "\\( a = 1.5, b = 2.5 \\)"
 	}
 
+	# The last argument here in info args is compiler generated.  It
+	# contains length of the passed array e (we are in mixed_func_1b here).
+	# For gfortran and ifx the compilers conveniently named this '_e',
+	# ifort however prints .tmp.E.len_V$4a.  As is seems unreasonable to
+	# test for an artificially created name and as at the same time all
+	# 3 tested compilers emit this argument, we only check for its
+	# existence and its value (6).
 	set args_pattern [multi_line \
 			      "a = 1" \
 			      "b = 2" \
@@ -176,7 +183,7 @@ proc run_tests { lang } {
 			      "d = ${d_pattern}" \
 			      "e = ${e_pattern}" \
 			      "g = ${g_val_pattern}" \
-			      "_e = 6" ]
+			      ".* = 6" ]
 
 	gdb_test "info args" $args_pattern \
 	    "info args in frame #7"
-- 
2.25.1

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

[PATCH 2/4] testsuite, fortran: Remove self assignment non-statements

[Nils-Christian Kempke]

There were a couple of places in the testsuite where instructions like

  var = var

were written in the source code of tests.  These were usually dummy
statements meant to generate a line table entry at that line on which
to break later on.

This worked fine for gfortran and ifx, but it seems that, when compiled
with ifort (2021.6.0) these statements do not actually create any
assmbler instructions and especially no line table entries.  Consider
the program

  program test
    Integer var :: var = 1
    var = var
  end program

compiled with gfortran (13.0.0, -O0 -g).  The linetable as emitted by
'objdump --dwarf=decodedline ./a.out' looks like

  test.f90:
  File name   Line number    Starting address    View    Stmt
  test.f90              1            0x401172               x
  test.f90              3            0x401176               x
  test.f90              4            0x401182               x
  test.f90              4            0x401185               x
  test.f90              4            0x401194               x
  test.f90              -            0x4011c0

actually containing line table info for line 3.  Running gdb, breaking
at 3 and checking the assembly we see

   0x0000000000401172 <+0>:     push   %rbp
   0x0000000000401173 <+1>:     mov    %rsp,%rbp
=> 0x0000000000401176 <+4>:     mov    0x2ebc(%rip),%eax   # 0x404038 <var.1>
   0x000000000040117c <+10>:    mov    %eax,0x2eb6(%rip)   # 0x404038 <var.1>
   0x0000000000401182 <+16>:    nop
   0x0000000000401183 <+17>:    pop    %rbp
   0x0000000000401184 <+18>:    ret

so two mov instructions are being issued for this assignment one copying
the value into a register and one writing it back to the same memory.
Ifort (2021.6.0, -O0 -g) on the other hand does not emit anything here
and also has no line table entry:

  test.f90:
  File name   Line number    Starting address    View    Stmt
  test.f90              1            0x4040f8               x
  test.f90              4            0x404109               x
  test.f90              4            0x40410e               x
  test.f90              -            0x404110

As I do not think that this is really a bug (on either side, gfortran/ifx or
ifort), and as I don't think this behavior is covered in the Fortran
standard, I changed these lines to become actual value assignments.

This removes a few FAILs in the testsuite when ran with ifort.
---
 gdb/testsuite/gdb.fortran/library-module-lib.f90  |  2 +-
 gdb/testsuite/gdb.fortran/library-module-main.f90 |  2 +-
 gdb/testsuite/gdb.fortran/module.f90              | 11 ++++++-----
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/gdb/testsuite/gdb.fortran/library-module-lib.f90 b/gdb/testsuite/gdb.fortran/library-module-lib.f90
index 1705afe9df..a5b535a98c 100644
--- a/gdb/testsuite/gdb.fortran/library-module-lib.f90
+++ b/gdb/testsuite/gdb.fortran/library-module-lib.f90
@@ -19,7 +19,7 @@ contains
         subroutine lib_func
         if (var_i .ne. 1) call abort
         var_i = 2
-        var_i = var_i                 ! i-is-2-in-lib
+        var_i = 2                 ! i-is-2-in-lib
         end subroutine lib_func
 end module lib
 
diff --git a/gdb/testsuite/gdb.fortran/library-module-main.f90 b/gdb/testsuite/gdb.fortran/library-module-main.f90
index e55a3e92c5..dcd29f20a0 100644
--- a/gdb/testsuite/gdb.fortran/library-module-main.f90
+++ b/gdb/testsuite/gdb.fortran/library-module-main.f90
@@ -19,5 +19,5 @@
 	call lib_func
         if (var_i .ne. 2) call abort
         if (var_j .ne. 3) call abort
-        var_i = var_i                 ! i-is-2-in-main
+        var_i = 7                 ! i-is-2-in-main
 end
diff --git a/gdb/testsuite/gdb.fortran/module.f90 b/gdb/testsuite/gdb.fortran/module.f90
index f3ad70a3f8..a7150e93c4 100644
--- a/gdb/testsuite/gdb.fortran/module.f90
+++ b/gdb/testsuite/gdb.fortran/module.f90
@@ -40,18 +40,19 @@ end module moduse
         subroutine sub1
         use mod1
         if (var_i .ne. 1) call abort
-        var_i = var_i                         ! i-is-1
+        var_i = 1                         ! i-is-1
         end
 
         subroutine sub2
         use mod2
         if (var_i .ne. 2) call abort
-        var_i = var_i                         ! i-is-2
+        var_i = 2                         ! i-is-2
         end
 
         subroutine sub3
-        USE mod3
-        var_i = var_i                         ! i-is-3
+        use mod3
+	if (var_i .ne. 3) call abort
+        var_i = 3                         ! i-is-3
         END
 
         program module
@@ -68,5 +69,5 @@ end module moduse
         if (var_i .ne. 14) call abort
         if (var_x .ne. 30) call abort
         if (var_z .ne. 31) call abort
-        var_b = var_b                         ! a-b-c-d
+        var_b = 11                         ! a-b-c-d
 end
-- 
2.25.1

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

[PATCH 3/4] testsuite, fortran: adapt tests for ifort's 'start' behavior

[Nils-Christian Kempke]

The modified tests array-slices-bad.exp and vla-type.exp both set a
breakpoint at the first real statement in the respective executables.

Normally, the expected behavior of fortran_runto_main for these would be
the stopping of the debugger at exactly the first statment in the code.

Strangely, neither gfortran nor ifx seem to do this for these tests.
Instead, issuing 'start' in ifx (for either of the 2 tests) lets GDB
stop at the 'program ...' line and gfortran stops at a variable
declaration line.  E.g. for vla-type it stops at

  41        type(five)               :: fivearr (2)

So, actually, ifort's behavior can be considered to be a bit more
'correct' here.  The changes skip running to the first breakpoint when
compiling with ifort, which improves test performance for ifort.  A
similar skip already existed for flang in vla-type.exp.
---
 gdb/testsuite/gdb.fortran/array-slices-bad.exp | 5 ++++-
 gdb/testsuite/gdb.fortran/vla-type.exp         | 5 +++--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/gdb/testsuite/gdb.fortran/array-slices-bad.exp b/gdb/testsuite/gdb.fortran/array-slices-bad.exp
index b832fea292..514f208577 100644
--- a/gdb/testsuite/gdb.fortran/array-slices-bad.exp
+++ b/gdb/testsuite/gdb.fortran/array-slices-bad.exp
@@ -40,7 +40,10 @@ gdb_breakpoint [gdb_get_line_number "First Breakpoint"]
 gdb_breakpoint [gdb_get_line_number "Second Breakpoint"]
 gdb_breakpoint [gdb_get_line_number "Final Breakpoint"]
 
-gdb_continue_to_breakpoint "First Breakpoint"
+# Ifort is already at this line after runto_main.
+if { ![test_compiler_info {ifort-*} f90] } {
+    gdb_continue_to_breakpoint "First Breakpoint"
+}
 
 # Access not yet allocated array.
 gdb_test "print other" " = <not allocated>"
diff --git a/gdb/testsuite/gdb.fortran/vla-type.exp b/gdb/testsuite/gdb.fortran/vla-type.exp
index fc8494fe36..884e0dc113 100755
--- a/gdb/testsuite/gdb.fortran/vla-type.exp
+++ b/gdb/testsuite/gdb.fortran/vla-type.exp
@@ -32,8 +32,9 @@ 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 {flang-*} f90] } {
+# Run to main for for Flang and ifort compilers already breaks here.
+if { ![test_compiler_info {flang-*} f90]
+     && ![test_compiler_info {ifort-*} f90]} {
     gdb_breakpoint [gdb_get_line_number "before-allocated"]
     gdb_continue_to_breakpoint "before-allocated"
 }
-- 
2.25.1

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

[PATCH 4/4] testsuite, fortran: make kfail gfortran specific

[Nils-Christian Kempke]

The modified test in function-calls.exp actually passes with ifort and
ifx.  The particular fail seems to be specific to gfortran.  When the
test was introduced it was only tested with gfortran (actually the
whole patch was written with gfortran and the GNU Fortran argument
passing convention in mind).
---
 gdb/testsuite/gdb.fortran/function-calls.exp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.fortran/function-calls.exp b/gdb/testsuite/gdb.fortran/function-calls.exp
index bc0192be06..533283b9ef 100644
--- a/gdb/testsuite/gdb.fortran/function-calls.exp
+++ b/gdb/testsuite/gdb.fortran/function-calls.exp
@@ -102,7 +102,9 @@ gdb_test "p sum_some(1,2)" " = 3"
 
 # Paragraph 10: optional value arguments. There is insufficient DWARF
 # information to reliably make this case work.
-setup_kfail "gdb/24305" *-*-*
+if { [test_compiler_info {gfortran-*} f90] } {
+    setup_kfail "gdb/24305" *-*-*
+}
 gdb_test "p one_arg_value(10)" " = 10"
 
 # DW_AT_artificial formal parameters must be passed manually. This
-- 
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

[PING 2][PATCH 0/4] Adapt Fortran testsuite for ifort

[Kempke, Nils-Christian]

Ping!

Cheers,
Nils
________________________________
From: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Sent: Friday, June 10, 2022 5:44 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>
Cc: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Subject: [PATCH 0/4] Adapt Fortran testsuite for ifort

Hi,

there were a few places in the testsuite where ifort's behavior was
FAILing the tests and where I think this is not the result of an ifort
bug but rather of a testsuite not forgiving enough.

The attached patches should not change the behavior for any other
compiler, and I could not find any regressions with gfortran/ifx (tested
with unix, unix/m32, native-gdbserver and native-extended-gdbserver).

For ifort this series improves testsuite performance if compared to the
current master:

master before series:

                === gdb Summary ===

  # of expected passes            5771
  # of unexpected failures        238
  # of unknown successes          1
  # of known failures             1
  # of untested testcases         1
  # of unresolved testcases       3
  # of unsupported tests          5
  # of duplicate test names       3

master after series:

                === gdb Summary ===

  # of expected passes            5847
  # of unexpected failures        161
  # of known failures             1
  # of untested testcases         1
  # of unresolved testcases       3
  # of unsupported tests          5
  # of duplicate test names       3


Any feedback is appreciated,

Cheers,
Nils

Nils-Christian Kempke (4):
  testsuite, fortran: make mixed-lang-stack less compiler dependent
  testsuite, fortran: Remove self assignment non-statements
  testsuite, fortran: adapt tests for ifort's 'start' behavior
  testsuite, fortran: make kfail gfortran specific

 gdb/testsuite/gdb.fortran/array-slices-bad.exp    |  5 ++++-
 gdb/testsuite/gdb.fortran/function-calls.exp      |  4 +++-
 gdb/testsuite/gdb.fortran/library-module-lib.f90  |  2 +-
 gdb/testsuite/gdb.fortran/library-module-main.f90 |  2 +-
 gdb/testsuite/gdb.fortran/mixed-lang-stack.exp    |  9 ++++++++-
 gdb/testsuite/gdb.fortran/module.f90              | 11 ++++++-----
 gdb/testsuite/gdb.fortran/vla-type.exp            |  5 +++--
 7 files changed, 26 insertions(+), 12 deletions(-)

--
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

[PING 3][PATCH 0/4] Adapt Fortran testsuite for ifort

[Kempke, Nils-Christian]

Ping!

Thanks,
Nils
________________________________
From: Gdb-patches <gdb-patches-bounces+nils-christian.kempke=intel.com@sourceware.org> on behalf of Kempke, Nils-Christian via Gdb-patches <gdb-patches@sourceware.org>
Sent: Monday, July 4, 2022 5:59 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>
Subject: [PING 2][PATCH 0/4] Adapt Fortran testsuite for ifort

Ping!

Cheers,
Nils
________________________________
From: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Sent: Friday, June 10, 2022 5:44 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>
Cc: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Subject: [PATCH 0/4] Adapt Fortran testsuite for ifort

Hi,

there were a few places in the testsuite where ifort's behavior was
FAILing the tests and where I think this is not the result of an ifort
bug but rather of a testsuite not forgiving enough.

The attached patches should not change the behavior for any other
compiler, and I could not find any regressions with gfortran/ifx (tested
with unix, unix/m32, native-gdbserver and native-extended-gdbserver).

For ifort this series improves testsuite performance if compared to the
current master:

master before series:

                === gdb Summary ===

  # of expected passes            5771
  # of unexpected failures        238
  # of unknown successes          1
  # of known failures             1
  # of untested testcases         1
  # of unresolved testcases       3
  # of unsupported tests          5
  # of duplicate test names       3

master after series:

                === gdb Summary ===

  # of expected passes            5847
  # of unexpected failures        161
  # of known failures             1
  # of untested testcases         1
  # of unresolved testcases       3
  # of unsupported tests          5
  # of duplicate test names       3


Any feedback is appreciated,

Cheers,
Nils

Nils-Christian Kempke (4):
  testsuite, fortran: make mixed-lang-stack less compiler dependent
  testsuite, fortran: Remove self assignment non-statements
  testsuite, fortran: adapt tests for ifort's 'start' behavior
  testsuite, fortran: make kfail gfortran specific

 gdb/testsuite/gdb.fortran/array-slices-bad.exp    |  5 ++++-
 gdb/testsuite/gdb.fortran/function-calls.exp      |  4 +++-
 gdb/testsuite/gdb.fortran/library-module-lib.f90  |  2 +-
 gdb/testsuite/gdb.fortran/library-module-main.f90 |  2 +-
 gdb/testsuite/gdb.fortran/mixed-lang-stack.exp    |  9 ++++++++-
 gdb/testsuite/gdb.fortran/module.f90              | 11 ++++++-----
 gdb/testsuite/gdb.fortran/vla-type.exp            |  5 +++--
 7 files changed, 26 insertions(+), 12 deletions(-)

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

Re: [PING 4][PATCH 0/4] Adapt Fortran testsuite for ifort

[Kempke, Nils-Christian]

Ping!,

Thanks,
Nils
________________________________
From: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Sent: Tuesday, July 12, 2022 2:55 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>; Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Subject: [PING 3][PATCH 0/4] Adapt Fortran testsuite for ifort

Ping!

Thanks,
Nils
________________________________
From: Gdb-patches <gdb-patches-bounces+nils-christian.kempke=intel.com@sourceware.org> on behalf of Kempke, Nils-Christian via Gdb-patches <gdb-patches@sourceware.org>
Sent: Monday, July 4, 2022 5:59 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>
Subject: [PING 2][PATCH 0/4] Adapt Fortran testsuite for ifort

Ping!

Cheers,
Nils
________________________________
From: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Sent: Friday, June 10, 2022 5:44 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>
Cc: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Subject: [PATCH 0/4] Adapt Fortran testsuite for ifort

Hi,

there were a few places in the testsuite where ifort's behavior was
FAILing the tests and where I think this is not the result of an ifort
bug but rather of a testsuite not forgiving enough.

The attached patches should not change the behavior for any other
compiler, and I could not find any regressions with gfortran/ifx (tested
with unix, unix/m32, native-gdbserver and native-extended-gdbserver).

For ifort this series improves testsuite performance if compared to the
current master:

master before series:

                === gdb Summary ===

  # of expected passes            5771
  # of unexpected failures        238
  # of unknown successes          1
  # of known failures             1
  # of untested testcases         1
  # of unresolved testcases       3
  # of unsupported tests          5
  # of duplicate test names       3

master after series:

                === gdb Summary ===

  # of expected passes            5847
  # of unexpected failures        161
  # of known failures             1
  # of untested testcases         1
  # of unresolved testcases       3
  # of unsupported tests          5
  # of duplicate test names       3


Any feedback is appreciated,

Cheers,
Nils

Nils-Christian Kempke (4):
  testsuite, fortran: make mixed-lang-stack less compiler dependent
  testsuite, fortran: Remove self assignment non-statements
  testsuite, fortran: adapt tests for ifort's 'start' behavior
  testsuite, fortran: make kfail gfortran specific

 gdb/testsuite/gdb.fortran/array-slices-bad.exp    |  5 ++++-
 gdb/testsuite/gdb.fortran/function-calls.exp      |  4 +++-
 gdb/testsuite/gdb.fortran/library-module-lib.f90  |  2 +-
 gdb/testsuite/gdb.fortran/library-module-main.f90 |  2 +-
 gdb/testsuite/gdb.fortran/mixed-lang-stack.exp    |  9 ++++++++-
 gdb/testsuite/gdb.fortran/module.f90              | 11 ++++++-----
 gdb/testsuite/gdb.fortran/vla-type.exp            |  5 +++--
 7 files changed, 26 insertions(+), 12 deletions(-)

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

Re: [PING 4][PATCH 0/4] Adapt Fortran testsuite for ifort

[Kempke, Nils-Christian]

Ping!,

Thanks,
Nils

________________________________
From: Gdb-patches <gdb-patches-bounces+nils-christian.kempke=intel.com@sourceware.org> on behalf of Kempke, Nils-Christian via Gdb-patches <gdb-patches@sourceware.org>
Sent: Wednesday, July 27, 2022 7:14 AM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>
Subject: Re: [PING 4][PATCH 0/4] Adapt Fortran testsuite for ifort

Ping!,

Thanks,
Nils
________________________________
From: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Sent: Tuesday, July 12, 2022 2:55 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>; Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Subject: [PING 3][PATCH 0/4] Adapt Fortran testsuite for ifort

Ping!

Thanks,
Nils
________________________________
From: Gdb-patches <gdb-patches-bounces+nils-christian.kempke=intel.com@sourceware.org> on behalf of Kempke, Nils-Christian via Gdb-patches <gdb-patches@sourceware.org>
Sent: Monday, July 4, 2022 5:59 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>
Subject: [PING 2][PATCH 0/4] Adapt Fortran testsuite for ifort

Ping!

Cheers,
Nils
________________________________
From: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Sent: Friday, June 10, 2022 5:44 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>
Cc: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Subject: [PATCH 0/4] Adapt Fortran testsuite for ifort

Hi,

there were a few places in the testsuite where ifort's behavior was
FAILing the tests and where I think this is not the result of an ifort
bug but rather of a testsuite not forgiving enough.

The attached patches should not change the behavior for any other
compiler, and I could not find any regressions with gfortran/ifx (tested
with unix, unix/m32, native-gdbserver and native-extended-gdbserver).

For ifort this series improves testsuite performance if compared to the
current master:

master before series:

                === gdb Summary ===

  # of expected passes            5771
  # of unexpected failures        238
  # of unknown successes          1
  # of known failures             1
  # of untested testcases         1
  # of unresolved testcases       3
  # of unsupported tests          5
  # of duplicate test names       3

master after series:

                === gdb Summary ===

  # of expected passes            5847
  # of unexpected failures        161
  # of known failures             1
  # of untested testcases         1
  # of unresolved testcases       3
  # of unsupported tests          5
  # of duplicate test names       3


Any feedback is appreciated,

Cheers,
Nils

Nils-Christian Kempke (4):
  testsuite, fortran: make mixed-lang-stack less compiler dependent
  testsuite, fortran: Remove self assignment non-statements
  testsuite, fortran: adapt tests for ifort's 'start' behavior
  testsuite, fortran: make kfail gfortran specific

 gdb/testsuite/gdb.fortran/array-slices-bad.exp    |  5 ++++-
 gdb/testsuite/gdb.fortran/function-calls.exp      |  4 +++-
 gdb/testsuite/gdb.fortran/library-module-lib.f90  |  2 +-
 gdb/testsuite/gdb.fortran/library-module-main.f90 |  2 +-
 gdb/testsuite/gdb.fortran/mixed-lang-stack.exp    |  9 ++++++++-
 gdb/testsuite/gdb.fortran/module.f90              | 11 ++++++-----
 gdb/testsuite/gdb.fortran/vla-type.exp            |  5 +++--
 7 files changed, 26 insertions(+), 12 deletions(-)

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

Re: [PING 5][PATCH 0/4] Adapt Fortran testsuite for ifort

[Kempke, Nils-Christian]

Ping!,
Thanks,
Nils
________________________________
From: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Sent: Monday, August 8, 2022 2:53 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>; Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Subject: Re: [PING 4][PATCH 0/4] Adapt Fortran testsuite for ifort


Ping!,

Thanks,
Nils

________________________________
From: Gdb-patches <gdb-patches-bounces+nils-christian.kempke=intel.com@sourceware.org> on behalf of Kempke, Nils-Christian via Gdb-patches <gdb-patches@sourceware.org>
Sent: Wednesday, July 27, 2022 7:14 AM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>
Subject: Re: [PING 4][PATCH 0/4] Adapt Fortran testsuite for ifort

Ping!,

Thanks,
Nils
________________________________
From: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Sent: Tuesday, July 12, 2022 2:55 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>; Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Subject: [PING 3][PATCH 0/4] Adapt Fortran testsuite for ifort

Ping!

Thanks,
Nils
________________________________
From: Gdb-patches <gdb-patches-bounces+nils-christian.kempke=intel.com@sourceware.org> on behalf of Kempke, Nils-Christian via Gdb-patches <gdb-patches@sourceware.org>
Sent: Monday, July 4, 2022 5:59 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>
Subject: [PING 2][PATCH 0/4] Adapt Fortran testsuite for ifort

Ping!

Cheers,
Nils
________________________________
From: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Sent: Friday, June 10, 2022 5:44 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>
Cc: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Subject: [PATCH 0/4] Adapt Fortran testsuite for ifort

Hi,

there were a few places in the testsuite where ifort's behavior was
FAILing the tests and where I think this is not the result of an ifort
bug but rather of a testsuite not forgiving enough.

The attached patches should not change the behavior for any other
compiler, and I could not find any regressions with gfortran/ifx (tested
with unix, unix/m32, native-gdbserver and native-extended-gdbserver).

For ifort this series improves testsuite performance if compared to the
current master:

master before series:

                === gdb Summary ===

  # of expected passes            5771
  # of unexpected failures        238
  # of unknown successes          1
  # of known failures             1
  # of untested testcases         1
  # of unresolved testcases       3
  # of unsupported tests          5
  # of duplicate test names       3

master after series:

                === gdb Summary ===

  # of expected passes            5847
  # of unexpected failures        161
  # of known failures             1
  # of untested testcases         1
  # of unresolved testcases       3
  # of unsupported tests          5
  # of duplicate test names       3


Any feedback is appreciated,

Cheers,
Nils

Nils-Christian Kempke (4):
  testsuite, fortran: make mixed-lang-stack less compiler dependent
  testsuite, fortran: Remove self assignment non-statements
  testsuite, fortran: adapt tests for ifort's 'start' behavior
  testsuite, fortran: make kfail gfortran specific

 gdb/testsuite/gdb.fortran/array-slices-bad.exp    |  5 ++++-
 gdb/testsuite/gdb.fortran/function-calls.exp      |  4 +++-
 gdb/testsuite/gdb.fortran/library-module-lib.f90  |  2 +-
 gdb/testsuite/gdb.fortran/library-module-main.f90 |  2 +-
 gdb/testsuite/gdb.fortran/mixed-lang-stack.exp    |  9 ++++++++-
 gdb/testsuite/gdb.fortran/module.f90              | 11 ++++++-----
 gdb/testsuite/gdb.fortran/vla-type.exp            |  5 +++--
 7 files changed, 26 insertions(+), 12 deletions(-)

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

Re: [PING 6][PATCH 0/4] Adapt Fortran testsuite for ifort

[Kempke, Nils-Christian]

Ping!

Thanks,
Nils
________________________________
From: Gdb-patches <gdb-patches-bounces+nils-christian.kempke=intel.com@sourceware.org> on behalf of Kempke, Nils-Christian via Gdb-patches <gdb-patches@sourceware.org>
Sent: Tuesday, August 23, 2022 4:43 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>
Subject: Re: [PING 5][PATCH 0/4] Adapt Fortran testsuite for ifort

Ping!,
Thanks,
Nils
________________________________
From: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Sent: Monday, August 8, 2022 2:53 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>; Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Subject: Re: [PING 4][PATCH 0/4] Adapt Fortran testsuite for ifort


Ping!,

Thanks,
Nils

________________________________
From: Gdb-patches <gdb-patches-bounces+nils-christian.kempke=intel.com@sourceware.org> on behalf of Kempke, Nils-Christian via Gdb-patches <gdb-patches@sourceware.org>
Sent: Wednesday, July 27, 2022 7:14 AM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>
Subject: Re: [PING 4][PATCH 0/4] Adapt Fortran testsuite for ifort

Ping!,

Thanks,
Nils
________________________________
From: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Sent: Tuesday, July 12, 2022 2:55 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>; Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Subject: [PING 3][PATCH 0/4] Adapt Fortran testsuite for ifort

Ping!

Thanks,
Nils
________________________________
From: Gdb-patches <gdb-patches-bounces+nils-christian.kempke=intel.com@sourceware.org> on behalf of Kempke, Nils-Christian via Gdb-patches <gdb-patches@sourceware.org>
Sent: Monday, July 4, 2022 5:59 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>
Subject: [PING 2][PATCH 0/4] Adapt Fortran testsuite for ifort

Ping!

Cheers,
Nils
________________________________
From: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Sent: Friday, June 10, 2022 5:44 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>
Cc: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Subject: [PATCH 0/4] Adapt Fortran testsuite for ifort

Hi,

there were a few places in the testsuite where ifort's behavior was
FAILing the tests and where I think this is not the result of an ifort
bug but rather of a testsuite not forgiving enough.

The attached patches should not change the behavior for any other
compiler, and I could not find any regressions with gfortran/ifx (tested
with unix, unix/m32, native-gdbserver and native-extended-gdbserver).

For ifort this series improves testsuite performance if compared to the
current master:

master before series:

                === gdb Summary ===

  # of expected passes            5771
  # of unexpected failures        238
  # of unknown successes          1
  # of known failures             1
  # of untested testcases         1
  # of unresolved testcases       3
  # of unsupported tests          5
  # of duplicate test names       3

master after series:

                === gdb Summary ===

  # of expected passes            5847
  # of unexpected failures        161
  # of known failures             1
  # of untested testcases         1
  # of unresolved testcases       3
  # of unsupported tests          5
  # of duplicate test names       3


Any feedback is appreciated,

Cheers,
Nils

Nils-Christian Kempke (4):
  testsuite, fortran: make mixed-lang-stack less compiler dependent
  testsuite, fortran: Remove self assignment non-statements
  testsuite, fortran: adapt tests for ifort's 'start' behavior
  testsuite, fortran: make kfail gfortran specific

 gdb/testsuite/gdb.fortran/array-slices-bad.exp    |  5 ++++-
 gdb/testsuite/gdb.fortran/function-calls.exp      |  4 +++-
 gdb/testsuite/gdb.fortran/library-module-lib.f90  |  2 +-
 gdb/testsuite/gdb.fortran/library-module-main.f90 |  2 +-
 gdb/testsuite/gdb.fortran/mixed-lang-stack.exp    |  9 ++++++++-
 gdb/testsuite/gdb.fortran/module.f90              | 11 ++++++-----
 gdb/testsuite/gdb.fortran/vla-type.exp            |  5 +++--
 7 files changed, 26 insertions(+), 12 deletions(-)

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

Re: [PING 6][PATCH 0/4] Adapt Fortran testsuite for ifort

[Kempke, Nils-Christian]

[-- Attachment #1: Type: text/plain, Size: 5735 bytes --]

Ping!

Thanks,
Nils
________________________________
From: Gdb-patches <gdb-patches-bounces+nils-christian.kempke=intel.com@sourceware.org> on behalf of Kempke, Nils-Christian via Gdb-patches <gdb-patches@sourceware.org>
Sent: Tuesday, August 23, 2022 4:43 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>
Subject: Re: [PING 5][PATCH 0/4] Adapt Fortran testsuite for ifort

Ping!,
Thanks,
Nils
________________________________
From: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Sent: Monday, August 8, 2022 2:53 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>; Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Subject: Re: [PING 4][PATCH 0/4] Adapt Fortran testsuite for ifort


Ping!,

Thanks,
Nils

________________________________
From: Gdb-patches <gdb-patches-bounces+nils-christian.kempke=intel.com@sourceware.org> on behalf of Kempke, Nils-Christian via Gdb-patches <gdb-patches@sourceware.org>
Sent: Wednesday, July 27, 2022 7:14 AM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>
Subject: Re: [PING 4][PATCH 0/4] Adapt Fortran testsuite for ifort

Ping!,

Thanks,
Nils
________________________________
From: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Sent: Tuesday, July 12, 2022 2:55 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>; Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Subject: [PING 3][PATCH 0/4] Adapt Fortran testsuite for ifort

Ping!

Thanks,
Nils
________________________________
From: Gdb-patches <gdb-patches-bounces+nils-christian.kempke=intel.com@sourceware.org> on behalf of Kempke, Nils-Christian via Gdb-patches <gdb-patches@sourceware.org>
Sent: Monday, July 4, 2022 5:59 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>
Subject: [PING 2][PATCH 0/4] Adapt Fortran testsuite for ifort

Ping!

Cheers,
Nils
________________________________
From: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Sent: Friday, June 10, 2022 5:44 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>
Cc: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
Subject: [PATCH 0/4] Adapt Fortran testsuite for ifort

Hi,

there were a few places in the testsuite where ifort's behavior was
FAILing the tests and where I think this is not the result of an ifort
bug but rather of a testsuite not forgiving enough.

The attached patches should not change the behavior for any other
compiler, and I could not find any regressions with gfortran/ifx (tested
with unix, unix/m32, native-gdbserver and native-extended-gdbserver).

For ifort this series improves testsuite performance if compared to the
current master:

master before series:

                === gdb Summary ===

  # of expected passes            5771
  # of unexpected failures        238
  # of unknown successes          1
  # of known failures             1
  # of untested testcases         1
  # of unresolved testcases       3
  # of unsupported tests          5
  # of duplicate test names       3

master after series:

                === gdb Summary ===

  # of expected passes            5847
  # of unexpected failures        161
  # of known failures             1
  # of untested testcases         1
  # of unresolved testcases       3
  # of unsupported tests          5
  # of duplicate test names       3


Any feedback is appreciated,

Cheers,
Nils

Nils-Christian Kempke (4):
  testsuite, fortran: make mixed-lang-stack less compiler dependent
  testsuite, fortran: Remove self assignment non-statements
  testsuite, fortran: adapt tests for ifort's 'start' behavior
  testsuite, fortran: make kfail gfortran specific

 gdb/testsuite/gdb.fortran/array-slices-bad.exp    |  5 ++++-
 gdb/testsuite/gdb.fortran/function-calls.exp      |  4 +++-
 gdb/testsuite/gdb.fortran/library-module-lib.f90  |  2 +-
 gdb/testsuite/gdb.fortran/library-module-main.f90 |  2 +-
 gdb/testsuite/gdb.fortran/mixed-lang-stack.exp    |  9 ++++++++-
 gdb/testsuite/gdb.fortran/module.f90              | 11 ++++++-----
 gdb/testsuite/gdb.fortran/vla-type.exp            |  5 +++--
 7 files changed, 26 insertions(+), 12 deletions(-)

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

Re: [PATCH 3/4] testsuite, fortran: adapt tests for ifort's 'start' behavior

[Tom Tromey]

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

> -gdb_continue_to_breakpoint "First Breakpoint"
> +# Ifort is already at this line after runto_main.
> +if { ![test_compiler_info {ifort-*} f90] } {
> +    gdb_continue_to_breakpoint "First Breakpoint"
> +}
 
I suspect that in this particular test it would be more robust to simply
run to this first breakpoint and not try to run to main.  That way the
test would be independent of where the compiler chooses to emit the
'main' entry point.

Tom

Re: [PATCH 0/4] Adapt Fortran testsuite for ifort

[Tom Tromey]

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

> The attached patches should not change the behavior for any other
> compiler, and I could not find any regressions with gfortran/ifx (tested
> with unix, unix/m32, native-gdbserver and native-extended-gdbserver).

I had a comment on patch 3, but otherwise these look fine to me.
Thanks for doing this.

Tom

RE: [PATCH 3/4] testsuite, fortran: adapt tests for ifort's 'start' behavior

[Kempke, Nils-Christian]

Hi Tom,

Yes, that is true.. But I think that would also hold true for the 
gdb.fortran/vla-type.exp test then - where both, ifort and flang
skip all variable declaration statements, too.  Or do you see a
difference there?

I'll change this patch for both tests and remove the
get_compiler_info checks as well as the fortran_run_to_main call
for now.  Instead I'll directly call the 'runto'.

Thanks!

Nils

> -----Original Message-----
> From: Tom Tromey <tom@tromey.com>
> Sent: Tuesday, August 30, 2022 9:52 PM
> To: Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org>
> Cc: Kempke, Nils-Christian <nils-christian.kempke@intel.com>
> Subject: Re: [PATCH 3/4] testsuite, fortran: adapt tests for ifort's 'start'
> behavior
> 
> >>>>> Nils-Christian Kempke via Gdb-patches <gdb-
> patches@sourceware.org> writes:
> 
> > -gdb_continue_to_breakpoint "First Breakpoint"
> > +# Ifort is already at this line after runto_main.
> > +if { ![test_compiler_info {ifort-*} f90] } {
> > +    gdb_continue_to_breakpoint "First Breakpoint"
> > +}
> 
> I suspect that in this particular test it would be more robust to simply
> run to this first breakpoint and not try to run to main.  That way the
> test would be independent of where the compiler chooses to emit the
> 'main' entry point.
> 
> Tom
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [PATCH 3/4] testsuite, fortran: adapt tests for ifort's 'start' behavior

[Tom Tromey]

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

> Yes, that is true.. But I think that would also hold true for the 
> gdb.fortran/vla-type.exp test then - where both, ifort and flang
> skip all variable declaration statements, too.  Or do you see a
> difference there?

I didn't really look at that test and I saw in the context of the patch
that there was already a special case.  But yes, it does seem like it
would be more robust.

thanks,
Tom