Documentation bug for __builtin_choose_expr

[Jamie Lokier <jamie@shareable.org>]

The documentation for __builtin_choose_expr says:

 -- Built-in Function: TYPE __builtin_choose_expr (CONST_EXP, EXP1, EXP2)
     You can use the built-in function `__builtin_choose_expr' to
     evaluate code depending on the value of a constant expression.
     This built-in function returns EXP1 if CONST_EXP, which is a
     constant expression that must be able to be determined at compile
     time, is nonzero.  Otherwise it returns 0.

     This built-in function is analogous to the `? :' 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 was not chosen.  For example, if CONST_EXP
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     evaluates to true, EXP2 is not evaluated even if it has
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     side-effects.
     ^^^^^^^^^^^^^

The way this is written implies that the underscored behaviour is
different from the `? :' operator in C.

But the `? :' operator does not evaluate the expression that was not
chosen either.  If the condition evaluates to true, EXP2 is not
evaluated in `COND ? EXP1 : EXP2'.

It would be better to replace that paragraph with:

     This built-in function is analogous to the `? :' operator in C,
     except that the expression returned has its type unaltered by
     promotion rules.

If there is some other effect of __builtin_choose_expr, for example if
it were to inhibit compilation or warnings in the unselected branch in
some way, it would be useful to mention that.  I don't know of any
such effects.  (Inhibiting warnings in the unselected branch and
promising to not expand large inline functions in that branch would be
a useful addition imho).

-- Jamie