[Bug lto/63968] New: [5 Regression] 175.vpr from cpu2000 fails to build with LTO

[Bug lto/63968] New: [5 Regression] 175.vpr from cpu2000 fails to build with LTO

[hjl.tools at gmail dot com]

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

            Bug ID: 63968
           Summary: [5 Regression] 175.vpr from cpu2000 fails to build
                    with LTO
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hjl.tools at gmail dot com

On Linux/x86-64, r217766 gave

gcc -c -o read_place.o   -DSPEC_CPU2000_LP64    -DSPEC_CPU2000     -O2
-ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin  read_place.c
gcc     -O2 -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin
-DSPEC_CPU2000_LP64 main.o util.o read_netlist.o read_arch.o place.o route.o
draw.o graphics.o stats.o segment_stats.o rr_graph.o rr_graph2.o
rr_graph_sbox.o rr_graph_util.o rr_graph_timing_params.o rr_graph_area.o
check_rr_graph.o check_route.o hash.o read_place.o   -lm  -o vpr
stats.c: In function 'routing_stats':
stats.c:128:1: internal compiler error: in decrease_key, at
fibonacci_heap.h:189
 }
 ^
0x59f5dc fibonacci_heap<long,
basic_block_def>::decrease_key(fibonacci_node<long, basic_block_def>*, long)
    ../../src-trunk/gcc/fibonacci_heap.h:189
0xf5463c fibonacci_heap<long,
basic_block_def>::decrease_key(fibonacci_node<long, basic_block_def>*, long)
    ../../src-trunk/gcc/bb-reorder.c:2248
0xf5463c find_traces_1_round
    ../../src-trunk/gcc/bb-reorder.c:648
0xf5463c find_traces
    ../../src-trunk/gcc/bb-reorder.c:326
0xf5463c reorder_basic_blocks
    ../../src-trunk/gcc/bb-reorder.c:2276
0xf5463c execute
    ../../src-trunk/gcc/bb-reorder.c:2371
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [/tmp/ccARtdMs.ltrans8.ltrans.o] Error 1
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/local/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
specmake[3]: *** [vpr] Error 1

[Bug lto/63968] [5 Regression] 175.vpr from cpu2000 fails to build with LTO

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-11-19
                 CC|                            |marxin at gcc dot gnu.org
   Target Milestone|---                         |5.0
     Ever confirmed|0                           |1

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
It was caused by r217721.

[Bug lto/63968] [5 Regression] 175.vpr from cpu2000 fails to build with LTO

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Problem was introduced by adding gcc_assert that guards if we really decrease a
key. I'm testing patch that implements slow path: if a key is bigger than
current value, we process correct increase operation (deletion + insertion).

Old implementation suppress replace operation if a key is bigger and there's no
notification about that.

bb-reorder output for 175.vpr:
lChanging key for bb 5 from -155 to -1015655.
Changing key for bb 12 from -533 to -1049033.
Changing key for bb 19 from -533 to -1049033.
Changing key for bb 22 from -53 to -1004853.
Changing key for bb 31 from -1250 to -1126250.
Changing key for bb 27 from -533 to -1006133.
Changing key for bb 23 from -53 to -1004853.
Changing key for bb 50 from -533 to -1049033.
Changing key for bb 51 from -53 to -1004853.
Changing key for bb 58 from -533 to -1049033.
Changing key for bb 61 from -53 to -1004853.
Changing key for bb 197 from -27 to -1002727.
Changing key for bb 205 from -9 to -1000809.
Changing key for bb 70 from -37 to -1003737.
Changing key for bb 79 from -37 to -1003737.
Changing key for bb 98 from -1003468 to -1001768.

