Currently we permit implicit conversions between vectors whose total
bitsizes are equal but which are divided into differing numbers of subparts.
It seems that in some circumstances this rule is overly lax. For example
the following code, using vector types (whose definitions I have provided
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
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
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
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
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.
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
Recently I proposed that implicit conversions between vectors with
differing numbers of elements yet the same total bitlength be disallowed.
It was agreed that this was reasonable, and I shall be submitting a
patch to vector_types_convertible_p and the testsuite in the near future.
I would now
Mark Shinwell <[EMAIL PROTECTED]> writes:
> I would now like to propose that the check in that function be made
> even stronger such that it disallows conversions between vectors
> whose element types differ -- even if an implicit conversion exists
> between those element types.
As far as I can s
On Oct 31, 2006, at 10:47 AM, Mark Shinwell wrote:
What do others think?
My only concern is that we have tons of customers with tons of code
and you don't have any and that you break their code. I don't have
any idea if this would be the case or not, I don't usually do the
vector bugs.
Ian Lance Taylor wrote:
Mark Shinwell <[EMAIL PROTECTED]> writes:
I would now like to propose that the check in that function be made
even stronger such that it disallows conversions between vectors
whose element types differ -- even if an implicit conversion exists
between those element types.
>
> Recently I proposed that implicit conversions between vectors with
> differing numbers of elements yet the same total bitlength be disallowed.
> It was agreed that this was reasonable, and I shall be submitting a
> patch to vector_types_convertible_p and the testsuite in
> > and that you break their code.
>
> ...is more of a concern, I agree, and is what I worry about most.
The other question how of this was accepted in 3.4.0 or earlier because
the behavior changed in 4.0.0 with respect of accepting these code.
Thanks,
Andrew Pinski
On Tuesday 31 October 2006 19:02, Mike Stump wrote:
> On Oct 31, 2006, at 10:47 AM, Mark Shinwell wrote:
> > What do others think?
>
> My only concern is that we have tons of customers with tons of code
> and you don't have any and that you break their code. I don't have
> any idea if this would b
>
> On Oct 31, 2006, at 10:47 AM, Mark Shinwell wrote:
> > What do others think?
>
> My only concern is that we have tons of customers with tons of code
> and you don't have any and that you break their code. I don't have
> any idea if this would be the case or not, I don't usually do the
On Oct 31, 2006, at 11:52 AM, Andrew Pinski wrote:
#define vector __attribute__((vector_size(16) ))
vector int f(vector int, vector unsigned int);
int g(void)
{
vector int t;
vector int t1;
vector unsigned int t2;
t2 = f(t,t1);
}
Our 3.3 compiler gives:
t.c:10: error: incompatible ty
Assuming I understand the proposal properly, this sounds to me like
it amounts reversing the change we experienced in the Apple GCC from
3.3 -> 4.0. Type checking became a lot more lax for us in 4.0.
We use AltiVec very heavily. From experience in cases when our 4.0
code had to be back
Ian Ollmann wrote:
Assuming I understand the proposal properly, this sounds to me like it
amounts reversing the change we experienced in the Apple GCC from 3.3
-> 4.0. Type checking became a lot more lax for us in 4.0.
This was a bug and has been fixed recently. I cannot recall if the fix
Paolo Bonzini wrote:
Ian Ollmann wrote:
Assuming I understand the proposal properly, this sounds to me like it
amounts reversing the change we experienced in the Apple GCC from 3.3
-> 4.0. Type checking became a lot more lax for us in 4.0.
This was a bug and has been fixed recently. I ca
Ian Ollmann wrote:
stronger type checking seems like a good idea to me in general.
I agree, but I don't really want to break lots of code all at once,
even if that code is being slightly more slack than it perhaps ought
to be :-)
Given that no-one has really objected to stronger type-checking
Assuming I understand the proposal properly, this sounds to me like
it amounts reversing the change we experienced in the Apple GCC
from 3.3 -> 4.0. Type checking became a lot more lax for us in 4.0.
This was a bug and has been fixed recently. I cannot recall if the
fix has been backporte
Paolo Bonzini wrote:
Assuming I understand the proposal properly, this sounds to me like
it amounts reversing the change we experienced in the Apple GCC
from 3.3 -> 4.0. Type checking became a lot more lax for us in 4.0.
This was a bug and has been fixed recently. I cannot recall if the
fi
Mark Shinwell <[EMAIL PROTECTED]> writes:
> Ian Ollmann wrote:
> > stronger type checking seems like a good idea to me in general.
>
> I agree, but I don't really want to break lots of code all at once,
> even if that code is being slightly more slack than it perhaps ought
> to be :-)
>
> Given
On Nov 2, 2006, at 5:33 AM, Mark Shinwell wrote:
Ian Ollmann wrote:
stronger type checking seems like a good idea to me in general.
I agree, but I don't really want to break lots of code all at once,
even if that code is being slightly more slack than it perhaps ought
to be :-)
Given that n
Ian Lance Taylor wrote:
I would vote for: break the code, but provide an option to restore the
old behaviour, and mention the option in the error message.
I like this -- I shall prepare a patch and circulate it for review.
Mark
25 matches
Mail list logo
