[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

In D67678#3446526 , @rsmith wrote:

> @dexonsmith @arphaman What do we need to do to get this re-landed?

FWIW, on the PPC side, we are working on cleaning up `altivec.h` and plan to 
eventually make `-fno-lax-vector-conversions` the default.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added a comment.

In D67678#3446526 , @rsmith wrote:

> @dexonsmith @arphaman What do we need to do to get this re-landed?

(I'm sorry I missed your ping two years ago :(... I was on an extended leave at 
the time and never ended up catching up on the email I missed.)

@arphaman is probably the best person to figure this out with you, but I'll 
start an internal thread to see if someone else can help too.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith reopened this revision.
rsmith added a comment.
This revision is now accepted and ready to land.
Herald added a project: All.

@dexonsmith @arphaman What do we need to do to get this re-landed?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

In D67678#1856229 , @rsmith wrote:

> In D67678#1836953 , @dexonsmith 
> wrote:
>
>> In D67678#1836922 , @rsmith wrote:
>>
>>> If there's no timeline to update the macOS SDK, then perhaps we could add a 
>>> hack to Clang to allow these conversions only in limited contexts (the 
>>> specific parts of the macOS SDK that are relying on them). Do you know how 
>>> many such places there might be? If it's just a few functions, we could 
>>> match against the function names, or depending on what `SIMD_CFUNC` expands 
>>> to, perhaps we could match that. Failing that, we could set a 
>>> platform-specific default or similar.
>>
>> A hack like this sounds pragmatic to me.  An initial look suggests it's a 
>> small number of frameworks; I suspect many functions, but we could 
>> potentially match on partial file path or `SIMD_CFUNC`.  We need a deeper 
>> audit across our internal stack to be sure, though.  I don't think we'll 
>> have bandwidth for that until ~late February.
>
> OK, that seems fine to me. I don't want this to miss another release if we 
> can avoid it, but that should give plenty of time to iterate on something 
> that keeps your SDK building :)

@dexonsmith Ping, I'd like to get this done for the Clang 12 release; what do 
we need to do to make sure we're not causing problems for the macOS SDK?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

In D67678#1836953 , @dexonsmith wrote:

> In D67678#1836922 , @rsmith wrote:
>
> > If there's no timeline to update the macOS SDK, then perhaps we could add a 
> > hack to Clang to allow these conversions only in limited contexts (the 
> > specific parts of the macOS SDK that are relying on them). Do you know how 
> > many such places there might be? If it's just a few functions, we could 
> > match against the function names, or depending on what `SIMD_CFUNC` expands 
> > to, perhaps we could match that. Failing that, we could set a 
> > platform-specific default or similar.
>
>
> A hack like this sounds pragmatic to me.  An initial look suggests it's a 
> small number of frameworks; I suspect many functions, but we could 
> potentially match on partial file path or `SIMD_CFUNC`.  We need a deeper 
> audit across our internal stack to be sure, though.  I don't think we'll have 
> bandwidth for that until ~late February.


OK, that seems fine to me. I don't want this to miss another release if we can 
avoid it, but that should give plenty of time to iterate on something that 
keeps your SDK building :)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added a comment.

In D67678#1836922 , @rsmith wrote:

> In D67678#1836668 , @dexonsmith 
> wrote:
>
> > In D67678#1836628 , @steven_wu 
> > wrote:
> >
> > > In D67678#1834957 , @rsmith 
> > > wrote:
> > >
> > > > In D67678#1834542 , @steven_wu 
> > > > wrote:
> > > >
> > > > > @rsmith This also breaks macOS SDK. Can we revert this as we discuss 
> > > > > a less aggressive option?
> > > >
> > > >
> > > > Do you have a timeline for how long it would take to fix the MacOS SDK? 
> > > > Is this something we could realistically aim to do in Clang 11 instead? 
> > > > I would really prefer for us to not have different defaults for Darwin 
> > > > versus everywhere else, so if waiting one release cycle is enough, that 
> > > > seems fine.
> > >
> > >
> > > I am also not sure if we have rules about SDK compatibility for releases 
> > > and I can't say macOS SDK can definitely be fixed before clang 11 
> > > release. @dexonsmith @arphaman might have more info.
> >
> >
> > We can't comment on future releases.
> >
> > That said, if this is urgent, let @arphaman know and we can try to qualify 
> > internally sometime in the next few months and we can report back what 
> > issues we find.
>
>
> Understood. The current situation is deeply unpalatable (the conversions we 
> allow by default that this patch would have disabled are *evil* and have 
> never been supported by GCC; it looks like Clang only ever allowed them as a 
> bug, and we really need to turn them off by default for safety as much as for 
> GCC compatibility). But this isn't a regression, at least, so I don't think 
> this is especially urgent. (I was working on this because Agner Fog made an 
> impassioned plea that we fix this, and I think our community owes Agner a 
> favor or two...)


Yeah, it definitely seems like a good change.

> If there's no timeline to update the macOS SDK, then perhaps we could add a 
> hack to Clang to allow these conversions only in limited contexts (the 
> specific parts of the macOS SDK that are relying on them). Do you know how 
> many such places there might be? If it's just a few functions, we could match 
> against the function names, or depending on what `SIMD_CFUNC` expands to, 
> perhaps we could match that. Failing that, we could set a platform-specific 
> default or similar.

A hack like this sounds pragmatic to me.  An initial look suggests it's a small 
number of frameworks; I suspect many functions, but we could potentially match 
on partial file path or `SIMD_CFUNC`.  We need a deeper audit across our 
internal stack to be sure, though.  I don't think we'll have bandwidth for that 
until ~late February.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

In D67678#1836668 , @dexonsmith wrote:

> In D67678#1836628 , @steven_wu wrote:
>
> > In D67678#1834957 , @rsmith wrote:
> >
> > > In D67678#1834542 , @steven_wu 
> > > wrote:
> > >
> > > > @rsmith This also breaks macOS SDK. Can we revert this as we discuss a 
> > > > less aggressive option?
> > >
> > >
> > > Do you have a timeline for how long it would take to fix the MacOS SDK? 
> > > Is this something we could realistically aim to do in Clang 11 instead? I 
> > > would really prefer for us to not have different defaults for Darwin 
> > > versus everywhere else, so if waiting one release cycle is enough, that 
> > > seems fine.
> >
> >
> > I am also not sure if we have rules about SDK compatibility for releases 
> > and I can't say macOS SDK can definitely be fixed before clang 11 release. 
> > @dexonsmith @arphaman might have more info.
>
>
> We can't comment on future releases.
>
> That said, if this is urgent, let @arphaman know and we can try to qualify 
> internally sometime in the next few months and we can report back what issues 
> we find.


Understood. The current situation is deeply unpalatable (the conversions we 
allow by default that this patch would have disabled are *evil* and have never 
been supported by GCC; it looks like Clang only ever allowed them as a bug, and 
we really need to turn them off by default for safety as much as for GCC 
compatibility). But this isn't a regression, at least, so I don't think this is 
especially urgent. (I was working on this because Agner Fog made an impassioned 
plea that we fix this, and I think our community owes Agner a favor or two...)

If there's no timeline to update the macOS SDK, then perhaps we could add a 
hack to Clang to allow these conversions only in limited contexts (the specific 
parts of the macOS SDK that are relying on them). Do you know how many such 
places there might be? If it's just a few functions, we could match against the 
function names, or depending on what `SIMD_CFUNC` expands to, perhaps we could 
match that. Failing that, we could set a platform-specific default or similar.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Hans Wennborg via Phabricator via cfe-commits]

