Re: Ping: [Patch, fortran] Bug 68241 - [meta-bug] Deferred-length character - PRs50221, 68216, 63932, 66408, 67674 and 49954

[Paul Richard Thomas]

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 

Re: Ping: [Patch, fortran] Bug 68241 - [meta-bug] Deferred-length character - PRs50221, 68216, 63932, 66408, 67674 and 49954

[Paul Richard Thomas]

Hi Steve,

I have run out of time because I am just about to set off to the UK
for Christmas. I only have trunk installed on my laptop, although I
might just load up 5 branch. I'll be back on the 29th and will deal
with this backport then.

Cheers

Paul

On 18 December 2015 at 19:58, Paul Richard Thomas
 wrote:
> Hi Steve,
>
> The patch is almost exactly as you reviewed before. The tweaks to
> trans.c came about because of other patches that prevented this one
> from applying. Please concentrate on the modified testcase and let me
> know if you would like me to make it work as it does in 6 branch. I
> will take a quick look to see how much work is involved.
>
> Thanks
>
> Paul
>
> On 18 December 2015 at 19:39, Steve Kargl
>  wrote:
>> On Fri, Dec 18, 2015 at 07:12:47PM +0100, Paul Richard Thomas wrote:
>>>
>>> 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.
>>>
>>
>> I'll review this tonight or tomorrow morning.
>>
>> As to your question, I think that it is time to let 4.9 go.
>> AFAIK, there is going to be only one more release from the 4
>> branch.  Too many PRs, too few hands to fix them.  Hopefully,
>> major OS's will move to 5.x as the recommended gcc distro.
>>
>> I think backports to the 5 branch should be done at the
>> disgression of the committer.  If you have cycles to burn,
>> backporting is up to you.  One problem with this viewpoint
>> is, of course, code divergence between 5-branch and trunk
>> makes backporting more difficult.
>>
>> --
>> 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

Re: Ping: [Patch, fortran] Bug 68241 - [meta-bug] Deferred-length character - PRs50221, 68216, 63932, 66408, 67674 and 49954

