[Bug middle-end/43901] New: [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[Bug middle-end/43901] New: [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[hjl dot tools at gmail dot com]

On Linux/ia32, revision 158720 gave

FAIL: gcc.c-torture/compile/pr42196-2.c  -O3 -fomit-frame-pointer  (internal
compiler error)
FAIL: gcc.c-torture/compile/pr42196-2.c  -O3 -fomit-frame-pointer  (test for
excess errors)
FAIL: gcc.c-torture/compile/pr42196-2.c  -O3 -g  (internal compiler error)
FAIL: gcc.c-torture/compile/pr42196-2.c  -O3 -g  (test for excess errors)

Revision 158713 is OK. Revision 158719:

http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00826.html

may be the cause.


-- 
           Summary: [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hjl dot tools at gmail dot com


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

[Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[irar at il dot ibm dot com]

------- Comment #1 from irar at il dot ibm dot com  2010-04-27 05:53 -------
Could you please give some more information? It doesn't fail on x86_64-linux.
(For SLP dump please use -fdump-tree-slp-details).

Thanks,
Ira


-- 


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

[Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2010-04-27 09:36 -------
I can't get it to FAIL either.  Tried various -march=XXX in

make check-gcc RUNTESTFLAGS="--target_board=unix/-m32/-march=atom
compile.exp=pr42196-2.c"

HJ, what arch do you configure for?


-- 


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

[Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[hjl dot tools at gmail dot com]

------- Comment #3 from hjl dot tools at gmail dot com  2010-04-27 13:07 -------
Ooops. I meant Linux/ia64.


-- 


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

[Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 GCC target triplet|                            |ia64-*-*
   Target Milestone|---                         |4.6.0


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

[Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[irar at il dot ibm dot com]

------- Comment #4 from irar at il dot ibm dot com  2010-05-02 05:51 -------
I don't have access to ia64. I tried to change the types in the test to make
the basic blocks vectorizable on x86_64, but didn't get any error. So I still
need SLP dump in order to solve this.

Thanks,
Ira


-- 

irar at il dot ibm dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.6.0                       |---


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

[Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[ubizjak at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2697 bytes --]



------- Comment #5 from ubizjak at gmail dot com  2010-05-02 10:44 -------
(In reply to comment #4)
> I don't have access to ia64. I tried to change the types in the test to make
> the basic blocks vectorizable on x86_64, but didn't get any error. So I still
> need SLP dump in order to solve this.

You can simply build ia64 crosscompiler with (you don't need to install
binutils):

$ ../gcc-svn/trunk/configure --target=ia64-linux-gnu --enable-languages=c

$ make
[... the build will fail, but cc1 will be compiled correctly ... ]

~/gcc-build-ia64/gcc/cc1 -O3 -quiet pr42196-2.c
pr42196-2.c: In function ‘foo’:
pr42196-2.c:10:7: internal compiler error: in vectorizable_operation, at
tree-vect-stmts.c:1989
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

gdb --args ~/gcc-build-ia64/gcc/cc1 -O3 -quiet pr42196-2.c
[...]
#0  fancy_abort (file=0xb2e818 "../../gcc-svn/trunk/gcc/tree-vect-stmts.c", 
    line=1989, function=0xb2f840 "vectorizable_operation")
    at ../../gcc-svn/trunk/gcc/diagnostic.c:810
#1  0x00000000008520c1 in vectorizable_operation (stmt=0x7ffff20e62d0, 
    gsi=0x0, vec_stmt=0x0, slp_node=0x10a3530)
    at ../../gcc-svn/trunk/gcc/tree-vect-stmts.c:1989
#2  0x0000000000855b78 in vect_analyze_stmt (stmt=0x7ffff20e62d0, 
    need_to_vectorize=0x7fffffffddaf "\001\320\350\005\001", node=0x10a3530)
    at ../../gcc-svn/trunk/gcc/tree-vect-stmts.c:4063
#3  0x0000000000868b43 in vect_slp_analyze_node_operations (
    bb_vinfo=<value optimized out>, node=0x10a3530)
    at ../../gcc-svn/trunk/gcc/tree-vect-slp.c:1404
#4  0x0000000000868abf in vect_slp_analyze_node_operations (
    bb_vinfo=0x105e8d0, node=0x10a34f0)
    at ../../gcc-svn/trunk/gcc/tree-vect-slp.c:1394
#5  0x000000000086dd23 in vect_slp_analyze_operations (
    bb=<value optimized out>) at ../../gcc-svn/trunk/gcc/tree-vect-slp.c:1424
#6  vect_slp_analyze_bb (bb=<value optimized out>)
    at ../../gcc-svn/trunk/gcc/tree-vect-slp.c:1564
#7  0x000000000086e1eb in execute_vect_slp ()
    at ../../gcc-svn/trunk/gcc/tree-vectorizer.c:276
#8  0x000000000068ed79 in execute_one_pass (pass=0xe90940)
    at ../../gcc-svn/trunk/gcc/passes.c:1590

Confirmed via ia64 cross.


-- 

ubizjak at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-05-02 10:44:22
               date|                            |


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

[Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[ubizjak at gmail dot com]

------- Comment #6 from ubizjak at gmail dot com  2010-05-02 10:46 -------
The _.115t.slp dump is empty:

$ more pr42196-2.c.115t.slp 

;; Function foo (foo)


-- 


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

[Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[ubizjak at gmail dot com]

------- Comment #7 from ubizjak at gmail dot com  2010-05-02 10:50 -------
Following assert in tree-vects-stmts.c is triggered:

  /* If op0 is an external or constant def use a vector type with
     the same size as the output vector type.  */
  if (!vectype)
    vectype = get_same_sized_vectype (TREE_TYPE (op0), vectype_out);
  gcc_assert (vectype);


-- 


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

[Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[ubizjak at gmail dot com]

------- Comment #8 from ubizjak at gmail dot com  2010-05-02 11:02 -------
Created an attachment (id=20531)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20531&action=view)
SLP dump with -O3 -fdump-tree-slp-details


-- 


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

[Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[irar at il dot ibm dot com]

------- Comment #9 from irar at il dot ibm dot com  2010-05-02 11:08 -------
Thanks, Uros! I reproduced the ICE using your instructions.


-- 


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

[Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[irar at il dot ibm dot com]

------- Comment #10 from irar at il dot ibm dot com  2010-05-02 12:12 -------
Looks like it's caused by:
r158157 | rguenth | 2010-04-09 13:40:14 +0300 (Fri, 09 Apr 2010) | 28 lines

The problem is in getting vectype for f1_2:

foo (int b, double f1, double f2, int c1, int c2)
{
...
  float D.1999;
  float D.1998;
...

<bb 3>:
  D.1998_3 = (float) f1_2(D);
  REALPART_EXPR <u.cf> = D.1998_3;
  D.1999_5 = (float) f2_4(D);
  IMAGPART_EXPR <u.cf> = D.1999_5;
  D.2012_10 = u.ci;
  goto <bb 5>;

An immediate fix would be to replace the assert in 

  /* If op0 is an external or constant def use a vector type with
     the same size as the output vector type.  */
  if (!vectype)
    vectype = get_same_sized_vectype (TREE_TYPE (op0), vectype_out);
  gcc_assert (vectype);

with 'return false', since get_same_sized_vectype currently just redirects to
get_vectype_for_scalar_type. But the comment (and the future intent) seems
incorrect for external defs, as f1 and f2 in this test.

Ira


-- 

irar at il dot ibm dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenther at suse dot de


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

[Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.6.0


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

[Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[rguenther at suse dot de]

------- Comment #11 from rguenther at suse dot de  2010-05-03 11:16 -------
Subject: Re:  [4.6 Regression] FAIL:
 gcc.c-torture/compile/pr42196-2.c

On Sun, 2 May 2010, irar at il dot ibm dot com wrote:

> ------- Comment #10 from irar at il dot ibm dot com  2010-05-02 12:12 -------
> Looks like it's caused by:
> r158157 | rguenth | 2010-04-09 13:40:14 +0300 (Fri, 09 Apr 2010) | 28 lines
> 
> The problem is in getting vectype for f1_2:
> 
> foo (int b, double f1, double f2, int c1, int c2)
> {
> ...
>   float D.1999;
>   float D.1998;
> ...
> 
> <bb 3>:
>   D.1998_3 = (float) f1_2(D);
>   REALPART_EXPR <u.cf> = D.1998_3;
>   D.1999_5 = (float) f2_4(D);
>   IMAGPART_EXPR <u.cf> = D.1999_5;
>   D.2012_10 = u.ci;
>   goto <bb 5>;
> 
> An immediate fix would be to replace the assert in 
> 
>   /* If op0 is an external or constant def use a vector type with
>      the same size as the output vector type.  */
>   if (!vectype)
>     vectype = get_same_sized_vectype (TREE_TYPE (op0), vectype_out);
>   gcc_assert (vectype);
> 
> with 'return false', since get_same_sized_vectype currently just redirects to
> get_vectype_for_scalar_type. But the comment (and the future intent) seems
> incorrect for external defs, as f1 and f2 in this test.

Well.  For loops we'd have disqualified it as there is no vector
type for the external def (well, the stmt inside the loop).
So we do not do this for SLP?  In that case
yes, if we can return false at this point then we should replace this
(and similar) asserts with return false.  Or we should fix
the code that scans the BB initially and sets vector types properly?

Thanks,
Richard.


-- 


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

[Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[irar at il dot ibm dot com]

------- Comment #12 from irar at il dot ibm dot com  2010-05-03 12:30 -------

> Well.  For loops we'd have disqualified it as there is no vector
> type for the external def (well, the stmt inside the loop).

I don't think that's true. With -fno-tree-pre we get the same ICE for loop
vectorization for:

#define N 64

union U
{
  __complex__ int ci;
  __complex__ float cf;
};

union U u[N];

void foo (double f1, double f2)
{
  int i;

  for (i=0; i<N; i++)
    {
      __real__ u[i].cf = f1;
      __imag__ u[i].cf = f2;
    }
}

> So we do not do this for SLP?  In that case
> yes, if we can return false at this point then we should replace this
> (and similar) asserts with return false.  Or we should fix
> the code that scans the BB initially and sets vector types properly?

The loop scan that sets vector types, only checks lhs types (or the smallest
type in stmt) in order to decide on vectorization factor. There is a similar
scan for BBs in vect_analyze_stmt (only to set vector types for stmts) and it
also looks only at lhs. 

The failure occurs in analysis, so it's ok to return false at this point. 
But I don't understand why external def has to have the same size as the lhs?
(And it is, of course, possible that both types are vectorizable, but still the
rhs type is bigger than the lhs type).

Thanks,
Ira

> 
> Thanks,
> Richard.
> 


-- 


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

[Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[rguenther at suse dot de]

------- Comment #13 from rguenther at suse dot de  2010-05-03 12:35 -------
Subject: Re:  [4.6 Regression] FAIL:
 gcc.c-torture/compile/pr42196-2.c

On Mon, 3 May 2010, irar at il dot ibm dot com wrote:

> ------- Comment #12 from irar at il dot ibm dot com  2010-05-03 12:30 -------
> 
> > Well.  For loops we'd have disqualified it as there is no vector
> > type for the external def (well, the stmt inside the loop).
> 
> I don't think that's true. With -fno-tree-pre we get the same ICE for loop
> vectorization for:
> 
> #define N 64
> 
> union U
> {
>   __complex__ int ci;
>   __complex__ float cf;
> };
> 
> union U u[N];
> 
> void foo (double f1, double f2)
> {
>   int i;
> 
>   for (i=0; i<N; i++)
>     {
>       __real__ u[i].cf = f1;
>       __imag__ u[i].cf = f2;
>     }
> }
> 
> > So we do not do this for SLP?  In that case
> > yes, if we can return false at this point then we should replace this
> > (and similar) asserts with return false.  Or we should fix
> > the code that scans the BB initially and sets vector types properly?
> 
> The loop scan that sets vector types, only checks lhs types (or the smallest
> type in stmt) in order to decide on vectorization factor. There is a similar
> scan for BBs in vect_analyze_stmt (only to set vector types for stmts) and it
> also looks only at lhs. 

Ah, my followup AVX patches look at all operands.

> The failure occurs in analysis, so it's ok to return false at this point. 
> But I don't understand why external def has to have the same size as the lhs?
> (And it is, of course, possible that both types are vectorizable, but still the
> rhs type is bigger than the lhs type).

It tries to get a _vector_ type of the same size.  In theory each
vectorization method can choose whatever vector size suits them
most (as for external defs they need to build up a vector of equivalent
elements anyway).  So with AVX we can do V4DF -> V4SF vectorization,
if the double is an external def the vectorization method could choose
to create a vector with double size.  But the reasonable default for
now is th force a same-sized vector type as that is what the vectorizer
was tested for until now (well, until I get the followup patch cleaned
up and posted again).

So yes, if we can return false we should probably do so instead of
asserting (maybe assert that if we are supposed to create vectorized
stmts and thus cannot fail that we indeed have a vector type here).

Richard.


-- 


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

[Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[irar at il dot ibm dot com]

------- Comment #14 from irar at il dot ibm dot com  2010-05-05 09:02 -------

> It tries to get a _vector_ type of the same size.  In theory each
> vectorization method can choose whatever vector size suits them
> most (as for external defs they need to build up a vector of equivalent
> elements anyway).  So with AVX we can do V4DF -> V4SF vectorization,
> if the double is an external def the vectorization method could choose
> to create a vector with double size.  But the reasonable default for
> now is th force a same-sized vector type as that is what the vectorizer
> was tested for until now (well, until I get the followup patch cleaned
> up and posted again).

OK, thanks for the explanation.

> 
> So yes, if we can return false we should probably do so instead of
> asserting (maybe assert that if we are supposed to create vectorized
> stmts and thus cannot fail that we indeed have a vector type here).

I'll prepare a patch.

Thanks,
Ira

> 
> Richard.
> 


-- 

irar at il dot ibm dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |irar at il dot ibm dot com
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2010-05-02 10:44:22         |2010-05-05 09:02:26
               date|                            |


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

[Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[irar at gcc dot gnu dot org]

------- Comment #15 from irar at gcc dot gnu dot org  2010-05-06 06:43 -------
Subject: Bug 43901

Author: irar
Date: Thu May  6 06:42:51 2010
New Revision: 159095

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159095
Log:

        PR tree-optimization/43901
        * tree-vect-stmts.c (vectorizable_call): Assert that vector
        type is not NULL if it's transformation phase, and return
        FALSE if it's analysis.
        (vectorizable_conversion, vectorizable_operation, 
        vectorizable_type_demotion, vectorizable_type_promotion):
        Likewise.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-vect-stmts.c


-- 


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

[Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[irar at il dot ibm dot com]

------- Comment #16 from irar at il dot ibm dot com  2010-05-10 08:17 -------
Fixed.


-- 

irar at il dot ibm dot com changed:

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


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