Comments

Dear All,
Please find attached a further development of the above patch that
responds to the issues that have been raised so far.
Bootstrapped and regtested on ubuntu10.1/i686 - OK for trunk?
Cheers
Paul
2010-11-27 Paul Thomas <pault@gcc.gnu.org>
PR fortran/35810
* trans-array.c (gfc_trans_array_constructor): If the loop->to
is a VAR_DECL, assume this is dynamic. In this case, use the
counter to obtain the value and set loop->to appropriately.
(gfc_conv_ss_descriptor): Always save the offset of a variable
in info.saved_offset.
(gfc_conv_ss_startstride): Do not attempt bound checking of the
lhs of an assignment, if allocatable and f2003 is allowed.
(gfc_conv_loop_setup): If possible, do not use an allocatable
lhs variable for the loopspec.
(gfc_is_reallocatable_lhs): New function.
(get_std_lbound): New function.
(gfc_alloc_allocatable_for_assignment): New function.
* gfortran.h : Add flag_realloc_lhs to the options structure.
* lang.opt : Add option f(no-)realloc-lhs.
* invoke.texi : Document option f(no-)realloc-lhs.
* options.c (gfc_init_options, gfc_post_options,
gfc_handle_option): Incorporate f(no-)realloc-lhs with default
to frealloc_lhs for -std > f95.
* trans-array.h : Add primitive for previous.
* trans-expr.c (gfc_conv_string_length): Return if character
length is a variable and the expression is NULL.
(gfc_conv_procedure_call): If the call is of the kind x = f(...)
and the lhs is allocatable and reallocation on assignment OK,
call gfc_alloc_allocatable_for_assignment. Do not generate the
function call unless direct by reference.
(realloc_lhs_loop_for_fcn_call): New function.
(realloc_lhs_bounds_for_intrinsic_call): New function.
(gfc_trans_arrayfunc_assign): Reallocation assignments need
a loopinfo and for the loop bounds to be set. With intrinsic
functions, free the lhs data and let the library allocate the
data array. Done by the new functions above.
(gfc_trans_assignment_1): If the lhs is allocatable and
reallocation on assignment is allowed, mark the lhs and use
gfc_alloc_allocatable_for_assignment to make the reallocation.
* trans.h : Add is_alloc_lhs bitfield to gfc_ss structure.
2010-11-27 Paul Thomas <pault@gcc.gnu.org
PR fortran/35810
* gfortran.dg/realloc_on_assign_1.f03: New test.
* gfortran.dg/realloc_on_assign_2.f03: New test.
* gfortran.dg/transpose_2.f90: dg-option -fno-realloc-lhs.
* gfortran.dg/unpack_bounds_1.f90: The same.
* gfortran.dg/cshift_bounds_2.f90: The same.
* gfortran.dg/matmul_bounds_2.f90: The same.
* gfortran.dg/matmul_bounds_3.f90: The same.
* gfortran.dg/matmul_bounds_4.f90: The same.
* gfortran.dg/matmul_bounds_5.f90: The same.

