From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20780 invoked by alias); 24 Jun 2014 03:13:03 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 20755 invoked by uid 89); 24 Jun 2014 03:12:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: smtp.mozilla.org Received: from mx2.corp.phx1.mozilla.com (HELO smtp.mozilla.org) (63.245.216.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 24 Jun 2014 03:12:57 +0000 Received: from tsaunders-iceball.corp.tor1.mozilla.com (69-165-234-187.cable.teksavvy.com [69.165.234.187]) (Authenticated sender: tsaunders@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 53269F248E; Mon, 23 Jun 2014 20:12:54 -0700 (PDT) Date: Tue, 24 Jun 2014 03:13:00 -0000 From: Trevor Saunders To: Jeff Law Cc: Tom Tromey , gcc-patches@gcc.gnu.org Subject: Re: [PATCH 5/5] add libcc1 Message-ID: <20140624031231.GA1815@tsaunders-iceball.corp.tor1.mozilla.com> References: <1400254001-12038-1-git-send-email-tromey@redhat.com> <87oayx4l0x.fsf@fleche.redhat.com> <87bntobp1f.fsf@fleche.redhat.com> <20140620031058.GA12633@tsaunders-iceball.corp.tor1.mozilla.com> <87vbrv8uje.fsf@fleche.redhat.com> <53A87B75.4090705@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53A87B75.4090705@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg01847.txt.bz2 On Mon, Jun 23, 2014 at 01:09:41PM -0600, Jeff Law wrote: > On 06/20/14 09:33, Tom Tromey wrote: > >>>>>>"Trevor" == Trevor Saunders writes: > > > >Trevor> I'm curious, what is the reason you choose not to write this in C++11 or > >Trevor> later? Its distributed with gcc, so the only case where you aren't > >Trevor> building with the in tree compiler and libraries is when your cross > >Trevor> compiling gcc, and it doesn't seem particularly important to support > >Trevor> building the plugin or library in that configuration. So istm you could > >Trevor> go all the way and assume you are being built with trunk gcc and > >Trevor> libraries. > > > >The plugin has to be ABI compatible with GCC itself, and my > >understanding was that C++11 and "however GCC is built" are not > >necessarily compatible. > Presumably you're referring to the upcoming abi breakage for C++ pair & > list. > > There's ways around that with the ABI tagging we're using, but at least for > now, the safe thing to do for something that must be ABI compatibile with > GCC itself is to stick with C++03 mode. > hrm, I know basically nothing about the upcoming changes, but I would have expected linking c++03 code against c++11 code would be fine especially when the interface doesn't involve any stl. > >Switching to C++11 would be an improvement -- variadic templates would > >simplify the RPC code (with a complicated caveat). So if it is possible > >I am interested. > There'll probably be a day when we can bless C++11 for building GCC itself > and any associated plugins, but we're not at that point right now. > > >Trevor> So can we add C++ stuff to libiberty and allow building > >Trevor> libiberty without it for binutils / gdb, or can we do something > >Trevor> else to avoid this kind of stuff? > > > >One way would be to just make a new top-level directory for a new > >library. > Seems like the easiest solution, at least for now. ugh more autotools, but wfm. > >Thanks. I changed it to do a NULL check. It's nothrow because nothing > >in libcc1 or gdb is prepared for a C++ exception. While I like > >exceptions (gdb uses its own longjmp-based exception system > >extensively), my understanding is that they aren't currently used in > >gcc. > Right. Or if we're using them in GCC, any such use is well buried in > non-critical , not widely known & marginally, if at all, tested code. Well, we build everything or at least everything I've seen with -fno-exceptions, so if something does throw we'll just crash right? istm we certainly write code calling the throwing new with that expectation. Trev > > Jeff >