vbyakovlcl added inline comments.
================
Comment at: llvm/tools/clang/lib/Sema/SemaExpr.cpp:8787
}
+ if (!S.LangOpts.OpenCL && !S.LangOpts.ZVector) {
+ const BuiltinType *LHSBT = LHSEleType->getAs<clang::BuiltinType>();
----------------
bruno wrote:
> vbyakovlcl wrote:
> > bruno wrote:
> > > Besides `__ext_vector_type__`, would this also trigger for `vector_size`?
> > > Right now this is an error for `vector_size` primarily because the number
> > > of elements is different, can you confirm this won't change?
> > I compare vector element sizes, so there must not be any differencies
> > caused by different triggers. I added additional type definitions to the
> > tests. All compiles fain.
>
> I don't think this is right. When I try to compile similar code for
> `vector_size` without your patch, I get the errors:
>
> /tmp/x.c:80:15: error: vector operands do not have the same number of
> elements ('vector_int8n' (vector of 2 'int' values) and 'vector_uchar8n'
> (vector of 8 'unsigned char' values))
> vi8n = vi8n << vuc8n; // expected-warning {{vector operands do not have the
> same elements sizes}}
> ~~~~ ^ ~~~~~
> /tmp/x.c:81:17: error: vector operands do not have the same number of
> elements ('vector_uchar8n' (vector of 8 'unsigned char' values) and
> 'vector_int8n' (vector of 2 'int' values))
> vuc8n = vuc8n << vi8n; // expected-warning {{vector operands do not have
> the same elements sizes}}
> ~~~~~ ^ ~~~~
> /tmp/x.c:82:17: error: vector operands do not have the same number of
> elements ('vector_ushort8n' (vector of 4 'unsigned short' values) and
> 'vector_uint8n' (vector of 2 'unsigned int' values))
> vus8n = vus8n << vui8n; // expected-warning {{vector operands do not have
> the same elements sizes}}
> ~~~~~ ^ ~~~~~
> /tmp/x.c:83:17: error: vector operands do not have the same number of
> elements ('vector_uint8n' (vector of 2 'unsigned int' values) and
> 'vector_short8n' (vector of 4 'short' values))
> vui8n = vui8n << vs8n; // expected-warning {{vector operands do not have
> the same elements sizes}}
> ~~~~~ ^ ~~~~
>
> Given your test changes, it seems that now, instead of "vector operands do
> not have the same number of elements" we would get "vector operands do not
> have the same elements sizes". I rather we stay with the first. Additionally,
> even if we had "vector operands do not have the same elements sizes" for
> `vector_size`, this should never be demoted to a warning.
Argument of a GNU vector size attribute specifies vector size measured in
bytes(see https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html). So you
got right diagnostics. Both compilers with and without my changes print the
same diagnostics for yours case. Here is a small testcase used both GNU and
clang extensions
$ cat bruno.c
typedef __attribute__((__ext_vector_type__(8))) int vector_int8;
typedef __attribute__((__ext_vector_type__(8))) unsigned char vector_uchar8;
typedef __attribute__((vector_size(8))) int vector_int8n;
typedef __attribute__((vector_size(8))) unsigned char vector_uchar8n;
vector_int8 vi8;
vector_uchar8 vuc8;
vector_int8n vi8n;
vector_uchar8n vuc8n;
int foo() {
vi8 = vi8 << vuc8;
vi8n = vi8n << vuc8n;
$ clang -c bruno.c -Wno-error-vec-elem-size
bruno.c:13:13: warning: vector operands do not have the same elements sizes
('vector_int8' (vector of 8 'int' values) and 'vector_uchar8' (vector of 8
'unsigned char' values)) [-Wvec-elem-size]
vi8 = vi8 << vuc8;
~~~ ^ ~~~~
bruno.c:14:15: error: vector operands do not have the same number of elements
('vector_int8n' (vector of 2 'int' values) and 'vector_uchar8n' (vector of 8
'unsigned char' values))
vi8n = vi8n << vuc8n;
The compiler without the changes prints the second error only (bruno.c:14:15).
================
Comment at: llvm/tools/clang/lib/Sema/SemaExpr.cpp:8795-8798
+ if (S.Diags.getDiagnosticLevel(
+ diag::warn_typecheck_vector_element_sizes_not_equal, Loc) ==
+ DiagnosticsEngine::Level::Error)
+ return QualType();
----------------
majnemer wrote:
> Why `return QualType()` here? Would returning `LHSType` provide confusing or
> incorrect diagnostics?
This is really excessive. Thanks.
https://reviews.llvm.org/D24669
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
