[Fortran-Experiments]: patch for error checking on binding labels and derived types, etc.

Tobias Burnus burnus@net-b.de
Tue Feb 27 13:49:00 GMT 2007


Hi Chris, hi all,

(more to your patch below)

First, I checked in my symbol patch (r122363):

-   conf (is_bind_c, dummy);
+   if (!function && !subroutine)
+     conf (is_bind_c, dummy);


I didn't add a test case yet, because there is one missing warning and
one wrong warning:
-----------------------------------
! { dg-do "compile" }
! Dummy arguments which are functions are allowed to have
! the Bind(c) flag set.

MODULE OpenGL_glut
IMPLICIT NONE

! Notes:
! (1) gives the wrong warning: "Variable 'func' is a parameter to the
!     BIND(C) procedure 'glutcreatemenu' but may not be C interoperable"
! (2) gives no warning although integer has no C interop. kind.

INTERFACE
  FUNCTION glutCreateMenu(func) BIND(C,NAME="glutCreateMenu")
    use iso_c_binding   ! ^^^^<<<<< (1)
    INTEGER :: glutCreateMenu   ! <<<<<<<< (2)
    INTERFACE                   ! The dummy argument 'func'
      SUBROUTINE func() BIND(C) ! is allowed to have the bind(c) flag set
      END SUBROUTINE func
    END INTERFACE
  END FUNCTION glutCreateMenu
END INTERFACE
END MODULE OpenGL_glut

! { dg-final { cleanup-modules "OpenGL_glut" } }
-----------------------------------


Secondly, I checked in the gfc_add_is_bind_c  name-argument patch, r122364.
http://gcc.gnu.org/ml/fortran/2007-02/msg00594.html


Christopher D. Rickett wrote:
> the attached patch includes: bootstrapped and regtested on x86 with no
> new failures.
Thanks. It build and regtested successfully on x86_64/openSUSE 10.2.
The patch looks also right, though I have not done much testing, yet.

Let's wait for the ok of Steve.
Chris, can you already commit the changes yourself?


Comments:

+++ gcc/fortran/decl.c  (working copy)
+     they're inteoperable if they're BIND(C) and they're params are all

Spelling: interoperable.


+          /* If it is a BIND(C) function, make sure the return value is a
+             scalar value.  The previous tests in this function made sure
+             the type is interoperable.  */

My feeling is that you check previously only for dummy arguments not for
return values. (This would at least explain why the test case above
gives no warning.)

+            gfc_error ("Return type of BIND(C) FUNCTION '%s' at %L cannot "
and
+              gfc_error ("Return type of BIND(C) FUNCTION '%s' at %L
cannot "

Not-capitalizing the word "function" ?

(By the way, I think some of the spaces should be replaced by tabs in
and around these lines)


+      /* TODO: If the name= was given and no binding label (name=""),
we simply
+         will let fortran mangle the symbol name as it usually would.
+         However, this could still let C call it if the user looked up the
+         symbol in the object file.  Should the name set during mangling in
+         trans-decl.c be marked with characters that are invalid for C to
+         prevent this?  */

I think mangling is the wrong approach. Simply not creating the symbol
name from the subroutine is enough.

The idea is not to make it impossible for C to call these functions, but
to prevent symbol-name clashes. Example:
-----------------------------------
module one
contains
  subroutine foo() bind(c)
  end subroutine foo
end module one

module two
contains
  ! This procedure is only used accessed in C
  ! as procedural pointer
  subroutine foo() bind(c, name="")
  end subroutine foo
end module two

use one, only: foo_one => foo
use two, only: foo_two => foo
end
-----------------------------------

Thus the name="" merely ensures that there are no two functions with the
name "foo" and instead of coming up with some clever name
name="_my_function_foo_not_to_be_called_directly", a simple name="" can
be used.

By the way, the example above does not work in gfortran:

bar.f90:14.29:
use two, only: foo_two => foo
                            1
bar.f90:3.16:
  subroutine foo() bind(c)
               2
Error: Binding label 'foo' at (1) collides with the global entity 'foo'
at (2)


+++ gcc/testsuite/gfortran.dg/binding_label_tests_10_main.f03

You should add
! { dg-final { cleanup-modules "binding_label_tests_10_main
binding_label_tests_10" } }
to delete the created "binding_label_tests_10_main.mod" and
binding_label_tests_10.mod files afterwards.

+++ gcc/testsuite/gfortran.dg/bind_c_usage_7.f03
Ditto for "x"

+++ gcc/testsuite/gfortran.dg/binding_label_tests_11_main.f03
Ditto for "binding_label_tests_11_main"  / binding_label_tests_11.f03

+++ gcc/testsuite/gfortran.dg/binding_label_tests_10.f03
Add a comment that "binding_label_tests_10.mod" should not be deleted
since it is will be used by binding_label_tests_10_main.f03.

Ditto for the file binding_label_tests_11.f03

+++ gcc/testsuite/gfortran.dg/bind_c_dts_4.f03
Delete test.mod

+++ gcc/testsuite/gfortran.dg/binding_label_tests_9.f03
And x.mod

Tobias



More information about the Fortran mailing list