[Bug fortran/67779] Strange ordering with strings in extended object

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

--- Comment #24 from Paul Thomas  ---
Author: pault
Date: Sun Jan 10 12:56:28 2016
New Revision: 232200

URL: https://gcc.gnu.org/viewcvs?rev=232200=gcc=rev
Log:
2016-01-10  Paul Thomas  

PR fortran/67779
* trans_array.c (gfc_conv_scalarized_array_ref): Add missing
se->use_offset from condition for calculation of 'base'.

2016-01-10  Paul Thomas  

PR fortran/67779
* gfortran.dg/actual_array_offset_1: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/actual_array_offset_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/67779] Strange ordering with strings in extended object

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #25 from Paul Thomas  ---
I found a completely trivial fix :-)

Fixed on trunk - thanks for the report.

Paul

[Bug fortran/67779] Strange ordering with strings in extended object

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

--- Comment #26 from Paul Thomas  ---
Author: pault
Date: Sun Jan 10 18:06:43 2016
New Revision: 232203

URL: https://gcc.gnu.org/viewcvs?rev=232203=gcc=rev
Log:
2016-01-10  Paul Thomas  

Backport from mainline.
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.

Backport from mainline.
PR fortran/67674
* trans-expr.c (gfc_conv_procedure_call): Do not fix deferred
string lengths of components.

Backport from mainline.
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): Fix 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.

Backport from mainline.
PR fortran/67779
* trans_array.c (gfc_conv_scalarized_array_ref): Add missing
se->use_offset from condition for calculation of 'base'.

2015-01-10  Paul Thomas  

Backport from mainline.
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.

Backport from mainline.
PR fortran/68216
* gfortran.dg/deferred_character_2.f90: New test.

Backport from mainline.
PR fortran/67674
* gfortran.dg/deferred_character_3.f90: New test.

Backport from mainline.
PR fortran/63932
* gfortran.dg/deferred_character_5.f90: New test.

Backport from mainline.
PR fortran/66408
* gfortran.dg/deferred_character_6.f90: New test.

Backport from mainline.
PR fortran/49954
* gfortran.dg/deferred_character_7.f90: New test.

Backport from mainline.
PR fortran/67779
* gfortran.dg/actual_array_offset_1: New test.

Added:
branches/gcc-5-branch/gcc/fortran/ChangeLog-2015
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/actual_array_offset_1.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_1.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_2.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_3.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_4.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_5.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_6.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_7.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/resolve.c
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/fortran/trans-expr.c
branches/gcc-5-branch/gcc/fortran/trans-stmt.c
branches/gcc-5-branch/gcc/fortran/trans-types.c
branches/gcc-5-branch/gcc/fortran/trans.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/67779] Strange ordering with strings in extended object

