This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, Fortran, OOP] PR 46971: [4.6 Regression] ICE on long class names


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]