hans added a comment.

I've cherry-picked the revert (edd4398f4cd33a305afbca76ac4e6590e9337f4d 
) to the 
10.x branch in b079266dcb6d1ee6446d074ebd1d212a13ce0665 
.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added a comment.



In D67678#1836628 , @steven_wu wrote:

> In D67678#1834957 , @rsmith wrote:
>
> > In D67678#1834542 , @steven_wu 
> > wrote:
> >
> > > @rsmith This also breaks macOS SDK. Can we revert this as we discuss a 
> > > less aggressive option?
> >
> >
> > Do you have a timeline for how long it would take to fix the MacOS SDK? Is 
> > this something we could realistically aim to do in Clang 11 instead? I 
> > would really prefer for us to not have different defaults for Darwin versus 
> > everywhere else, so if waiting one release cycle is enough, that seems fine.
>
>
> I am also not sure if we have rules about SDK compatibility for releases and 
> I can't say macOS SDK can definitely be fixed before clang 11 release. 
> @dexonsmith @arphaman might have more info.


We can't comment on future releases.

That said, if this is urgent, let @arphaman know and we can try to qualify 
internally sometime in the next few months and we can report back what issues 
we find.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Steven Wu via Phabricator via cfe-commits]

steven_wu added a subscriber: dexonsmith.
steven_wu added a comment.

In D67678#1834957 , @rsmith wrote:

> In D67678#1834542 , @steven_wu wrote:
>
> > @rsmith This also breaks macOS SDK. Can we revert this as we discuss a less 
> > aggressive option?
>
>
> (This was already reverted a couple of days ago.)
>
> Do you have a timeline for how long it would take to fix the MacOS SDK? Is 
> this something we could realistically aim to do in Clang 11 instead? I would 
> really prefer for us to not have different defaults for Darwin versus 
> everywhere else, so if waiting one release cycle is enough, that seems fine.
>
> I'll split out the new flag at least and re-land for Clang 10, while we 
> figure out how to set the default.


I am not sure if we ever have rules about compatibility against old SDKs. The 
earliest time we can fix SDK is the next major Xcode release, which might not 
@dexonsmith

In D67678#1834957 , @rsmith wrote:

> In D67678#1834542 , @steven_wu wrote:
>
> > @rsmith This also breaks macOS SDK. Can we revert this as we discuss a less 
> > aggressive option?
>
>
> (This was already reverted a couple of days ago.)
>
> Do you have a timeline for how long it would take to fix the MacOS SDK? Is 
> this something we could realistically aim to do in Clang 11 instead? I would 
> really prefer for us to not have different defaults for Darwin versus 
> everywhere else, so if waiting one release cycle is enough, that seems fine.
>
> I'll split out the new flag at least and re-land for Clang 10, while we 
> figure out how to set the default.


Thanks @rsmith!

I am also not sure if we have rules about SDK compatibility for releases and I 
can't say macOS SDK can definitely be fixed before clang 11 release. 
@dexonsmith @arphaman might have more info.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

In D67678#1834957 , @rsmith wrote:

> I'll split out the new flag at least and re-land for Clang 10, while we 
> figure out how to set the default.


Looks like there's nothing to re-land here: only the change of default was 
reverted, not splitting up the flag.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

In D67678#1834542 , @steven_wu wrote:

> @rsmith This also breaks macOS SDK. Can we revert this as we discuss a less 
> aggressive option?


(This was already reverted a couple of days ago.)

Do you have a timeline for how long it would take to fix the MacOS SDK? Is this 
something we could realistically aim to do in Clang 11 instead? I would really 
prefer for us to not have different defaults for Darwin versus everywhere else, 
so if waiting one release cycle is enough, that seems fine.

I'll split out the new flag at least and re-land for Clang 10, while we figure 
out how to set the default.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[dmajor via Phabricator via cfe-commits]

dmajor added a comment.

I noticed that this was merged to the 10.0 release branch. Should the merge be 
reverted while the dust settles on the trunk implementation?

FWIW this change breaks code in skia, as used in both Firefox and Chromium. I 
see that crbug.com/1042470 added the flag as a bandaid, and we'll probably have 
to do the same in Firefox. It's a bit frustrating to see a breaking change like 
this pop up late in the release cycle.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Alex Lorenz via Phabricator via cfe-commits]

arphaman added a comment.

This also breaks the macOS SDK. @rsmith could you please disable this change 
for Darwin when you're recommitting this patch?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Steven Wu via Phabricator via cfe-commits]

steven_wu added a comment.

@rsmith This also breaks macOS SDK. Can we revert this as we discuss a less 
aggressive option?

Here is an example in macOS SDK (from /usr/include/simd/logic.h):

  static inline SIMD_CFUNC simd_bool simd_any(simd_int2 x) {
return (_mm_movemask_ps(simd_make_int4_undef(x)) & 0x3);
  }

This change will cause problem for people using TOT clang with macOS SDK. Maybe 
we can start with warning or provide a toolchain overwrite for this?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Mitch Phillips via Phabricator via cfe-commits]

hctim added a comment.

This change broke the sanitizer buildbots and was reverted here 
. Please 
see here 
 for 
more information:

  
/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/lib/msan/tests/msan_test.cpp:4232:7:
 error: no matching function for call to '_mm_cmpneq_ps'
c = _mm_cmpneq_ps(V4x32{Poisoned(), 1, 2, 3}, V4x32{4, 5, 
Poisoned(), 6});
^
  
/b/sanitizer-x86_64-linux/build/clang_build/lib/clang/11.0.0/include/xmmintrin.h:719:1:
 note: candidate function not viable: no known conversion from '(anonymous 
namespace)::V4x32' (vector of 4 'U4' values) to '__m128' (vector of 4 'float' 
values) for 1st argument
  _mm_cmpneq_ps(__m128 __a, __m128 __b)
  ^
  
/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/lib/msan/tests/msan_test.cpp:4238:7:
 error: no matching function for call to '_mm_cmpneq_ps'
c = _mm_cmpneq_ps(V4x32{0, 1, 2, 3}, V4x32{4, 5, 6, 7});
^
  
/b/sanitizer-x86_64-linux/build/clang_build/lib/clang/11.0.0/include/xmmintrin.h:719:1:
 note: candidate function not viable: no known conversion from '(anonymous 
namespace)::V4x32' (vector of 4 'U4' values) to '__m128' (vector of 4 'float' 
values) for 1st argument
  _mm_cmpneq_ps(__m128 __a, __m128 __b)
  ^
  
/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/lib/msan/tests/msan_test.cpp:4244:7:
 error: no matching function for call to '_mm_cmpneq_sd'
c = _mm_cmpneq_sd(V2x64{Poisoned(), 1}, V2x64{2, 3});
^
  
/b/sanitizer-x86_64-linux/build/clang_build/lib/clang/11.0.0/include/emmintrin.h:866:1:
 note: candidate function not viable: no known conversion from '(anonymous 
namespace)::V2x64' (vector of 2 'U8' values) to '__m128d' (vector of 2 'double' 
values) for 1st argument
  _mm_cmpneq_sd(__m128d __a, __m128d __b)
  ^
  
/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/lib/msan/tests/msan_test.cpp:4246:7:
 error: no matching function for call to '_mm_cmpneq_sd'
c = _mm_cmpneq_sd(V2x64{1, 2}, V2x64{Poisoned(), 3});
^
  
/b/sanitizer-x86_64-linux/build/clang_build/lib/clang/11.0.0/include/emmintrin.h:866:1:
 note: candidate function not viable: no known conversion from '(anonymous 
