[Bug tree-optimization/34038] New: 176.gcc segfaults when compiled with -O2 -ftree-vectorize -maltivec

[Bug tree-optimization/34038] New: 176.gcc segfaults when compiled with -O2 -ftree-vectorize -maltivec

[janis at gcc dot gnu dot org]

Test 176.gcc from SPEC CPU2000 fails at execution time on powerpc-linux when
compiled with "-O2 -ftree-vectorize -maltivec".  The stack frame is corrupted
but the last few entries are several recursive calls of reload which calls
spill_failure which calls asm_noperands.  This is odd, but when _either_
reload.c or reload1.c is compiled without -ftree-vectorize, the test runs to
completion and the output is as expected.

I don't have a minimized testcase.  The failure starts with:

    http://gcc.gnu.org/viewcvs?view=rev&rev=112621

    r112621 | spop | 2006-04-02 04:27:40 +0000 (Sun, 02 Apr 2006)


-- 
           Summary: 176.gcc segfaults when compiled with -O2 -ftree-
                    vectorize -maltivec
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: janis at gcc dot gnu dot org
 GCC build triplet: powerpc-unknown-linux-gnu


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

[Bug tree-optimization/34038] 176.gcc segfaults when compiled with -O2 -ftree-vectorize -maltivec

[irar at il dot ibm dot com]

------- Comment #1 from irar at il dot ibm dot com  2007-11-29 09:31 -------
I can't reproduce this failure with the same flags with revision 130403 on
ppc64-redhat-linux. 

(Some loops indeed get vectorized in reload.c and reload1.c:
reload1.c.104t.vect:reload1.c:2433: note: LOOP VECTORIZED.
reload1.c.104t.vect:reload1.c:3968: note: LOOP VECTORIZED.
reload1.c.104t.vect:reload1.c:3749: note: LOOP VECTORIZED.
reload1.c.104t.vect:reload1.c:784: note: LOOP VECTORIZED.
reload1.c.104t.vect:reload1.c:697: note: LOOP VECTORIZED.
reload1.c.104t.vect:reload1.c:3623: note: LOOP VECTORIZED.
reload1.c.104t.vect:reload1.c:3617: note: LOOP VECTORIZED.
reload1.c.104t.vect:reload1.c:2447: note: LOOP VECTORIZED.
reload1.c.104t.vect:reload1.c:474: note: LOOP VECTORIZED.
reload.c.104t.vect:reload.c:3231: note: LOOP VECTORIZED.
reload.c.104t.vect:reload.c:3257: note: LOOP VECTORIZED.
reload.c.104t.vect:reload.c:2352: note: LOOP VECTORIZED.)

Ira


-- 


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

[Bug tree-optimization/34038] 176.gcc segfaults when compiled with -O2 -ftree-vectorize -maltivec

[janis at gcc dot gnu dot org]

------- Comment #2 from janis at gcc dot gnu dot org  2007-11-29 19:01 -------
I can reproduce the failure with revision 130507 on a p970 system.  I compile
176.gcc with "-m32 -O3 -maltivec" and execute that benchmark program with test
input.

My list of vectorized loops is the same except that reload1.c:2433 is reported
twice:

