From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22661 invoked by alias); 20 Mar 2012 11:47:27 -0000 Received: (qmail 22653 invoked by uid 22791); 20 Mar 2012 11:47:26 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail1-relais-roc.national.inria.fr (HELO mail1-relais-roc.national.inria.fr) (192.134.164.82) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Mar 2012 11:47:03 +0000 Received: from unknown (HELO pluto) ([193.50.110.167]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 20 Mar 2012 12:47:01 +0100 From: ludovic.courtes@inria.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) To: Richard Guenther Cc: David Malcolm , Ian Lance Taylor , Andrew Pinski , gcc@gcc.gnu.org Subject: Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1) References: <877gyu85mc.fsf@inria.fr> <87ty1y6oq2.fsf@inria.fr> <877gytvl0o.fsf@inria.fr> <87r4x1r9re.fsf@inria.fr> <87pqciurih.fsf@inria.fr> <87obrwyfhg.fsf@inria.fr> <87ty1ou26x.fsf@inria.fr> <87mx7gshhk.fsf@inria.fr> <1331918370.2174.50.camel@surprise> <87ehsobo18.fsf@inria.fr> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 1 Germinal an 220 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu Date: Tue, 20 Mar 2012 11:47:00 -0000 In-Reply-To: (Richard Guenther's message of "Mon, 19 Mar 2012 16:57:51 +0100") Message-ID: <87r4wnwl3e.fsf@inria.fr> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2012-03/txt/msg00307.txt.bz2 Hi Richard, Richard Guenther skribis: > 2012/3/19 Ludovic Court=C3=A8s : [...] >> In the example of name mangling, I=E2=80=99d just have wrapped in =E2=80= =98extern "C"=E2=80=99 >> all the headers listed in =E2=80=98PLUGIN_HEADERS=E2=80=99 in gcc/Makefi= le.in. =C2=A0The >> rationale is that it simplifies plug-in maintenance, while not impeding >> development work in 4.7. > > Well, that's _all_ headers. Basically. Well, these headers get installed, and they get installed to be actually used, don=E2=80=99t they? :-) > And exactly the problem. There will be never even API compatibility > between major releases of GCC with the current plugin "API". My experience is more encouraging: between 4.5 and 4.6, I was only hit by a couple of tree.h declarations found in one and not the other. When switching to 4.7, the main problem was mangled names, and all the problems that making my code compilable with g++ entails. Other issues were the removal of the =E2=80=98built_in_decls=E2=80=99 array, and the new =E2=80=98affects_type_identity=E2=80=99 field of =E2=80=98attribute_spec=E2= =80=99. All this is summarized in the Autoconf macro I use [0]: dnl build_call_expr_loc_array -- not in GCC 4.5.x; appears in 4.6 dnl build_call_expr_loc_vec -- likewise dnl build_array_ref -- present but undeclared in 4.6.1 dnl build_zero_cst -- not in GCC 4.5.x; appears in 4.6 dnl builtin_decl_explicit -- new in 4.7, replaces `built_in_decls' dnl .affects_type_identity -- new field in 4.7 Then again, my plug-in is relatively small, and uses a small part of GCC. Plug-ins with a larger API footprint may have more problems, of course. Thanks, Ludo=E2=80=99. [0] https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?view=3Dmarkup&ro= ot=3Dstarpu