On Wed, Sep 28, 2011 at 4:23 PM, Richard Guenther <richard.guent...@gmail.com> wrote: > On Mon, Sep 26, 2011 at 5:43 PM, Richard Guenther > <richard.guent...@gmail.com> wrote: >> On Mon, Sep 26, 2011 at 4:25 PM, Richard Guenther >> <richard.guent...@gmail.com> wrote: >>> On Wed, Sep 7, 2011 at 5:06 PM, Joseph S. Myers <jos...@codesourcery.com> >>> wrote: >>>> This looks like it has the same issue with maybe needing to use >>>> TYPE_MAIN_VARIANT in type comparisons as the shuffle patch. >>> >>> I don't think so, we move qualifiers to the vector type from the element >>> type >>> in make_vector_type and the tests only look at the component type. >>> >>> I am re-testing the patch currently and will commit it if that succeeds. >> >> Unfortunately gcc.c-torture/execute/vector-compare-1.c fails with -m32 >> for >> >> vector (2, double) d0; >> vector (2, double) d1; >> vector (2, long) idres; >> >> d0 = (vector (2, double)){(double)argc, 10.}; >> d1 = (vector (2, double)){0., (double)-23}; >> idres = (d0 > d1); >> >> as appearantly the type we chose to assign to (d0 > d1) is different >> from that of idres: >> >> /space/rguenther/src/svn/trunk/gcc/testsuite/gcc.c-torture/execute/vector-compare-1.c:118:5: >> error: incompatible types when assigning to type '__vector(2) long >> int' from type '__vector(2) long long int'^M >> >> Adjusting it to vector (2, long long) otoh yields, for -m64: >> >> /space/rguenther/src/svn/trunk/gcc/testsuite/gcc.c-torture/execute/vector-compare-1.c:118:5: >> error: incompatible types when assigning to type '__vector(2) long >> long int' from type '__vector(2) long int' >> >> But those two types are at least compatible from their modes. Joseph, >> should we accept mode-compatible types in assignments or maybe >> transparently convert them? > > Looks like we have a more suitable solution for these automatically > generated vector types - mark them with TYPE_VECTOR_OPAQUE. > > I'm testing the following incremental patch. > > Richard. > > Index: gcc/c-typeck.c > =================================================================== > --- gcc/c-typeck.c.orig 2011-09-28 16:22:10.000000000 +0200 > +++ gcc/c-typeck.c 2011-09-28 16:18:39.000000000 +0200 > @@ -9928,8 +9928,10 @@ build_binary_op (location_t location, en > } > > /* Always construct signed integer vector type. */ > - intt = c_common_type_for_size (TYPE_PRECISION (TREE_TYPE > (type0)), 0); > - result_type = build_vector_type (intt, TYPE_VECTOR_SUBPARTS > (type0)); > + intt = c_common_type_for_size (GET_MODE_BITSIZE > + (TYPE_MODE (TREE_TYPE (type0))), > 0); > + result_type = build_opaque_vector_type (intt, > + TYPE_VECTOR_SUBPARTS > (type0)); > converted = 1; > break; > } > @@ -10063,8 +10065,10 @@ build_binary_op (location_t location, en > } > > /* Always construct signed integer vector type. */ > - intt = c_common_type_for_size (TYPE_PRECISION (TREE_TYPE > (type0)), 0); > - result_type = build_vector_type (intt, TYPE_VECTOR_SUBPARTS > (type0)); > + intt = c_common_type_for_size (GET_MODE_BITSIZE > + (TYPE_MODE (TREE_TYPE (type0))), > 0); > + result_type = build_opaque_vector_type (intt, > + TYPE_VECTOR_SUBPARTS > (type0)); > converted = 1; > break; > }
That doesn't seem to work either. Because we treat the opaque and non-opaque variants of vector<int> as different (the opaque type isn't a variant type of the non-opaque one - something suspicious anyway). I'm going to try to apply some surgery on how we build opaque variants and then re-visit the above again. Richard.