[Bug debug/51746] New: Segfault in cselib_preserved_value_p

[Bug debug/51746] New: Segfault in cselib_preserved_value_p

[rmansfield at qnx dot com]

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

             Bug #: 51746
           Summary: Segfault in cselib_preserved_value_p
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: rmansfield@qnx.com
                CC: aoliva@gcc.gnu.org, jakub@gcc.gnu.org
              Host: x86_64-linux-gnu
            Target: arm-unknown-linux-gnueabi
             Build: x86_64-linux-gnu


Created attachment 26234
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26234
preprocessed source

Starting with rev182760 the following crash occurs:

$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: arm-unknown-linux-gnueabi
Configured with: ../configure --target=arm-unknown-linux-gnueabi
--prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi
--with-sysroot=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi//sys-root
--disable-multilib
--with-local-prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99
--enable-long-long --enable-target-optspace
target_alias=arm-unknown-linux-gnueabi --enable-languages=c++ --disable-shared
--disable-libmudflap --disable-libssp
Thread model: posix
gcc version 4.7.0 20120103 (experimental) [trunk revision 182858] (GCC) 
ryan@zoidberg:~/gnu/gcc/trunk/arm-eabi/gcc$ ./xgcc -B. -O -g ~/seg.i
/home/ryan/seg.i: In function 'init_textlist':
/home/ryan/seg.i:12:38: warning: incompatible implicit declaration of built-in
function 'strlen' [enabled by default]
/home/ryan/seg.i:13:10: warning: assignment makes pointer from integer without
a cast [enabled by default]
/home/ryan/seg.i:18:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

#0  cselib_preserved_value_p (v=0x0) at ../../gcc/cselib.c:674
#1  0x0000000000a7543a in add_stores (loc=<optimized out>, 
    expr=0x7ffff6dfb840, cuip=0x7fffffffbb10) at ../../gcc/var-tracking.c:5522
#2  0x0000000000a73277 in add_with_sets (insn=0x7ffff6dfc510, 
    sets=<optimized out>, n_sets=<optimized out>)
    at ../../gcc/var-tracking.c:6049
#3  0x00000000005ddc00 in cselib_record_sets (insn=0x7ffff6dfc510)
    at ../../gcc/cselib.c:2476
#4  0x00000000005de850 in cselib_process_insn (insn=0x7ffff6dfc510)
    at ../../gcc/cselib.c:2568
#5  0x0000000000a79ca2 in vt_initialize () at ../../gcc/var-tracking.c:9398
#6  0x0000000000a82537 in variable_tracking_main_1 ()
    at ../../gcc/var-tracking.c:9575
#7  variable_tracking_main () at ../../gcc/var-tracking.c:9627

[Bug debug/51746] Segfault in cselib_preserved_value_p

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-04 10:40:35 UTC ---
Looks latent before to me.
The issue is that when cselib_process_insn for
(insn 56 51 60 4 (cond_exec (eq (reg:CC 24 cc)
            (const_int 0 [0]))
        (set (mem:QI (plus:SI (reg:SI 1 r1 [orig:169 ivtmp.6 ] [169])
                    (const_int -1 [0xffffffffffffffff])) [0 MEM[base: 0B,
index: ivtmp.6_13, offset: 4294967295B]+0 S1 A8])
            (reg:QI 2 r2 [176]))) pr51746.i:16 3031 {*p *arm_movqi_insn}
     (nil))
is called, initially when doing cselib_lookup on the r1 - 1, we get value
18:18,
but still during processing of that insn htab_expand is called on the cselib
hash table, as it reached the 3/4 fullness limit.  After this expand we don't
find VALUE 18:18 for r1 - 1 anymore and instead create VALUE 27:8168 (8168 is
the hash value of r1 - 1 at that point).  But that means cselib_lookup on
(mem:QI (value 27:8168)) in add_stores fails, because the desired value that
was created earlier on for (mem:QI (r1 - 1)) is in value 18:18's addr_list, not
in 27:8168's addr_list and add_stores calls cselib_lookup with create=0.
It seems most of the places in var-tracking.c that call cselib_lookup with
create=0 allow it to return NULL, but not this spot.  So the easiest fix is
just handle the oval == NULL case.  And we can think about some improvements if
it would be possible to improve this case somehow.  E.g. if cselib_find_slot
in cselib_lookup_1 succeeeds, but returns a value with e->hash != hash, perhaps
we could insert a cselib_val with the desired hash and make it
cselib_add_permanent_equiv to the actual value found?  Perhaps not 4.7
material...

