[Fortran-Experiments]: patch

[Christopher D. Rickett]

On Mon, 26 Feb 2007, Tobias Burnus wrote:

> Hello Chris, hi all,
>
> Christopher D. Rickett wrote:
>> i've attached another patch for the fortran-experiments branch.  it
>> contains quite a bit of whitespace fixes and new test cases.  it also has
>> improved error messages for a few things and new error checking on binding
>> labels.  it also fixes some minor bugs, such as c_size_t and the required
>> parens for subroutines marked with bind(c).  bootstrapped and regtested on
>> x86 with no new failures.
>>
> I applied it, build it (but did not bootstrap), tested it a bit, skimmed
> the patch itself and regtested it on x86-64/openSUSE 10.2 with no
> failures (but the old c_int_fast*_t in c_kind_params.f90).
>
> Thanks for all those fixes. Steve, is this patch ok for the
> fortran-experiments branch? If yes, I'd like to check it in.
>
> Tobias
>
>
> PS: Just to keep track myself:
>
> - nested interfaces do not work yet,
> http://gcc.gnu.org/ml/fortran/2007-02/msg00535.html

did you apply your proposed patch for bind(c) dummy procedures?  if so, my 
next patch (which i'm holding on to until the one from Saturday gets 
committed) should finish fixing these.

>
> - gfortran rejects bind(c,name=""),
> http://gcc.gnu.org/ml/fortran/2007-02/msg00505.html (b)

should work with the patch i'm waiting to submit.  now i simply let 
gfortran mangle the symbol as normal if the binding label was "".  we 
could further improve this by adding some sort of character that is 
invalid for C names just to ensure the C programmer can't call it by it's 
mangled name either.  i also issue a warning for private symbols that have 
been given a binding label (this was proposed in one of Tobias' emails and 
seemed like a good idea).

>
> - gfortran allows functions to return an array,
> http://gcc.gnu.org/ml/fortran/2007-02/msg00505.html (c)

this is fixed in the patch i'm holding.  i also added a check to ensure 
character strings aren't returned, since i hadn't checked for that either. 
apologies for the obvious oversites.

>
> - Same error is printed twice,
> http://gcc.gnu.org/ml/fortran/2007-02/msg00496.html

this should be also be fixed in the patch i'm holding.  the problem was 
that i had not moved all of the error checking for BIND(C) to the resolve 
stage.  i was still verifying the derived types after matching them. 
however, i now do it during resolution only.

>
> - bind_c symbol collision:
> ----------- 1.f90--------
> module x
>  use iso_c_binding
>  implicit none
>  integer(c_int), bind(c,name="c_one") :: one
> end module x
> ---------------------------
> ----------- 2.f90--------
> module y
>  use iso_c_binding
>  implicit none
>  integer(c_int), bind(c,name="c_one") :: one
> end module y
>
> program main
>  use x
>  use y
> end program main
> ---------------------------
> Does compile with gfortran, but NAG f95 outputs:
>  Error: 2.f90: Duplicate binding label 'c_one' for variable ONE of
> module Y and variable ONE of module X
> On the other hand, neither g95, sunf95 nor ifort 10 give a compile-time
> error/warning.
>

hmm, i thought that this should have been fixed with my last patch. 
either way, my current local gfortran reports the following:

tobias4.f03:10.44:

  integer(c_int), bind(c,name="c_one") :: one
                                            1
tobias4.f03:4.44:

  integer(c_int), bind(c,name="c_one") :: one
                                            2
Error: Binding label 'c_one' at (1) collides with global entity 'c_one' at 
(2)
tobias4.f03:15.6:

  use y
      1
Fatal Error: Can't open module file 'y.mod' for reading at (1): No such 
file or directory

is that acceptable?  in your copy Tobias, do you have a function called 
gfc_verify_binding_labels?  if you do, then i'm not sure why the above 
code isn't getting reported as an error.

again, i'll submit my next patch once the one from Feb. 24 has been 
committed to make things easier.

Chris