From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20180 invoked by alias); 16 Jan 2019 18:29:47 -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 20160 invoked by uid 89); 16 Jan 2019 18:29:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-22.9 required=5.0 tests=BAYES_00,BODY_8BITS,GARBLED_BODY,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=cpp, Gmail, H*F:D*ru X-HELO: mail-it1-f195.google.com Received: from mail-it1-f195.google.com (HELO mail-it1-f195.google.com) (209.85.166.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 16 Jan 2019 18:29:43 +0000 Received: by mail-it1-f195.google.com with SMTP id g76so4606847itg.2 for ; Wed, 16 Jan 2019 10:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=frtk-ru.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3yfFlL9QOk89Qlh8d5P6U5f20/n/BpWAT94/E5dO3vw=; b=dQaEDzVPfzOQ+gqMFaXAdtzRzD/ZgasqvfSo7PflMbj2f0tgE8OyzM0WZHCm//8VMv ovq6cinenAUxA7rUD2djDaevwKgwiMKc9kH3x/6M7E2gsN7X7izmsuKZiVuXuuEIYsnG c1kLhFnh1bJ6diBdPCXYGppMPpwx3m8FtEuIqbjE2xta6HlrcWaq+vnIacCQx601EflC c5BBuSNzsUlKHpbK6JZdPcWdLhwZplQA2XcUzxBEKczg+IbCT5Iydz6WNAqLzYMgNisg GT418pQ9G32QxOgicPMTRFjsGPvhSKQDhKcDas2yOW7hq7c/HNMW0mCHSToVGjbaxtCD uEmg== MIME-Version: 1.0 References: <7d0cf55807aabaf4391662dc5e25b3cf@polymtl.ca> In-Reply-To: From: "Pavel I. Kryukov" Date: Wed, 16 Jan 2019 18:29: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/msg00377.txt.bz2 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 =D1=81=D1=80, 16 =D1=8F=D0=BD=D0=B2. 2019 =D0=B3. =D0=B2 02:31, =D0=9F=D0= =B0=D0=B2=D0=B5=D0=BB =D0=9A=D1=80=D1=8E=D0=BA=D0=BE=D0=B2 : > > 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 ap= plies 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++-s= pecific 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 Mar= chi : >> >> 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