> -----Original Message----- > From: Jakub Jelinek [mailto:ja...@redhat.com] > Sent: Tuesday, November 19, 2013 11:31 AM > To: Joseph S. Myers > Cc: Iyer, Balaji V; gcc-patches@gcc.gnu.org; Aldy Hernandez > (al...@redhat.com); Jeff Law > Subject: Re: [GOMP4] [PATCH] SIMD-Enabled Functions (formerly Elemental > functions) for C > > On Tue, Nov 19, 2013 at 04:13:34PM +0000, Joseph S. Myers wrote: > > On Tue, 19 Nov 2013, Jakub Jelinek wrote: > > > > > Also, I wonder if you couldn't save the tokens wrapped into some > > > tree temporarily into the attribute, rather than having to adjust > > > c_parser_attribute callers. Joseph, what do you prefer here? > > > > I think including whatever parsed data is relevant to this attribute > > in the structure returned by c_parser_attributes (which is currently a > > tree) > > Well, it has to have an array of tokens, because it can't be parsed until the > arguments of the function (which may come afterwards) are parsed. > But IMHO it can be just created as vec<..., va_gc> of the tokens and pointer > to that added to some magic tree code, or could be kept in an on-the-size > data structure (say, put in an INTEGER_CST index into some vector inside of > c_parser into the vector attribute argument temporarily, push the tokens > into that vector and release it from the vector after parsing the function > parameters (where OpenMP #pragma omp declare simd is parsed right > now). > That parsing then transforms it into a normal tree arguments. >
I just need a clarification, so I am sorry if I am making you repeat: Right now, the array of tokens (vec<c_token> elem_fn_tokens) is passed in as a parameter and then passed back to the c_parser_declaration_or_fndef function. Instead of that, you would like this information to be stored in parser->specs (using the c_parser_declspecs function) and then have my own routine that will go through these tokens and store them in the DECL_ATTRIBUTES (very similar to what c_finish_omp_declare_simd does). Am I correct? Did I mistake anything? Thanks, Balaji V. Iyer. > Jakub
