Patchwork [wwwdocs] gcc-4.6/changes.html: Minor Fortran update

login
register
mail settings
Submitter Tobias Burnus
Date Jan. 28, 2011, 3:54 p.m.
Message ID <4D42E6B6.6020304@net-b.de>
Download mbox | patch
Permalink /patch/80861/
State New
Headers show

Comments

Tobias Burnus - Jan. 28, 2011, 3:54 p.m.
Small patch to the Fortran section of the 4.6 release notes.
Current version at: http://gcc.gnu.org/gcc-4.6/changes.html#fortran

Do you have comments to the modification? General comments?
Did we miss something newsworthy?

Tobias
Gerald Pfeifer - Jan. 28, 2011, 10:18 p.m.
On Fri, 28 Jan 2011, Tobias Burnus wrote:
> Do you have comments to the modification? General comments?

Only two minor nitpicks from my side:

Index: changes.html
===================================================================
+	allocated (if unallocated) or reallocated (if the shape or type
+	parameter is different). To avoid the small performance penalty,
+	you can use for arrays and character strings <code>a(:) = ...</code>
+	instead of <code>a = ...</code> &ndash; or disable the feature using
+        <code>-std=f95</code> or <code>-fno-realloc-lhs</code>.</li>

I believe in English we better say "for arrays and ... you can use ...
instead of ... "

+	<li>Namelist variables with allocatable and pointer attribute and
+	nonconstant length type parameter are supported</li>

Full stop?

Gerald
Tobias Burnus - Jan. 29, 2011, 9:58 a.m.
Am 28.01.2011 23:18, schrieb Gerald Pfeifer:
> +	allocated (if unallocated) or reallocated (if the shape or type
> +	parameter is different). To avoid the small performance penalty,
> +	you can use for arrays and character strings<code>a(:) = ...</code>
> +	instead of<code>a = ...</code>  &ndash; or disable the feature using
> +<code>-std=f95</code>  or<code>-fno-realloc-lhs</code>.</li>
>
> I believe in English we better say "for arrays and ... you can use ...
> instead of ... "

It is not clear to me whether you suggest:
"To avoid the small performance penalty, for arrays ..."
or
"To avoid the small performance penalty for arrays ..."
I think the first one sounds also a bit awkward while the second one 
changes the meaning.

I mean - and read my version such - that using reallocate on assignment 
has a small performance penalty, but for arrays and character strings 
one can avoid it. In particular, for noncharacter scalar (allocatable) 
variables one can not (except by disabling the feature completely).

If I revert the order (and remove the comma), it sounds to me as if the 
performance penalty only affects arrays and character variables.

Tobias
Gerald Pfeifer - Jan. 29, 2011, 10:05 a.m.
On Sat, 29 Jan 2011, Tobias Burnus wrote:
> Am 28.01.2011 23:18, schrieb Gerald Pfeifer:
>> +	allocated (if unallocated) or reallocated (if the shape or type
>> +	parameter is different). To avoid the small performance penalty,
>> +	you can use for arrays and character strings<code>a(:) = ...</code>
>> +	instead of<code>a = ...</code>  &ndash; or disable the feature using
>> +<code>-std=f95</code>  or<code>-fno-realloc-lhs</code>.</li>
>> 
>> I believe in English we better say "for arrays and ... you can use ...
>> instead of ... "
> It is not clear to me whether you suggest:
> "To avoid the small performance penalty, for arrays ..."
> or
> "To avoid the small performance penalty for arrays ..."
> I think the first one sounds also a bit awkward while the second one changes
> the meaning.
> 
> I mean - and read my version such - that using reallocate on assignment 
> has a small performance penalty, but for arrays and character strings 
> one can avoid it. In particular, for noncharacter scalar (allocatable) 
> variables one can not (except by disabling the feature completely).

Let me try to be more clear.  "You can use for arrays" only works in
English if there is the concept of a "for array", otherwise this looks
like a Germanism.


So that would become

  "To avoid the small performance penalty, for arrays and
  character strings you can use <code>a(:) =...</code> instead
  of <code>a = ...</code>.  You can also disable..."

or

  "To avoid the small performance penalty, you can use
  <code>a(:) =...</code> instead of <code>a = ...</code> for
  arrays and character strings.  You can also disable..."

Or, of course

  "You can use <code>a(:) =...</code> instead of <code>a = ...</code>
  for arrays and characters strings to avoid the small performance
  penalty.  You can also disable..."

Hope this clarifies?

Gerald
Tobias Burnus - Jan. 29, 2011, 10:52 a.m.
Gerald Pfeifer wrote:
>    "To avoid the small performance penalty, you can use
>    <code>a(:) =...</code>  instead of<code>a = ...</code>  for
>    arrays and character strings.  You can also disable..."

I have chosen this version.

Tobias

Patch

Index: changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.6/changes.html,v
retrieving revision 1.97
diff -u -r1.97 changes.html
--- changes.html	27 Jan 2011 21:19:49 -0000	1.97
+++ changes.html	28 Jan 2011 15:49:48 -0000
@@ -377,15 +377,17 @@ 
 	<li>In pointer assignments it is now possible to specify the lower
 	bounds of the pointer and, for a rank-1 or a simply contiguous
 	data-target, to remap the bounds.</li>
-	<li>Automatic (re)allocation for arrays: In intrinsic assignments to
+	<li>Automatic (re)allocation: In intrinsic assignments to
 	allocatable variables the left-hand side will be automatically
-	allocated (if unallocated) or reallocated (if the shape is different).
-	To avoid the small performance penalty, you can use, for instance,
-	for arrays <code>a(:) = ...</code> instead of <code>a = ...</code>
-	&ndash; or disable the feature using <code>-std=f95</code> or
-	<code>-fno-realloc-lhs</code>. Note: GCC does not yet support
-	(re)allocation on assignment for allocatable <em>scalar</em> variables.
-	</li>
+	allocated (if unallocated) or reallocated (if the shape or type
+	parameter is different). To avoid the small performance penalty,
+	you can use for arrays and character strings <code>a(:) = ...</code>
+	instead of <code>a = ...</code> &ndash; or disable the feature using
+        <code>-std=f95</code> or <code>-fno-realloc-lhs</code>.</li>
+	<li>Deferred type parameter: For scalar allocatable and pointer
+	variables the character length can be deferred.</li>
+	<li>Namelist variables with allocatable and pointer attribute and
+	nonconstant length type parameter are supported</li>
       </ul>
     </li>
     <li>Fortran 2008 support has been extended: