Bug 54070 - [4.9/5 Regression] Wrong code with allocatable deferred-length (array) function results
Summary: [4.9/5 Regression] Wrong code with allocatable deferred-length (array) functi...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.8.0
: P4 normal
Target Milestone: 4.9.4
Assignee: Paul Thomas
URL:
Keywords: wrong-code
: 63903 66065 (view as bug list)
Depends on:
Blocks: F2003 68241
  Show dependency treegraph
 
Reported: 2012-07-23 09:32 UTC by Tobias Burnus
Modified: 2016-03-09 20:54 UTC (History)
10 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.8.0
Known to fail: 4.8.1
Last reconfirmed: 2014-01-07 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2012-07-23 09:32:52 UTC
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
Comment 1 Tobias Burnus 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.)
Comment 2 Tobias Burnus 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?
Comment 3 Tobias Burnus 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).
Comment 4 Vittorio Zecca 2013-07-15 06:24:27 UTC
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
Comment 5 Dominique d'Humieres 2014-01-07 11:15:26 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."

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?
Comment 6 Dominique d'Humieres 2014-03-23 00:26:12 UTC
> Should I mark this pr as a 4.8/4.9 regression?

No answer, marking as a 4.8/4.9 regression.
Comment 7 Damian Rouson 2014-03-24 05:28:58 UTC
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)
Comment 8 Richard Biener 2014-03-31 09:09:06 UTC
known-to-work version?
Comment 9 Richard Biener 2014-05-22 09:03:38 UTC
GCC 4.8.3 is being released, adjusting target milestone.
Comment 10 Dominique d'Humieres 2014-11-16 15:31:25 UTC
*** Bug 63903 has been marked as a duplicate of this bug. ***
Comment 11 Dominique d'Humieres 2014-11-16 15:33:34 UTC
I think the remaining issue(s) of pr51976 is (are) duplicate(s) of this PR.
Comment 12 Dominique d'Humieres 2014-12-08 23:22:31 UTC
*** Bug 64229 has been marked as a duplicate of this bug. ***
Comment 13 Jakub Jelinek 2014-12-19 13:25:38 UTC
GCC 4.8.4 has been released.
Comment 14 Dominique d'Humieres 2015-03-10 17:57:58 UTC
*** Bug 65381 has been marked as a duplicate of this bug. ***
Comment 15 Richard Biener 2015-06-23 08:14:58 UTC
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
Comment 16 Jakub Jelinek 2015-06-26 19:52:30 UTC
GCC 4.9.3 has been released.
Comment 17 Vittorio Zecca 2015-08-31 16:45:50 UTC
I found it fixed in 5.2.0
Comment 18 Dominique d'Humieres 2015-09-03 21:16:21 UTC
> 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.
Comment 19 Neil Carlson 2015-11-02 01:58:49 UTC
What is the status of this issue?  It would appear from comment 18 to be "fixed" insofar as the the provided examples compile, but is the compiled code correct?

I'd report the following example as a new bug, but I know it would be immediately dismissed as a duplicate of this bug.  This dumb little example compiles with 5.2 and the 20151025 snapshot of 6.0, but in both cases the generated code is bad as it segfaults on a clearly valid assignment statement.

program main
  character(:), allocatable :: string(:)
  call fubar (string)
contains
  subroutine fubar (string)
    character(:), allocatable, intent(out) :: string(:)
    allocate(character(5) :: string(2))
    print *, 'len(string)=', len(string), ', size(string)=', size(string)
    string = 'fubar' ! <== SEGMENTATION FAULT HERE
  end subroutine
end program

