[Bug fortran/54070] New: Wrong code with allocatable deferred-length (array) function results

[Bug fortran/54070] New: Wrong code with allocatable deferred-length (array) function results

[burnus at gcc dot gnu.org]

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

             Bug #: 54070
           Summary: Wrong code with allocatable deferred-length (array)
                    function results
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org
                CC: damian@rouson.net, pault@gcc.gnu.org


As reported by Damian at http://gcc.gnu.org/ml/fortran/2012-07/msg00117.html ,
allocatable deferred-length (array) function results have issues.


The following code gives a segfault - or with tree checking:
gfc_add_modify_loc, at fortran/trans.c:160

function f()
  character(len=:),allocatable :: f
  f ="ABC"
end function


The following (invalid) program gives an ICE:
  in gimplify_var_or_parm_decl, at gimplify.c:2048
(the program is invalid as one assigns a scalar to an unallocated array)

function f(a)
  character(len=*) :: a
  character(len=:),allocatable :: f(:)
  f = a
end function



One gets the same ICE for the original example. Looking at the dump, there is
no (re)allocation - but there should be one!

module deferred_length_char_array
contains
  function return_string(argument)
    character(*) :: argument
    character(:), dimension(:), allocatable :: return_string
    return_string = argument
  end function 
end module

[Bug fortran/54070] Wrong code with allocatable deferred-length (array) function results

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

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

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-07-23 10:23:15 UTC ---
(In reply to comment #0)
> function f()
>   character(len=:),allocatable :: f
>   f ="ABC"
> end function

Here, one has for the internal length assignment:
  .__result = 3

The RHS is a simple "3", but the LHS is a pointer to an integer ...

 * * *

(In reply to comment #0)
> One gets the same ICE for the original example. Looking at the dump, there is
> no (re)allocation - but there should be one!

Pilot error of mine: As that code also lacks an ALLOCATE, it is also invalid
without an explicit ALLOCATE statement.

(The real-world program uses an array on the RHS. When the result_string has no
"dimension(:)", it compiled. For both, cf. email.)

[Bug fortran/54070] Wrong code with allocatable deferred-length (array) function results

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-07-24 09:27:53 UTC ---
(In reply to comment #0)
> function f()
>   character(len=:),allocatable :: f
>   f ="ABC"
> end function

That part is solved via the following patch; I not yet sure whether I like the
patch or not.

--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -1228 +1228,2 @@ gfc_get_symbol_decl (gfc_symbol * sym)
-  if ((sym->attr.dummy && ! sym->attr.function) || (sym->attr.result &&
byref))
+  if ((sym->attr.dummy && ! sym->attr.function)
+      || (byref && (sym->attr.result || sym->result == sym)))
@@ -1254 +1255,2 @@ gfc_get_symbol_decl (gfc_symbol * sym)
-         if (sym->ts.deferred && sym->attr.result
+         if (sym->ts.deferred
+             && (sym->attr.result || sym->result == sym)


For some reason, the temporary does not seem to be needed when doing an
assignment of a variable, i.e.
  function f()
    character (len=*) :: a
    character(len=:),allocatable :: f
    f = a
  end function

 * * *

For arrays, I think the proper way is to store the length in the array
descriptor - as required for C interoperable strings in TR29113.

In any case, the array code doesn't use gfc_get_symbol_decl but invokes:
gfc_trans_deferred_vars -> (gfc_trans_dummy_array_bias,
gfc_trans_dummy_character), where the latter calls gfc_trans_vla_type_sizes.

In one of the latter procedures, one could insert some code to generate a local
length variable, which could then be put in the finally part as last argument
of the gfc_add_init_cleanup in gfc_trans_dummy_character. Or one might be able
to dereference the variable directly in se.string_len?

[Bug fortran/54070] Wrong code with allocatable deferred-length (array) function results

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-07-24 14:39:54 UTC ---
Dominique mentions that the failure of the array test case seems to be a
regression between Rev. 188654 and 188694. Well, there was only one commit
during that time (Rev. 188692, 2012-06-16): The one for PR 53642 / PR45170:
"Ensure that the RHS string length is evaluated before the deferred-length LHS
is reallocated."

Using my (older) build of Rev. 187316 (2012-05-09), the array test case fails
with the same error as today, but the scalar example of comment 0 works. (The
dump looks fine and identical to today's trunk plus patch of comment 2.)

Thus, the scalar version got broken between 187316 and 188654; the array
version got repaired after 187316 and got broken again before 188694 (i.e. with
188692).

[Bug fortran/54070] Wrong code with allocatable deferred-length (array) function results

[zeccav at gmail dot com]

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

Vittorio Zecca <zeccav at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zeccav at gmail dot com

--- Comment #4 from Vittorio Zecca <zeccav at gmail dot com> ---
The following duplicates the ICE in gimplify_var_or_parm_decl:

      SUBROUTINE sub (n)

      INTEGER, INTENT(IN) :: n

      CHARACTER(LEN=n) :: s

      ASSOCIATE (mio => s)
      END ASSOCIATE

      END

[Bug fortran/54070] Wrong code with allocatable deferred-length (array) function results

[dominiq at lps dot ens.fr]

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

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

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

--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Dominique mentions that the failure of the array test case seems to be 
> a regression between Rev. 188654 and 188694. Well, there was only one 
> commit during that time (Rev. 188692, 2012-06-16): The one for 
> PR 53642 / PR45170: "Ensure that the RHS string length is evaluated 
> before the deferred-length LHS is reallocated."

I cannot reproduce that any longer.

> Using my (older) build of Rev. 187316 (2012-05-09), the array test case 
> fails with the same error as today, but the scalar example of comment 0 
> works. (The dump looks fine and identical to today's trunk plus patch 
> of comment 2.)
>
> Thus, the scalar version got broken between 187316 and 188654; the array 
> version got repaired after 187316 and got broken again before 188694 
> (i.e. with 188692).

The second and third tests in comment 0 give respectively

function f(a)
1
Error: CHARACTER(*) function 'f' at (1) cannot be array-valued

and

  function return_string(argument)
  1
Error: CHARACTER(*) function 'return_string' at (1) cannot be array-valued
pr54070_2.f90:3.2:

  function return_string(argument)
  1
Error: CHARACTER(*) function 'return_string' at (1) cannot be array-valued

when compiled with 4.7.3 or 4.7.4 (r206161).

Should I mark this pr as a 4.8/4.9 regression?

[Bug fortran/54070] [4.8/4.9 Regression] Wrong code with allocatable deferred-length (array) function results

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
            Summary|Wrong code with allocatable |[4.8/4.9 Regression] Wrong
                   |deferred-length (array)     |code with allocatable
                   |function results            |deferred-length (array)
                   |                            |function results

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Should I mark this pr as a 4.8/4.9 regression?

No answer, marking as a 4.8/4.9 regression.

[Bug fortran/54070] [4.8/4.9 Regression] Wrong code with allocatable deferred-length (array) function results

[rouson at stanford dot edu]

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

--- Comment #7 from Damian Rouson <rouson at stanford dot edu> ---
I assume the ICE below is related to this PR, but the  argument in this case is
an array. Should I generate a separate PR? 

$ cat parse_command_line.f90 
module parse_command_line
  implicit none
contains
  function get_keyword_values(default_values) result(actual_values)
    character(len=*), intent(in) :: default_values(:)
    character(len=:), allocatable :: actual_values(:)     
    actual_values=default_values
  end function 
end module

$ gfortran -c parse_command_line.f90 
parse_command_line.f90: In function 'get_keyword_values':
parse_command_line.f90:7:0: internal compiler error: in
gimplify_var_or_parm_decl, at gimplify.c:1721
     actual_values=default_values
 ^

parse_command_line.f90:7:0: internal compiler error: Abort trap: 6
gfortran: internal compiler error: Abort trap: 6 (program f951)
Abort trap: 6

$ gfortran --version
GNU Fortran (MacPorts gcc49 4.9-20140316_0) 4.9.0 20140316 (experimental)

[Bug fortran/54070] [4.8/4.9 Regression] Wrong code with allocatable deferred-length (array) function results

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.8.3

[Bug fortran/54070] [4.8/4.9 Regression] Wrong code with allocatable deferred-length (array) function results

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
known-to-work version?

[Bug fortran/54070] [4.8/4.9/4.10 Regression] Wrong code with allocatable deferred-length (array) function results

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.3                       |4.8.4

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 4.8.3 is being released, adjusting target milestone.

[Bug fortran/54070] [4.8/4.9/5 Regression] Wrong code with allocatable deferred-length (array) function results

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |davidgkinniburgh at yahoo dot co.u
                   |                            |k

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

[Bug fortran/54070] [4.8/4.9/5 Regression] Wrong code with allocatable deferred-length (array) function results

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
I think the remaining issue(s) of pr51976 is (are) duplicate(s) of this PR.

[Bug fortran/54070] [4.8/4.9/5 Regression] Wrong code with allocatable deferred-length (array) function results

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ondrej.certik at gmail dot com

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

[Bug fortran/54070] [4.8/4.9/5 Regression] Wrong code with allocatable deferred-length (array) function results

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.4                       |4.8.5

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.4 has been released.

[Bug fortran/54070] [4.8/4.9/5 Regression] Wrong code with allocatable deferred-length (array) function results

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jwmwalrus at gmail dot com

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

[Bug fortran/54070] [4.8/4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.5                       |4.9.3

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.

[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.3 has been released.

[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.3                       |4.9.4

[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results

[zeccav at gmail dot com]

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

--- Comment #17 from Vittorio Zecca <zeccav at gmail dot com> ---
I found it fixed in 5.2.0

[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.8.0
             Blocks|                            |20585
      Known to fail|                            |4.8.1

--- Comment #18 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> I found it fixed in 5.2.0

This PR contains 5 tests. Let me label them a, b, and c for the ones in comment
0, d for the one in comment 4 and e for the one in comment 7.

As for today I find that a, c, and e are still giving an ICE with 4.9 up to
trunk (6.0), b compiles with 4.9 up to trunk, and d compiles with 5.2 and
trunk, but still gives an ICE with 4.9.4.

I confirm that revision r188654 compiles a, c, d, and e, but not b.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585
[Bug 20585] [meta-bug] Fortran 2003 support