2012/10/4 Tobias Burnus <bur...@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 <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 > >
