Nathan Froyd wrote: > for (parm = 1; d->parm[parm] != SPU_BTI_END_OF_PARAMS; parm++) > ; > > - p = void_list_node; > + gcc_assert (parm <= (SPU_MAX_ARGS_TO_BUILTIN + 1)); > + > + for (i = 0; i < ARRAY_SIZE (args); i++) > + args[i] = NULL_TREE; > + > while (parm > 1) > - p = tree_cons (NULL_TREE, spu_builtin_types[d->parm[--parm]], p); > + { > + tree arg = spu_builtin_types[d->parm[--parm]]; > + args[parm-1] = arg; > + } > > - p = build_function_type (spu_builtin_types[d->parm[0]], p); > + ftype = build_function_type_list (spu_builtin_types[d->parm[0]], > + args[0], args[1], args[2], NULL_TREE);
This looks really odd now. The reason for running through parms twice, first forwards and then backwards, is just that you need build up the linked tree using tree_cons from the end. With the new scheme, all of that is now unnecessary. Why not simply something along the lines of: for (i = 0; i < ARRAY_SIZE (args) && d->parm[i] != SPU_BTI_END_OF_PARAMS; i++) args[i] = spu_builtin_types[d->parm[i]]; for (; i < ARRAY_SIZE (args); i++) args[i] = NULL; ftype = build_function_type_list (args[0], args[1], args[2], args[3], NULL_TREE); (As an aside, the SPU_MAX_ARGS_TO_BUILTIN define appears to imply a generality that is not really there: the call to build_function_type in itself implies an upper bound on the number of supported arguments.) Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com