namespace)::V2x64' (vector of 2 'U8' values) to '__m128d' (vector of 2 'double' 
values) for 1st argument
  _mm_cmpneq_sd(__m128d __a, __m128d __b)
  ^
  
/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/lib/msan/tests/msan_test.cpp:4248:7:
 error: no matching function for call to '_mm_cmpneq_sd'
c = _mm_cmpneq_sd(V2x64{1, 2}, V2x64{3, 4});
^
  
/b/sanitizer-x86_64-linux/build/clang_build/lib/clang/11.0.0/include/emmintrin.h:866:1:
 note: candidate function not viable: no known conversion from '(anonymous 
namespace)::V2x64' (vector of 2 'U8' values) to '__m128d' (vector of 2 'double' 
values) for 1st argument
  _mm_cmpneq_sd(__m128d __a, __m128d __b)
  ^
  
/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/lib/msan/tests/msan_test.cpp:4250:7:
 error: no matching function for call to '_mm_cmpneq_sd'
c = _mm_cmpneq_sd(V2x64{1, Poisoned()}, V2x64{2, Poisoned()});
^
  
/b/sanitizer-x86_64-linux/build/clang_build/lib/clang/11.0.0/include/emmintrin.h:866:1:
 note: candidate function not viable: no known conversion from '(anonymous 
namespace)::V2x64' (vector of 2 'U8' values) to '__m128d' (vector of 2 'double' 
values) for 1st argument
  _mm_cmpneq_sd(__m128d __a, __m128d __b)
  ^
  
/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/lib/msan/tests/msan_test.cpp:4252:7:
 error: no matching function for call to '_mm_cmpneq_sd'
c = _mm_cmpneq_sd(V2x64{1, Poisoned()}, V2x64{1, Poisoned()});
^
  
/b/sanitizer-x86_64-linux/build/clang_build/lib/clang/11.0.0/include/emmintrin.h:866:1:
 note: candidate function not viable: no known conversion from '(anonymous 
namespace)::V2x64' (vector of 2 'U8' values) to '__m128d' (vector of 2 'double' 
values) for 1st argument
  _mm_cmpneq_sd(__m128d __a, __m128d __b)
  ^
  
/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/lib/msan/tests/msan_test.cpp:4258:32:
 error: cannot initialize a parameter of type '__attribute__((__vector_size__(2 
