[Bug debug/111958] New: Line number debugging information indicates wrong file

[Bug debug/111958] New: Line number debugging information indicates wrong file

[shelmer.gcc at gmail dot com]

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

            Bug ID: 111958
           Summary: Line number debugging information indicates wrong file
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: shelmer.gcc at gmail dot com
  Target Milestone: ---

Created attachment 56188
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56188&action=edit
Preprocessed file for getgid.c

The line number debugging information is incorrect for versions 12.2.0 and
13.2.0. Sometimes the wrong file is used in the ".loc" assembler directives
which causes issues with GDB then debugging application.

This does not happen with version 4.8.5 or 4.8.9 (which come with REHL7).

Command line to reproduce:

gcc -v --save-temps -c -g -O2 getgid.c

Output from gcc-13.2.0:

Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-pc-linux-gnu
Configured with:
/export/wildstar1/helmers/toolset_test/TCore_Toolset/src/gcc-13.2.0/configure
--disable-maintainer-mode --disable-multilib
--prefix=/export/wildstar1/helmers/toolset_test/TCore_Toolset
--datarootdir=/export/wildstar1/helmers/toolset_test/TCore_Toolset
--disable-bootstrap
--with-gmp=/export/wildstar1/helmers/toolset_test/TCore_Toolset
--with-mpfr=/export/wildstar1/helmers/toolset_test/TCore_Toolset
--with-mpc=/export/wildstar1/helmers/toolset_test/TCore_Toolset
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-g' '-O2' '-mtune=generic'
'-march=x86-64'

/export/wildstar1/helmers/toolset_test/TCore_Toolset/libexec/gcc/x86_64-pc-linux-gnu/13.2.0/cc1
-E -quiet -v getgid.c -mtune=generic -march=x86-64 -g -fworking-directory -O2
-fpch-preprocess -o getgid.i
ignoring nonexistent directory
"/export/wildstar1/helmers/toolset_test/TCore_Toolset/lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/export/wildstar1/helmers/toolset_test/TCore_Toolset/lib/gcc/x86_64-pc-linux-gnu/13.2.0/include
 /usr/local/include
 /export/wildstar1/helmers/toolset_test/TCore_Toolset/include

/export/wildstar1/helmers/toolset_test/TCore_Toolset/lib/gcc/x86_64-pc-linux-gnu/13.2.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-g' '-O2' '-mtune=generic'
'-march=x86-64'

/export/wildstar1/helmers/toolset_test/TCore_Toolset/libexec/gcc/x86_64-pc-linux-gnu/13.2.0/cc1
-fpreprocessed getgid.i -quiet -dumpbase getgid.c -dumpbase-ext .c
-mtune=generic -march=x86-64 -g -O2 -version -o getgid.s
GNU C17 (GCC) version 13.2.0 (x86_64-pc-linux-gnu)
        compiled by GNU C version 4.8.5 20150623 (Red Hat 4.8.5-44), GMP
version 6.3.0, MPFR version 4.2.1, MPC version 1.3.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 39ec987cd36af7de9356af0202288cf7
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-g' '-O2' '-mtune=generic'
'-march=x86-64'

/export/wildstar1/helmers/toolset_test/TCore_Toolset/lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../x86_64-pc-linux-gnu/bin/as
-v --gdwarf-5 --64 -o getgid.o getgid.s
GNU assembler version 2.41 (x86_64-pc-linux-gnu) using BFD version (GNU
Binutils) 2.41
COMPILER_PATH=/export/wildstar1/helmers/toolset_test/TCore_Toolset/libexec/gcc/x86_64-pc-linux-gnu/13.2.0/:/export/wildstar1/helmers/toolset_test/TCore_Toolset/libexec/gcc/x86_64-pc-linux-gnu/13.2.0/:/export/wildstar1/helmers/toolset_test/TCore_Toolset/libexec/gcc/x86_64-pc-linux-gnu/:/export/wildstar1/helmers/toolset_test/TCore_Toolset/lib/gcc/x86_64-pc-linux-gnu/13.2.0/:/export/wildstar1/helmers/toolset_test/TCore_Toolset/lib/gcc/x86_64-pc-linux-gnu/:/export/wildstar1/helmers/toolset_test/TCore_Toolset/lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../x86_64-pc-linux-gnu/bin/
LIBRARY_PATH=/export/wildstar1/helmers/toolset_test/TCore_Toolset/lib/gcc/x86_64-pc-linux-gnu/13.2.0/:/export/wildstar1/helmers/toolset_test/TCore_Toolset/lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/export/wildstar1/helmers/toolset_test/TCore_Toolset/lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../x86_64-pc-linux-gnu/lib/:/export/wildstar1/helmers/toolset_test/TCore_Toolset/lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-g' '-O2' '-mtune=generic'
'-march=x86-64'




If you look at the assembly file generated by versions 4.8.5 and 13.2.0 you can
clearly see that some of the ".loc" directives from version 13.2.0 show that a
couple of the functions are located in unistd.h. When using version 4.8.5 all
".loc" directives indicate that all functions are located in getgid.c (as
expected).

[Bug debug/111958] [12/13/14 Regression] Line number debugging information indicates wrong file

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-10-24
      Known to fail|                            |12.1.0
      Known to work|                            |11.1.0, 5.1.0, 8.1.0
            Summary|Line number debugging       |[12/13/14 Regression] Line
                   |information indicates wrong |number debugging
                   |file                        |information indicates wrong
                   |                            |file
   Target Milestone|---                         |12.4
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
           Keywords|                            |needs-bisection,
                   |                            |wrong-debug

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(insn 10 6 11 2 (set (reg/i:SI 0 ax)
        (reg:SI 98 [ <retval> ])) "/usr/include/unistd.h":706:16 -1
     (nil))
(insn 11 10 0 2 (use (reg/i:SI 0 ax)) "/usr/include/unistd.h":706:16 -1
     (nil))


Confirmed.

[Bug debug/111958] [11/12/13/14 Regression] Line number debugging information indicates wrong file

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|11.1.0, 5.1.0, 8.1.0        |6.1.0
      Known to fail|                            |7.1.0

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
6.x (and before) have the correct line info:

(insn 10 6 11 2 (set (reg/i:SI 0 ax)
        (reg:SI 87 [ <retval> ])) getgid.c:32 -1
     (nil))
(insn 11 10 0 2 (use (reg/i:SI 0 ax)) getgid.c:32 -1
     (nil))

[Bug ipa/111958] [11/12/13/14 Regression] Line number debugging information indicates wrong file

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |needs-reduction
          Component|debug                       |ipa
           Priority|P3                          |P2
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |marxin at gcc dot gnu.org

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
The issue goes away when using -fno-ipa-icf - we have

# 2 "/usr/include/sys/unistd.h" 2 3 4
# 9 "getgid.c" 2
# 14 "getgid.c"
gid_t _POSIX_types_Gid = 0;
gid_t
getgid (void)
{
  return _POSIX_types_Gid;
}

gid_t
getegid (void)
{
  return _POSIX_types_Gid;
}

which we first ICF and then inline back.  So it looks like when "materializing"
the alias clone for getegid we get a wrong location (or the location for the
alias clone is broken / not initialized?)

Honza?

[Bug ipa/111958] [11/12/13/14 Regression] Line number debugging information indicates wrong file

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #3)
> which we first ICF and then inline back.  So it looks like when
> "materializing"
> the alias clone for getegid we get a wrong location (or the location for the
> alias clone is broken / not initialized?)

I think we don't set it at all (i.e. keep it UNKNOWN_LOCATION), after all, it
doesn't correspond to any particular source line in the function, e.g. even
just trying to use a location of a particular return stmt is wrong, the
function could have multiple returns.
So it is even in -fdump-{tree,ipa}-all-lineno dumps
  retval.5_4 = setgid (gid_2(D)); [tail call]
  return retval.5_4;
The unistd.h locus appears during expansion, seems to match the
DECL_SOURCE_LOCATION of the first declaration of the function or something like
that.
ICF is simply very much harmful to all the locations in the function, if it is
not inlined back, we have have the elsewhere tracked problem that the merged
function can have solely locations/scopes etc. of one of the functions and not
the others,
if it is inlined back, the debug info will pretend that another function has
been inlined into the current one even when that is not true.
The latter perhaps could be improved by somehow just noting to turn a function
into the thunk at the end of IPA passes and if we'd in between decide to inline
itself back into the function, somehow arrange to use the original body rather
than the thunk with the other function inlined into it.  Similarly for
fnsplit...