It should have an unsigned vector result def_builtin (MASK_ALTIVEC, "__builtin_vec_ctu", opaque_ftype_opaque_int, ALTIVEC_BUILTIN_VEC_CTU); this casues FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gcc.c-torture/compile/pr39943.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -g (test for excess errors) The failure is: [karma] f90/bug% gcc45 -O3 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr39943.c /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr39943.c: In function 'gl_fog_index_pixels': /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr39943.c:1: error: invalid conversion in gimple call vector unsigned int __vector signed int # .MEM_98 = VDEF <.MEM_97> vect_var_.47_88 = __builtin_altivec_vctuxs (vect_var_.46_87);
Looking at rs6000.c likely many more builtins are affected.
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(NODE) \ (VECTOR_TYPE_CHECK (NODE)->base.deprecated_flag) WTF?? It looks like frontend concept - see c-common.c:vector_targets_convertible_p. Why is this frontend specific when a _backend_ sets it? What semantics is it supposed to have - yeah well, proper documentation for the flag would have been a start...
IMHO the frontend should, for TYPE_VECTOR_OPAQUE "conversions" emit VIEW_CONVERT_EXPRs to honour GIMPLE/GENERIC type system requirements.
For the case in question, vctuxs doesn't look like an instruction that has an opaque return type.
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.
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 VECTOR_TYPE if the frontends should not emit warnings about missing conversions to other vector types of the same size. */ #define TYPE_VECTOR_OPAQUE(NODE) \ (VECTOR_TYPE_CHECK (NODE)->base.deprecated_flag) ?
> 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 for a single width). BTW, the opaque vector types were actually invented for SPE, and only later recycled for the implementation of Altivec. > Nonzero in a VECTOR_TYPE if the frontends should not emit warnings > about missing conversions to other vector types of the same size. Yes, will commit a patch to change it.
What's remaining was already in the database. *** This bug has been marked as a duplicate of 30210 ***
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.