(j3.2006) binding labels and global identifiers

[Craig Dedo]

Everyone:
	I ran this program with GFortran 4.7.0 and Intel Visual Fortran 11.1.048, both
under Windows Vista SP2.

	GFortran failed to link.  It gave an error message,
"C:\DEV\Low_Line_Test\GFortran/Low_Line_Test.f03:2: undefined reference to `subr'
collect2: ld returned 1 exit status"

	Intel Visual Fortran for Windows succeeded in building the executable.  The
resulting program gave the correct answer of "0.1000000".

	I also would like to reply to Jim Xia's comments that he made in a separate reply.
He said, "Naming schemes (or name mangling) fall out of the scope of the standard as I see
it.  It is the programmers' responsibility to avoid duplicate global names."

	I disagree with Jim Xia.  The standard speaks in terms of a "processor".  A
"processor" is defined in section 1.3.113 as, "combination of computing system and
mechanism by which programs are transformed for use on that computing system".  This
definition includes not only the Fortran compiler but also other components such as the
linker, run time libraries, etc.

	Thus, my answer to Robert Corbett's original question is:  Yes, this program is
intended to be standard-conforming.

	The root cause of the problem is that the Fortran processors that have this
problem are generating external names that are different from the names used in the
Fortran program but these generated names are still legal names in Fortran or C or both.
Such a name-generation practice is likely to run into the kinds of conflicts reported in
this example.

	As Bill hinted, I would recommend that the Fortran processors that have this
problem change their external name generation rule to generate names for the linker that
are known to be illegal in Fortran and C.  Either that or don't change the name at all.


Sincerely,
Craig T. Dedo
17130 W. Burleigh Place
P. O. Box 423                  Mobile Phone:  (414) 412-5869
Brookfield, WI   53008-0423    E-mail:  <craig at ctdedo.com>
USA
Linked-In:  http://www.linkedin.com/in/craigdedo

> -----Original Message-----
> From: j3-bounces at j3-fortran.org [mailto:j3-bounces at j3-fortran.org] On Behalf Of
> Bill Long
> Sent: Tuesday, June 14, 2011 07:29
> To: j3 at j3-fortran.org
> Subject: Re: (j3.2006) binding labels and global identifiers
> 
> 
> 
> On 6/14/11 5:28 AM, Robert Corbett wrote:
> > One of Oracle's other engineers working on Fortran raised
> > a question regarding conflicting binding labels and global
> > identifiers (see Clause 16.2 of 10-007r1).  He pointed out
> > that many Fortran implementations, including Oracle's,
> > construct the linker name for an external procedure or
> > common block by adding a low line to the end of the global
> > name of the procedure or common block.  Consider the
> > following program:
> >
> >        MODULE variables
> >          USE ISO_C_BINDING
> >          PRIVATE
> >          PUBLIC x
> >          REAL, BIND(C, NAME="subr_") :: x = 0.1
> >        END
> >
> >        SUBROUTINE subr
> >          USE variables
> >          PRINT *, x
> >        END
> >
> >        PROGRAM main
> >          CALL subr
> >        END
> >
> > This program caused a problem for every implementation I
> > tried.  I was amused that it failed in a different way for
> > each implementation.  Nonetheless, the program does not
> > appear to violate the requirements set out in Clause 16.2.
> > The global identifier "subr" and the binding label "subr_"
> > are different according to the language of Clause 16.2.
> >
> > Is the program presented above intended to be standard-
> > conforming?  Implementations could easily be made to handle
> > the program by using a different mapping of global names to
> > linker names.  Making such a change might break backward
> > compatibility.
> >
> 
> I also got 5/5 failures with the compilers I tried.  Choosing a
> different name mangling scheme would help only if the Fortran-generated
> linker names contained characters that made them illegal as names in C,
> but still legal to the linker.   While solving this problem, it would
> upset assumptions made in legacy codes from the pre-interop era that
> were written based on the old trailing underscore convention.  Granted
> that there is a better and more portable way of accomplishing C
> interoperability now.  But such a  solution will probably require a
> compiler switch to recover the old name mangling scheme.
> 
> Cheers,
> Bill
> 
> 
> > Robert Corbett
> > _______________________________________________
> > J3 mailing list
> > J3 at j3-fortran.org
> > http://j3-fortran.org/mailman/listinfo/j3
> 
> --
> Bill Long                                           longb at cray.com
> Fortran Technical Support    &                 voice: 651-605-9024
> Bioinformatics Software Development            fax:   651-605-9142
> Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101
>