Re: [Qemu-devel] [PATCH 00/14] More #include cleanups

[Peter Maydell]

On 9 February 2016 at 17:18, Eric Blake <address@hidden> wrote:
> On 02/09/2016 10:10 AM, Eric Blake wrote:
>
>> but with the new header order it expands to:
>>
>> # 1989 "/usr/include/c++/5.3.1/x86_64-redhat-linux/bits/c++config.h" 3
>> namespace std
>> {
>>
>> # 1991 "/usr/include/c++/5.3.1/x86_64-redhat-linux/bits/c++config.h"
>>  __attribute__ (( always_inline )) __inline__
>> # 1991 "/usr/include/c++/5.3.1/x86_64-redhat-linux/bits/c++config.h" 3
>>         namespace __cxx11 __attribute__((__abi_tag__ ("cxx11"))) { }
>> }
>>
>> So _something_ in osdep.h is redefining 'inline' with disastrous effects
>> to C++.
>
> This hack seems to fix things; but I'm not enough of a C++ expert to
> know if it is the best fix.
>
> diff --git i/include/qemu/compiler.h w/include/qemu/compiler.h
> index d22eb01..d50b806 100644
> --- i/include/qemu/compiler.h
> +++ w/include/qemu/compiler.h
> @@ -77,6 +77,7 @@
>  #define typeof_field(type, field) typeof(((type *)0)->field)
>  #define type_check(t1,t2) ((t1*)0 - (t2*)0)
>
> +#ifndef __cplusplus
>  #ifndef always_inline
>  #if !((__GNUC__ < 3) || defined(__APPLE__))
>  #ifdef __OPTIMIZE__
> @@ -88,6 +89,7 @@
>  #undef inline
>  #define inline always_inline
>  #endif
> +#endif

Ah, well tracked down. I guess my system headers don't happen
to rely on this bit of inline syntax.

Next question -- do we really need to redefine "inline" to
always_inline at all, in C or C++? (cc'd a few people who might
have an opinion). My instinct is to say "don't do this, just
trust the compiler to decide whether to bother inlining".

Git blame says this was added back in commit df2542c737ea2 in
2007, with the rationale "To avoid discarded inlining bug"...

thanks
-- PMM