Maybe something like the following: Index: trans-decl.c =================================================================== --- trans-decl.c (revision 192019) +++ trans-decl.c (working copy) @@ -1097,9 +1097,9 @@
/* Also prefix the mangled name. */ if (sym->module) - name = gfc_get_string (".__%s_MOD_%s", sym->module, sym->name); + name = gfc_get_string ("_F_%s_MOD_%s", sym->module, sym->name); else - name = gfc_get_string (".%s", sym->name); + name = gfc_get_string ("_F_%s", sym->name); length = build_decl (input_location, VAR_DECL, get_identifier (name), Thanks, David On Wed, Oct 3, 2012 at 5:00 PM, Tobias Burnus <bur...@net-b.de> wrote: > David, > > > David Edelsohn wrote: >> >> I am not sure why you chose a period and how best to correct this. > > > Well, in principle any name which the user cannot enter would do. (Not > enter: At least not as valid Fortran identifier.) > > The reason for choosing "." is that <dot><var_name> is used elsewhere in > gfortran for such identifier for the string-length variable belonging to > <var_name>, e.g. "._result" in trans-decl.c. I assume the reason that it > didn't pop up with those is that those are local variables, but I wouldn't > be surprised if it would break elsewhere. > > I wonder whether "@" would work, otherwise, one could also use "_". The only > other problem is that it will break the ABI. On the other hand, it's a > rather new feature and if we bump the .mod version number, the chance that > one effectively forces the user to re-compile is rather high. So far we > always bumped the .mod version number as something changed. There are also > some other patches pending which effectively lead to a bump in the .mod > version. > > (The .mod version won't affect code which doesn't use modules such as > BLAS/LAPACK or any Fortran 66/77 code, but those won't be affected by the > ABI change anyway as there the name doesn't propagate as it does with > modules..) > > > Thanks for investigating the test-suite failure. > > Tobias