[Bug testsuite/100467] New: [12 regression] g++.dg/debug/dwarf2/thunk1.C

[Bug testsuite/100467] New: [12 regression] g++.dg/debug/dwarf2/thunk1.C

[ro at gcc dot gnu.org]

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

            Bug ID: 100467
           Summary: [12 regression] g++.dg/debug/dwarf2/thunk1.C
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: testsuite
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ro at gcc dot gnu.org
                CC: edlinger at gcc dot gnu.org
  Target Milestone: ---
            Target: i?86-*-*, x86_64-*-*

Between 20210505 (b927ffdd6cecd0eeda6ef77df2623519870b1e75) and 20210506
(07dd185755a791ab19e6a63274cf2cb69f087a6c),
the g++.dg/debug/dwarf2/thunk1.C test regressed:

+FAIL: g++.dg/debug/dwarf2/thunk1.C  -std=gnu++14  scan-assembler-times LFB3 5
+FAIL: g++.dg/debug/dwarf2/thunk1.C  -std=gnu++17  scan-assembler-times LFB3 5
+FAIL: g++.dg/debug/dwarf2/thunk1.C  -std=gnu++2a  scan-assembler-times LFB3 5
+FAIL: g++.dg/debug/dwarf2/thunk1.C  -std=gnu++98  scan-assembler-times LFB3 5

I'm seeing this on 32-bit Solaris/x86, but there are also reports for
Linux/x86.

This is most likely due to

commit e69ac0203725fb8da83a1cc88d32191b7a0b2c0c
Author: Bernd Edlinger <bernd.edlinger@hotmail.de>
Date:   Tue Jan 12 16:27:53 2021 +0100

    Add line debug info for virtual thunks

the number of LFB3 instances increased from the expected 5 to 8.

[Bug testsuite/100467] [12 regression] g++.dg/debug/dwarf2/thunk1.C

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0

[Bug testsuite/100467] [12 regression] g++.dg/debug/dwarf2/thunk1.C

[edlinger at gcc dot gnu.org]

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

Bernd Edlinger <edlinger at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-05-07

--- Comment #1 from Bernd Edlinger <edlinger at gcc dot gnu.org> ---
confirmed, I did not try to test with --target_board=unix/-m32
and the test case is unsupported on x86_64.

I'm not sure what to here,
the test case says
// Test that we don't add the x86 PC thunk to .debug_ranges

but my patch does emit a line number (if there is any) for thunks,
and of course include them in debug_ranges and debug_aranges,
so it is not possible to debug those functions where it was
previously not possible.

intersting that the LFB3 increase from 5 to 9 when I tried this:

diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C
b/gcc/testsuite/g++.dg/d
index 304cf45..3d5f301 100644
--- a/gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C
+++ b/gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C
@@ -1,9 +1,9 @@
-// Test that we don't add the x86 PC thunk to .debug_ranges
+// Test that we do add the x86 PC thunk to .debug_ranges
 // { dg-do compile { target { { i?86-*-* x86_64-*-* } && ia32 } } }
 // { dg-require-effective-target fpic }
 // { dg-skip-if "darwin doesn't use the thunk for PIC" { *-*-darwin* } }
 // { dg-options "-g -fpic -fno-dwarf2-cfi-asm" }
-// { dg-final { scan-assembler-times "LFB3" 5 } }
+// { dg-final { scan-assembler-times "LFB3" 9 } }

 template <class T> void f(T t) { }

[Bug testsuite/100467] [12 regression] g++.dg/debug/dwarf2/thunk1.C

[edlinger at gcc dot gnu.org]

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

--- Comment #2 from Bernd Edlinger <edlinger at gcc dot gnu.org> ---
> so it is not possible to debug those functions

Aehm, i meant of course it is _now_ possible

[Bug testsuite/100467] [12 regression] g++.dg/debug/dwarf2/thunk1.C

[edlinger at gcc dot gnu.org]

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

--- Comment #3 from Bernd Edlinger <edlinger at gcc dot gnu.org> ---
Okay, after some debugging I see the problem.

Usually thunks are emitted from ymtab-thunks.cc:

      cfun->is_thunk = 1;
      insn_locations_init ();
      set_curr_insn_location (DECL_SOURCE_LOCATION (thunk_fndecl));
      prologue_location = curr_insn_location ();

      targetm.asm_out.output_mi_thunk (asm_out_file, thunk_fndecl,
                                       fixed_offset, virtual_value, alias);


the only other place where prologue_location is set
is in cfgexpand.c:

  if (!DECL_IS_UNDECLARED_BUILTIN (current_function_decl))
    {
      /* Eventually, all FEs should explicitly set function_start_locus.  */
      if (LOCATION_LOCUS (fun->function_start_locus) == UNKNOWN_LOCATION)
        set_curr_insn_location
          (DECL_SOURCE_LOCATION (current_function_decl));
      else
        set_curr_insn_location (fun->function_start_locus);
    }
  else
    set_curr_insn_location (UNKNOWN_LOCATION);
  prologue_location = curr_insn_location ();


BUT this special "thunk" is emitted from toplev.c:

      /* This must be at the end before unwind and debug info.
         Some target ports emit PIC setup thunks here.  */
      targetm.asm_out.code_end ();

and here the prologue_location is not initialized, also the backend
does not know about it's significance.

So the source line number for this thunk is indeed wrong.

[Bug middle-end/100467] [12 regression] g++.dg/debug/dwarf2/thunk1.C

[edlinger at gcc dot gnu.org]

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

--- Comment #4 from Bernd Edlinger <edlinger at gcc dot gnu.org> ---
Created attachment 50778
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50778&action=edit
Proposed patch

[Bug middle-end/100467] [12 regression] g++.dg/debug/dwarf2/thunk1.C

[edlinger at gcc dot gnu.org]

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

--- Comment #5 from Bernd Edlinger <edlinger at gcc dot gnu.org> ---
Rainer,

I would be happy if you could give this patch a try.

Thanks
Bernd.

[Bug middle-end/100467] [12 regression] g++.dg/debug/dwarf2/thunk1.C

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Bernd Edlinger <edlinger@gcc.gnu.org>:

https://gcc.gnu.org/g:6c9071c089c31eddc4ac80e0488bb9d37f9e11f1

commit r12-640-g6c9071c089c31eddc4ac80e0488bb9d37f9e11f1
Author: Bernd Edlinger <bernd.edlinger@hotmail.de>
Date:   Sat May 8 07:46:17 2021 +0200

    Reset prologue_location before calling code_end

    Some targets emit thunks from the targetm.asm_out.code_end
    function and set the DECL_IGNORED_P, but due to
    e69ac020372 ("Add line debug info for virtual thunks")
    the value in prologue_location is no longer ignored.

    So reset that value before calling the backend.

    2021-05-10  Bernd Edlinger  <bernd.edlinger@hotmail.de>

            PR middle-end/100467
            * toplev.c (compile_file): Call insn_locations_init before
            targetm.asm_out.code_end.

[Bug middle-end/100467] [12 regression] g++.dg/debug/dwarf2/thunk1.C

[edlinger at gcc dot gnu.org]

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

Bernd Edlinger <edlinger at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #7 from Bernd Edlinger <edlinger at gcc dot gnu.org> ---
should be fixed now.
Thanks for reporting.

[Bug middle-end/100467] [12 regression] g++.dg/debug/dwarf2/thunk1.C

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #7 from Bernd Edlinger <edlinger at gcc dot gnu.org> ---
> should be fixed now.

It is: tested on i386-pc-solaris2.11 (and, for good measure, on
sparc-sun-solaris2.11).

Thanks for the quick fix.