[Bug target/64172] New: [4.9 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

[Bug target/64172] New: [4.9 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

[siarhei.siamashka at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172

            Bug ID: 64172
           Summary: [4.9 Regression] Wrong code with GCC vector extensions
                    on ARM when compiled without NEON
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: siarhei.siamashka at gmail dot com

The attached partially reduced testcase misbehaves at runtime if it is compiled
using GCC 4.9.2 on ARM with -O2 optimizations and without -mfpu=neon. Reducing
optimizations to -O1 helps.

[Bug target/64172] [4.9 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

[siarhei.siamashka at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172

Siarhei Siamashka <siarhei.siamashka at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |siarhei.siamashka at gmail dot com

--- Comment #1 from Siarhei Siamashka <siarhei.siamashka at gmail dot com> ---
Created attachment 34183
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34183&action=edit
partially reduced testcase

GCC 4.9.2

== Fails: ==

$ arm-none-linux-gnueabi-gcc -O2 preliminary-testcase-pr64172.c && ./a.out
a.out: preliminary-testcase-pr64172.c:91: main: Assertion `prng_state.d[3] ==
0xA7223834' failed.

== Works: ==

$ arm-none-linux-gnueabi-gcc -O1 preliminary-testcase-pr64172.c && ./a.out

$ arm-none-linux-gnueabi-gcc -O2 -mfpu=neon preliminary-testcase-pr64172.c &&
./a.out

[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Target|                            |arm-none-linux-gnueabi
   Target Milestone|---                         |4.9.3
            Summary|[4.9 Regression] Wrong code |[4.9/5 Regression] Wrong
                   |with GCC vector extensions  |code with GCC vector
                   |on ARM when compiled        |extensions on ARM when
                   |without NEON                |compiled without NEON

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
So it works with GCC 4.8?

[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

[siarhei.siamashka at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172

--- Comment #3 from Siarhei Siamashka <siarhei.siamashka at gmail dot com> ---
(In reply to Richard Biener from comment #2)
> So it works with GCC 4.8?

Yes, the testcase works with GCC 4.8. It started to fail only with GCC 4.9 and
only on ARM hardware. Originally reported at
https://bugs.freedesktop.org/show_bug.cgi?id=81229

This looks like some sort of stack corruption, because the assert catches
modification of a part of data which is not supposed to be changed in this
particular testcase.

[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172

--- Comment #4 from ktkachov at gcc dot gnu.org ---
I can't reproduce with -O2 and -mfpu=neon.
Can you please give the exact configuration of your GCC?
The output of 'arm-none-linux-gnueabi-gcc -v' should be good

[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2014-12-04
                 CC|                            |ktkachov at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #5 from ktkachov at gcc dot gnu.org ---
(In reply to ktkachov from comment #4)
> I can't reproduce with -O2 and -mfpu=neon.
And -mfpu=vfp doesn't reproduce for me either I should say

[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

[siarhei.siamashka at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172

--- Comment #6 from Siarhei Siamashka <siarhei.siamashka at gmail dot com> ---
(In reply to ktkachov from comment #4)
> I can't reproduce with -O2 and -mfpu=neon.
> Can you please give the exact configuration of your GCC?
> The output of 'arm-none-linux-gnueabi-gcc -v' should be good

My apologies, you are right. Adding -march=armv7-a option appears to be also
needed ("-O2 -march=armv7-a") and I had it as part of my GCC configuration:

Using built-in specs.
COLLECT_GCC=arm-none-linux-gnueabi-gcc-4.9.2
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-none-linux-gnueabi/4.9.2/lto-wrapper
Target: arm-none-linux-gnueabi
Configured with:
/var/tmp/portage/cross-arm-none-linux-gnueabi/gcc-4.9.2/work/gcc-4.9.2/configure
--host=x86_64-pc-linux-gnu --target=arm-none-linux-gnueabi
--build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/arm-none-linux-gnueabi/gcc-bin/4.9.2
--includedir=/usr/lib/gcc/arm-none-linux-gnueabi/4.9.2/include
--datadir=/usr/share/gcc-data/arm-none-linux-gnueabi/4.9.2
--mandir=/usr/share/gcc-data/arm-none-linux-gnueabi/4.9.2/man
--infodir=/usr/share/gcc-data/arm-none-linux-gnueabi/4.9.2/info
--with-gxx-include-dir=/usr/lib/gcc/arm-none-linux-gnueabi/4.9.2/include/g++-v4
--with-python-dir=/share/gcc-data/arm-none-linux-gnueabi/4.9.2/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --disable-nls --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.9.2'
--enable-libstdcxx-time --enable-poison-system-directories
--with-sysroot=/usr/arm-none-linux-gnueabi --disable-bootstrap
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-altivec
--disable-fixed-point --disable-libgcj --disable-libgomp --disable-libmudflap
--disable-libssp --disable-libquadmath --enable-lto --without-cloog
--enable-libsanitizer --with-arch=armv7-a --with-float=hard
Thread model: posix
gcc version 4.9.2 (Gentoo 4.9.2)

[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|arm-none-linux-gnueabi      |arm-none-linux-gnueabi,
                   |                            |arm-none-eabi
             Status|WAITING                     |NEW
      Known to work|                            |4.8.4
      Known to fail|                            |4.9.2, 5.0

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Thanks, confirmed.

[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172

--- Comment #8 from ktkachov at gcc dot gnu.org ---
Hmm, is passing vectors around when vector instructions are not present
expected to work?

[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172

--- Comment #9 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Thu, 4 Dec 2014, ktkachov at gcc dot gnu.org wrote:

> Hmm, is passing vectors around when vector instructions are not present
> expected to work?

All you need to conform to the VFP AAPCS variant is loads/stores.  Even 
single-precision-only VFP has the required loads/stores to support that 
AAPCS variant.

When fixing up various problems in an early version of the VFP ABI support 
patch some years ago, one of the things I implemented was making sure 
generic vector types would be passed the same (which would be the same as 
the corresponding NEON vector types) whether or not NEON instructions were 
available.  In the current version of the code, I think what's relevant is 
in aapcs_vfp_sub_candidate:

    case VECTOR_TYPE:
      /* Use V2SImode and V4SImode as representatives of all 64-bit
         and 128-bit vector types, whether or not those modes are
         supported with the present options.  */

The test in the present bug doesn't even seem to have vectors as function 
arguments / returns so the ABI shouldn't even be involved - I'd have 
expected the generic vector code to be lowered completely to non-vector 
code before the back end gets involved.

[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to joseph@codesourcery.com from comment #9)
> On Thu, 4 Dec 2014, ktkachov at gcc dot gnu.org wrote:
> 
> > Hmm, is passing vectors around when vector instructions are not present
> > expected to work?
> 
> All you need to conform to the VFP AAPCS variant is loads/stores.  Even 
> single-precision-only VFP has the required loads/stores to support that 
> AAPCS variant.
> 
> When fixing up various problems in an early version of the VFP ABI support 
> patch some years ago, one of the things I implemented was making sure 
> generic vector types would be passed the same (which would be the same as 
> the corresponding NEON vector types) whether or not NEON instructions were 
> available.  In the current version of the code, I think what's relevant is 
> in aapcs_vfp_sub_candidate:
> 
>     case VECTOR_TYPE:
>       /* Use V2SImode and V4SImode as representatives of all 64-bit
>          and 128-bit vector types, whether or not those modes are
>          supported with the present options.  */
> 
> The test in the present bug doesn't even seem to have vectors as function 
> arguments / returns so the ABI shouldn't even be involved - I'd have 
> expected the generic vector code to be lowered completely to non-vector 
> code before the back end gets involved.

That indeed happens if the target doesn't provide optabs with vector modes.
See tree-vect-generic.c.

[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|arm-none-linux-gnueabi,     |arm-none-linux-gnueabi,
                   |arm-none-eabi               |arm-none-eabi,arm-none-linu
                   |                            |x-gnueabihf
                 CC|                            |ramana at gcc dot gnu.org,
                   |                            |vmakarov at gcc dot gnu.org

--- Comment #12 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Confirmed.

[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172

--- Comment #13 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
I've investigated the generated code.  The problem is in IRA live-range
splitting on the region borders.  The pseudo to consider is 157 which contains
local_prng.d in the following code

void randmemset (prng_t *prng, uint8_t *buf, size_t size)
 {
     prng_t local_prng = *prng;
     .... 
     while (size > 0)
      {
          uint32_t e = local_prng.p0.a - ((local_prng.p0.b << 27) +
(local_prng.p0.b >> (32 - 27)));
          local_prng.p0.a = local_prng.p0.b ^ ((local_prng.p0.c << 17) ^
(local_prng.p0.c >> (32 - 17)));
          local_prng.p0.b = local_prng.p0.c + local_prng.p0.d;
          local_prng.p0.c = local_prng.p0.d + e;
          local_prng.p0.d = e + local_prng.p0.a;
          *buf++ = local_prng.p0.d;
          size--;
      }

  =>  *prng = local_prng;
  }

The pseudo gets different hard regs in different regions

Disposition:
    ...
    8:r155 l0   mem   40:r157 l1     8   25:r157 l2     6    6:r157 l0     4
    ...

In the loop above, it gets 6, outside the loop it gets 4.  On the exit from the
loop, IRA generates
   157:TI = 308:TI

308 is created from 157 to be used in the loop.

  The insn is split on 4 insns:

  449: r157:TI#0=r308:TI#0
  450: r157:TI#4=r308:TI#4
  451: r157:TI#8=r308:TI#8
  452: r157:TI#12=r308:TI#12

In order words, in terms of hard regs we do 6<-4; 7<-5; 8<-6; 9<-7.  The two
last insns  use wrong values.

I'll think how to fix it better.  I hope that the fix will be ready at the end
of next week.

[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172

--- Comment #14 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
Author: vmakarov
Date: Fri Feb 20 18:59:02 2015
New Revision: 220877

URL: https://gcc.gnu.org/viewcvs?rev=220877&root=gcc&view=rev
Log:
2015-02-20  Vladimir Makarov  <vmakarov@redhat.com>

    PR target/64172
    * ira-color.c (color_pass): Prevent splitting multi-register
    pseudos.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ira-color.c

[Bug target/64172] [4.9 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172

--- Comment #16 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Vlad, 

are you planning a 4.9 backport ? 


Ramana

[Bug rtl-optimization/64172] [4.9 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ra
          Component|target                      |rtl-optimization

--- Comment #17 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Really an rtl-optimization bug - Vlad are you considering a 4.9 backport given
this is a P2 ?

[Bug rtl-optimization/64172] [4.9 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.3 has been released.

[Bug rtl-optimization/64172] [4.9 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.3                       |4.9.4