| Message ID | AANLkTimqd4i=bQdJj6veS72U-vZFftbLP2VRzPpt36v6@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
Janne,
> Tested with make pdf, Ok for trunk?
OK - many thanks for the contribution. On your monologue:
"I don't this is anything worth bragging about in the release notes,
but perhaps some note could be put into the documentation?"
mmmm! I am not so sure?
Paul
On Sun, Feb 6, 2011 at 12:02, Paul Richard Thomas <paul.richard.thomas@gmail.com> wrote: > Janne, > > >> Tested with make pdf, Ok for trunk? > > OK - many thanks for the contribution. Thanks, Sending fortran/ChangeLog Sending fortran/gfortran.texi Sending fortran/intrinsic.texi Transmitting file data ... Committed revision 169864.
Hello Janne, a few nits, if I may: * Janne Blomqvist wrote on Sat, Feb 05, 2011 at 10:44:48PM CET: > --- a/gcc/fortran/gfortran.texi > +++ b/gcc/fortran/gfortran.texi > @@ -1157,6 +1157,36 @@ representation of @code{LOGICAL} variables in GNU Fortran is identical > to C99 _Bool, except for a possible difference in storage size > depending on the kind. > > + > +@node Thread-safety of the runtime library > +@section Thread-safety of the runtime library > +@cindex thread-safety, threads > + > +GNU Fortran can be used in programs with multiple threads, e.g. by e.g.@: by > +using OpenMP, by calling OS thread handling functions via the > +@code{ISO_C_BINDING} facility, or by GNU Fortran compiled library code > +being called from a multi-threaded program. > + > +The GNU Fortran runtime library, (@var{libgfortran}), supports being @code{libgfortran} or @file{libgfortran}, I suppose. @var is for metasyntactic variables. > +called concurrently from multiple threads with the following > +exceptions. > + > +During library initialization, the C @code{getenv()} function is used, The GCS recommends to use refer to functions without trailing (), but I see that the gfortran manual uses that elsewhere also. Several instances. > +which need not be thread-safe. Similarly, the @code{getenv()} > +function is used to implement the @code{GET_ENVIRONMENT_VARIABLE} and > +@code{GETENV} intrinsics. It is the responsibility of the user to > +ensure that the environment is not being updated concurrently when any > +of these actions are taking place. > + > +The @code{EXECUTE_COMMAND_LINE} and @code{SYSTEM} intrinsics are > +implemented with the @code{system()} function, which need not be > +thread-safe. It is the responsibility of the user to ensure that > +@code{system()} is not called concurrently. > + > +Finally, for platforms not supporting thread-safe @code{POSIX} POSIX without @code. > +functions, further functionality might not be thread-safe. For > +details, please consult the documentation for your operating system. Cheers, Ralf
On Sun, Feb 6, 2011 at 23:45, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote: > Hello Janne, > > a few nits, if I may: > > * Janne Blomqvist wrote on Sat, Feb 05, 2011 at 10:44:48PM CET: >> --- a/gcc/fortran/gfortran.texi >> +++ b/gcc/fortran/gfortran.texi >> @@ -1157,6 +1157,36 @@ representation of @code{LOGICAL} variables in GNU Fortran is identical >> to C99 _Bool, except for a possible difference in storage size >> depending on the kind. >> >> + >> +@node Thread-safety of the runtime library >> +@section Thread-safety of the runtime library >> +@cindex thread-safety, threads >> + >> +GNU Fortran can be used in programs with multiple threads, e.g. by > > e.g.@: by I don't understand what you mean by that. [snip] I fixed the other stuff you suggested, and committed as obvious. Sending fortran/ChangeLog Sending fortran/gfortran.texi Sending fortran/intrinsic.texi Transmitting file data ... Committed revision 169892.
* Janne Blomqvist wrote on Mon, Feb 07, 2011 at 08:03:17PM CET: > On Sun, Feb 6, 2011 at 23:45, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote: > > * Janne Blomqvist wrote on Sat, Feb 05, 2011 at 10:44:48PM CET: > >> --- a/gcc/fortran/gfortran.texi > >> +++ b/gcc/fortran/gfortran.texi > >> @@ -1157,6 +1157,36 @@ representation of @code{LOGICAL} variables in GNU Fortran is identical > >> to C99 _Bool, except for a possible difference in storage size > >> depending on the kind. > >> > >> + > >> +@node Thread-safety of the runtime library > >> +@section Thread-safety of the runtime library > >> +@cindex thread-safety, threads > >> + > >> +GNU Fortran can be used in programs with multiple threads, e.g. by > > > > e.g.@: by > > I don't understand what you mean by that. In the PDF output, TeX adds more spacing after an end-of-sentence period. After an abbreviation however, you don't want that larger space. Writing e.g.@: gets TeX to only add normal spacing. See 'info texinfo "Not Ending a Sentence"'. It's a very minor nit. But since we fixed all instances of 'e.g.' and 'i.e.' for the 4.5 release, it would be nice to not regress. > I fixed the other stuff you suggested, and committed as obvious. Thanks! Ralf
On Mon, Feb 7, 2011 at 21:09, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote: > * Janne Blomqvist wrote on Mon, Feb 07, 2011 at 08:03:17PM CET: >> On Sun, Feb 6, 2011 at 23:45, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote: >> > * Janne Blomqvist wrote on Sat, Feb 05, 2011 at 10:44:48PM CET: >> >> --- a/gcc/fortran/gfortran.texi >> >> +++ b/gcc/fortran/gfortran.texi >> >> @@ -1157,6 +1157,36 @@ representation of @code{LOGICAL} variables in GNU Fortran is identical >> >> to C99 _Bool, except for a possible difference in storage size >> >> depending on the kind. >> >> >> >> + >> >> +@node Thread-safety of the runtime library >> >> +@section Thread-safety of the runtime library >> >> +@cindex thread-safety, threads >> >> + >> >> +GNU Fortran can be used in programs with multiple threads, e.g. by >> > >> > e.g.@: by >> >> I don't understand what you mean by that. > > In the PDF output, TeX adds more spacing after an end-of-sentence > period. After an abbreviation however, you don't want that larger > space. Writing e.g.@: gets TeX to only add normal spacing. > See 'info texinfo "Not Ending a Sentence"'. > > It's a very minor nit. But since we fixed all instances of 'e.g.' > and 'i.e.' for the 4.5 release, it would be nice to not regress. Ok, fixed. I also took the liberty of fixing a few other spurious ()'s, and one bug (errno is a variable, not a function). Committed as obvious Sending fortran/gfortran.texi Sending fortran/intrinsic.texi Transmitting file data .. Committed revision 169893. (I didn't include a ChangeLog entry as IMHO it goes under the previous one).
On 02/07/2011 08:21 PM, Janne Blomqvist wrote: > Ok, fixed. I also took the liberty of fixing a few other spurious > ()'s, and one bug (errno is a variable, not a function). Thanks for cleaning up the documentation. Nitpick 1: errno can also be a macro. (Cf. POSIX or the comment in gfortran.texi.) [No action required.] > Committed revision 169893. Nitpick 2: I would prefer if you could also include the patch in the commit message. I think there is an increasing tendency to avoid attaching/including patches for obvious commits. For me it is much faster to browse through a commit diff in an email than to access the patch via "svn diff". Tobias
On Mon, Feb 7, 2011 at 21:32, Tobias Burnus <burnus@net-b.de> wrote: > On 02/07/2011 08:21 PM, Janne Blomqvist wrote: >> >> Ok, fixed. I also took the liberty of fixing a few other spurious >> ()'s, and one bug (errno is a variable, not a function). > > Thanks for cleaning up the documentation. > > Nitpick 1: errno can also be a macro. (Cf. POSIX or the comment in > gfortran.texi.) [No action required.] Well yes, but certainly it's not a function which the documentation previously stated! But, point taken. Any ideas for a proper, short, and easy to understand wording? As Steve mentions, properly it's a "modifiable lvalue of type int", but that might be somewhat of a mouthful for a Fortran programmer not well versed in C. >> Committed revision 169893. > > Nitpick 2: I would prefer if you could also include the patch in the commit > message. I think there is an increasing tendency to avoid > attaching/including patches for obvious commits. For me it is much faster to > browse through a commit diff in an email than to access the patch via "svn > diff". Ok, I'll try to remember that. FWIW, I'm using git for my gcc development, where diff's between arbitrary revisions is blazing fast (compared to svn, at least) and usually quite simple, so I personally don't see it as a big issue to have to check my own tree. But, not everybody is on the git bandwagon (yet?)..
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi index a34d82e..54f2457 100644 --- a/gcc/fortran/gfortran.texi +++ b/gcc/fortran/gfortran.texi @@ -1157,6 +1157,36 @@ representation of @code{LOGICAL} variables in GNU Fortran is identical to C99 _Bool, except for a possible difference in storage size depending on the kind. + +@node Thread-safety of the runtime library +@section Thread-safety of the runtime library +@cindex thread-safety, threads + +GNU Fortran can be used in programs with multiple threads, e.g. by +using OpenMP, by calling OS thread handling functions via the +@code{ISO_C_BINDING} facility, or by GNU Fortran compiled library code +being called from a multi-threaded program. + +The GNU Fortran runtime library, (@var{libgfortran}), supports being +called concurrently from multiple threads with the following +exceptions. + +During library initialization, the C @code{getenv()} function is used, +which need not be thread-safe. Similarly, the @code{getenv()} +function is used to implement the @code{GET_ENVIRONMENT_VARIABLE} and +@code{GETENV} intrinsics. It is the responsibility of the user to +ensure that the environment is not being updated concurrently when any +of these actions are taking place. + +The @code{EXECUTE_COMMAND_LINE} and @code{SYSTEM} intrinsics are +implemented with the @code{system()} function, which need not be +thread-safe. It is the responsibility of the user to ensure that +@code{system()} is not called concurrently. + +Finally, for platforms not supporting thread-safe @code{POSIX} +functions, further functionality might not be thread-safe. For +details, please consult the documentation for your operating system. + @c --------------------------------------------------------------------- @c Extensions @c --------------------------------------------------------------------- diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi index f0287f6..ea5528f 100644 --- a/gcc/fortran/intrinsic.texi +++ b/gcc/fortran/intrinsic.texi @@ -4162,6 +4162,9 @@ the command, as returned by @code{system}. @code{CMDSTAT} is set to zero if the command line was executed (whatever its exit status was). @code{CMDMSG} is assigned an error message if an error has occurred. +Note that the @code{system()} call need not be thread-safe. It is the +responsibility of the user to ensure that @code{system()} is not +called concurrently. @item @emph{Standard}: Fortran 2008 and later @@ -5452,11 +5455,15 @@ END PROGRAM @item @emph{Description}: Get the @var{VALUE} of the environmental variable @var{NAME}. -This intrinsic routine is provided for backwards compatibility with -GNU Fortran 77. In new code, programmers should consider the use of +This intrinsic routine is provided for backwards compatibility with +GNU Fortran 77. In new code, programmers should consider the use of the @ref{GET_ENVIRONMENT_VARIABLE} intrinsic defined by the Fortran 2003 standard. +Note that @code{GETENV} need not be thread-safe. It is the +responsibility of the user to ensure that the environment is not being +updated concurrently with a call to the @code{GETENV} intrinsic. + @item @emph{Standard}: GNU extension @@ -5501,6 +5508,11 @@ END PROGRAM @item @emph{Description}: Get the @var{VALUE} of the environmental variable @var{NAME}. +Note that @code{GET_ENVIRONMENT_VARIABLE} need not be thread-safe. It +is the responsibility of the user to ensure that the environment is +not being updated concurrently with a call to the +@code{GET_ENVIRONMENT_VARIABLE} intrinsic. + @item @emph{Standard}: Fortran 2003 and later @@ -11779,6 +11791,10 @@ and environment-dependent. This intrinsic is provided in both subroutine and function forms; however, only one form can be used in any given program unit. +Note that the @code{system()} call need not be thread-safe. It is the +responsibility of the user to ensure that @code{system()} is not +called concurrently. + @item @emph{Standard}: GNU extension