sdardis marked 3 inline comments as done.
sdardis added a comment.
Thanks for getting back to this. I've traced the appearance of the ext_vector
type to a piece of code that only produces ext-vector types for comparisons.
I'm presuming that's wrong when clang is producing vectors implicitly in the
non-OpenCL case. I'll update the diff once I've changed that.
================
Comment at: test/Sema/vector-gcc-compat.c:61
+ // match.
+ v2i64_r = v2i64_a == 1; // expected-warning {{incompatible vector types
assigning to 'v2i64' (vector of 2 'long long' values) from 'long
__attribute__((ext_vector_type(2)))' (vector of 2 'long' values)}}
+ v2i64_r = v2i64_a != 1; // expected-warning {{incompatible vector types
assigning to 'v2i64' (vector of 2 'long long' values) from 'long
__attribute__((ext_vector_type(2)))' (vector of 2 'long' values)}}
----------------
bruno wrote:
> Can you double check where 'long __attribute__((ext_vector_type(2)))' comes
> from?
>
> We have regressed in the past year in the way ext-vector interacts with
> non-ext-vectors, and I don't wanna make it worse until we actually have time
> to fix that; there's a lot of code out there relying on bitcasts between
> ext-vectors and non-ext-vectors to bridge between intrinsics headers and
> ext-vector code.
Sema::CheckVectorCompareOperands calls Sema::GetSignedVectorType which only
returns ext-vector types. I presume that is now incorrect if we're producing
vectors from literal scalars in the non OpenCL case.
https://reviews.llvm.org/D25866
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
