public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Nils-Christian Kempke <nils-christian.kempke@intel.com>
To: gdb-patches@sourceware.org
Cc: tom@tromey.com, Nils-Christian Kempke <nils-christian.kempke@intel.com>
Subject: [PATCH v2 3/4] testsuite, fortran: adapt tests for ifort's 'start' behavior
Date: Wed, 31 Aug 2022 11:36:49 +0200	[thread overview]
Message-ID: <20220831093650.674582-4-nils-christian.kempke@intel.com> (raw)
In-Reply-To: <20220831093650.674582-1-nils-christian.kempke@intel.com>

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.  This patch remove the fortran_runto_main in the
two tests and instead uses runto to directly run to the first breakpoint
set at the first program statement.  This works with both compiler
behaviors and makes the tests more robust.
---
 gdb/testsuite/gdb.fortran/array-slices-bad.exp | 13 +++++--------
 gdb/testsuite/gdb.fortran/vla-type.exp         | 11 +++--------
 2 files changed, 8 insertions(+), 16 deletions(-)

diff --git a/gdb/testsuite/gdb.fortran/array-slices-bad.exp b/gdb/testsuite/gdb.fortran/array-slices-bad.exp
index b832fea292a..a9da37bc3dd 100644
--- a/gdb/testsuite/gdb.fortran/array-slices-bad.exp
+++ b/gdb/testsuite/gdb.fortran/array-slices-bad.exp
@@ -28,20 +28,17 @@ if {[prepare_for_testing ${testfile}.exp ${testfile} ${srcfile} \
 # Avoid shared lib symbols.
 gdb_test_no_output "set auto-solib-add off"
 
-if ![fortran_runto_main] {
-    return -1
-}
-
 # Avoid libc symbols, in particular the 'array' type.
 gdb_test_no_output "nosharedlibrary"
 
-# gdb_breakpoint [gdb_get_line_number "Display Message Breakpoint"]
-gdb_breakpoint [gdb_get_line_number "First Breakpoint"]
+if {![runto [gdb_get_line_number "First Breakpoint"]]} {
+    perror "couldn't run to breakpoint First Breakpoint"
+    return -1
+}
+
 gdb_breakpoint [gdb_get_line_number "Second Breakpoint"]
 gdb_breakpoint [gdb_get_line_number "Final Breakpoint"]
 
-gdb_continue_to_breakpoint "First Breakpoint"
-
 # Access not yet allocated array.
 gdb_test "print other" " = <not allocated>"
 gdb_test "print other(0:4,2:3)" "array not allocated"
diff --git a/gdb/testsuite/gdb.fortran/vla-type.exp b/gdb/testsuite/gdb.fortran/vla-type.exp
index fc8494fe36c..1bc30dc7f15 100755
--- a/gdb/testsuite/gdb.fortran/vla-type.exp
+++ b/gdb/testsuite/gdb.fortran/vla-type.exp
@@ -23,19 +23,14 @@ if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile} \
     return -1
 }
 
-if ![fortran_runto_main] {
-    return -1
-}
-
 # Depending on the compiler being used, the type names can be printed differently.
 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] } {
-    gdb_breakpoint [gdb_get_line_number "before-allocated"]
-    gdb_continue_to_breakpoint "before-allocated"
+if {![runto [gdb_get_line_number "before-allocated"]]} {
+    perror "couldn't run to breakpoint before-allocated"
+    return -1
 }
 
 gdb_test "print twov" " = \\\( ivla1 = <not allocated>, ivla2 = <not 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


  parent reply	other threads:[~2022-08-31  9:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-31  9:36 [PATCH v2 0/4] Adapt Fortran testsuite for ifort Nils-Christian Kempke
2022-08-31  9:36 ` [PATCH v2 1/4] testsuite, fortran: make mixed-lang-stack less compiler dependent Nils-Christian Kempke
2022-08-31  9:36 ` [PATCH v2 2/4] testsuite, fortran: Remove self assignment non-statements Nils-Christian Kempke
2022-08-31  9:36 ` Nils-Christian Kempke [this message]
2022-08-31  9:36 ` [PATCH v2 4/4] testsuite, fortran: make kfail gfortran specific Nils-Christian Kempke
2022-09-19 10:18 ` [PING][PATCH v2 0/4] Adapt Fortran testsuite for ifort Kempke, Nils-Christian
2022-09-19 10:18   ` Kempke, Nils-Christian
2022-09-26 14:02   ` [PING 2][PATCH " Kempke, Nils-Christian
2022-09-26 14:02     ` Kempke, Nils-Christian
2022-10-05 20:23     ` [PING 3][PATCH " Kempke, Nils-Christian
2022-10-05 20:23       ` Kempke, Nils-Christian
2022-10-13  8:52       ` [PING 4][PATCH " Kempke, Nils-Christian
2022-10-13  8:52         ` Kempke, Nils-Christian
2022-10-21  8:15         ` [PING 5][PATCH " Kempke, Nils-Christian
2022-10-21  8:15           ` Kempke, Nils-Christian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220831093650.674582-4-nils-christian.kempke@intel.com \
    --to=nils-christian.kempke@intel.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).