| Message ID | 4EEF7A40.9050605@moene.org |
|---|---|
| State | New |
| Headers | show |
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.
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.
*** 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
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>.