From: "Павел Крюков" <kryukov@frtk.ru>
To: Simon Marchi <simon.marchi@polymtl.ca>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Simulator: prevent inlining in C++ mode
Date: Tue, 15 Jan 2019 23:31:00 -0000 [thread overview]
Message-ID: <CADip9gaSinsc5h4daRBrrdQvjw+w+AqZz55URpsp4_ynUkb-eA@mail.gmail.com> (raw)
In-Reply-To: <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
>
next prev parent reply other threads:[~2019-01-15 23:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-11 9:59 Павел Крюков
2019-01-15 23:07 ` Simon Marchi
2019-01-15 23:31 ` Павел Крюков [this message]
2019-01-16 18:29 ` Pavel I. Kryukov
2019-01-16 19:51 ` Simon Marchi
2019-01-17 9:53 ` Alan Hayward
2019-01-17 13:20 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CADip9gaSinsc5h4daRBrrdQvjw+w+AqZz55URpsp4_ynUkb-eA@mail.gmail.com \
--to=kryukov@frtk.ru \
--cc=gdb-patches@sourceware.org \
--cc=simon.marchi@polymtl.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox