[Bug fortran/49509] New: cannot promote types for arguments passed by value

[Bug fortran/49509] New: cannot promote types for arguments passed by value

[stevenj at alum dot mit.edu]

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

           Summary: cannot promote types for arguments passed by value
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: stevenj@alum.mit.edu


Compile the following test program gfortran, which is a toy example of
iso_c_binding that calls malloc(3).

  program bug

  use, intrinsic :: iso_c_binding
  implicit none
  interface
     type(C_PTR) function malloc(n) bind(C, name='malloc')
       import
       integer(C_SIZE_T), value :: n
     end function malloc
  end interface

  integer, parameter :: n = 3
  integer(C_SIZE_T) sz
  type(C_PTR) p
  p = malloc(n)  ! compiler error, cannot promote argument passed by value
  sz = n         ! ... whereas assignment succeeds
  p = malloc(sz)

  end program bug

I obtain the following error:

  promote.f03:15.13:

    p = malloc(n) ! compiler error, cannot promote argument type
               1
  Error: Type mismatch in argument 'n' at (1); passed INTEGER(4) to INTEGER(8)

(Similarly with older versions of gcc.)  Note that "n" is passed by value, so
my understanding is that this should act much like the assignment sz = n (which
succeeds): gfortran should automatically promote n to a size_t, like any other
assignment of a narrower type to a wider type.

Please consider applying the same type-promotion rules that are used for
assignments to passing arguments by value.  (I don't have the Fortran 2003
standard handy, but it is hard to believe that the two situations should be
treated differently.)

[Bug fortran/49509] cannot promote types for arguments passed by value

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

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

--- Comment #1 from kargl at gcc dot gnu.org 2011-06-23 02:10:32 UTC ---
I believe your code is simply invalid on some targets.

You need to change
  integer, parameter :: n = 3
to
  integer(c_size_t), parameter :: n = 3

The matching of type, kind, and rank of actual
and dummy argument is a requirement of the Fortran
standard.  This requirement is placed on the 
programmer.  What you want is explicitly prohibited
by the standard.

12.4.1.2 Actual arguments associated with dummy data objects

If a dummy argument is neither allocatable nor a pointer,
it shall be type compatible (5.1.1.2) with the associated
actual argument.

The type parameter values of the actual argument shall agree
with the corresponding ones of the dummy argument that are
not assumed or deferred, except for the case of the character
length parameter of an actual argument of type default character
associated with a dummy argument that is not assumed shape.

This should probably be closed as WONTFIX, but I'll let 
other gfortran maintainers weigh in on the subject.

[Bug fortran/49509] cannot promote types for arguments passed by value

[stevenj at alum dot mit.edu]

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

--- Comment #2 from stevenj at alum dot mit.edu 2011-06-23 02:54:50 UTC ---
You're missing the point.  Traditionally in Fortran, all arguments were passed
*by reference*, in which case it is clearly a requirement that actual parameter
match the formal parameter's type exactly, because the formal parameter refers
to the *same memory* as the actual parameter.

However, in this case we are passing by value.  This should act just like an
assignment of the formal parameter to the actual parameter (as opposed to
having them be the *same* object as in passing by reference).  Hence, just like
an assignment statement the compiler should be able to assign a narrower
integer type to a wider one.

Hence, the familiar old requirements of the Fortran standard are irrelevant.
The question is, what does the Fortran 2003 standard require for passing by
value, which is I believe is NEW IN FORTRAN 2003, and is SPECIFIC TO BIND(C)
functions.

[Bug fortran/49509] cannot promote types for arguments passed by value

[stevenj at alum dot mit.edu]

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

--- Comment #3 from stevenj at alum dot mit.edu 2011-06-23 03:00:47 UTC ---
> Hence, the familiar old requirements of the Fortran standard are irrelevant.
> The question is, what does the Fortran 2003 standard require for passing by
> value, which is I believe is NEW IN FORTRAN 2003, and is SPECIFIC TO BIND(C)
> functions.

Just checked, and the VALUE attribute it is indeed new in Fortran 2003, but it
is not specific to bind(C).

But the point remains that your usual understanding of Fortran semantics does
not apply here.

[Bug fortran/49509] cannot promote types for arguments passed by value

[stevenj at alum dot mit.edu]

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

--- Comment #4 from stevenj at alum dot mit.edu 2011-06-23 03:23:06 UTC ---
Section 12.4.1.2 of Fortran 2003 standard:
"If the dummy argument has the VALUE attribute it becomes associated with a
definable anonymous data object whose initial value is that of the actual
argument."

Furthermore, NOTE 12.22 says:
"If the VALUE attribute is specified, the effect is as if the actual argument
is assigned to a temporary, and the temporary is then argument associated with
the dummy argument.  The actual mechanism by which this happens is determined
by the processor."

