[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes

2009-05-03 Thread bonzini at gnu dot org
--- Comment #9 from bonzini at gnu dot org 2009-05-03 14:34 --- To be more specific, the builtin call is created by the vectorizer, and the vectorizer is quite careless in matching types. The front-end *does* insert VIEW_CONVERT_EXPRs and so does rs6000-c.c. -- http://gcc.gnu.org/b

[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes

2009-05-03 Thread bonzini at gnu dot org
--- Comment #8 from bonzini at gnu dot org 2009-05-03 14:25 --- What's remaining was already in the database. *** This bug has been marked as a duplicate of 30210 *** -- bonzini at gnu dot org changed: What|Removed |Added -

[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes

2009-05-03 Thread bonzini at gnu dot org
--- Comment #7 from bonzini at gnu dot org 2009-05-03 14:00 --- > Ok, so the builtins should have a proper, but opaque vector type (like for > VEC_CTU it should be an unsigned vector type, not a signed one). No, there's no reason to have >1 opaque vector type for a single mode (or even

[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes

2009-05-03 Thread rguenth at gcc dot gnu dot org
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-05-03 13:29 --- Ok, so the builtins should have a proper, but opaque vector type (like for VEC_CTU it should be an unsigned vector type, not a signed one). Thus, the TYPE_VECTOR_OPAQUE description should read like /* Nonzero in a

[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes

2009-05-03 Thread bonzini at gnu dot org
--- Comment #5 from bonzini at gnu dot org 2009-05-03 12:11 --- In many cases, opaque types are used in the prototypes just to avoid warnings. You're right that the front-end should insert VIEW_CONVERT_EXPRs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009

[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes

2009-05-03 Thread rguenth at gcc dot gnu dot org
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-03 11:18 --- For the case in question, vctuxs doesn't look like an instruction that has an opaque return type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009

[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes

2009-05-03 Thread rguenth at gcc dot gnu dot org
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-03 11:16 --- IMHO the frontend should, for TYPE_VECTOR_OPAQUE "conversions" emit VIEW_CONVERT_EXPRs to honour GIMPLE/GENERIC type system requirements. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009

[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes

2009-05-03 Thread rguenth at gcc dot gnu dot org
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-03 11:12 --- Huh. It uses build_opaque_vector_type, but /* Nonzero in an IDENTIFIER_NODE if the name is a local alias, whose uses are to be substituted for uses of the TREE_CHAINed identifier. */ #define TYPE_VECTOR_OPAQUE(

[Bug target/40009] altivec __builtin_vec_ctu has wrong tyes

2009-05-03 Thread rguenth at gcc dot gnu dot org
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-03 11:06 --- Looking at rs6000.c likely many more builtins are affected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009