[Bug middle-end/59350] New: [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[Bug middle-end/59350] New: [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[dimhen at gmail dot com]

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

            Bug ID: 59350
           Summary: [4.9 regression] ICE: in vt_expand_var_loc_chain, at
                    var-tracking.c:8212
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dimhen at gmail dot com

Fedora 19 x86_64

r205459 PASS
r205527 FAIL

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/usr/local/gcc_current --with-multilib-list=m64
--enable-checking=yes,df,fold,rtl,tree --enable-languages=c,c++,lto
--enable-plugin --with-tune=native --with-arch=native
--enable-version-specific-runtime-libs
Thread model: posix
gcc version 4.9.0 20131129 (experimental) [trunk revision 205527] (GCC) 

$ cat x.ii
struct A {
  int LLVMTy;
} a;
class B;
class C {
  B *Node;
  int ResNo;
public:
  A m_fn1() const;
  void m_fn2() { m_fn1(); }
};
class D {
  void *Ptr;
  int IROrder;
};
class F {
public:
  void m_fn1(int, D, A, C);
};
void fn1();
class B {
  int NumValues;
public:
  void m_fn1(int) { NumValues ? static_cast<void>(0) : fn1(); }
};


$ g++ -fpreprocessed -O1 -g -c x.ii -o x.o
x.ii: In function 'void fn2(C)':
x.ii:31:1: internal compiler error: in vt_expand_var_loc_chain, at
var-tracking.c:8212
 }
 ^
0xf2e719 vt_expand_var_loc_chain
    /home/dimhen/src/gcc_current/gcc/var-tracking.c:8212
0xf2e719 vt_expand_loc_callback
    /home/dimhen/src/gcc_current/gcc/var-tracking.c:8408
0x93d7b7 cselib_expand_value_rtx_1
    /home/dimhen/src/gcc_current/gcc/cselib.c:1684
0x93e6de cselib_expand_value_rtx_cb(rtx_def*, bitmap_head_def*, int, rtx_def*
(*)(rtx_def*, bitmap_head_def*, int, void*), void*)
    /home/dimhen/src/gcc_current/gcc/cselib.c:1531
0xf2d9fc vt_expand_loc_callback
    /home/dimhen/src/gcc_current/gcc/var-tracking.c:8344
0x93d8a9 cselib_expand_value_rtx_1
    /home/dimhen/src/gcc_current/gcc/cselib.c:1649
0x93e6de cselib_expand_value_rtx_cb(rtx_def*, bitmap_head_def*, int, rtx_def*
(*)(rtx_def*, bitmap_head_def*, int, void*), void*)
    /home/dimhen/src/gcc_current/gcc/cselib.c:1531
0xf2de17 vt_expand_var_loc_chain
    /home/dimhen/src/gcc_current/gcc/var-tracking.c:8246
0xf2de17 vt_expand_loc_callback
    /home/dimhen/src/gcc_current/gcc/var-tracking.c:8408
0x93d7b7 cselib_expand_value_rtx_1
    /home/dimhen/src/gcc_current/gcc/cselib.c:1684
0x93e6de cselib_expand_value_rtx_cb(rtx_def*, bitmap_head_def*, int, rtx_def*
(*)(rtx_def*, bitmap_head_def*, int, void*), void*)
    /home/dimhen/src/gcc_current/gcc/cselib.c:1531
0xf2de17 vt_expand_var_loc_chain
    /home/dimhen/src/gcc_current/gcc/var-tracking.c:8246
0xf2de17 vt_expand_loc_callback
    /home/dimhen/src/gcc_current/gcc/var-tracking.c:8408
0x93e6de cselib_expand_value_rtx_cb(rtx_def*, bitmap_head_def*, int, rtx_def*
(*)(rtx_def*, bitmap_head_def*, int, void*), void*)
    /home/dimhen/src/gcc_current/gcc/cselib.c:1531
0xf2de17 vt_expand_var_loc_chain
    /home/dimhen/src/gcc_current/gcc/var-tracking.c:8246
0xf2de17 vt_expand_loc_callback
    /home/dimhen/src/gcc_current/gcc/var-tracking.c:8408
0x93d7b7 cselib_expand_value_rtx_1
    /home/dimhen/src/gcc_current/gcc/cselib.c:1684
0x93e6de cselib_expand_value_rtx_cb(rtx_def*, bitmap_head_def*, int, rtx_def*
(*)(rtx_def*, bitmap_head_def*, int, void*), void*)
    /home/dimhen/src/gcc_current/gcc/cselib.c:1531
0xf22658 vt_expand_var_loc_chain
    /home/dimhen/src/gcc_current/gcc/var-tracking.c:8246
0xf22658 vt_expand_1pvar
    /home/dimhen/src/gcc_current/gcc/var-tracking.c:8521
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.

[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-*-*
   Target Milestone|---                         |4.9.0

[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[rmansfield at qnx dot com]

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

Ryan Mansfield <rmansfield at qnx dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rmansfield at qnx dot com

--- Comment #1 from Ryan Mansfield <rmansfield at qnx dot com> ---
Also seen on an armeabi target.

[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[dimhen at gmail dot com]

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

--- Comment #2 from Dmitry G. Dyachenko <dimhen at gmail dot com> ---
enough --enable-checking=yes

[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Strange, can't reproduce.  You are using --with-arch=native --with=native, what
exactly it expands to?

[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[dimhen at gmail dot com]

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

--- Comment #5 from Dmitry G. Dyachenko <dimhen at gmail dot com> ---
(In reply to Jakub Jelinek from comment #4)
> Strange, can't reproduce.  You are using --with-arch=native --with=native,
> what exactly it expands to?

[dimhen@dim PR59350]$ ~/bin/gcc_205461_yes/bin/g++ -v -fpreprocessed -O1 -g -c
x.ii -o x.o
Using built-in specs.
COLLECT_GCC=/home/dimhen/bin/gcc_205461_yes/bin/g++
Target: x86_64-unknown-linux-gnu
Configured with: /home/dimhen/src/gcc_current_205461/configure
--prefix=/usr/local/gcc_current --with-multilib-list=m64 --enable-checking=yes
--enable-languages=c,c++,lto --enable-plugin --with-tune=native
--with-arch=native --enable-version-specific-runtime-libs
Thread model: posix
gcc version 4.9.0 20131127 (experimental) [trunk revision 205461] (GCC) 
COLLECT_GCC_OPTIONS='-v' '-fpreprocessed' '-O1' '-g' '-c' '-o' 'x.o'
'-shared-libgcc' '-mtune=native' '-march=native'

/home/dimhen/bin/gcc_205461_yes/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1plus
-fpreprocessed x.ii -march=corei7 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3
-mno-sse4a -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt -mno-abm
-mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx
-mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c
-mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt
-mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf --param l1-cache-size=32
--param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=corei7 -quiet
-dumpbase x.ii -auxbase-strip x.o -g -O1 -version -fpreprocessed -o
/tmp/ccQJHhK6.s
GNU C++ (GCC) version 4.9.0 20131127 (experimental) [trunk revision 205461]
(x86_64-unknown-linux-gnu)
    compiled by GNU C version 4.9.0 20131127 (experimental) [trunk revision
205461], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.9.0 20131127 (experimental) [trunk revision 205461]
(x86_64-unknown-linux-gnu)
    compiled by GNU C version 4.9.0 20131127 (experimental) [trunk revision
205461], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: e2018620b941388d06d586f5e1499b7d
x.ii: In function 'void fn2(C)':
x.ii:31:1: internal compiler error: in vt_expand_var_loc_chain, at
var-tracking.c:8212
[...]

[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Still can't reproduce.

[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[dimhen at gmail dot com]

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

--- Comment #8 from Dmitry G. Dyachenko <dimhen at gmail dot com> ---
(In reply to Jakub Jelinek from comment #6)
> Still can't reproduce.

PASS
/home/dimhen/bin/gcc_205461_yes/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1plus
-fpreprocessed x.ii -march=corei7 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3
-mno-sse4a -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt -mno-abm
-mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx
-mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c
-mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt
-mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf --param l1-cache-size=32
--param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=corei7 -quiet
-dumpbase x.ii -auxbase-strip x.o -g -O1 -version -fpreprocessed -o
/tmp/ccbEj5NK.s

FAIL
prev.cmd -march=corei7 -mtune=corei7

valgrind --tool=memcheck --track-origins=yes
/home/dimhen/bin/gcc_205461_yes/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1plus
-fpreprocessed x.ii -march=corei7 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3
-mno-sse4a -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt -mno-abm
-mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx
-mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c
-mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt
-mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf --param l1-cache-size=32
--param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=corei7 -quiet
-dumpbase x.ii -auxbase-strip x.o -g -O1 -version -fpreprocessed -o
/tmp/ccbEj5NK.s

[...]
==575== Conditional jump or move depends on uninitialised value(s)
==575==    at 0x1047E6E: register_active_defs(df_ref_d**) (sparseset.h:147)
==575==    by 0x1047F02: update_df_init(rtx_def*, rtx_def*) [clone .isra.14]
(fwprop.c:892)
==575==    by 0x599FD3: try_fwprop_subst(df_ref_d*, rtx_def**, rtx_def*,
rtx_def*, bool) (fwprop.c:960)
==575==    by 0x10489E3: forward_propagate_into(df_ref_d*) (fwprop.c:1340)
==575==    by 0x10490B7: (anonymous namespace)::pass_rtl_fwprop::execute()
(fwprop.c:1477)
==575==    by 0xAF9149: execute_one_pass(opt_pass*) (passes.c:2215)
==575==    by 0xAF93F5: execute_pass_list(opt_pass*) (passes.c:2268)
==575==    by 0xAF9407: execute_pass_list(opt_pass*) (passes.c:2269)
==575==    by 0x88B058: expand_function(cgraph_node*) (cgraphunit.c:1763)
==575==    by 0x88D05F: compile() (cgraphunit.c:1868)
==575==    by 0x88D6B4: finalize_compilation_unit() (cgraphunit.c:2280)
==575==    by 0x6893A6: cp_write_global_declarations() (decl2.c:4431)
==575==  Uninitialised value was created by a heap allocation
==575==    at 0x4A06B2D: malloc (vg_replace_malloc.c:291)
==575==    by 0x1163187: xmalloc (xmalloc.c:147)
==575==    by 0xB8CEA4: sparseset_alloc(unsigned long) (sparseset.c:33)
==575==    by 0x1047932: fwprop_init() (fwprop.c:1421)
==575==    by 0x104902A: (anonymous namespace)::pass_rtl_fwprop::execute()
(fwprop.c:1461)
==575==    by 0xAF9149: execute_one_pass(opt_pass*) (passes.c:2215)
==575==    by 0xAF93F5: execute_pass_list(opt_pass*) (passes.c:2268)
==575==    by 0xAF9407: execute_pass_list(opt_pass*) (passes.c:2269)
==575==    by 0x88B058: expand_function(cgraph_node*) (cgraphunit.c:1763)
==575==    by 0x88D05F: compile() (cgraphunit.c:1868)
==575==    by 0x88D6B4: finalize_compilation_unit() (cgraphunit.c:2280)
==575==    by 0x6893A6: cp_write_global_declarations() (decl2.c:4431)
[..]
 ERROR SUMMARY: 130 errors from 38 contexts (suppressed: 0 from 0)

[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[dimhen at gmail dot com]

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

--- Comment #7 from Dmitry G. Dyachenko <dimhen at gmail dot com> ---
Created attachment 31409
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31409&action=edit
valgrind' log

[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[rmansfield at qnx dot com]

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

--- Comment #9 from Ryan Mansfield <rmansfield at qnx dot com> ---
Created attachment 31410
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31410&action=edit
arm-eabi testcase

I haven't been able to reproduce with the inline testcase either. But I can
still consistently repoduce ICE with the attached testcase (not fully reduced)

gcc version 4.9.0 20131207 (experimental) [trunk revision 205782] (GCC) 

~/gnu/gcc/trunk/arm-eabi/gcc$ ./xgcc -B. -Os ~/ice.i  -c -g
/home/ryan/ice.i: In function 'uDNS_ReceiveMsg':
/home/ryan/ice.i:80:1: internal compiler error: in vt_expand_var_loc_chain, at
var-tracking.c:8212
 }
 ^
0xbb0353 vt_expand_var_loc_chain
    ../../gcc/var-tracking.c:8212
0xbb0353 vt_expand_loc_callback
    ../../gcc/var-tracking.c:8408
0x64cef7 cselib_expand_value_rtx_1
    ../../gcc/cselib.c:1684
0x64e31e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head_def*, int, rtx_def*
(*)(rtx_def*, bitmap_head_def*, int, void*), void*)
    ../../gcc/cselib.c:1531
0xbaf77a vt_expand_loc_callback
    ../../gcc/var-tracking.c:8344
0x64ce31 cselib_expand_value_rtx_1
    ../../gcc/cselib.c:1649
0x64e31e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head_def*, int, rtx_def*
(*)(rtx_def*, bitmap_head_def*, int, void*), void*)
    ../../gcc/cselib.c:1531
0xbafc28 vt_expand_var_loc_chain
    ../../gcc/var-tracking.c:8246
0xbafc28 vt_expand_loc_callback
    ../../gcc/var-tracking.c:8408
0x64cef7 cselib_expand_value_rtx_1
    ../../gcc/cselib.c:1684
0x64e31e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head_def*, int, rtx_def*
(*)(rtx_def*, bitmap_head_def*, int, void*), void*)
    ../../gcc/cselib.c:1531
0xba941c vt_expand_loc
    ../../gcc/var-tracking.c:8498
0xbbc0c3 emit_notes_in_bb
    ../../gcc/var-tracking.c:9094
0xbbc0c3 vt_emit_notes
    ../../gcc/var-tracking.c:9431
0xbbcb91 variable_tracking_main_1
    ../../gcc/var-tracking.c:10292
0xbbcb91 variable_tracking_main
    ../../gcc/var-tracking.c:10306
0xbbcb91 execute
    ../../gcc/var-tracking.c:10347
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.

[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[dimhen at gmail dot com]

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

--- Comment #10 from Dmitry G. Dyachenko <dimhen at gmail dot com> ---
(In reply to Dmitry G. Dyachenko from comment #8)
valgrind' messages looks unrelated to ICE.
I rebuild r205461 with memset(set, {0,0x42}, n_bytes) instead of
VALGRIND_DISCARD (VALGRIND_MAKE_MEM_DEFINED (set, n_bytes))
in sparseset.c::sparseset_alloc() without luck.

But I see one strangeness: according to /proc/cpuinfo I have Intel(R) Core
i5/760. Gcc is build with arch/tune=native, but while running selects
tune/arch=i7.

[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[dimhen at gmail dot com]

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

--- Comment #11 from Dmitry G. Dyachenko <dimhen at gmail dot com> ---
(In reply to Ryan Mansfield from comment #9)
> Created attachment 31410 [details]
> arm-eabi testcase
> 
> I haven't been able to reproduce with the inline testcase either. But I can
> still consistently repoduce ICE with the attached testcase (not fully
> reduced)
PASS for me (x86_64) as '-Os -g' and '-O3 -g' for some versions in
[202775..205759]

[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-12-13
     Ever confirmed|0                           |1

--- Comment #12 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
I can reproduce on the ARM, it was introduced by r205461.

[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|ebotcazou at gcc dot gnu.org       |
           Assignee|unassigned at gcc dot gnu.org      |ebotcazou at gcc dot gnu.org

--- Comment #13 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Looking into it.

[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |rtl-optimization

--- Comment #14 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Recategorizing.

[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[ebotcazou at gcc dot gnu.org]

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

--- Comment #15 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Author: ebotcazou
Date: Sat Dec 14 15:24:58 2013
New Revision: 205986

URL: http://gcc.gnu.org/viewcvs?rev=205986&root=gcc&view=rev
Log:
    * var-tracking.c (add_stores): Fix oversight in latest commit.

Added:
    trunk/gcc/testsuite/gcc.dg/pr59350.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/var-tracking.c

[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|x86_64-*-*                  |
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #16 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Reopen if this still fails on x86-64.

[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[dimhen at gmail dot com]

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

Dmitry G. Dyachenko <dimhen at gmail dot com> changed:

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

--- Comment #17 from Dmitry G. Dyachenko <dimhen at gmail dot com> ---
(In reply to Eric Botcazou from comment #16)
> Reopen if this still fails on x86-64.

r205987 FAIl for me. Only linenumbers in var-tracking.c are increased by 1.

Summary:
1) x86_64 testcase from PR start FAIL for me at r205461
2) arm-eabi testcase from c#9 PASS for me
3) for me
-- PASS -O0 -g
-- FAIL -O1 -g
-- PASS -O1 -g w/o tune/arch=corei7
-- PASS -O1 -g -fno-split-wide-types

-- enable-checking=yes,df,fold,rtl,tree not report anything
-- enable-checking=yes is enough to trigger ICE
-- valgrind not found smth unusual
-- gcc is configured with arch/tune=native
-- while running gcc selects arch/tune=corei7
-- I have 16Gb RAM, Fedora 19, ld (not gold), four processors
cat /proc/cpuinfo
processor    : 0
vendor_id    : GenuineIntel
cpu family    : 6
model        : 30
model name    : Intel(R) Core(TM) i5 CPU         760  @ 2.80GHz
stepping    : 5
microcode    : 0x6
cpu MHz        : 2808.871
cache size    : 8192 KB
physical id    : 0
siblings    : 4
core id        : 0
cpu cores    : 4
apicid        : 0
initial apicid    : 0
fpu        : yes
fpu_exception    : yes
cpuid level    : 11
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc
aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm
sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips    : 5617.74
clflush size    : 64
cache_alignment    : 64
address sizes    : 36 bits physical, 48 bits virtual
power management:

[...]

[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |WAITING

--- Comment #18 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
I cannot reproduce with --enable-checking=yes,rtl.  Are you saying that the ICE
depends on whether 'rtl' is present in the checking options?

[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[dimhen at gmail dot com]

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

--- Comment #19 from Dmitry G. Dyachenko <dimhen at gmail dot com> ---
(In reply to Eric Botcazou from comment #18)
> I cannot reproduce with --enable-checking=yes,rtl.  Are you saying that the
> ICE depends on whether 'rtl' is present in the checking options?

Sorry for unclear description.

1) I have ICE with --enable-checking=yes
2) I have ICE with --enable-checking=yes,df,fold,rtl,tree
and additional checks prints nothing additional.

[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[dimhen at gmail dot com]

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

--- Comment #20 from Dmitry G. Dyachenko <dimhen at gmail dot com> ---
may be r205461 trigger latent bug?
There are no ICE with -fno-split-wide-types or without arch/tune=corei7

I can run gdb if it'll usefull

[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[ebotcazou at gcc dot gnu.org]

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

--- Comment #21 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
What I don't get in that in comment 8 there is a command line with a PASS and
then FAIL has "prev.cmd -march=corei7 -mtune=corei7" but the two options are
already in the former command line...

Could you post only the command line passed to cc1plus that FAILs?

[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[dimhen at gmail dot com]

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

--- Comment #22 from Dmitry G. Dyachenko <dimhen at gmail dot com> ---
(In reply to Eric Botcazou from comment #21)
> What I don't get in that in comment 8 there is a command line with a PASS
> and then FAIL has "prev.cmd -march=corei7 -mtune=corei7" but the two options
> are already in the former command line...
> 
> Could you post only the command line passed to cc1plus that FAILs?

PR59350]$
/home/dimhen/bin/gcc_205461_yes/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1plus
-fpreprocessed x.ii -march=corei7 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3
-mno-sse4a -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt -mno-abm
-mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx
-mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c
-mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt
-mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf --param l1-cache-size=32
--param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=corei7 -quiet
-dumpbase x.ii -auxbase-strip x.o -g -O1 -version -fpreprocessed -o
/tmp/ccbEj5NK.s
GNU C++ (GCC) version 4.9.0 20131127 (experimental) [trunk revision 205461]
(x86_64-unknown-linux-gnu)
    compiled by GNU C version 4.9.0 20131127 (experimental) [trunk revision
205461], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.9.0 20131127 (experimental) [trunk revision 205461]
(x86_64-unknown-linux-gnu)
    compiled by GNU C version 4.9.0 20131127 (experimental) [trunk revision
205461], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: e2018620b941388d06d586f5e1499b7d
x.ii: In function 'void fn2(C)':
x.ii:31:1: internal compiler error: in vt_expand_var_loc_chain, at
var-tracking.c:8212

[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[dimhen at gmail dot com]

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

--- Comment #23 from Dmitry G. Dyachenko <dimhen at gmail dot com> ---
(In reply to Eric Botcazou from comment #21)
> What I don't get in that in comment 8 there is a command line with a PASS
> and then FAIL has "prev.cmd -march=corei7 -mtune=corei7" but the two options
> are already in the former command line...
> 
> Could you post only the command line passed to cc1plus that FAILs?

Sorry. Press enter too quickly
current gcc now

PR59350]$
/usr/local/gcc_current/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1plus
-fpreprocessed x.ii -march=corei7 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3
-mno-sse4a -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt -mno-abm
-mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx
-mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c
-mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt
-mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf --param l1-cache-size=32
--param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=corei7 -quiet
-dumpbase x.ii -auxbase-strip x.o -g -O1 -version -fpreprocessed -o
/tmp/ccbEj5NK.s
GNU C++ (GCC) version 4.9.0 20131214 (experimental) [trunk revision 205989]
(x86_64-unknown-linux-gnu)
    compiled by GNU C version 4.9.0 20131214 (experimental) [trunk revision
205989], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.9.0 20131214 (experimental) [trunk revision 205989]
(x86_64-unknown-linux-gnu)
    compiled by GNU C version 4.9.0 20131214 (experimental) [trunk revision
205989], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 275b0946f15033889007099ffb561344
x.ii: In function 'void fn2(C)':
x.ii:31:1: internal compiler error: in vt_expand_var_loc_chain, at
var-tracking.c:8213

[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org
           Assignee|ebotcazou at gcc dot gnu.org       |unassigned at gcc dot gnu.org

--- Comment #24 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Still not reproducible here.

[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[dimhen at gmail dot com]

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

--- Comment #25 from Dmitry G. Dyachenko <dimhen at gmail dot com> ---
After reading http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01344.html about
corei7 tuning ("Corei7 tuning doesn't set -maccumulate-outgoing-args option by
default")

I check -maccumulate-outgoing-args and
saw "-O1 -g -maccumulate-outgoing-args" PASS

Sounds like the picture is consistant now
1) gcc uses corei7 tuning
2) corei7 tuning doesn't set -maccumulate-outgoing-args
3) -fno-split-wide-types changes arguments passing too

And:
FAIL: -O1 -g
PASS: -O1 -g without corei7 tuning
PASS: -O1 -g -maccumulate-outgoing-args
PASS: -O1 -g -fno-split-wide-types

2 questions:
1) why nobody can reproduce ICE
2) why r205461 trigger it

[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[dimhen at gmail dot com]

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

--- Comment #27 from Dmitry G. Dyachenko <dimhen at gmail dot com> ---
An other box with Fedora 18 / AMD Athlon I cant reproduce (r205515)

How do you think, what is the right way to go?
[I already tests RAM with memtest]
run 2 GDBs and search differences in control-flow?

[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

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

--- Comment #28 from ktkachov at gcc dot gnu.org ---
I'm seeing this on arm-none-eabi now as well:

FAIL: gcc.dg/pr59350.c (internal compiler error)
FAIL: gcc.dg/pr59350.c (test for excess errors)

$TOP/gcc/gcc/testsuite/gcc.dg/pr59350.c: In function 'uDNS_ReceiveMsg':
$TOP/gcc/gcc/testsuite/gcc.dg/pr59350.c:82:1: internal compiler error: in
vt_expand_var_loc_chain, at var-tracking.c:8212
0xc123cb vt_expand_var_loc_chain
        $TOP/gcc/gcc/var-tracking.c:8212
0xc123cb vt_expand_var_loc_chain
        $TOP/gcc/gcc/var-tracking.c:8190
0xc14a0a vt_expand_loc_callback
        $TOP/gcc/gcc/var-tracking.c:8408
0x6b54eb cselib_expand_value_rtx_1
        $TOP/gcc/gcc/cselib.c:1684
0x6b681e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
        $TOP/gcc/gcc/cselib.c:1531
0xc146a6 vt_expand_loc_callback
        $TOP/gcc/gcc/var-tracking.c:8344
0x6b5405 cselib_expand_value_rtx_1
        $TOP/gcc/gcc/cselib.c:1649
0x6b681e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
        $TOP/gcc/gcc/cselib.c:1531
0xc11f57 vt_expand_var_loc_chain
        $TOP/gcc/gcc/var-tracking.c:8246
0xc14a0a vt_expand_loc_callback
        $TOP/gcc/gcc/var-tracking.c:8408
0x6b54eb cselib_expand_value_rtx_1
        $TOP/gcc/gcc/cselib.c:1684
0x6b681e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
        $TOP/gcc/gcc/cselib.c:1531
0xc0dd9f vt_expand_loc
        $TOP/gcc/gcc/var-tracking.c:8498
0xc1e669 emit_notes_in_bb
        $TOP/gcc/gcc/var-tracking.c:9094
0xc1e669 vt_emit_notes
        $TOP/gcc/gcc/var-tracking.c:9431
0xc1f18f variable_tracking_main_1
        $TOP/gcc/gcc/var-tracking.c:10292
0xc1f18f variable_tracking_main()
        $TOP/gcc/gcc/var-tracking.c:10306
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.

[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[ebotcazou at gcc dot gnu.org]

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

--- Comment #29 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> I'm seeing this on arm-none-eabi now as well:
> 
> FAIL: gcc.dg/pr59350.c (internal compiler error)
> FAIL: gcc.dg/pr59350.c (test for excess errors)
> 
> $TOP/gcc/gcc/testsuite/gcc.dg/pr59350.c: In function 'uDNS_ReceiveMsg':
> $TOP/gcc/gcc/testsuite/gcc.dg/pr59350.c:82:1: internal compiler error: in
> vt_expand_var_loc_chain, at var-tracking.c:8212

The assertion is supposed to be at var-tracking.c:8213 after the patch.

[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[ktkachov at gcc dot gnu.org]

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

--- Comment #30 from ktkachov at gcc dot gnu.org ---
It seems I had some weird tree state. It passes on trunk after doing a clean
build.

[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[dcb314 at hotmail dot com]

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

--- Comment #31 from David Binderman <dcb314 at hotmail dot com> ---
Created attachment 31456
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31456&action=edit
C source code

[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[dcb314 at hotmail dot com]

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

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

--- Comment #32 from David Binderman <dcb314 at hotmail dot com> ---
Same error with gcc trunk, dated 20131215, for attached
source code.

Flags -O3 -g -fPIC -fstack-protector-strong required.

[dcb@zippy4 foundBugs]$ ../results/bin/gcc -c -O3 -g -fPIC
-fstack-protector-strong bug126.c
zprime.c: In function ‘zfactor’:
zprime.c:577:1: internal compiler error: in vt_expand_var_loc_chain, at
var-tracking.c:8213
0xd1b1d0 vt_expand_var_loc_chain
    ../../src/trunk/gcc/var-tracking.c:8213
0xd1b5c7 vt_expand_loc_callback
    ../../src/trunk/gcc/var-tracking.c:8409
0x6d44de cselib_expand_value_rtx_1
    ../../src/trunk/gcc/cselib.c:1684
0x6d44de cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
    ../../src/trunk/gcc/cselib.c:1531

...
>From gcc-bugs-return-437839-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Dec 17 13:08:15 2013
Return-Path: <gcc-bugs-return-437839-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10468 invoked by alias); 17 Dec 2013 13:08:15 -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 10421 invoked by uid 48); 17 Dec 2013 13:08:11 -0000
From: "rearnsha at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/59535] [4.9 regression] -Os code size regressions for Thumb1/Thumb2 with LRA
Date: Tue, 17 Dec 2013 13:08:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rearnsha 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: attachments.created
Message-ID: <bug-59535-4-KhO79eWVjW@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59535-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59535-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: 2013-12/txt/msg01494.txt.bz2
Content-length: 1705

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY535

--- Comment #6 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Created attachment 31457
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id1457&actioníit
Another testcase

Another testcase, but this one has some obvious examples of poor behaviour for
-Os.

In addtion to the options used on the previous case, this might need
-fno-strict-aliasing -fno-common -fomit-frame-pointer -fno-strength-reduce

Example one, spilling a value and then keeping a copy in a hard reg over a
call.

    mov    r5, r1          <= R1 copied to R5
    sub    sp, sp, #28
    str    r1, [sp, #8]    <= And spilled to the stack
    mov    r2, #12
    mov    r1, #0
    mov    r4, r0
    bl    memset
    mov    r3, #2
    mov    r2, r5          <= Could reload from the stack instead

Example two, use of multiple reloads to use high register:

    ldr    r3, [sp, #4]
    mov    ip, r3          <= Copying value into high register
    add    ip, ip, r5      <= Arithmetic
    mov    r3, ip          <= Copying result back to original register
    str    r3, [sp, #4]
    ldr    r3, [sp, #12]
    mov    ip, r3          <= And IP is dead anyway...

In this case,
    mov    ip, r3
    add    ip, ip, r5
    mov    r3, ip

can be replaced entirely with
    add    r3, r5
saving two completely unnecessary MOV instructions.

Third, related case,

    mov    r1, #12
    mov    ip, r1
    add    ip, ip, r4
    mov    r1, ip

Could be done either as
    mov    r1, #12
    add     r1, r4
    mov    ip, r1
or
    mov    r1, r4
    add    r1, #12
    mov    ip, r1

both saving one instruction, or even two if the value doesn't really need
copying to a high reg.

[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |ebotcazou at gcc dot gnu.org

--- Comment #33 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
OK, thanks for the testcase, which boils down to:

typedef struct
{
  void *v;
  int len;
  int sign;
} ZVALUE;

extern int pred (ZVALUE);

static unsigned long
small_factor (ZVALUE z)
{
  if (z.len > 0)
    return 0;

  return pred (z) ? -1 : 0;
}

unsigned long
zfactor (ZVALUE z)
{
  z.sign = 0;
  return small_factor (z);
}

eric@polaris:~/build/gcc/native> gcc/xgcc -Bgcc -S -O -g pr59350-2.c
pr59350-2.c: In function 'zfactor':
pr59350-2.c:24:1: internal compiler error: in vt_expand_var_loc_chain, at
var-tracking.c:8213
 }
 ^
0xd6d63c vt_expand_var_loc_chain
        /home/eric/svn/gcc/gcc/var-tracking.c:8213
0xd6d63c vt_expand_loc_callback
        /home/eric/svn/gcc/gcc/var-tracking.c:8409

[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[rguenth at gcc dot gnu.org]

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

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

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

[Bug rtl-optimization/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[dcb314 at hotmail dot com]

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

--- Comment #35 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to David Binderman from comment #32)
> Same error with gcc trunk, dated 20131215, for attached
> source code.
> 
> Flags -O3 -g -fPIC -fstack-protector-strong required.

Sorry, I forgot to mention for machine type x86_64 ( AMD Phenom).

[Bug debug/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[ebotcazou at gcc dot gnu.org]

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

--- Comment #37 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Author: ebotcazou
Date: Mon Jan  6 11:39:41 2014
New Revision: 206356

URL: http://gcc.gnu.org/viewcvs?rev=206356&root=gcc&view=rev
Log:
    PR debug/59350
    PR debug/59510
    * var-tracking.c (add_stores): Preserve the value of the source even if
    we don't record the store.

Added:
    trunk/gcc/testsuite/g++.dg/pr59510.C
    trunk/gcc/testsuite/gcc.dg/pr59350-2.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/pr59350.c
    trunk/gcc/var-tracking.c

[Bug debug/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

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

--- Comment #38 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Thanks for reporting the problem.

[Bug debug/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212

[dimhen at gmail dot com]

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

--- Comment #39 from Dmitry G. Dyachenko <dimhen at gmail dot com> ---
r206356 PASS for me all testcases (including my from c#0)

Thanks for fixing the problem.