Hi! On Thu, Feb 03, 2022 at 08:44:48AM -0600, Bill Schmidt wrote: > Although the previous patch was correct, the logic around what to do when > the number of arguments is wrong was still hard to understand. It should > be better now. I'm now explicitly counting the number of expected arguments > and comparing against that. The way the argument list is represented ensures > there is always at least one element in the argument chain, by terminating > the chain with an argument type of void, which is why the previous logic was > so convoluted.
Aha :-) > + /* Count the number of expected arguments. */ > + unsigned expected_args = 0; > + for (tree chain = fnargs; > + chain && !VOID_TYPE_P (TREE_VALUE (chain)); > + chain = TREE_CHAIN (chain)) > + expected_args++; FOREACH_FUNCTION_ARGS? > + So even though __builtin_vec_splats accepts all vector types, the > + infrastructure cheats and just records one prototype. We end up getting > + an error message that refers to this specific prototype even when we > + are handling a different argument type. That is completely confusing > + to the user, so it's best to let these cases be handled individually > + in the resolve_vec_splats, etc., helper functions. */ > + > + if (n != expected_args > + && !(fcode == RS6000_OVLD_VEC_PROMOTE > + || fcode == RS6000_OVLD_VEC_SPLATS > + || fcode == RS6000_OVLD_VEC_EXTRACT > + || fcode == RS6000_OVLD_VEC_INSERT > + || fcode == RS6000_OVLD_VEC_STEP)) > return NULL; Even I can understand that! Thank you! :-) Okay for trunk. Segher
