This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch,wwwdocs] 4.5 changes: MPC and Fortran


Tobias Burnus wrote:

I think the list should be reasonably complete, but I am sure the wording can be improved.

Suggestions for the wording?

+    <li>The <a href="http://www.multiprecision.org/";>Multiple Precision
+    Complex Library</a> (MPC) is now used if found at during configure.
+    This allows GCC to evaluate and replace at compile-time calls to
+    complex built-in math functions having constant arguments with their
+    mathematically equivalent results. Some complex functions were
+    supported before; those are used as fall back if MPC is not used.</li>

Gerald already commented on "at during".


The second sentence seems a little tortured. I would change it as follows:

This allows GCC to evaluate calls to complex built-in math functions having constant arguments at compile-time and replace them with their mathematically equivalent results.

+    <li>The new flag <code>-fcheck=</code> had been added with the options
+    <code>bounds</code> and <code>array-temps</code>, which are equivalent
+    to <code>-fbounds-check</code> and
+    <code>-fcheck-array-temporaries</code>, and the new tests
+    <code>do</code> for finding invalid modification of loop iteration
+    variables and <code>recursive</code> for finding recursive calls to
+    subroutines/functions which are not marked as recursive. Using
+    <code>-fcheck=all</code> enables all those run-time checks.</li>

I don't think putting all four sub-options into one sentence works very well. I would change it as follows (I've omitted the code tags for brevity, I don't mean they should be removed):


The new flag -fcheck= has been added with the options bounds, array-temps, do, and recursive. The bounds and array-temps options are equivalent to -fbounds-check and -fcheck-array-temporaries. The do option checks for invalid modification of loop iteration variables, and the recursive option tests for recursive calls to subroutines/functions which are not marked as recursive. Using -fcheck=all enables all these run-time checks.

+    <li>GNU Fortran no longer links agains <code>libgfortranbegin</code>.
+    As before <code>MAIN__</code> (assembler symbol name) is the actual
+    Fortran main program, which is invoked by <code>main</code> function.
+    However, <code>main</code> is now generated and in the same object
+    file as <code>MAIN__</code>. For the time being,
+    <code>libgfortranbegin</code> still exists for backward
+    compatibility. For details see the new <a

s/agains/&t/


Add a comma after "As before".

I would add a "the" after "invoked by". I disagree with Gerald's comment about removing the ", which", I don't think the result would make any sense at all.

+ <li>Fortran 2003 support has been extended:
+ <ul>
+ <li>Procedure-pointer function results and procedure-pointer
+ components with the NOPASS attribute,</li> + <li><code>DEFERRED</code> type-bound procedures, and</li>
+ <li>the ERRMSG= argument of the ALLOCATE and DEALLOCATE statements
+ has been implemented.</li>
+ <li>The <code>INT_FAST{8,16,32,64,128}_T</code> kind type parameters
+ of the intrisic module <code>ISO_C_BINDING</code> are now supported.
+ </ul>
+ </li>

In the third bullet, s/has/have/. (I think Gerald got this as well.)


s/intrisic/intrinsic/

+        <li>The <code>OPEN</code> statement now supports the
+        <code>NEWUNIT=</code> option, which returns a unique file unit,
+        thus preventing inadvertently uses the same unit at different parts
+	of the program.</li>

The whitespace between the '+' and the text on the last quoted line here is a tab character, instead of spaces as you appear to be using elsewhere.


Change the part after the second comma to:
thus preventing inadvertent use of the same unit in different parts...

(it could also be ...inadvertently using the same unit in..., but I think that would be too many participles)

The "thus" isn't essential there.

+        <li>The <code>INT{8,16,32}</code> and <code>REAL{32,64,128}</code>
+        kind type parameters of the <code>ISO_FORTRAN_ENV</code> module are
+        now supported.</li>

For consistency, either the bit from ISO_C_BINDING should be changed to match this, or this should be changed to match that.


In one case, you have,
...of the intrinsic module ISO_C_BINDING are now supported.

In the other, you have
...of the ISO_FORTRAN_ENV module are now supported.

If ISO_FORTRAN_ENV is not intrinsic (I don't remember if it is or not), then maybe it's OK as-is.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]