[Bug debug/51746] [4.7 Regression] Segfault in cselib_preserved_value_p

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-01-04
   Target Milestone|---                         |4.7.0
            Summary|Segfault in                 |[4.7 Regression] Segfault
                   |cselib_preserved_value_p    |in cselib_preserved_value_p
     Ever Confirmed|0                           |1

[Bug debug/51746] [4.7 Regression] Segfault in cselib_preserved_value_p

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |jakub at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-04 10:46:39 UTC ---
Created attachment 26236
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26236
gcc47-pr51746.patch

Untested fix.

[Bug debug/51746] [4.7 Regression] Segfault in cselib_preserved_value_p

[rguenth at gcc dot gnu.org]

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

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

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

[Bug debug/51746] [4.7 Regression] Segfault in cselib_preserved_value_p

[aoliva at gcc dot gnu.org]

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

--- Comment #3 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-01-05 00:17:27 UTC ---
Thanks, Jakub, the patch is fine, I've just verified that it fixes the problem.

[Bug debug/51746] [4.7 Regression] Segfault in cselib_preserved_value_p

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-05 00:29:16 UTC ---
Author: jakub
Date: Thu Jan  5 00:29:13 2012
New Revision: 182897

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182897
Log:
    PR debug/51746
    * var-tracking.c (add_stores): For COND_EXEC allow oval to be NULL.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/var-tracking.c

[Bug debug/51746] Segfault in cselib_preserved_value_p

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P2
            Summary|[4.7 Regression] Segfault   |Segfault in
                   |in cselib_preserved_value_p |cselib_preserved_value_p

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-05 00:31:22 UTC ---
Fixed, keeping the bug open just so that we can consider improving the case
where cselib hashtable grows for 4.8+.

[Bug debug/51746] Segfault in cselib_preserved_value_p

[aoliva at gcc dot gnu.org]

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

--- Comment #6 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-01-05 00:58:13 UTC ---
I've now realized the reason we fail to find the (plus:si (reg:si r1)
(const_int -1)) is that reverse_op miscomputes the hash of value 22, because
we're looking up an expr containing a VALUE, and cselib_hash_rtx doesn't handle
that properly.  Getting it to support VALUEs as part of expressions, lookup
succeeds and we reuse the value, as expected.  Here's the patch I'm testing:

diff --git a/gcc/cselib.c b/gcc/cselib.c
index eeb88e6..ab9c458 100644
--- a/gcc/cselib.c
+++ b/gcc/cselib.c
@@ -1035,6 +1035,10 @@ cselib_hash_rtx (rtx x, int create, enum machine_mode
mem

   switch (code)
     {
+    case VALUE:
+      e = CSELIB_VAL_PTR (x);
+      return e->hash;
+
     case MEM:
     case REG:
       e = cselib_lookup (x, GET_MODE (x), create, memmode);

[Bug debug/51746] Segfault in cselib_preserved_value_p

[aoliva at gcc dot gnu.org]

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

--- Comment #7 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-01-06 20:21:00 UTC ---
Author: aoliva
Date: Fri Jan  6 20:20:55 2012
New Revision: 182963

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182963
Log:
PR debug/51746
* cselib.c (cselib_hash_rtx): Hash incoming VALUEs too.

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

[Bug debug/51746] Segfault in cselib_preserved_value_p

[aoliva at gcc dot gnu.org]

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

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

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

--- Comment #8 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-01-06 22:57:38 UTC ---
Fixed