Bug 34402 - Diagnose illegal initialization of derived type containing allocatable component
Summary: Diagnose illegal initialization of derived type containing allocatable component
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: 4.5.0
Assignee: Daniel Franke
URL:
Keywords: accepts-invalid
Depends on:
Blocks: 29962
  Show dependency treegraph
 
Reported: 2007-12-09 06:34 UTC by Walter Spector
Modified: 2009-12-10 19:59 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-12-09 22:05:38


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Walter Spector 2007-12-09 06:34:50 UTC
The initialization in following test case should be diagnosed as an error:

$ cat nocomp7.f90
module nocomp7
  implicit none

  type bad_t
    real, allocatable :: x(:)
  end type

! The following is illegal!

  type (bad_t) :: bad = bad_t ( (/ 1., 3., 5., 7., 9. /) )

end module
$
$ gfortran --version
GNU Fortran (GCC) 4.3.0 20071005 (experimental) [trunk revision 127783]
Copyright (C) 2007 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING


$
$ gfortran --pedantic -c nocomp7.f90
$
Comment 1 Tobias Burnus 2007-12-09 13:07:58 UTC
NAG f95:
Error: adf.f90, line 10: Initialisation expression for BAD is not constant

ifort:
fortcom: Error: adf.f90, line 10: A data initialization-expr is not valid for this object.   [BAD]
  type (bad_t) :: bad = bad_t ( (/ 1., 3., 5., 7., 9. /) )
------------------^
Comment 2 Daniel Franke 2009-12-08 20:33:32 UTC
(In reply to comment #0)
> ! The following is illegal!
>   type (bad_t) :: bad = bad_t ( (/ 1., 3., 5., 7., 9. /) )

I don't get it. "Fortran 95/2003 explained" by Metcalf has exactly this in the example (figure 12.3, p243) for allocatable components. I don't have the standard section, but Metcalf states:
"In a structure constructor, an expression corresponding to an allocatable component must be an array or a reference to the intrinsic function NULL with no arguments. [...] If it is an array, but not an allocatable array, the component is allocated with the same bounds and is assigned the same value."

If compiled with "-std=f95", gfortran complains about allocatable components in general and accepts it with "-std=f2003". So, where's the actual problem?
Comment 3 Walter Spector 2009-12-08 21:34:25 UTC
(In reply to comment #2)
> I don't get it. "Fortran 95/2003 explained" by Metcalf has exactly this in the
> example (figure 12.3, p243) for allocatable components... So, where's the actual problem?

The example on p243 correctly shows the use of a structure constructor in an assignment statement.  This bug report is different in that it concerns a structure constructor in the initializer portion of a TYPE statement (where the derived type contains an ALLOCATABLE.)
Comment 4 Daniel Franke 2009-12-08 21:41:51 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > I don't get it. "Fortran 95/2003 explained" by Metcalf has exactly this in the
> > example (figure 12.3, p243) for allocatable components... So, where's the actual problem?
> 
> The example on p243 correctly shows the use of a structure constructor in an
> assignment statement.  This bug report is different in that it concerns a
> structure constructor in the initializer portion of a TYPE statement (where 
> the derived type contains an ALLOCATABLE.)

And while writing the above, I didn't take this as significant difference. However, it dawns on me that the crucial point is, that variables with initializer get the SAVE attribute which doesn't go well with the ALLOCATABLE components. Correct?
Comment 5 Walter Spector 2009-12-09 00:27:53 UTC
(In reply to comment #4)
> ... it dawns on me that the crucial point is, that variables with
> initializer get the SAVE attribute which doesn't go well with the ALLOCATABLE
> components. Correct?

I am not sure why they put the restriction in.  But note that one *can* use null() in a structure constructor for the allocatable component.  So the following is legal:

  type xyzzy
    integer, allocatable :: x(:)
    real :: y
  end type

  type(xyzzy) :: plugh = xyzzy (null (), 123.456)

See 7.1.7(3) in F2003 (and 7.1.12(3) in the F2008 draft.)
Comment 6 Daniel Franke 2009-12-09 22:05:38 UTC
(In reply to comment #5)
> See 7.1.7(3) in F2003 (and 7.1.12(3) in the F2008 draft.)

Walter, thanks for reference!
Comment 7 Daniel Franke 2009-12-10 19:57:30 UTC
Subject: Bug 34402

Author: dfranke
Date: Thu Dec 10 19:57:16 2009
New Revision: 155138

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155138
Log:
gcc/fortran/:
2009-12-10  Daniel Franke  <franke.daniel@gmail.com>

        PR fortran/34402
        * expr.c (check_alloc_comp_init): New.
        (check_init_expr): Verify that allocatable components
        are not data-initalized.

gcc/testsuite/:
2009-12-10  Daniel Franke  <franke.daniel@gmail.com>

        PR fortran/34402
        * gfortran.dg/alloc_comp_init_expr.f03: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/alloc_comp_init_expr.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/expr.c
    trunk/gcc/testsuite/ChangeLog

Comment 8 Daniel Franke 2009-12-10 19:59:03 UTC
Fixed in trunk. Closing.