Thus, if you have a subroutine foo(x) with T, VALUE :: X, then the standard
requires that 

      call foo(y)

have the same "effect as if" you did

     T :: temp
     temp = y
     call foo(temp)

with pass by reference.  But in that case, it would be valid to assign y to a
wider type T.

This implicitly contravenes the wording earlier in the section that the dummy
and actual argument be "type compatible (5.1.1.2)".   It is unfortunate that it
is not explicit on this point, however -- one could argue that there is a bug
in the standard here.

[Bug fortran/49509] cannot promote types for arguments passed by value

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-06-23 04:01:49 UTC ---
On Thu, Jun 23, 2011 at 02:55:20AM +0000, stevenj at alum dot mit.edu wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49509
> 
> --- Comment #2 from stevenj at alum dot mit.edu 2011-06-23 02:54:50 UTC ---
> You're missing the point.

Ah, no.  I believe I understand what you want.

> Traditionally in Fortran, all arguments were passed *by reference*,
> in which case it is clearly a requirement that actual parameter
> match the formal parameter's type exactly, because the formal parameter refers
> to the *same memory* as the actual parameter.

Traditionally, the standard was silent on the passing
mechanism.  It could have been accomplished by chipmunks.

> However, in this case we are passing by value.  This should act
> just like an assignment of the formal parameter to the actual
> parameter (as opposed to having them be the *same* object as
> in passing by reference).  Hence, just like an assignment statement
> the compiler should be able to assign a narrower
> integer type to a wider one.

That's not what the standard mandates.

[Bug fortran/49509] cannot promote types for arguments passed by value

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-06-23 04:02:38 UTC ---
On Thu, Jun 23, 2011 at 03:01:04AM +0000, stevenj at alum dot mit.edu wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49509
> 
> --- Comment #3 from stevenj at alum dot mit.edu 2011-06-23 03:00:47 UTC ---
> > Hence, the familiar old requirements of the Fortran standard are irrelevant.
> > The question is, what does the Fortran 2003 standard require for passing by
> > value, which is I believe is NEW IN FORTRAN 2003, and is SPECIFIC TO BIND(C)
> > functions.
> 
> Just checked, and the VALUE attribute it is indeed new in Fortran 2003, but it
> is not specific to bind(C).
> 
> But the point remains that your usual understanding of Fortran semantics does
> not apply here.
> 

Sorry, but I believe the semantics do apply.

I already fixed your toy code.

[Bug fortran/49509] cannot promote types for arguments passed by value

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-06-23 04:13:49 UTC ---
On Thu, Jun 23, 2011 at 03:23:26AM +0000, stevenj at alum dot mit.edu wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49509
> 
> --- Comment #4 from stevenj at alum dot mit.edu 2011-06-23 03:23:06 UTC ---
> Section 12.4.1.2 of Fortran 2003 standard:
> "If the dummy argument has the VALUE attribute it becomes associated with a
> definable anonymous data object whose initial value is that of the actual
> argument."

I believe you are misintrepreting the meaning of "defineable
anonymous data object".  This does not mean that TKR does 
not apply.  It means, well, the data object is definable
and it is anonymous to the calling procedure.  That is, the
calling procedure has no means to getting at anything that
might affect the value of the dummy argument.


> Furthermore, NOTE 12.22 says:

NOTEs in the standard are non-normative text.

> "If the VALUE attribute is specified, the effect is as if the actual argument
> is assigned to a temporary, and the temporary is then argument associated with
> the dummy argument.  The actual mechanism by which this happens is determined
> by the processor."

This note does not remove the requirement of TKR.

> It is unfortunate that it  is not explicit on this point,
> however -- one could argue that there is a bug in the
> standard here.

Feel free to post to comp.lang.c about the issue.  The
technical editor of F2003 routinely answers questions 
about the standard as do others who are current members
of J3 or former members of J3.

[Bug fortran/49509] cannot promote types for arguments passed by value

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-06-23 04:22:51 UTC ---
On Wed, Jun 22, 2011 at 09:13:19PM -0700, Steve Kargl wrote:
> 
> Feel free to post to comp.lang.c about the issue.  The
> technical editor of F2003 routinely answers questions 
> about the standard as do others who are current members
> of J3 or former members of J3.
> 

Dang.  That should have been comp.lang.fortran.

[Bug fortran/49509] cannot promote types for arguments passed by value

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

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

--- Comment #9 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-06-23 16:06:24 UTC ---
Cf.
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/b0ffeb2f0d07d7a7#

[Bug fortran/49509] cannot promote types for arguments passed by value

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |tkoenig at gcc dot gnu.org
         Resolution|                            |INVALID

--- Comment #10 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2011-08-06 21:08:56 UTC ---
I think the c.l.f discussion shows that this is not allowed in
Fortran.

Closing.