* [Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719
[not found] <bug-66468-4@http.gcc.gnu.org/bugzilla/>
@ 2015-06-09 8:52 ` trippels at gcc dot gnu.org
2015-06-09 9:12 ` rguenth at gcc dot gnu.org
` (12 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: trippels at gcc dot gnu.org @ 2015-06-09 8:52 UTC (permalink / raw)
To: gcc-bugs
[-- 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719
[not found] <bug-66468-4@http.gcc.gnu.org/bugzilla/>
2015-06-09 8:52 ` [Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719 trippels at gcc dot gnu.org
@ 2015-06-09 9:12 ` rguenth at gcc dot gnu.org
2015-06-09 14:38 ` aldyh at gcc dot gnu.org
` (11 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-06-09 9:12 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719
[not found] <bug-66468-4@http.gcc.gnu.org/bugzilla/>
2015-06-09 8:52 ` [Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719 trippels at gcc dot gnu.org
2015-06-09 9:12 ` rguenth at gcc dot gnu.org
@ 2015-06-09 14:38 ` aldyh at gcc dot gnu.org
2015-07-17 20:10 ` hjl.tools at gmail dot com
` (10 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: aldyh at gcc dot gnu.org @ 2015-06-09 14:38 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719
[not found] <bug-66468-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2015-06-09 14:38 ` aldyh at gcc dot gnu.org
@ 2015-07-17 20:10 ` hjl.tools at gmail dot com
2015-07-20 18:22 ` jason at gcc dot gnu.org
` (9 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: hjl.tools at gmail dot com @ 2015-07-17 20:10 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719
[not found] <bug-66468-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2015-07-17 20:10 ` hjl.tools at gmail dot com
@ 2015-07-20 18:22 ` jason at gcc dot gnu.org
2015-07-20 22:14 ` jason at gcc dot gnu.org
` (8 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: jason at gcc dot gnu.org @ 2015-07-20 18:22 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719
[not found] <bug-66468-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2015-07-20 18:22 ` jason at gcc dot gnu.org
@ 2015-07-20 22:14 ` jason at gcc dot gnu.org
2015-07-21 17:10 ` jason at gcc dot gnu.org
` (7 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: jason at gcc dot gnu.org @ 2015-07-20 22:14 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719
[not found] <bug-66468-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2015-07-20 22:14 ` jason at gcc dot gnu.org
@ 2015-07-21 17:10 ` jason at gcc dot gnu.org
2015-07-21 18:12 ` jason at gcc dot gnu.org
` (6 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: jason at gcc dot gnu.org @ 2015-07-21 17:10 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719
[not found] <bug-66468-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2015-07-21 17:10 ` jason at gcc dot gnu.org
@ 2015-07-21 18:12 ` jason at gcc dot gnu.org
2015-07-27 16:57 ` jason at gcc dot gnu.org
` (5 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: jason at gcc dot gnu.org @ 2015-07-21 18:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719
[not found] <bug-66468-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2015-07-21 18:12 ` jason at gcc dot gnu.org
@ 2015-07-27 16:57 ` jason at gcc dot gnu.org
2015-07-27 17:00 ` [Bug lto/66468] " jason at gcc dot gnu.org
` (4 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: jason at gcc dot gnu.org @ 2015-07-27 16:57 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug lto/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719
[not found] <bug-66468-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2015-07-27 16:57 ` jason at gcc dot gnu.org
@ 2015-07-27 17:00 ` jason at gcc dot gnu.org
2015-08-06 2:28 ` miyuki at gcc dot gnu.org
` (3 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: jason at gcc dot gnu.org @ 2015-07-27 17:00 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug lto/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719
[not found] <bug-66468-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2015-07-27 17:00 ` [Bug lto/66468] " jason at gcc dot gnu.org
@ 2015-08-06 2:28 ` miyuki at gcc dot gnu.org
2015-08-15 7:59 ` trippels at gcc dot gnu.org
` (2 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: miyuki at gcc dot gnu.org @ 2015-08-06 2:28 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug lto/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719
[not found] <bug-66468-4@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2015-08-06 2:28 ` miyuki at gcc dot gnu.org
@ 2015-08-15 7:59 ` trippels at gcc dot gnu.org
2015-09-03 9:56 ` rguenth at gcc dot gnu.org
2015-09-03 10:00 ` rguenth at gcc dot gnu.org
13 siblings, 0 replies; 14+ messages in thread
From: trippels at gcc dot gnu.org @ 2015-08-15 7:59 UTC (permalink / raw)
To: gcc-bugs
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. ***
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug lto/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719
[not found] <bug-66468-4@http.gcc.gnu.org/bugzilla/>
` (11 preceding siblings ...)
2015-08-15 7:59 ` trippels at gcc dot gnu.org
@ 2015-09-03 9:56 ` rguenth at gcc dot gnu.org
2015-09-03 10:00 ` rguenth at gcc dot gnu.org
13 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-09-03 9:56 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug lto/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719
[not found] <bug-66468-4@http.gcc.gnu.org/bugzilla/>
` (12 preceding siblings ...)
2015-09-03 9:56 ` rguenth at gcc dot gnu.org
@ 2015-09-03 10:00 ` rguenth at gcc dot gnu.org
13 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-09-03 10:00 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread