On Thu, 2006-10-12 at 08:02 -0700, Ian Lance Taylor wrote:
> It's been this way at least since 4.0.
But it was rejected in 3.4.0.
> I believe that the problem with changing this unconditionally is that
> the Altivec programming guidelines specify the rules which gcc
> currently follows: you are pe
Ian Lance Taylor wrote:
I believe that the problem with changing this unconditionally is that
the Altivec programming guidelines specify the rules which gcc
currently follows: you are permitted to assign one vector variable to
another, without an explicit cast, when the vectors are the same size.
Mark Shinwell <[EMAIL PROTECTED]> writes:
> Here, the compiler is not complaining about an attempt to implicitly
> convert a vector of four 16-bit quantities to a vector of eight
> 8-bit quantities.
>
> This lack of type safety is unsettling, and I wonder if it should be fixed
> with a patch alon
Andrew Pinski wrote:
On Thu, 2006-10-12 at 13:03 +0100, Mark Shinwell wrote:
typedef __builtin_neon_qi int8x8_t __attribute__ ((__vector_size__ (8)));
typedef __builtin_neon_hi int16x4_t __attribute__ ((__vector_size__ (8)));
...
int8x8_t f (int16x4_t a)
{
return a;
}
This should
On Thu, 2006-10-12 at 13:03 +0100, Mark Shinwell wrote:
> typedef __builtin_neon_qi int8x8_t __attribute__ ((__vector_size__ (8)));
> typedef __builtin_neon_hi int16x4_t __attribute__ ((__vector_size__ (8)));
> ...
>
> int8x8_t f (int16x4_t a)
> {
>return a;
> }
This should error out
This lack of type safety is unsettling, and I wonder if it should be fixed
with a patch along the lines of the (not yet fully tested) one below. Does
that sound reasonable? It seems right to try to fix the generic code here,
even though the testcase in hand is target-specific. If this approac
