[Patch, fortran] Would this patch - applied to trunk - be OK for the 4.6 branch ?

[Patch, fortran] Would this patch - applied to trunk - be OK for the 4.6 branch ?

[Toon Moene]

[-- Attachment #1: Type: text/plain, Size: 866 bytes --]

The attached patch makes -finit-<type>=<constant> generate default 
initialization for automatic arrays.

It was OK for the trunk - is it also OK for the 4.6 branch ?

Strictly speaking, it doesn't fix a regression, it is a fix for a 
(non-default) debugging option.

2011-12-19  Toon Moene  <toon@moene.org>

         PR fortran/51310
         * resolve.c (build_default_init_expr): Allow non-allocatable,
         non-compile-time-constant-shape arrays to have a default
         initializer.
         * invoke.texi: Delete the restriction on automatic arrays not
	being initialized by -finit-<type>=<constant>.

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news

[-- Attachment #2: init_real.patch --]
[-- Type: text/x-patch, Size: 977 bytes --]

*** resolve.c.orig	2011-12-13 13:23:59.488029519 +0000
--- resolve.c	2011-12-13 13:24:37.098239361 +0000
*************** build_default_init_expr (gfc_symbol *sym
*** 9899,9905 ****
    int i;
  
    /* These symbols should never have a default initialization.  */
!   if ((sym->attr.dimension && !gfc_is_compile_time_shape (sym->as))
        || sym->attr.external
        || sym->attr.dummy
        || sym->attr.pointer
--- 9899,9905 ----
    int i;
  
    /* These symbols should never have a default initialization.  */
!   if (sym->attr.allocatable
        || sym->attr.external
        || sym->attr.dummy
        || sym->attr.pointer
Index: invoke.texi
===================================================================
--- invoke.texi	(revision 182127)
+++ invoke.texi	(working copy)
@@ -1474,8 +1474,6 @@
 value) options.  These options do not initialize
 @itemize @bullet
 @item
-automatic arrays
-@item
 allocatable arrays
 @item
 components of derived type variables

Re: [Patch, fortran] Would this patch - applied to trunk - be OK for the 4.6 branch ?

[Steve Kargl]

On Mon, Dec 19, 2011 at 06:54:08PM +0100, Toon Moene wrote:
> The attached patch makes -finit-<type>=<constant> generate default 
> initialization for automatic arrays.
> 
> It was OK for the trunk - is it also OK for the 4.6 branch ?
> 
> Strictly speaking, it doesn't fix a regression, it is a fix for a 
> (non-default) debugging option.
> 

Speaking for myself, it seems that the general rule
of thumb among the gfortran committers is that it
is up to the discretion of the committer if he/she
wants to backport a non-regression patch.  The 2
measures I use are: 1) is the patch fairly local
(ie., only a few lines in at most a couple of files);
2) what is the likelihood for causing a problem
(ie., a regression of breaking bootstrap).

In your particular case, I think the patch is a
useful debugging aid, and the likelihood of causing
a problem is very low.

-- 
Steve

Re: [Patch, fortran] Would this patch - applied to trunk - be OK for the 4.6 branch ?

[Toon Moene]

On 12/21/2011 10:00 PM, Steve Kargl wrote:

> On Mon, Dec 19, 2011 at 06:54:08PM +0100, Toon Moene wrote:

>> The attached patch makes -finit-<type>=<constant>  generate default
>> initialization for automatic arrays.
>>
>> It was OK for the trunk - is it also OK for the 4.6 branch ?
>>
>> Strictly speaking, it doesn't fix a regression, it is a fix for a
>> (non-default) debugging option.

> Speaking for myself, it seems that the general rule
> of thumb among the gfortran committers is that it
> is up to the discretion of the committer if he/she
> wants to backport a non-regression patch.  The 2
> measures I use are: 1) is the patch fairly local
> (ie., only a few lines in at most a couple of files);
> 2) what is the likelihood for causing a problem
> (ie., a regression of breaking bootstrap).
>
> In your particular case, I think the patch is a
> useful debugging aid, and the likelihood of causing
> a problem is very low.

Yep, I thought so too - however, it has been over 6 years since I 
contributed a code patch, so I wanted to be careful.

It is committed as revision 182634.

Thanks for your comment.

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news