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

login
register
mail settings
Submitter Tobias Burnus
Date Oct. 4, 2012, 9:55 a.m.
Message ID <506D5D21.7080201@net-b.de>
Download mbox | patch
Permalink /patch/189082/
State New
Headers show

Comments

Tobias Burnus - Oct. 4, 2012, 9:55 a.m.
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.)

We probably should also bump the .mod version (and timely also commit 
the patch http://gcc.gnu.org/ml/fortran/2012-04/msg00033.html). Comments?

Tobias


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 <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
Janus Weil - Oct. 4, 2012, 10:17 a.m.
2012/10/4 Tobias Burnus <burnus@net-b.de>:
> 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.


> We probably should also bump the .mod version (and timely also commit the
> patch http://gcc.gnu.org/ml/fortran/2012-04/msg00033.html).

Strong agreement here :)


> Comments?

When backporting to 4.6 and 4.7, do you intend to also bump the module
version there? Does that make sense?

Moreover, ".__result" probably goes back even further than 4.6, right?

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 <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
>
>
Janus Weil - Oct. 4, 2012, 10:50 a.m.
>> 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 <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
>>
>>
Mikael Morin - Oct. 4, 2012, 10:56 a.m.
Le 04/10/2012 12:17, Janus Weil a écrit :
> 
> When backporting to 4.6 and 4.7, do you intend to also bump the module
> version there? Does that make sense?
> 
If the module version is different from that of trunk, please don't, as
we would have two different module formats with the same module version.
I have proposed before to encode the gcc major version in the module
version, but there wasn't much interest back then.
There should be a better way to detect ABI incompatibilities, really.

Mikael
Janne Blomqvist - Oct. 4, 2012, 11:15 a.m.
On Thu, Oct 4, 2012 at 1:50 PM, Janus Weil <janus@gcc.gnu.org> wrote:
>>> 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?

For "normal" identifiers in a module, the current scheme of
"__modulename_MOD_symbolname" is probably too widely entrenched e.g.
in debuggers and various interoperability toolkits to be worth
changing at this point. The OOP stuff OTOH is IMHO sufficiently new
that there is little harm in changing it.

I was thinking about this in the beginning of the year and produced
the attached document (I never sent it before as I realized I wouldn't
have time to do anything about it myself in the near future). Funnily,
I also came up with the idea of "_F" at that point, though maybe not
so surprising as I also studied the g++ name mangling for inspiration.
Also note that the document itself has a perhaps naive approach which
does not consider backwards compatibility enough (see e.g. the above
paragraph).

Some related mangling PR's:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51802

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52606 (not the PR itself,
but the discussion in the comments)
Tobias Burnus - Oct. 4, 2012, 11:16 a.m.
Hi Janus,

Janus Weil wrote:
> When backporting to 4.6 and 4.7, do you intend to also bump the module 
> version there? Does that make sense?

Probably not. The .__result and the .saved_dovar are not ABI relevant, 
thus, they can be changed without problems - but also not that 
important. The module variable is more crucial, but I think we should 
avoid bumping the module version. I think we should only change the trunk.

> Moreover, ".__result" probably goes back even further than 4.6, right?

Presumably yes.

Janus Weil wrote:
> 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?

It think it would be useful to unify those. Are you volunteering?

Regarding the "@": GCC only has: NO_DOLLAR_IN_LABEL and NO_DOT_IN_LABEL. 
However, I would be also careful with the @ label.

The @ has also a special meaning to assemblers. However, if the name 
with the @ is not publicly visible, the name does not occur in the 
assembler file (except as string for the debug information). Thus, there 
should be no real problem. Still, one should consider to change also 
them to the _F convention.

Tobias
Janus Weil - Oct. 4, 2012, 12:50 p.m.
Hi,

>> 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?
>
>
> It think it would be useful to unify those. Are you volunteering?

yeah, why not ;)

Attached is a draft patch (not regtested), which adds a macro
GFC_PREFIX (in gfortran.h) to prepend "_F" to the cases included in
Tobias' earlier patch as well as the OOP-related stuff and procedure
pointer results. It also bumps the module version.