* sizeof(double double' (vector of 2 'double' values) with an rvalue of 
type '(anonymous namespace)::V2x64' (vector of 2 'U8' values)
c = __builtin_ia32_ucomisdlt(V2x64{Poisoned(), 1}, V2x64{2, 3});
 ^~~~
  
/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/lib/msan/tests/msan_test.cpp:4260:32:
 error: cannot initialize a parameter of type '__attribute__((__vector_size__(2 
* sizeof(double double' (vector of 2 'double' values) with an rvalue of 
type '(anonymous namespace)::V2x64' (vector of 2 'U8' values)
c = __builtin_ia32_ucomisdlt(V2x64{1, 2}, V2x64{Poisoned(), 

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGb72a8c65e4e3: PR17164: Change clangs default behavior 
from -flax-vector-conversions=all to… (authored by Richard Smith 
richard-l...@metafoo.co.uk, committed by rsmith).

Changed prior to commit:
  https://reviews.llvm.org/D67678?vs=238099=238351#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678

Files:
  clang/docs/CommandGuide/clang.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/LangOptions.def
  clang/test/Headers/altivec-header.c
  clang/test/Headers/arm-neon-header.c
  clang/test/Headers/x86-intrinsics-headers.c
  clang/test/Headers/x86intrin-2.c
  clang/test/Headers/x86intrin.c
  clang/test/Sema/vector-assign.c
  clang/test/Sema/vector-cast.c
  clang/test/Sema/vector-ops.c

Index: clang/test/Sema/vector-ops.c
===
--- clang/test/Sema/vector-ops.c
+++ clang/test/Sema/vector-ops.c
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 %s -verify -fsyntax-only -Wvector-conversion -triple x86_64-apple-darwin10
+// RUN: %clang_cc1 %s -verify -fsyntax-only -Wvector-conversion -triple x86_64-apple-darwin10 -flax-vector-conversions=all
+// FIXME: We get worse diagnostics here with -flax-vector-conversions disabled.
 typedef unsigned int v2u __attribute__ ((vector_size (8)));
 typedef int v2s __attribute__ ((vector_size (8)));
 typedef float v2f __attribute__ ((vector_size(8)));
Index: clang/test/Sema/vector-cast.c
===
--- clang/test/Sema/vector-cast.c
+++ clang/test/Sema/vector-cast.c
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 -fsyntax-only %s -verify -Wvector-conversion
+// RUN: %clang_cc1 -fsyntax-only %s -verify=expected,no-lax -Wvector-conversion -flax-vector-conversions=none
+// RUN: %clang_cc1 -fsyntax-only %s -verify=expected,lax -Wvector-conversion -flax-vector-conversions=all
 
 typedef long long t1 __attribute__ ((vector_size (8)));
 typedef char t2 __attribute__ ((vector_size (16)));
@@ -41,7 +42,9 @@
 void f2(t2 X); // expected-note{{passing argument to parameter 'X' here}}
 
 void f3(t3 Y) {
-  f2(Y);  // expected-warning {{incompatible vector types passing 't3' (vector of 4 'float' values) to parameter of type 't2' (vector of 16 'char' values)}}
+  f2(Y);
+  // lax-warning@-1 {{incompatible vector types passing 't3' (vector of 4 'float' values) to parameter of type 't2' (vector of 16 'char' values)}}
+  // no-lax-error@-2 {{passing 't3' (vector of 4 'float' values) to parameter of incompatible type 't2' (vector of 16 'char' values)}}
 }
 
 typedef float float2 __attribute__ ((vector_size (8)));
@@ -58,13 +61,15 @@
   float64x2_t v = {0.0, 1.0};
   f2 += d; // expected-error {{cannot convert between scalar type 'double' and vector type 'float2' (vector of 2 'float' values) as implicit conversion would cause truncation}}
   d += f2; // expected-error {{assigning to 'double' from incompatible type 'float2' (vector of 2 'float' values)}}
-  a = 3.0 + vget_low_f64(v);
-  b = vget_low_f64(v) + 3.0;
-  c = vget_low_f64(v);
-  c -= vget_low_f64(v);
+  a = 3.0 + vget_low_f64(v); // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
+  b = vget_low_f64(v) + 3.0; // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
+  c = vget_low_f64(v); // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
+  c -= vget_low_f64(v); // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
   // LAX conversions between scalar and vector types require same size and one element sized vectors.
   d = f2; // expected-error {{assigning to 'double' from incompatible type 'float2'}}
-  d = d + f2; // expected-error {{assigning to 'double' from incompatible type 'float2'}}
+  d = d + f2;
+  // lax-error@-1 {{assigning to 'double' from incompatible type 'float2' (vector of 2 'float' values)}}
+  // no-lax-error@-2 {{cannot convert between scalar type 'double' and vector type 'float2' (vector of 2 'float' values) as implicit conversion would cause truncation}}
 }
 
 // rdar://15931426
@@ -78,6 +83,8 @@
 }
 
 void f6(vSInt32 a0) {
-  vUInt32 counter = (float16){0.0f, 0.0f, 0.0f, 0.0f}; // expected-warning {{incompatible vector types initializing 'vUInt32' (vector of 4 'unsigned int' values) with an expression of type 'float16' (vector of 4 'float' values)}}
+  vUInt32 counter = (float16){0.0f, 0.0f, 0.0f, 0.0f};
+  // lax-warning@-1 {{incompatible vector types initializing 'vUInt32' (vector of 4 'unsigned int' values) with an expression of type 'float16' (vector of 4 'float' values)}}
+  // no-lax-error@-2 {{initializing 'vUInt32' (vector of 4 'unsigned int' values) with an expression of incompatible type 'float16' (vector of 

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Eli Friedman via Phabricator via cfe-commits]

efriedma accepted this revision.
efriedma added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.
Herald added a subscriber: wuzish.

Ping, I don't think I have any actionable feedback here and I'd like to get 
this landed before Clang 10 branches.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith updated this revision to Diff 238099.
rsmith added a comment.
Herald added subscribers: kbarton, nemanjai.

Rebase and slightly expand release notes.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678

Files:
  clang/docs/CommandGuide/clang.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/LangOptions.def
  clang/lib/Headers/ppc_wrappers/emmintrin.h
  clang/test/Headers/altivec-header.c
  clang/test/Headers/arm-neon-header.c
  clang/test/Headers/x86-intrinsics-headers.c
  clang/test/Headers/x86intrin-2.c
  clang/test/Headers/x86intrin.c
  clang/test/Sema/vector-assign.c
  clang/test/Sema/vector-cast.c
  clang/test/Sema/vector-ops.c

Index: clang/test/Sema/vector-ops.c
===
--- clang/test/Sema/vector-ops.c
+++ clang/test/Sema/vector-ops.c
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 %s -verify -fsyntax-only -Wvector-conversion -triple x86_64-apple-darwin10
+// RUN: %clang_cc1 %s -verify -fsyntax-only -Wvector-conversion -triple x86_64-apple-darwin10 -flax-vector-conversions=all
+// FIXME: We get worse diagnostics here with -flax-vector-conversions disabled.
 typedef unsigned int v2u __attribute__ ((vector_size (8)));
 typedef int v2s __attribute__ ((vector_size (8)));
 typedef float v2f __attribute__ ((vector_size(8)));
Index: clang/test/Sema/vector-cast.c
===
--- clang/test/Sema/vector-cast.c
+++ clang/test/Sema/vector-cast.c
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 -fsyntax-only %s -verify -Wvector-conversion
+// RUN: %clang_cc1 -fsyntax-only %s -verify=expected,no-lax -Wvector-conversion -flax-vector-conversions=none
+// RUN: %clang_cc1 -fsyntax-only %s -verify=expected,lax -Wvector-conversion -flax-vector-conversions=all
 
 typedef long long t1 __attribute__ ((vector_size (8)));
 typedef char t2 __attribute__ ((vector_size (16)));
@@ -41,7 +42,9 @@
 void f2(t2 X); // expected-note{{passing argument to parameter 'X' here}}
 
 void f3(t3 Y) {
-  f2(Y);  // expected-warning {{incompatible vector types passing 't3' (vector of 4 'float' values) to parameter of type 't2' (vector of 16 'char' values)}}
+  f2(Y);
+  // lax-warning@-1 {{incompatible vector types passing 't3' (vector of 4 'float' values) to parameter of type 't2' (vector of 16 'char' values)}}
+  // no-lax-error@-2 {{passing 't3' (vector of 4 'float' values) to parameter of incompatible type 't2' (vector of 16 'char' values)}}
 }
 
 typedef float float2 __attribute__ ((vector_size (8)));
@@ -58,13 +61,15 @@
   float64x2_t v = {0.0, 1.0};
   f2 += d; // expected-error {{cannot convert between scalar type 'double' and vector type 'float2' (vector of 2 'float' values) as implicit conversion would cause truncation}}
   d += f2; // expected-error {{assigning to 'double' from incompatible type 'float2' (vector of 2 'float' values)}}
-  a = 3.0 + vget_low_f64(v);
-  b = vget_low_f64(v) + 3.0;
-  c = vget_low_f64(v);
-  c -= vget_low_f64(v);
+  a = 3.0 + vget_low_f64(v); // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
+  b = vget_low_f64(v) + 3.0; // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
+  c = vget_low_f64(v); // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
+  c -= vget_low_f64(v); // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
   // LAX conversions between scalar and vector types require same size and one element sized vectors.
   d = f2; // expected-error {{assigning to 'double' from incompatible type 'float2'}}
-  d = d + f2; // expected-error {{assigning to 'double' from incompatible type 'float2'}}
+  d = d + f2;
+  // lax-error@-1 {{assigning to 'double' from incompatible type 'float2' (vector of 2 'float' values)}}
+  // no-lax-error@-2 {{cannot convert between scalar type 'double' and vector type 'float2' (vector of 2 'float' values) as implicit conversion would cause truncation}}
 }
 
 // rdar://15931426
@@ -78,6 +83,8 @@
 }
 
 void f6(vSInt32 a0) {
-  vUInt32 counter = (float16){0.0f, 0.0f, 0.0f, 0.0f}; // expected-warning {{incompatible vector types initializing 'vUInt32' (vector of 4 'unsigned int' values) with an expression of type 'float16' (vector of 4 'float' values)}}
+  vUInt32 counter = (float16){0.0f, 0.0f, 0.0f, 0.0f};
+  // lax-warning@-1 {{incompatible vector types initializing 'vUInt32' (vector of 4 'unsigned int' values) with an expression of type 'float16' (vector of 4 'float' values)}}
+  // no-lax-error@-2 {{initializing 'vUInt32' (vector of 4 'unsigned int' values) with an expression of incompatible type 'float16' (vector of 4 'float' values)}}
   counter -= a0;
 }
Index: clang/test/Sema/vector-assign.c

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Kristof Beyls via Phabricator via cfe-commits]

kristof.beyls added inline comments.



Comment at: docs/ReleaseNotes.rst:84
+  In a future release of Clang, we intend to change the default to
+  ``-fno-lax-vector-conversions``.
+

rsmith wrote:
> efriedma wrote:
> > kristof.beyls wrote:
> > > efriedma wrote:
> > > > rsmith wrote:
> > > > > efriedma wrote:
> > > > > > And if you want to allow your code to build with both clang-9 and 
> > > > > > clang-10, you have to do version detection in your build scripts?
> > > > > I guess you'd detect whether the compiler supports 
> > > > > `-flax-vector-conversions=all`, and pass that if so, and otherwise 
> > > > > pass `-flax-vector-conversions`. Well, either that or you fix your 
> > > > > code to not rely on lax vector conversions between int and float 
> > > > > vectors. If your code builds with GCC, you did that already (they 
> > > > > never supported lax conversions between float and int vectors, as far 
> > > > > as I can tell).
> > > > > 
> > > > > Do you have a preferred alternative?
> > > > All the alternatives are terrible in their own way:
> > > > 
> > > > 1. This status quo, which breaks compatibility with previous versions 
> > > > of clang
> > > > 2. We could make -flax-vector-conversions mean the same thing as 
> > > > earlier versions of clang.  So the flag wouldn't have the same meaning 
> > > > as gcc's flag.
> > > > 3. Some mix of the previous options: we could wait until there are one 
> > > > or two released versions that support -flax-vector-conversions=all , 
> > > > then change the meaning of -flax-vector-conversions.  But I have no 
> > > > idea how we would decide on a timeline.
> > > > 
> > > > I ran into this issue recently updating our compiler.  That said, the 
> > > > code in question was only using the implicit conversion in a couple 
> > > > places by accident, so it was easy enough to just fix the source.
> > > Maybe adding an entry in the release notes about this change could help 
> > > with making option 1 slightly more palatable?
> > > My guess is that option 1 is the right one for the long term 
> > > (compatibility between gcc and clang so code is more portable between 
> > > both compilers).
> > It probably makes sense to call out the behavior change to 
> > -flax-vector-conversions in the release notes, yes.
> @kristof.beyls Are you looking for more changes to the release notes in 
> addition to what's already in this change? If so, what would you like to see?
@rsmith I'm afraid I reacted to the review comments above and completely missed 
you had already added an entry to the release notes! My apologies.
I think it might still take some time for someone getting a build error who 
then goes through the release notes to easily spot that it's the change to lax 
vector conversions that's making their build fail.
However, I can't think of a much better way to describe this in the release 
notes so that a developer would spot this more easily, unless we'd put a source 
code example of something that now fails by default that didn't before. Putting 
source code examples in the release notes for all changes might make the 
release notes too long/complex?


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith marked an inline comment as done.
rsmith added inline comments.



