https://gcc.gnu.org/g:4b152f62e4acff41c6d0f1423f7f50e7a0528b5b
commit r15-4192-g4b152f62e4acff41c6d0f1423f7f50e7a0528b5b
Author: Jan Beulich <jbeul...@suse.com>
Date: Wed Oct 9 09:36:42 2024 +0200
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.
Diff:
---
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.
