On Thu, 13 Sep 2012, Jason Merrill wrote:
I don't know either.
+ if (TREE_TYPE (type0) != TREE_TYPE (type1))
I think this should use same_type_ignoring_top_level_qualifiers_p.
Hmm, I assume you mean
same_type_ignoring_top_level_qualifiers_p (type0, type1)
which would replace both this test and
TYPE_VECTOR_SUBPARTS (type0) != TYPE_VECTOR_SUBPARTS (type1)
below?
I was thinking just for the first test, but I suppose that would work too.
My concern is that vectors of typedefs of the same type need to be
compatible.
Oh, so you meant something like:
same_type_ignoring_top_level_qualifiers_p (TREE_TYPE (type0), TREE_TYPE (type1))
? I thought the element types of vectors were already kind of
canonicalized. build_vector_type uses TYPE_MAIN_VARIANT (although it does
handle the case where this is not its own TYPE_CANONICAL). And when I
tried making a vector of T where T was a typedef for const int, I got a
const vector of int instead, which I thought was pretty cool. But I agree
that using same_type_ignoring_top_level_qualifiers_p is safer and can't
hurt, plus it will keep the code close enough to the one in the C
front-end.
While checking my facts for the previous paragraph, I got an ICE :-(
typedef int vec __attribute__((vector_size(16)));
vec const f(vec x,vec y){return x<y;}
cc.c:2:11: internal compiler error: in prepare_cmp_insn, at optabs.c:4176
The same program compiles with gcc (prepare_cmp_insn isn't called), but
ICEs with g++. Looking at the 003t.original tree dump, the C one looks
like:
return VIEW_CONVERT_EXPR<const vec>(x < y);
while the C++ one looks like:
return <retval> = x < y ? { -1, -1, -1, -1 } : { 0, 0, 0, 0 };
or in raw form:
gimple_cond <lt_expr, x, y, <D.2200>, <D.2201>>
gimple_label <<D.2200>>
gimple_assign <vector_cst, iftmp.0, { -1, -1, -1, -1 }, NULL, NULL>
gimple_goto <<D.2202>>
gimple_label <<D.2201>>
gimple_assign <vector_cst, iftmp.0, { 0, 0, 0, 0 }, NULL, NULL>
gimple_label <<D.2202>>
gimple_assign <var_decl, D.2198, iftmp.0, NULL, NULL>
gimple_return <D.2198>
That doesn't look very vector-like... I'll investigate before resending
the patch.
As Mike says, we want code that works in C to work in C++ too as much as
possible. Furthermore, this builtin support would be useful for implementing
a C++ class for vector arithmetic, just as it is with std::complex. I'm not
aware of any other portable way to implement such a class.
Ok, thanks to both of you.
--
Marc Glisse
