[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190906163918.GJ2120@tucnak>
Date: Fri, 6 Sep 2019 18:39:18 +0200
From: Jakub Jelinek <jakub@...hat.com>
To: Segher Boessenkool <segher@...nel.crashing.org>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Nick Desaulniers <ndesaulniers@...gle.com>,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
"gcc-patches@....gnu.org" <gcc-patches@....gnu.org>
Subject: Re: [PATCH v2 4/6] compiler-gcc.h: add asm_inline definition
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
> > <segher@...nel.crashing.org> 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
Powered by blists - more mailing lists