Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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
>


  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