[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[sje at gcc dot gnu.org]

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

--- Comment #20 from Steve Ellcey  ---
I have still not been able to reproduce this or understand what is happening.

Aurelien, could you try applying the patch that has been submitted for PR 69129
to see if that helps?  The failure modes for this bug and 69129 don't look the
same but I think both may be related to uninitialized memory usage and I can't
reproduce either one so I am hoping maybe they have the same root cause.

Patch for PR 69129:

https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01407.html

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

--- Comment #21 from Aurelien Jarno  ---
(In reply to Steve Ellcey from comment #20)
> I have still not been able to reproduce this or understand what is happening.
> 
> Aurelien, could you try applying the patch that has been submitted for PR
> 69129
> to see if that helps?  The failure modes for this bug and 69129 don't look
> the same but I think both may be related to uninitialized memory usage and I
> can't reproduce either one so I am hoping maybe they have the same root
> cause.
> 
> Patch for PR 69129:
> 
> https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01407.html

It happens I am not able to reproduce the problem given the problem has been
fixed in the meantime. It is actually the same bug than PR67355.

Sorry for not noticing that earlier, and thanks for your help debugging this
issue.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

Aurelien Jarno  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #22 from Aurelien Jarno  ---
This bug is a duplicate of PR67355

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

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[sje at gcc dot gnu.org]

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

--- Comment #18 from Steve Ellcey  ---
I think there is still a difference in our configurations.  If you add '-v' to
the compile line when compiling the test program what do you see?  Specifically
what does COLLECT_GCC_OPTIONS show?  Mine has:

COLLECT_GCC_OPTIONS='-c' '-O2' '-g' '-march=mips32r2' '-v' '-mllsc' '-mplt'
'-mips32r2' '-mno-shared' '-EL' '-mabi=32'

I suspect yours is different.  I have tried adding some other options like
-mabicalls and -mexplicit-relocs to get output that looks more like yours but I
haven't succeeded in getting an exact match.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

--- Comment #19 from Aurelien Jarno  ---
Please find below the output produced by gcc when compiling with -v

Reading specs from /home/aurel32/work/mips-gcc/build/./gcc/specs
COLLECT_GCC=/home/aurel32/work/mips-gcc/build/./gcc/xgcc
Target: mipsel-linux-gnu
Configured with: /home/aurel32/git/gcc/configure --enable-languages=c
--prefix=/usr --target=mipsel-linux-gnu
--includedir=/usr/mipsel-linux-gnu/include
Thread model: posix
gcc version 5.3.1 20151221 (GCC)
COLLECT_GCC_OPTIONS='-v' '-B' '/home/aurel32/work/mips-gcc/build/./gcc/' '-O2'
'-g' '-o' 'test.o' '-c' '-march=mips32r2' '-mllsc' '-mips32r2' '-mno-shared'
'-EL' '-mabi=32'
 /home/aurel32/work/mips-gcc/build/./gcc/cc1 -quiet -v -iprefix
/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/mipsel-linux-gnu/5.3.1/
-isystem /home/aurel32/work/mips-gcc/build/./gcc/include -isystem
/home/aurel32/work/mips-gcc/build/./gcc/include-fixed test.c -mel -quiet
-dumpbase test.c -march=mips32r2 -mllsc -mips32r2 -mno-shared -mabi=32
-auxbase-strip test.o -g -O2 -version -o /tmp/cc4pCfly.s
GNU C11 (GCC) version 5.3.1 20151221 (mipsel-linux-gnu)
compiled by GNU C version 5.3.1 20151207, GMP version 6.1.0, MPFR
version 3.1.3, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/mipsel-linux-gnu/5.3.1/include"
ignoring nonexistent directory
"/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/mipsel-linux-gnu/5.3.1/include-fixed"
ignoring nonexistent directory
"/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/mipsel-linux-gnu/5.3.1/../../../../mipsel-linux-gnu/sys-include"
ignoring nonexistent directory
"/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/mipsel-linux-gnu/5.3.1/../../../../mipsel-linux-gnu/include"
ignoring nonexistent directory
"/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/../../lib/gcc/mipsel-linux-gnu/5.3.1/include"
ignoring nonexistent directory
"/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/../../lib/gcc/mipsel-linux-gnu/5.3.1/include-fixed"
ignoring nonexistent directory
"/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/../../lib/gcc/mipsel-linux-gnu/5.3.1/../../../../mipsel-linux-gnu/sys-include"
ignoring nonexistent directory
"/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/../../lib/gcc/mipsel-linux-gnu/5.3.1/../../../../mipsel-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/aurel32/work/mips-gcc/build/./gcc/include
 /home/aurel32/work/mips-gcc/build/./gcc/include-fixed
End of search list.
GNU C11 (GCC) version 5.3.1 20151221 (mipsel-linux-gnu)
compiled by GNU C version 5.3.1 20151207, GMP version 6.1.0, MPFR
version 3.1.3, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e3226672ebc300cae5ef5d0d012ad534

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

--- Comment #17 from Aurelien Jarno  ---
Created attachment 37098
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37098=edit
output log with cselib.c patched

Please find attached the output with your cselib.c patch. Sorry for the delay.

If you want I can also try to setup a virtual machine image that can be used to
reproduce the problem.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[raj.khem at gmail dot com]

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

Khem Raj  changed:

   What|Removed |Added

 CC||raj.khem at gmail dot com

--- Comment #16 from Khem Raj  ---
I see this issue as well with OpenEmbedded cross compilers ( gcc 5.2 ) -g -O2
-march=mips32r2 is the combination that fails.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

--- Comment #14 from Aurelien Jarno  ---
Created attachment 36970
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36970=edit
Output log 2

Unfortunately it still fails, though the output log is now slightly different.
Please find it attached.

I have also tried to build this mipsel cross gcc using gcc 4.9 as the base
compiler, but it doesn't change the result.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[sje at gcc dot gnu.org]

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

--- Comment #15 from Steve Ellcey  ---
Created attachment 36978
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36978=edit
patch to put debug statements in cselib.c

I still cannot reproduce the failure.  I have built cross compilers on linux
with GCC 4.9 and GCC 5.2 and I have built the cross compiler in both 32 and 64
bit modes.

Here is a patch file to apply to cselib.c, Could you try applying it, building
GCC, running the test program, and sending me the output.  Maybe comparing the
output you get with what I get will help me understand what is going on.  This
patch includes the earlier changes I had suggested so you should remove those
before applying this patch or they will conflict.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

--- Comment #12 from Aurelien Jarno  ---
Created attachment 36965
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36965=edit
Output log

Please find attached the output log of gcc running patched as you requested.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[sje at gcc dot gnu.org]

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

--- Comment #13 from Steve Ellcey  ---
Thanks for the trace.  I am still not sure I understand what is going on but I
wonder if you could try commenting out this code under the "case 'e'" code in
rtx_equal_for_cselib_1.


#if 0
  if (i == 1
  && targetm.commutative_p (x, UNKNOWN)
  && rtx_equal_for_cselib_1 (XEXP (x, 1), XEXP (y, 0), memmode)
  && rtx_equal_for_cselib_1 (XEXP (x, 0), XEXP (y, 1), memmode))
return 1;
#endif

I think something is going wrong when we get here with x of:

(plus:SI (value/u:SI 60:60 @0x2335948/0x2391aa0)
(value/u:SI 15:4257 @0x2335678/0x2353978))

and y of:

(plus:SI (plus:SI (value/u:SI 60:60 @0x2335948/0x2391aa0)
(value/u:SI 15:4257 @0x2335678/0x2353978))
(value/u:SI 15:4257 @0x2335678/0x2353978))


I am not sure why that would send you into an infinite loop but
I think it might.  Possibly due to having the value of 15 in the
expression twice.  I think the reason you see it and I don't
might be related to new_cselib_val.  It creates pointers
to values and I think GCC sorts things based on those pointers
at some point and the difference in how things are allocated
by pool_alloc in new_cselib_val might be the reason you get the
problem and I don't.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[sje at gcc dot gnu.org]

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

--- Comment #11 from Steve Ellcey  ---
Could you try adding 'debug_rtx (x); debug_rtx (y);' to  the front
of rtx_equal_for_cselib_1?  It looks like this routine is in an
infinite loop, I would like to see what input it is working on
and see if the same input keeps re-occurring over and over.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

--- Comment #10 from Aurelien Jarno  ---
(In reply to Steve Ellcey from comment #8)
> Where in CC1 do you segfault?  Can you show me the error message you get
> when compiling the test program using the latest gcc-5-branch sources.

The only message I got when compiling it is the following:

xgcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

If I try to run cc1 with gdb, I get the following backtrace:

#0  0x0063cc5f in rtx_equal_for_cselib_1 (x=0x768a0480,
y=y@entry=0x769c7738, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:866
code = 
fmt = 
i = 
__FUNCTION__ = "rtx_equal_for_cselib_1"
#1  0x0063cd72 in rtx_equal_for_cselib_1 (x=,
y=0x769c7738, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:907
t = 
l = 0x15deb28
code = 
fmt = 
i = 
__FUNCTION__ = "rtx_equal_for_cselib_1"
#2  0x0063d1d9 in rtx_equal_for_cselib_1 (x=x@entry=0x769c7738,
y=0x769c7720, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:1023
j = 
code = 
fmt = 
i = 1
__FUNCTION__ = "rtx_equal_for_cselib_1"
#3  0x0063cdda in rtx_equal_for_cselib_1 (x=0x769c7738,
y=0x15de2b8, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:924
t = 
l = 0x15df088
code = 
fmt = 
i = 
__FUNCTION__ = "rtx_equal_for_cselib_1"
#4  0x0063d002 in rtx_equal_for_cselib_1 (x=0x769c7720,
y=y@entry=0x769c7738, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:1026
j = 
code = 
fmt = 
i = 0
__FUNCTION__ = "rtx_equal_for_cselib_1"
#5  0x0063cd72 in rtx_equal_for_cselib_1 (x=,
y=0x769c7738, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:907
t = 
l = 0x15df088
code = 
fmt = 
i = 
__FUNCTION__ = "rtx_equal_for_cselib_1"
#6  0x0063d002 in rtx_equal_for_cselib_1 (x=x@entry=0x769c7738,
y=0x769c7720, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:1026
j = 
code = 
fmt = 
i = 0
__FUNCTION__ = "rtx_equal_for_cselib_1"
#7  0x0063cdda in rtx_equal_for_cselib_1 (x=0x769c7738,
y=0x15de2b8, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:924
t = 
l = 0x15df088
code = 
fmt = 
i = 
__FUNCTION__ = "rtx_equal_for_cselib_1"
#8  0x0063d002 in rtx_equal_for_cselib_1 (x=0x769c7720,
y=y@entry=0x769c7738, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:1026
j = 
code = 
fmt = 
i = 0
__FUNCTION__ = "rtx_equal_for_cselib_1"
#9  0x0063cd72 in rtx_equal_for_cselib_1 (x=,
y=0x769c7738, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:907
t = 
l = 0x15df088
code = 
fmt = 
i = 
__FUNCTION__ = "rtx_equal_for_cselib_1"
#10 0x0063d002 in rtx_equal_for_cselib_1 (x=x@entry=0x769c7738,
y=0x769c7720, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:1026
j = 
code = 
fmt = 
i = 0
__FUNCTION__ = "rtx_equal_for_cselib_1"
#11 0x0063cdda in rtx_equal_for_cselib_1 (x=0x769c7738,
y=0x15de2b8, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:924
t = 
l = 0x15df088
code = 
fmt = 
i = 
__FUNCTION__ = "rtx_equal_for_cselib_1"
#12 0x0063d002 in rtx_equal_for_cselib_1 (x=0x769c7720,
y=y@entry=0x769c7738, memmode=memmode@entry=VOIDmode) at
/home/aurel32/git/gcc/gcc/cselib.c:1026
j = 
code = 

It continues like that probably up to stack exhaustion. It looks like two
mutually recursive functions.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|5.3 |5.4

--- Comment #9 from Richard Biener  ---
GCC 5.3 is being released, adjusting target milestone.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[sje at gcc dot gnu.org]

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

--- Comment #8 from Steve Ellcey  ---
Where in CC1 do you segfault?  Can you show me the error message you get when
compiling the test program using the latest gcc-5-branch sources.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[sje at gcc dot gnu.org]

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

--- Comment #6 from Steve Ellcey  ---
I still haven't been able to reproduce this.  I have been trying to do so with
the gcc-5-branch.  Aurelien, what host GCC version are you using when you build
a cross compiler?  I am building on Ubuntu 12.04 with GCC 4.6.3 and am building
the cross compiler as a 64 bit executable.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

--- Comment #7 from Aurelien Jarno  ---
I am using gcc 5.2 from Debian unstable to build the cross compiler. Please
also note that I have the same issue when using the native GCC 5.2 compiler on
a mips or mipsel system.

How can I help debugging that? Is there any output I can provide that might
help?

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Can't reproduce with a gcc-5-branch cross either (but, this is a cross without
mips binutils around, so some auto-host.h tests might be different).

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

--- Comment #3 from Aurelien Jarno  ---
I built GCC with the following options:

configure --enable-languages=c --prefix=/usr --target=mipsel-linux-gnu
--includedir=/usr/mipsel-linux-gnu/include 

Then I build the file with -O2  -g -o test.o -c test.c -march=mips32r2.

The ICE disappears when I don't use -g.

All that said, I am still able to reproduce the issue with the gcc-5-branch,
but not with trunk. I start to wonder if I correctly tested trunk or if the
problem has been fixed in the meantime. Anyway if it's not reproducible with
trunk, that's something that can be bisected. I'll do that.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

--- Comment #4 from Aurelien Jarno  ---
The bisection shows that this commit has fixed the issue on trunk:

2015-07-23  Richard Biener  

PR middle-end/66916
* match.pd: Guard widen and sign-change comparison simplification
with single_use.

That said, it just seems to be a side effect of this commit and not a fix for
the original issue.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at gcc dot gnu.org

--- Comment #2 from Steve Ellcey  ---
Aurelien,

I could not reproduce this on today’s top-of-tree or the top of the
gcc-5-branch.
Did you use any configure options when building GCC?

When you say 'compiled with debugging enabled' are you talking about just using
-g when compiling the test program or are you talking about something else?

I built a cross compiler on my x86 linux system targeting mips-linux-gnu and
used '-g -O2 -march=mips32r2' when compiling the test program but I did not get
a seg fault or an ICE or any other type of error.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.3

--- Comment #1 from Richard Biener  ---
Can you please add a version to the known-to-work field?