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.

Reply via email to