[Bug fortran/59398] New: Wrong bounds for allocatable result and for

[Bug fortran/59398] New: Wrong bounds for allocatable result and for

[loximann at gmail dot com]

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

            Bug ID: 59398
           Summary: Wrong bounds for allocatable result and for
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: loximann at gmail dot com

The lower bounds of the result of an allocatable array-valued function are
always set to 1.

Also, I discovered that if LHS is allocated and has the same size as RHS, the
bounds are not changed.

This code illustrates it:
************************************************
program return_allocatable
    implicit none

    real, allocatable :: a(:)

    real, parameter :: b(-2:4)=[1,2,3,4,5,6,7]

    a=foo(3)
    print*,lbound(a),':',ubound(a)

    a=b
    print*,lbound(a),':',ubound(a)

contains
    function foo(n)
        integer :: n
        real, allocatable :: foo(:)

        allocate(foo(-3:n))

        foo=n
    end function
end program
************************************************
The expected output is
-3:3
-2:4
but instead I get
1:7
1:7

[Bug fortran/59398] Wrong bounds for allocatable result and for

[anlauf at gmx dot de]

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

Harald Anlauf <anlauf at gmx dot de> changed:

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

--- Comment #1 from Harald Anlauf <anlauf at gmx dot de> ---
Sergio,

I'm not sure about the first assignment, but the behavior in
the second case is certainly correct.

On the first assignment, a is not allocated.
On the second assignment, the shape of the RHS is the same,
so you get the same result.

If you modify your program as follows:

program return_allocatable
    implicit none

    real, allocatable :: a(:)

    real, parameter :: b(-2:4)=[1,2,3,4,5,6,7]

    a=foo(3)
    print*,lbound(a),':',ubound(a)
    deallocate (a)

    a=b
    print*,lbound(a),':',ubound(a)
    deallocate (a)

contains
    function foo(n)
        integer :: n
        real, allocatable :: foo(:)

        allocate(foo(-3:n))

        foo=n
    end function
end program


You get:

           1 :           7
          -2 :           4

which is what you also get with Intel v14 and Crayftn 8.2.1.
However, xlf 14.1.0.5 agrees with you:

 -3 : 3
 -2 : 4

F2k8 states:

7.2.1.3 Interpretation of intrinsic assignments

If the variable is an unallocated allocatable array, expr shall have the same
rank. If the variable is an allocated
allocatable variable, it is deallocated if expr is an array of different shape, 
...
If the variable is or becomes an unallocated allocatable variable, it is then
allocated with
...
    • if expr is an array, the shape of expr with each lower bound equal to the
corresponding element of
      LBOUND (expr ).

Thus the assignment from the allocatable function result is broken.
>From gcc-bugs-return-436776-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Dec 05 20:42:32 2013
Return-Path: <gcc-bugs-return-436776-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1680 invoked by alias); 5 Dec 2013 20:42:32 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 1652 invoked by uid 48); 5 Dec 2013 20:42:29 -0000
From: "loximann at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/59398] Wrong bounds for allocatable result and for
Date: Thu, 05 Dec 2013 20:42:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: loximann at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59398-4-2c6acJRDUh@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59398-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59398-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-12/txt/msg00431.txt.bz2
Content-length: 653

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY398

--- Comment #2 from Sergio Losilla <loximann at gmail dot com> ---
There should be no need to deallocate. From the excerpt you copied: "If the
variable is an allocated allocatable variable, it is deallocated if expr is an
array of different shape".

For the second, the obtained shape should *always* be the same. It looks like
gfortran will not touch LHS if it is allocated and has the same size as RHS.
And that should not be the case.

By the way, the Intel compiler is quite crazy. Version 11 something works as
expected in a platform I have access to, but 12 and 13 fail one or both
assignments!

[Bug fortran/59398] Wrong bounds for allocatable result and for

[anlauf at gmx dot de]

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

--- Comment #3 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to Sergio Losilla from comment #2)
> There should be no need to deallocate. From the excerpt you copied: "If the
> variable is an allocated allocatable variable, it is deallocated if expr is
> an array of different shape".

shape(-3:3) == shape (-2:4) == shape(1:7)

Shape is UBOUND-LBOUND+1.

> For the second, the obtained shape should *always* be the same. It looks
> like gfortran will not touch LHS if it is allocated and has the same size as
> RHS. And that should not be the case.

No, gfortran is right here, see above.

