From 4b152f62e4acff41c6d0f1423f7f50e7a0528b5b Mon Sep 17 00:00:00 2001
From: Jan Beulich <jbeulich@suse.com>
Date: Wed, 9 Oct 2024 09:36:42 +0200
Subject: [PATCH] gcc/doc: adjust __builtin_choose_expr() description
Present wording has misled people to believe the ?: operator would be
evaluating all three of the involved expressions.
gcc/
* doc/extend.texi: Clarify __builtin_choose_expr()
(dis)similarity to the ?: operator.
---
gcc/doc/extend.texi | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index f46c3df33030..302c3299ede8 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -15153,11 +15153,12 @@ evaluate code depending on the value of a constant expression. This
built-in function returns @var{exp1} if @var{const_exp}, which is an
integer constant expression, is nonzero. Otherwise it returns @var{exp2}.
-This built-in function is analogous to the @samp{? :} operator in C,
-except that the expression returned has its type unaltered by promotion
-rules. Also, the built-in function does not evaluate the expression
-that is not chosen. For example, if @var{const_exp} evaluates to @code{true},
-@var{exp2} is not evaluated even if it has side effects.
+Like the @samp{? :} operator, this built-in function does not evaluate the
+expression that is not chosen. For example, if @var{const_exp} evaluates to
+@code{true}, @var{exp2} is not evaluated even if it has side effects. On the
+other hand, @code{__builtin_choose_expr} differs from @samp{? :} in that the
+first operand must be a compile-time constant, and the other operands are not
+subject to the @samp{? :} type constraints and promotions.
This built-in function can return an lvalue if the chosen argument is an
lvalue.
--
GitLab