[Bug tree-optimization/27299] New: gcc 4.1 produces bad code -ftree-vectorize option

[Bug tree-optimization/27299] New: gcc 4.1 produces bad code -ftree-vectorize option

[gringo at slonko dot net]

Compiling an attached test program on AMD64 using gcc-4.1.0 with '-O
-ftree-vectorize' produces a code which segfaults, eg.

gringo@sun ~ $ gcc -O -ftree-vectorize test.c -o test
gringo@sun ~ $ ./test
Segmentation fault

Compiling it using any -O flags doesn't produce code which segfaults, eg:

gringo@sun ~ $ gcc -O3 test.c -o test
gringo@sun ~ $ ./test
gringo@sun ~ $

I'm using glibc-2.4-r1 (Gentoo) and kernel 2.6.16-beyond2.


-- 
           Summary: gcc 4.1 produces bad code -ftree-vectorize option
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: gringo at slonko dot net


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

[Bug tree-optimization/27299] gcc 4.1 produces bad code -ftree-vectorize option

[gringo at slonko dot net]

------- Comment #1 from gringo at slonko dot net  2006-04-25 08:01 -------
Created an attachment (id=11332)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11332&action=view)
Test source which produces bad code with '-O -ftree-vectorize'


-- 


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

[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2006-04-25 11:49 -------
Confirmed.  We generate

0x08048475 <main+193>:  movdqu (%edx),%xmm0
0x08048479 <main+197>:  movdqa %xmm0,(%eax)

but both %edx and %eax are unaligned:

eax            0x804a021        134520865
ecx            0x0      0
edx            0x804a009        134520841

4.0.3 works, because nothing is vectorized there.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |wrong-code
      Known to fail|                            |4.1.0
      Known to work|                            |4.0.3
   Last reconfirmed|0000-00-00 00:00:00         |2006-04-25 11:49:33
               date|                            |
            Summary|gcc 4.1 produces bad code - |[4.1 Regression] vectorizer
                   |ftree-vectorize option      |generates aligned accesses
                   |                            |to unaligned memory


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

[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2006-04-25 11:55 -------
mainline doesn't do vectorization here:

/tmp/t.c:12: note: === vect_analyze_dependences ===
/tmp/t.c:12: note: not vectorized: can't determine dependence between *src.1_24
and *dest.0_23
/tmp/t.c:12: note: bad data dependence. 

while 4.1 peels for alignment (wrongly).


-- 


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

[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory

[reichelt at gcc dot gnu dot org]

------- Comment #4 from reichelt at gcc dot gnu dot org  2006-04-25 14:23 -------
Richard, you confirmed this.

But to me this looks like the code is violating the aliasing rules
(which would mean that the PR in invalid):
    *(uint64_t *)dest = *(uint64_t *)src;
but
    uint8_t *dest
    const uint8_t *src


-- 

reichelt at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org, reichelt at gcc dot gnu
                   |                            |dot org


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

[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2006-04-25 14:27 -------
Yes, but the problem appears with -O1 which has -fno-strict-aliasing.  Now
whether -fno-strict-aliasing makes the testcase valid is another question ;)


-- 


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

[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2006-04-25 14:29 -------
Changing the function to take both arguments as uint8_t* fixes the problem.


-- 


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

[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2006-04-25 17:35 -------
(In reply to comment #5)
> Yes, but the problem appears with -O1 which has -fno-strict-aliasing.  Now
> whether -fno-strict-aliasing makes the testcase valid is another question ;)

Nope, unaligned access is different from strict aliasing. With the cast to
uint64_t* you say the alignment is correct for that type.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


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

[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory

[rguenth at gcc dot gnu dot org]

------- Comment #8 from rguenth at gcc dot gnu dot org  2006-04-26 07:58 -------
Ok, that makes sense.  Still the failure mode is weird and hints at the
vectorizer not following those semantics but something else.


-- 


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