> By the way, the Intel compiler is quite crazy. Version 11 something works as
> expected in a platform I have access to, but 12 and 13 fail one or both
> assignments!

Funny!  Would you please report to the Intel forum?

[Bug fortran/59398] Wrong bounds for allocatable result and for

[anlauf at gmx dot de]

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

--- Comment #4 from Harald Anlauf <anlauf at gmx dot de> ---
I also tested the modified case with NAG 5.3.2(951).
It agrees with gfortran.

I now wonder whether there is something special about
allocatable function results.

[Bug fortran/59398] Wrong bounds for allocatable result and for

[loximann at gmail dot com]

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

--- Comment #5 from Sergio Losilla <loximann at gmail dot com> ---
(In reply to Harald Anlauf from comment #3)

OK, so we seem to agree that gfortran is not assigning the correct bounds,
right?

> shape(-3:3) == shape (-2:4) == shape(1:7)
> 
> Shape is UBOUND-LBOUND+1.

Hm, you are right. This is funny though, as the result of the allocation is not
predictable. The workaround should be deallocating ALWAYS, if this is the
wished behaviour.

> > By the way, the Intel compiler is quite crazy. Version 11 something works as
> > expected in a platform I have access to, but 12 and 13 fail one or both
> > assignments!
> 
> Funny!  Would you please report to the Intel forum?

http://software.intel.com/en-us/forums/topic/495378

[Bug fortran/59398] Wrong bounds for allocatable result and for

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2014-01-06
     Ever confirmed|0                           |1

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
(In reply to Harald Anlauf from comment #1)
> Thus the assignment from the allocatable function result is broken.

Is it true?

[Bug fortran/59398] Wrong bounds for allocatable result and for

[anlauf at gmx dot de]

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

--- Comment #7 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to Dominique d'Humieres from comment #6)
> (In reply to Harald Anlauf from comment #1)
> > Thus the assignment from the allocatable function result is broken.
> 
> Is it true?

I looked at the discussion in the Intel Forum (c.f. comment #5) and I have
to admit that I am unsure.  Steve Lionel quotes the first two phrases of

12.3.3 Characteristics of function results

The characteristics of a function result are its type, type parameters (if
any), rank, whether it is polymorphic, whether it is allocatable, whether it is
a pointer, whether it has the CONTIGUOUS attribute, and whether it is a
procedure pointer. If a function result is an array that is not an allocatable
or pointer, its shape is a characteristic.


(I checked this with the F2k8 draft).

Steve argues that it does not say whether its actual bounds are a
characteristic.  If you assume that only the shape matters, then
the gfortran behavior is not a bug.  I think it is up to the experts
to discuss this and maybe submit an interpretation request.

[Bug fortran/59398] Wrong bounds for allocatable result and for

[loximann at gmail dot com]

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

--- Comment #8 from Sergio Losilla <loximann at gmail dot com> ---
> Steve argues that it does not say whether its actual bounds are a
> characteristic.  If you assume that only the shape matters, then
> the gfortran behavior is not a bug.  I think it is up to the experts
> to discuss this and maybe submit an interpretation request.

My bad for not reporting the outcome of that discussion.

That seems to be the case. For the moment, the lesson I learnt is never to
return arrays with a lower bound different from 1.

This kind of sucks. Why having lower bounds different than 0 sometimes only?
Either have them, or don't!

Sergio

[Bug fortran/59398] Wrong bounds for allocatable result and for

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Any progress or should this PR be closed as INVALID?

[Bug fortran/59398] Wrong bounds for allocatable result and for

[dominiq at lps dot ens.fr]

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

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

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

--- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> That seems to be the case. For the moment, the lesson I learnt is never
> to return arrays with a lower bound different from 1.

The following variant

program return_allocatable
    implicit none

    real, allocatable :: a(:)

    real, parameter :: b(-2:4)=[1,2,3,4,5,6,7]

    a=b
    print*,lbound(a),':',ubound(a)

    deallocate(a)
    a=foo(3)
    print*,lbound(a),':',ubound(a)

contains
    function foo(n) result(res)
        integer :: n
        real, allocatable :: res(:)

        allocate(res(-3:n))

        res=n
        print *, lbound(res), ubound(res)
    end function
end program

gives (with the default -frealloc-lhs)

          -2 :           4
          -3           3
           1 :           7

Is this correct?

> This kind of sucks. Why having lower bounds different than 0 sometimes only?
> Either have them, or don't!

In Fortran the default lower bounds are always 1 and never 0.