Am 27.11.2010 17:49, schrieb Paul Richard Thomas:
> Dear All,>> Please find attached a further development of the above patch that> responds to the issues that have been raised so far.>> Bootstrapped and regtested on ubuntu10.1/i686 - OK for trunk?
Interdiff looks fine; thus: OK for the trunk.
Thanks for the patch!
Tobias
> 2010-11-27 Paul Thomas<pault@gcc.gnu.org>>> PR fortran/35810> * trans-array.c (gfc_trans_array_constructor): If the loop->to> is a VAR_DECL, assume this is dynamic. In this case, use the> counter to obtain the value and set loop->to appropriately.> (gfc_conv_ss_descriptor): Always save the offset of a variable> in info.saved_offset.> (gfc_conv_ss_startstride): Do not attempt bound checking of the> lhs of an assignment, if allocatable and f2003 is allowed.> (gfc_conv_loop_setup): If possible, do not use an allocatable> lhs variable for the loopspec.> (gfc_is_reallocatable_lhs): New function.> (get_std_lbound): New function.> (gfc_alloc_allocatable_for_assignment): New function.> * gfortran.h : Add flag_realloc_lhs to the options structure.> * lang.opt : Add option f(no-)realloc-lhs.> * invoke.texi : Document option f(no-)realloc-lhs.> * options.c (gfc_init_options, gfc_post_options,> gfc_handle_option): Incorporate f(no-)realloc-lhs with default> to frealloc_lhs for -std> f95.> * trans-array.h : Add primitive for previous.> * trans-expr.c (gfc_conv_string_length): Return if character> length is a variable and the expression is NULL.> (gfc_conv_procedure_call): If the call is of the kind x = f(...)> and the lhs is allocatable and reallocation on assignment OK,> call gfc_alloc_allocatable_for_assignment. Do not generate the> function call unless direct by reference.> (realloc_lhs_loop_for_fcn_call): New function.> (realloc_lhs_bounds_for_intrinsic_call): New function.> (gfc_trans_arrayfunc_assign): Reallocation assignments need> a loopinfo and for the loop bounds to be set. With intrinsic> functions, free the lhs data and let the library allocate the> data array. Done by the new functions above.> (gfc_trans_assignment_1): If the lhs is allocatable and> reallocation on assignment is allowed, mark the lhs and use> gfc_alloc_allocatable_for_assignment to make the reallocation.> * trans.h : Add is_alloc_lhs bitfield to gfc_ss structure.>> 2010-11-27 Paul Thomas<pault@gcc.gnu.org>> PR fortran/35810> * gfortran.dg/realloc_on_assign_1.f03: New test.> * gfortran.dg/realloc_on_assign_2.f03: New test.> * gfortran.dg/transpose_2.f90: dg-option -fno-realloc-lhs.> * gfortran.dg/unpack_bounds_1.f90: The same.> * gfortran.dg/cshift_bounds_2.f90: The same.> * gfortran.dg/matmul_bounds_2.f90: The same.> * gfortran.dg/matmul_bounds_3.f90: The same.> * gfortran.dg/matmul_bounds_4.f90: The same.> * gfortran.dg/matmul_bounds_5.f90: The same.

On 11/27/2010 09:06 AM, Tobias Burnus wrote:
> Am 27.11.2010 17:49, schrieb Paul Richard Thomas:>> Dear All,>>>> Please find attached a further development of the above patch that>> responds to the issues that have been raised so far.>>>> Bootstrapped and regtested on ubuntu10.1/i686 - OK for trunk?>> Interdiff looks fine; thus: OK for the trunk.>> Thanks for the patch!>> Tobias
I second this, then we can get onto some regression fixing. ;)
Jerry

