This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Simulator: prevent inlining in C++ mode
- From: Павел Крюков <kryukov at frtk dot ru>
- To: Simon Marchi <simon dot marchi at polymtl dot ca>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 16 Jan 2019 02:31:43 +0300
- Subject: Re: [PATCH] Simulator: prevent inlining in C++ mode
- References: <CADip9gbbSjB8s9-E8MzgM4cDHig=NpUnh+eSyOC8drYb1VOBPw@mail.gmail.com> <7d0cf55807aabaf4391662dc5e25b3cf@polymtl.ca>
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
>