[Bug fortran/36771] New: Non-Standard addition for C_LOC and character strings

[Bug fortran/36771] New: Non-Standard addition for C_LOC and character strings

[brtnfld at hdfgroup dot org]

Would it be possible to implement the non-standard extension for a character
argument X in C_LOC(X) to have a LEN >1. Most if not all the current Fortran
compilers provide this extension and I think it would be useful for other users
of gfortran as well.

The feature would allow:

CHARACTER(LEN=80, KIND=C_CHAR), TARGET :: X
....
f_ptr = C_LOC(X)

or for an assumed size character in a subroutine:

CHARACTER(LEN=*, KIND=C_CHAR), TARGET :: X
....
f_ptr = C_LOC(X)

Thanks


-- 
           Summary: Non-Standard addition for C_LOC and character strings
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: brtnfld at hdfgroup dot org


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

[Bug fortran/36771] Non-Standard addition for C_LOC and character strings

[brtnfld at hdfgroup dot org]

------- Comment #1 from brtnfld at hdfgroup dot org  2008-07-14 20:45 -------
For the simple program,

PROGRAM main
  USE ISO_C_BINDING
  CHARACTER(LEN=2, KIND=C_CHAR), TARGET :: chr
  TYPE(C_PTR) :: chr_ptr
  chr_ptr = C_LOC(chr)
END PROGRAM main


the work around is to:
CHARACTER(LEN=1, KIND=C_CHAR), dimension(1:2), TARGET :: chr

However, forcing it to be an array instead of a character(LEN>1) causes
problems with generic interfaces. Take for example the following code which to
me looks to be standard compliant, via the standard the CHARACTER(LEN=4) actual
argument is allowed to match a CHARACTER(LEN=1,KIND=C_CHAR), DIMENSION(4) dummy
argument (12.4.1.2).
But the compiler will not recognize subroutine 'Two' as a valid interface for
the call indicated since the dimensions check is not satisfied even though it
is a valid interface. So if you are going by the standard you can not use a
generic interface to handle a scalar character (len>1) and an array of
characters (keeping in mind that all the subroutines have to have LEN=1 so that
you can use C_LOC).

MODULE modtest
  USE ISO_C_BINDING
  INTERFACE One
     MODULE PROCEDURE Two
  END INTERFACE
CONTAINS
  SUBROUTINE Two( chr )
    CHARACTER(LEN=1, KIND=C_CHAR), DIMENSION(1:4) :: chr
  END SUBROUTINE Two
END MODULE modtest

PROGRAM main
  USE ISO_C_BINDING
  USE modtest
  CHARACTER(LEN=4, KIND=C_CHAR) :: chrScalar
  chrScalar = 'Scal'
! This does not work, it will not find the interface.
  CALL One( chrScalar )
! This works
  CALL Two( chrScalar )
END PROGRAM main

It is simply not feasible to cast all character strings into character arrays.
This problem would all go away if we did not have to recast the string as an
array.


-- 


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

[Bug fortran/36771] Non-Standard addition for C_LOC and character strings

[burnus at gcc dot gnu dot org]

------- Comment #2 from burnus at gcc dot gnu dot org  2008-12-12 16:19 -------
I have the gut feeling that the program in comment 1 is valid, even though
gfortran, g95, ifort and NAG f95 reject it. See PR 38506.

Regarding the c_loc: I think that should be possible; I'm not 100% sure whether
there exists scenarios where it causes problems, but ad hoc I don't see any.

Patch:

