| Message ID | 1455043788-28112-1-git-send-email-eblake@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 9 February 2016 at 18:49, Eric Blake <eblake@redhat.com> wrote: > Actively redefining 'inline' is wrong for C++, where gcc has an > extension 'inline namespace' which fails to compile if the > keyword 'inline' is replaced by a macro expansion. This will > matter once we start to include "qemu/osdep.h" first from C++ > files, depending also on whether the system headers are new > enough to be using the gcc extension. > > But rather than just guard things by __cplusplus, let's look at > the overall picture. Commit df2542c737ea2 in 2007 defined 'inline' > to the gcc attribute __always_inline__, with the rationale "To > avoid discarded inlining bug". But compilers have improved since > then, and we are probably better off trusting the compiler rather > than trying to force its hand. > > So just nuke our craziness. > > Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> (and tested that it passes my usual merge build tests). Does this patch suffice to get your system to build all my clean-includes patches? thanks -- PMM
On 02/12/2016 06:24 AM, Peter Maydell wrote: > On 9 February 2016 at 18:49, Eric Blake <eblake@redhat.com> wrote: >> Actively redefining 'inline' is wrong for C++, where gcc has an >> extension 'inline namespace' which fails to compile if the >> keyword 'inline' is replaced by a macro expansion. This will >> matter once we start to include "qemu/osdep.h" first from C++ >> files, depending also on whether the system headers are new >> enough to be using the gcc extension. >> >> But rather than just guard things by __cplusplus, let's look at >> the overall picture. Commit df2542c737ea2 in 2007 defined 'inline' >> to the gcc attribute __always_inline__, with the rationale "To >> avoid discarded inlining bug". But compilers have improved since >> then, and we are probably better off trusting the compiler rather >> than trying to force its hand. >> >> So just nuke our craziness. >> >> Signed-off-by: Eric Blake <eblake@redhat.com> > > Reviewed-by: Peter Maydell <peter.maydell@linaro.org> > > (and tested that it passes my usual merge build tests). > > Does this patch suffice to get your system to build all > my clean-includes patches? Yes.
On 9 February 2016 at 18:49, Eric Blake <eblake@redhat.com> wrote: > Actively redefining 'inline' is wrong for C++, where gcc has an > extension 'inline namespace' which fails to compile if the > keyword 'inline' is replaced by a macro expansion. This will > matter once we start to include "qemu/osdep.h" first from C++ > files, depending also on whether the system headers are new > enough to be using the gcc extension. > > But rather than just guard things by __cplusplus, let's look at > the overall picture. Commit df2542c737ea2 in 2007 defined 'inline' > to the gcc attribute __always_inline__, with the rationale "To > avoid discarded inlining bug". But compilers have improved since > then, and we are probably better off trusting the compiler rather > than trying to force its hand. > > So just nuke our craziness. > > Signed-off-by: Eric Blake <eblake@redhat.com> > --- > include/qemu/compiler.h | 12 ------------ > 1 file changed, 12 deletions(-) Applied to master, thanks. I am all in favour of reducing the craziness quotient of our codebase. -- PMM
diff --git a/include/qemu/compiler.h b/include/qemu/compiler.h index d22eb01..c5fbe28 100644 --- a/include/qemu/compiler.h +++ b/include/qemu/compiler.h @@ -77,18 +77,6 @@ #define typeof_field(type, field) typeof(((type *)0)->field) #define type_check(t1,t2) ((t1*)0 - (t2*)0) -#ifndef always_inline -#if !((__GNUC__ < 3) || defined(__APPLE__)) -#ifdef __OPTIMIZE__ -#undef inline -#define inline __attribute__ (( always_inline )) __inline__ -#endif -#endif -#else -#undef inline -#define inline always_inline -#endif - #define QEMU_BUILD_BUG_ON(x) \ typedef char glue(qemu_build_bug_on__,__LINE__)[(x)?-1:1] __attribute__((unused));
Actively redefining 'inline' is wrong for C++, where gcc has an extension 'inline namespace' which fails to compile if the keyword 'inline' is replaced by a macro expansion. This will matter once we start to include "qemu/osdep.h" first from C++ files, depending also on whether the system headers are new enough to be using the gcc extension. But rather than just guard things by __cplusplus, let's look at the overall picture. Commit df2542c737ea2 in 2007 defined 'inline' to the gcc attribute __always_inline__, with the rationale "To avoid discarded inlining bug". But compilers have improved since then, and we are probably better off trusting the compiler rather than trying to force its hand. So just nuke our craziness. Signed-off-by: Eric Blake <eblake@redhat.com> --- include/qemu/compiler.h | 12 ------------ 1 file changed, 12 deletions(-)