From: Nils-Christian Kempke <nils-christian.kempke@intel.com>
To: gdb-patches@sourceware.org
Subject: [PATCH 2/4] testsuite, fortran: Remove self assignment non-statements
Date: Fri, 10 Jun 2022 17:44:58 +0200 [thread overview]
Message-ID: <20220610154500.374897-3-nils-christian.kempke@intel.com> (raw)
In-Reply-To: <20220610154500.374897-1-nils-christian.kempke@intel.com>
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
next prev parent reply other threads:[~2022-06-10 15:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-10 15:44 [PATCH 0/4] Adapt Fortran testsuite for ifort Nils-Christian Kempke
2022-06-10 15:44 ` [PATCH 1/4] testsuite, fortran: make mixed-lang-stack less compiler dependent Nils-Christian Kempke
2022-06-10 15:44 ` Nils-Christian Kempke [this message]
2022-06-10 15:44 ` [PATCH 3/4] testsuite, fortran: adapt tests for ifort's 'start' behavior Nils-Christian Kempke
2022-08-30 19:51 ` Tom Tromey
2022-08-31 9:32 ` Kempke, Nils-Christian
2022-08-31 17:22 ` Tom Tromey
2022-06-10 15:45 ` [PATCH 4/4] testsuite, fortran: make kfail gfortran specific Nils-Christian Kempke
2022-07-04 15:59 ` [PING 2][PATCH 0/4] Adapt Fortran testsuite for ifort Kempke, Nils-Christian
2022-07-12 12:55 ` [PING 3][PATCH " Kempke, Nils-Christian
2022-07-27 5:14 ` [PING 4][PATCH " Kempke, Nils-Christian
2022-08-08 12:53 ` Kempke, Nils-Christian
2022-08-23 14:43 ` [PING 5][PATCH " Kempke, Nils-Christian
2022-08-30 14:47 ` [PING 6][PATCH " Kempke, Nils-Christian
2022-08-30 14:47 ` Kempke, Nils-Christian
2022-08-30 19:52 ` [PATCH " Tom Tromey
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=20220610154500.374897-3-nils-christian.kempke@intel.com \
--to=nils-christian.kempke@intel.com \
--cc=gdb-patches@sourceware.org \
/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).