From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18345 invoked by alias); 15 Jan 2019 23:31:59 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 18329 invoked by uid 89); 15 Jan 2019 23:31:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-21.9 required=5.0 tests=BAYES_00,BODY_8BITS,FROM_EXCESS_BASE64,GARBLED_BODY,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,HTML_MESSAGE,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*c:alternative, H*F:D*ru X-HELO: mail-it1-f196.google.com Received: from mail-it1-f196.google.com (HELO mail-it1-f196.google.com) (209.85.166.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 15 Jan 2019 23:31:56 +0000 Received: by mail-it1-f196.google.com with SMTP id w18so356883ite.1 for ; Tue, 15 Jan 2019 15:31:56 -0800 (PST) MIME-Version: 1.0 References: <7d0cf55807aabaf4391662dc5e25b3cf@polymtl.ca> In-Reply-To: <7d0cf55807aabaf4391662dc5e25b3cf@polymtl.ca> From: =?UTF-8?B?0J/QsNCy0LXQuyDQmtGA0Y7QutC+0LI=?= Date: Tue, 15 Jan 2019 23:31:00 -0000 Message-ID: Subject: Re: [PATCH] Simulator: prevent inlining in C++ mode To: Simon Marchi Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2019-01/txt/msg00365.txt.bz2 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 =D1=81=D1=80, 16 =D1=8F=D0=BD=D0=B2. 2019 =D0=B3. =D0=B2 02:07, Simon March= i : > On 2019-01-11 04:59, =D0=9F=D0=B0=D0=B2=D0=B5=D0=BB =D0=9A=D1=80=D1=8E=D0= =BA=D0=BE=D0=B2 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 > > > > * 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 >