altivec still broken?!

altivec still broken?!

[Aldy Hernandez]

Paolo.

AltiVec is still broken after your changes to comptypes().  I thought
you were taking up rth's approach and finishing it up?

AltiVec needs fixing, be it by following Richard's advice or reverting
your patch.

Aldy

Re: altivec still broken?!

[Paolo Bonzini]

> AltiVec is still broken after your changes to comptypes().  I thought
> you were taking up rth's approach and finishing it up?

But it never got reviewed despite a ping.

Paolo

Re: altivec still broken?!

[Paolo Bonzini]

Paolo Bonzini wrote:
>> AltiVec is still broken after your changes to comptypes().  I thought
>> you were taking up rth's approach and finishing it up?
> 
> But it never got reviewed despite a ping.
> 
> Paolo

To be clear: that means, the change to comptypes() that would have fixed 
PR/14899 until the rewrite, never got reviewed.

Paolo

Re: altivec still broken?!

[Aldy Hernandez]

>>>>> "Paolo" == Paolo Bonzini <bonzini@gnu.org> writes:

 >> AltiVec is still broken after your changes to comptypes().  I thought
 >> you were taking up rth's approach and finishing it up?

 > But it never got reviewed despite a ping.

I think rth had some issues with it being incomplete, but I'm not
sure.  Rth, can you elaborate?

Re: altivec still broken?!

[Paolo Bonzini]

I actually found a bug that is solved in my implementation of comptypes. 
  It is a contrived example and it is in C++, but is indeed a bug.

1  template <class T> class X {
2  };
3
4  template <> class X<__ev64_opaque__> {
5  };
6
7  typedef int v2si __attribute__ ((vector_size (8)));
8
9  template <> class X<v2si> {
10 };

With my patch, this compiles.  With rth's proposed resolution
of comptypes for vector types, instead it gives a wrong error

/home/utente/aaa.c:9: error: redefinition of `class X<int __vector__>'
/home/utente/aaa.c:4: error: previous definition of `class X<int 
__vector__>'

Paolo

Re: altivec still broken?!

[Ziemowit Laski]

I suspect we may be in need of a target hook :-) for VECTOR_TYPE 
comparison, since it appears that SPE and AltiVec (not to mention 
MMX/SSE) may require different semantics in this regard.  A 
one-size-fits-all approach for vectors may not be feasible.

My 2 zlotys,

--Zem

On 29 Apr 2004, at 10.02, Paolo Bonzini wrote:

> I actually found a bug that is solved in my implementation of 
> comptypes.  It is a contrived example and it is in C++, but is indeed 
> a bug.
>
> 1  template <class T> class X {
> 2  };
> 3
> 4  template <> class X<__ev64_opaque__> {
> 5  };
> 6
> 7  typedef int v2si __attribute__ ((vector_size (8)));
> 8
> 9  template <> class X<v2si> {
> 10 };
>
> With my patch, this compiles.  With rth's proposed resolution
> of comptypes for vector types, instead it gives a wrong error
>
> /home/utente/aaa.c:9: error: redefinition of `class X<int __vector__>'
> /home/utente/aaa.c:4: error: previous definition of `class X<int 
> __vector__>'
>
> Paolo
>
>
>

Re: altivec still broken?!

[Paolo Bonzini]

Ziemowit Laski wrote:
> I suspect we may be in need of a target hook :-) for VECTOR_TYPE 
> comparison, since it appears that SPE and AltiVec (not to mention 
> MMX/SSE) may require different semantics in this regard.  A 
> one-size-fits-all approach for vectors may not be feasible.

Hmmm... this seems very much overkill...

The C++ example I posted is just a case in which we see the difference 
between being the same type vs. having a default conversion.  Opaque 
types are the same type as other opaque types, but have a default 
conversion from and to all other vector types.

Paolo

Re: altivec still broken?!

[Paolo Bonzini]

> If so, why the change at all.  What code would it affect?

I just felt it was right this way... I did not know what code it would 
affect, but I've now found an answer which I wrote in my other 
message---template specialization---and in that case it fixes bugs.

Paolo

Re: altivec still broken?!

[Paolo Bonzini]

> If so, why the change at all.  What code would it affect?

I just felt it was right this way... I did not know what code it would 
affect, but I've now found an answer which I wrote in my other 
message---template specialization---and in that case it fixes bugs.

Paolo

Re: altivec still broken?!

[aldyh]

On Thu, Apr 29, 2004 at 04:17:51PM +0200, carlo.bonzini@libero.it wrote:

(copying list)

> > Are you changing the behavior of opaque types?
> 
> No, except with respect to __builtin_types_compatible_p, which does not happen
> anyway because AltiVec does not use them.

Let me see if I get this right...

You are changing the behavior of opaque types with respect to
__builtin_types_compatible_p?  If so, we don't really care about a
change in this functionality because SPE uses opaque types but does
NOT use __builtin_types_compatible_p.  So, nothing changes.

OTOH, if you change the behavior of opaque types wrt
__builtin_types_compatible_p, this doesn't affect AltiVec either
because AltiVec uses __builtin_types_compatible_p but does NOT use
opaque types.

Agreed?

If so, why the change at all.  What code would it affect?

Aldy