[Paul Richard Thomas]

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
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c   (revision 230837)
--- gcc/fortran/resolve.c   (working copy)
*** generate_component_assignments (gfc_code
*** 9992,9997 

Re: Ping: [Patch, fortran] Bug 68241 - [meta-bug] Deferred-length character - PRs50221, 68216, 63932, 66408, 67674 and 49954

[Steve Kargl]

On Fri, Dec 18, 2015 at 07:12:47PM +0100, Paul Richard Thomas wrote:
> 
> 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.
> 

I'll review this tonight or tomorrow morning.

As to your question, I think that it is time to let 4.9 go.
AFAIK, there is going to be only one more release from the 4
branch.  Too many PRs, too few hands to fix them.  Hopefully,
major OS's will move to 5.x as the recommended gcc distro.

I think backports to the 5 branch should be done at the
disgression of the committer.  If you have cycles to burn,
backporting is up to you.  One problem with this viewpoint
is, of course, code divergence between 5-branch and trunk
makes backporting more difficult.

-- 
steve

Re: Ping: [Patch, fortran] Bug 68241 - [meta-bug] Deferred-length character - PRs50221, 68216, 63932, 66408, 67674 and 49954

[Paul Richard Thomas]

Hi Steve,

The patch is almost exactly as you reviewed before. The tweaks to
trans.c came about because of other patches that prevented this one
from applying. Please concentrate on the modified testcase and let me
know if you would like me to make it work as it does in 6 branch. I
will take a quick look to see how much work is involved.

Thanks

Paul

On 18 December 2015 at 19:39, Steve Kargl
 wrote:
> On Fri, Dec 18, 2015 at 07:12:47PM +0100, Paul Richard Thomas wrote:
>>
>> 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.
>>
>
> I'll review this tonight or tomorrow morning.
>
> As to your question, I think that it is time to let 4.9 go.
> AFAIK, there is going to be only one more release from the 4
> branch.  Too many PRs, too few hands to fix them.  Hopefully,
> major OS's will move to 5.x as the recommended gcc distro.
>
> I think backports to the 5 branch should be done at the
> disgression of the committer.  If you have cycles to burn,
> backporting is up to you.  One problem with this viewpoint
> is, of course, code divergence between 5-branch and trunk
> makes backporting more difficult.
>
> --
> 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

Re: Ping: [Patch, fortran] Bug 68241 - [meta-bug] Deferred-length character - PRs50221, 68216, 63932, 66408, 67674 and 49954

[Paul Richard Thomas]

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

Re: Ping: [Patch, fortran] Bug 68241 - [meta-bug] Deferred-length character - PRs50221, 68216, 63932, 66408, 67674 and 49954

[Paul Richard Thomas]

Hi Steve,

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 :-(

Cheers

Paul


On 14 November 2015 at 18:49, Steve Kargl
 wrote:
> On Sat, Nov 14, 2015 at 06:39:28PM +0100, Paul Richard Thomas wrote:
>>
>> I am completely unable to reproduce the problems that Dominique is
>> reporting for deferred_character_4.f90. This might be because the
>> patch has moved on to fix PR49554 :-)
>>
>> Concatenation expressions assigned to deferred length character arrays
>> need careful handling to ensure that the temporary creation for the
>> concatenation operator occurs at the right place, that the descriptor
>> dtype is updated and an array temporary is created if there is any
>> dependency between lhs and rhs. This latter has been implemented in
>> resolve.c.
>>
>> Testcases 4-6 have been added to reflect the additional fixes afforded
>> by the original patch, as reported by Dominique (thanks!).
>>
>> As soon as this patch has been committed, I will prepare a version for
>> 4.9 and 5 branches
>>
>> Bootstrapped and regtested on FC21/x86_64 - OK for trunk?
>>
>
> Hi Paul,
>
> I was going to cast an eye over your diff today.  I'll
> build and run some tests on FreeBSD.  Dominiq uses
> MacOS.  So, perhaps, some latent memory corruption
> issue.
>
> --
> 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

Re: Ping: [Patch, fortran] Bug 68241 - [meta-bug] Deferred-length character - PRs50221, 68216, 63932, 66408, 67674 and 49954

[Steve Kargl]

On Sat, Nov 14, 2015 at 06:39:28PM +0100, Paul Richard Thomas wrote:
> 
> I am completely unable to reproduce the problems that Dominique is
> reporting for deferred_character_4.f90. This might be because the
> patch has moved on to fix PR49554 :-)
> 
> Concatenation expressions assigned to deferred length character arrays
> need careful handling to ensure that the temporary creation for the
> concatenation operator occurs at the right place, that the descriptor
> dtype is updated and an array temporary is created if there is any
> dependency between lhs and rhs. This latter has been implemented in
> resolve.c.
> 
> Testcases 4-6 have been added to reflect the additional fixes afforded
> by the original patch, as reported by Dominique (thanks!).
> 
> As soon as this patch has been committed, I will prepare a version for
> 4.9 and 5 branches
> 
> Bootstrapped and regtested on FC21/x86_64 - OK for trunk?
> 

Hi Paul,

I was going to cast an eye over your diff today.  I'll
build and run some tests on FreeBSD.  Dominiq uses 
MacOS.  So, perhaps, some latent memory corruption 
issue. 

-- 
steve

Ping: [Patch, fortran] Bug 68241 - [meta-bug] Deferred-length character - PRs50221, 68216, 63932, 66408, 67674 and 49954

[Paul Richard Thomas]

Dear All,

I am completely unable to reproduce the problems that Dominique is
reporting for deferred_character_4.f90. This might be because the
patch has moved on to fix PR49554 :-)

Concatenation expressions assigned to deferred length character arrays
need careful handling to ensure that the temporary creation for the
concatenation operator occurs at the right place, that the descriptor
dtype is updated and an array temporary is created if there is any
dependency between lhs and rhs. This latter has been implemented in
resolve.c.

Testcases 4-6 have been added to reflect the additional fixes afforded
by the original patch, as reported by Dominique (thanks!).

As soon as this patch has been committed, I will prepare a version for
4.9 and 5 branches

Bootstrapped and regtested on FC21/x86_64 - OK for trunk?

