This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Patch, Fortran, OOP] PR 46971: [4.6 Regression] ICE on long class names
- From: Janus Weil <janus at gcc dot gnu dot org>
- To: salvatore dot filippone at uniroma2 dot it
- Cc: fortran at gcc dot gnu dot org
- Date: Thu, 30 Dec 2010 22:37:56 +0100
- Subject: Re: [Patch, Fortran, OOP] PR 46971: [4.6 Regression] ICE on long class names
- References: <1293743094.2387.3.camel@localhost.localdomain>
Hi Salvatore,
>> So we just use this hash value (in hex representation) for the class
>> container naming, e.g. "__class_12083EB", which guarantees to respect
>> the 63 character limit. These names are not user-visible, of course,
>> so this obfuscation's only negative effect may be in debugging the
>> internal class symbols. Therefore we keep the name constructed from
>> the old scheme if it is short enough, and only use the hash for those
>> cases where the 63 character limit is violated.
>
>
> This scheme will make it impossible for cmake and other cross-language
> build tools to figure out the module name mangling. Yes, I know mixed
> language should go with ISO_C_BINDING, but ?I'd like to cross-check with
> the cmake foks, or this would give trouble to project using it (e.g.
> ForTrilinos)
I'm not sure I'm getting your point. The naming scheme that we're
discussing does neither affect the modules themselves, nor any of the
user-defined variables or routines. It only affects the
compiler-generated internal symbols (class containers, vtables, etc).
Anyway, cross-language OOP is *very* tricky, since it's not part of
any standard yet. If you're trying to do that, you'll probably have
harder problems to solve than dealing with our naming scheme.
Also, I don't know a lot about cmake, but I don't see in which way it
could be affected ...?!?
Cheers,
Janus