User account creation filtered due to spam.

Bug 49093 - [4.6/4.7 Regression] ICE in vect_enhance_data_refs_alignment() with volatile inside peeled loop
Summary: [4.6/4.7 Regression] ICE in vect_enhance_data_refs_alignment() with volatile ...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: 4.6.1
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-20 18:45 UTC by Arthur O'Dwyer
Modified: 2011-06-02 07:11 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.4.5, 4.5.1
Known to fail: 4.6.0
Last reconfirmed: 2011-05-21 09:40:47


Attachments
Output of "ajo-gcc -std=c99 -w -O1 -funswitch-loops -ftree-vectorize -fno-tree-fre test.c -v" (896 bytes, text/plain)
2011-05-20 18:45 UTC, Arthur O'Dwyer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Arthur O'Dwyer 2011-05-20 18:45:19 UTC
Created attachment 24311 [details]
Output of "ajo-gcc -std=c99 -w -O1 -funswitch-loops -ftree-vectorize -fno-tree-fre test.c -v"

This reproduces for me with svn revision 173843 (2011-05-17). It doesn't
reproduce with gcc 4.5.1. I'm on Ubuntu 10.10, x86-64.

cat >test.c <<EOF
volatile unsigned char g_324[4] = {0, 1, 0, 1};
int x, y;
void func_81()
{
    int l_466, l_439[7] = {0};
lbl_473:
    if (x) {
        for (int g_97 = 0; (g_97 < 4); ++g_97) {
            if (y)
              goto lbl_473;
            g_324[g_97];
            l_466 = l_439[g_97];
        }
        foo(l_466);
    }
}
EOF
gcc -std=c99 -w -O1 -funswitch-loops -ftree-vectorize -fno-tree-fre test.c

test.c: In function ‘func_81’:
test.c:3:6: internal compiler error: in vect_enhance_data_refs_alignment, at tree-vect-data-refs.c:1551