Thanks,
Martin
>From gcc-bugs-return-467697-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Nov 20 10:30:07 2014
Return-Path: <gcc-bugs-return-467697-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18962 invoked by alias); 20 Nov 2014 10:30:07 -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 18921 invoked by uid 48); 20 Nov 2014 10:30:04 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63977] [5 Regression] r217769 caused many failures
Date: Thu, 20 Nov 2014 10:30:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: rth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: priority target_milestone
Message-ID: <bug-63977-4-7bRmSYZKoT@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63977-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63977-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: 2014-11/txt/msg02169.txt.bz2
Content-length: 344

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
   Target Milestone|---                         |5.0

[Bug lto/63968] [5 Regression] 175.vpr from cpu2000 fails to build with LTO

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
Created attachment 34050
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34050&action=edit
fh_fix.patch
>From gcc-bugs-return-467700-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Nov 20 10:34:33 2014
Return-Path: <gcc-bugs-return-467700-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22280 invoked by alias); 20 Nov 2014 10:34:33 -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 22243 invoked by uid 48); 20 Nov 2014 10:34:30 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/63968] [5 Regression] 175.vpr from cpu2000 fails to build with LTO
Date: Thu, 20 Nov 2014 10:34:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: marxin at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: priority
Message-ID: <bug-63968-4-7KGvleRpUp@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63968-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63968-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: 2014-11/txt/msg02172.txt.bz2
Content-length: 291

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug lto/63968] [5 Regression] 175.vpr from cpu2000 fails to build with LTO

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

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

--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
  /* If we wanted to, we could actually do a real increase by redeleting and
     inserting. However, this would require O (log n) time. So just bail out
     for now.  */
  if (fibheap_comp_data (heap, key, data, node) > 0)
    return NULL;

It is clearly bug in the old implementation.  Increase is quite easy to handle:
you just remember the increased value and if your find_min returns one where
value has increased, just re-insert it and get another minimum.

This requires to store two keys, that is probably not good for generic
template.  Perhaps bb-reorder can just see if it is increasing and perform
delete+insert. Its loop is not perofrmance critical (inliner did so and it was
too slow in that case)

[Bug lto/63968] [5 Regression] 175.vpr from cpu2000 fails to build with LTO

[mliska at suse dot cz]

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

--- Comment #5 from Martin Liška <mliska at suse dot cz> ---
On 11/20/2014 11:43 PM, hubicka at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63968
>
> Jan Hubicka <hubicka at gcc dot gnu.org> changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                   CC|                            |hubicka at gcc dot gnu.org
>
> --- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
>    /* If we wanted to, we could actually do a real increase by redeleting and
>       inserting. However, this would require O (log n) time. So just bail out
>       for now.  */
>    if (fibheap_comp_data (heap, key, data, node) > 0)
>      return NULL;
>
> It is clearly bug in the old implementation.  Increase is quite easy to handle:
> you just remember the increased value and if your find_min returns one where
> value has increased, just re-insert it and get another minimum.
>
> This requires to store two keys, that is probably not good for generic
> template.  Perhaps bb-reorder can just see if it is increasing and perform
> delete+insert. Its loop is not perofrmance critical (inliner did so and it was
> too slow in that case)
>

Hi.

My suggested patch adds support for increase operation, where I delete 
and insert new key. As such usage is quite rare, I hope suggested 
approach fits? One can choose between: 'replace_key' and 'decrease', 
where the second one contains assert that new key is really smaller.

Thanks,
Martin
>From gcc-bugs-return-467923-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 21 11:14:19 2014
Return-Path: <gcc-bugs-return-467923-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24784 invoked by alias); 21 Nov 2014 11:14:18 -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 24704 invoked by uid 55); 21 Nov 2014 11:14:10 -0000
From: "ienkovich at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/60451] X86 vectorization improve: pack instead of pshufb
Date: Fri, 21 Nov 2014 11:14:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: ienkovich at gcc dot gnu.org
X-Bugzilla-Status: NEW
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:
Message-ID: <bug-60451-4-gbtA419UAy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60451-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60451-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: 2014-11/txt/msg02395.txt.bz2
Content-length: 728

https://gcc.gnu.org/bugzilla/show_bug.cgi?id`451