Comment at: docs/ReleaseNotes.rst:84
+  In a future release of Clang, we intend to change the default to
+  ``-fno-lax-vector-conversions``.
+

efriedma wrote:
> kristof.beyls wrote:
> > efriedma wrote:
> > > rsmith wrote:
> > > > efriedma wrote:
> > > > > And if you want to allow your code to build with both clang-9 and 
> > > > > clang-10, you have to do version detection in your build scripts?
> > > > I guess you'd detect whether the compiler supports 
> > > > `-flax-vector-conversions=all`, and pass that if so, and otherwise pass 
> > > > `-flax-vector-conversions`. Well, either that or you fix your code to 
> > > > not rely on lax vector conversions between int and float vectors. If 
> > > > your code builds with GCC, you did that already (they never supported 
> > > > lax conversions between float and int vectors, as far as I can tell).
> > > > 
> > > > Do you have a preferred alternative?
> > > All the alternatives are terrible in their own way:
> > > 
> > > 1. This status quo, which breaks compatibility with previous versions of 
> > > clang
> > > 2. We could make -flax-vector-conversions mean the same thing as earlier 
> > > versions of clang.  So the flag wouldn't have the same meaning as gcc's 
> > > flag.
> > > 3. Some mix of the previous options: we could wait until there are one or 
> > > two released versions that support -flax-vector-conversions=all , then 
> > > change the meaning of -flax-vector-conversions.  But I have no idea how 
> > > we would decide on a timeline.
> > > 
> > > I ran into this issue recently updating our compiler.  That said, the 
> > > code in question was only using the implicit conversion in a couple 
> > > places by accident, so it was easy enough to just fix the source.
> > Maybe adding an entry in the release notes about this change could help 
> > with making option 1 slightly more palatable?
> > My guess is that option 1 is the right one for the long term (compatibility 
> > between gcc and clang so code is more portable between both compilers).
> It probably makes sense to call out the behavior change to 
> -flax-vector-conversions in the release notes, yes.
@kristof.beyls Are you looking for more changes to the release notes in 
addition to what's already in this change? If so, what would you like to see?


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: docs/ReleaseNotes.rst:84
+  In a future release of Clang, we intend to change the default to
+  ``-fno-lax-vector-conversions``.
+

kristof.beyls wrote:
> efriedma wrote:
> > rsmith wrote:
> > > efriedma wrote:
> > > > And if you want to allow your code to build with both clang-9 and 
> > > > clang-10, you have to do version detection in your build scripts?
> > > I guess you'd detect whether the compiler supports 
> > > `-flax-vector-conversions=all`, and pass that if so, and otherwise pass 
> > > `-flax-vector-conversions`. Well, either that or you fix your code to not 
> > > rely on lax vector conversions between int and float vectors. If your 
> > > code builds with GCC, you did that already (they never supported lax 
> > > conversions between float and int vectors, as far as I can tell).
> > > 
> > > Do you have a preferred alternative?
> > All the alternatives are terrible in their own way:
> > 
> > 1. This status quo, which breaks compatibility with previous versions of 
> > clang
> > 2. We could make -flax-vector-conversions mean the same thing as earlier 
> > versions of clang.  So the flag wouldn't have the same meaning as gcc's 
> > flag.
> > 3. Some mix of the previous options: we could wait until there are one or 
> > two released versions that support -flax-vector-conversions=all , then 
> > change the meaning of -flax-vector-conversions.  But I have no idea how we 
> > would decide on a timeline.
> > 
> > I ran into this issue recently updating our compiler.  That said, the code 
> > in question was only using the implicit conversion in a couple places by 
> > accident, so it was easy enough to just fix the source.
> Maybe adding an entry in the release notes about this change could help with 
> making option 1 slightly more palatable?
> My guess is that option 1 is the right one for the long term (compatibility 
> between gcc and clang so code is more portable between both compilers).
It probably makes sense to call out the behavior change to 
-flax-vector-conversions in the release notes, yes.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Kristof Beyls via Phabricator via cfe-commits]

kristof.beyls added inline comments.



Comment at: docs/ReleaseNotes.rst:84
+  In a future release of Clang, we intend to change the default to
+  ``-fno-lax-vector-conversions``.
+

efriedma wrote:
> rsmith wrote:
> > efriedma wrote:
> > > And if you want to allow your code to build with both clang-9 and 
> > > clang-10, you have to do version detection in your build scripts?
> > I guess you'd detect whether the compiler supports 
> > `-flax-vector-conversions=all`, and pass that if so, and otherwise pass 
> > `-flax-vector-conversions`. Well, either that or you fix your code to not 
> > rely on lax vector conversions between int and float vectors. If your code 
> > builds with GCC, you did that already (they never supported lax conversions 
> > between float and int vectors, as far as I can tell).
> > 
> > Do you have a preferred alternative?
> All the alternatives are terrible in their own way:
> 
> 1. This status quo, which breaks compatibility with previous versions of clang
> 2. We could make -flax-vector-conversions mean the same thing as earlier 
> versions of clang.  So the flag wouldn't have the same meaning as gcc's flag.
> 3. Some mix of the previous options: we could wait until there are one or two 
> released versions that support -flax-vector-conversions=all , then change the 
> meaning of -flax-vector-conversions.  But I have no idea how we would decide 
> on a timeline.
> 
> I ran into this issue recently updating our compiler.  That said, the code in 
> question was only using the implicit conversion in a couple places by 
> accident, so it was easy enough to just fix the source.
Maybe adding an entry in the release notes about this change could help with 
making option 1 slightly more palatable?
My guess is that option 1 is the right one for the long term (compatibility 
between gcc and clang so code is more portable between both compilers).


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: docs/ReleaseNotes.rst:84
+  In a future release of Clang, we intend to change the default to
+  ``-fno-lax-vector-conversions``.
+

rsmith wrote:
> efriedma wrote:
> > And if you want to allow your code to build with both clang-9 and clang-10, 
> > you have to do version detection in your build scripts?
> I guess you'd detect whether the compiler supports 
> `-flax-vector-conversions=all`, and pass that if so, and otherwise pass 
> `-flax-vector-conversions`. Well, either that or you fix your code to not 
> rely on lax vector conversions between int and float vectors. If your code 
> builds with GCC, you did that already (they never supported lax conversions 
> between float and int vectors, as far as I can tell).
> 
> Do you have a preferred alternative?
All the alternatives are terrible in their own way:

