https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88698
--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> --- (In reply to Devin Hussey from comment #7) > I mean, sure, but how about this? > > What about meeting in the middle? The problem is how do you implement the rules that are required by both the Altivec and Neon programming manuals? Do you treat those types differently? And then what about the generic vector types to/from the Altivec/Neon types? How do you want to have those handled? Basically GCC was trying to follow what the Altivec (VMX) PEM says with respect to the types and their casting. For reference of the Altivec PEM: https://www.nxp.com/docs/en/reference-manual/ALTIVECPEM.pdf Have you read the Altivec PEM? GCC vector extension is/was modeled mostly after the Altivec PEM with a few additions aftwards (like operators and condtionals). Here is the patch which added vector_size: https://gcc.gnu.org/ml/gcc-patches/2001-12/msg00379.html Here is the patch that made it in which added the operators: https://gcc.gnu.org/ml/gcc/2002-05/msg02234.html Notice that this patch has the following test: + v4si a, b; .. + uv4si f; ... + f = a; /* { dg-error "incompatible types in assignment" } */ As mentioned in the thread which added -flax-vector-conversions, that was an accident that some versions of GCC accepted the assignment without the cast. Somehow the testcase got lost.
