Dear All, As promised, please find attached the version of this patch for 5-branch. The changes are small enough that I couldn't immediately see any changes required in the text of the ChangeLog. I will look more carefully tomorrow, add the "backported from trunk"s and the current date. I intend to commit on Sunday evening, unless there is any objection. Bootstrapped and regtested in 5-branch on FC21/x86_64 Cheers Paul On 18 December 2015 at 19:12, Paul Richard Thomas wrote: > Dear All, > > In running through the PRs assigned to me, I realised that I have not > closed these PRs because I had promised to see if the patch would > apply to 4.9 and 5 branch. > > I have just applied the patch to 5 branch and have found that, apart > from two minor tweaks in trans.c, all was well. It bootstrapped > and regtested fine, apart from deferred_character_2.f90. In this > latter, deferred length SOURCE and MOLD do not work because the > requisite patches in gfc_trans_allocate were not backported. In > addition, I had to add explicit array specifications to the allocate > statements. > > Should I get deferred length SOURCE and MOLD to work or apply the > attached patch as it stands? Alternatively, I could forget about 4.9 > and 5 branches and close the PRs. > > I have added the ChangeLogs below. > > Cheers > > Paul > > 2015-12-18 Paul Thomas > > PR fortran/50221 > PR fortran/68216 > PR fortran/63932 > PR fortran/66408 > * trans_array.c (gfc_conv_scalarized_array_ref): Pass the > symbol decl for deferred character length array references. > * trans-stmt.c (gfc_trans_allocate): Keep the string lengths > to update deferred length character string lengths. > * trans-types.c (gfc_get_dtype_rank_type); Use the string > length of deferred character types for the dtype size. > * trans.c (gfc_build_array_ref): For references to deferred > character arrays, use the domain max value, if it is a variable > to set the 'span' and use pointer arithmetic for acces to the > element. > (trans_code): Set gfc_current_locus for diagnostic purposes. > > PR fortran/67674 > * trans-expr.c (gfc_conv_procedure_call): Do not fix deferred > string lengths of components. > > PR fortran/49954 > * resolve.c (deferred_op_assign): New function. > (gfc_resolve_code): Call it. > * trans-array.c (concat_str_length): New function. > (gfc_alloc_allocatable_for_assignment): Jump directly to alloc/ > realloc blocks for deferred character length arrays because the > string length might change, even if the shape is the same. Call > concat_str_length to obtain the string length for concatenation > since it is needed to compute the lhs string length. > Set the descriptor dtype appropriately for the new string > length. > * trans-expr.c (gfc_trans_assignment_1): Use the rse string > length for all characters, other than deferred types. For > concatenation operators, push the rse.pre block to the inner > most loop so that the temporary pointer and the assignments > are properly placed. > > 2015-12-18 Paul Thomas > > PR fortran/50221 > * gfortran.dg/deferred_character_1.f90: New test. > * gfortran.dg/deferred_character_4.f90: New test for comment > #4 of the PR. > > PR fortran/68216 > * gfortran.dg/deferred_character_2.f90: New test. > > PR fortran/67674 > * gfortran.dg/deferred_character_3.f90: New test. > > PR fortran/63932 > * gfortran.dg/deferred_character_5.f90: New test. > > PR fortran/66408 > * gfortran.dg/deferred_character_6.f90: New test. > > PR fortran/49954 > * gfortran.dg/deferred_character_7.f90: New test. > > On 15 November 2015 at 15:13, Paul Richard Thomas > wrote: >> Dear Steve, >> >> Thanks for the review. >> >> Committed as revision 230396. >> >> My diagnosis of the last problem that Dominique found is correct. >> However, I have not succeeded in fixing it and so the patch was >> committed as review. I'll just have to return to the problem this >> evening. >> >> Cheers >> >> Paul >> >> On 14 November 2015 at 21:10, Steve Kargl >> wrote: >>> On Sat, Nov 14, 2015 at 07:25:29PM +0100, Paul Richard Thomas wrote: >>>> >>>> Following an email from Dominique to me, I think not. In the course of >>>> fixing PR49954, I put right the setting of the descriptor dtype. Since >>>> this gets passed to the IO runtime, I think that this is the reason >>>> for the difference in behaviour. >>>> >>>> I think that another week of effort should put right gfortran's woes >>>> with deferred characters. As well as concatenation problems that I >>>> think I have fixed, parentheses cause instant death :-( >>>> >>> >>> Hi Paul, >>> >>> I built and tested on both x86_64-*-freebsd and i386-*-freebsd. >>> All tests passed. >>> >>> I read through the patch did not raise any red (or what >>> the heck is he doing here) flags. >>> >>> OK to commit as this is a step in the right direction in >>> dealing with deferred character issues. >>> >>> -- >>> Steve >> >> >> >> -- >> Outside of a dog, a book is a man's best friend. Inside of a dog it's >> too dark to read. >> >> Groucho Marx > > > > -- > Outside of a dog, a book is a man's best friend. Inside of a dog it's > too dark to read. > > Groucho Marx -- The difference between genius and stupidity is; genius has its limits. Albert Einstein