On Fri, Sep 6, 2019 at 9:39 AM Jakub Jelinek <ja...@redhat.com> wrote: > > 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 > > > <seg...@kernel.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
Here's the case that I think is perfect: https://developers.redhat.com/blog/2016/02/25/new-asm-flags-feature-for-x86-in-gcc-6/ Specifically the feature test preprocessor define __GCC_ASM_FLAG_OUTPUTS__. See exactly how we handle it in the kernel: - https://github.com/ClangBuiltLinux/linux/blob/0445971000375859008414f87e7c72fa0d809cf8/arch/x86/include/asm/asm.h#L112-L118 - https://github.com/ClangBuiltLinux/linux/blob/0445971000375859008414f87e7c72fa0d809cf8/arch/x86/include/asm/rmwcc.h#L14-L30 Feature detection of the feature makes it trivial to detect when the feature is supported, rather than brittle compiler version checks. Had it been a GCC version check, it wouldn't work for clang out of the box when clang added support for __GCC_ASM_FLAG_OUTPUTS__. But since we had the helpful __GCC_ASM_FLAG_OUTPUTS__, and wisely based our use of the feature on that preprocessor define, the code ***just worked*** for compilers that didn't support the feature ***and*** compilers when they did support the feature ***without changing any of the source code*** being compiled. All I'm asking for is that when GCC adds a new GNU C extension (such as `asm inline`), define a new preprocessor symbol (like has already been done w/ __GCC_ASM_FLAG_OUTPUTS__), so that we don't have to use version checking (or reimplementing autoconf) and use feature detection instead. This simplifies use of this feature even between codebases supporting multiple versions of GCC. (Also, I'm guessing the cost of another preprocessor define is near zero compared to parsing comments for -Wimplicit-fallthrough) -- Thanks, ~Nick Desaulniers
