[PATCH] c: Fix up __builtin_assoc_barrier handling in the C FE [PR104427]

[PATCH] c: Fix up __builtin_assoc_barrier handling in the C FE [PR104427]

[Jakub Jelinek]

Hi!

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.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2022-02-08  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.

--- gcc/c/c-parser.cc.jj	2022-01-18 11:58:58.927991414 +0100
+++ gcc/c/c-parser.cc	2022-02-08 12:56:00.028208794 +0100
@@ -10128,8 +10128,7 @@ c_parser_postfix_expression (c_parser *p
 	    mark_exp_read (e1.value);
 	    location_t end_loc = c_parser_peek_token (parser)->get_finish ();
 	    parens.skip_until_found_close (parser);
-	    expr.value = build1_loc (loc, PAREN_EXPR, TREE_TYPE (e1.value),
-				     e1.value);
+	    expr = parser_build_unary_op (loc, PAREN_EXPR, e1);
 	    set_c_expr_source_range (&expr, start_loc, end_loc);
 	  }
 	  break;
--- gcc/c/c-typeck.cc.jj	2022-01-18 11:58:58.929991386 +0100
+++ gcc/c/c-typeck.cc	2022-02-08 12:53:16.026485823 +0100
@@ -4921,6 +4921,10 @@ build_unary_op (location_t location, enu
       ret = val;
       goto return_build_unary_op;
 
+    case PAREN_EXPR:
+      ret = build1 (code, TREE_TYPE (arg), arg);
+      goto return_build_unary_op;
+
     default:
       gcc_unreachable ();
     }
--- gcc/c/c-fold.cc.jj	2022-01-18 11:58:58.925991443 +0100
+++ gcc/c/c-fold.cc	2022-02-08 12:37:46.315411262 +0100
@@ -465,6 +465,7 @@ c_fully_fold_internal (tree expr, bool i
     case BIT_NOT_EXPR:
     case TRUTH_NOT_EXPR:
     case CONJ_EXPR:
+    case PAREN_EXPR:
     unary:
       /* Unary operations.  */
       orig_op0 = op0 = TREE_OPERAND (expr, 0);
--- gcc/testsuite/gcc.dg/pr104427.c.jj	2022-02-08 13:08:14.054022838 +0100
+++ gcc/testsuite/gcc.dg/pr104427.c	2022-02-08 13:08:41.541641923 +0100
@@ -0,0 +1,13 @@
+/* PR c/104427 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+/* { dg-add-options float16 } */
+/* { dg-require-effective-target float16 } */
+
+_Float16 x, y;
+
+int
+foo ()
+{
+  return __builtin_assoc_barrier (x + y) - y;
+}

	Jakub

Re: [PATCH] c: Fix up __builtin_assoc_barrier handling in the C FE [PR104427]

[Joseph Myers]

On Wed, 9 Feb 2022, Jakub Jelinek via Gcc-patches wrote:

> Hi!
> 
> 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.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

-- 
Joseph S. Myers
joseph@codesourcery.com