[Bug fortran/105037] New: gfortran emits incorrect debug information if compiled with -finit-real=snan

[Bug fortran/105037] New: gfortran emits incorrect debug information if compiled with -finit-real=snan

[christian.friedl at gmx dot at]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105037

            Bug ID: 105037
           Summary: gfortran emits incorrect debug information if compiled
                    with -finit-real=snan
           Product: gcc
           Version: 10.3.0
            Status: UNCONFIRMED
          Keywords: wrong-debug
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: christian.friedl at gmx dot at
  Target Milestone: ---

I have the following small example, let's call it example.F

      SUBROUTINE TEST(N1,N2,O2)
      IMPLICIT DOUBLE PRECISION (A-H,O-Z)
      COMMON /ABC/  EMP2,ITRLE,ITER,IREST
      DIMENSION O2(1)
      IF(IREST.EQ.0) THEN
      CALL WO2(1,N1,N2,O2)
      ENRGOLD=EMP2
      ITER=0
      END IF
      ITRLE=0
      RETURN
      END

I compile this and dissassemble it afterwards

gfortran -c -ggdb -O0 example.F
objdump -S example.o

This is how the disassembly looks

...
0000000000000000 <test_>:
      SUBROUTINE TEST(N1,N2,O2)
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   48 83 ec 30             sub    $0x30,%rsp
   8:   48 89 7d e8             mov    %rdi,-0x18(%rbp)
   c:   48 89 75 e0             mov    %rsi,-0x20(%rbp)
  10:   48 89 55 d8             mov    %rdx,-0x28(%rbp)
  14:   8b 05 00 00 00 00       mov    0x0(%rip),%eax        # 1a <test_+0x1a>
      IMPLICIT DOUBLE PRECISION (A-H,O-Z)
      COMMON /ABC/  EMP2,ITRLE,ITER,IREST
      DIMENSION O2(1)
      IF(IREST.EQ.0) THEN
  1a:   85 c0                   test   %eax,%eax
  1c:   75 32                   jne    50 <test_+0x50>
...

I can also compile with -finit-real=snan

gfortran -c -ggdb -O0 -finit-real=snan example.F
objdump -S example.o

In this case the disassembly looks like this

...
0000000000000000 <test_>:
      SUBROUTINE TEST(N1,N2,O2)
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   48 83 ec 30             sub    $0x30,%rsp
   8:   48 89 7d e8             mov    %rdi,-0x18(%rbp)
   c:   48 89 75 e0             mov    %rsi,-0x20(%rbp)
  10:   48 89 55 d8             mov    %rdx,-0x28(%rbp)
      IMPLICIT DOUBLE PRECISION (A-H,O-Z)
      COMMON /ABC/  EMP2,ITRLE,ITER,IREST
      DIMENSION O2(1)
      IF(IREST.EQ.0) THEN
      CALL WO2(1,N1,N2,O2)
      ENRGOLD=EMP2
  14:   f2 0f 10 05 00 00 00    movsd  0x0(%rip),%xmm0        # 1c <test_+0x1c>
  1b:   00
  1c:   f2 0f 11 45 f8          movsd  %xmm0,-0x8(%rbp)
      SUBROUTINE TEST(N1,N2,O2)
  21:   8b 05 00 00 00 00       mov    0x0(%rip),%eax        # 27 <test_+0x27>
      IF(IREST.EQ.0) THEN
  27:   85 c0                   test   %eax,%eax
  29:   75 32                   jne    5d <test_+0x5d>
...

I have extracted this small testcase from a much bigger subroutine. When
debugging a floating-point exception in the original subroutine the gdb
debugger would be upset and yield

/build/gdb-ktlO15/gdb-9.2/gdb/utils.c:690: internal-error: virtual memory
exhausted.

I am working on Ubuntu 20.04 LTS with gfortran version 4:9.3.0-1ubuntu2 on
amd64.

[Bug fortran/105037] gfortran emits incorrect debug information if compiled with -finit-real=snan

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105037

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
What do you think is wrong?  Have you raised the gdb issue with the gdb folks?

[Bug fortran/105037] gfortran emits incorrect debug information if compiled with -finit-real=snan

[christian.friedl at gmx dot at]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105037

--- Comment #2 from Christian Friedl <christian.friedl at gmx dot at> ---
> What do you think is wrong?

The lines

      IF(IREST.EQ.0) THEN
      CALL WO2(1,N1,N2,O2)
      ENRGOLD=EMP2

get emitted twice when -finit-real=snan is used. The first time that they are
emitted, they don't fit the assembly that they refer to.

> Have you raised the gdb issue with the gdb folks?

No. I wasn't really able to provide a minimal example for the error. Using
objdump, I saw that the cause probably was the debug information and not gdb
itself.