From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66944 invoked by alias); 6 Sep 2019 16:39:41 -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 66873 invoked by uid 89); 6 Sep 2019 16:39:40 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=hundreds, measurable, HX-Languages-Length:1376, tons X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Sep 2019 16:39:38 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 77CE03086272; Fri, 6 Sep 2019 16:39:37 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-139.ams2.redhat.com [10.36.116.139]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C95995D9D3; Fri, 6 Sep 2019 16:39:36 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id x86GdN6r015074; Fri, 6 Sep 2019 18:39:29 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id x86GdI8l015073; Fri, 6 Sep 2019 18:39:18 +0200 Date: Fri, 06 Sep 2019 16:39:00 -0000 From: Jakub Jelinek To: Segher Boessenkool Cc: Miguel Ojeda , Rasmus Villemoes , Nick Desaulniers , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , LKML , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH v2 4/6] compiler-gcc.h: add asm_inline definition Message-ID: <20190906163918.GJ2120@tucnak> Reply-To: Jakub Jelinek References: <20190829083233.24162-1-linux@rasmusvillemoes.dk> <20190830231527.22304-1-linux@rasmusvillemoes.dk> <20190830231527.22304-5-linux@rasmusvillemoes.dk> <20190905134535.GP9749@gate.crashing.org> <20190906122349.GZ9749@gate.crashing.org> <20190906163028.GC9749@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190906163028.GC9749@gate.crashing.org> User-Agent: Mutt/1.11.3 (2019-02-01) X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00418.txt.bz2 On Fri, Sep 06, 2019 at 11:30:28AM -0500, Segher Boessenkool wrote: > On Fri, Sep 06, 2019 at 05:13:54PM +0200, Miguel Ojeda wrote: > > On Fri, Sep 6, 2019 at 2:23 PM Segher Boessenkool > > wrote: > > > I can't find anything with "feature" and "macros" in the C++ standard, > > > it's "predefined macros" there I guess? In C, it is also "predefined > > > macros" in general, and there is "conditional feature macros". > > > > They are introduced in C++20, > > (Which isn't the C++ standard yet, okay). Well, they have been required by SD-6 before being added to C++20, so we have tons of the predefined macros for C++ already starting with gcc 4.9 or so, but it is something required by the standard so we have to do that. Most of them depend also on compiler options, so can't be easily replaced with a simple __GNUC__ version check. What I'd like to add is that each predefined macro isn't without cost, while adding one predefined macro might not be measurable (though, for some predefined macros (the floating point values) it was very measurable and we had to resort to lazy evaluation of the macros), adding hundreds of predefined macros is measurable, affects the speed of empty compiler run, adds size of -g3 produced debug info, increases size of -E -dD output etc. Jakub