[Patch,wwwdocs] 4.5 changes: MPC and Fortran

[Craig Powers]

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.