Bug 59536 - [4.9 regression] internal compiler error: in cselib_record_set, at cselib.c:2376 breaks m68k-linux bootstrap
Summary: [4.9 regression] internal compiler error: in cselib_record_set, at cselib.c:2...
Status: RESOLVED DUPLICATE of bug 52306
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.9.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-17 11:20 UTC by Mikael Pettersson
Modified: 2013-12-19 09:02 UTC (History)
3 users (show)

See Also:
Host:
Target: m68k-*-*
Build:
Known to work:
Known to fail:
Last reconfirmed: 2013-12-18 00:00:00


Attachments
Preprocessed source (163.75 KB, text/plain)
2013-12-18 13:52 UTC, Andreas Schwab
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mikael Pettersson 2013-12-17 11:20:13 UTC
Attempting to bootstrap gcc-4.9-20131215 (r206004) on m68k-linux fails with:

/mnt/scratch/objdir49/./prev-gcc/xg++ -B/mnt/scratch/objdir49/./prev-gcc/ -B/mnt/scratch/install49/m68k-unknown-linux-gnu/bin/ -nostdinc++ -B/mnt/scratch/objdir49/prev-m68k-unknown-linux-gnu/libstdc++-v3/src/.libs -B/mnt/scratch/objdir49/prev-m68k-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/mnt/scratch/objdir49/prev-m68k-unknown-linux-gnu/libstdc++-v3/include/m68k-unknown-linux-gnu -I/mnt/scratch/objdir49/prev-m68k-unknown-linux-gnu/libstdc++-v3/include -I/mnt/scratch/gcc-4.9-20131215/libstdc++-v3/libsupc++ -L/mnt/scratch/objdir49/prev-m68k-unknown-linux-gnu/libstdc++-v3/src/.libs -L/mnt/scratch/objdir49/prev-m68k-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c   -g -O2 -gtoggle -DIN_GCC    -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror   -DHAVE_CONFIG_H -I. -I. -I/mnt/scratch/gcc-4.9-20131215/gcc -I/mnt/scratch/gcc-4.9-20131215/gcc/. -I/mnt/scratch/gcc-4.9-20131215/gcc/../include -I/mnt/scratch/gcc-4.9-20131215/gcc/../libcpp/include  -I/mnt/scratch/gcc-4.9-20131215/gcc/../libdecnumber -I/mnt/scratch/gcc-4.9-20131215/gcc/../libdecnumber/dpd -I../libdecnumber -I/mnt/scratch/gcc-4.9-20131215/gcc/../libbacktrace    -o tree-loop-distribution.o -MT tree-loop-distribution.o -MMD -MP -MF ./.deps/tree-loop-distribution.TPo /mnt/scratch/gcc-4.9-20131215/gcc/tree-loop-distribution.c
/mnt/scratch/gcc-4.9-20131215/gcc/tree-loop-distribution.c: In member function 'virtual unsigned int {anonymous}::pass_loop_distribution::execute()':
/mnt/scratch/gcc-4.9-20131215/gcc/tree-loop-distribution.c:1826:63: internal compiler error: in cselib_record_set, at cselib.c:2376
   unsigned int execute () { return tree_loop_distribution (); }
                                                               ^
0x80260fa7 cselib_record_set
        /mnt/scratch/gcc-4.9-20131215/gcc/cselib.c:2376
0x80261715 cselib_record_sets
        /mnt/scratch/gcc-4.9-20131215/gcc/cselib.c:2593
0x8026195b cselib_process_insn(rtx_def*)
        /mnt/scratch/gcc-4.9-20131215/gcc/cselib.c:2668
0x804d77b1 reload_cse_regs_1
        /mnt/scratch/gcc-4.9-20131215/gcc/postreload.c:222
0x804d731f reload_cse_regs
        /mnt/scratch/gcc-4.9-20131215/gcc/postreload.c:68
0x804dc70d rest_of_handle_postreload
        /mnt/scratch/gcc-4.9-20131215/gcc/postreload.c:2332