elm3b145% fgrep 'LOOP VECTORIZED' reload.c.104t.vect
reload.c:3231: note: LOOP VECTORIZED.(get_loop_exit_condition 
reload.c:3257: note: LOOP VECTORIZED.(get_loop_exit_condition 
reload.c:2352: note: LOOP VECTORIZED.
elm3b145% fgrep 'LOOP VECTORIZED' reload1.c.104t.vect
reload1.c:2433: note: LOOP VECTORIZED.
reload1.c:3968: note: LOOP VECTORIZED.(get_loop_exit_condition 
reload1.c:3749: note: LOOP VECTORIZED.
reload1.c:784: note: LOOP VECTORIZED.(get_loop_exit_condition 
reload1.c:697: note: LOOP VECTORIZED.(get_loop_exit_condition 
reload1.c:3623: note: LOOP VECTORIZED.(get_loop_exit_condition 
reload1.c:3617: note: LOOP VECTORIZED.(get_loop_exit_condition 
reload1.c:2447: note: LOOP VECTORIZED.(get_loop_exit_condition 
reload1.c:2433: note: LOOP VECTORIZED.(get_loop_exit_condition 
reload1.c:474: note: LOOP VECTORIZED.

It shouldn't make any difference, of course, but I normally build GCC using
--with-cpu=default32 and I think you don't do that; I'll try without it.


-- 


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

[Bug tree-optimization/34038] 176.gcc segfaults when compiled with -O2 -ftree-vectorize -maltivec

[janis at gcc dot gnu dot org]

------- Comment #3 from janis at gcc dot gnu dot org  2007-12-03 21:57 -------
The failure occurs with "-m32 -O3 -maltivec -fno-strict-aliasing", but not
without -fno-strict-aliasing.  That option is sometimes necessary because of
invalid code in 176.gcc, as described in 
http://gcc.gnu.org/ml/gcc/2002-01/msg00711.html.  Without it 176.gcc. fails
with -m64.

I get the failure with cpu2000 v1.2 plus 176.gcc.64bitgcc40.src.alt and with
cpu2000 v1.3.


-- 

janis at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |irar at il dot ibm dot com


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

[Bug tree-optimization/34038] 176.gcc segfaults when compiled with -O2 -ftree-vectorize -maltivec

[irar at il dot ibm dot com]

------- Comment #4 from irar at il dot ibm dot com  2007-12-04 07:31 -------
(In reply to comment #3)
> The failure occurs with "-m32 -O3 -maltivec -fno-strict-aliasing", but not
> without -fno-strict-aliasing.  

Yes, I succeeded to reproduce the failure with -fno-strict-aliasing.

Thanks,
Ira


-- 

irar at il dot ibm dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-12-04 07:31:15
               date|                            |


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

[Bug tree-optimization/34038] 176.gcc segfaults when compiled with -O2 -ftree-vectorize -maltivec

[irar at il dot ibm dot com]

------- Comment #5 from irar at il dot ibm dot com  2007-12-06 07:49 -------
It also fails with -O2 and -O1 (and not only with -O3).

The offending loop is reload.c:2352 (in function find_reloads):
      for (i = 0; i < noperands; i++)
        {
          constraints[i] = constraints1[i]
            = insn_operand_constraint[insn_code_number][i];
          operand_mode[i] = insn_operand_mode[insn_code_number][i];
        }
If I force this loop not to be vectorized, no failure occurs.

Vectorizer dumps for this loop are identical with and without
-fno-strict-aliasing, as well as the 'optimized' dumps. 

Ira


-- 


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

[Bug tree-optimization/34038] 176.gcc segfaults when compiled with -O2 -ftree-vectorize -maltivec

[irar at il dot ibm dot com]

------- Comment #6 from irar at il dot ibm dot com  2007-12-11 13:24 -------
The first difference I found between with and without -fno-strict-aliasing
versions of the loop in reload.c:2352 is in 

with -fno-strict-aliasing (the "bad" one):
(insn 414 413 415 43 ../src/reload.c:2354 (set (reg/f:SI 593 [ D.5672 ])
        (mem/s/u/f/j:SI (reg:SI 361 [ ivtmp.3074 ]) [0 insn_operand_constraint
S4 A8])) -1 (nil))

without -fno-strict-aliasing (the "good" one):
(insn 414 413 415 43 ../src/reload.c:2354 (set (reg/f:SI 593 [ D.5672 ]) 
        (mem/s/u/f:SI (reg:SI 361 [ ivtmp.3165 ]) [28 insn_operand_constraint
S4 A8])) -1 (nil)) 

Since 'j' is related to alias set, I don't know if this difference gives any
information on the reasons for the failure. 

In the assemlby the only difference I see is in the order of the stores:
without -fno-strict-aliasing
        lwz 31,1032(1)
        stvx 0,7,9
        stvx 1,8,9
        stvx 0,31,9
with -fno-strict-aliasing
        stvx 0,7,9
        lwz 31,1032(1)
        stvx 0,31,9
        stvx 1,8,9

I wonder if those differences can explain the problem...

Ira


-- 


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

[Bug tree-optimization/34038] 176.gcc segfaults when compiled with -O2 -ftree-vectorize -maltivec

[janis at gcc dot gnu dot org]

------- Comment #7 from janis at gcc dot gnu dot org  2007-12-12 19:22 -------
The failure goes away with -mabi=altivec, which is not the default with -m32. 
I had never seen this failure in my earlier testing on powerpc64-linux because
whenever I used -maltivec I also used -mabi=altivec.  It's not clear to me if
it's legitimate to use -maltivec, or -mcpu with machines that imply -maltivec,
without also using -mabi=altivec when the code will use AltiVec registers.


-- 


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

[Bug tree-optimization/34038] 176.gcc segfaults when compiled with -O2 -ftree-vectorize -maltivec

[janis at gcc dot gnu dot org]

------- Comment #8 from janis at gcc dot gnu dot org  2007-12-12 23:34 -------
Ira, it seems I've wasted your time; it's a well-known problem (except to me)
that -maltivec without -mabi=altivec doesn't work in the general case because
vector registers are not saved and restored.  That explains why this test
passes with either reload.c or reload1.c is compiled without vectorization. 
Meanwhile there are discussions happening about how to fix this so that someone
using "-O3 -mcpu=970" won't run into failures when they don't even realize
they're using vector registers.


-- 


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