--- resolve.c   (Revision 142706)
+++ resolve.c
@@ -2165,7 +2165,7 @@ gfc_iso_c_func_interface (gfc_symbol *sy
                       if (args_sym->attr.dimension != 0
                           && (args_sym->as && args_sym->as->rank == 0))
                         {
-                          gfc_error_now ("Allocatable variable '%s' used as a
"
+                          gfc_notify_std (GFC_STD_F2003, "Allocatable variable
'%s' used as a "
                                          "parameter to '%s' at %L must not be
"
                                          "an array of zero size",
                                          args_sym->name, sym->name,


-- 

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=36771

[Bug fortran/36771] Non-Standard addition for C_LOC and character strings

[burnus at gcc dot gnu dot org]

------- Comment #3 from burnus at gcc dot gnu dot org  2008-12-15 10:48 -------
I think the patch in comment 2 is about the wrong gfc_error.
Additionally, the generic resolution seems to be correct in gfortran (-> PR
38506).

 * * *

In any case: I tried ifort, g95, NAG f95, gfortran, and sunf95 - of these only
"ifort" allows it (even with all checking enabled - thus presumably only by
accident and not on purpose).

Thus I wonder whether simply using the following "evil" workaround is better
than patching the compiler:

  f_ptr = C_LOC(X(1:1))

That works with gfortran, ifort, g95 and NAG f95. (It fails with sunf95, whose
C interoperability is a bit shaky in general.) As the string should be
contiguous in memory it should be the OK. Additionally, that is also what one
would do in C:

  char X[40];
  ptr = &X; // or equivalently:  ptr = &X[0];


-- 


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

[Bug fortran/36771] Non-Standard addition for C_LOC and character strings

[brtnfld at hdfgroup dot org]

------- Comment #4 from brtnfld at hdfgroup dot org  2008-12-15 16:52 -------

> 
> In any case: I tried ifort, g95, NAG f95, gfortran, and sunf95 - of these only
> "ifort" allows it (even with all checking enabled - thus presumably only by
> accident and not on purpose).
> 
> Thus I wonder whether simply using the following "evil" workaround is better
> than patching the compiler:
> 
>   f_ptr = C_LOC(X(1:1))
> 
> That works with gfortran, ifort, g95 and NAG f95. (It fails with sunf95, whose
> C interoperability is a bit shaky in general.) As the string should be
> contiguous in memory it should be the OK. Additionally, that is also what one
> would do in C:
> 
>   char X[40];
>   ptr = &X; // or equivalently:  ptr = &X[0];

as you said using C_LOC(X(1:1)) works fine and that is what I ended up doing.
BTW, ifort 11 and pgf90 7.2-1 also allow C_LOC(X). But, while using X(1:1)
works fine in general, if I try to use it in a derived type gfortan (all
versions) it fails to compile with an internal error,

Internal Error at (1):
Unexpected expression reference type in gfc_iso_c_func_interface

for example:

MODULE modtest
  USE ISO_C_BINDING
  TYPE test
     CHARACTER(LEN=2), DIMENSION(1:2) :: c
     INTEGER(C_INT) :: i
  END TYPE test
END MODULE modtest

PROGRAM main
  USE ISO_C_BINDING
  USE modtest
  TYPE(test), TARGET :: chrScalar
  TYPE(C_PTR) :: f_ptr

  f_ptr = c_loc(chrScalar%c(1)(1:1))

END PROGRAM main

g95, ifort, and pgf90 all compile it. But this is maybe a separate issue.

Since there is a work around (in most cases) and according to the standard a
character must be length = 1 for X, I'm willing to withdrawal the request for
the enhancement.

As for the issue with the generic interface; none of the compilers can compile
the code so generic resolution does not seem to have been extended to allow
this behavior and it seems the requirement of matching Type, Kind and Rank
trumps all.


-- 


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

[Bug fortran/36771] Non-Standard addition for C_LOC and character strings

[burnus at gcc dot gnu dot org]

------- Comment #5 from burnus at gcc dot gnu dot org  2008-12-15 20:35 -------
(In reply to comment #4)
> > In any case: I tried ifort, g95, NAG f95, gfortran, and sunf95
> > - of these only "ifort" allows it
>
> as you said using C_LOC(X(1:1)) works fine and that is what I ended up doing.
> BTW, ifort 11 and pgf90 7.2-1 also allow C_LOC(X).

OK. Then I close this PR as WONTFIX.

> But, while using X(1:1) works fine in general, if I try to use it in a 
> derived type gfortan (all versions) it fails to compile with an internal
> error,

Filed as new PR 38536. Thanks a lot for finding and reporting this problem.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WONTFIX


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