[Bug fortran/60322] New: Incorrect bounds on polymorphic dummy array

[Bug fortran/60322] New: Incorrect bounds on polymorphic dummy array

[Thomas.L.Clune at nasa dot gov]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60322

            Bug ID: 60322
           Summary: Incorrect bounds on polymorphic dummy array
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: Thomas.L.Clune at nasa dot gov

Created attachment 32202
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32202&action=edit
Simple complete program should print that the lower bound is 0, but reports
"1".

The attached reproducer shows that the bounds are incorrect for a polymorphic
dummy argument when an array constructor is passed as the actual argument.  If
an actual array variable is passed, the behavior is correct.

This seems simple enough that I was sure there would be a bug report, but the
few that I found that were at least in this direction were not obviously the
same, and this reproducer is much simpler in any event.

Fails on Mac OS X 10.8.5 with 
GNU Fortran (MacPorts gcc47 4.7.3_3) 4.7.3
GNU Fortran (MacPorts gcc48 4.8.2_0+universal) 4.8.2
GNU Fortran (GCC) 4.9.0 20140103 (experimental)

[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60322

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-02-23
                 CC|                            |janus at gcc dot gnu.org
            Summary|Incorrect bounds on         |[OOP] Incorrect bounds on
                   |polymorphic dummy array     |polymorphic dummy array
     Ever confirmed|0                           |1

--- Comment #1 from janus at gcc dot gnu.org ---
Confirmed. Slightly reduced test case (to exclude that the problem is
module-related):


program main
   implicit none

   type Foo
   end type

   call copyFromArray([Foo()])

contains

   subroutine copyFromArray(array)
      class (Foo), intent(in) :: array(:)
      print*,'lbound should be 1: ', lbound(array), ubound(array), size(array)
   end subroutine

end


When changing 'class(foo)' to 'type(foo)', the expected output is obtained.

[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60322

--- Comment #2 from janus at gcc dot gnu.org ---
For both cases (TYPE and CLASS), the temporary that is created (to be passed to
copyFromArray) has an lbound of zero (as shown by -fdump-tree-original):

    atmp.6.dim[0].stride = 1;
    atmp.6.dim[0].lbound = 0;
    atmp.6.dim[0].ubound = 0;

For the TYPE case, additional code (and another temporary) is generated inside
of copyFromArray, which resets the bounds:

            parm.6.dim[0].lbound = 1;
            parm.6.dim[0].ubound = D.2342;

So we just have to make sure that this additional code is also generated for
the CLASS case.

Or, why not directly start with lbound=1 for the original temporary?

[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60322

--- Comment #3 from janus at gcc dot gnu.org ---
Here is a closely-related variant of comment 1:

program main
   implicit none

   type Foo
   end type

   type(foo), dimension(2:2) :: arg

   call copyFromArray(arg)

contains

   subroutine copyFromArray(array)
      class (Foo), intent(in) :: array(:)
      print*,'lbound should be 1: ', lbound(array)
   end subroutine

end


This one also yields '1' for a TYPE argument (as expected), but '2' for a CLASS
argument.

So, we clearly need to add code to reset the bounds inside of 'copyFromArray'
(but having the temporary in comment 1 start from 1 won't hurt either, I guess,
though I'm not sure if there is a way to detect the difference).

[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60322

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |a.vogt at fulguritus dot com

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
*** Bug 60509 has been marked as a duplicate of this bug. ***

[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array

[antony at cosmologist dot info]

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

Antony Lewis <antony at cosmologist dot info> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |antony at cosmologist dot info

--- Comment #5 from Antony Lewis <antony at cosmologist dot info> ---
Here's another example (giving 0 and 1 for lbound)

program test
double precision x,y
 x=3
 y=4

 call W([x,y]) !this gives wrong result (4,4)
 call W([3.d0,4.d0]) !this works (3,4)
contains

     subroutine W(Ar)
     class(*), intent(in) :: Ar(:)

     print *, lbound(ar)
     select type (Ar)
    type is (double precision)
      print *,Ar(1:2) 
     end select

     end subroutine

end program

[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array

[vehre at gmx dot de]

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

Andre Vehreschild <vehre at gmx dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vehre at gmx dot de

--- Comment #6 from Andre Vehreschild <vehre at gmx dot de> ---
When I see this correctly, we have two ways to resolve this issue:

1. Make sure that the temporary array created to be passed to copyFromArr() has
lbound=1, ubound=1, size(1), or

2. Make sure the additional temporary array in copyFromArr() is created and the
bounds are set correctly. 

Which one is the preferred way?

[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |vehre at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |vehre at gcc dot gnu.org

[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array

[vehre at gcc dot gnu.org]

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

--- Comment #7 from vehre at gcc dot gnu.org ---
I just want to report some progress. I have a patch that fixes the issues in
comment #1 and #3. The tree-dump shows, that a class array is handled the same
for a class array as for a "type array" as described in comment #2.

Currently I am in a battle with the code in comment #5. Somehow the routine
taking care about the association of the temporary real array needed for the
type is (double precision) does not get the array descriptors, neither the one
for the original array ar nor the one for the temporary real-array.

[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array

[vehre at gcc dot gnu.org]

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

--- Comment #8 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Thu Apr 23 11:32:00 2015
New Revision: 222361

URL: https://gcc.gnu.org/viewcvs?rev=222361&root=gcc&view=rev
Log:
gcc/testsuite/ChangeLog:

2015-04-23  Andre Vehreschild  <vehre@gmx.de>

    PF fortran/60322
    * gfortran.dg/class_allocate_19.f03: New test.
    * gfortran.dg/class_array_20.f03: New test.
    * gfortran.dg/class_array_21.f03: New test.
    * gfortran.dg/finalize_10.f90: Corrected scan-trees.
    * gfortran.dg/finalize_15.f90: Fixing comparision to model
    initialization correctly.
    * gfortran.dg/finalize_29.f08: New test.


gcc/fortran/ChangeLog:

2015-04-23  Andre Vehreschild  <vehre@gmx.de>

    PR fortran/60322
    * expr.c (gfc_lval_expr_from_sym): Code to select the regular
    or class array added.
    * gfortran.h: Add IS_CLASS_ARRAY macro.
    * trans-array.c (gfc_add_loop_ss_code): Treat class objects
    to be referenced always.
    (build_class_array_ref): Adapt retrieval of array descriptor.
    (build_array_ref): Likewise.
    (gfc_conv_array_ref): Hand the vptr or the descriptor to 
    build_array_ref depending whether the sym is class or not.
    (gfc_trans_array_cobounds):  Select correct gfc_array_spec for
    regular and class arrays.
    (gfc_trans_array_bounds): Likewise.
    (gfc_trans_dummy_array_bias): Likewise. 
    (gfc_get_dataptr_offset): Correcting call of build_array_ref.
    (gfc_conv_expr_descriptor): Set the array's offset to -1 when
    lbound in inner most dim is 1 and symbol non-pointer/assoc.
    * trans-decl.c (gfc_build_qualified_array): Select correct
    gfc_array_spec for regular and class arrays.
    (gfc_build_dummy_array_decl): Likewise.
    (gfc_get_symbol_decl): Get a dummy array for class arrays.
    (gfc_trans_deferred_vars): Tell conv_expr that the descriptor
    is desired.
    * trans-expr.c (gfc_class_vptr_get): Get the class descriptor
    from the correct location for class arrays.
    (gfc_class_len_get): Likewise.
    (gfc_conv_intrinsic_to_class): Add handling of _len component.
    (gfc_conv_class_to_class):  Prevent access to unset array data
    when the array is an optional argument. Add handling of _len
    component.
    (gfc_copy_class_to_class): Check that _def_init is non-NULL
    when used in _vptr->copy()
    (gfc_trans_class_init_assign): Ensure that the rank of
    _def_init is zero.
    (gfc_conv_component_ref): Get the _vptr along with _data refs.
    (gfc_conv_variable): Make sure the temp array descriptor is
    returned for class arrays, too, and that class arrays are
    dereferenced correctly.
    (gfc_conv_procedure_call): For polymorphic type initialization
    the initializer has to be a pointer to _def_init stored in a
    dummy variable, which then needs to be used by value.
    * trans-intrinsic.c (gfc_conv_intrinsic_sizeof): Use the
    temporary array descriptor for class arrays, too.
    (gfc_conv_intrinsic_storage_size): Likewise.
    (gfc_conv_intrinsic_loc): Add ref to _data for BT_CLASS
    expressions.
    * trans-stmt.c (trans_associate_var): Use a temporary array for
    the associate variable of class arrays, too, making the array
    one-based (lbound == 1).
    * trans-types.c (gfc_is_nodesc_array): Use the correct
    array data.
    * trans.c (gfc_build_array_ref): Use the dummy array descriptor
    when present.
    * trans.h: Add class_vptr to gfc_se for storing a class ref's
    vptr.



Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/expr.c
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/fortran/trans-intrinsic.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/fortran/trans-types.c
    trunk/gcc/fortran/trans.c
    trunk/gcc/fortran/trans.h
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/finalize_10.f90
    trunk/gcc/testsuite/gfortran.dg/finalize_15.f90

[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array

[vehre at gcc dot gnu.org]

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

--- Comment #9 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Mon Apr 27 17:41:01 2015
New Revision: 222478

URL: https://gcc.gnu.org/viewcvs?rev=222478&root=gcc&view=rev
Log:
2015-04-27  Andre Vehreschild  <vehre@gmx.de>

        PR fortran/60322
        Add tests forgotten to svn-add.
        * gfortran.dg/class_allocate_19.f03: New test.
        * gfortran.dg/class_array_20.f03: New test.
        * gfortran.dg/class_array_21.f03: New test.
        * gfortran.dg/finalize_29.f08: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/class_allocate_19.f03
    trunk/gcc/testsuite/gfortran.dg/class_array_20.f03
    trunk/gcc/testsuite/gfortran.dg/class_array_21.f03
    trunk/gcc/testsuite/gfortran.dg/finalize_29.f08
Modified:
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #10 from vehre at gcc dot gnu.org ---
No complaints since commit r222478. I therefore close this pr.

[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array

[mikael at gcc dot gnu.org]

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

Bug 65894 Summary: [6 Regression] severe regression in gfortran 6.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |FIXED

[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |neil.n.carlson at gmail dot com

--- Comment #11 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
*** Bug 67562 has been marked as a duplicate of this bug. ***