On 9/6/21 8:21 AM, Matthias Kretz wrote:
Hi,
On Tuesday, 20 July 2021 22:22:02 CEST Jason Merrill wrote:
The C++ front end already uses PAREN_EXPR in templates to indicate
parenthesized initializers in cases where that matters for
decltype(auto). It should be fine to use it for both that and
__builtin_assoc_barrier, but you probably want to distinguish them with
a TREE_LANG_FLAG, and change tsubst_copy_and_build to keep the
PAREN_EXPR in this case.
I reused REF_PARENTHESIZED_P for PAREN_EXPR.
For constexpr you probably just need to add handling to
cxx_eval_constant_expression to evaluate its operand instead.
OK, that was easy.
On Monday, 19 July 2021 14:34:12 CEST Richard Biener wrote:
On Mon, 19 Jul 2021, Matthias Kretz wrote:
tested on x86_64-pc-linux-gnu with no new failures. OK for master?
I think now that PAREN_EXPR can appear in C++ code you need to
adjust some machiner to expect it (constexpr folding? template stuff?).
I suggest to add some testcases covering templates and constexpr
functions.
Right. I expanded the test.
+@deftypefn {Built-in Function} @var{type} __builtin_assoc_barrier
(@var{type} @var{expr})
+This built-in represents a re-association barrier for the floating-point
+expression @var{expr} with operations following the built-in. The
expression
+@var{expr} itself can be reordered, and the whole expression @var{expr}
can
be
+reordered with operations after the barrier.
What operations follow the built-in also applies to operations leading
the builtin? Maybe "This built-in represents a re-association barrier
for the floating-point expression @var{expr} with the expression
consuming its value." But I'm not an english speaker - I guess
I'm mostly confused about "follow" here.
With "follow" I meant time / precedence and not that the operation follows
syntactically. So e.g. a + b * c: the addition follows after the
multiplication. It's probably not as precise as it could/should be. Also "the
whole expression @var{expr} can be reordered with operations after the
barrier" probably should say "with operands" not "with operations", right?
I'm not sure if there are better C/C++ language terms describing what
the builtin does, but basically it appears as opaque operand to the
surrounding expression and the surrounding expression is opaque
to the expression inside the parens.
I can't think of any other term that would help here.
Based upon your suggestion, the attached patch now says:
"This built-in inhibits re-association of the floating-point expression
@var{expr} with expressions consuming the return value of the built-in. The
expression @var{expr} itself can be reordered, and the whole expression
@var{expr} can be reordered with operands after the barrier. [...]"
New patch attached. OK to push?
-----------------------------------------------------------
New builtin to enable explicit use of PAREN_EXPR in C & C++ code.
Signed-off-by: Matthias Kretz <m.kr...@gsi.de>
gcc/testsuite/ChangeLog:
* c-c++-common/builtin-assoc-barrier-1.c: New test.
gcc/cp/ChangeLog:
* constexpr.c (cxx_eval_constant_expression): Handle PAREN_EXPR
via cxx_eval_constant_expression.
* cp-objcp-common.c (names_builtin_p): Handle
RID_BUILTIN_ASSOC_BARRIER.
* cp-tree.h: Adjust TREE_LANG_FLAG documentation to include
PAREN_EXPR in REF_PARENTHESIZED_P.
(REF_PARENTHESIZED_P): Add PAREN_EXPR.
* parser.c (cp_parser_postfix_expression): Handle
RID_BUILTIN_ASSOC_BARRIER.
* pt.c (tsubst_copy_and_build): If the PAREN_EXPR is not a
parenthesized initializer, evaluate by ignoring the PAREN_EXPR.
* semantics.c (force_paren_expr): Simplify conditionals. Set
REF_PARENTHESIZED_P on PAREN_EXPR.
(maybe_undo_parenthesized_ref): Test PAREN_EXPR for
REF_PARENTHESIZED_P.
gcc/c-family/ChangeLog:
* c-common.c (c_common_reswords): Add __builtin_assoc_barrier.
* c-common.h (enum rid): Add RID_BUILTIN_ASSOC_BARRIER.
gcc/c/ChangeLog:
* c-decl.c (names_builtin_p): Handle RID_BUILTIN_ASSOC_BARRIER.
* c-parser.c (c_parser_postfix_expression): Likewise.
gcc/ChangeLog:
* doc/extend.texi: Document __builtin_assoc_barrier.
---
gcc/c-family/c-common.c | 1 +
gcc/c-family/c-common.h | 2 +-
gcc/c/c-decl.c | 1 +
gcc/c/c-parser.c | 20 ++++++++
gcc/cp/constexpr.c | 6 +++
gcc/cp/cp-objcp-common.c | 1 +
gcc/cp/cp-tree.h | 12 +++--
gcc/cp/parser.c | 14 ++++++
gcc/cp/pt.c | 5 +-
gcc/cp/semantics.c | 23 +++------
gcc/doc/extend.texi | 18 +++++++
.../c-c++-common/builtin-assoc-barrier-1.c | 48 +++++++++++++++++++
12 files changed, 128 insertions(+), 23 deletions(-)
create mode 100644 gcc/testsuite/c-c++-common/builtin-assoc-barrier-1.c
case PAREN_EXPR:
- RETURN (finish_parenthesized_expr (RECUR (TREE_OPERAND (t, 0))));
+ if (REF_PARENTHESIZED_P (t))
+ RETURN (finish_parenthesized_expr (RECUR (TREE_OPERAND (t, 0))));
+ else
+ RETURN (RECUR (TREE_OPERAND (t, 0)));
I think you need to build a new PAREN_EXPR in the assoc barrier case as
well, for it to have any effect in templates.
Please also add a comment mentioning __builtin_assoc_barrier.
Jason
