public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/99816] New: fortran do loop line table issue
@ 2021-03-29 15:36 andrew.burgess at embecosm dot com
2021-03-29 16:08 ` [Bug fortran/99816] " rguenth at gcc dot gnu.org
0 siblings, 1 reply; 2+ messages in thread
From: andrew.burgess at embecosm dot com @ 2021-03-29 15:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99816
Bug ID: 99816
Summary: fortran do loop line table issue
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: andrew.burgess at embecosm dot com
Target Milestone: ---
Consider this Fortran program:
subroutine sub(a,n)
dimension a(n)
do 100 i = 1, n
a(i) = i
100 continue ! Breakpoint here.
return
end subroutine sub
program test
dimension a(10)
write(*,*) 'This is a test.'
call sub(a,10)
write(*,*) a
end program test
The line marked 'Breakpoint here' is line #5. I compile the test as:
gfortran -g3 -O0 -o bug.x bug.f90
The run this GDB session:
$ gdb bug.x
(gdb) b 5
Breakpoint 1 at 0x4011de: file bug.f90, line 5.
(gdb) r
Starting program: /home/andrew/tmp/bug.x
This is a test.
Breakpoint 1, sub (a=..., n=10) at bug.f90:5
5 100 continue ! Breakpoint here.
(gdb) c
Continuing.
1.00000000 2.00000000 3.00000000 4.00000000
5.00000000 6.00000000 7.00000000 8.00000000 9.00000000
10.0000000
[Inferior 1 (process 1170395) exited normally]
Notice that the breakpoint was only hit once, despite line #5 being the last
statement _within_ the loop. My expectation was that this breakpoint would be
hit 10 times.
I then look at the line table (I've truncated the output, but included the
lines we care about):
$ objdump --dwarf=decodedline bug.x
bug.x: file format elf64-x86-64
Contents of the .debug_line section:
CU: ./bug.f90:
File name Line number Starting address View
Stmt
bug.f90 1 0x401176
x
bug.f90 1 0x401183
x
bug.f90 3 0x4011a7
x
bug.f90 3 0x4011b4
bug.f90 4 0x4011c1
x
bug.f90 3 0x4011d8
x
bug.f90 5 0x4011de
x
bug.f90 6 0x4011df
x
bug.f90 7 0x4011e0
x
bug.f90 9 0x4011e3
x
Finally, here's a snippet of the generated assembler code (from objdump -d)
with an annotation of my own:
....
4011b4: 39 55 ec cmp %edx,-0x14(%rbp)
4011b7: 0f 9f c0 setg %al
4011ba: 0f b6 c0 movzbl %al,%eax
4011bd: 85 c0 test %eax,%eax
4011bf: 75 1d jne 4011de <sub_+0x68>
4011c1: 8b 45 ec mov -0x14(%rbp),%eax
4011c4: 48 98 cltq
4011c6: 48 8d 48 ff lea -0x1(%rax),%rcx
4011ca: f3 0f 2a 45 ec cvtsi2ssl -0x14(%rbp),%xmm0
4011cf: 48 8b 45 d8 mov -0x28(%rbp),%rax
4011d3: f3 0f 11 04 88 movss %xmm0,(%rax,%rcx,4)
4011d8: 83 45 ec 01 addl $0x1,-0x14(%rbp)
4011dc: eb d6 jmp 4011b4 <sub_+0x3e>
4011de: 90 nop <----------- Line 5 is
recorded as here!
4011df: 90 nop
4011e0: 5b pop %rbx
4011e1: 5d pop %rbp
4011e2: c3 retq
You can see that line 5 is clearly recorded at a point after the loop, hence
why we only hit the breakpoint once.
I've tested this with gfortran versions 'GNU Fortran (GCC) 9.3.1 20200408 (Red
Hat 9.3.1-2)' (my distro's default version) and also with current HEAD of
master branch (e19afa0645f).
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug fortran/99816] fortran do loop line table issue
2021-03-29 15:36 [Bug fortran/99816] New: fortran do loop line table issue andrew.burgess at embecosm dot com
@ 2021-03-29 16:08 ` rguenth at gcc dot gnu.org
0 siblings, 0 replies; 2+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-29 16:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99816
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-debug
Last reconfirmed| |2021-03-29
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
The IL from the frontend is (with line numbers):
__attribute__((fn spec (". w w ")))
void sub (real(kind=4)[0:D.3943] * restrict a, integer(kind=4) & restrict n)
[t.f90:1:16] {
integer(kind=8) ubound.0;
integer(kind=8) size.1;
integer(kind=4) i;
integer(kind=8) D.3943;
bitsizetype D.3944;
sizetype D.3945;
[t.f90:1:18] ubound.0 = [t.f90:1:18] (integer(kind=8)) [t.f90:1:18] *n;
[t.f90:1:18] size.1 = [t.f90:1:18] NON_LVALUE_EXPR <ubound.0>;
[t.f90:1:18] size.1 = [t.f90:1:18] MAX_EXPR <size.1, 0>;
[t.f90:1:18] D.3943 = [t.f90:1:16] size.1 + -1;
[t.f90:1:18] D.3944 = (bitsizetype) (sizetype) NON_LVALUE_EXPR <size.1> * 32;
[t.f90:1:18] D.3945 = (sizetype) NON_LVALUE_EXPR <size.1> * 4;
[t.f90:3:22] {
integer(kind=4) D.3938;
[t.f90:3:22] D.3938 = [t.f90:3:22] *n;
[t.f90:3:17] i = 1;
[t.f90:3:17] while (1)
{
[t.f90:5:34] {
logical(kind=4) D.3941;
[t.f90:3:17] D.3941 = [t.f90:3:17] i > D.3938;
[t.f90:3:17] if (D.3941) [t.f90:3:17] goto L.2;
[t.f90:4:15] [t.f90:4:15] ([t.f90:4:15] *a)[[t.f90:4:15]
(integer(kind=8)) i + -1] = (real(kind=4)) i;
[t.f90:4:15] __label_000100:;
[t.f90:5:34] L.1:;
[t.f90:3:17] i = [t.f90:3:17] i + 1;
}
}
[t.f90:5:34] L.2:;
}
[t.f90:6:13] return;
}
where we have two labels / empty stmts with line number 5, one inside and
one outside of the loop. Note the actual "continue" is the end of the
while loop.
gimplification turns this into
[t.f90:3:22] {
integer(kind=4) D.3938;
[t.f90:3:22] D.3938 = [t.f90:3:22] *n;
[t.f90:3:17] i = 1;
<D.3974>:
[t.f90:5:34] {
logical(kind=4) D.3941;
[t.f90:3:17] D.3941 = i > D.3938;
[t.f90:3:17] if (D.3941 != 0) goto L.2; else goto <D.3975>;
<D.3975>:
[t.f90:4:15] _5 = (integer(kind=8)) i;
[t.f90:4:15] _6 = _5 + -1;
[t.f90:4:15] _7 = (real(kind=4)) i;
[t.f90:4:15] [t.f90:4:15] [t.f90:4:15] (*a)[_6] = _7;
[t.f90:4:15] __label_000100:
[t.f90:5:34] L.1:
[t.f90:3:17] i = i + 1;
}
[t.f90:3:17] goto <D.3974>;
[t.f90:5:34] L.2:
}
note how the while (1) backwards jump gets line number 3. How the Fortran
frontend uses LOOP_EXPR but does control flow by itself makes it difficult
to deal with this.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2021-03-29 16:08 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-29 15:36 [Bug fortran/99816] New: fortran do loop line table issue andrew.burgess at embecosm dot com
2021-03-29 16:08 ` [Bug fortran/99816] " rguenth at gcc dot gnu.org
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).