Paul

2015-15-08  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-15-08  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.
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c   (revision 229953)
--- gcc/fortran/resolve.c   (working copy)
*** resolve_ptr_fcn_assign (gfc_code **code,
*** 10222,10227 
--- 10222,10271 
  }
  
  
+ /* Deferred character length assignments from an operator expression
+require a temporary because the character length of the lhs can
+change in the course of the assignment.  */
+ 
+ static bool
+ deferred_op_assign (gfc_code **code, gfc_namespace *ns)
+ {
+   gfc_expr *tmp_expr;
+   gfc_code *this_code;
+ 
+   if (!((*code)->expr1->ts.type == BT_CHARACTER
+&& (*code)->expr1->ts.deferred && (*code)->expr1->rank
+&& (*code)->expr2->expr_type == EXPR_OP))
+ return false;
+ 
+   if (!gfc_check_dependency ((*code)->expr1, (*code)->expr2, 1))
+ return false;
+ 
+   tmp_expr = get_temp_from_expr ((*code)->expr1, ns);
+   tmp_expr->where = (*code)->loc;
+ 
+   /* A new charlen is required to ensure that the variable string
+  length is different to that of the original lhs.  */
+   tmp_expr->ts.u.cl = gfc_get_charlen();
+   tmp_expr->symtree->n.sym->ts.u.cl = tmp_expr->ts.u.cl;
+   tmp_expr->ts.u.cl->next = (*code)->expr2->ts.u.cl->next;
+   (*code)->expr2->ts.u.cl->next = tmp_expr->ts.u.cl;
+ 
+   tmp_expr->symtree->n.sym->ts.deferred = 1;
+ 
+   this_code = build_assignment (EXEC_ASSIGN,
+   (*code)->expr1,
+   gfc_copy_expr (tmp_expr),
+   NULL, NULL, (*code)->loc);
+ 
+   (*code)->expr1 = tmp_expr;
+ 
+   this_code->next = (*code)->next;
+   (*code)->next = this_code;
+ 
+   return true;
+ }
+ 
+ 
  /* Given a block of code, recursively resolve everything pointed to by this
 code block.  */
  

Re: Ping: [Patch, fortran] Bug 68241 - [meta-bug] Deferred-length character - PRs50221, 68216, 63932, 66408, 67674 and 49954

[Dominique d'Humières]

Dear Paul,

Update with your latest patch. Using the following patch

--- /opt/gcc/work/gcc/testsuite/gfortran.dg/deferred_character_4.f90
2015-11-14 19:28:59.0 +0100
+++ deferred_character_4_db.f90 2015-11-14 19:43:55.0 +0100
@@ -21,6 +21,16 @@ program chk_alloc_string
 
 strings = [character(len=4) :: "A", "C", "ABCDE", "V", ""]
 
+print *, len(strings), size(strings, 1)
+do i = 1, size(strings, 1)
+  print *, "'",strings(i),"'"
+end do
+print *, "other print"
+print *, (strings(i), i= 1, size(strings, 1))
+print *, "'", strings(1),"' '", strings(2), "' '", strings(3), "' '", 
strings(4), "' '", strings(5), "'"
+print *, "'", strings, "'"
+print '(">",a,"<")', strings
+print '(">",a,"<")', strings(1:5)
 if (len(strings) .ne. 4) call abort
 if (size(strings, 1) .ne. 5) call abort
 if (any (strings .ne. [character(len=4) :: "A", "C", "ABCD", "V", 
""])) call abort

the output is now correct except the one for print '(">",a,"<")', strings(1:5) 
which is now

>A   <
>A   <
>A   <
>A   <
>A   <

It was correct with the previous patch.

Everything else looks good.

IMO the latest issue may be delayed after a commit!-)

Dominique

> Le 14 nov. 2015 à 19:25, Paul Richard Thomas  
> a écrit :
> 
> Hi Steve,
> 
> 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 :-(
> 
> Cheers
> 
> Paul

Re: Ping: [Patch, fortran] Bug 68241 - [meta-bug] Deferred-length character - PRs50221, 68216, 63932, 66408, 67674 and 49954

[Steve Kargl]

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