From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15734 invoked by alias); 7 Nov 2010 14:21:21 -0000 Received: (qmail 15716 invoked by uid 22791); 7 Nov 2010 14:21:20 -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 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 14:21:15 +0000 Received: by bwz10 with SMTP id 10so4111907bwz.20 for ; Sun, 07 Nov 2010 06:21:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.117.204 with SMTP id s12mr1513582bkq.60.1289139671715; Sun, 07 Nov 2010 06:21:11 -0800 (PST) Received: by 10.204.7.80 with HTTP; Sun, 7 Nov 2010 06:21:11 -0800 (PST) In-Reply-To: <4CD6A751.6090807@net-b.de> References: <20101106233415.7DA533BE18@mailhost.lps.ens.fr> <4CD65B85.8030903@net-b.de> <4CD6977B.6010002@physik.uni-muenchen.de> <4CD6A751.6090807@net-b.de> Date: Sun, 07 Nov 2010 14:21:00 -0000 Message-ID: Subject: Re: [Patch, Fortran, OOP] PR 46313: OOP-ABI issue, ALLOCATE issue, CLASS renaming issue From: Janus Weil To: Tobias Burnus Cc: =?ISO-8859-1?Q?Tobias_Schl=FCter?= , 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/msg00121.txt.bz2 >>> The best option I can currently see is to use leading underscores (as >>> in "_vtab_main_dt"). This is forbidden in Fortran (cf. F08:R303), but >>> accepted by the assembler (cf. >>> >>> http://sourceware.org/binutils/docs-2.20/as/Symbol-Names.html#Symbol-Na= mes). >>> >>> Attached is a patch which does this change. I also added a few macros >>> in gfortran.h. Ok for trunk after successful regtest? > > +static void > +get_unique_type_string (char *string, gfc_symbol *derived) > +{ > + =A0if (derived->module) > + =A0 =A0sprintf (string, "%s_%s", derived->module, derived->name); > + =A0else > + =A0 =A0sprintf (string, "%s_%s", derived->ns->proc_name->name, derived-= >name); > +} > > I wonder whether that works for cases like: > > * module name =3D=3D procedure name > * internal procedures =3D=3D procedure name / module name. > * Nested submodules (when implemented) > > I assume defining the same-named (and disjunct) DT in a module and > separately in a subroutine is weird; with internal procedures and submodu= les > it will start to get crazy. But shouldn't one do something like > _proc_ for procedures? A {module/procedure > name}_internal-proc-name? > > Alternatively, one can defer it until a real-world bug report comes (whic= h I > think is very unlikely). I also think it's unlikely. And in fact we have enough real-world PRs to deal with right now, so I would prefer to defer this to some point in late stage 3 when we have fixed all the worst bugs and start to get bored ;) The last patch I sent (leading underscore version) regtested fine btw. Is it ok if I commit it now and leave the PR open for the corner cases? Cheers, Janus