Dear Tobias,
Committed as revision 167220.
Many thanks to you and Dominique for all the help that you gave me on
this patch. Without the tests that you provided, it would have been
distinctly flakey, at best.
Cheers
Paul
On Sat, Nov 27, 2010 at 6:06 PM, Tobias Burnus <burnus@net-b.de> wrote:
> Am 27.11.2010 17:49, schrieb Paul Richard Thomas:>>>> Dear All,>>>> Please find attached a further development of the above patch that>> responds to the issues that have been raised so far.>>>> Bootstrapped and regtested on ubuntu10.1/i686 - OK for trunk?>> Interdiff looks fine; thus: OK for the trunk.>> Thanks for the patch!>> Tobias>>> 2010-11-27 Paul Thomas<pault@gcc.gnu.org>>>>> PR fortran/35810>> * trans-array.c (gfc_trans_array_constructor): If the loop->to>> is a VAR_DECL, assume this is dynamic. In this case, use the>> counter to obtain the value and set loop->to appropriately.>> (gfc_conv_ss_descriptor): Always save the offset of a variable>> in info.saved_offset.>> (gfc_conv_ss_startstride): Do not attempt bound checking of the>> lhs of an assignment, if allocatable and f2003 is allowed.>> (gfc_conv_loop_setup): If possible, do not use an allocatable>> lhs variable for the loopspec.>> (gfc_is_reallocatable_lhs): New function.>> (get_std_lbound): New function.>> (gfc_alloc_allocatable_for_assignment): New function.>> * gfortran.h : Add flag_realloc_lhs to the options structure.>> * lang.opt : Add option f(no-)realloc-lhs.>> * invoke.texi : Document option f(no-)realloc-lhs.>> * options.c (gfc_init_options, gfc_post_options,>> gfc_handle_option): Incorporate f(no-)realloc-lhs with default>> to frealloc_lhs for -std> f95.>> * trans-array.h : Add primitive for previous.>> * trans-expr.c (gfc_conv_string_length): Return if character>> length is a variable and the expression is NULL.>> (gfc_conv_procedure_call): If the call is of the kind x = f(...)>> and the lhs is allocatable and reallocation on assignment OK,>> call gfc_alloc_allocatable_for_assignment. Do not generate the>> function call unless direct by reference.>> (realloc_lhs_loop_for_fcn_call): New function.>> (realloc_lhs_bounds_for_intrinsic_call): New function.>> (gfc_trans_arrayfunc_assign): Reallocation assignments need>> a loopinfo and for the loop bounds to be set. With intrinsic>> functions, free the lhs data and let the library allocate the>> data array. Done by the new functions above.>> (gfc_trans_assignment_1): If the lhs is allocatable and>> reallocation on assignment is allowed, mark the lhs and use>> gfc_alloc_allocatable_for_assignment to make the reallocation.>> * trans.h : Add is_alloc_lhs bitfield to gfc_ss structure.>>>> 2010-11-27 Paul Thomas<pault@gcc.gnu.org>>>> PR fortran/35810>> * gfortran.dg/realloc_on_assign_1.f03: New test.>> * gfortran.dg/realloc_on_assign_2.f03: New test.>> * gfortran.dg/transpose_2.f90: dg-option -fno-realloc-lhs.>> * gfortran.dg/unpack_bounds_1.f90: The same.>> * gfortran.dg/cshift_bounds_2.f90: The same.>> * gfortran.dg/matmul_bounds_2.f90: The same.>> * gfortran.dg/matmul_bounds_3.f90: The same.>> * gfortran.dg/matmul_bounds_4.f90: The same.>> * gfortran.dg/matmul_bounds_5.f90: The same.>>

Janus,
Using -fno-realloc-lhs to compile realloc_on_assign_2.f03 is bound to
produce a segfault. That does not trouble me.
On the other hand, the ICE with -frealloc-lhs does. Would you be so
kind as to produce a backtrace leading up to the ICE.
Thanks
Paul
On Mon, Nov 29, 2010 at 10:47 AM, Janus Weil <janus@gcc.gnu.org> wrote:
> Sorry, guys. The problem persists, even after rebuilding from scratch> with a clean tree, r167234. My configure line is:>> $GCC_DIR/trunk/configure --program-suffix=-4.6 --prefix=/usr> --libdir=/usr/lib64 --libexecdir=/usr/lib64> --enable-languages=c,fortran --enable-checking --disable-bootstrap> --disable-multilib --enable-lto>> Anything wrong with that?>> What happens is:>>> gfortran-4.6 -fno-realloc-lhs realloc_on_assign_2.f03>> ./a.out> Segmentation fault>>> gfortran-4.6 -frealloc-lhs realloc_on_assign_2.f03> realloc_on_assign_2.f03: In function ‘test5’:> realloc_on_assign_2.f03:101:0: internal compiler error: in> fold_convert_loc, at fold-const.c:1907>> Cheers,> Janus>>>> 2010/11/29 Paul Richard Thomas <paul.richard.thomas@gmail.com>:>> Dear Janus,>>>> Works for me on x86_64 - cf. Jerry's message.>>>> As Jerry says, do a clean build. I have had the -f(no)-realloc-lhs>> not "take" on several occasions. The option is accepted but it does>> nothing. Something wrong with the build dependencies?>>>> Cheers>>>> Paul>>>> On Sun, Nov 28, 2010 at 8:48 PM, Janus Weil <janus@gcc.gnu.org> wrote:>>> Hi Paul,>>>>>>> Committed as revision 167220.>>>>>> your second test case fails for me on x86_64-unknown-linux-gnu:>>>>>>> gfortran-4.6 realloc_on_assign_2.f03>>> realloc_on_assign_2.f03: In function ‘test5’:>>> realloc_on_assign_2.f03:101:0: internal compiler error: in>>> fold_convert_loc, at fold-const.c:1907>>>>>> Cheers,>>> Janus>>>>>>>>>>> -->> The knack of flying is learning how to throw yourself at the ground and miss.>> --Hitchhikers Guide to the Galaxy>>>