[Bug middle-end/60381] New: [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245

[Bug middle-end/60381] New: [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381

            Bug ID: 60381
           Summary: [4.9 Regression] ICE: in vt_expand_var_loc_chain, at
                    var-tracking.c:8245
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: danglin at gcc dot gnu.org
                CC: aoliva at gcc dot gnu.org
              Host: hppa-unknown-linux-gnu
            Target: hppa-unknown-linux-gnu
             Build: hppa-unknown-linux-gnu

Created attachment 32241
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32241&action=edit
Preprocessed source

/home/dave/gnu/gcc/objdir/./gcc/xgcc -B/home/dave/gnu/gcc/objdir/./gcc/
-B/home/
dave/opt/gnu/gcc/gcc-4.9/hppa-linux-gnu/bin/
-B/home/dave/opt/gnu/gcc/gcc-4.9/hppa-linux-gnu/lib/ -isystem
/home/dave/opt/gnu/gcc/gcc-4.9/hppa-linux-gnu/include -isystem
/home/dave/opt/gnu/gcc/gcc-4.9/hppa-linux-gnu/sys-include    -g -O2 -O
2  -g -O2 -DIN_GCC    -W -Wall -Wwrite-strings -Wcast-qual -Wno-format
-Wstrict-
prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include  
-fPIC -DELF=1 -DLINUX=1 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector 
 -fPIC -DELF=1 -DLINUX=1 -I. -I. -I../.././gcc -I../../../gcc/libgcc
-I../../../gcc
/libgcc/. -I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include 
-DHAVE_
CC_TLS  -o _divdc3.o -MT _divdc3.o -MD -MP -MF _divdc3.dep -DL_divdc3 -c
../../.
./gcc/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
../../../gcc/libgcc/libgcc2.c: In function ‘__muldc3’:
../../../gcc/libgcc/libgcc2.c:2001:1: internal compiler error: in
vt_expand_var_
loc_chain, at var-tracking.c:8245
 }
0xd07623 vt_expand_var_loc_chain
        ../../gcc/gcc/var-tracking.c:8245
0xd0823b vt_expand_loc_callback
        ../../gcc/gcc/var-tracking.c:8441
0x3caa57 cselib_expand_value_rtx_1
        ../../gcc/gcc/cselib.c:1692
0x3cacdb cselib_expand_value_rtx_1
        ../../gcc/gcc/cselib.c:1730
0x3ca46f cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
        ../../gcc/gcc/cselib.c:1539
0xd0775f vt_expand_var_loc_chain
        ../../gcc/gcc/var-tracking.c:8279
0xd0823b vt_expand_loc_callback
        ../../gcc/gcc/var-tracking.c:8441
0x3caa57 cselib_expand_value_rtx_1
        ../../gcc/gcc/cselib.c:1692
0x3cacdb cselib_expand_value_rtx_1
        ../../gcc/gcc/cselib.c:1730
0x3ca46f cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
        ../../gcc/gcc/cselib.c:1539
0xd0775f vt_expand_var_loc_chain
        ../../gcc/gcc/var-tracking.c:8279
0xd0823b vt_expand_loc_callback
        ../../gcc/gcc/var-tracking.c:8441
0x3caa57 cselib_expand_value_rtx_1
        ../../gcc/gcc/cselib.c:1692
0x3ca46f cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
        ../../gcc/gcc/cselib.c:1539
0xd0775f vt_expand_var_loc_chain
        ../../gcc/gcc/var-tracking.c:8279
0xd0880b vt_expand_1pvar
        ../../gcc/gcc/var-tracking.c:8554
0xd08b0f emit_note_insn_var_location(variable_def**, emit_note_data_def*)
        ../../gcc/gcc/var-tracking.c:8608
0xd116df void hash_table<variable_hasher,
xcallocator>::traverse_noresize<emit_note_data_def*,
&(emit_note_insn_var_location(variable_def**,
emit_note_data_def*))>(emit_note_data_def*)
        ../../gcc/gcc/hash-table.h:928
0xd105e7 void hash_table<variable_hasher,
xcallocator>::traverse<emit_note_data_def*,
&(emit_note_insn_var_location(variable_def**,
emit_note_data_def*))>(emit_note_data_def*)
        ../../gcc/gcc/hash-table.h:950
0xd0a46f emit_notes_for_changes
        ../../gcc/gcc/var-tracking.c:8970
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[3]: *** [_muldc3.o] Error 1

Introduced in revision 208220.
>From gcc-bugs-return-445183-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Mar 01 21:28:54 2014
Return-Path: <gcc-bugs-return-445183-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25311 invoked by alias); 1 Mar 2014 21:28:54 -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 25285 invoked by uid 55); 1 Mar 2014 21:28:50 -0000
From: "abutcher at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60377] [c++1y] ICE with invalid function parameter in conjunction with auto parameter
Date: Sat, 01 Mar 2014 21:28: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.9.0
X-Bugzilla-Keywords: diagnostic, error-recovery, ice-on-invalid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: abutcher 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:
Message-ID: <bug-60377-4-prby1Gnox5@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60377-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60377-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-03/txt/msg00052.txt.bz2
Content-length: 639

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`377

--- Comment #1 from Adam Butcher <abutcher at gcc dot gnu.org> ---
Author: abutcher
Date: Sat Mar  1 21:28:18 2014
New Revision: 208250

URL: http://gcc.gnu.org/viewcvs?rev 8250&root=gcc&view=rev
Log:
Fix PR c++/60377.

    PR c++/60377
    * parser.c (cp_parser_parameter_declaration_clause): Unwind generic
    function scope on parse error in function parameter list.

    PR c++/60377
    * g++.dg/cpp1y/pr60377.C: New testcase.

Added:
    trunk/gcc/testsuite/g++.dg/cpp1y/pr60377.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/parser.c
    trunk/gcc/testsuite/ChangeLog

[Bug middle-end/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381

--- Comment #1 from John David Anglin <danglin at gcc dot gnu.org> ---
(gdb) r
Starting program: /home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgcc/../../gcc/cc1
-fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -auxbase-strip _divdc3.o -g
-g -g -O2 -O2 -O2 -Wextra -Wall -Wwrite-strings -Wcast-qual -Wformat=0
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version
-fbuilding-libgcc -fno-stack-protector -fPIC -fvisibility=hidden -o libgcc2.s
GNU C (GCC) version 4.9.0 20140228 (experimental) [trunk revision 208220]
(hppa-linux-gnu)
    compiled by GNU C version 4.6.4, GMP version 5.1.3, MPFR version 3.1.2-p3,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.9.0 20140228 (experimental) [trunk revision 208220]
(hppa-linux-gnu)
    compiled by GNU C version 4.6.4, GMP version 5.1.3, MPFR version 3.1.2-p3,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: e5ddc5eadc758a9e6fcf473bee448b45

Breakpoint 1, vt_expand_var_loc_chain (var=0x14df4d0, regs=0x14817ac, 
    data=0xfaf02d4c, pendrecp=0xfaf03610) at ../../gcc/gcc/var-tracking.c:8245
8245          gcc_checking_assert (cselib_preserved_value_p (val));
(gdb) p val
$1 = (cselib_val *) 0x14bce80
(gdb) p *val
$2 = {hash = 7, uid = 7, val_rtx = 0x14ddda0, locs = 0x0, addr_list = 0x0, 
  next_containing_mem = 0x0}
(gdb) p debug_rtx (val->val_rtx)
(value/f/i:SI 7:7 @0x14ddda0/0x14bce80)
$3 = void

[Bug middle-end/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381

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

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

[Bug middle-end/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P2
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Seems like hppa only, thus does not merit P1.

[Bug middle-end/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This seems to be due to r208220.

One problem I see is that when var-tracking.c calls cselib_preserve_only_values
+ cselib_reset_table, the latter clears n_useless_values (and
n_useless_debug_values) and drops non-preserved VALUEs with no locations, so
while we get rid of the non-preserved VALUEs with no locations, it can happen
that discard_useless_locs is never performed, even when the cumulative number
of dropped useless locs became very large.

So, I wonder if r208220 shouldn't be reverted and instead we'd use slightly
different condition on when to call remove_useless_values from
cselib_preserve_only_values, or perhaps just do the
  do
    {
      values_became_useless = 0;
      cselib_hash_table.traverse <void *, discard_useless_locs> (NULL);
    }
  while (values_became_useless);
part of remove_useless_values, since the rest of the function does nothing or
is useless with the immediately following cselib_reset_table (is it?) or
cselib_invalidate_mem (callmem) done right before that.  For the different
condition, I'd imagine that for cselib_preserve_constants we'd sum up in some
new int variable the n_useless_values counts from entry to cselib_reset_table,
and clear that inside of remove_useless_locs and use that in the guard
condition when to discard useless locs from cselib_preserve_only_values.  Thus,
if we say have 30000 ebbs and in each of them gain say 10 useless values (that
are dropped), we'd eventually discard_useless_locs at least after some ebbs,
though not after each one.

Also, I wonder because of this ICE if we shouldn't forcefully
remove_useless_values (if any values have become useless since last
discard_useless_locs call) at the end of vt_initialize, to make sure we don't
have useless locs at the end, and also
cselib_preserved_hash_table.traverse <void *, discard_useless_locs> (NULL);
after that (so that we don't reference non-preserved VALUEs from preserved
VALUE locs).  We don't need to retry that, because cselib_preserved_hash_table
contains only preserved values and thus value_became_useless should be always
unchanged while walking that table.

[Bug debug/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381

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

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note I've posted a patch in the mean time:
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00142.html

[Bug debug/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245

[aoliva at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381

--- Comment #6 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Created attachment 32274
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32274&action=edit
WIP patch to start combining useless value removal and table reset, after
reverting the faulty patch

I'd prefer if we kept the preserved table without potentially useless locs. 
I've struggled for several hours this morning trying to combine useless value
removal, preservation of values in the alternate table, detection of constants
and equivalences for preservation and discarding values that should not be
preserved into fewer passes over the hash table, unfortunately without much
success.  In the end, I returned to mostly separate removal and reset passes,
but I've managed to make both passes optional, except at the end of
vt_initialize.  Here's the WIP patch, to be applied after the reversal of the
faulty patch.  Unfortunately, the result is not much faster than the reversal,
probably because it works much harder to release cselib_vals and loc lists as
they get removed from the table, instead of just dropping them on the floor
till the pool is released as a whole.

[Bug debug/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I've measured (everything --enable-checking=release bootstrapped) vanilla
trunk, that + my http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00142.html patch,
trunk with 208220 reverted and the same plus your WIP patch on insn-recog.ii
(on a SNB box):
vanilla
real 2m11.855s
user 2m9.917s
sys 0m1.479s

my
real 2m11.760s
user 2m9.823s
sys 0m1.449s

208220revert
real 2m11.632s
user 2m9.847s
sys 0m1.310s

lxo
real 2m12.491s
user 2m10.699s
sys 0m1.304s

so I guess all the changes are pretty much in the noise when the r208221 change
is in, so we might as well just revert r208220 and do nothing else.

[Bug debug/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245

[aoliva at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381

--- Comment #9 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Author: aoliva
Date: Thu Mar  6 07:04:47 2014
New Revision: 208361

URL: http://gcc.gnu.org/viewcvs?rev=208361&root=gcc&view=rev
Log:
PR debug/60381
Revert:
2014-02-28  Alexandre Oliva <aoliva@redhat.com>
PR debug/59992
* cselib.c (remove_useless_values): Skip to avoid quadratic
behavior if the condition moved from...
(cselib_process_insn): ... here holds.

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

[Bug debug/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245

[aoliva at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |UNCONFIRMED
     Ever confirmed|1                           |0

--- Comment #10 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Fixed by reversal of the faulty patch.  We should eventually tweak
vt_add_function_parameter so as to preserve VALUEs recursively, adding
dataflow_set binds for all of them, like we do for top-level MEMs (and their
addresses) and REGs.  We'll probably have to work harder to preserve these
intermediate equivalences in spite of the removal of the base VALUEs when their
REGs are reset and their loc lists become empty.  Just marking the VALUEs as
preserved won't stop that, and when we get to preserving them in the separate
preserved table, they'll be gone already.  Regarding preserved values as
non-useless will likely cause lots of values to be preserved that currently
aren't.  This may very well get us better debug info, but I'm not sure at what
cost.

[Bug debug/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245

[aoliva at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381

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

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

--- Comment #11 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Oops, really fixed now ;-)