Any comments so far? (Of course the name of the macro can be debated.
I just tried to keep it short for now.)

Cheers,
Janus
Janus Weil - Oct. 4, 2012, 9:04 p.m.
Hi all,

>>> 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?
>>
>>
>> It think it would be useful to unify those. Are you volunteering?
>
> yeah, why not ;)
>
> Attached is a draft patch (not regtested), which adds a macro
> GFC_PREFIX (in gfortran.h) to prepend "_F" to the cases included in
> Tobias' earlier patch as well as the OOP-related stuff and procedure
> pointer results. It also bumps the module version.
>
> Any comments so far? (Of course the name of the macro can be debated.
> I just tried to keep it short for now.)

unfortunately my previous patch regressed on the proc_ptr_result test
cases (due to problems with implicit typing of symbols with leading
underscores, which also were the reason for using a suffix instead of
a prefix for proc-ptr results in the first place). So I have taken out
the 'ppr' parts, leaving only Tobias' original cases and the OOP
stuff, which at least should be regression-free now.

There are some more double-underscore cases which one could also
change into the new _F convention. Should I keep going in this
direction, or should we rather restrict this to the "leading dot"
cases for now? I guess this is a question of how much ABI breaking we
are willing to take. Opinions?

Cheers,
Janus
David Edelsohn - Dec. 10, 2012, 12:48 a.m.
There has been no progress on this bug for over two months.  I have
opened PR fortran/55636.  This must be fixed before GCC 4.8 ships.

Thanks, David

On Thu, Oct 4, 2012 at 5:04 PM, Janus Weil <janus@gcc.gnu.org> wrote:
> Hi all,
>
>>>> 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?
>>>
>>>
>>> It think it would be useful to unify those. Are you volunteering?
>>
>> yeah, why not ;)
>>
>> Attached is a draft patch (not regtested), which adds a macro
>> GFC_PREFIX (in gfortran.h) to prepend "_F" to the cases included in
>> Tobias' earlier patch as well as the OOP-related stuff and procedure
>> pointer results. It also bumps the module version.
>>
>> Any comments so far? (Of course the name of the macro can be debated.
>> I just tried to keep it short for now.)
>
> unfortunately my previous patch regressed on the proc_ptr_result test
> cases (due to problems with implicit typing of symbols with leading
> underscores, which also were the reason for using a suffix instead of
> a prefix for proc-ptr results in the first place). So I have taken out
> the 'ppr' parts, leaving only Tobias' original cases and the OOP
> stuff, which at least should be regression-free now.
>
> There are some more double-underscore cases which one could also
> change into the new _F convention. Should I keep going in this
> direction, or should we rather restrict this to the "leading dot"
> cases for now? I guess this is a question of how much ABI breaking we
> are willing to take. Opinions?
>
> Cheers,
> Janus
Steve Kargl - Dec. 10, 2012, 1:51 a.m.
On Sun, Dec 09, 2012 at 07:48:44PM -0500, David Edelsohn wrote:
> There has been no progress on this bug for over two months.  I have
> opened PR fortran/55636.  This must be fixed before GCC 4.8 ships.
> 

Somethings are hard to fix.  They are especially hard to
fix when one relies on volunteers, who are doing the 
best that they can with the limited amount of time 
that they have.

PS: You forgot to attach your patch that fixes this problem.
Janus Weil - Dec. 10, 2012, 9:22 a.m.
2012/12/10 David Edelsohn <dje.gcc@gmail.com>:
> There has been no progress on this bug for over two months.  I have
> opened PR fortran/55636.  This must be fixed before GCC 4.8 ships.

Thanks for pinging, David. I almost forgot about it ...

Here is a re-diffed version of my previous patch. I'd be grateful for
comments. In particular: Does it fix all the problems on AIX? (For
more open questions, see below.)

Cheers,
Janus



