[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[trippels at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 6481 bytes --]

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-06-09
     Ever confirmed|0                           |1

--- Comment #4 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Yeah. It is also easily fixed:


markus@x4 testc % cat 1.ii
namespace std
{
template <typename> class allocator;
template <typename _Tp, typename = allocator<_Tp> > class vector
{
public:
  ~vector () {}
};
vector<unsigned> b;
}

template <typename _Tp> class A
{
public:
  typedef _Tp reference;
};

template <typename _Tp, typename _Alloc = A<_Tp> > class B
{
public:
  typename _Alloc::reference operator[](int);
};

namespace MosesTuning
{
class Point
{
};
class Optimizer
{
public:
  float Run (Point &) const;
};
}
using namespace MosesTuning;
class C
{
public:
  C (Point) { m_optimizer.Run (m_point); }
  Optimizer m_optimizer;
  Point m_point;
};

main ()
{
  B<Point> a;
  (C (a[0]));
}

markus@x4 testc % cat 2.ii
namespace std
{
template <typename> class allocator;
struct _Vector_base
{
  ~_Vector_base ();
};
template <typename _Tp, typename = allocator<_Tp> > class vector : _Vector_base
{
};
}

namespace MosesTuning
{
class Point;
class Optimizer
{
  float Run (Point &) const;
};
}
using namespace std;
namespace MosesTuning
{
float
Optimizer::Run (Point &) const
{
  vector<unsigned> a;
}
}

markus@x4 testc % /var/tmp/gcc_test/usr/local/bin/g++ -r -nostdlib 1.ii 2.ii -g
-O2 -flto
2.ii: In member function ‘__base_dtor ’:
2.ii:28:1: internal compiler error: in check_die, at dwarf2out.c:5712
>From gcc-bugs-return-488456-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 09 08:54:24 2015
Return-Path: <gcc-bugs-return-488456-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13298 invoked by alias); 9 Jun 2015 08:54:24 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 13241 invoked by uid 48); 9 Jun 2015 08:54:20 -0000
From: "iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
Date: Tue, 09 Jun 2015 08:54:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: iains at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66448-4-3i3t2hAnpg@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66448-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66448-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg00788.txt.bz2
Content-length: 472

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

--- Comment #11 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #10)
> It's not supposed to. It's for issue three as stated.

indeed;
state as of now is that (with both proposed patches in place and
--disable-werror), the multiple DWARF entity ld64 warnings are gone from my
bootstrap log.  The test suite is running - was going to wait to report until
that's done …
>From gcc-bugs-return-488457-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 09 09:06:11 2015
Return-Path: <gcc-bugs-return-488457-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 41264 invoked by alias); 9 Jun 2015 09:06:11 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 41179 invoked by uid 48); 9 Jun 2015 09:06:07 -0000
From: "krebbel at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/33661] template methods forget explicit local reg vars
Date: Tue, 09 Jun 2015 09:06:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.2.2
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: krebbel at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-33661-4-hZ6b8aqnNC@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-33661-4@http.gcc.gnu.org/bugzilla/>
References: <bug-33661-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg00789.txt.bz2
Content-length: 491

https://gcc.gnu.org/bugzilla/show_bug.cgi?id3661

--- Comment #13 from Andreas Krebbel <krebbel at gcc dot gnu.org> ---
Created attachment 35723
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id5723&actioníit
Experimental fix

The attached patch fixes the problem for me.

There appear to be two problems:

1. When parsing a template function cp_finish_decl returns before the asmspec
is set in a var decl.
2. When expanding the template function the assembler_name is zeroed out.

