From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83041 invoked by alias); 21 Aug 2019 19:10:01 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 83023 invoked by uid 89); 21 Aug 2019 19:10:01 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.2 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=Until X-HELO: esa3.mentor.iphmx.com Received: from esa3.mentor.iphmx.com (HELO esa3.mentor.iphmx.com) (68.232.137.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 21 Aug 2019 19:10:00 +0000 IronPort-SDR: zJaHneogjt9kzcRRDOTJSL6YauldmQGM6tcPq5jtFlnw0vmnwTaduqX9U8SOKTm9wN3KYpDXOH eSOU1c/IBpdB2wUwk3Ia4q8b5MSQD5daa4gb6J/HmxXY9ZThWsa6gjod9vnzHKDypqj24tHQz3 8oT22x7swT7ejSo3lz+fSJe7G8OnOxhcFvnHZLbhFKtZIxWTft/epkdbL57Pm/KN7XjRiSrPSv p+QpgePMODifgz5+LpD5FoYEta7+fBrzGgpgCUrrpzTHl7LyOwKN0/Gg+8h5TFa2a1evW31176 MO0= Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 21 Aug 2019 11:09:58 -0800 IronPort-SDR: Axw+d6k+Vb7vfr+mpm6OlH4//VpssYCOiE6eZZb0UtGmIEi0ro9jUkhj1aLV8HocCr5FVM9od8 WBBSJyvVT51Bt17+0bIZqqWQh2d7Q2jAnC5zAVZaJirL8eoqmDzGfyu2ozpNjFexdVuhlwRm30 lRFCXRnZw2ma396FKEGnukkMspB+PjyTvNqXvZ/h8LKERiEEnuJIhr/IBWtxxpIc78zDHLhQ3a NG/1RpH52bXZsaiGqiHA8N7XqPcUzD7UkPfZ4CJLHk1xJrOVR6oRQKf4QNpDe5KYHgMd7FLidU GPA= Date: Wed, 21 Aug 2019 20:50:00 -0000 From: Joseph Myers To: Martin Jambor CC: Tejas Joshi , , Subject: Re: [PATCH] Builtin function roundeven folding implementation In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Return-Path: joseph@codesourcery.com X-SW-Source: 2019-08/txt/msg01517.txt.bz2 On Wed, 21 Aug 2019, Martin Jambor wrote: > - I have listed roundeven variants in extend.texi. If I did not find > the right spot, I will gladly move to a more appropriate one. I don't think they should be documented with the __builtin_* that are always expanded inline. They should be documented in the list of functions that *might* be expanded inline. That is, where extend.texi says: [...] Many of these functions are only optimized in certain cases; if they are not optimized in a particular case, a call to the library function is emitted. @opindex ansi @opindex std Outside strict ISO C mode (@option{-ansi}, @option{-std=c90}, @option{-std=c99} or @option{-std=c11}), the functions @code{_exit}, [...] may be handled as built-in functions. All these functions have corresponding versions prefixed with @code{__builtin_}, which may be used even in strict C90 mode. (Until we enable these by default for C2X, at which point they'd be listed as C2X functions after the C99 ones.) -- Joseph S. Myers joseph@codesourcery.com