1. This status quo, which breaks compatibility with previous versions of clang
2. We could make -flax-vector-conversions mean the same thing as earlier 
versions of clang.  So the flag wouldn't have the same meaning as gcc's flag.
3. Some mix of the previous options: we could wait until there are one or two 
released versions that support -flax-vector-conversions=all , then change the 
meaning of -flax-vector-conversions.  But I have no idea how we would decide on 
a timeline.

I ran into this issue recently updating our compiler.  That said, the code in 
question was only using the implicit conversion in a couple places by accident, 
so it was easy enough to just fix the source.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith marked an inline comment as done.
rsmith added inline comments.



Comment at: docs/ReleaseNotes.rst:84
+  In a future release of Clang, we intend to change the default to
+  ``-fno-lax-vector-conversions``.
+

efriedma wrote:
> And if you want to allow your code to build with both clang-9 and clang-10, 
> you have to do version detection in your build scripts?
I guess you'd detect whether the compiler supports 
`-flax-vector-conversions=all`, and pass that if so, and otherwise pass 
`-flax-vector-conversions`. Well, either that or you fix your code to not rely 
on lax vector conversions between int and float vectors. If your code builds 
with GCC, you did that already (they never supported lax conversions between 
float and int vectors, as far as I can tell).

Do you have a preferred alternative?


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: docs/ReleaseNotes.rst:84
+  In a future release of Clang, we intend to change the default to
+  ``-fno-lax-vector-conversions``.
+

And if you want to allow your code to build with both clang-9 and clang-10, you 
have to do version detection in your build scripts?


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

Ping:  is fixed, this is now good to go.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith updated this revision to Diff 224473.
rsmith added a comment.

Test fixup.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678

Files:
  docs/CommandGuide/clang.rst
  docs/ReleaseNotes.rst
  include/clang/Basic/LangOptions.def
  test/Headers/altivec-header.c
  test/Headers/arm-neon-header.c
  test/Headers/x86-intrinsics-headers.c
  test/Headers/x86intrin-2.c
  test/Headers/x86intrin.c
  test/Sema/vector-assign.c
  test/Sema/vector-cast.c
  test/Sema/vector-ops.c

Index: test/Sema/vector-ops.c
===
--- test/Sema/vector-ops.c
+++ test/Sema/vector-ops.c
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 %s -verify -fsyntax-only -Wvector-conversion -triple x86_64-apple-darwin10
+// RUN: %clang_cc1 %s -verify -fsyntax-only -Wvector-conversion -triple x86_64-apple-darwin10 -flax-vector-conversions=all
+// FIXME: We get worse diagnostics here with -flax-vector-conversions disabled.
 typedef unsigned int v2u __attribute__ ((vector_size (8)));
 typedef int v2s __attribute__ ((vector_size (8)));
 typedef float v2f __attribute__ ((vector_size(8)));
Index: test/Sema/vector-cast.c
===
--- test/Sema/vector-cast.c
+++ test/Sema/vector-cast.c
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 -fsyntax-only %s -verify -Wvector-conversion
+// RUN: %clang_cc1 -fsyntax-only %s -verify=expected,no-lax -Wvector-conversion -flax-vector-conversions=none
+// RUN: %clang_cc1 -fsyntax-only %s -verify=expected,lax -Wvector-conversion -flax-vector-conversions=all
 
 typedef long long t1 __attribute__ ((vector_size (8)));
 typedef char t2 __attribute__ ((vector_size (16)));
@@ -41,7 +42,9 @@
 void f2(t2 X); // expected-note{{passing argument to parameter 'X' here}}
 
 void f3(t3 Y) {
-  f2(Y);  // expected-warning {{incompatible vector types passing 't3' (vector of 4 'float' values) to parameter of type 't2' (vector of 16 'char' values)}}
+  f2(Y);
+  // lax-warning@-1 {{incompatible vector types passing 't3' (vector of 4 'float' values) to parameter of type 't2' (vector of 16 'char' values)}}
+  // no-lax-error@-2 {{passing 't3' (vector of 4 'float' values) to parameter of incompatible type 't2' (vector of 16 'char' values)}}
 }
 
 typedef float float2 __attribute__ ((vector_size (8)));
@@ -58,13 +61,15 @@
   float64x2_t v = {0.0, 1.0};
   f2 += d; // expected-error {{cannot convert between scalar type 'double' and vector type 'float2' (vector of 2 'float' values) as implicit conversion would cause truncation}}
   d += f2; // expected-error {{assigning to 'double' from incompatible type 'float2' (vector of 2 'float' values)}}
-  a = 3.0 + vget_low_f64(v);
-  b = vget_low_f64(v) + 3.0;
-  c = vget_low_f64(v);
-  c -= vget_low_f64(v);
+  a = 3.0 + vget_low_f64(v); // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
+  b = vget_low_f64(v) + 3.0; // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
+  c = vget_low_f64(v); // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
+  c -= vget_low_f64(v); // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
   // LAX conversions between scalar and vector types require same size and one element sized vectors.
   d = f2; // expected-error {{assigning to 'double' from incompatible type 'float2'}}
-  d = d + f2; // expected-error {{assigning to 'double' from incompatible type 'float2'}}
+  d = d + f2;
+  // lax-error@-1 {{assigning to 'double' from incompatible type 'float2' (vector of 2 'float' values)}}
+  // no-lax-error@-2 {{cannot convert between scalar type 'double' and vector type 'float2' (vector of 2 'float' values) as implicit conversion would cause truncation}}
 }
 
 // rdar://15931426
@@ -78,6 +83,8 @@
 }
 
 void f6(vSInt32 a0) {
-  vUInt32 counter = (float16){0.0f, 0.0f, 0.0f, 0.0f}; // expected-warning {{incompatible vector types initializing 'vUInt32' (vector of 4 'unsigned int' values) with an expression of type 'float16' (vector of 4 'float' values)}}
+  vUInt32 counter = (float16){0.0f, 0.0f, 0.0f, 0.0f};
+  // lax-warning@-1 {{incompatible vector types initializing 'vUInt32' (vector of 4 'unsigned int' values) with an expression of type 'float16' (vector of 4 'float' values)}}
+  // no-lax-error@-2 {{initializing 'vUInt32' (vector of 4 'unsigned int' values) with an expression of incompatible type 'float16' (vector of 4 'float' values)}}
   counter -= a0;
 }
Index: test/Sema/vector-assign.c
===
--- test/Sema/vector-assign.c
+++ test/Sema/vector-assign.c
@@ -14,12 +14,12 @@
   
   v1 = v2; // expected-warning {{incompatible vector types assigning to 'v2s' (vector of 2 'int' values) from 'v2u' (vector of 2 'unsigned int' 

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith updated this revision to Diff 224138.
rsmith added a comment.

Update documentation and release notes.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678

Files:
  docs/CommandGuide/clang.rst
  docs/ReleaseNotes.rst
  include/clang/Basic/LangOptions.def
  test/Headers/altivec-header.c
  test/Headers/arm-neon-header.c
  test/Headers/x86-intrinsics-headers.c
  test/Headers/x86intrin-2.c
  test/Headers/x86intrin.c
  test/Sema/vector-assign.c
  test/Sema/vector-cast.c
  test/Sema/vector-ops.c

Index: test/Sema/vector-ops.c
===
--- test/Sema/vector-ops.c
+++ test/Sema/vector-ops.c
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 %s -verify -fsyntax-only -Wvector-conversion -triple x86_64-apple-darwin10
+// RUN: %clang_cc1 %s -verify -fsyntax-only -Wvector-conversion -triple x86_64-apple-darwin10 -flax-vector-conversions=integer
+// FIXME: We get worse diagnostics here with -flax-vector-conversions disabled.
 typedef unsigned int v2u __attribute__ ((vector_size (8)));
 typedef int v2s __attribute__ ((vector_size (8)));
 typedef float v2f __attribute__ ((vector_size(8)));
