On Tue, 30 Aug 2011, Richard Guenther wrote: > oh, hum - now I remember ;) Eventually the C frontend should handle > this not via the function call mechanism but similar to how Joseph > added __builtin_complex support with > > 2011-08-19 Joseph Myers <jos...@codesourcery.com> > > * c-parser.c (c_parser_postfix_expression): Handle > RID_BUILTIN_COMPLEX. > * doc/extend.texi (__builtin_complex): Document. > > and then emit VEC_SHUFFLE_EXPRs directly from the frontend. Joseph?
It's probably time to refactor the parsing code before adding yet another pseudo-builtin. Considering just those all of whose operands are expressions (there are more where types are involved), we have __builtin_complex (two operands) and __builtin_choose_expr (three operands). How about a helper that parses a parenthesized list of expressions (using c_parser_expr_list, disabling all folding and conversions), gives an error if the number of expressions is wrong, then returns an error status and the list? Pass the keyword to this function and it can give a "wrong number of arguments" error that says which pseudo-builtin is involved, rather than less friendly parse errors - so these things would act a bit more like built-in functions while still being purely front-end syntax for GENERIC and GIMPLE operations. Then c_parser_postfix_expression would only have the code that deals with semantics, without duplicating the generic code for parsing lists. -- Joseph S. Myers jos...@codesourcery.com