> On Thu, Oct 4, 2012 at 5:04 PM, Janus Weil <janus@gcc.gnu.org> wrote:
>>
>> unfortunately my previous patch regressed on the proc_ptr_result test
>> cases (due to problems with implicit typing of symbols with leading
>> underscores, which also were the reason for using a suffix instead of
>> a prefix for proc-ptr results in the first place). So I have taken out
>> the 'ppr' parts, leaving only Tobias' original cases and the OOP
>> stuff, which at least should be regression-free now.
>>
>> There are some more double-underscore cases which one could also
>> change into the new _F convention. Should I keep going in this
>> direction, or should we rather restrict this to the "leading dot"
>> cases for now? I guess this is a question of how much ABI breaking we
>> are willing to take. Opinions?
>>
>> Cheers,
>> Janus
Jakub Jelinek - Dec. 10, 2012, 9:42 a.m.
On Mon, Dec 10, 2012 at 10:22:30AM +0100, Janus Weil wrote:
> 2012/12/10 David Edelsohn <dje.gcc@gmail.com>:
> > There has been no progress on this bug for over two months.  I have
> > opened PR fortran/55636.  This must be fixed before GCC 4.8 ships.
> 
> Thanks for pinging, David. I almost forgot about it ...
> 
> Here is a re-diffed version of my previous patch. I'd be grateful for
> comments. In particular: Does it fix all the problems on AIX? (For
> more open questions, see below.)

IMHO there is no point to mangle automatic vars or PARM_DECLs that way,
i.e. anything that won't be TREE_STATIC.  And, what will be TREE_STATIC
should have dot or $ character in the symbol name if the target allows it,
to avoid unnecessary clashes with e.g. the C library etc.

	Jakub
Janus Weil - Dec. 10, 2012, 9:56 a.m.
>> Here is a re-diffed version of my previous patch. I'd be grateful for
>> comments. In particular: Does it fix all the problems on AIX? (For
>> more open questions, see below.)
>
> IMHO there is no point to mangle automatic vars or PARM_DECLs that way,
> i.e. anything that won't be TREE_STATIC.  And, what will be TREE_STATIC
> should have dot or $ character in the symbol name if the target allows it,
> to avoid unnecessary clashes with e.g. the C library etc.

well, I'm not an expert for C/C++ name mangling, but this patch was
motivated by David's earlier statement:

> For C and C++, identifiers beginning with underscore and upper case
> letter or with two underscores are reserve to the implementation.

See the previous discussion in this thread ...

Cheers,
Janus
Jakub Jelinek - Dec. 10, 2012, 10:05 a.m.
On Mon, Dec 10, 2012 at 10:56:58AM +0100, Janus Weil wrote:
> > For C and C++, identifiers beginning with underscore and upper case
> > letter or with two underscores are reserve to the implementation.
> 
> See the previous discussion in this thread ...

That's true, but the implementation isn't just GCC, it is also C libraries
which aren't provided by GCC.  Including a character (if possible) that
will make it unaccessible from C/C++ is desirable.  And, not changing the
names of non-TREE_STATIC vars is also desirable, those I'm afraid show up
in the debug info from time to time, so making them unnecessarily larger
results in .debug_info size increases.

	Jakub
David Edelsohn - Dec. 10, 2012, 3:45 p.m.
On Mon, Dec 10, 2012 at 4:22 AM, Janus Weil <janus@gcc.gnu.org> wrote:
> 2012/12/10 David Edelsohn <dje.gcc@gmail.com>:
>> There has been no progress on this bug for over two months.  I have
>> opened PR fortran/55636.  This must be fixed before GCC 4.8 ships.
>
> Thanks for pinging, David. I almost forgot about it ...
>
> Here is a re-diffed version of my previous patch. I'd be grateful for
> comments. In particular: Does it fix all the problems on AIX? (For
> more open questions, see below.)

Janus,

Anything that changes the mangling of the symbols referenced in
fortran/trans-decl.c will fix the problem on AIX.

Thanks, David
David Edelsohn - Dec. 10, 2012, 3:49 p.m.
On Mon, Dec 10, 2012 at 5:05 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Mon, Dec 10, 2012 at 10:56:58AM +0100, Janus Weil wrote:
>> > For C and C++, identifiers beginning with underscore and upper case
>> > letter or with two underscores are reserve to the implementation.
>>
>> See the previous discussion in this thread ...
>
> That's true, but the implementation isn't just GCC, it is also C libraries
> which aren't provided by GCC.  Including a character (if possible) that
> will make it unaccessible from C/C++ is desirable.  And, not changing the
> names of non-TREE_STATIC vars is also desirable, those I'm afraid show up
> in the debug info from time to time, so making them unnecessarily larger
> results in .debug_info size increases.

