From: Tobias Burnus <burnus@net-b.de>
To: Julian Brown <julian@codesourcery.com>, gcc-patches@gcc.gnu.org
Cc: fortran@gcc.gnu.org, jakub@redhat.com, tobias@codesourcery.com
Subject: Re: [PATCH 2/8] OpenMP: lvalue parsing for map/to/from clauses (C)
Date: Wed, 10 Jan 2024 22:31:33 +0100 [thread overview]
Message-ID: <34099853-299a-415e-a762-c84a39f3e334@net-b.de> (raw)
In-Reply-To: <78fa6c4dae60578a8feffe204bfe24d85d19520c.1693941293.git.julian@codesourcery.com>
Julian Brown wrote:
> This patch adds support for parsing general lvalues ("locator list item
> types") for OpenMP "map", "to" and "from" clauses to the C front-end,
> similar to the previously-posted patch for C++. Such syntax is permitted
> for OpenMP 5.0 and above. It was previously posted for mainline here
...
In libgomp/libgomp.texi, the following can now be set to 'Y':
@item C/C++'s lvalue expressions in @code{to}, @code{from}
and @code{map} clauses @tab N @tab
> @@ -11253,16 +11263,41 @@ c_parser_postfix_expression_after_primary (c_parser *parser,
> case CPP_OPEN_SQUARE:
> /* Array reference. */
> c_parser_consume_token (parser);
> - idx = c_parser_expression (parser).value;
> - c_parser_skip_until_found (parser, CPP_CLOSE_SQUARE,
> - "expected %<]%>");
> - start = expr.get_start ();
> - finish = parser->tokens_buf[0].location;
> - expr.value = build_array_ref (op_loc, expr.value, idx);
> - set_c_expr_source_range (&expr, start, finish);
> - expr.original_code = ERROR_MARK;
> - expr.original_type = NULL;
> - expr.m_decimal = 0;
> + idx = len = NULL_TREE;
> + if (!c_omp_array_section_p
> + || c_parser_next_token_is_not (parser, CPP_COLON))
> + idx = c_parser_expression (parser).value;
> +
> + if (c_omp_array_section_p
> + && c_parser_next_token_is (parser, CPP_COLON))
> + {
> + c_parser_consume_token (parser);
> + if (c_parser_next_token_is_not (parser, CPP_CLOSE_SQUARE))
> + len = c_parser_expression (parser).value;
> +
> + c_parser_skip_until_found (parser, CPP_CLOSE_SQUARE,
> + "expected %<]%>");
> +
> + start = expr.get_start ();
> + finish = parser->tokens_buf[0].location;
> + expr.value = build_omp_array_section (op_loc, expr.value, idx,
> + len);
> + set_c_expr_source_range (&expr, start, finish);
> + expr.original_code = ERROR_MARK;
> + expr.original_type = NULL;
> + }
> + else
> + {
> + c_parser_skip_until_found (parser, CPP_CLOSE_SQUARE,
> + "expected %<]%>");
> + start = expr.get_start ();
> + finish = parser->tokens_buf[0].location;
> + expr.value = build_array_ref (op_loc, expr.value, idx);
> + set_c_expr_source_range (&expr, start, finish);
> + expr.original_code = ERROR_MARK;
> + expr.original_type = NULL;
> + expr.m_decimal = 0;
> + }
I think that's more readable when moving everything but the expr.value
assignment after the if/else (obviously for "if" also everything until
"len =" has to remain). That also adds the missing "m_decimal = 0" for
the "if" case.
> @@ -13915,8 +13955,97 @@ c_parser_omp_variable_list (c_parser *parser,
...
> + else if (TREE_CODE (decl) == INDIRECT_REF)
> + {
> + /* Turn *foo into the representation previously used for
> + foo[0]. */
> + decl = TREE_OPERAND (decl, 0);
> + STRIP_NOPS (decl);
> +
> + decl = build_omp_array_section (loc, decl, integer_zero_node,
> + integer_one_node);
> + }
I wonder whether we shouldn't use the C++ wording, i.e.
/* If we have "*foo" and
- it's an indirection of a reference, "unconvert" it,
i.e. strip the indirection (to just "foo").
- it's an indirection of a pointer, turn it into
"foo[0:1]". */
* * *
As remarked for cp/typecheck.cc's build_omp_array_section:
> +tree
> +build_omp_array_section (location_t loc, tree array, tree index, tree length)
> +{
> + tree idxtype;
> +
> + if (index != NULL_TREE
> + && length != NULL_TREE
> + && INTEGRAL_TYPE_P (TREE_TYPE (index))
> + && INTEGRAL_TYPE_P (TREE_TYPE (length)))
> + {
> + tree low = fold_convert (sizetype, index);
> + tree high = fold_convert (sizetype, length);
> + high = size_binop (PLUS_EXPR, low, high);
> + high = size_binop (MINUS_EXPR, high, size_one_node);
> + idxtype = build_range_type (sizetype, low, high);
> + }
> + else if ((index == NULL_TREE || integer_zerop (index))
> + && length != NULL_TREE
> + && INTEGRAL_TYPE_P (TREE_TYPE (length)))
> + idxtype = build_index_type (length);
> + else
> + idxtype = NULL_TREE;
> +
> + tree type = TREE_TYPE (array);
> + gcc_assert (type);
> +
> + tree sectype, eltype = TREE_TYPE (type);
> +
> + /* It's not an array or pointer type. Just reuse the type of the original
> + expression as the type of the array section (an error will be raised
> + anyway, later). */
> + if (eltype == NULL_TREE
> + || error_operand_p (eltype)
> + || error_operand_p (idxtype))
> + sectype = TREE_TYPE (array);
> + else
> + sectype = build_array_type (eltype, idxtype);
> +
> + return build3_loc (loc, OMP_ARRAY_SECTION, sectype, array, index, length);
> +}
I think that's more readable when having that if condition at the top
and moving everything before into the else branch.
Otherwise, LGTM.
Thanks for the patch!
Tobias
next prev parent reply other threads:[~2024-01-10 21:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-05 19:28 [PATCH 0/8] OpenMP: lvalue parsing and "declare mapper" support Julian Brown
2023-09-05 19:28 ` [PATCH 1/8] OpenMP: lvalue parsing for map/to/from clauses (C++) Julian Brown
2023-12-20 14:31 ` Tobias Burnus
2024-01-05 12:23 ` Julian Brown
2024-01-07 15:04 ` Tobias Burnus
2024-01-09 23:02 ` Thomas Schwinge
2024-01-10 9:14 ` Jakub Jelinek
2024-01-10 13:17 ` Julian Brown
2023-09-05 19:28 ` [PATCH 2/8] OpenMP: lvalue parsing for map/to/from clauses (C) Julian Brown
2024-01-10 21:31 ` Tobias Burnus [this message]
2023-09-05 19:28 ` [PATCH 3/8] OpenMP: C++ "declare mapper" support Julian Brown
2023-09-05 19:28 ` [PATCH 4/8] OpenMP: Support OpenMP 5.0 "declare mapper" directives for C Julian Brown
2023-09-05 19:28 ` [PATCH 5/8] OpenMP, Fortran: Pass list number to gfc_free_omp_namelist Julian Brown
2023-09-05 19:28 ` [PATCH 6/8] OpenMP, Fortran: Per-directive control for gfc_trans_omp_clauses Julian Brown
2023-09-05 19:28 ` [PATCH 7/8] OpenMP, Fortran: Split out OMP clause checking Julian Brown
2023-09-05 19:28 ` [PATCH 8/8] OpenMP: Fortran "!$omp declare mapper" support Julian Brown
2023-09-14 15:13 ` Bernhard Reutner-Fischer
2023-09-18 10:19 ` Julian Brown
2023-09-21 22:52 ` Bernhard Reutner-Fischer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=34099853-299a-415e-a762-c84a39f3e334@net-b.de \
--to=burnus@net-b.de \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=julian@codesourcery.com \
--cc=tobias@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).