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
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
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
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
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
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
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:
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
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
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
>
> 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 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
> > 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
>
> 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.
>
>
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.
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.
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
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 li
18 matches
Mail list logo
