User account creation filtered due to spam.

Bug 49755 - ALLOCATE with STAT= produces invalid code for already allocated vars
Summary: ALLOCATE with STAT= produces invalid code for already allocated vars
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: missed-optimization, wrong-code
Depends on:
Blocks: 32834
  Show dependency treegraph
Reported: 2011-07-15 08:28 UTC by Tobias Burnus
Modified: 2011-07-27 17:38 UTC (History)
1 user (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2011-07-15 08:28:25 UTC
The Fortran standard states that ALLOCATEing an already allocated variable is an error.

gfortran nicely aborts with a run-time error if there is no STAT= variable. However, if there is STAT= variable, instead of just setting it and stopping, gfortran deallocates the variable and then tries the new allocation.

There are several issues with that:

(a) It's invalid according to the Fortran standard, which states in
    "6.7.4 STAT= specifier":
    "* each allocate-object that was not successfully allocated or
       deallocated shall retain its previous allocation status
       or pointer association status."

(b) It adds lots of code, which should be most of the time not used,
    increasing the code size and making optimizations more difficult,
    especially for derived types with allocatable components

(c) With coarrays, there are even more issues - one shall not simply
    free a coarray unilaterally!

Test case (except for the "abort" function, valid Fortran 2008):

integer, allocatable :: A(:, :)
integer :: stat

A = 42

! Allocate of already allocated variable
allocate (A(5,5), stat=stat)

! Expected: Error stat and previous allocation status

if (stat == 0) call abort ()
if (any (shape (A) /= [20, 20])) call abort ()
if (any (A /= 42)) call abort ()
Comment 1 dcarrera 2011-07-27 10:10:10 UTC
Author: dcarrera
Date: Wed Jul 27 10:10:06 2011
New Revision: 176822

2011-07-26  Daniel Carrera  <>

	PR fortran/49755
	* trans.c (gfc_allocate_using_malloc): Change function signature.
	Return nothing. New parameter "pointer". Eliminate temorary variables.
	(gfc_allocate_using_lib): Ditto.
	(gfc_allocate_allocatable): Ditto. Update call to gfc_allocate_using_lib
	and gfc_allocate_using_malloc. Do not free and then reallocate a
	variable that is already allocated.
	(gfc_likely): New function. Basedon gfc_unlikely.
	* trans-array.c (gfc_array_init_size): New parameter "descriptor_block".
	Instructions to modify the array descriptor are stored in this block
	while other instructions continue to be stored in "pblock".
	(gfc_array_allocate): Update call to gfc_array_init_size. Move the
	descriptor_block so that the array descriptor is only updated if
	the array was allocated successfully.
	Update calls to gfc_allocate_allocatable and gfc_allocate_using_malloc.
	* trans.h (gfc_allocate_allocatable): Change function signature.
	Function now returns void.
	(gfc_allocate_using_lib): Ditto, and new function parameter.
	(gfc_allocate_using_malloc): Ditto.
	* trans-openmp.c (gfc_omp_clause_default_ctor,
	gfc_omp_clause_copy_ctor,gfc_trans_omp_array_reduction): Replace a call
	to gfc_allocate_allocatable with gfc_allocate_using_malloc.
	* trans-stmt.c (gfc_trans_allocate): Update function calls for
	gfc_allocate_allocatable and gfc_allocate_using_malloc.

2011-07-26  Daniel Carrera  <>

	PR fortran/49755
	* gfortran.dg/multiple_allocation_1.f90: Fix test. Allocating an
	allocated array should *not* change its size.
	* gfortran.dg/multiple_allocation_3.f90: New test.

Comment 2 Tobias Burnus 2011-07-27 17:38:15 UTC
FIXED on the 4.7 trunk.