Re: vector comparisons in C++
On Thu, Sep 20, 2012 at 10:01 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Sat, 1 Sep 2012, Marc Glisse wrote:
I have some issues with the vector-compare-2.c torture test. It passes a
vector by value (argument and return type), which is likely to warn
(although for some reason it doesn't for me, with today's compiler). And it
takes -Wno-psabi through a .x file, but those are not read in c-c++-common,
so I put it in dg-options. I would have changed the function to use
pointers, but I don't know if it specifically wants to test passing by
value...
Hello,
Pat Haugen just explained it to me: there was a default -w option in the old
location of the testcase. However, there isn't in the new one. I am thus
proposing the following, which restores the old behavior. Note that
-Wno-psabi is still needed as it is not implied by -w.
Ok.
Thanks,
Richard.
2012-09-20 Marc Glisse marc.gli...@inria.fr
PR c++/54427
* c-c++-common/torture/vector-compare-2.c: Add -w.
--
Marc Glisse
Index: c-c++-common/torture/vector-compare-2.c
===
--- c-c++-common/torture/vector-compare-2.c (revision 191585)
+++ c-c++-common/torture/vector-compare-2.c (working copy)
@@ -1,12 +1,12 @@
/* { dg-do run } */
-/* { dg-options -Wno-psabi } */
+/* { dg-options -Wno-psabi -w } */
#define vector(elcount, type) \
__attribute__((vector_size((elcount)*sizeof(type type
/* Check that constant folding in
these simple cases works. */
vector (4, int)
foo (vector (4, int) x)
{
return (x == x) + (x != x) + (x x)
+ (x x) + (x = x) + (x = x);
Re: vector comparisons in C++
On Sat, 1 Sep 2012, Marc Glisse wrote:
I have some issues with the vector-compare-2.c torture test. It passes a
vector by value (argument and return type), which is likely to warn (although
for some reason it doesn't for me, with today's compiler). And it takes
-Wno-psabi through a .x file, but those are not read in c-c++-common, so I
put it in dg-options. I would have changed the function to use pointers, but
I don't know if it specifically wants to test passing by value...
Hello,
Pat Haugen just explained it to me: there was a default -w option in the
old location of the testcase. However, there isn't in the new one. I am
thus proposing the following, which restores the old behavior. Note that
-Wno-psabi is still needed as it is not implied by -w.
2012-09-20 Marc Glisse marc.gli...@inria.fr
PR c++/54427
* c-c++-common/torture/vector-compare-2.c: Add -w.
--
Marc GlisseIndex: c-c++-common/torture/vector-compare-2.c
===
--- c-c++-common/torture/vector-compare-2.c (revision 191585)
+++ c-c++-common/torture/vector-compare-2.c (working copy)
@@ -1,12 +1,12 @@
/* { dg-do run } */
-/* { dg-options -Wno-psabi } */
+/* { dg-options -Wno-psabi -w } */
#define vector(elcount, type) \
__attribute__((vector_size((elcount)*sizeof(type type
/* Check that constant folding in
these simple cases works. */
vector (4, int)
foo (vector (4, int) x)
{
return (x == x) + (x != x) + (x x)
+ (x x) + (x = x) + (x = x);
Re: vector comparisons in C++
On 09/13/2012 07:37 PM, Marc Glisse wrote: Looks like a latent bug in fold_unary. The following seems to work in this case. Looks good. Jason
Re: vector comparisons in C++
Here is the patch I just tested. Changes compared to the previous patch
include:
* same_type_ignoring_top_level_qualifiers_p
* build_vector_type: don't use an opaque vector for the return type of
operator (not sure what the point was of making it opaque?)
* Disable BIT_AND - TRUTH_AND optimization for vectors
* Disable (type)(ab) - (ab)?type(true):type(false) for vectors.
It would be doable with vec_cond_expr, but I am not sure it helps.
* In ab|a==b - a=b, use a vector type, not boolean
* 2 more testcases (through which I discovered the issues)
I am sure there are other optimizations that do weird things, but I should
stop increasing the size of this patch... I'll update the doc in a later
patch.
Ok?
2012-09-14 Marc Glisse marc.gli...@inria.fr
PR c++/54427
gcc/ChangeLog
* fold-const.c (fold_unary_loc): Disable for VECTOR_TYPE.
(fold_binary_loc): Likewise.
* gimple-fold.c (and_comparisons_1): Handle VECTOR_TYPE.
(or_comparisons_1): Likewise.
gcc/cp/ChangeLog
* typeck.c (cp_build_binary_op) [LSHIFT_EXPR, RSHIFT_EXPR, EQ_EXPR,
NE_EXPR, LE_EXPR, GE_EXPR, LT_EXPR, GT_EXPR]: Handle VECTOR_TYPE.
gcc/testsuite/ChangeLog
* g++.dg/other/vector-compare.C: New testcase.
* gcc/testsuite/c-c++-common/vector-compare-3.c: New testcase.
* gcc.dg/vector-shift.c: Move ...
* c-c++-common/vector-shift.c: ... here.
* gcc.dg/vector-shift1.c: Move ...
* c-c++-common/vector-shift1.c: ... here.
* gcc.dg/vector-shift3.c: Move ...
* c-c++-common/vector-shift3.c: ... here.
* gcc.dg/vector-compare-1.c: Move ...
* c-c++-common/vector-compare-1.c: ... here.
* gcc.dg/vector-compare-2.c: Move ...
* c-c++-common/vector-compare-2.c: ... here.
* gcc.c-torture/execute/vector-compare-1.c: Move ...
* c-c++-common/torture/vector-compare-1.c: ... here.
* gcc.c-torture/execute/vector-compare-2.x: Delete.
* gcc.c-torture/execute/vector-compare-2.c: Move ...
* c-c++-common/torture/vector-compare-2.c: ... here.
* gcc.c-torture/execute/vector-shift.c: Move ...
* c-c++-common/torture/vector-shift.c: ... here.
* gcc.c-torture/execute/vector-shift2.c: Move ...
* c-c++-common/torture/vector-shift2.c: ... here.
* gcc.c-torture/execute/vector-subscript-1.c: Move ...
* c-c++-common/torture/vector-subscript-1.c: ... here.
* gcc.c-torture/execute/vector-subscript-2.c: Move ...
* c-c++-common/torture/vector-subscript-2.c: ... here.
* gcc.c-torture/execute/vector-subscript-3.c: Move ...
* c-c++-common/torture/vector-subscript-3.c: ... here.
--
Marc GlisseIndex: gcc/testsuite/g++.dg/other/vector-compare.C
===
--- gcc/testsuite/g++.dg/other/vector-compare.C (revision 0)
+++ gcc/testsuite/g++.dg/other/vector-compare.C (revision 0)
@@ -0,0 +1,38 @@
+/* { dg-do compile } */
+/* { dg-options -std=gnu++11 -Wall } */
+
+// Check that we can compare vector types that really are the same through
+// typedefs.
+
+typedef float v4f __attribute__((vector_size(4*sizeof(float;
+
+template class T void eat (T) {}
+
+template class T, int n
+struct Vec
+{
+ typedef T type __attribute__((vector_size(4*sizeof(T;
+
+ template class U
+ static void fun (type const t, U u) { eat (t u); }
+};
+
+long long
+f (v4f *x, v4f const *y)
+{
+ return ((*x *y) | (*x = *y))[2];
+}
+
+int main ()
+{
+ v4f x = {0,1,2,3};
+ typedef decltype (x x) v4i;
+ v4i y = {4,5,6,7}; // v4i is not opaque
+ Vecconst volatile float,4::type f = {-1,5,2,3.1};
+ v4i c = (x == f) == y;
+ eat (c);
+ Vecconst volatile float,4::fun (f, x);
+ Vecconst volatile float,4::fun (x, f);
+ Vecconst volatile float,4::fun (f, f);
+ Vecconst volatile float,4::fun (x, x);
+}
Property changes on: gcc/testsuite/g++.dg/other/vector-compare.C
___
Added: svn:keywords
+ Author Date Id Revision URL
Added: svn:eol-style
+ native
Index: gcc/testsuite/c-c++-common/vector-compare-3.c
===
--- gcc/testsuite/c-c++-common/vector-compare-3.c (revision 0)
+++ gcc/testsuite/c-c++-common/vector-compare-3.c (revision 0)
@@ -0,0 +1,25 @@
+/* { dg-do compile } */
+/* { dg-options -O2 } */
+
+typedef int v4i __attribute__((vector_size(4*sizeof(int;
+
+// fold should not turn (vec_other)(xy) into (xy)?vec_other(-1):vec_other(0).
+
+void use (v4i const *z);
+
+void
+f (v4i *x, v4i *y)
+{
+ v4i const zz = *x *y;
+ use (zz);
+}
+
+// Optimizations shouldn't introduce a boolean type in there
+
+void
+g (v4i *x, v4i const *y, v4i *z, v4i *t)
+{
+ *z = *x *y | *x == *y;
+ *t = *x *y *x *y;
+}
+
Property changes on: gcc/testsuite/c-c++-common/vector-compare-3.c
Re: vector comparisons in C++
On 09/14/2012 09:59 AM, Marc Glisse wrote: * build_vector_type: don't use an opaque vector for the return type of operator (not sure what the point was of making it opaque?) I think the point was to allow conversion of the result to a different vector type. Why do you want it not to be opaque? * Disable (type)(ab) - (ab)?type(true):type(false) for vectors. It would be doable with vec_cond_expr, but I am not sure it helps. Right. It certainly doesn't help for integer vectors. + error_at (location, comparing vectors with different + element types); Let's print the vector types in these errors. Jason
Re: vector comparisons in C++
On Fri, 14 Sep 2012, Jason Merrill wrote: On 09/14/2012 09:59 AM, Marc Glisse wrote: * build_vector_type: don't use an opaque vector for the return type of operator (not sure what the point was of making it opaque?) I think the point was to allow conversion of the result to a different vector type. Ah, I see. I'll change it back to opaque and remove that use from the testcase. I noticed that for the fold patch, I am using once opaque and once not-opaque, I'll make them both opaque, although it probably doesn't matter once we are out of the front-end. Why do you want it not to be opaque? I wanted to use decltype(xx) to find an integer vector type of the same size as x, and then actually be able to use it. Being opaque, it refuses to be initialized (cp/decl.c:5550). Maybe decltype (and others?) could return non-opaque types? + error_at (location, comparing vectors with different + element types); Let's print the vector types in these errors. Type is %qT right? I see a number of %q#T but can't remember where the doc is. Well, I'll try both and see what happens. Thanks, -- Marc Glisse
Re: vector comparisons in C++
On 09/14/2012 11:03 AM, Marc Glisse wrote: I wanted to use decltype(xx) to find an integer vector type of the same size as x, and then actually be able to use it. Being opaque, it refuses to be initialized (cp/decl.c:5550). Maybe decltype (and others?) could return non-opaque types? That sounds like the right answer. Type is %qT right? I see a number of %q#T but can't remember where the doc is. Well, I'll try both and see what happens. Either one works; the # asks for more verbose output. Jason
Re: vector comparisons in C++
On Fri, 14 Sep 2012, Jason Merrill wrote:
On 09/14/2012 11:03 AM, Marc Glisse wrote:
I wanted to use decltype(xx) to find an integer vector type of the same
size as x, and then actually be able to use it. Being opaque, it refuses
to be initialized (cp/decl.c:5550). Maybe decltype (and others?) could
return non-opaque types?
That sounds like the right answer.
Ok, I'll open a bugzilla to remember to try that later.
Type is %qT right? I see a number of %q#T but can't remember where the
doc is. Well, I'll try both and see what happens.
Either one works; the # asks for more verbose output.
The %qT looked good enough to me (it prints the alias and the type). I
added the types in an inform because the line was already getting long,
I hope that's ok.
The attached just finished the testsuite (changelog unchanged).
--
Marc GlisseIndex: gcc/gimple-fold.c
===
--- gcc/gimple-fold.c (revision 191291)
+++ gcc/gimple-fold.c (working copy)
@@ -23,20 +23,21 @@ along with GCC; see the file COPYING3.
#include coretypes.h
#include tm.h
#include tree.h
#include flags.h
#include function.h
#include dumpfile.h
#include tree-flow.h
#include tree-ssa-propagate.h
#include target.h
#include gimple-fold.h
+#include langhooks.h
/* Return true when DECL can be referenced from current unit.
FROM_DECL (if non-null) specify constructor of variable DECL was taken from.
We can get declarations that are not possible to reference for various
reasons:
1) When analyzing C++ virtual tables.
C++ virtual tables do have known constructors even
when they are keyed to other compilation unit.
Those tables can contain pointers to methods and vars
@@ -1685,41 +1686,51 @@ and_var_with_comparison_1 (gimple stmt,
(OP1A CODE1 OP1B) and (OP2A CODE2 OP2B), respectively.
If this can be done without constructing an intermediate value,
return the resulting tree; otherwise NULL_TREE is returned.
This function is deliberately asymmetric as it recurses on SSA_DEFs
in the first comparison but not the second. */
static tree
and_comparisons_1 (enum tree_code code1, tree op1a, tree op1b,
enum tree_code code2, tree op2a, tree op2b)
{
+ tree truth_type = boolean_type_node;
+ if (TREE_CODE (TREE_TYPE (op1a)) == VECTOR_TYPE)
+{
+ tree vec_type = TREE_TYPE (op1a);
+ tree elem = lang_hooks.types.type_for_size
+ (GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (vec_type))), 0);
+ truth_type = build_opaque_vector_type (elem,
+TYPE_VECTOR_SUBPARTS (vec_type));
+}
+
/* First check for ((x CODE1 y) AND (x CODE2 y)). */
if (operand_equal_p (op1a, op2a, 0)
operand_equal_p (op1b, op2b, 0))
{
/* Result will be either NULL_TREE, or a combined comparison. */
tree t = combine_comparisons (UNKNOWN_LOCATION,
TRUTH_ANDIF_EXPR, code1, code2,
- boolean_type_node, op1a, op1b);
+ truth_type, op1a, op1b);
if (t)
return t;
}
/* Likewise the swapped case of the above. */
if (operand_equal_p (op1a, op2b, 0)
operand_equal_p (op1b, op2a, 0))
{
/* Result will be either NULL_TREE, or a combined comparison. */
tree t = combine_comparisons (UNKNOWN_LOCATION,
TRUTH_ANDIF_EXPR, code1,
swap_tree_comparison (code2),
- boolean_type_node, op1a, op1b);
+ truth_type, op1a, op1b);
if (t)
return t;
}
/* If both comparisons are of the same value against constants, we might
be able to merge them. */
if (operand_equal_p (op1a, op2a, 0)
TREE_CODE (op1b) == INTEGER_CST
TREE_CODE (op2b) == INTEGER_CST)
{
@@ -2147,41 +2158,51 @@ or_var_with_comparison_1 (gimple stmt,
(OP1A CODE1 OP1B) and (OP2A CODE2 OP2B), respectively.
If this can be done without constructing an intermediate value,
return the resulting tree; otherwise NULL_TREE is returned.
This function is deliberately asymmetric as it recurses on SSA_DEFs
in the first comparison but not the second. */
static tree
or_comparisons_1 (enum tree_code code1, tree op1a, tree op1b,
enum tree_code code2, tree op2a, tree op2b)
{
+ tree truth_type = boolean_type_node;
+ if (TREE_CODE (TREE_TYPE (op1a)) == VECTOR_TYPE)
+{
+ tree vec_type = TREE_TYPE (op1a);
+ tree elem = lang_hooks.types.type_for_size
+ (GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (vec_type))), 0);
+ truth_type = build_opaque_vector_type (elem,
+TYPE_VECTOR_SUBPARTS (vec_type));
+}
+
/* First check for ((x CODE1 y) OR (x CODE2 y)). */
if (operand_equal_p
Re: vector comparisons in C++
On 09/14/2012 12:33 PM, Marc Glisse wrote: Ok, I'll open a bugzilla to remember to try that later. OK. The attached just finished the testsuite (changelog unchanged). This patch is OK. Jason
Re: vector comparisons in C++
On Fri, 14 Sep 2012, Jason Merrill wrote: [decltype of opaque vector] I think a simple TYPE_MAIN_VARIANT will do, I just need to find where to add it, and how much to constrain that change. Type deduction in templates and auto already seem to remove opacity :-) This patch is OK. Committed. Thank you for all the quick comments, -- Marc Glisse
Re: vector comparisons in C++
On 08/31/2012 06:20 PM, Marc Glisse wrote: this patch copies some more vector extensions from the C front-end to the C++ front-end. There seemed to be some reluctance to add those, but I guess a patch is the best way to ask What was the reluctance? It seems clear to me that if we support the type, we should support these operations. Following the OpenCL standard makes sense to me. I have some issues with the vector-compare-2.c torture test. It passes a vector by value (argument and return type), which is likely to warn (although for some reason it doesn't for me, with today's compiler). And it takes -Wno-psabi through a .x file, but those are not read in c-c++-common, so I put it in dg-options. That sounds fine. I would have changed the function to use pointers, but I don't know if it specifically wants to test passing by value... I don't know either. + if (TREE_TYPE (type0) != TREE_TYPE (type1)) I think this should use same_type_ignoring_top_level_qualifiers_p. Jason
Re: vector comparisons in C++
On Thu, 13 Sep 2012, Jason Merrill wrote: On 08/31/2012 06:20 PM, Marc Glisse wrote: this patch copies some more vector extensions from the C front-end to the C++ front-end. There seemed to be some reluctance to add those, but I guess a patch is the best way to ask What was the reluctance? It seems clear to me that if we support the type, we should support these operations. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033 In comments 1 and 7, Richard Guenther didn't seem too enthusiastic about any vector-related extension to the C++ front-end. Some users (other PRs) asked instead that we make vector types class-like so users can define their own operator(vec,vec). Following the OpenCL standard makes sense to me. I should really take a look at that standard... 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 copied this directly from the C front-end, which I guess split the test to have 2 different error messages. I could call same_type_ignoring_top_level_qualifiers_p and only if it fails do more specific tests to determine the error message (or I could even merge the 2 error messages, vectors with different types should be good enough). Did I understand your suggestion correctly? Thank you for your comments, -- Marc Glisse
Re: vector comparisons in C++
On Sep 13, 2012, at 8:47 AM, Marc Glisse marc.gli...@inria.fr wrote: What was the reluctance? It seems clear to me that if we support the type, we should support these operations. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033 In comments 1 and 7, Richard Guenther didn't seem too enthusiastic about any vector-related extension to the C++ front-end. C++, as designed, wants to be a proper super set of C (not that it is, or ever will be), so, in general, it wants things that work in C to also work in C++. Richard is right there are more 2,3 and 4 features at a time interaction problems that make C++ support in general for any new feature tend to be slightly non-trivial, but that, while true, I don't think should dissuade us. Now, we might recommend people use some better, C++ish to solve their problems, but, for people that just want existing C code to just compile as C++ code… having the support is nice.
Re: vector comparisons in C++
On 09/13/2012 11:47 AM, Marc Glisse wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033 In comments 1 and 7, Richard Guenther didn't seem too enthusiastic about any vector-related extension to the C++ front-end. Some users (other PRs) asked instead that we make vector types class-like so users can define their own operator(vec,vec). 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. Following the OpenCL standard makes sense to me. I should really take a look at that standard... My impression is that the C vector support was written to follow OpenCL, so extending the same semantics to C++ would also follow OpenCL. 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. Jason
Re: vector comparisons in C++
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 xy;}
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_EXPRconst 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
Re: vector comparisons in C++
On Thu, 13 Sep 2012, Jason Merrill wrote:
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.
I forgot to say: it is always possible to do the operations elementwise:
__m128d x,y;
__m128i cmp={(x[0]y[0])?-1:0,(x[1]y[1])?-1:0};
(__m128d is a pair of double, __m128i a pair of long long)
This counts on the middle-end to recognize the patterns. But that will
have to be implemented anyway, possibly for sqrt, and certainly for type
conversions:
__m128i i;
__m128d x={i[0],i[1]};
because the sensible syntax (__m128d)i has been taken to mean
*(__m128d*)i :-(
(it is also possible to add __builtin_convert, __builtin_math_sqrt, etc)
--
Marc Glisse
Re: vector comparisons in C++
Any comment? http://gcc.gnu.org/ml/gcc-patches/2012-08/msg02098.html Maybe separately on the technical and political aspects? On Sat, 1 Sep 2012, Marc Glisse wrote: With the patch... On Sat, 1 Sep 2012, Marc Glisse wrote: Hello, this patch copies some more vector extensions from the C front-end to the C++ front-end. There seemed to be some reluctance to add those, but I guess a patch is the best way to ask. Note that I only added the vector x vector operations, not the vector x scalar ones. I have some issues with the vector-compare-2.c torture test. It passes a vector by value (argument and return type), which is likely to warn (although for some reason it doesn't for me, with today's compiler). And it takes -Wno-psabi through a .x file, but those are not read in c-c++-common, so I put it in dg-options. I would have changed the function to use pointers, but I don't know if it specifically wants to test passing by value... 2012-08-31 Marc Glisse marc.gli...@inria.fr PR c++/54427 cp/ChangeLog * typeck.c (cp_build_binary_op) [LSHIFT_EXPR, RSHIFT_EXPR, EQ_EXPR, NE_EXPR, LE_EXPR, GE_EXPR, LT_EXPR, GT_EXPR]: Handle VECTOR_TYPE. testsuite/ChangeLog * gcc.dg/vector-shift.c: Move ... * c-c++-common/vector-shift.c: ... here. * gcc.dg/vector-shift1.c: Move ... * c-c++-common/vector-shift1.c: ... here. * gcc.dg/vector-shift3.c: Move ... * c-c++-common/vector-shift3.c: ... here. * gcc.dg/vector-compare-1.c: Move ... * c-c++-common/vector-compare-1.c: ... here. * gcc.dg/vector-compare-2.c: Move ... * c-c++-common/vector-compare-2.c: ... here. * gcc.c-torture/execute/vector-compare-1.c: Move ... * c-c++-common/torture/vector-compare-1.c: ... here. * gcc.c-torture/execute/vector-compare-2.x: Delete. * gcc.c-torture/execute/vector-compare-2.c: Move ... * c-c++-common/torture/vector-compare-2.c: ... here. * gcc.c-torture/execute/vector-shift.c: Move ... * c-c++-common/torture/vector-shift.c: ... here. * gcc.c-torture/execute/vector-shift2.c: Move ... * c-c++-common/torture/vector-shift2.c: ... here. * gcc.c-torture/execute/vector-subscript-1.c: Move ... * c-c++-common/torture/vector-subscript-1.c: ... here. * gcc.c-torture/execute/vector-subscript-2.c: Move ... * c-c++-common/torture/vector-subscript-2.c: ... here. * gcc.c-torture/execute/vector-subscript-3.c: Move ... * c-c++-common/torture/vector-subscript-3.c: ... here. -- Marc Glisse
Re: vector comparisons in C++
With the patch...
On Sat, 1 Sep 2012, Marc Glisse wrote:
Hello,
this patch copies some more vector extensions from the C front-end to the C++
front-end. There seemed to be some reluctance to add those, but I guess a
patch is the best way to ask. Note that I only added the vector x vector
operations, not the vector x scalar ones.
I have some issues with the vector-compare-2.c torture test. It passes a
vector by value (argument and return type), which is likely to warn (although
for some reason it doesn't for me, with today's compiler). And it takes
-Wno-psabi through a .x file, but those are not read in c-c++-common, so I
put it in dg-options. I would have changed the function to use pointers, but
I don't know if it specifically wants to test passing by value...
2012-08-31 Marc Glisse marc.gli...@inria.fr
PR c++/54427
cp/ChangeLog
* typeck.c (cp_build_binary_op) [LSHIFT_EXPR, RSHIFT_EXPR, EQ_EXPR,
NE_EXPR, LE_EXPR, GE_EXPR, LT_EXPR, GT_EXPR]: Handle VECTOR_TYPE.
testsuite/ChangeLog
* gcc.dg/vector-shift.c: Move ...
* c-c++-common/vector-shift.c: ... here.
* gcc.dg/vector-shift1.c: Move ...
* c-c++-common/vector-shift1.c: ... here.
* gcc.dg/vector-shift3.c: Move ...
* c-c++-common/vector-shift3.c: ... here.
* gcc.dg/vector-compare-1.c: Move ...
* c-c++-common/vector-compare-1.c: ... here.
* gcc.dg/vector-compare-2.c: Move ...
* c-c++-common/vector-compare-2.c: ... here.
* gcc.c-torture/execute/vector-compare-1.c: Move ...
* c-c++-common/torture/vector-compare-1.c: ... here.
* gcc.c-torture/execute/vector-compare-2.x: Delete.
* gcc.c-torture/execute/vector-compare-2.c: Move ...
* c-c++-common/torture/vector-compare-2.c: ... here.
* gcc.c-torture/execute/vector-shift.c: Move ...
* c-c++-common/torture/vector-shift.c: ... here.
* gcc.c-torture/execute/vector-shift2.c: Move ...
* c-c++-common/torture/vector-shift2.c: ... here.
* gcc.c-torture/execute/vector-subscript-1.c: Move ...
* c-c++-common/torture/vector-subscript-1.c: ... here.
* gcc.c-torture/execute/vector-subscript-2.c: Move ...
* c-c++-common/torture/vector-subscript-2.c: ... here.
* gcc.c-torture/execute/vector-subscript-3.c: Move ...
* c-c++-common/torture/vector-subscript-3.c: ... here.
--
Marc GlisseIndex: cp/typeck.c
===
--- cp/typeck.c (revision 190842)
+++ cp/typeck.c (working copy)
@@ -3977,21 +3977,29 @@ cp_build_binary_op (location_t location,
case TRUTH_AND_EXPR:
case TRUTH_OR_EXPR:
result_type = boolean_type_node;
break;
/* Shift operations: result has same type as first operand;
always convert second operand to int.
Also set SHORT_SHIFT if shifting rightward. */
case RSHIFT_EXPR:
- if (code0 == INTEGER_TYPE code1 == INTEGER_TYPE)
+ if (code0 == VECTOR_TYPE code1 == VECTOR_TYPE
+ TREE_CODE (TREE_TYPE (type0)) == INTEGER_TYPE
+ TREE_CODE (TREE_TYPE (type1)) == INTEGER_TYPE
+ TYPE_VECTOR_SUBPARTS (type0) == TYPE_VECTOR_SUBPARTS (type1))
+ {
+ result_type = type0;
+ converted = 1;
+ }
+ else if (code0 == INTEGER_TYPE code1 == INTEGER_TYPE)
{
result_type = type0;
if (TREE_CODE (op1) == INTEGER_CST)
{
if (tree_int_cst_lt (op1, integer_zero_node))
{
if ((complain tf_warning)
c_inhibit_evaluation_warnings == 0)
warning (0, right shift count is negative);
}
@@ -4006,21 +4014,29 @@ cp_build_binary_op (location_t location,
/* Convert the shift-count to an integer, regardless of
size of value being shifted. */
if (TYPE_MAIN_VARIANT (TREE_TYPE (op1)) != integer_type_node)
op1 = cp_convert (integer_type_node, op1, complain);
/* Avoid converting op1 to result_type later. */
converted = 1;
}
break;
case LSHIFT_EXPR:
- if (code0 == INTEGER_TYPE code1 == INTEGER_TYPE)
+ if (code0 == VECTOR_TYPE code1 == VECTOR_TYPE
+ TREE_CODE (TREE_TYPE (type0)) == INTEGER_TYPE
+ TREE_CODE (TREE_TYPE (type1)) == INTEGER_TYPE
+ TYPE_VECTOR_SUBPARTS (type0) == TYPE_VECTOR_SUBPARTS (type1))
+ {
+ result_type = type0;
+ converted = 1;
+ }
+ else if (code0 == INTEGER_TYPE code1 == INTEGER_TYPE)
{
result_type = type0;
if (TREE_CODE (op1) == INTEGER_CST)
{
if (tree_int_cst_lt (op1, integer_zero_node))
{
if ((complain tf_warning)
c_inhibit_evaluation_warnings == 0)
warning (0, left shift count is negative);