This test case is reduced from the output of Csmith 2.1.0 (git hash 01aa8b04,
https://github.com/Quuxplusone/csmith/), using the following command line:
csmith --no-paranoid --no-longlong --no-pointers --arrays --jumps --consts --volatiles --no-checksum --no-divs --no-muls --no-bitfields --packed-struct -s 799267216
Comment 1 Richard Biener 2011-05-21 09:40:47 UTC
Confirmed.
Comment 2 H.J. Lu 2011-05-21 14:44:23 UTC
It is caused by revision 166244:

http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00130.html
Comment 3 Ira Rosen 2011-05-31 07:31:02 UTC
The problem here is that
vol.2_8 ={v} g_324[g_97_22];
is skipped during determination of the vectorization factor, because it has no uses. The vf is set to 4, and then the analysis fails on the char data-ref.

I think we should just not vectorize when there is a volatile access in a loop. Is that reasonable?

Thanks,
Ira
Comment 4 rguenther@suse.de 2011-05-31 08:22:51 UTC
On Tue, 31 May 2011, irar at il dot ibm.com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49093
> 
> Ira Rosen <irar at il dot ibm.com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |irar at il dot ibm.com
> 
> --- Comment #3 from Ira Rosen <irar at il dot ibm.com> 2011-05-31 07:31:02 UTC ---
> The problem here is that
> vol.2_8 ={v} g_324[g_97_22];
> is skipped during determination of the vectorization factor, because it has no
> uses. The vf is set to 4, and then the analysis fails on the char data-ref.
> 
> I think we should just not vectorize when there is a volatile access in a loop.
> Is that reasonable?

I think that's reasonable for 4.6.  But we don't need to make
data-ref analysis fail just because of volatile references - we for
example can easily unroll a loop with volatile loads/stores.

Of course this case seems to be special - how do we deal with
stmts with no uses during vectorization?  Or do we assume
they don't happen because usually DCE gets rid of them?

Richard.
Comment 5 Ira Rosen 2011-05-31 08:30:49 UTC
(In reply to comment #4)

> I think that's reasonable for 4.6.  But we don't need to make
> data-ref analysis fail just because of volatile references - we for
> example can easily unroll a loop with volatile loads/stores.
> 
> Of course this case seems to be special - how do we deal with
> stmts with no uses during vectorization?  Or do we assume
> they don't happen because usually DCE gets rid of them?

We ignore them. But this is under the assumption that they don't have memory accesses.

Ira

> 
> Richard.
Comment 6 rguenther@suse.de 2011-05-31 08:43:39 UTC
On Tue, 31 May 2011, irar at il dot ibm.com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49093
> 
> --- Comment #5 from Ira Rosen <irar at il dot ibm.com> 2011-05-31 08:30:49 UTC ---
> (In reply to comment #4)
> 
> > I think that's reasonable for 4.6.  But we don't need to make
> > data-ref analysis fail just because of volatile references - we for
> > example can easily unroll a loop with volatile loads/stores.
> > 
> > Of course this case seems to be special - how do we deal with
> > stmts with no uses during vectorization?  Or do we assume
> > they don't happen because usually DCE gets rid of them?
> 
> We ignore them. But this is under the assumption that they don't have memory
> accesses.

Ah, I see.  Yes, I guess not vectorizing for volatiles is the way
to go then.

Richard.
Comment 7 Ira Rosen 2011-05-31 09:06:04 UTC
I am testing this patch then:

Index: tree-vect-data-refs.c
===================================================================
--- tree-vect-data-refs.c       (revision 174467)
+++ tree-vect-data-refs.c       (working copy)
@@ -2584,6 +2584,16 @@ vect_analyze_data_refs (loop_vec_info lo
             return false;
         }

+      if (TYPE_VOLATILE (TREE_TYPE (DR_REF (dr))))
+        {
+          if (vect_print_dump_info (REPORT_UNVECTORIZED_LOCATIONS))
+            {
+              fprintf (vect_dump, "not vectorized: volatile type ");
+              print_gimple_stmt (vect_dump, stmt, 0, TDF_SLIM);
+            }
+          return false;
+        }
+
       base = unshare_expr (DR_BASE_ADDRESS (dr));
       offset = unshare_expr (DR_OFFSET (dr));
       init = unshare_expr (DR_INIT (dr));


Thanks,
Ira
Comment 8 rguenther@suse.de 2011-05-31 09:09:37 UTC
On Tue, 31 May 2011, irar at il dot ibm.com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49093
> 
> --- Comment #7 from Ira Rosen <irar at il dot ibm.com> 2011-05-31 09:06:04 UTC ---
> I am testing this patch then:
> 
> Index: tree-vect-data-refs.c
> ===================================================================
> --- tree-vect-data-refs.c       (revision 174467)
> +++ tree-vect-data-refs.c       (working copy)
> @@ -2584,6 +2584,16 @@ vect_analyze_data_refs (loop_vec_info lo
>              return false;
>          }
> 
> +      if (TYPE_VOLATILE (TREE_TYPE (DR_REF (dr))))

 if (TREE_THIS_VOLATILE (DR_REF (dr)))

instead.

Richard.
Comment 9 Ira Rosen 2011-05-31 09:17:26 UTC
(In reply to comment #8)

> > 
> > +      if (TYPE_VOLATILE (TREE_TYPE (DR_REF (dr))))
> 
>  if (TREE_THIS_VOLATILE (DR_REF (dr)))
> 
> instead.
>

OK. Thanks.
Ira
 
> Richard.
Comment 10 irar 2011-05-31 12:31:09 UTC
Author: irar
Date: Tue May 31 12:31:04 2011
New Revision: 174477

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

        PR tree-optimization/49093
        * tree-vect-data-refs.c (vect_analyze_data_refs): Fail for
        volatile data references.


Added:
    trunk/gcc/testsuite/gcc.dg/vect/pr49093.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-vect-data-refs.c
Comment 11 irar 2011-06-02 07:03:04 UTC
Author: irar
Date: Thu Jun  2 07:02:57 2011
New Revision: 174559

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

        PR tree-optimization/49093
        * tree-vect-data-refs.c (vect_analyze_data_refs): Fail for
        volatile data references.


Added:
    branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/vect/pr49093.c
Modified:
    branches/gcc-4_6-branch/gcc/ChangeLog
    branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_6-branch/gcc/tree-vect-data-refs.c
Comment 12 Ira Rosen 2011-06-02 07:11:29 UTC
Fixed.