diff options
author | Jakub Jelinek <jakub@redhat.com> | 2022-02-09 20:45:31 +0100 |
---|---|---|
committer | Jakub Jelinek <jakub@redhat.com> | 2022-02-09 20:46:10 +0100 |
commit | 499f8d4c2bc585b985882b4716f35b4c1553ce32 (patch) | |
tree | 0ccfe39e85279e622704fc53b6b2d72b86cd1554 /gcc/c/c-fold.cc | |
parent | 2f9ab267e725ddf2b6b44113e4fc4fb8b2a6adfb (diff) | |
download | gcc-499f8d4c2bc585b985882b4716f35b4c1553ce32.zip gcc-499f8d4c2bc585b985882b4716f35b4c1553ce32.tar.gz gcc-499f8d4c2bc585b985882b4716f35b4c1553ce32.tar.bz2 |
c: Fix up __builtin_assoc_barrier handling in the C FE [PR104427]
The following testcase ICEs, because when creating PAREN_EXPR for
__builtin_assoc_barrier the FE doesn't do the usual tweaks for
EXCESS_PRECISION_EXPR or C_MAYBE_CONST_EXPR. I believe that the
declared effect of the builtin is just association barrier, so
e.g. excess precision should be still handled like if it wasn't
there.
The following patch uses build_unary_op to handle those.
2022-02-09 Jakub Jelinek <jakub@redhat.com>
PR c/104427
* c-parser.cc (c_parser_postfix_expression)
<case RID_BUILTIN_ASSOC_BARRIER>: Use parser_build_unary_op
instead of build1_loc to build PAREN_EXPR.
* c-typeck.cc (build_unary_op): Handle PAREN_EXPR.
* c-fold.cc (c_fully_fold_internal): Likewise.
* gcc.dg/pr104427.c: New test.
Diffstat (limited to 'gcc/c/c-fold.cc')
-rw-r--r-- | gcc/c/c-fold.cc | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/gcc/c/c-fold.cc b/gcc/c/c-fold.cc index fc593753..76ea25b 100644 --- a/gcc/c/c-fold.cc +++ b/gcc/c/c-fold.cc @@ -465,6 +465,7 @@ c_fully_fold_internal (tree expr, bool in_init, bool *maybe_const_operands, case BIT_NOT_EXPR: case TRUTH_NOT_EXPR: case CONJ_EXPR: + case PAREN_EXPR: unary: /* Unary operations. */ orig_op0 = op0 = TREE_OPERAND (expr, 0); |