* altivec still broken?!
@ 2004-04-27 0:56 Aldy Hernandez
2004-04-27 11:07 ` Paolo Bonzini
2004-04-29 20:10 ` Paolo Bonzini
0 siblings, 2 replies; 10+ messages in thread
From: Aldy Hernandez @ 2004-04-27 0:56 UTC (permalink / raw)
To: gcc, rth, bonzini
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: altivec still broken?!
2004-04-27 0:56 altivec still broken?! Aldy Hernandez
@ 2004-04-27 11:07 ` Paolo Bonzini
2004-04-27 11:55 ` Paolo Bonzini
2004-04-27 22:15 ` Aldy Hernandez
2004-04-29 20:10 ` Paolo Bonzini
1 sibling, 2 replies; 10+ messages in thread
From: Paolo Bonzini @ 2004-04-27 11:07 UTC (permalink / raw)
To: gcc
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: altivec still broken?!
2004-04-27 0:56 altivec still broken?! Aldy Hernandez
2004-04-27 11:07 ` Paolo Bonzini
@ 2004-04-29 20:10 ` Paolo Bonzini
2004-04-29 21:21 ` Ziemowit Laski
1 sibling, 1 reply; 10+ messages in thread
From: Paolo Bonzini @ 2004-04-29 20:10 UTC (permalink / raw)
To: Aldy Hernandez; +Cc: gcc, rth
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: altivec still broken?!
2004-04-29 20:10 ` Paolo Bonzini
@ 2004-04-29 21:21 ` Ziemowit Laski
2004-04-30 10:56 ` Paolo Bonzini
0 siblings, 1 reply; 10+ messages in thread
From: Ziemowit Laski @ 2004-04-29 21:21 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: gcc, Aldy Hernandez, rth
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
>
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: altivec still broken?!
2004-04-29 21:21 ` Ziemowit Laski
@ 2004-04-30 10:56 ` Paolo Bonzini
0 siblings, 0 replies; 10+ messages in thread
From: Paolo Bonzini @ 2004-04-30 10:56 UTC (permalink / raw)
To: Ziemowit Laski; +Cc: gcc, Aldy Hernandez, rth
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
^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <HWXRPR$155B48652FCC799C9F3CD6AD93475DFB@libero.it>]
* Re: altivec still broken?!
[not found] <HWXRPR$155B48652FCC799C9F3CD6AD93475DFB@libero.it>
@ 2004-04-29 16:39 ` aldyh
2004-04-30 15:32 ` Paolo Bonzini
0 siblings, 1 reply; 10+ messages in thread
From: aldyh @ 2004-04-29 16:39 UTC (permalink / raw)
To: carlo.bonzini; +Cc: bonzini, rth, gcc
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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2004-04-30 9:20 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-04-27 0:56 altivec still broken?! Aldy Hernandez
2004-04-27 11:07 ` Paolo Bonzini
2004-04-27 11:55 ` Paolo Bonzini
2004-04-27 22:15 ` Aldy Hernandez
2004-04-29 20:10 ` Paolo Bonzini
2004-04-29 21:21 ` Ziemowit Laski
2004-04-30 10:56 ` Paolo Bonzini
[not found] <HWXRPR$155B48652FCC799C9F3CD6AD93475DFB@libero.it>
2004-04-29 16:39 ` aldyh
2004-04-30 15:32 ` Paolo Bonzini
2004-04-30 15:47 ` Paolo Bonzini
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).