0x804dc789 execute
        /mnt/scratch/gcc-4.9-20131215/gcc/postreload.c:2368
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]: *** [tree-loop-distribution.o] Error 1
make[3]: Leaving directory `/mnt/scratch/objdir49/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/mnt/scratch/objdir49'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/mnt/scratch/objdir49'
make: *** [bootstrap] Error 2

The previous weekly snapshot, gcc-4.9-20131208, bootstrapped fine.

Configured as:
/mnt/scratch/gcc-4.9-20131215/configure --prefix=/mnt/scratch/install49 --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-linker-build-id --enable-languages=c,c++ --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --disable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --disable-sjlj-exceptions --disable-libmudflap --disable-plugin --disable-lto --disable-multilib
Comment 1 Andreas Schwab 2013-12-18 13:44:50 UTC
Between r205951 and r205984.
Comment 2 Andreas Schwab 2013-12-18 13:52:51 UTC
Created attachment 31468 [details]
Preprocessed source
Comment 3 Andreas Schwab 2013-12-18 14:29:11 UTC
c03531c413c501b0033ea2ea3f030cd7e6f66320 is the first bad commit
commit c03531c413c501b0033ea2ea3f030cd7e6f66320
Author: amker <amker@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Fri Dec 13 11:36:22 2013 +0000

        PR tree-optimization/58296
        PR tree-optimization/41488
        * tree-scalar-evolution.c: Include necessary header files.
        (simplify_peeled_chrec): New function.
        (analyze_evolution_in_loop): New static variable.
        Call simplify_peeled_chrec.
        * tree-ssa-loop-ivopts.c (mark_bivs): Don't mark peeled IV as biv.
        (add_old_iv_candidates): Don't add candidate for peeled IV.
        * tree-affine.h (aff_combination_zero_p): New function.
    
        PR tree-optimization/58296
        PR tree-optimization/41488
        * gcc.dg/tree-ssa/scev-7.c: New test.
        * gcc.dg/pr41488.c: New test.
        * g++.dg/pr59445.C: New test.
    
    
    
    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@205959 138bc75d-0d04-0410-961f-82ee72b054a4
Comment 4 Jakub Jelinek 2013-12-18 15:43:54 UTC
Sounds just like uncovering a latent bug in cselib?
Comment 5 bin.cheng 2013-12-19 01:11:01 UTC
I will have a look.
Thanks.
Comment 6 bin.cheng 2013-12-19 02:18:17 UTC
Hi,
Sorry I don't have m68k environment to do the bootstrap, could anyone help dump "-fdump-tree-all-details -fdump-rtl-all-slim" with and without the patch for me?  Otherwise I have to revert the patch and hold it for future.

Hi Jakub, should I revert the patch for now?

Thanks.
Comment 7 H.J. Lu 2013-12-19 04:16:09 UTC
(In reply to bin.cheng from comment #6)
> Hi,
> Sorry I don't have m68k environment to do the bootstrap, could anyone help
> dump "-fdump-tree-all-details -fdump-rtl-all-slim" with and without the
> patch for me?  Otherwise I have to revert the patch and hold it for future.
> 

Can't you use cross compiler on preprocessed input to debug it?
Comment 8 bin.cheng 2013-12-19 05:20:43 UTC
(In reply to Andreas Schwab from comment #1)
> Between r205951 and r205984.

(In reply to H.J. Lu from comment #7)
> (In reply to bin.cheng from comment #6)
> > Hi,
> > Sorry I don't have m68k environment to do the bootstrap, could anyone help
> > dump "-fdump-tree-all-details -fdump-rtl-all-slim" with and without the
> > patch for me?  Otherwise I have to revert the patch and hold it for future.
> > 
> 
> Can't you use cross compiler on preprocessed input to debug it?

The bare-metal tool seems not handle the preprocessed file correctly, so am trying to build cross linux tools.  Unfortunately, cross-ng only supports uclinux for m68k.  Given that I am not familiar with m68k-linux, so I am having difficulty in enabling one for now.
Comment 9 bin.cheng 2013-12-19 06:03:54 UTC
Turns out my crossed bare-metal tool works after deleting all preprocessed "# xxx file" lines, but why these lines matter?
Comment 10 bin.cheng 2013-12-19 08:26:54 UTC
The offending loop before IVOPT is like:

  <bb 350>:
  # var_index_1889 = PHI <1(924), var_index_983(923)>
  # var_index.250_1269 = PHI <1(924), var_index.250_1959(923)>
  if (var_index.250_1269 < _1237)
    goto <bb 351>;
  else
    goto <bb 885>;

  <bb 351>:
  loopi_952 = MEM[(const struct vec *)pretmp_2270].m_vecdata[var_index.250_1269];
  _947 = loopi_952->num;
  if (_947 == pretmp_2268)
    goto <bb 352>;
  else
    goto <bb 923>;

  <bb 923>:
  var_index_983 = var_index_1889 + 1;
  var_index.250_1959 = (unsigned int) var_index_983;
  goto <bb 350>;

  <bb 924>:
  goto <bb 350>;

The patch can recognize var_index.250_1269 is an iv with {1, 1}_loop, thus rewriting the loop into:


  <bb 350>:
  # var_index_1889 = PHI <1(924), var_index_983(923)>
  # ivtmp.1067_1968 = PHI <ivtmp.1067_696(924), ivtmp.1067_884(923)>
  var_index.250_1269 = (unsigned int) var_index_1889;
  if (var_index_1889 != _958)
    goto <bb 351>;
  else
    goto <bb 885>;

  <bb 351>:
  _111 = (void *) ivtmp.1067_1968;
  loopi_952 = MEM[base: _111, offset: 0B];
  ivtmp.1067_884 = ivtmp.1067_1968 + 4;
  _947 = loopi_952->num;
  if (_947 == pretmp_2268)
    goto <bb 352>;
  else
    goto <bb 923>;

  <bb 923>:
  var_index_983 = var_index_1889 + 1;
  goto <bb 350>;

  <bb 924>:
  _1542 = pretmp_2270 + 12;
  ivtmp.1067_696 = (unsigned int) _1542;
  _958 = (int) _1237;
  goto <bb 350>;

The transformation looks good and takes advantage of post-increment addressing mode for memory access "MEM[base: _111, offset: 0B]".
The loop is expanded into rtl like:
 4438: L4438:
 1814: NOTE_INSN_BASIC_BLOCK 352
 1815: r626:SI=r817:SI
 1816: cc0=cmp(r817:SI,r492:SI)
 1817: pc={(cc0==0)?L4244:pc}
      REG_BR_PROB 900
 1818: NOTE_INSN_BASIC_BLOCK 353
 1819: r490:SI=[r829:SI]
 1820: r829:SI=r829:SI+0x4
 1821: cc0=cmp([r490:SI],r864:SI)
 1822: pc={(cc0!=0)?L4435:pc}
       ...
 4435: L4435:
 4436: NOTE_INSN_BASIC_BLOCK 952
 4437: r817:SI=r817:SI+0x1
 4439: pc=L4438
 4440: barrier
 4441: L4441:
 4442: NOTE_INSN_BASIC_BLOCK 953
 4443: r829:SI=r865:SI+0xc
 4444: r492:SI=r621:SI
   44: r817:SI=0x1
 4445: pc=L4438

Then instruction 1819/1820 are combined by auto-inc-dec pass into:

 1819: r490:SI=[r829:SI++]
      REG_INC r829:SI
 1821: cc0=cmp([r490:SI],r864:SI)
      REG_DEAD r490:SI
 1822: pc={(cc0!=0)?L4435:pc}
      REG_BR_PROB 9550

Problem comes from reload which puts both r490 and r829 into %a0 (reg 8?) and generates below code:
 1819: %a0:SI=[%a0:SI++]
      REG_INC %a0:SI
 1821: cc0=cmp([%a0:SI],%d2:SI)
 1822: pc={(cc0!=0)?L4435:pc}
      REG_BR_PROB 9550

Insn 1819 is now bogus and causes assertion in cselib.

In IRA, there are dumps like:
      Popping a1119(r829,l0: a921(r829,l17))  -- assign reg 8
      Popping a1122(r1111,l0: a924(r1111,l17))  -- assign reg 8
      Popping a1120(r494,l0: a922(r494,l17))  -- assign reg 9
      Popping a1147(r1054,l0: a1006(r1054,l15))  -- assign reg 8
      Popping a1157(r490,l0: a1124(r490,l17: a959(r490,l18)))  -- assign reg 2

But in reload, there are dumps:

Reloads for insn # 1819
Reload 0: reload_in (SI) = (post_inc:SI (reg:SI 829 [ ivtmp.1067 ]))
	reload_out (SI) = (post_inc:SI (reg:SI 829 [ ivtmp.1067 ]))
	ADDR_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 1), inc by 4
	reload_in_reg: (post_inc:SI (reg:SI 829 [ ivtmp.1067 ]))
	reload_reg_rtx: (reg:SI 8 %a0)
Reload 1: reload_out (SI) = (reg/v/f:SI 490 [ loopi ])
	GENERAL_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
	reload_out_reg: (reg/v/f:SI 490 [ loopi ])
Reload 2: reload_in (SI) = (mem/f:SI (post_inc:SI (reg:SI 829 [ ivtmp.1067 ])) [4 MEM[base: _111, offset: 0B]+0 S4 A16])
	GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1), optional
	reload_in_reg: (mem/f:SI (post_inc:SI (reg:SI 829 [ ivtmp.1067 ])) [4 MEM[base: _111, offset: 0B]+0 S4 A16])


So I am not sure if there are some bugs in reload for m68k, or ivopt is doing something very trick and wrong?

Thanks,
bin
Comment 11 bin.cheng 2013-12-19 08:34:31 UTC
Add reload maintainer for some suggestions.
Comment 12 Andreas Schwab 2013-12-19 08:40:52 UTC
-fno-auto-inc-dec avoids the crash.  Dup of #52306?
Comment 13 bin.cheng 2013-12-19 08:49:43 UTC
(In reply to Andreas Schwab from comment #12)
> -fno-auto-inc-dec avoids the crash.  Dup of #52306?

It looks like, AFAICT.  Only this time it's blocking bootstrap :(
Comment 14 Andreas Schwab 2013-12-19 09:02:19 UTC
As confirmed by comment 9 there.

*** This bug has been marked as a duplicate of bug 52306 ***