>> Thanks for the suggestions. The attached patch changes all "."-something
>> symbol names, which I found.
>>
>> Build and regtested on x86-64-gnu-linux.
>> OK for the trunk and 4.7? (".saved_dovar" also occurs in 4.6; we could also
>> backport that part to 4.6, but I am not sure whether it is needed.)
>
> I think at least for trunk it should be ok.
One more comment: Since its appearance is a bit scattered in the code,
how about using a small macro which prepends the "_F" prefix to a
given variable name?
Btw, note that we are using a double underscore scheme in other places
(like __class, __vtab, __vtype, etc). I have even used an '@' in one
place, namely (hidden) procedure pointer results ("ppr@"). Is there a
need to unify all those cases?
Cheers,
Janus
>> Am 04.10.2012 01:07, schrieb David Edelsohn:
>>
>>> For C and C++, identifiers beginning with underscore and upper case
>>> letter or with two underscores are reserve to the implementation. C++
>>> uses _Z for mangling.
>>>
>>> Maybe Fortran could prepend "_F". Something beginning with an
>>> underscore seems like a much better choice, given the rules about
>>> reserved identifiers.
>>>
>>> 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
>>
>>