[vehre at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
Bug 67779 depends on bug 69011, which changed state.

Bug 69011 Summary: [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE 
with SOURCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69011

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/67779] Strange ordering with strings in extended object

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

--- Comment #23 from Thomas Koenig  ---
(In reply to Paul Thomas from comment #21)

> the right patch this time

Works well, looks obvious.

Pre-approved if you don't think it is, in fact, obvious :-)

[Bug fortran/67779] Strange ordering with strings in extended object

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

--- Comment #19 from Paul Thomas  ---
Created attachment 37198
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37198=edit
Patch to fix the problem

The attached fixes all versions of the problem and regtests OK on FC21/x86_64.

I would prefer to have cured the problem in gfc_conv_expr_descriptor but the
logic associated with setting the offset has become so convoluted that I kept
breaking things. I guess that it would be neater to have a specific gfc_se flag
and to put the patch in gfc_conv_expr_descriptor?

I'll come back to this in the next day or so the latter being more likely
:-)

Paul

[Bug fortran/67779] Strange ordering with strings in extended object

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

Paul Thomas  changed:

   What|Removed |Added

  Attachment #37198|0   |1
is obsolete||

--- Comment #21 from Paul Thomas  ---
Created attachment 37201
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37201=edit
the right patch this time

duuuh!

Thanks

[Bug fortran/67779] Strange ordering with strings in extended object

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

--- Comment #20 from Dominique d'Humieres  ---
> Created attachment 37198 [details]
> Patch to fix the problem
>
> The attached fixes all versions of the problem and regtests OK on FC21/x86_64.

Are you sure you attached the right patch to the right PR?

[Bug fortran/67779] Strange ordering with strings in extended object

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

--- Comment #22 from Dominique d'Humieres  ---
> Created attachment 37201 [details]
> the right patch this time

Works as expected without regression!

[Bug fortran/67779] Strange ordering with strings in extended object

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #15 from Paul Thomas  ---
Created attachment 37185
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37185=edit
A provisional patch for the PR

This patch has two objectives:

(i) To fix the ICE in trans.c. This is fixed by the change to trans-stmt.c.
Note that I have not checked to see if this has been cured - my tree is
somewhat out of date. In anycase, expr3 should never be coming back as a
NOP_EXPR; and

(ii) Fix the original problem in sorting. As noted previously, this is
associated with the array offset being zero, rather than -1. Setting
parmse.use_offset = 0; rather than one does the job.

Rather alarmingly, in my opinion, the patch regtests OK. This begs the question
as to why parmse.use_offset was set in the first place. In the absence of any
explanation, it might be judicious to only set it for full arrays; ie. not to
set it for array sections, as is the case here.

s/write( string_array(i)%value, '(a,i0)' ) "String = ", 11 - i
 /write( string_array(i)%value, '(a,i2)' ) "String = ", 11 - i /

Allows the original testcase not only to run but to sort string_array
correctly. Is this indicative of a bug in LLT?

I'll take the PR.

Paul

[Bug fortran/67779] Strange ordering with strings in extended object

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

--- Comment #14 from Thomas Koenig  ---
The error occurs for class arrays only.

Changing

class(myclass), dimension(:) :: array

to

type(mysortable), dimension(:) :: array

in the more simplified test case results in correct
behavior.

[Bug fortran/67779] Strange ordering with strings in extended object

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

--- Comment #17 from Dominique d'Humieres  ---
> Now sorting the right-hand part of the array fails:

Confirmed, starting with

   2   9   8   7   6   5   
   4   3  10   1

I get

   1   2   3   4   5   6   
   7   8  10   9

[Bug fortran/67779] Strange ordering with strings in extended object

[paul.richard.thomas at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

--- Comment #18 from paul.richard.thomas at gmail dot com  ---
It works for me - a mystery for tomorrow :-)

Paul

On 29 December 2015 at 23:10, dominiq at lps dot ens.fr
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
>
> --- Comment #17 from Dominique d'Humieres  ---
>> Now sorting the right-hand part of the array fails:
>
> Confirmed, starting with
>
>2   9   8   7   6   5
>4   3  10   1
>
> I get
>
>1   2   3   4   5   6
>7   8  10   9
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

[Bug fortran/67779] Strange ordering with strings in extended object

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

--- Comment #16 from Thomas Koenig  ---
Created attachment 37190
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37190=edit
Test case that still fails

Hi Paul,

> (i) To fix the ICE in trans.c. This is fixed by the change to trans-stmt.c.
> Note that I have not checked to see if this has been cured - my tree is
> somewhat out of date. In anycase, expr3 should never be coming back as a
> NOP_EXPR; and

Andre already fixed this one (PR 69011).

> (ii) Fix the original problem in sorting. As noted previously, this is
> associated with the array offset being zero, rather than -1. Setting
> parmse.use_offset = 0; rather than one does the job.

I tried out this part of your patch (with Andre's fix) and got yet
another failure on a modification of the original test case.

Now sorting the right-hand part of the array fails:

 Sorting ...
 Array on entry
0.997559547 0.566824675 0.965915322 0.747927666 0.367390871 0.480636895
0.737542510E-01 0.535517931E-02 0.347081244 0.342243791  
 Array after shuffling
0.342243791 0.347081244 0.535517931E-02 0.737542510E-01 0.367390871 0.480636895
0.747927666 0.965915322 0.566824675 0.997559547  
Left part, pivot=0.367390871  
 Array on entry
0.342243791 0.347081244 0.535517931E-02 0.737542510E-01  
 Array after shuffling
0.342243791 0.737542510E-01 0.535517931E-02 0.347081244  
Left part, pivot=0.347081244  
 Array on entry
0.342243791 0.737542510E-01 0.535517931E-02  
 Array after shuffling
0.535517931E-02 0.737542510E-01 0.342243791  
Right part, pivot=0.367390871  
 Array on entry
0.535517931E-02 0.737542510E-01 0.342243791 0.347081244 0.367390871  
 Array after shuffling
0.535517931E-02 0.737542510E-01 0.342243791 0.347081244 0.367390871  
Left part, pivot=0.342243791  
 Array on entry
0.480636895 0.747927666  
 Array after shuffling
0.480636895 0.747927666  
Right part, pivot=0.342243791  
 Array on entry
0.480636895 0.747927666  
 Array after shuffling
0.480636895 0.747927666  
 Result:
0.535517931E-02 0.737542510E-01 0.342243791 0.347081244 0.367390871 0.480636895
0.747927666 0.965915322 0.566824675 0.997559547

[Bug fortran/67779] Strange ordering with strings in extended object

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

--- Comment #13 from Paul Thomas  ---
(In reply to Thomas Koenig from comment #11)
> Created attachment 37182 [details]
> More simplified test case
> 
> This illustrates the problem - the array is passed wrong on
> the first call to the subroutine.
> 
> Output:
> 
>  array on input
> 5 1 4 3 2  
>  array on input
> 1 4 3 2  
>  array on input
> 1 4 3  
>  array on input
> 1 4  
>  array on input
> 1

The call to quicksort from the main program generates:
class.15._vptr = (struct __vtype_myclass_def_Myclass * {ref-all})
&__vtab_myclass_def_Mysortable;
parm.16.dtype = 297;
parm.16.dim[0].lbound = 1;
parm.16.dim[0].ubound = 5;
parm.16.dim[0].stride = 1;
parm.16.data = (void *) [0];
parm.16.offset = -1;
class.15._data = parm.16;
quicksort ();

whereas the recursive call to self is:
  parm.11.dim[0].lbound = 1;
  parm.11.dim[0].ubound = D.3501;
  parm.11.dim[0].stride = NON_LVALUE_EXPR ;
  parm.11.data = NON_LVALUE_EXPR _data.data>;
  parm.11.offset = 0;
  class.12._data = VIEW_CONVERT_EXPR(parm.11);
  class.12._vptr = array->_vptr;
  quicksort ();

It is the offset being set to zero, rather than -1, that does the damage.

Paul

[Bug fortran/67779] Strange ordering with strings in extended object

[vehre at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

--- Comment #12 from vehre at gcc dot gnu.org ---
That rings a bell. I feel like already have done some work on a similar issue.
I will take a look, when I have some time left.

[Bug fortran/67779] Strange ordering with strings in extended object

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

--- Comment #11 from Thomas Koenig  ---
Created attachment 37182
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37182=edit
More simplified test case

This illustrates the problem - the array is passed wrong on
the first call to the subroutine.

Output:

 array on input
5 1 4 3 2  
 array on input
1 4 3 2  
 array on input
1 4 3  
 array on input
1 4  
 array on input
1

[Bug fortran/67779] Strange ordering with strings in extended object

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #10 from Thomas Koenig  ---
Created attachment 37181
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37181=edit
simplified, instrumented test case

The problem happens in passing the array bounds.

The somewhat simplified (integer only) and instrumented test case shows the
following output:

 Sorting ...
 array on input
5 1 4 3 2  
 array after pretreatment
2 1 3 4 5  
 array recursively passed to quicksort
2 1 3  
 array on input
1 3 4  

 and this is off by one. The array slice passed should be
[ 2 1 3] and ends up as [1 3 4] in the called subroutine.

Well, I'm off to bed.  I'm sure this can be simplified further.



 array after pretreatment
1 3 4  
 array on input
1 3  
 array after pretreatment
1 3

[Bug fortran/67779] Strange ordering with strings in extended object

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

--- Comment #9 from vries at gcc dot gnu.org ---
PR69011 is probably a duplicate.

[Bug fortran/67779] Strange ordering with strings in extended object

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||pault at gcc dot gnu.org,
   ||vehre at gcc dot gnu.org,
   ||vries at gcc dot gnu.org

--- Comment #8 from Dominique d'Humieres  ---
Revision r229621 changes the wrong code to an ICE

[Book15] f90/bug% /opt/gcc/gcc6p-229621p2/bin/gfortran pr67779.f90
pr67779.f90:76:0:

 allocate( v,   source = array(1) )
1
internal compiler error: in gfc_advance_chain, at fortran/trans.c:61

[Bug fortran/67779] Strange ordering with strings in extended object

[arjen.markus895 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

--- Comment #7 from Arjen Markus  ---
Yes, I can confirm this - I also tried with the Intel Fortran compiler and that
sorts the integers and strings in the way one would expect.

[Bug fortran/67779] Strange ordering with strings in extended object

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

--- Comment #6 from Dominique d'Humieres  ---
The problem is not limited to strings. If I add the following lines

array(1)%value = 2
array(9)%value = 10
write( string_array(1)%value, '(a,i0)' ) "String = ", 2
write( string_array(9)%value, '(a,i0)' ) "String = ", 10

the initial values are

   2 'String = 2  '
   9 'String = 9  '
   8 'String = 8  '
   7 'String = 7  '
   6 'String = 6  '
   5 'String = 5  '
   4 'String = 4  '
   3 'String = 3  '
  10 'String = 10 '
   1 'String = 1  '

and the "sorted" ones are

   2
   1
   3
   4
   5
   6
   7
   8
  10
   9
 String = 2  
 String = 1  
 String = 10 
 String = 3  
 String = 4  
 String = 5  
 String = 6  
 String = 7  
 String = 8  
 String = 9

[Bug fortran/67779] Strange ordering with strings in extended object

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

--- Comment #5 from Dominique d'Humieres  ---
Apparently there is a nasty bug somewhere: if I sort

   'String = 2  '
   'String = 9  '
   'String = 8  '
   'String = 7  '
   'String = 6  '
   'String = 5  '
   'String = 4  '
   'String = 3  '
   'String = 10 '
   'String = 1  '

I get

 String = 2  
 String = 1  
 String = 10 
 String = 3  
 String = 4  
 String = 5  
 String = 6  
 String = 7  
 String = 8  
 String = 9

[Bug fortran/67779] Strange ordering with strings in extended object

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

--- Comment #4 from Dominique d'Humieres  ---
I have instrumented the test and found that 'String = 10 ', which at
the first position, is compared only once at the first call to quick sort, but
not for the other invocations of array(1:j). I am unable to understand why.

[Bug fortran/67779] Strange ordering with strings in extended object

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-10-09
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
> Test : changing format '(a,i0)' to e.g. '(a,i2)'

Confirmed. Closing as INVALID?

[Bug fortran/67779] Strange ordering with strings in extended object

[arjen.markus895 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

--- Comment #3 from Arjen Markus  ---
Let me clarify: 
the STRING "String = 10" should come after the STRING "String = 1 ". It is not
a matter of the numbers inside. If you compare these strings with LLT(), you
will see this.

[Bug fortran/67779] Strange ordering with strings in extended object

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779

Gerhard Steinmetz  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #1 from Gerhard Steinmetz  
---
This differs :
   llt('9 ', '10') : F
   llt(' 9', '10') : T

Test : changing format '(a,i0)' to e.g. '(a,i2)'

$ a.out
 Sorting ...
 Result:
   1
   2
   3
   4
   5
   6
   7
   8
   9
  10
 String =  1
 String =  2
 String =  3
 String =  4
 String =  5
 String =  6
 String =  7
 String =  8
 String =  9
 String = 10