Index: test/Sema/vector-cast.c
===
--- test/Sema/vector-cast.c
+++ test/Sema/vector-cast.c
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 -fsyntax-only %s -verify -Wvector-conversion
+// RUN: %clang_cc1 -fsyntax-only %s -verify=expected,no-lax -Wvector-conversion -flax-vector-conversions=none
+// RUN: %clang_cc1 -fsyntax-only %s -verify=expected,lax -Wvector-conversion -flax-vector-conversions=all
 
 typedef long long t1 __attribute__ ((vector_size (8)));
 typedef char t2 __attribute__ ((vector_size (16)));
@@ -41,7 +42,9 @@
 void f2(t2 X); // expected-note{{passing argument to parameter 'X' here}}
 
 void f3(t3 Y) {
-  f2(Y);  // expected-warning {{incompatible vector types passing 't3' (vector of 4 'float' values) to parameter of type 't2' (vector of 16 'char' values)}}
+  f2(Y);
+  // lax-warning@-1 {{incompatible vector types passing 't3' (vector of 4 'float' values) to parameter of type 't2' (vector of 16 'char' values)}}
+  // no-lax-error@-2 {{passing 't3' (vector of 4 'float' values) to parameter of incompatible type 't2' (vector of 16 'char' values)}}
 }
 
 typedef float float2 __attribute__ ((vector_size (8)));
@@ -58,13 +61,15 @@
   float64x2_t v = {0.0, 1.0};
   f2 += d; // expected-error {{cannot convert between scalar type 'double' and vector type 'float2' (vector of 2 'float' values) as implicit conversion would cause truncation}}
   d += f2; // expected-error {{assigning to 'double' from incompatible type 'float2' (vector of 2 'float' values)}}
-  a = 3.0 + vget_low_f64(v);
-  b = vget_low_f64(v) + 3.0;
-  c = vget_low_f64(v);
-  c -= vget_low_f64(v);
+  a = 3.0 + vget_low_f64(v); // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
+  b = vget_low_f64(v) + 3.0; // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
+  c = vget_low_f64(v); // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
+  c -= vget_low_f64(v); // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
   // LAX conversions between scalar and vector types require same size and one element sized vectors.
   d = f2; // expected-error {{assigning to 'double' from incompatible type 'float2'}}
-  d = d + f2; // expected-error {{assigning to 'double' from incompatible type 'float2'}}
+  d = d + f2;
+  // lax-error@-1 {{assigning to 'double' from incompatible type 'float2' (vector of 2 'float' values)}}
+  // no-lax-error@-2 {{cannot convert between scalar type 'double' and vector type 'float2' (vector of 2 'float' values) as implicit conversion would cause truncation}}
 }
 
 // rdar://15931426
@@ -78,6 +83,8 @@
 }
 
 void f6(vSInt32 a0) {
-  vUInt32 counter = (float16){0.0f, 0.0f, 0.0f, 0.0f}; // expected-warning {{incompatible vector types initializing 'vUInt32' (vector of 4 'unsigned int' values) with an expression of type 'float16' (vector of 4 'float' values)}}
+  vUInt32 counter = (float16){0.0f, 0.0f, 0.0f, 0.0f};
+  // lax-warning@-1 {{incompatible vector types initializing 'vUInt32' (vector of 4 'unsigned int' values) with an expression of type 'float16' (vector of 4 'float' values)}}
+  // no-lax-error@-2 {{initializing 'vUInt32' (vector of 4 'unsigned int' values) with an expression of incompatible type 'float16' (vector of 4 'float' values)}}
   counter -= a0;
 }
Index: test/Sema/vector-assign.c
===
--- test/Sema/vector-assign.c
+++ test/Sema/vector-assign.c
@@ -14,12 +14,12 @@
   
   v1 = v2; // expected-warning {{incompatible vector types assigning to 'v2s' (vector of 2 'int' values) from 'v2u' 

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith updated this revision to Diff 224130.
rsmith added a comment.

Remove special-casing of ARM NEON; let's wait for  to get fixed 
before landing this.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67678/new/

https://reviews.llvm.org/D67678

Files:
  include/clang/Basic/LangOptions.def
  test/Headers/altivec-header.c
  test/Headers/arm-neon-header.c
  test/Headers/x86-intrinsics-headers.c
  test/Headers/x86intrin-2.c
  test/Headers/x86intrin.c
  test/Sema/vector-assign.c
  test/Sema/vector-cast.c
  test/Sema/vector-ops.c

Index: test/Sema/vector-ops.c
===
--- test/Sema/vector-ops.c
+++ test/Sema/vector-ops.c
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 %s -verify -fsyntax-only -Wvector-conversion -triple x86_64-apple-darwin10
+// RUN: %clang_cc1 %s -verify -fsyntax-only -Wvector-conversion -triple x86_64-apple-darwin10 -flax-vector-conversions=integer
+// FIXME: We get worse diagnostics here with -flax-vector-conversions disabled.
 typedef unsigned int v2u __attribute__ ((vector_size (8)));
 typedef int v2s __attribute__ ((vector_size (8)));
 typedef float v2f __attribute__ ((vector_size(8)));
Index: test/Sema/vector-cast.c
===
--- test/Sema/vector-cast.c
+++ test/Sema/vector-cast.c
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 -fsyntax-only %s -verify -Wvector-conversion
+// RUN: %clang_cc1 -fsyntax-only %s -verify=expected,no-lax -Wvector-conversion -flax-vector-conversions=none
+// RUN: %clang_cc1 -fsyntax-only %s -verify=expected,lax -Wvector-conversion -flax-vector-conversions=all
 
 typedef long long t1 __attribute__ ((vector_size (8)));
 typedef char t2 __attribute__ ((vector_size (16)));
@@ -41,7 +42,9 @@
 void f2(t2 X); // expected-note{{passing argument to parameter 'X' here}}
 
 void f3(t3 Y) {
-  f2(Y);  // expected-warning {{incompatible vector types passing 't3' (vector of 4 'float' values) to parameter of type 't2' (vector of 16 'char' values)}}
+  f2(Y);
+  // lax-warning@-1 {{incompatible vector types passing 't3' (vector of 4 'float' values) to parameter of type 't2' (vector of 16 'char' values)}}
+  // no-lax-error@-2 {{passing 't3' (vector of 4 'float' values) to parameter of incompatible type 't2' (vector of 16 'char' values)}}
 }
 
 typedef float float2 __attribute__ ((vector_size (8)));
@@ -58,13 +61,15 @@
   float64x2_t v = {0.0, 1.0};
   f2 += d; // expected-error {{cannot convert between scalar type 'double' and vector type 'float2' (vector of 2 'float' values) as implicit conversion would cause truncation}}
   d += f2; // expected-error {{assigning to 'double' from incompatible type 'float2' (vector of 2 'float' values)}}
-  a = 3.0 + vget_low_f64(v);
-  b = vget_low_f64(v) + 3.0;
-  c = vget_low_f64(v);
-  c -= vget_low_f64(v);
+  a = 3.0 + vget_low_f64(v); // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
+  b = vget_low_f64(v) + 3.0; // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
+  c = vget_low_f64(v); // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
+  c -= vget_low_f64(v); // no-lax-error {{assigning to 'double' from incompatible type 'float64x1_t' (vector of 1 'double' value)}}
   // LAX conversions between scalar and vector types require same size and one element sized vectors.
   d = f2; // expected-error {{assigning to 'double' from incompatible type 'float2'}}
