On Mon, Feb 01, 2016 at 01:41:50PM -0600, James Norris wrote:
> The attached patch resolves c/PR64748. The patch
> adds the use of parm's with the deviceptr clause.
>
> Question....
>
> As there is VAR_P (), could there be a PARM_P ()?
Not for GCC 6.x, for 7 it is possible.
> --- a/gcc/c/c-parser.c
> +++ b/gcc/c/c-parser.c
> @@ -10760,7 +10760,7 @@ c_parser_oacc_data_clause_deviceptr (c_parser
> *parser, tree list)
> c_parser_omp_var_list_parens() should construct a list of
> locations to go along with the var list. */
>
> - if (!VAR_P (v))
> + if (!VAR_P (v) && !(TREE_CODE (v) == PARM_DECL))
Please don't write !(x == y) but x != y.
> --- a/gcc/cp/parser.c
> +++ b/gcc/cp/parser.c
> @@ -30087,7 +30087,7 @@ cp_parser_oacc_data_clause_deviceptr (cp_parser
> *parser, tree list)
> c_parser_omp_var_list_parens should construct a list of
> locations to go along with the var list. */
>
> - if (!VAR_P (v))
> + if (!VAR_P (v) && !(TREE_CODE (v) == PARM_DECL))
> error_at (loc, "%qD is not a variable", v);
> else if (TREE_TYPE (v) == error_mark_node)
> ;
For C++, all this diagnostics is premature, if processing_template_decl
you really often don't know what the type will be, not sure if you always
know at least if it is a VAR_DECL, PARM_DECL or something else. I bet you
can easily ICE with the current POINTER_TYPE_P (TREE_TYPE (v)) check as
in templates the type can be NULL, or it could be some lang type and only
later on become POINTER_TYPE, etc.
For C++ the diagnostics need to be done during finish_omp_clauses or so, not
earlier.
Jakub