Produces this output:

 len(string)=           5 , size(string)=           2

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7FFB05C4E517
#1  0x7FFB05C4EB5E
#2  0x7FFB0514F95F
#3  0x7FFB051B6EC8
#4  0x400D23 in fubar.3417 at fubar.f90:?
#5  0x400DC9 in MAIN__ at fubar.f90:?
Segmentation fault (core dumped)
Comment 20 kargl 2015-11-02 03:02:53 UTC
(In reply to neil.n.carlson from comment #19)
> What is the status of this issue? 

It appears to not be completely fixed.
Comment 21 Dominique d'Humieres 2015-11-02 03:44:37 UTC
*** Bug 66065 has been marked as a duplicate of this bug. ***
Comment 22 Dominique d'Humieres 2015-11-02 03:50:30 UTC
> What is the status of this issue?  It would appear from comment 18
> to be "fixed" insofar as the the provided examples compile, but is
> the compiled code correct?

This a wrong interpretation: most of the tests used to compile (with r188654, hence the regression), at some point compiling most of them gave an ICE, now two of them compiles. I never said that the compiled codes were correct, they are all missing a test for that. In top of that this PR is still opened. 

Now the following variant of 'b' ('a' being the original test, i.e., the third in comment 0):

print *, "'", f(), "'"

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

compiles and outputs

 'ABC'

Now tha problem is that there are several PRs opened for deferred-length (at least nine, eight now!-) and so far nobody care to check for duplicates.

Note that comment 18 was an answer to comment 17

> I found it fixed in 5.2.0
Comment 23 Neil Carlson 2015-11-02 04:58:19 UTC
Here's an even simpler example with the deferred length character array as a local variable -- not a function result or dummy argument.  Sure seems as though the allocate statement itself is what is being mishandled:

program main
  character(:), pointer :: s(:)
  allocate(character(3)::s(2))
  s(1) = 'foo'; s(2) = 'bar'
  print *, s, ' (expect "foobar")'
end program

Compiles with both 5.2 and 6.0 20151025, but both return the wrong result:

 barbar (expect "foobar")
Comment 24 Dominique d'Humieres 2015-11-02 11:24:54 UTC
The test in comment 23 looks like a duplicate of pr50221.
Comment 25 Dominique d'Humieres 2015-11-02 22:51:02 UTC
The regression (ICE) is caused by revision r188692 (pr53642). If I apply the following patch

--- ../_clean/gcc/fortran/trans-expr.c	2015-10-29 17:11:18.000000000 +0100
+++ gcc/fortran/trans-expr.c	2015-11-02 23:44:18.000000000 +0100
@@ -9288,7 +9354,7 @@ gfc_trans_assignment_1 (gfc_expr * expr1
      otherwise the character length of the result is not known.
      NOTE: This relies on having the exact dependence of the length type
      parameter available to the caller; gfortran saves it in the .mod files.  */
-  if (flag_realloc_lhs && expr2->ts.type == BT_CHARACTER && expr1->ts.deferred)
+  if (flag_realloc_lhs && expr2->ts.type == BT_CHARACTER && expr1->ts.deferred && expr2->expr_type != EXPR_VARIABLE)
     gfc_add_block_to_block (&block, &rse.pre);
 
   /* Nullify the allocatable components corresponding to those of the lhs

the ICEs are gone (it does not mean that the generated code is correct!) but the test

gfortran.dg/deferred_type_param_8.f90

aborts at run time.
Comment 26 Paul Thomas 2015-11-28 10:19:42 UTC
I have a somewhat ragged patch that does the job. I will be cleaning it up in the next 24 hours for submission.

Paul
Comment 27 paul.richard.thomas@gmail.com 2015-12-17 12:21:29 UTC
...so ragged in fact that it fails at all levels of optimization.... I
have not had time these last days to come back to it and understand
why. Something for the holidays!

Paul

On 28 November 2015 at 11:19, pault at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070
>
> 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 #26 from Paul Thomas <pault at gcc dot gnu.org> ---
> I have a somewhat ragged patch that does the job. I will be cleaning it up in
> the next 24 hours for submission.
>
> Paul
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.
Comment 28 Paul Thomas 2016-01-07 11:00:17 UTC
(In reply to paul.richard.thomas@gmail.com from comment #27)
> ...so ragged in fact that it fails at all levels of optimization.... I
> have not had time these last days to come back to it and understand
> why. Something for the holidays!
> 
> Paul
> 
> On 28 November 2015 at 11:19, pault at gcc dot gnu.org
> <gcc-bugzilla@gcc.gnu.org> wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070
> >
> > 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 #26 from Paul Thomas <pault at gcc dot gnu.org> ---
> > I have a somewhat ragged patch that does the job. I will be cleaning it up in
> > the next 24 hours for submission.
> >
> > Paul
> >
> > --
> > You are receiving this mail because:
> > You are on the CC list for the bug.
> > You are the assignee for the bug.

OK - I found the problem with correct code; ie. the three cases in comment #0 with an allocation.

However, not for the first time, I have failed to make the -fcheck=mem test work for the unallocated result. I suspect that there is some trivial problem and that I will crack it in the next 24 hours.

Paul
Comment 29 Paul Thomas 2016-01-15 20:34:31 UTC
Author: pault
Date: Fri Jan 15 20:33:58 2016
New Revision: 232450

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

	PR fortran/64324
	* resolve.c (check_uop_procedure): Prevent deferred length
	characters from being trapped by assumed length error.

	PR fortran/49630
	PR fortran/54070
	PR fortran/60593
	PR fortran/60795
	PR fortran/61147
	PR fortran/64324
	* trans-array.c (gfc_conv_scalarized_array_ref): Pass decl for
	function as well as variable expressions.
	(gfc_array_init_size): Add 'expr' as an argument. Use this to
	correctly set the descriptor dtype for deferred characters.
	(gfc_array_allocate): Add 'expr' to the call to
	'gfc_array_init_size'.
	* trans.c (gfc_build_array_ref): Expand logic for setting span
	to include indirect references to character lengths.
	* trans-decl.c (gfc_get_symbol_decl): Ensure that deferred
	result char lengths that are PARM_DECLs are indirectly
	referenced both for directly passed and by reference.
	(create_function_arglist): If the length type is a pointer type
	then store the length as the 'passed_length' and make the char
	length an indirect reference to it.
	(gfc_trans_deferred_vars): If a character length has escaped
	being set as an indirect reference, return it via the 'passed
	length'.
	* trans-expr.c (gfc_conv_procedure_call): The length of
	deferred character length results is set TREE_STATIC and set to
	zero.
	(gfc_trans_assignment_1): Do not fix the rse string_length if
	it is a variable, a parameter or an indirect reference. Add the
	code to trap assignment of scalars to unallocated arrays.
	* trans-stmt.c (gfc_trans_allocate): Remove 'def_str_len' and
	all references to it. Instead, replicate the code to obtain a
	explicitly defined string length and provide a value before
	array allocation so that the dtype is correctly set.
	trans-types.c (gfc_get_character_type): If the character length
	is a pointer, use the indirect reference.

2016-01-15  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/49630
	* gfortran.dg/deferred_character_13.f90: New test for the fix
	of comment 3 of the PR.

	PR fortran/54070
	* gfortran.dg/deferred_character_8.f90: New test
	* gfortran.dg/allocate_error_5.f90: New test

	PR fortran/60593
	* gfortran.dg/deferred_character_10.f90: New test

	PR fortran/60795
	* gfortran.dg/deferred_character_14.f90: New test

	PR fortran/61147
	* gfortran.dg/deferred_character_11.f90: New test

	PR fortran/64324
	* gfortran.dg/deferred_character_9.f90: New test

Added:
    trunk/gcc/testsuite/gfortran.dg/allocate_error_5.f90
    trunk/gcc/testsuite/gfortran.dg/deferred_character_10.f90
    trunk/gcc/testsuite/gfortran.dg/deferred_character_11.f90
    trunk/gcc/testsuite/gfortran.dg/deferred_character_12.f90
    trunk/gcc/testsuite/gfortran.dg/deferred_character_13.f90
    trunk/gcc/testsuite/gfortran.dg/deferred_character_14.f90
    trunk/gcc/testsuite/gfortran.dg/deferred_character_8.f90
    trunk/gcc/testsuite/gfortran.dg/deferred_character_9.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/fortran/trans-types.c
    trunk/gcc/fortran/trans.c
    trunk/gcc/testsuite/ChangeLog
Comment 30 Neil Carlson 2016-01-18 14:47:28 UTC
Paul, you've done a lot of great work here (a huge thanks!) and I can confirm that many of my deferred-length character issues seem to be resolved now with the trunk (r232457, 1/15/2016).  I'm uncertain though whether you consider this PR resolved or if you are still working on it (there were lots of examples in PRs marked as duplicates).  I still have at least one remaining issue with this trunk version:

class(*), allocatable :: x(:)
allocate(x, source=['foo','bar'])
end

Compiles fine, but produces a run time seg fault:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7F85F60F5517
#1  0x7F85F60F5B5E
#2  0x7F85F55F695F
#3  0x7F85F56507ED
#4  0x400932 in __copy_character_1.3416 at bug.f90:?
#5  0x400B91 in MAIN__ at bug.f90:?
Segmentation fault (core dumped)

Should I open another PR for this?
Comment 31 Neil Carlson 2016-01-18 14:55:39 UTC
Sorry, ignore the example of comment 30.  I had already reported this in PR 67564 (not a duplicate of this one).  I'm getting old ...
Comment 32 Paul Thomas 2016-01-18 15:26:33 UTC
(In reply to neil.n.carlson from comment #31)
> Sorry, ignore the example of comment 30.  I had already reported this in PR
> 67564 (not a duplicate of this one).  I'm getting old ...

Thanks for your appreciation of my efforts!

I was going to attack some of the remaining deferred character issues after a spell of regression fixing.

I have taken note of PR67564 and will give it a poke around tonight.

Best regards

Paul
Comment 33 Paul Thomas 2016-03-09 20:50:31 UTC
Author: pault
Date: Wed Mar  9 20:49:58 2016
New Revision: 234093

URL: https://gcc.gnu.org/viewcvs?rev=234093&root=gcc&view=rev
Log:
2016-03-09  Paul Thomas  <pault@gcc.gnu.org>

	Backport from trunk.
	PR fortran/69423
	* trans-decl.c (create_function_arglist): Deferred character
	length functions, with and without declared results, address
	the passed reference type as '.result' and the local string
	length as '..result'.
	(gfc_null_and_pass_deferred_len): Helper function to null and
	return deferred string lengths, as needed.
	(gfc_trans_deferred_vars): Call it, thereby reducing repeated
	code, add call for deferred arrays and reroute pointer function
	results. Avoid using 'tmp' for anything other that a temporary
	tree by introducing 'type_of_array' for the arrayspec type.

2016-03-09  Paul Thomas  <pault@gcc.gnu.org>

	Backport from trunk.
	PR fortran/64324
	* resolve.c (check_uop_procedure): Prevent deferred length
	characters from being trapped by assumed length error.

	Backport from trunk.
	PR fortran/49630
	PR fortran/54070
	PR fortran/60593
	PR fortran/60795
	PR fortran/61147
	PR fortran/64324
	* trans-array.c (gfc_conv_scalarized_array_ref): Pass decl for
	function as well as variable expressions.
	(gfc_array_init_size): Add 'expr' as an argument. Use this to
	correctly set the descriptor dtype for deferred characters.
	(gfc_array_allocate): Add 'expr' to the call to
	'gfc_array_init_size'.
	* trans.c (gfc_build_array_ref): Expand logic for setting span
	to include indirect references to character lengths.
	* trans-decl.c (gfc_get_symbol_decl): Ensure that deferred
	result char lengths that are PARM_DECLs are indirectly
	referenced both for directly passed and by reference.
	(create_function_arglist): If the length type is a pointer type
	then store the length as the 'passed_length' and make the char
	length an indirect reference to it.
	(gfc_trans_deferred_vars): If a character length has escaped
	being set as an indirect reference, return it via the 'passed
	length'.
	* trans-expr.c (gfc_conv_procedure_call): The length of
	deferred character length results is set TREE_STATIC and set to
	zero.
	(gfc_trans_assignment_1): Do not fix the rse string_length if
	it is a variable, a parameter or an indirect reference. Add the
	code to trap assignment of scalars to unallocated arrays.
	* trans-stmt.c (gfc_trans_allocate): Remove 'def_str_len' and
	all references to it. Instead, replicate the code to obtain a
	explicitly defined string length and provide a value before
	array allocation so that the dtype is correctly set.
	trans-types.c (gfc_get_character_type): If the character length
	is a pointer, use the indirect reference.

2016-03-09  Paul Thomas  <pault@gcc.gnu.org>

	Backport from trunk.
	PR fortran/69423
	* gfortran.dg/deferred_character_15.f90 : New test.

2016-03-09  Paul Thomas  <pault@gcc.gnu.org>

	Backport from trunk.
	PR fortran/49630
	* gfortran.dg/deferred_character_13.f90: New test for the fix
	of comment 3 of the PR.

	Backport from trunk.
	PR fortran/54070
	* gfortran.dg/deferred_character_8.f90: New test
	* gfortran.dg/allocate_error_5.f90: New test

	Backport from trunk.
	PR fortran/60593
	* gfortran.dg/deferred_character_10.f90: New test

	Backport from trunk.
	PR fortran/60795
	* gfortran.dg/deferred_character_14.f90: New test

	Backport from trunk.
	PR fortran/61147
	* gfortran.dg/deferred_character_11.f90: New test

	Backport from trunk.
	PR fortran/64324
	* gfortran.dg/deferred_character_9.f90: New test


Added:
    branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_error_5.f90
    branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_10.f90
    branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_11.f90
    branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_12.f90
    branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_13.f90
    branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_14.f90
    branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_15.f90
    branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_8.f90
    branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_9.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-decl.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
Comment 34 Paul Thomas 2016-03-09 20:54:47 UTC
Fixed on trunk and 5-branch.

Thanks for the report.

Paul