-  d = d + f2; // expected-error {{assigning to 'double' from incompatible type 'float2'}}
+  d = d + f2;
+  // lax-error@-1 {{assigning to 'double' from incompatible type 'float2' (vector of 2 'float' values)}}
+  // no-lax-error@-2 {{cannot convert between scalar type 'double' and vector type 'float2' (vector of 2 'float' values) as implicit conversion would cause truncation}}
 }
 
 // rdar://15931426
@@ -78,6 +83,8 @@
 }
 
 void f6(vSInt32 a0) {
-  vUInt32 counter = (float16){0.0f, 0.0f, 0.0f, 0.0f}; // expected-warning {{incompatible vector types initializing 'vUInt32' (vector of 4 'unsigned int' values) with an expression of type 'float16' (vector of 4 'float' values)}}
+  vUInt32 counter = (float16){0.0f, 0.0f, 0.0f, 0.0f};
+  // lax-warning@-1 {{incompatible vector types initializing 'vUInt32' (vector of 4 'unsigned int' values) with an expression of type 'float16' (vector of 4 'float' values)}}
+  // no-lax-error@-2 {{initializing 'vUInt32' (vector of 4 'unsigned int' values) with an expression of incompatible type 'float16' (vector of 4 'float' values)}}
   counter -= a0;
 }
Index: test/Sema/vector-assign.c
===
--- test/Sema/vector-assign.c
+++ test/Sema/vector-assign.c
@@ -14,12 +14,12 @@
   
   v1 = v2; // expected-warning {{incompatible vector types assigning to 'v2s' (vector of 2 'int' values) from 'v2u' (vector of 2 

[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith created this revision.
rsmith added a reviewer: SjoerdMeijer.
Herald added a subscriber: kristof.beyls.
Herald added a project: clang.

For ARM compilations with NEON enabled, for now we retain the old
default of -flax-vector-conversions=all, because our intrinsic header
 relies on it, and it appears to be far from straightforward
to fix that. (See PR43341.)

See proposal on cfe-dev:
http://lists.llvm.org/pipermail/cfe-dev/2019-April/062030.html


Repository:
  rC Clang

https://reviews.llvm.org/D67678

Files:
  include/clang/Basic/LangOptions.def
  lib/Basic/Targets/AArch64.cpp
  lib/Basic/Targets/AArch64.h
  lib/Basic/Targets/ARM.cpp
  lib/Basic/Targets/ARM.h
  lib/Frontend/CompilerInvocation.cpp
  test/Headers/altivec-header.c
  test/Headers/arm-neon-header.c
  test/Headers/x86-intrinsics-headers.c
  test/Headers/x86intrin-2.c
  test/Headers/x86intrin.c
  test/Sema/vector-assign.c
  test/Sema/vector-cast.c
  test/Sema/vector-ops.c

Index: test/Sema/vector-ops.c
===
--- test/Sema/vector-ops.c
+++ test/Sema/vector-ops.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 %s -verify -fsyntax-only -Wvector-conversion -triple x86_64-apple-darwin10
+// RUN: %clang_cc1 %s -verify -fsyntax-only -Wvector-conversion -triple x86_64-apple-darwin10 -flax-vector-conversions=all
 typedef unsigned int v2u __attribute__ ((vector_size (8)));
 typedef int v2s __attribute__ ((vector_size (8)));
 typedef float v2f __attribute__ ((vector_size(8)));
Index: test/Sema/vector-cast.c
===
--- test/Sema/vector-cast.c
+++ test/Sema/vector-cast.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only %s -verify -Wvector-conversion
+// RUN: %clang_cc1 -fsyntax-only %s -verify -Wvector-conversion -flax-vector-conversions=all
 
 typedef long long t1 __attribute__ ((vector_size (8)));
 typedef char t2 __attribute__ ((vector_size (16)));
Index: test/Sema/vector-assign.c
===
--- test/Sema/vector-assign.c
+++ test/Sema/vector-assign.c
@@ -14,12 +14,12 @@
   
   v1 = v2; // expected-warning {{incompatible vector types assigning to 'v2s' (vector of 2 'int' values) from 'v2u' (vector of 2 'unsigned int' values)}}
   v1 = v3; // expected-error {{assigning to 'v2s' (vector of 2 'int' values) from incompatible type 'v1s' (vector of 1 'int' value)}}
-  v1 = v4; // expected-warning {{incompatible vector types assigning to 'v2s' (vector of 2 'int' values) from 'v2f' (vector of 2 'float' values)}}
+  v1 = v4; // expected-error {{assigning to 'v2s' (vector of 2 'int' values) from incompatible type 'v2f' (vector of 2 'float' values)}}
   v1 = v5; // expected-warning {{incompatible vector types assigning to 'v2s' (vector of 2 'int' values) from 'v4ss' (vector of 4 'short' values)}}
   
   v2 = v1; // expected-warning {{incompatible vector types assigning to 'v2u' (vector of 2 'unsigned int' values) from 'v2s' (vector of 2 'int' values)}}
   v2 = v3; // expected-error {{assigning to 'v2u' (vector of 2 'unsigned int' values) from incompatible type 'v1s' (vector of 1 'int' value)}}
-  v2 = v4; // expected-warning {{incompatible vector types assigning to 'v2u' (vector of 2 'unsigned int' values) from 'v2f' (vector of 2 'float' values)}}
+  v2 = v4; // expected-error {{assigning to 'v2u' (vector of 2 'unsigned int' values) from incompatible type 'v2f' (vector of 2 'float' values)}}
   v2 = v5; // expected-warning {{incompatible vector types assigning to 'v2u' (vector of 2 'unsigned int' values) from 'v4ss' (vector of 4 'short' values)}}
   
   v3 = v1; // expected-error {{assigning to 'v1s' (vector of 1 'int' value) from incompatible type 'v2s' (vector of 2 'int' values)}}
@@ -27,15 +27,15 @@
   v3 = v4; // expected-error {{assigning to 'v1s' (vector of 1 'int' value) from incompatible type 'v2f' (vector of 2 'float' values)}}
   v3 = v5; // expected-error {{assigning to 'v1s' (vector of 1 'int' value) from incompatible type 'v4ss'}}
   
-  v4 = v1; // expected-warning {{incompatible vector types assigning to 'v2f' (vector of 2 'float' values) from 'v2s' (vector of 2 'int' values)}}
-  v4 = v2; // expected-warning {{incompatible vector types assigning to 'v2f' (vector of 2 'float' values) from 'v2u' (vector of 2 'unsigned int' values)}}
+  v4 = v1; // expected-error {{assigning to 'v2f' (vector of 2 'float' values) from incompatible type 'v2s' (vector of 2 'int' values)}}
+  v4 = v2; // expected-error {{assigning to 'v2f' (vector of 2 'float' values) from incompatible type 'v2u' (vector of 2 'unsigned int' values)}}
   v4 = v3; // expected-error {{assigning to 'v2f' (vector of 2 'float' values) from incompatible type 'v1s' (vector of 1 'int' value)}}
-  v4 = v5; // expected-warning {{incompatible vector types assigning to 'v2f' (vector of 2 'float' values) from 'v4ss' (vector of 4 'short' values)}}
+  v4 = v5; // expected-error {{assigning to 'v2f' (vector of 2 'float' values) from