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

Christopher D. Rickett crickett@lanl.gov
Wed Feb 28 20:03:00 GMT 2007


hi all,

has anyone had a chance to look over this patch yet?

Chris

On Tue, 27 Feb 2007, Tobias Burnus wrote:

> Hi,
>
> Christopher D. Rickett wrote:
>>> Let's wait for the ok of Steve.
> *ping*  ;-)
>
>>> +++ gcc/fortran/decl.c  (working copy)
>>> +     they're inteoperable if they're BIND(C) and they're params are all
>>>
>>> Spelling: interoperable.
>> oops.  i also think the third "they're" is wrong; it should be
>> "their". i'll fix those in my copy.  do you want me to send another
>> patch, or did you want to fix this?
> I can do the "interoperable", "their", "FUNCTION" and  "! { dg-final {
> cleanup-modules "  changes. The rest I leave to your next round of patches.
>
>
>>> +            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" ?
>>
>> i can lower-case the "FUNCTION".  i had put it as all-caps simply
>> because it was a token and i started doing all caps for other things,
>> like BIND(C).
> For me "BIND(C) FUNCTION" looks as it is put in in one block rather than
> as "FUNCTION name() BIND(C)", besides I think it looks too cluttered if
> too many words are capitalized. However, I do think BIND(C) should
> remain capitalized as it is both important in this sentence and it is a
> token.
>
>>> I think mangling is the wrong approach. Simply not creating the symbol
>>> name from the subroutine is enough.
>>
>> what name should it be given for fortran to generate the symbol in the
>> object file?  right now, with name="", i let fortran do what it
>> normally would do.  is that acceptable?  that should prevent two
>> functions from appearing with the same name "foo" i think.
> That was my idea.
>
> For completeness, gfortran currently calls module procedures
>   __<module name>__<procedure name>
> and procedures outside modules
>  <procedure name>_
> Special are procedures which are contained in the PROGRAM, they appear
> e.g. as  <procedure name>.1351   and are local symbols.
>
>
>> the binding label verification definitely doesn't seem like the
>> easiest thing to enforce.
> Indeed. For the Fortran part, it took quite long until we get it work
> reasonably well. (Especially the part: When is a symbol ambiguous? We
> probably have some still some bugs there - as have the other compilers.)
>
> Tobias
>



More information about the Fortran mailing list