| Message ID | 506D5D21.7080201@net-b.de |
|---|---|
| State | New |
| Headers | show |
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 > >
>> 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 >> >>
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
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)
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
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
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
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
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.
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
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
>> 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
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
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
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
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
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
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
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
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
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); }
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