[Bug fortran/67171] New: [6.0 regression] sourced allocation

[Bug fortran/67171] New: [6.0 regression] sourced allocation

[mexas at bristol dot ac.uk]

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

            Bug ID: 67171
           Summary: [6.0 regression] sourced allocation
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mexas at bristol dot ac.uk
                CC: vehre at gcc dot gnu.org
  Target Milestone: ---

program z
implicit none

real, allocatable :: d(:,:), tmp(:,:)
integer :: i, errstat

allocate( d( 100, 2 ), source = 0.0, stat=errstat )

d(:,1) = (/ ( real(i), i=1,100) /)
d(:,2) = (/ ( real(2*i), i=1,100) /)

write (*,*) d( 1, :) 
call move_alloc( from=d, to=tmp )
write (*,*) tmp( 1, :) 
allocate( d( 50, 2 ), source = tmp(1:50,:) , stat=errstat )
write (*,*) d( 1, :) 
deallocate( tmp )

end program z 

Correct output in gfortran 5:

$ gfortran5 -Wl,-rpath=/usr/local/lib/gcc5 z.f90
$ ./a.out 
   1.00000000       2.00000000    
   1.00000000       2.00000000    
   1.00000000       2.00000000    

Wrong output in gfortran 6:

$ gfortran6 -Wl,-rpath=/usr/local/lib/gcc6 z.f90 
$ ./a.out 
   1.00000000       2.00000000    
   1.00000000       2.00000000    
   4.00000000       0.00000000    

This is on FreeBSD 10.1-RELEASE-p16 amd64

[Bug fortran/67171] [6.0 regression] sourced allocation

[vehre at gcc dot gnu.org]

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

--- Comment #1 from vehre at gcc dot gnu.org ---
First working thesis on this:

offset of d is errorneously propagate to tmp.

A suitable workaround is to wrap the last allocate in an associate:

associate (t => tmp(1:50,:))
allocate( d( 50, 2 ), source = t , stat=errstat )
end associate

[Bug fortran/67171] [6.0 regression] sourced allocation

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-08-10
     Ever confirmed|0                           |1

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Revision r223090 is OK, r223694 is not.

[Bug fortran/67171] [6 regression] sourced allocation

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |6.0
            Summary|[6.0 regression] sourced    |[6 regression] sourced
                   |allocation                  |allocation

[Bug fortran/67171] [6 regression] sourced allocation

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

[Bug fortran/67171] [6 regression] sourced allocation

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |pault at gcc dot gnu.org

--- Comment #3 from Paul Thomas <pault at gcc dot gnu.org> ---
The bug arises because array sections are marked as DECL_ARTIFICIAL and so the
offending SOURCE expression produces a temporary variable, whose offset is out
of kilter, being zero. The most economical solution, in terms of effort, is
simply to suppress the creation of the temporary, when the source is a
variable. This is regtesting right now. Alternatively, the array descriptor
could be converted to unity based indexes, with the appropriate offset.

I'll take it.

Paul

[Bug fortran/67171] [6 regression] sourced allocation

[vehre at gmx dot de]

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

--- Comment #4 from Andre Vehreschild <vehre at gmx dot de> ---
Hi Paul,

please compare:

https://gcc.gnu.org/ml/fortran/2015-10/msg00033.html

to your fix. Sounds like we are doing the same.

- Andre

On Tue, 20 Oct 2015 14:13:55 +0000
"pault at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67171
> 
> Paul Thomas <pault at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>            Assignee|unassigned at gcc dot gnu.org      |pault at gcc dot gnu.org
> 
> --- Comment #3 from Paul Thomas <pault at gcc dot gnu.org> ---
> The bug arises because array sections are marked as DECL_ARTIFICIAL and so the
> offending SOURCE expression produces a temporary variable, whose offset is out
> of kilter, being zero. The most economical solution, in terms of effort, is
> simply to suppress the creation of the temporary, when the source is a
> variable. This is regtesting right now. Alternatively, the array descriptor
> could be converted to unity based indexes, with the appropriate offset.
> 
> I'll take it.
> 
> Paul
>

