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 <[email protected]> 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
