Hi Chung-Lin! Thanks for your work on this.
Please reference PR76739 in your submission/ChangeLog updates.
We'll need Jakub to review the generic code changes, but let me provide
some first review remarks, too.
On 2019-08-20T19:36:24+0800, Chung-Lin Tang <chunglin_t...@mentor.com> wrote:
> The first patch here are the C/C++ front-end patches.
As far as I'm concerned, it doesn't make sense to artificially split up
patches like that, given that the individual three pieces can only be
considered all together.
And if posting split-up for other reasonse, then please make sure that
the individual patch submission emails have a common "cover letter" email
so that they show up as one email thread.
> --- gcc/c/c-typeck.c (revision 274618)
> +++ gcc/c/c-typeck.c (working copy)
> @@ -13099,6 +13100,21 @@ handle_omp_array_sections_1 (tree c, tree t, vec<t
> }
> }
> }
> +
> + /* For OpenACC, if the low_bound/length suggest this is a subarray,
> + and is referenced through by a pointer, then mark this as
> + non-contiguous. */
I don't directly understand this logic. I'll have to think about it
more.
> + if (ort == C_ORT_ACC
> + && types.length () > 0
> + && (TREE_CODE (low_bound) != INTEGER_CST
> + || integer_nonzerop (low_bound)
> + || (length && (TREE_CODE (length) != INTEGER_CST
> + || !tree_int_cst_equal (size, length)))))
> + {
> + tree x = types.last ();
> + if (TREE_CODE (x) == POINTER_TYPE)
> + non_contiguous = true;
> + }
> }
> else if (length == NULL_TREE)
> {
> @@ -13142,7 +13158,8 @@ handle_omp_array_sections_1 (tree c, tree t, vec<t
> /* If there is a pointer type anywhere but in the very first
> array-section-subscript, the array section can't be contiguous. */
> if (OMP_CLAUSE_CODE (c) != OMP_CLAUSE_DEPEND
> - && TREE_CODE (TREE_CHAIN (t)) == TREE_LIST)
> + && TREE_CODE (TREE_CHAIN (t)) == TREE_LIST
> + && ort != C_ORT_ACC)
> {
> error_at (OMP_CLAUSE_LOCATION (c),
> "array section is not contiguous in %qs clause",
> @@ -13149,6 +13166,8 @@ handle_omp_array_sections_1 (tree c, tree t, vec<t
> omp_clause_code_name[OMP_CLAUSE_CODE (c)]);
> return error_mark_node;
> }
> + else if (TREE_CODE (TREE_CHAIN (t)) == TREE_LIST)
> + non_contiguous = true;
> }
> else
> {
> @@ -13337,6 +13365,14 @@ handle_omp_array_sections (tree c, enum c_omp_regi
> size = size_binop (MULT_EXPR, size, l);
> }
> }
> + if (non_contiguous)
> + {
> + int kind = OMP_CLAUSE_MAP_KIND (c);
> + OMP_CLAUSE_SET_MAP_KIND (c, kind | GOMP_MAP_NONCONTIG_ARRAY);
> + OMP_CLAUSE_DECL (c) = t;
> + OMP_CLAUSE_SIZE (c) = ncarray_dims;
> + return false;
> + }
I'm expecting to see front end test cases (probably
'-fdump-tree-original' scanning?) for a good number of different data
clauses/array variants, whether that flag 'GOMP_MAP_NONCONTIG_ARRAY' has
been set or not. (That would then also document the logic presented
above, and should thus help me understand that.)
> --- gcc/cp/semantics.c (revision 274618)
> +++ gcc/cp/semantics.c (working copy)
Likewise.
Grüße
Thomas
signature.asc
Description: PGP signature
