public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug debug/97060] New: Missing DW_AT_declaration=1 in dwarf data
@ 2020-09-15 22:16 jolsa at redhat dot com
  2020-09-16  6:16 ` [Bug debug/97060] " rguenth at gcc dot gnu.org
                   ` (17 more replies)
  0 siblings, 18 replies; 19+ messages in thread
From: jolsa at redhat dot com @ 2020-09-15 22:16 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 97060
           Summary: Missing DW_AT_declaration=1 in dwarf data
           Product: gcc
           Version: 10.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jolsa at redhat dot com
  Target Milestone: ---

We are missing expected declaration tag - DW_AT_declaration : 1 for function
in debug info data.

The problem we see is:

 - fs/init.c calls vfs_getattr function
 - vfs_getattr is defined outside the fs/init.c
 - once compiled, debug info data for vfs_getattr should contain declaration
   tag - DW_AT_declaration : 1, but it's missing

gcc version: gcc (GCC) 10.2.1 20200826 (Red Hat 10.2.1-3)

Unfortunately the issue can be so far reproduced only inside container,
I tried to narrow it down to single fs/init.o object.

Following steps create fs/init.o binary in kernel tree within the container:

# podman image pull
registry.gitlab.com/cki-project/containers/builder-rawhide:latest
# podman image list
# podman run -it <ID> /bin/bash
# git clone https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
--depth 1
# curl
https://xci32.lab.eng.rdu2.redhat.com/cki-project/cki-pipeline/-/jobs/974002/artifacts/raw/artifacts/kernel-bpf-next-x86_64-cd04b04de119a222c83936f7e9dbd46a650cb688.config
-o bpf-next/.config
# cd bpf-next/

# make oldconfig # might need some ENTERs
# make fs/ -j

# gcc -Wp,-MMD,fs/.init.o.d -nostdinc -isystem
/usr/lib/gcc/x86_64-redhat-linux/10/include -I./arch/x86/include
-I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi
-I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi
-include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h
-D__KERNEL__ -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE
-Werror=implicit-function-declaration -Werror=implicit-int -Wno-format-security
-std=gnu89 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1
-falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3
-mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -Wno-sign-compare
-fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern
-mindirect-branch-register -fno-jump-tables -fno-delete-null-pointer-checks
-Wno-frame-address -Wno-format-truncation -Wno-format-overflow
-Wno-address-of-packed-member -O2 -fno-allow-store-data-races
-Wframe-larger-than=2048 -fstack-protector -Wno-unused-but-set-variable
-Wimplicit-fallthrough -Wno-unused-const-variable -fno-var-tracking-assignments
-g -pg -mrecord-mcount -mfentry -DCC_USING_FENTRY -flive-patching=inline-clone
-Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-stringop-truncation
-Wno-zero-length-bounds -Wno-array-bounds -Wno-stringop-overflow -Wno-restrict
-Wno-maybe-uninitialized -fno-strict-overflow -fno-merge-all-constants
-fmerge-constants -fno-stack-check -fconserve-stack -Werror=date-time
-Werror=incompatible-pointer-types -Werror=designated-init
-fmacro-prefix-map=./= -fcf-protection=none -Wno-packed-not-aligned   
-DKBUILD_MODFILE='"fs/init"' -DKBUILD_BASENAME='"init"'
-DKBUILD_MODNAME='"init"' -c -o fs/init.o fs/init.c

# readelf --debug fs/init.o
...
 <1><9145>: Abbrev Number: 46 (DW_TAG_subprogram)
    <9146>   DW_AT_external    : 1
    <9146>   DW_AT_name        : (indirect string, offset: 0x531c): vfs_getattr
    <914a>   DW_AT_decl_file   : 7
    <914b>   DW_AT_decl_line   : 3148
    <914d>   DW_AT_decl_column : 12
    <914e>   DW_AT_prototyped  : 1
    <914e>   DW_AT_type        : <0xa9>
    <9152>   DW_AT_sibling     : <0x916b>
 <2><9156>: Abbrev Number: 3 (DW_TAG_formal_parameter)
    <9157>   DW_AT_type        : <0x3573>
 <2><915b>: Abbrev Number: 3 (DW_TAG_formal_parameter)
    <915c>   DW_AT_type        : <0x893a>
 <2><9160>: Abbrev Number: 3 (DW_TAG_formal_parameter)
    <9161>   DW_AT_type        : <0x111>
 <2><9165>: Abbrev Number: 3 (DW_TAG_formal_parameter)
    <9166>   DW_AT_type        : <0x4c>


