From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5226 invoked by alias); 22 Nov 2004 10:07:46 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 4904 invoked from network); 22 Nov 2004 10:07:31 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.9) by sourceware.org with SMTP; 22 Nov 2004 10:07:31 -0000 Received: (qmail 27400 invoked from network); 22 Nov 2004 10:07:31 -0000 Received: from localhost (HELO digraph.polyomino.org.uk) (joseph@127.0.0.1) by mail.codesourcery.com with DES-CBC3-SHA encrypted SMTP; 22 Nov 2004 10:07:31 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.42) id 1CWB6w-0006dH-Up; Mon, 22 Nov 2004 10:07:54 +0000 Date: Mon, 22 Nov 2004 10:41:00 -0000 From: "Joseph S. Myers" X-X-Sender: jsm28@digraph.polyomino.org.uk To: Jamie Lokier cc: gcc@gcc.gnu.org Subject: Re: Documentation bug for __builtin_choose_expr In-Reply-To: <20041122042652.GA26998@mail.shareable.org> Message-ID: References: <20041122042652.GA26998@mail.shareable.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-11/txt/msg00737.txt.bz2 On Mon, 22 Nov 2004, Jamie Lokier wrote: > 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. I'd think the idea is actually to say that it is different from normal functions (built-in and otherwise), which inevitably evaluate all their arguments before calling the function. (Although the syntax is that of a built-in function, the implementation is that of a new keyword __builtin_choose_expr handled specially in the parser.) Perhaps it should say "Unlike most built-in functions, but like the ? : operator, ...". -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ jsm@polyomino.org.uk (personal mail) joseph@codesourcery.com (CodeSourcery mail) jsm28@gcc.gnu.org (Bugzilla assignments and CCs)