Re: [patch] various OpenACC reduction enhancements - FE changes

[Jakub Jelinek <jakub@redhat.com>]

On Thu, Dec 13, 2018 at 02:11:31PM +0000, Julian Brown wrote:
> > Any reason for the above (ditto in C), rather than just adding
> > && ort != C_ORT_ACC to the while loop condition for CPP_OPEN_SQUARE?
> > (, . or * after id-expression is like any other unhandled
> > characters...
> 
> I think the reason was that 'decl' ('t' in the C version) is not set to
> error_mark_node if the while loop is skipped, and then the gimplifier
> gets confused. I've tried to tackle this in another way, by checking
> there aren't any stray characters before the next comma or
> close-parenthesis.
> 
> I'm not sure if you were objecting to the error message too -- with the
> current patch, the user will just get e.g.:
> 
> error: expected ')' before '.' token
> 
> if they try to use an unsupported type of construct as a reduction
> target.

> @@ -12004,7 +12005,8 @@ c_parser_omp_variable_list (c_parser *parser,
>  	    case OMP_CLAUSE_REDUCTION:
>  	    case OMP_CLAUSE_IN_REDUCTION:
>  	    case OMP_CLAUSE_TASK_REDUCTION:
> -	      while (c_parser_next_token_is (parser, CPP_OPEN_SQUARE))
> +	      while (ort != C_ORT_ACC
> +		     && c_parser_next_token_is (parser, CPP_OPEN_SQUARE))
>  		{
>  		  tree low_bound = NULL_TREE, length = NULL_TREE;
>  
> @@ -12074,6 +12076,10 @@ c_parser_omp_variable_list (c_parser *parser,
>  			}
>  		    }
>  		}
> +	      if (ort == C_ORT_ACC
> +	          && c_parser_next_token_is_not (parser, CPP_COMMA)
> +		  && c_parser_next_token_is_not (parser, CPP_CLOSE_PAREN))
> +		t = error_mark_node;
>  	      break;
>  	    default:
>  	      break;

I still don't understand this at all, sorry.
So, t is guaranteed to be non-error_mark_node before entering this spot.
If you have reduction (decl[0]) etc. vs. reduction (decl), why do you care whether
it is added to the returned list or not for error recovery?  If it is something
that causes ICE in the gimplifier, then user could have written just
reduction (decl) or reduction (decl, ) and have it added to the list anyway,
so the bug would be that it isn't diagnosed as something incorrect in
c_finish_omp_clauses (or whatever the problem with it is).
If there is any kind of garbage after the decl, it will just return to the
caller at that point and the caller should do the error recovery, the same
for reduction (decl[0]) as well as for reduction (decl, [0]).

	Jakub