From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15983 invoked by alias); 7 Nov 2010 15:50:05 -0000 Received: (qmail 15949 invoked by uid 22791); 7 Nov 2010 15:50:03 -0000 X-SWARE-Spam-Status: No, hits=-0.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,TW_FN X-Spam-Check-By: sourceware.org Received: from mail-bw0-f47.google.com (HELO mail-bw0-f47.google.com) (209.85.214.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 07 Nov 2010 15:49:36 +0000 Received: by bwz10 with SMTP id 10so4158902bwz.20 for ; Sun, 07 Nov 2010 07:49:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.116.5 with SMTP id k5mr3932440bkq.141.1289144974231; Sun, 07 Nov 2010 07:49:34 -0800 (PST) Received: by 10.204.7.80 with HTTP; Sun, 7 Nov 2010 07:49:34 -0800 (PST) In-Reply-To: <4CD6C713.2020709@physik.uni-muenchen.de> References: <20101106233415.7DA533BE18@mailhost.lps.ens.fr> <4CD65B85.8030903@net-b.de> <4CD6977B.6010002@physik.uni-muenchen.de> <4CD6A751.6090807@net-b.de> <4CD6C713.2020709@physik.uni-muenchen.de> Date: Sun, 07 Nov 2010 15:50:00 -0000 Message-ID: Subject: Re: [Patch, Fortran, OOP] PR 46313: OOP-ABI issue, ALLOCATE issue, CLASS renaming issue From: Janus Weil To: =?ISO-8859-1?Q?Tobias_Schl=FCter?= Cc: Tobias Burnus , Dominique Dhumieres , fortran , gcc-patches , tkoenig Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org X-SW-Source: 2010-11/txt/msg00123.txt.bz2 >>>>>> Yes, that is expected, because the patch changes the name of the vtab >>>>>> to "vtab$main$dt", so one needs to change the name of the subroutine >>>>>> in the test case in the same way in order to see the failure: >>> >>> Sorry I'm late, but gcc has the macro ASM_FORMAT_PRIVATE_NAME which does >>> the work of making a name collision-free. If you use it you can make the >>> rest of the name as readable as you want. >> >> I think that it won't work. One needs the same assembler name for in >> each translation unit as there is one, common, global vtable per base >> type. My understanding is that ASM_FORMAT_PRIVATE_NAME would generate >> several disjunct assembler names... > > I don't think so, it only adds a platform-dependent character to the > variable name. =A0The offered varieties cover exactly what was suggested = in > this thread so far: > > #ifndef ASM_PN_FORMAT > # ifndef NO_DOT_IN_LABEL > # =A0define ASM_PN_FORMAT "%s.%lu" > # else > # =A0ifndef NO_DOLLAR_IN_LABEL > # =A0 define ASM_PN_FORMAT "%s$%lu" > # =A0else > # =A0 define ASM_PN_FORMAT "__%s_%lu" > # =A0endif > # endif > #endif /* ! ASM_PN_FORMAT */ > > #ifndef ASM_FORMAT_PRIVATE_NAME > # define ASM_FORMAT_PRIVATE_NAME(OUTPUT, NAME, LABELNO) \ > =A0do { const char *const name_ =3D (NAME); \ > =A0 =A0 =A0 char *const output_ =3D (OUTPUT) =3D \ > =A0 =A0 =A0 =A0 (char *) alloca (strlen (name_) + 32); \ > =A0 =A0 =A0 sprintf (output_, ASM_PN_FORMAT, name_, (unsigned long)(LABEL= NO)); \ > =A0} while (0) > #endif Yes, I think it would do the job. But we actually do not need the additional number. Btw, what is the reason for the macro adding *two* underscores in front, instead of just one? Cheers, Janus