--- Comment #2 from ienkovich at gcc dot gnu.org ---
Author: ienkovich
Date: Fri Nov 21 11:13:37 2014
New Revision: 217913

URL: https://gcc.gnu.org/viewcvs?rev!7913&root=gcc&view=rev
Log:
gcc/testsuite

    PR target/60451
    * gcc.target/i386/pr60451.c: New.

gcc/
    PR target/60451
    * config/i386/i386.c (expand_vec_perm_even_odd_pack): New.
    (expand_vec_perm_even_odd_1): Add new expand for V8HI mode,
    replace for V16QI, V16HI and V32QI modes.
    (ix86_expand_vec_perm_const_1): Add new expand.


Added:
    trunk/gcc/testsuite/gcc.target/i386/pr60451.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c
    trunk/gcc/testsuite/ChangeLog

[Bug lto/63968] [5 Regression] 175.vpr from cpu2000 fails to build with LTO

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

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

--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
Fixed.
>From gcc-bugs-return-468210-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Nov 24 10:25:44 2014
Return-Path: <gcc-bugs-return-468210-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21297 invoked by alias); 24 Nov 2014 10:25:44 -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 21230 invoked by uid 55); 24 Nov 2014 10:25:39 -0000
From: "marxin at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/63968] [5 Regression] 175.vpr from cpu2000 fails to build with LTO
Date: Mon, 24 Nov 2014 10:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marxin at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: marxin at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63968-4-FwAGJqnUVX@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63968-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63968-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: 2014-11/txt/msg02682.txt.bz2
Content-length: 790

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

--- Comment #7 from Martin Liška <marxin at gcc dot gnu.org> ---
Author: marxin
Date: Mon Nov 24 10:25:06 2014
New Revision: 218006

URL: https://gcc.gnu.org/viewcvs?rev=218006&root=gcc&view=rev
Log:
PR lto/63968

        * bb-reorder.c (find_traces_1_round): decreate_key is replaced
    with replace_key method.
    * fibonacci_heap.h (fibonacci_heap::insert): New argument.
    (fibonacci_heap::replace_key_data): Likewise.
    (fibonacci_heap::replace_key): New method that can even increment key,
    this operation costs O(log N).
    (fibonacci_heap::extract_min): New argument.
    (fibonacci_heap::delete_node): Likewise.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/bb-reorder.c
    trunk/gcc/fibonacci_heap.h
>From gcc-bugs-return-468211-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Nov 24 10:29:41 2014
Return-Path: <gcc-bugs-return-468211-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24013 invoked by alias); 24 Nov 2014 10:29:41 -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 23966 invoked by uid 48); 24 Nov 2014 10:29:35 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/64043] [5 Regression] ICE (segfault) with LTO: in tree_check/tree.h:2758 get_binfo_at_offset/tree.c:11914
Date: Mon, 24 Nov 2014 10:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on cc target_milestone everconfirmed
Message-ID: <bug-64043-4-VLFNw2lohN@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64043-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64043-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: 2014-11/txt/msg02683.txt.bz2
Content-length: 2224

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-11-24
                 CC|                            |trippels at gcc dot gnu.org
   Target Milestone|---                         |5.0
     Ever confirmed|0                           |1

--- Comment #1 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
This is a case of -O0 vs -O2 (during final link):

Further reduced:

markus@x4 testcase % cat one.ii
class Validator
{
public:
  virtual ~Validator ();
};
class FooWriter
{
  Validator *validator;
  ~FooWriter ();
};
FooWriter::~FooWriter () { delete validator; }

markus@x4 testcase % g++ -flto -std=c++11 -c one.ii
markus@x4 testcase % g++ -r -nostdlib -O2 -flto one.o
one.ii: In member function ‘__base_dtor ’:
one.ii:11:1: internal compiler error: Segmentation fault
 FooWriter::~FooWriter () { delete validator; }
 ^
0x9dc45f crash_signal
        ../../gcc/gcc/toplev.c:359
