Re: [PATCH] Simulator: prevent inlining in C++ mode

["Pavel I. Kryukov" <kryukov@frtk.ru>]

Okay, there are no C++ compiler errors other than macro expansion,
so this patch may be ignored. I submitted a separate patch for macros
expansion (https://sourceware.org/ml/gdb-patches/2019-01/msg00367.html)

(Sorry, I still get lines wrapped in patches while sending them via Gmail.
Could you please tell if there is a workaround?)

Thanks,
--
Pavel

ср, 16 янв. 2019 г. в 02:31, Павел Крюков <kryukov@frtk.ru>:

>
> I got an error with that code:
>
> #define DEFINE_INLINE_P (! defined (SIM_ARANGE_C_INCLUDED))
> #define DEFINE_NON_INLINE_P defined (SIM_ARANGE_C_INCLUDED)
> #if DEFINE_NON_INLINE_P
>
> as it contains undefined behavior (see https://gcc.gnu.org/onlinedocs/cpp/Defined.html).
> Probably, it's better to revise the macro completely, as the same rule applies to C as well.
>
> However, even it is fixed, the remaining code of sim-arange.c is a C code and I do not
> want to pass it to my C++ compiler, as it is usually accompanied by C++-specific sanitizers
> For instance, they forbid C-style cast, malloc/free etc. Additionally, it would be quite hard
> to keep sim-arange.c C++-compatible all the time.
>
> Thanks,
> --
> Pavel
>
>
>
> ср, 16 янв. 2019 г. в 02:07, Simon Marchi <simon.marchi@polymtl.ca>:
>>
>> On 2019-01-11 04:59, Павел Крюков wrote:
>> > Simulator: prevent inlining in C++ mode
>> >
>> > sim-arange.c contains C code and cannot be built with C++ compiler.
>> > Instead, it should be built separately by C compiler w/o inlining.
>> >
>> > sim/common/Changelog:
>> > 2019-01-11  Pavel I. Kryukov  <kryukov@frtk.ru>
>> >
>> >         * sim-inline.h: don't define HAVE_INLINE with __cplusplus
>> >
>> > diff --git a/sim/common/sim-inline.h b/sim/common/sim-inline.h
>> > index b2a3fc3..e9fb5c7 100644
>> > --- a/sim/common/sim-inline.h
>> > +++ b/sim/common/sim-inline.h
>> > @@ -282,7 +282,7 @@
>> >
>> >
>> >  #ifndef HAVE_INLINE
>> > -#ifdef __GNUC__
>> > +#if defined(__GNUC__) && !defined(__cplusplus)
>> >  #define HAVE_INLINE
>> >  #endif
>> >  #endif
>>
>> What kind of errors do you get?  Would it be possible to modify the code
>> so it compiles both as C and C++?  If all this trouble was taken to make
>> these functions inline-able, I asusme that it's because the speedup is
>> significant.
>>
>> Simon