[Bug fortran/67171] [6 regression] sourced allocation

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to Andre Vehreschild from comment #4)
> Hi Paul,
> 
> please compare:
> 
> https://gcc.gnu.org/ml/fortran/2015-10/msg00033.html
> 
> to your fix. Sounds like we are doing the same.
> 
> - Andre
> 
> On Tue, 20 Oct 2015 14:13:55 +0000
> "pault at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67171
> > 
> > Paul Thomas <pault at gcc dot gnu.org> changed:
> > 
> >            What    |Removed                     |Added
> > ----------------------------------------------------------------------------
> >            Assignee|unassigned at gcc dot gnu.org      |pault at gcc dot gnu.org
> > 
> > --- Comment #3 from Paul Thomas <pault at gcc dot gnu.org> ---
> > The bug arises because array sections are marked as DECL_ARTIFICIAL and so the
> > offending SOURCE expression produces a temporary variable, whose offset is out
> > of kilter, being zero. The most economical solution, in terms of effort, is
> > simply to suppress the creation of the temporary, when the source is a
> > variable. This is regtesting right now. Alternatively, the array descriptor
> > could be converted to unity based indexes, with the appropriate offset.
> > 
> > I'll take it.
> > 
> > Paul
> >

Hi Andre,

That's not the same PR is it?

Cheers

Paul

[Bug fortran/67171] [6 regression] sourced allocation

[vehre at gmx dot de]

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

--- Comment #6 from Andre Vehreschild <vehre at gmx dot de> ---
Hi Paul,

No it's not, but the patch for the other pr addresses a lot of things in the
allocate. Mostly about functions returning class objects, but I remember to
have changed some of the things your patch might address . I just wanted to
point you to similar work.

Regards,
Andre

[Bug fortran/67171] [6 regression] sourced allocation

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #7 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Andre Vehreschild from comment #4)
> Hi Paul,
> 
> please compare:
> 
> https://gcc.gnu.org/ml/fortran/2015-10/msg00033.html
> 
> to your fix. Sounds like we are doing the same.
> 

(In reply to Andre Vehreschild from comment #6)
> Hi Paul,
> 
> No it's not, but the patch for the other pr addresses a lot of things in the
> allocate. Mostly about functions returning class objects, but I remember to
> have changed some of the things your patch might address . I just wanted to
> point you to similar work.
> 
Andre, the patch linked above doesn't seem to address that many things,
especially allocate-related.
Maybe you were referring to the following patch instead? It's also one of
yours, and still awaiting review.

https://gcc.gnu.org/ml/gcc-patches/2015-09/msg02208.html

[Bug fortran/67171] [6 regression] sourced allocation

[vehre at gcc dot gnu.org]

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

--- Comment #8 from vehre at gcc dot gnu.org ---
Hi Mikael,

yes, you are absolutely right. I mixed those two up, sorry. My head is in CUDA
programming currently and that's keeping it quite busy. Feel free to review
though :-)

Regards,
   Andre

[Bug fortran/67171] [6 regression] sourced allocation

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas <pault at gcc dot gnu.org> ---
Author: pault
Date: Sun Oct 25 21:31:12 2015
New Revision: 229303

URL: https://gcc.gnu.org/viewcvs?rev=229303&root=gcc&view=rev
Log:
2015-01-25  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/67171
        * trans-array.c (structure_alloc_comps): On deallocation of
        class components, reset the vptr to the declared type vtable
        and reset the _len field of unlimited polymorphic components.
        *trans-expr.c (gfc_find_and_cut_at_last_class_ref): Bail out on
        allocatable component references to the right of part reference
        with non-zero rank and return NULL.
        (gfc_reset_vptr): Simplify this function by using the function
        gfc_get_vptr_from_expr. Return if the vptr is NULL_TREE.
        (gfc_reset_len): If gfc_find_and_cut_at_last_class_ref returns
        NULL return.
        * trans-stmt.c (gfc_trans_allocate): Rely on the use of
        gfc_trans_assignment if expr3 is a variable expression since
        this deals correctly with array sections.

2015-01-25  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/67171
        * gfortran.dg/allocate_with_source_12.f03: New test

        PR fortran/61819
        * gfortran.dg/allocate_with_source_13.f03: New test

        PR fortran/61830
        * gfortran.dg/allocate_with_source_14.f03: New test

Added:
    trunk/gcc/testsuite/gfortran.dg/allocate_with_source_12.f03
    trunk/gcc/testsuite/gfortran.dg/allocate_with_source_13.f03
    trunk/gcc/testsuite/gfortran.dg/allocate_with_source_14.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/67171] [6 regression] sourced allocation

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

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

--- Comment #10 from Paul Thomas <pault at gcc dot gnu.org> ---
Fixed on trunk.

Thanks for the report.

Paul