This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Even stricter implicit conversions between vectors


Ian Lance Taylor wrote:
Mark Shinwell <shinwell@codesourcery.com> 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 see, what that amounts to is saying that there should not be an implicit conversion between vector of int and vector of unsigned int. It seems to me that a cast would then be required to call, e.g., vec_add with arguments of type __vector unsigned int. I don't see how that is useful.

But perhaps I am mistaken; can you give an example of the type of
thing which is currently permitted which you think should be
prohibited?

Things exactly like what you write above ("an implicit conversion between vector of int and vector of unsigned int"). My main argument is that the gcc behaviour seems to be at odds with the semantics envisaged by the designers of these various vector-based instruction sets we see around -- and indeed the designers of the STL -- although perhaps that is a misconception and there are actually many more examples where it is believed that these implicit conversions are reasonable.

I don't see a reason _per se_ why having the implicit conversions
is a good thing -- for things such as vec_add, presumably more
alternatives can be added (there are various ones already I see for
differing orders of "vector bool short" / "vector signed short") etc.
I think it is open to debate whether it is a good thing to have to
make those alternatives explicit, or whether some should be filled in
by implicit conversions.

However, this...

Mike Stump wrote:
> My only concern is that we have tons of customers with tons of code and
> you don't have any

That isn't quite true :-)

> and that you break their code.

...is more of a concern, I agree, and is what I worry about most.

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]