[Bug fortran/35040] New: usage of init expression in its own definition

[Bug fortran/35040] New: usage of init expression in its own definition

[dfranke at gcc dot gnu dot org]

REAL, DIMENSION(2,2), PARAMETER :: xyz = RESHAPE((/ 1,2,3,4 /), SHAPE(xyz))
END

This is accepted by gfortran and all other compilers Tobias tested. However,
neither of us is sure whether it's valid or not.

For any invalid example, see also: PR34495.


-- 
           Summary: usage of init expression in its own definition
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dfranke at gcc dot gnu dot org


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

[Bug fortran/35040] usage of init expression in its own definition

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2008-01-31 12:22 -------
I think this is valid. One has to read carefully what specification-part and
entity-decl means. I think after "integer(8)" the kind is known and in the next
specification part (e.g. for the dimension) one may use it; similar for your
example: After the bounds are known in the specification (i.e. before "::") one
may use it in the entry decl.

However, the following is circular and thus invalid:

  REAL(8), PARAMETER :: xyz(size(xyz))  = 1

which is rejected by NAG f95:
  Error: Shape enquiry on PARAMETER XYZ before its array declarator is complete
but gfortran wrongly accepts it.


I wonder whether the following is valid or not:
  REAL(8), dimension(kind(xyz)) :: xyz
NAG f95 and gfortran say yes, ifort says no.

That dimension depends on the kind is ok, the problem is whether one may
already use "xyz" or not.

>From "7.1.7 Initialization expression" (F2003):

"If an initialization expression includes a specification inquiry that depends
on a type parameter or an array bound of an entity specified in the same
specification-part, the type parameter or array bound shall be specified in a
prior specification of the specification-part. The prior specification may be
to the left of the specification inquiry in the same statement, but shall not
be within the same entity-decl."


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid


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

[Bug fortran/35040] usage of init expression in its own definition

[burnus at gcc dot gnu dot org]

------- Comment #2 from burnus at gcc dot gnu dot org  2008-01-31 12:39 -------
I asked at comp.lang.fortran:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/a05b8b177f2eb7b1/


-- 

burnus at gcc dot gnu dot org changed:

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


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

[Bug fortran/35040] usage of init expression in its own definition

[burnus at gcc dot gnu dot org]

------- Comment #3 from burnus at gcc dot gnu dot org  2008-01-31 22:25 -------
Answer (see link): All these are wrong per answer to an interpretation request:

6.  INTEGER :: B = BIT_SIZE(B)
7.  INTEGER :: B(BIT_SIZE(B))
8.  INTEGER :: D = DIGITS(D)
9.  INTEGER :: D(DIGITS(D))
10. REAL :: X = EPSILON(X)
2.  INTEGER(selected_int_kind(4)) :: A(KIND(A)) 3.  INTEGER ::
A(2,2*SIZE(A,1)+1) 4.  CHARACTER :: C(10)*(SIZE(C,1)) 5.  INTEGER ::
P(10) = LBOUND(P,1)
1.  INTEGER :: P(complicated_expression_for_lower_bound_1:   &
                & complicated_expression_for_upper_bound_1,   &
                & complicated_expression_for_lower_bound_2:   &
                & complicated_expression_for_upper_bound_2) = &
                & RESHAPE( (/ 11, 21, 12, 22 /), SHAPE(P) ) 

And I also believe all our examples in this PR are wrong. While we really have
to reject
  REAL(8), PARAMETER :: xyz(size(xyz))  = 1
we could allow the others as extension (i.e. only reject using -std=f*) - or we
reject them all.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-01-31 22:25:49
               date|                            |


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

[Bug fortran/35040] usage of init expression in its own definition

[dfranke at gcc dot gnu dot org]

------- Comment #4 from dfranke at gcc dot gnu dot org  2008-02-01 09:47 -------
> And I also believe all our examples in this PR are wrong.

In all the invalid examples given in comment #3, the dimension specification is
on the rhs of '::'. In my example it's on the lhs. If the latter is invalid
too, how about

DIMENSION :: xyz(2,2)
REAL, PARAMETER :: xyz = RESHAPE((/ 1,2,3,4 /), SHAPE(xyz))
END

This should be perfectly valid?


-- 


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

[Bug fortran/35040] usage of init expression in its own definition

[janus at gcc dot gnu dot org]

------- Comment #5 from janus at gcc dot gnu dot org  2008-11-01 21:19 -------
On a related note: The following snippet from PR36426 produces an ICE.

 function foo(x)
   character(len=len(x)) :: foo,x
 end function foo


-- 


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

[Bug fortran/35040] usage of init expression in its own definition

[burnus at gcc dot gnu dot org]

------- Comment #6 from burnus at gcc dot gnu dot org  2008-11-01 22:14 -------
(In reply to comment #5)
> On a related note: The following snippet from PR36426 produces an ICE.
>  function foo(x)
>    character(len=len(x)) :: foo,x
>  end function foo

As this ICE is a regression, I opened the PR 37992 for this. (It is also not an
accepts invalid since gfortran 4.4 now prints an error message.)

 * * *

For the LHS (of "=") expressions such as in comment 1, one now also gets the
error message.

 * * *

(In reply to comment #4)
> > And I also believe all our examples in this PR are wrong.
> In all the invalid examples given in comment #3, the dimension specification
> is on the rhs of '::'. In my example it's on the lhs.

Sorry, I don't understand / find your example. The example

 REAL, DIMENSION(2,2), PARAMETER :: xyz = RESHAPE((/ 1,2,3,4 /), SHAPE(xyz))
is no different from the invalid examples of comment #3:
  REAL :: X = EPSILON(X)

> If the latter is invalid too, how about
> DIMENSION :: xyz(2,2)
> REAL, PARAMETER :: xyz = RESHAPE((/ 1,2,3,4 /), SHAPE(xyz))

I think that test case is OK.


-- 


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

[Bug fortran/35040] usage of init expression in its own definition

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-06-27 16:17:29 UTC ---
(In reply to comment #3)
> Answer (see link): All these are wrong per answer to an interpretation
> request

For completeness, that is Fortran 95's "000090" at
ftp://ftp.nag.co.uk/sc22wg5/N1451-N1500/N1473.txt, which got incorporated in
Fortran 95, Corrigendum 2 (and in Fortran 2003).

[Bug fortran/35040] usage of init expression in its own definition

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

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

--- Comment #8 from janus at gcc dot gnu.org ---
Status:
 * both examples and comment 1 and some of comment 3 are being rejected since
quite some time (4.4 at least)
 * comment 0 and part of comment 3 is still (wrongly) accepted
 * comment 4 is (correctly) accepted