Jakub Jelinek wrote:
So, what about this version instead?
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2012-12-11 Jakub Jelinek<ja...@redhat.com>
Janus Weil<ja...@gcc.gnu.org>
PR fortran/55636
* gfortran.h (GFC_PREFIX): Define.
* trans-decl.c (gfc_create_string_length): For VAR_DECLs that
will be TREE_STATIC, use GFC_PREFIX to mangle the names.
…
/* Also prefix the mangled name. */
- if (sym->module)
+ if (sym->attr.save || sym->ns->proc_name->attr.flavor == FL_MODULE)
+ {
+ if (sym->module)
+ name = gfc_get_string (GFC_PREFIX ("%s_MOD_%s"), sym->module,
+ sym->name);
+ else
+ name = gfc_get_string (GFC_PREFIX ("%s"), sym->name);
+ }
+ else if (sym->module)
name = gfc_get_string (".__%s_MOD_%s", sym->module, sym->name);
else
name = gfc_get_string (".%s", sym->name);
Looks mostly okay, however, I fear that for
subroutine foo()
character(len=:), allocatable :: str
allocate(str, stat=istat)
end subroutine foo
compiled with "-fno-automatic", gfortran will still generate the
non-GFC_PREFIX-mangled string.
"-fno-automatic" implies SAVE / static memory and is required by some
old code. Hence, it is unlikely to be used with new code; still,
gfortran should get this right. (Actually, as PR55733 shows, there are
issues beyond the mangling with -fno-automatic for deferred-length
strings/scalar allocatables).
Thus, I wonder whether one should always use GFC_PREFIX. On the other
hand, for scan-tree-dump, it is nice to have a single mangling instead
of 3 different ones. (Though, currently, no scan-tree-dump seems to be
used in this case.)
Hence:
OK with either always using GFC_PREFIX – or with an additional "&&
gfc_option.flag_max_stack_var_size == 0" check and a comment why the
mangling is done.
Tobias