An earlier suggestion was "_F." .  Maybe gfortran.h should follow the
same logic as gcc/defaults.h and gcc/cp/cp-tree.h:

#ifndef NO_DOT_IN_LABEL
"_F."
#else
#ifndef NO_DOLLAR_IN_LABEL
"_F$"
#else
"_F_"
#endif
#endif

Thanks, David
Jakub Jelinek - Dec. 10, 2012, 3:54 p.m.
On Mon, Dec 10, 2012 at 10:49:57AM -0500, David Edelsohn wrote:
> On Mon, Dec 10, 2012 at 5:05 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> > On Mon, Dec 10, 2012 at 10:56:58AM +0100, Janus Weil wrote:
> >> > For C and C++, identifiers beginning with underscore and upper case
> >> > letter or with two underscores are reserve to the implementation.
> >>
> >> See the previous discussion in this thread ...
> >
> > That's true, but the implementation isn't just GCC, it is also C libraries
> > which aren't provided by GCC.  Including a character (if possible) that
> > will make it unaccessible from C/C++ is desirable.  And, not changing the
> > names of non-TREE_STATIC vars is also desirable, those I'm afraid show up
> > in the debug info from time to time, so making them unnecessarily larger
> > results in .debug_info size increases.
> 
> An earlier suggestion was "_F." .  Maybe gfortran.h should follow the
> same logic as gcc/defaults.h and gcc/cp/cp-tree.h:
> 
> #ifndef NO_DOT_IN_LABEL
> "_F."
> #else
> #ifndef NO_DOLLAR_IN_LABEL
> "_F$"
> #else
> "_F_"
> #endif
> #endif

Sure, we my
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55636
comment.

	Jakub
David Edelsohn - Dec. 10, 2012, 4:27 p.m.
On Mon, Dec 10, 2012 at 10:54 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Mon, Dec 10, 2012 at 10:49:57AM -0500, David Edelsohn wrote:
>> On Mon, Dec 10, 2012 at 5:05 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>> > On Mon, Dec 10, 2012 at 10:56:58AM +0100, Janus Weil wrote:
>> >> > For C and C++, identifiers beginning with underscore and upper case
>> >> > letter or with two underscores are reserve to the implementation.
>> >>
>> >> See the previous discussion in this thread ...
>> >
>> > That's true, but the implementation isn't just GCC, it is also C libraries
>> > which aren't provided by GCC.  Including a character (if possible) that
>> > will make it unaccessible from C/C++ is desirable.  And, not changing the
>> > names of non-TREE_STATIC vars is also desirable, those I'm afraid show up
>> > in the debug info from time to time, so making them unnecessarily larger
>> > results in .debug_info size increases.
>>
>> An earlier suggestion was "_F." .  Maybe gfortran.h should follow the
>> same logic as gcc/defaults.h and gcc/cp/cp-tree.h:
>>
>> #ifndef NO_DOT_IN_LABEL
>> "_F."
>> #else
>> #ifndef NO_DOLLAR_IN_LABEL
>> "_F$"
>> #else
>> "_F_"
>> #endif
>> #endif
>
> Sure, we my
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55636
> comment.

Yes, I agree with the intention. The remaining question is if this
concept should be applied to all of the mangling with the new macro in
gfortran.h.

- David
Janus Weil - Dec. 11, 2012, 11:16 a.m.
Ok, so here is a new patch, updated according to the suggestions of
David and Jakub. This now only touches the dotted variables, which are
responsible for the AIX trouble. Whether the same prefixing should
also be applied in other cases, we can still decide later.

> The remaining question is if this
> concept should be applied to all of the mangling with the new macro in
> gfortran.h.

The trouble is that changing the mangling will break ABI
compatibility. But, anyway, since we need to change it in some places,
it might be worth to clean up other places, too?