When we link the final kernel binary the debug info data contains multiple
records for vfs_getattr,
and neither has 'declaration' tag and it confuses pahole tool that uses this
data to get function
records and skips declarations.

The problem is for more functions, vfs_getattr is just one example.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
  2020-09-15 22:16 [Bug debug/97060] New: Missing DW_AT_declaration=1 in dwarf data jolsa at redhat dot com
@ 2020-09-16  6:16 ` rguenth at gcc dot gnu.org
  2020-09-16  8:16 ` jolsa at redhat dot com
                   ` (16 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-09-16  6:16 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-09-16
     Ever confirmed|0                           |1
                 CC|                            |jsm28 at gcc dot gnu.org
             Status|UNCONFIRMED                 |WAITING

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I guess that vfs_getattr is declared 'extern inline'.  At least with

extern inline int foo (int i) { return i; }

int main()
{
  foo (5);
}

I can reproduce this kind of DIE:

 <1><52>: Abbrev Number: 4 (DW_TAG_subprogram)
    <53>   DW_AT_external    : 1
    <53>   DW_AT_name        : foo
    <57>   DW_AT_decl_file   : 1
    <58>   DW_AT_decl_line   : 1
    <59>   DW_AT_decl_column : 19
    <5a>   DW_AT_prototyped  : 1
    <5a>   DW_AT_type        : <0x4b>
    <5e>   DW_AT_low_pc      : 0x0
    <66>   DW_AT_high_pc     : 0xc
    <6e>   DW_AT_frame_base  : 1 byte block: 9c         (DW_OP_call_frame_cfa)
    <70>   DW_AT_GNU_all_call_sites: 1

these "extern" inline functions are not really external, but I'm not sure
of a better representation of GNU extern inline functions.

Can you please provide preprocessed source of the fs/init.o TU?

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
  2020-09-15 22:16 [Bug debug/97060] New: Missing DW_AT_declaration=1 in dwarf data jolsa at redhat dot com
  2020-09-16  6:16 ` [Bug debug/97060] " rguenth at gcc dot gnu.org
@ 2020-09-16  8:16 ` jolsa at redhat dot com
  2020-09-16  8:41 ` jakub at gcc dot gnu.org
                   ` (15 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: jolsa at redhat dot com @ 2020-09-16  8:16 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from Jiri Olsa <jolsa at redhat dot com> ---
Created attachment 49223
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49223&action=edit
fs/init.i

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
  2020-09-15 22:16 [Bug debug/97060] New: Missing DW_AT_declaration=1 in dwarf data jolsa at redhat dot com
  2020-09-16  6:16 ` [Bug debug/97060] " rguenth at gcc dot gnu.org
  2020-09-16  8:16 ` jolsa at redhat dot com
@ 2020-09-16  8:41 ` jakub at gcc dot gnu.org
  2020-09-16  8:55 ` jolsa at redhat dot com
                   ` (14 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-09-16  8:41 UTC (permalink / raw)
  To: gcc-bugs

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

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

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So this is really just something like: -O2 -g -dA:
extern int foo (unsigned int, unsigned int);

int
bar (void)
{
  foo (1, 2);
  return 0;
}

where we don't emit DW_AT_declaration neither for the external declaration of
foo, nor for the definition of bar.  Other compilers don't emit them either.

Anyway, older gcc versions used to emit those and this changed with
PR96383 r11-2455-gc6ef9d8d3f11221df1ea6358b8d4e79e42f074fb

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
  2020-09-15 22:16 [Bug debug/97060] New: Missing DW_AT_declaration=1 in dwarf data jolsa at redhat dot com
                   ` (2 preceding siblings ...)
  2020-09-16  8:41 ` jakub at gcc dot gnu.org
@ 2020-09-16  8:55 ` jolsa at redhat dot com
  2020-09-16  8:55 ` jakub at gcc dot gnu.org
                   ` (13 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: jolsa at redhat dot com @ 2020-09-16  8:55 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from Jiri Olsa <jolsa at redhat dot com> ---
(In reply to Jakub Jelinek from comment #3)
> So this is really just something like: -O2 -g -dA:
> extern int foo (unsigned int, unsigned int);
> 
> int
> bar (void)
> {
>   foo (1, 2);
>   return 0;
> }
> 
> where we don't emit DW_AT_declaration neither for the external declaration
> of foo, nor for the definition of bar.  Other compilers don't emit them
> either.
> 
> Anyway, older gcc versions used to emit those and this changed with
> PR96383 r11-2455-gc6ef9d8d3f11221df1ea6358b8d4e79e42f074fb

is there a way we can tell which record is for declaration/definition?

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
  2020-09-15 22:16 [Bug debug/97060] New: Missing DW_AT_declaration=1 in dwarf data jolsa at redhat dot com
                   ` (3 preceding siblings ...)
  2020-09-16  8:55 ` jolsa at redhat dot com
@ 2020-09-16  8:55 ` jakub at gcc dot gnu.org
  2020-09-16  9:00 ` jakub at gcc dot gnu.org
                   ` (12 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-09-16  8:55 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So perhaps completely untested:
--- gcc/dwarf2out.c.jj  2020-09-07 13:17:58.383594248 +0200
+++ gcc/dwarf2out.c     2020-09-16 10:53:44.353632197 +0200
@@ -26547,7 +26547,8 @@ dwarf2out_early_global_decl (tree decl)
              && ((origin_die = lookup_decl_die (origin)) == NULL
                  || is_declaration_die (origin_die)))
            {
-             current_function_decl = origin;
+             current_function_decl
+               = DECL_EXTERNAL (origin) ? NULL_TREE : origin;
              dwarf2out_decl (origin);
            }

@@ -26556,7 +26557,7 @@ dwarf2out_early_global_decl (tree decl)
          if ((old_die = lookup_decl_die (decl)) == NULL
              || is_declaration_die (old_die))
            {
-             current_function_decl = decl;
+             current_function_decl = DECL_EXTERNAL (decl) ? NULL_TREE : decl;
              dwarf2out_decl (decl);
            }

?

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
  2020-09-15 22:16 [Bug debug/97060] New: Missing DW_AT_declaration=1 in dwarf data jolsa at redhat dot com
                   ` (4 preceding siblings ...)
  2020-09-16  8:55 ` jakub at gcc dot gnu.org
@ 2020-09-16  9:00 ` jakub at gcc dot gnu.org
  2020-09-16  9:19 ` jakub at gcc dot gnu.org
                   ` (11 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-09-16  9:00 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|10.2.1                      |11.0

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Also, to avoid confusion, upstream 10 branch is not affected, but in 10-RH
we've backported the PR96383 changes from the trunk.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
  2020-09-15 22:16 [Bug debug/97060] New: Missing DW_AT_declaration=1 in dwarf data jolsa at redhat dot com
                   ` (5 preceding siblings ...)
  2020-09-16  9:00 ` jakub at gcc dot gnu.org
@ 2020-09-16  9:19 ` jakub at gcc dot gnu.org
  2020-09-16 11:42 ` jakub at gcc dot gnu.org
                   ` (10 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-09-16  9:19 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 49224
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49224&action=edit
gcc11-pr97060.patch

Actually, the DECL_EXTERNAL tests aren't probably a good idea because of the
GNU extern inlines.  This patch attempts to match the previous behavior where
early_debug_decl was called only on FUNCTION_DECLs with gimple bodies, so the
patch for those keeps setting current_function_decl to non-NULL and sets it to
NULL only for the FUNCTION_DECLs for which it wouldn't be called previously and
only the PR96383 changed that.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
  2020-09-15 22:16 [Bug debug/97060] New: Missing DW_AT_declaration=1 in dwarf data jolsa at redhat dot com
                   ` (6 preceding siblings ...)
  2020-09-16  9:19 ` jakub at gcc dot gnu.org
@ 2020-09-16 11:42 ` jakub at gcc dot gnu.org
  2020-09-17 11:47 ` jolsa at redhat dot com
                   ` (9 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-09-16 11:42 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Unfortunately the patch doesn't really bootstrap.
Small testcase that ICEs:
struct S { virtual ~S (); } s;
This is on the external S::~S() declaration, which has non-NULL
decl_ultimate_origin (the abstract destructor from which the concrete ones are
inherited), but with the above patch we want to emit it as declaration and run
into:
  /* A concrete instance, tag a new DIE with DW_AT_abstract_origin.  */
  if (origin != NULL)
    {
      gcc_assert (!declaration || local_scope_p (context_die));
So, one way around would be to only clear current_function_decl for functions
with decl_ultimate_origin (decl) == NULL.
But then we wouldn't emit DW_AT_declaration in this case (ok, one needs
-fno-eliminate-unused-debug-symbols to actually see it in the assembly).
On the other side, having a DW_TAG_subprogram with both DW_AT_specification and
DW_AT_declaration looks invalid to me.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
  2020-09-15 22:16 [Bug debug/97060] New: Missing DW_AT_declaration=1 in dwarf data jolsa at redhat dot com
                   ` (7 preceding siblings ...)
  2020-09-16 11:42 ` jakub at gcc dot gnu.org
@ 2020-09-17 11:47 ` jolsa at redhat dot com
  2020-09-17 12:23 ` jakub at gcc dot gnu.org
                   ` (8 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: jolsa at redhat dot com @ 2020-09-17 11:47 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #9 from Jiri Olsa <jolsa at redhat dot com> ---
(In reply to Jakub Jelinek from comment #6)
> Also, to avoid confusion, upstream 10 branch is not affected, but in 10-RH
> we've backported the PR96383 changes from the trunk.

Is this gcc going to RHEL8? that could be a problem for us.

Also, is there a way how we can workaround this?

How to recgnize function declaration apart from
definition in dwarf data?

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
  2020-09-15 22:16 [Bug debug/97060] New: Missing DW_AT_declaration=1 in dwarf data jolsa at redhat dot com
                   ` (8 preceding siblings ...)
  2020-09-17 11:47 ` jolsa at redhat dot com
@ 2020-09-17 12:23 ` jakub at gcc dot gnu.org
  2020-09-17 12:39 ` jolsa at redhat dot com
                   ` (7 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-09-17 12:23 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
RHEL8 uses gcc 8 which is not affected (unless one uses DTS/GTS).
Also, it is unclear for what in particular pahole or what wants to use
DW_AT_declaration.
DW_TAG_subprogram of a real definition (that hasn't been optimized out) is the
one that has DW_AT_low_pc/DW_AT_high_pc or DW_AT_ranges attributes (i.e. has
any associated code).  Some functions can have many definitions (e.g. inline
functions or other comdat entities).

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
  2020-09-15 22:16 [Bug debug/97060] New: Missing DW_AT_declaration=1 in dwarf data jolsa at redhat dot com
                   ` (9 preceding siblings ...)
  2020-09-17 12:23 ` jakub at gcc dot gnu.org
@ 2020-09-17 12:39 ` jolsa at redhat dot com
  2020-09-17 13:49 ` jakub at gcc dot gnu.org
                   ` (6 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: jolsa at redhat dot com @ 2020-09-17 12:39 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #11 from Jiri Olsa <jolsa at redhat dot com> ---
(In reply to Jakub Jelinek from comment #10)
> RHEL8 uses gcc 8 which is not affected (unless one uses DTS/GTS).
> Also, it is unclear for what in particular pahole or what wants to use
> DW_AT_declaration.

pahole takes dwarf data and produces BTF type data
that includes functions

the DW_AT_declaration flag was used to skip function
declarations so only one function record was processed
and added to BTF data

without that flag pahole will add one function multiple
times to BTF data, based on how many times it was declared
in other objects

> DW_TAG_subprogram of a real definition (that hasn't been optimized out) is
> the one that has DW_AT_low_pc/DW_AT_high_pc or DW_AT_ranges attributes (i.e.
> has any associated code).  Some functions can have many definitions (e.g.
> inline functions or other comdat entities).

I'll check if we can add more check to pahole for this

thanks

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
  2020-09-15 22:16 [Bug debug/97060] New: Missing DW_AT_declaration=1 in dwarf data jolsa at redhat dot com
                   ` (10 preceding siblings ...)
  2020-09-17 12:39 ` jolsa at redhat dot com
@ 2020-09-17 13:49 ` jakub at gcc dot gnu.org
  2020-10-14 20:22 ` jolsa at redhat dot com
                   ` (5 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-09-17 13:49 UTC (permalink / raw)
  To: gcc-bugs

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

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

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, I've tried to bootstrap/regtest an adjusted patch:
2020-09-16  Jakub Jelinek  <jakub@redhat.com>

        PR debug/97060
        * dwarf2out.c (dwarf2out_early_global_decl): For FUNCTION_DECLs
        and their abstract origins, if they don't have gimple body,
        set current_function_decl to NULL rather than the decl or origin.

        * gcc.dg/debug/dwarf2/pr97060.c: New test.

--- gcc/dwarf2out.c.jj  2020-09-07 13:17:58.383594248 +0200
+++ gcc/dwarf2out.c     2020-09-16 11:14:57.763550862 +0200
@@ -26547,7 +26547,12 @@ dwarf2out_early_global_decl (tree decl)
              && ((origin_die = lookup_decl_die (origin)) == NULL
                  || is_declaration_die (origin_die)))
            {
-             current_function_decl = origin;
+             cgraph_node *cnode = cgraph_node::get (origin);
+             if ((cnode && cnode->has_gimple_body_p ())
+                 || decl_ultimate_origin (origin))
+               current_function_decl = origin;
+             else
+               current_function_decl = NULL_TREE;
              dwarf2out_decl (origin);
            }

@@ -26556,7 +26561,12 @@ dwarf2out_early_global_decl (tree decl)
          if ((old_die = lookup_decl_die (decl)) == NULL
              || is_declaration_die (old_die))
            {
-             current_function_decl = decl;
+             cgraph_node *cnode = cgraph_node::get (decl);
+             if ((cnode && cnode->has_gimple_body_p ())
+                 || decl_ultimate_origin (decl))
+               current_function_decl = decl;
+             else
+               current_function_decl = NULL_TREE;
              dwarf2out_decl (decl);
            }

--- gcc/testsuite/gcc.dg/debug/dwarf2/pr97060.c.jj      2020-09-16
11:03:22.358420449 +0200
+++ gcc/testsuite/gcc.dg/debug/dwarf2/pr97060.c 2020-09-16 11:03:17.717486318
+0200
@@ -0,0 +1,13 @@
+/* PR debug/97060 */
+/* { dg-do compile } */
+/* { dg-options "-g -dA" } */
+/* { dg-final { scan-assembler-times "DW_AT_declaration" 2 } } */
+
+extern int foo (unsigned int, unsigned int);
+
+int
+bar (void)
+{
+  foo (1, 2);
+  return 0;
+}

It passes bootstrap, but causes some regressions:
-FAIL: g++.dg/guality/pr55665.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 23 p == 40
+FAIL: g++.dg/debug/dwarf2/array-3.C  -std=gnu++11  scan-assembler-times 
DW_TAG_const_type 5
+FAIL: g++.dg/debug/dwarf2/array-3.C  -std=gnu++14  scan-assembler-times 
DW_TAG_const_type 5
+FAIL: g++.dg/debug/dwarf2/array-3.C  -std=gnu++17  scan-assembler-times 
DW_TAG_const_type 5
+FAIL: g++.dg/debug/dwarf2/array-3.C  -std=gnu++2a  scan-assembler-times 
DW_TAG_const_type 5
+FAIL: g++.dg/debug/dwarf2/array-3.C  -std=gnu++98  scan-assembler-times 
DW_TAG_const_type 5
+FAIL: g++.dg/debug/dwarf2/array-4.C  -std=gnu++11  scan-assembler-times 
DW_TAG_const_type 4
+FAIL: g++.dg/debug/dwarf2/array-4.C  -std=gnu++14  scan-assembler-times 
DW_TAG_const_type 4
+FAIL: g++.dg/debug/dwarf2/array-4.C  -std=gnu++17  scan-assembler-times 
DW_TAG_const_type 4
+FAIL: g++.dg/debug/dwarf2/array-4.C  -std=gnu++2a  scan-assembler-times 
DW_TAG_const_type 4
+FAIL: g++.dg/debug/dwarf2/array-4.C  -std=gnu++98  scan-assembler-times 
DW_TAG_const_type 4
+FAIL: g++.dg/debug/dwarf2/defaulted-member-function-2.C   scan-assembler-times
0x2[ \\t][^\\n]* DW_AT_defaulted 1
+FAIL: g++.dg/debug/dwarf2/local-var-in-contructor.C  -std=gnu++11 
scan-assembler problem
+FAIL: g++.dg/debug/dwarf2/local-var-in-contructor.C  -std=gnu++14 
scan-assembler problem
+FAIL: g++.dg/debug/dwarf2/local-var-in-contructor.C  -std=gnu++17 
scan-assembler problem
+FAIL: g++.dg/debug/dwarf2/local-var-in-contructor.C  -std=gnu++2a 
scan-assembler problem
+FAIL: g++.dg/debug/dwarf2/local-var-in-contructor.C  -std=gnu++98 
scan-assembler problem
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++11  scan-assembler
"one::c1::c1\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++11  scan-assembler
"one::c1::~c1\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++11  scan-assembler
"two::c2<double>::c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++11  scan-assembler
"two::c2<double>::~c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++11  scan-assembler
"two::c2<int const\\\\*>::c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++11  scan-assembler
"two::c2<int const\\\\*>::~c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++11  scan-assembler
"two::c2<int>::c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++11  scan-assembler
"two::c2<int>::~c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++14  scan-assembler
"one::c1::c1\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++14  scan-assembler
"one::c1::~c1\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++14  scan-assembler
"two::c2<double>::c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++14  scan-assembler
"two::c2<double>::~c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++14  scan-assembler
"two::c2<int const\\\\*>::c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++14  scan-assembler
"two::c2<int const\\\\*>::~c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++14  scan-assembler
"two::c2<int>::c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++14  scan-assembler
"two::c2<int>::~c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++17  scan-assembler
"one::c1::c1\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++17  scan-assembler
"one::c1::~c1\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++17  scan-assembler
"two::c2<double>::c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++17  scan-assembler
"two::c2<double>::~c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++17  scan-assembler
"two::c2<int const\\\\*>::c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++17  scan-assembler
"two::c2<int const\\\\*>::~c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++17  scan-assembler
"two::c2<int>::c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++17  scan-assembler
"two::c2<int>::~c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++2a  scan-assembler
"one::c1::c1\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++2a  scan-assembler
"one::c1::~c1\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++2a  scan-assembler
"two::c2<double>::c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++2a  scan-assembler
"two::c2<double>::~c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++2a  scan-assembler
"two::c2<int const\\\\*>::c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++2a  scan-assembler
"two::c2<int const\\\\*>::~c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++2a  scan-assembler
"two::c2<int>::c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-2.C  -std=gnu++2a  scan-assembler
"two::c2<int>::~c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++11  scan-assembler
"one::c1::c1\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++11  scan-assembler
"one::c1::~c1\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++11  scan-assembler
"two::c2<double>::c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++11  scan-assembler
"two::c2<double>::~c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++11  scan-assembler
"two::c2<int const\\\\*>::c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++11  scan-assembler
"two::c2<int const\\\\*>::~c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++11  scan-assembler
"two::c2<int>::c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++11  scan-assembler
"two::c2<int>::~c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++14  scan-assembler
"one::c1::c1\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++14  scan-assembler
"one::c1::~c1\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++14  scan-assembler
"two::c2<double>::c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++14  scan-assembler
"two::c2<double>::~c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++14  scan-assembler
"two::c2<int const\\\\*>::c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++14  scan-assembler
"two::c2<int const\\\\*>::~c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++14  scan-assembler
"two::c2<int>::c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++14  scan-assembler
"two::c2<int>::~c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++17  scan-assembler
"one::c1::c1\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++17  scan-assembler
"one::c1::~c1\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++17  scan-assembler
"two::c2<double>::c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++17  scan-assembler
"two::c2<double>::~c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++17  scan-assembler
"two::c2<int const\\\\*>::c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++17  scan-assembler
"two::c2<int const\\\\*>::~c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++17  scan-assembler
"two::c2<int>::c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++17  scan-assembler
"two::c2<int>::~c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++2a  scan-assembler
"one::c1::c1\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++2a  scan-assembler
"one::c1::~c1\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++2a  scan-assembler
"two::c2<double>::c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++2a  scan-assembler
"two::c2<double>::~c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++2a  scan-assembler
"two::c2<int const\\\\*>::c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++2a  scan-assembler
"two::c2<int const\\\\*>::~c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++2a  scan-assembler
"two::c2<int>::c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/pubnames-3.C  -std=gnu++2a  scan-assembler
"two::c2<int>::~c2\\\\\\\\0"+[ \\t]+[#;/|@!]+[ \\t]+external name
+FAIL: g++.dg/debug/dwarf2/static-local-var-in-ctor.C  -std=gnu++11 
scan-assembler DW_OP_addr[^\\n\\r]*[\\n\\r]*[^\\n\\r]*staticvar1
+FAIL: g++.dg/debug/dwarf2/static-local-var-in-ctor.C  -std=gnu++14 
scan-assembler DW_OP_addr[^\\n\\r]*[\\n\\r]*[^\\n\\r]*staticvar1
+FAIL: g++.dg/debug/dwarf2/static-local-var-in-ctor.C  -std=gnu++17 
scan-assembler DW_OP_addr[^\\n\\r]*[\\n\\r]*[^\\n\\r]*staticvar1
+FAIL: g++.dg/debug/dwarf2/static-local-var-in-ctor.C  -std=gnu++2a 
scan-assembler DW_OP_addr[^\\n\\r]*[\\n\\r]*[^\\n\\r]*staticvar1
+FAIL: g++.dg/debug/dwarf2/static-local-var-in-ctor.C  -std=gnu++98 
scan-assembler DW_OP_addr[^\\n\\r]*[\\n\\r]*[^\\n\\r]*staticvar1
+FAIL: g++.dg/pr78112-2.C   scan-assembler-times DW_AT_object_pointer 12
+FAIL: g++.dg/pr82155.C  -std=gnu++11 (internal compiler error)
+FAIL: g++.dg/pr82155.C  -std=gnu++11 (test for excess errors)
+FAIL: g++.dg/pr82155.C  -std=gnu++14 (internal compiler error)
+FAIL: g++.dg/pr82155.C  -std=gnu++14 (test for excess errors)
+FAIL: g++.dg/pr82155.C  -std=gnu++17 (internal compiler error)
+FAIL: g++.dg/pr82155.C  -std=gnu++17 (test for excess errors)
+FAIL: g++.dg/pr82155.C  -std=gnu++2a (internal compiler error)
+FAIL: g++.dg/pr82155.C  -std=gnu++2a (test for excess errors)

The ICEs are due to dwarf2out_early_finish -> prune_unused_types ->
prune_unused_types_prune -> mark_removed -> mark_removed marking the k method's
DW_TAG_subprogram as removed (surprisingly, for k itself the above patch makes
no difference, it only makes operator-> and some ctor variants
DW_AT_declaration).  Later on during function versioning, IPA calls
dwarf2out_abstract_function on k and that function assumes lookup_decl_die
succeeds, but due to the pruning it does not.
The other changes are not ICEs, I'd say again type prunning results in fewer
attributes being emitted.
But why it hasn't been a problem before the PR96383 changes is a mystery.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
  2020-09-15 22:16 [Bug debug/97060] New: Missing DW_AT_declaration=1 in dwarf data jolsa at redhat dot com
                   ` (11 preceding siblings ...)
  2020-09-17 13:49 ` jakub at gcc dot gnu.org
@ 2020-10-14 20:22 ` jolsa at redhat dot com
  2020-11-12  5:58 ` cvs-commit at gcc dot gnu.org
                   ` (4 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: jolsa at redhat dot com @ 2020-10-14 20:22 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #13 from Jiri Olsa <jolsa at redhat dot com> ---
hi,
any update on the fix? I'm seeing the bug now in fedora 32 with:

  $ gcc --version
  gcc (GCC) 10.2.1 20201005 (Red Hat 10.2.1-5)


thanks,
jirka

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
  2020-09-15 22:16 [Bug debug/97060] New: Missing DW_AT_declaration=1 in dwarf data jolsa at redhat dot com
                   ` (12 preceding siblings ...)
  2020-10-14 20:22 ` jolsa at redhat dot com
@ 2020-11-12  5:58 ` cvs-commit at gcc dot gnu.org
  2020-11-13 18:38 ` jason at gcc dot gnu.org
                   ` (3 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-11-12  5:58 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #14 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jason Merrill <jason@gcc.gnu.org>:

https://gcc.gnu.org/g:87b7d45e358e4df93b6a93b2e7a55b123ea76f5d

commit r11-4933-g87b7d45e358e4df93b6a93b2e7a55b123ea76f5d
Author: Jason Merrill <jason@redhat.com>
Date:   Tue Nov 10 18:02:04 2020 -0500

    dwarf2: Set DW_AT_declaration for undefined fns [PR97060]

    If DECL_INITIAL isn't set, we can't emit anything about the body of the
    function, so add the declaration attribute.

    gcc/ChangeLog:

            PR debug/97060
            * dwarf2out.c (gen_subprogram_die): It's a declaration
            if DECL_INITIAL isn't set.

    gcc/testsuite/ChangeLog:

            PR debug/97060
            * gcc.dg/debug/dwarf2/pr97060.c: New test.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
  2020-09-15 22:16 [Bug debug/97060] New: Missing DW_AT_declaration=1 in dwarf data jolsa at redhat dot com
                   ` (13 preceding siblings ...)
  2020-11-12  5:58 ` cvs-commit at gcc dot gnu.org
@ 2020-11-13 18:38 ` jason at gcc dot gnu.org
  2020-11-19 13:33 ` hjl.tools at gmail dot com
                   ` (2 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: jason at gcc dot gnu.org @ 2020-11-13 18:38 UTC (permalink / raw)
  To: gcc-bugs

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #15 from Jason Merrill <jason at gcc dot gnu.org> ---
Fixed for GCC 11.  The patch will also be backported to the Red Hat GCC 10
branch that has the same bug.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
  2020-09-15 22:16 [Bug debug/97060] New: Missing DW_AT_declaration=1 in dwarf data jolsa at redhat dot com
                   ` (14 preceding siblings ...)
  2020-11-13 18:38 ` jason at gcc dot gnu.org
@ 2020-11-19 13:33 ` hjl.tools at gmail dot com
  2020-11-24 17:55 ` cvs-commit at gcc dot gnu.org
  2020-12-02 11:48 ` aoliva at gcc dot gnu.org
  17 siblings, 0 replies; 19+ messages in thread
From: hjl.tools at gmail dot com @ 2020-11-19 13:33 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #16 from H.J. Lu <hjl.tools at gmail dot com> ---
FWIW, I cherry-picked the fix onto vendors/redhat/gcc-10-branch branch.
I can build 5.10 kernel with the fixed GCC.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
  2020-09-15 22:16 [Bug debug/97060] New: Missing DW_AT_declaration=1 in dwarf data jolsa at redhat dot com
                   ` (15 preceding siblings ...)
  2020-11-19 13:33 ` hjl.tools at gmail dot com
@ 2020-11-24 17:55 ` cvs-commit at gcc dot gnu.org
  2020-12-02 11:48 ` aoliva at gcc dot gnu.org
  17 siblings, 0 replies; 19+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-11-24 17:55 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #17 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jason Merrill
<jason@gcc.gnu.org>:

https://gcc.gnu.org/g:38888c45da4414884a5424484f5db1ab951d9de6

commit r10-9070-g38888c45da4414884a5424484f5db1ab951d9de6
Author: Jason Merrill <jason@redhat.com>
Date:   Tue Nov 10 18:02:04 2020 -0500

    dwarf2: Set DW_AT_declaration for undefined fns [PR97060]

    If DECL_INITIAL isn't set, we can't emit anything about the body of the
    function, so add the declaration attribute.

    gcc/ChangeLog:

            PR debug/97060
            * dwarf2out.c (gen_subprogram_die): It's a declaration
            if DECL_INITIAL isn't set.

    gcc/testsuite/ChangeLog:

            PR debug/97060
            * gcc.dg/debug/dwarf2/pr97060.c: New test.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
  2020-09-15 22:16 [Bug debug/97060] New: Missing DW_AT_declaration=1 in dwarf data jolsa at redhat dot com
                   ` (16 preceding siblings ...)
  2020-11-24 17:55 ` cvs-commit at gcc dot gnu.org
@ 2020-12-02 11:48 ` aoliva at gcc dot gnu.org
  17 siblings, 0 replies; 19+ messages in thread
From: aoliva at gcc dot gnu.org @ 2020-12-02 11:48 UTC (permalink / raw)
  To: gcc-bugs

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

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

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

--- Comment #18 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
The pr97060 test is failing for me, in the gcc-10 branch, at least on target
arm-eabi.  It passes when optimization is enabled, because then the DIE with
the declaration tag, generated in resolve_addr, makes to the output.  With
optimization disabled, it's created and resolved, but doesn't make it.

It looks like this only works at -O0 with the patch for bug 96383, but it
hasn't been backported to gcc-10.  Only Red Hat's gcc-10 branch has it, as
stated in comment 6.

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2020-12-02 11:48 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-15 22:16 [Bug debug/97060] New: Missing DW_AT_declaration=1 in dwarf data jolsa at redhat dot com
2020-09-16  6:16 ` [Bug debug/97060] " rguenth at gcc dot gnu.org
2020-09-16  8:16 ` jolsa at redhat dot com
2020-09-16  8:41 ` jakub at gcc dot gnu.org
2020-09-16  8:55 ` jolsa at redhat dot com
2020-09-16  8:55 ` jakub at gcc dot gnu.org
2020-09-16  9:00 ` jakub at gcc dot gnu.org
2020-09-16  9:19 ` jakub at gcc dot gnu.org
2020-09-16 11:42 ` jakub at gcc dot gnu.org
2020-09-17 11:47 ` jolsa at redhat dot com
2020-09-17 12:23 ` jakub at gcc dot gnu.org
2020-09-17 12:39 ` jolsa at redhat dot com
2020-09-17 13:49 ` jakub at gcc dot gnu.org
2020-10-14 20:22 ` jolsa at redhat dot com
2020-11-12  5:58 ` cvs-commit at gcc dot gnu.org
2020-11-13 18:38 ` jason at gcc dot gnu.org
2020-11-19 13:33 ` hjl.tools at gmail dot com
2020-11-24 17:55 ` cvs-commit at gcc dot gnu.org
2020-12-02 11:48 ` aoliva 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).