[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |6.0

[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

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

--- Comment #5 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Jason, this behavior exists prior to the debug-early work.

For the 1.ii/2.ii testcase in comment 4 we are generating a DIE for a
__base_dtor.  First we retrofit the declaration with force_decl_die,
and use this DIE as the basis for a DW_AT_specification variant.
Eventually dwarf2out_abstract_function() gets called on this
DW_AT_specification variant and we annotate it with DW_AT_inline.
This DW_AT_specification variant, already has location info which is
why we fail the assert.

It was my understanding that DW_AT_inline cannot appear in conjunction
with location info.

I added the check_die() code to a branch of mainline immediately
before my work, and it ICEs similarly to current mainline with a
problematic DIE of:

DIE    0: DW_TAG_subprogram (0x7ffff03885a0)
  abbrev id: 0 offset: 0 mark: 0
  DW_AT_specification: die -> 0 (0x7ffff03884b0)
  DW_AT_low_pc: label: *.LFB0
  DW_AT_high_pc: label: *.LFE0
  DW_AT_frame_base: location descriptor:
    (0x7ffff03885f0) DW_OP_call_frame_cfa 0, 0

  DW_AT_GNU_all_call_sites: 1
  DW_AT_inline: 2

Could you please take a look at this, since it is broken behavior
prior to early debug?  Perhaps it is expected behavior and we can
remove the DW_AT_inline + location check?

[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> ---
Any progress on this?  FDO+LTO bootstrap has been broken for weeks now.

[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #5)
> It was my understanding that DW_AT_inline cannot appear in conjunction
> with location info.

Right.

"A debugging information entry that is a member of an abstract instance tree
should not contain any attributes which describe aspects of the subroutine
which
vary between distinct inlined expansions or distinct out-of-line expansions."

I'll take a look.

[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill <jason at gcc dot gnu.org> ---
The problem seems to be that we inlined the function, but DECL_POSSIBLY_INLINED
remains unset, so dwarf2out doesn't think it needs to call
dwarf2out_abstract_function.

There also doesn't seem to be a cgraph edge for the inlined function call; I'm
guessing that the function was inlined in the initial compilation, and this
relationship is forgotten by the time we get to LTO.

So, doesn't look like a dwarf2out bug.

[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #9)
> Do you think perhaps we could diagnose this sort of problem earlier so 
> it doesn't show up (confusingly) in dwarf2out land?

I'm not sure where to check that outside dwarf2out.

I tried adding

  gcc_checking_assert (cgraph_function_possibly_inlined_p (decl));

in gen_inlined_subroutine_die to make the problem clearer, and I get a bunch of
new failures in the debug tests, so it doesn't seem to be limited to LTO.

[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[jason at gcc dot gnu.org]

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

--- Comment #11 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Jason Merrill from comment #10)
> I tried adding
> 
>   gcc_checking_assert (cgraph_function_possibly_inlined_p (decl));
> 
> in gen_inlined_subroutine_die to make the problem clearer, and I get a bunch
> of new failures in the debug tests, so it doesn't seem to be limited to LTO.

...but changing that to

  gcc_checking_assert (DECL_ABSTRACT_P (decl)
                       || cgraph_function_possibly_inlined_p (decl));

resolves the testsuite failures, and just fires on this LTO testcase.

[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[jason at gcc dot gnu.org]

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

--- Comment #12 from Jason Merrill <jason at gcc dot gnu.org> ---
Author: jason
Date: Mon Jul 27 16:57:15 2015
New Revision: 226255

URL: https://gcc.gnu.org/viewcvs?rev=226255&root=gcc&view=rev
Log:
        PR debug/66468
        * dwarf2out.c (gen_inlined_subroutine_die): Check
        cgraph_function_possibly_inlined_p.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/dwarf2out.c

[Bug lto/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[jason at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|debug                       |lto

--- Comment #13 from Jason Merrill <jason at gcc dot gnu.org> ---
Changing component to LTO, since the bug seems to be with early inlining vs LTO
streaming.

[Bug lto/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev <miyuki at gcc dot gnu.org> changed:

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

--- Comment #14 from Mikhail Maltsev <miyuki at gcc dot gnu.org> ---
Another reproducer:

$ cat genmodes.cc 
inline char *strchr(const char *, int) __asm("strchr");
inline char *strchr(const char *, int)
{
  return __builtin_strchr(0, 0);
}

int make_complex_modes()
{
  if (strchr(0, 0))
    return 1;
}

$ cc1plus -O -flto genmodes.cc -quiet -o - | as -o genmodes.o
$ lto1 genmodes.o -g -o /dev/null -quiet
genmodes.cc: In function 'make_complex_modes':
genmodes.cc:11:1: internal compiler error: in gen_inlined_subroutine_die, at
dwarf2out.c:19910

[Bug lto/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dilyan.palauzov at aegee dot org

--- Comment #15 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
*** Bug 67158 has been marked as a duplicate of this bug. ***

[Bug lto/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Mikhail Maltsev from comment #14)
> Another reproducer:
> 
> $ cat genmodes.cc 
> inline char *strchr(const char *, int) __asm("strchr");
> inline char *strchr(const char *, int)
> {
>   return __builtin_strchr(0, 0);
> }
> 
> int make_complex_modes()
> {
>   if (strchr(0, 0))
>     return 1;
> }
> 
> $ cc1plus -O -flto genmodes.cc -quiet -o - | as -o genmodes.o
> $ lto1 genmodes.o -g -o /dev/null -quiet
> genmodes.cc: In function 'make_complex_modes':
> genmodes.cc:11:1: internal compiler error: in gen_inlined_subroutine_die, at
> dwarf2out.c:19910

This one i fixed recently.

[Bug lto/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
Comment 4 is also fixed, the original testcase as well.