Message ID | 1423524046-20605-10-git-send-email-palves@redhat.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 10969 invoked by alias); 9 Feb 2015 23:21:05 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 10950 invoked by uid 89); 9 Feb 2015 23:21:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL, BAYES_00, SPF_HELO_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 09 Feb 2015 23:21:04 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t19NKxqB010988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 9 Feb 2015 18:20:59 -0500 Received: from brno.lan (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t19NKkuY026307; Mon, 9 Feb 2015 18:20:59 -0500 From: Pedro Alves <palves@redhat.com> To: gdb-patches@sourceware.org Cc: GCC Patches <gcc-patches@gcc.gnu.org> Subject: [PATCH 09/36] floatformat.h: Wrap in extern "C". Date: Mon, 9 Feb 2015 23:20:19 +0000 Message-Id: <1423524046-20605-10-git-send-email-palves@redhat.com> In-Reply-To: <1423524046-20605-1-git-send-email-palves@redhat.com> References: <1423524046-20605-1-git-send-email-palves@redhat.com> |
Commit Message
Pedro Alves
Feb. 9, 2015, 11:20 p.m. UTC
Just like libiberty.h. So that C++ programs, such as GDB when built as a C++ program, can use it. include/ChangeLog: 2015-02-09 Pedro Alves <palves@redhat.com> * floatformat.h [__cplusplus]: Wrap in extern "C". --- include/floatformat.h | 8 ++++++++ 1 file changed, 8 insertions(+)
Comments
On Mon, Feb 9, 2015 at 3:20 PM, Pedro Alves <palves@redhat.com> wrote: > Just like libiberty.h. So that C++ programs, such as GDB when built > as a C++ program, can use it. Why is not needed for GCC building with C++ compiler? Thanks, Andrew > > include/ChangeLog: > 2015-02-09 Pedro Alves <palves@redhat.com> > > * floatformat.h [__cplusplus]: Wrap in extern "C". > --- > include/floatformat.h | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/include/floatformat.h b/include/floatformat.h > index 6b559864..71d332b 100644 > --- a/include/floatformat.h > +++ b/include/floatformat.h > @@ -20,6 +20,10 @@ Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA 02110-1301, USA. > #if !defined (FLOATFORMAT_H) > #define FLOATFORMAT_H 1 > > +#ifdef __cplusplus > +extern "C" { > +#endif > + > #include "ansidecl.h" > > /* A floatformat consists of a sign bit, an exponent and a mantissa. Once the > @@ -148,4 +152,8 @@ floatformat_from_double (const struct floatformat *, const double *, void *); > extern int > floatformat_is_valid (const struct floatformat *fmt, const void *from); > > +#ifdef __cplusplus > +} > +#endif > + > #endif /* defined (FLOATFORMAT_H) */ > -- > 1.9.3 >
On 02/09/2015 11:35 PM, Andrew Pinski wrote: > On Mon, Feb 9, 2015 at 3:20 PM, Pedro Alves <palves@redhat.com> wrote: >> Just like libiberty.h. So that C++ programs, such as GDB when built >> as a C++ program, can use it. > > Why is not needed for GCC building with C++ compiler? Because it doesn't include it. The header of the file claims it is part of GDB, though MAINTAINERS nowadays says that everything under include/ is owned by GCC. Thanks, Pedro Alves
On Mon, Feb 9, 2015 at 3:49 PM, Pedro Alves <palves@redhat.com> wrote: > On 02/09/2015 11:35 PM, Andrew Pinski wrote: >> On Mon, Feb 9, 2015 at 3:20 PM, Pedro Alves <palves@redhat.com> wrote: >>> Just like libiberty.h. So that C++ programs, such as GDB when built >>> as a C++ program, can use it. >> >> Why is not needed for GCC building with C++ compiler? > > Because it doesn't include it. > > The header of the file claims it is part of GDB, though MAINTAINERS > nowadays says that everything under include/ is owned by GCC. Wait, what? The actual wording is: "The rule is that if the file exists in the gcc tree then gcc owns it." It originated from this thread, https://sourceware.org/ml/gdb/2013-11/msg00025.html That's not the first message in the thread, but that's where I remember wanting to see something written down. Perhaps kinda unfortunate for things like include/gdb/gdb-index.h. But at least it's a rule that can be expressed in one sentence, and I don't think it's been a problem.
On 02/14/2015 05:29 PM, Doug Evans wrote: > On Mon, Feb 9, 2015 at 3:49 PM, Pedro Alves <palves@redhat.com> wrote: >> On 02/09/2015 11:35 PM, Andrew Pinski wrote: >>> Why is not needed for GCC building with C++ compiler? >> >> Because it doesn't include it. >> >> The header of the file claims it is part of GDB, though MAINTAINERS >> nowadays says that everything under include/ is owned by GCC. > > Wait, what? > > The actual wording is: > "The rule is that if the file exists in the gcc tree then gcc owns it." I was paraphrasing, and simplified it. That distinction seems irrelevant to me here because the file does exist in the gcc tree. It's necessary to build libiberty (for libiberty/floatformat.o). It's a fact that the header claims it is part of GDB: ~~~~~~ /* IEEE floating point support declarations, for GDB, the GNU Debugger. Copyright (C) 1991-2015 Free Software Foundation, Inc. This file is part of GDB. (...) ~~~~~~ I guess it should say that it is part of libiberty instead. > It originated from this thread, > https://sourceware.org/ml/gdb/2013-11/msg00025.html > That's not the first message in the thread, but that's where > I remember wanting to see something written down. > > Perhaps kinda unfortunate for things like include/gdb/gdb-index.h. > But at least it's a rule that can be expressed in one sentence, > and I don't think it's been a problem. I'm confused -- I didn't say it was a problem, nor expressed any concern with the rule. I just was pointing out facts. ISTM that the procedure here is to push this change first through the gcc repo first, and then merge it to binutils-gdb git. Is that wrong? Thanks, Pedro Alves
On Sat, Feb 14, 2015 at 10:36 AM, Pedro Alves <palves@redhat.com> wrote: > On 02/14/2015 05:29 PM, Doug Evans wrote: >> On Mon, Feb 9, 2015 at 3:49 PM, Pedro Alves <palves@redhat.com> wrote: >>> On 02/09/2015 11:35 PM, Andrew Pinski wrote: >>>> Why is not needed for GCC building with C++ compiler? >>> >>> Because it doesn't include it. >>> >>> The header of the file claims it is part of GDB, though MAINTAINERS >>> nowadays says that everything under include/ is owned by GCC. >> >> Wait, what? >> >> The actual wording is: >> "The rule is that if the file exists in the gcc tree then gcc owns it." > > I was paraphrasing, and simplified it. That distinction seems > irrelevant to me here because the file does exist in the gcc tree. > It's necessary to build libiberty (for libiberty/floatformat.o). No worries, I just wanted to make sure it didn't say something it shouldn't. > It's a fact that the header claims it is part of GDB: > > ~~~~~~ > /* IEEE floating point support declarations, for GDB, the GNU Debugger. > Copyright (C) 1991-2015 Free Software Foundation, Inc. > > This file is part of GDB. > (...) > ~~~~~~ > > I guess it should say that it is part of libiberty instead. At the least the current wording is confusing. >> It originated from this thread, >> https://sourceware.org/ml/gdb/2013-11/msg00025.html >> That's not the first message in the thread, but that's where >> I remember wanting to see something written down. >> >> Perhaps kinda unfortunate for things like include/gdb/gdb-index.h. >> But at least it's a rule that can be expressed in one sentence, >> and I don't think it's been a problem. > > I'm confused -- I didn't say it was a problem, nor expressed any > concern with the rule. I just was pointing out facts. I didn't say you said it was a problem. It was just an offhand comment about the rule itself, not anything you said. > ISTM that the procedure here is to push this change first through > the gcc repo first, and then merge it to binutils-gdb git. Is that > wrong? That's the procedure as I understand it.
diff --git a/include/floatformat.h b/include/floatformat.h index 6b559864..71d332b 100644 --- a/include/floatformat.h +++ b/include/floatformat.h @@ -20,6 +20,10 @@ Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA 02110-1301, USA. #if !defined (FLOATFORMAT_H) #define FLOATFORMAT_H 1 +#ifdef __cplusplus +extern "C" { +#endif + #include "ansidecl.h" /* A floatformat consists of a sign bit, an exponent and a mantissa. Once the @@ -148,4 +152,8 @@ floatformat_from_double (const struct floatformat *, const double *, void *); extern int floatformat_is_valid (const struct floatformat *fmt, const void *from); +#ifdef __cplusplus +} +#endif + #endif /* defined (FLOATFORMAT_H) */