Bug 59411 - [F03] Problem with TYPE(C_PTR) constant initialization
[F03] Problem with TYPE(C_PTR) constant initialization
Status: NEW
Product: gcc
Classification: Unclassified
Component: fortran
4.9.0
: P3 normal
: ---
Assigned To: Not yet assigned to anyone
: rejects-valid
Depends on:
Blocks: 32630
  Show dependency treegraph
 
Reported: 2013-12-06 16:39 UTC by mrestelli
Modified: 2013-12-18 12:32 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2013-12-18 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mrestelli 2013-12-06 16:39:32 UTC
Hi all,
   the attached code does not compile:

gfortran -c cst.f90 
cst.f90:6.31:

 type(c_ptr), parameter :: p2 = pp
                               1
Error: non-constant initialization expression at (1)

However, as far as I can tell, the code is correct (ifort accepts it).


gfortran --version
GNU Fortran (GCC) 4.9.0 20130813 (experimental)



module m
 use iso_c_binding
 implicit none

 type(c_ptr), parameter :: pp = c_null_ptr ! this works
 type(c_ptr), parameter :: p2 = pp         ! this doesn't work

end module m
Comment 1 janus 2013-12-07 16:29:34 UTC
(In reply to mrestelli from comment #0)
> 
>  type(c_ptr), parameter :: p2 = pp
>                                1
> Error: non-constant initialization expression at (1)
> 
> However, as far as I can tell, the code is correct (ifort accepts it).

well, just because ifort accepts it doesn't mean that it's valid.

In fact the corresponing case with actual Fortran pointers (i.e. pointer initialization) is only allowed since F08, cf. PR45290. One should check the Fortran standard for restrictions in the case of C_PTRs (which, strictly speaking, are no actual pointers in the Fortran sense).
Comment 2 janus 2013-12-07 16:37:17 UTC
(In reply to janus from comment #1)
> One should check the
> Fortran standard for restrictions in the case of C_PTRs (which, strictly
> speaking, are no actual pointers in the Fortran sense).

Since C_PTR is a derived type in the Fortran sense, I don't see why any restrictions on pointer init should apply.

Unless there are any special restrictions for C_PTR, the code should be valid, just as the corresponding code with any other derived type:


module m
 implicit none

 type :: t
 end type

 type(t), parameter :: pp = t()
 type(t), parameter :: p2 = pp

end module m
Comment 3 janus 2013-12-07 17:12:39 UTC
In F03, I think the relevant quotes are:

R506 initialization is = initialization-expr
                    or => null-init

7.1.7 Initialization expression
An initialization expression is an expression with limitations that make it suitable for use as a kind type parameter, initializer, or named constant. It is an expression in which each operation is intrinsic, and each primary is
(1) A constant or subobject of a constant,
...


Since pp is clearly a constant, the code should be valid (probably also in F08).
Comment 4 mrestelli 2013-12-09 08:09:09 UTC
(In reply to janus from comment #1)
> (In reply to mrestelli from comment #0)
> > 
> >  type(c_ptr), parameter :: p2 = pp
> >                                1
> > Error: non-constant initialization expression at (1)
> > 
> > However, as far as I can tell, the code is correct (ifort accepts it).
> 
> well, just because ifort accepts it doesn't mean that it's valid.

Janus, yes, of course you are right, what I wanted to say was that the
code seems fine according to my understanding of what "should happen",
and for what is worth also ifort is happy with it. But I see that my
sentence was not clear.

Thank you for checking the relevant text in the standard, and also for
the nice example

type(t), parameter :: pp = suitable_initialization_expr_for_type_t
type(t), parameter :: p2 = pp

I would assume that, provided the first assignment is correct, the
second one is always correct, whatever the definition of type(t). Am I
right?

Marco
Comment 5 janus 2013-12-09 09:58:10 UTC
(In reply to mrestelli from comment #4)
> type(t), parameter :: pp = suitable_initialization_expr_for_type_t
> type(t), parameter :: p2 = pp
> 
> I would assume that, provided the first assignment is correct, the
> second one is always correct, whatever the definition of type(t). Am I
> right?

I would think so. It is important, though, that pp is a PARAMETER.
Comment 6 Dominique d'Humieres 2013-12-18 12:32:51 UTC
Confirmed at r206083.