0xc3f211 tree_check
        ../../gcc/gcc/tree.h:2758
0xc3f211 get_binfo_at_offset(tree_node*, long, tree_node*)
        ../../gcc/gcc/tree.c:11914
0x82855b possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**, bool)
        ../../gcc/gcc/ipa-devirt.c:2404
0x792a2f possible_polymorphic_call_targets(tree_node*, gimple_statement_base*,
bool*, void**)
        ../../gcc/gcc/ipa-utils.h:126
0x790c4a gimple_fold_call
        ../../gcc/gcc/gimple-fold.c:2667
0x790c4a fold_stmt_1
        ../../gcc/gcc/gimple-fold.c:3246
0xafb1a3 execute
        ../../gcc/gcc/tree-ssa-forwprop.c:2228
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: fatal error: /var/tmp/gcc_test/usr/local/bin/g++ returned 1 exit
status
compilation terminated.
/usr/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
>From gcc-bugs-return-468212-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Nov 24 10:32:51 2014
Return-Path: <gcc-bugs-return-468212-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26052 invoked by alias); 24 Nov 2014 10:32:50 -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 25843 invoked by uid 48); 24 Nov 2014 10:32:47 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug java/64044] New: Java emits bogus .class$ decls
Date: Mon, 24 Nov 2014 10:32:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: java
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status keywords bug_severity priority component assigned_to reporter cc
Message-ID: <bug-64044-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: 2014-11/txt/msg02684.txt.bz2
Content-length: 2480

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

            Bug ID: 64044
           Summary: Java emits bogus .class$ decls
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: java
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org
                CC: aph at gcc dot gnu.org

Currently the Java FE is lucky that not all -findirect-dispatch testcases are
miscompiled as gimple-fold.c:get_symbol_constant_value has

      /* Variables declared 'const' without an initializer
         have zero as the initializer if they may not be
         overridden at link or run time.  */
      if (!val
          && (INTEGRAL_TYPE_P (TREE_TYPE (sym))
               || SCALAR_FLOAT_TYPE_P (TREE_TYPE (sym))))
        return build_zero_cst (TREE_TYPE (sym));

which for unkown reason avoids to fold the reads from .class$ at the beginning
of all functions to NULL (because the above doesn't allow pointer types).

I ran into this when doing the same during value-numbering but "forgetting"
to paper over the Java FE bug.

The Java FE emits (for example)

 <var_decl 0x7ffff6c6e360 Array_2.class$
    type <pointer_type 0x7ffff6c69a80
        type <record_type 0x7ffff6c69930 java.lang.Class readonly type_4 BLK
            size <integer_cst 0x7ffff6c43858 constant 2240>
            unit size <integer_cst 0x7ffff6c43828 constant 280>
            align 64 symtab 0 alias set -1 canonical type 0x7ffff6c69930 fields
<field_decl 0x7ffff6c521c8 D.89>
            pointer_to_this <pointer_type 0x7ffff6c699d8>>
        readonly public unsigned DI
        size <integer_cst 0x7ffff6c25bb8 constant 64>
        unit size <integer_cst 0x7ffff6c25bd0 constant 8>
        align 64 symtab 0 alias set -1 canonical type 0x7ffff6c69a80
        pointer_to_this <pointer_type 0x7ffff6c7f888>>
    readonly constant addressable public static unsigned ignored DI file
Array_2.java line 4 col 0 size <integer_cst 0x7ffff6c25bb8 64> unit size
<integer_cst 0x7ffff6c25bd0 8>
    align 64 context <record_type 0x7ffff6c5e540 Array_2>
    (mem/u/f/c:DI (symbol_ref:DI ("_ZN7Array_27class$$E") [flags 0x2]
<var_decl 0x7ffff6c6e360 Array_2.class$>) [2 Array_2.class$+0 S8 A64])>

which misses an initializer (it seems to be not initialized in .s either,
thus the flags on it are wrong?  Probably they get initialized by the
runtime?).