This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix profiledbootstrap ada checking failure (PR debug/79255)
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Jason Merrill <jason at redhat dot com>, gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 24 Mar 2017 12:45:28 +0100
- Subject: Re: [PATCH] Fix profiledbootstrap ada checking failure (PR debug/79255)
- Authentication-results: sourceware.org; auth=none
- References: <20170323204414.GZ11094@tucnak> <CADzB+2mj8WxSAUvPWcywYt=hEn=0VbAYMSoVH6rxypPV-0kC6A@mail.gmail.com> <20170324074639.GG11094@tucnak> <CAFiYyc1XHY_z3UkUrhZA8oDu0Jz71jKGCdu2puXbn3g5RByWCA@mail.gmail.com> <20170324084326.GH11094@tucnak>
On Fri, Mar 24, 2017 at 9:43 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Fri, Mar 24, 2017 at 09:29:00AM +0100, Richard Biener wrote:
>> Yeah, the thing BLOCK_NONLOCALIZED_VARS wants to do is optimize generated
>> dwarf by adding a DW_AT_abstract_origin (just to refer to the
>> subprogram DIE) but
>
> Well, for FUNCTION_DECLs in BLOCK_VARS/BLOCK_NONLOCALIZED_VARS we actually don't
> emit any further DIE and so there is no DW_AT_abstract_origin.
> E.g. gen_subprogram_die has:
> /* Detect and ignore this case, where we are trying to output
> something we have already output. */
> if (get_AT (old_die, DW_AT_low_pc)
> || get_AT (old_die, DW_AT_ranges))
> return;
Hmm, but we do want to put the function in scope? THus
void foo () {}
void bar ()
{
int foo;
{
void foo();
foo();
}
}
should have a DIE for foo in bar (possibly refering to the concrete instance
for optimization).
Richard.
> That is why the posted testcase doesn't ICE without -fno-toplevel-reorder,
> normally the body is emitted earlier and so we don't do anything at all.
> Otherwise we just want to make sure we have a DIE and, if it is
> inline/clone, have also DW_AT_inline set, and if the DIE is without parent
> that we put it into proper place in the DIE tree. And when we actually
> see the body of the function we fill locations and all other details.
>
> Jakub