[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" <gcc-bugzilla at gcc dot gnu dot 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.