diff mbox

[Fortran,(RFC)] PR49110/51055 Assignment to alloc. deferred-length character vars

Message ID CAGWvnykzKRL=u-X1X5wbU_o2v6aEbp17veePgWWQbwQohkcv9w@mail.gmail.com
State New
Headers show

Commit Message

David Edelsohn Oct. 3, 2012, 11:15 p.m. UTC 
Maybe something like the following:


Thanks, David

On Wed, Oct 3, 2012 at 5:00 PM, Tobias Burnus <burnus@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

Comments

David Edelsohn Oct. 3, 2012, 11:49 p.m. UTC | #1 
Another suggestion from Segher is "_F.", which is both reserve and
cannot conflict with C/C++ because identifiers cannot contain ".".

- David
Mike Stump Oct. 4, 2012, 12:29 a.m. UTC | #2 
On Oct 3, 2012, at 4:49 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
> Another suggestion from Segher is "_F.", which is both reserve and
> cannot conflict with C/C++ because identifiers cannot contain ".".

The problem with that are machines that don't like "." in identifiers (aka NO_DOT_IN_LABEL)…  so one just has to be a little careful in using it.
David Edelsohn Oct. 4, 2012, 12:46 a.m. UTC | #3 
On Wed, Oct 3, 2012 at 8:29 PM, Mike Stump <mikestump@comcast.net> wrote:
> On Oct 3, 2012, at 4:49 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
>> Another suggestion from Segher is "_F.", which is both reserve and
>> cannot conflict with C/C++ because identifiers cannot contain ".".
>
> The problem with that are machines that don't like "." in identifiers (aka NO_DOT_IN_LABEL)…  so one just has to be a little careful in using it.

That's a good reason to use "_F".  And NO_DOT_IN_LABEL systems will
not function with the current "." mangling.

- David
diff mbox

Patch

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),