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.