Cheers,
Janus
Jakub Jelinek - Dec. 11, 2012, 12:04 p.m.
On Tue, Dec 11, 2012 at 12:16:33PM +0100, Janus Weil wrote:
> Ok, so here is a new patch, updated according to the suggestions of
> David and Jakub. This now only touches the dotted variables, which are
> responsible for the AIX trouble. Whether the same prefixing should
> also be applied in other cases, we can still decide later.

Why are you changing anything in create_function_arglist (PARM_DECLs
can't ever be TREE_STATIC, and it is compiler internal (plus debug info)
thing how they are named, no need for any kind of mangling) or
saved_dovar (again, doesn't seem to be TREE_STATIC)?

Even in gfc_create_string_length you don't need to increase the length
of the names and obfuscate them if it isn't going to be TREE_STATIC.

	Jakub
Janus Weil - Dec. 11, 2012, 1:29 p.m.
2012/12/11 Jakub Jelinek <jakub@redhat.com>:
> On Tue, Dec 11, 2012 at 12:16:33PM +0100, Janus Weil wrote:
>> Ok, so here is a new patch, updated according to the suggestions of
>> David and Jakub. This now only touches the dotted variables, which are
>> responsible for the AIX trouble. Whether the same prefixing should
>> also be applied in other cases, we can still decide later.
>
> Why are you changing anything in create_function_arglist (PARM_DECLs
> can't ever be TREE_STATIC, and it is compiler internal (plus debug info)
> thing how they are named, no need for any kind of mangling) or
> saved_dovar (again, doesn't seem to be TREE_STATIC)?
>
> Even in gfc_create_string_length you don't need to increase the length
> of the names and obfuscate them if it isn't going to be TREE_STATIC.

Yes, you're probably right.

Anyway, I'm out. I don't have the capacities to deal with this right
now (and, frankly, it's not my duty anyway) ...

Cheers,
Janus

Patch

2012-10-04  Tobias Burnus  <burnus@net-b.de>

	* trans-decl.c (gfc_create_string_length, create_function_arglist):
	Don't create a symbol which contains a dot.
	* trans-stmt.c (gfc_trans_simple_do, gfc_trans_do): Ditto.

diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 910b150..f41fc8b 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -1097,9 +1097,9 @@  gfc_create_string_length (gfc_symbol * sym)
 
       /* 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),
@@ -1984,7 +1984,7 @@  create_function_arglist (gfc_symbol * sym)
 
 	  length = build_decl (input_location,
 			       PARM_DECL,
-			       get_identifier (".__result"),
+			       get_identifier ("_Flen__result"),
 			       len_type);
 	  if (!sym->ts.u.cl->length)
 	    {
@@ -2007,7 +2007,7 @@  create_function_arglist (gfc_symbol * sym)
 		{
 		  tree len = build_decl (input_location,
 					 VAR_DECL,
-					 get_identifier ("..__result"),
+					 get_identifier ("_Flen2__result"),
 					 gfc_charlen_type_node);
 		  DECL_ARTIFICIAL (len) = 1;
 		  TREE_USED (len) = 1;
diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
index 204f069..37fc6ee 100644
--- a/gcc/fortran/trans-stmt.c
+++ b/gcc/fortran/trans-stmt.c
@@ -1376,7 +1376,7 @@  gfc_trans_simple_do (gfc_code * code, stmtblock_t *pblock, tree dovar,
   /* Save value for do-tinkering checking. */
   if (gfc_option.rtcheck & GFC_RTCHECK_DO)
     {
-      saved_dovar = gfc_create_var (type, ".saved_dovar");
+      saved_dovar = gfc_create_var (type, "_F_saved_dovar");
       gfc_add_modify_loc (loc, pblock, saved_dovar, dovar);
     }
 
@@ -1581,7 +1581,7 @@  gfc_trans_do (gfc_code * code, tree exit_cond)
   /* Save value for do-tinkering checking. */
   if (gfc_option.rtcheck & GFC_RTCHECK_DO)
     {
-      saved_dovar = gfc_create_var (type, ".saved_dovar");
+      saved_dovar = gfc_create_var (type, "_F_saved_dovar");
       gfc_add_modify_loc (loc, &block, saved_dovar, dovar);
     }