itaps-parallel Fortran name mangling issues

Mark Miller miller86 at llnl.gov
Thu Nov 13 12:06:15 CST 2008 

Hello all,

By 'keep both options,' do you mean some software in the ITAPS suite
does it one way and some does it another? If so, my only comment is that
I think it is better for everything to become standardized.

I am certain I have yet to understand Onkar's proposed solution. I think
we each may have different underlying assumptions about the name
mangling issue.

At any rate, I am guessing it is a distraction from the important work
of preparing for SC tutorial. So, I think we can agree to re-visit the
issue in the near future.

Mark


On Thu, 2008-11-13 at 09:16, Tim Tautges wrote:
> Onkar Sahni wrote:
> > Thanks Tim for looking into it and Thanks Mark M. for brining this issue
> > in an organized way.
> > 
> > There are two further suggestions I want to mention:
> > 
> > a) If possible, we keep both options available (one where there is a
> > central place for headers and FCdefs, and other what we do now) or some
> > blend of it, so that user can choose.
> > 
> 
> I am in full support of this.
> 
> - tim
> 
> > b) We let some (selected) users try either one solution and get their
> > feedback, and go with one option accordingly.
> > 
> > Thanks,
> > Onkar
> > 
> >> Onkar,
> >>    I understand your suggested solution, and agree that it would work.
> >> I just don't think it's the best one when you consider all the use
> >> cases.  The advantage of your approach is that you're guaranteed to have
> >> all implementations/services agreeing on the name mangling and function
> >> signatures.  The disadvantage is that services and apps require an
> >> extra, independent process to build part of their iMesh-dependent code.
> >>   While this extra step isn't that difficult, it presents an extra
> >> burden on users and on service/impl'n developers.  Furthermore, there's
> >> an alternative solution that buys us almost the same thing while
> >> preserving independence.  The disadvantage of this alternative solution
> >> is something controlled by us and can be minimized.
> >>
> >> - tim
> >>
> >> Onkar Sahni wrote:
> >>> I think my point is being missed, here is my last attempt... if in case
> >>> of
> >>> MOAB "AC_CONFIG_HEADERS is called to produce MBCN_FCDefs.h" why not one
> >>> can produce "ITAPS_FCDefs.h" in a central place and one central
> >>> iMesh_protos.h includes ITAPS_FCDefs.h that is generated during as an
> >>> install/build process (all ITAPS header files can live in one location,
> >>> for example, /usr/local/itaps/headers).
> >>>
> >>> In summary, user/app. would do following basic steps:
> >>>
> >>> * Download itaps-headers (say in /<path-itaps-headers>/)
> >>> * Run configure to generate ITAPS_FCDefs.h in /<path-itaps-headers>/ (an
> >>> app./user would do this step with platform and compiler combination of
> >>> their choice)
> >>>
> >>> * Download any implementation/service (such as FMDB/MOAB/GRUMMP or
> >>> iZoltan)
> >>> * Run configure and compile it (point to /<path-itaps-headers>/ to get
> >>> header files from central place)
> >>>
> >>> * Write app. code like MHD solver
> >>> * Build it and link with appropriate libs. (ofcourse fortran name
> >>> mangling
> >>> has to be consistent while compling app. code with ITAPS_FCDefs.h
> >>> generated by app.)
> >>>
> >>> Is this not possible?
> >>>
> >>> - Onkar
> >>>
> >>>> On Wed, 2008-11-12 at 16:53 -0500, Onkar Sahni wrote:
> >>>>>> The FC_FUNC macro winds up getting defined by something; Autoconf's
> >>>>> configure script does some work to define it. Or, like Onkar suggests,
> >>>>> you can define some logic ahead of time to set whatever FC_FUNC does
> >>>>> using logic like so...
> >>>>>> #ifdef AIX
> >>>>>> #define FC_FUNC(lowFunc,UPfunc) _lowFunc
> >>>>>> #elif GFORTRAN
> >>>>>> #define FC_FUNC(lowFunc,UPfunc) UPfunc
> >>>>>> #elif ...
> >>>>>> ..
> >>>>>> .
> >>>>>   So here is my question (basically what I was trying to ask in
> >>>>> tele-con)
> >>>>> which may or may not be possible:
> >>>>>
> >>>>>   Can "#define FC_FUNC............" be generated in a central place
> >>>>> during
> >>>>> the process to install and build itaps softwares (before building any
> >>>> I don't think it can because its definition depends on the name
> >>>> mangling
> >>>> properties of the fortran compiler being used at time of
> >>>> (configuration)
> >>>> compilation. Yes, the number of possible definitions for FC_FUNC is
> >>>> finite, but know which it should be set to for a given compiler (and
> >>>> what to use in the way of a detecting that) varies from compiler to
> >>>> compiler. The BEST you can achieve is to identify what FC_FUNC should
> >>>> be
> >>>> identified for common cases or cases that you know of so that it
> >>>> doesn't
> >>>> need to be re-computed with each configure/compile.
> >>>>
> >>>>> implementation/library or service). This would be an extra configure
> >>>>> step in say /usr/local/itaps/headers (central location where all
> >>>>> headers
> >>>>> sit along with probably configure stuff) and this step would just
> >>>>> generate a new header file say "itaps_fc_func.h".
> >>>>> Say if one uses gfortran then the header file generated in "central"
> >>>>> place
> >>>>> (as an extra step using configure in "central" place) will contain
> >>>>> following lines and every service and implementation simply use it.
> >>>>>
> >>>>>   #ifndef _ITAPS_FC_FUNC_H_
> >>>>>   #define _ITAPS_FC_FUNC_H_
> >>>>>
> >>>>>   /* following line is for specific platform, compiler... combination
> >>>>> */
> >>>>>   #define FC_FUNC(lowFunc,UPfunc) UPfunc
> >>>>>
> >>>>>   #endif
> >>>>>
> >>>>> - Onkar
> >>>>>
> >>>>>> The only issue I see with this approach is that you need to have
> >>>>> defined
> >>>>> ahead of time all the possible #ifdef #elif cases above and whenever
> >>>>> you
> >>>>> go to a new machine, then you'll have to re-visit this logic. So, I
> >>>>> like
> >>>>> the approach where Autconf's configure is used to set FC_FUNC.
> >>>>>> Finally, whatever FC_FUNC is set to, it MUST match the actual name
> >>>>> mangling used by whatever fortran compiler is being used to compile
> >>>>> the
> >>>>> code. So, it is not just a matter of everyone agreeing on an
> >>>>>> implementation for FC_FUNC. FC_FUNC must also address whatever name
> >>>>> mangling is being used by a given fortran compiler on a given platform
> >>>>> when the code is getting compiled. For that reason, I think the best
> >>>>> approach is the Autoconf approach.
> >>>>>> Mark
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Mark C. Miller, Lawrence Livermore National Laboratory
> >>>>>> email: mailto:miller86 at llnl.gov
> >>>>>> (M/T/W) (925)-423-5901 (!!LLNL BUSINESS ONLY!!)
> >>>>>> (Th/F)  (530)-753-8511 (!!LLNL BUSINESS ONLY!!)
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>> --
> >>>> Mark C. Miller, Lawrence Livermore National Laboratory
> >>>> email: mailto:miller86 at llnl.gov
> >>>> (M/T/W) (925)-423-5901 (!!LLNL BUSINESS ONLY!!)
> >>>> (Th/F)  (530)-753-8511 (!!LLNL BUSINESS ONLY!!)
> >>>>
> >>>>
> >>>
> >>>
> >> --
> >> ================================================================
> >> "You will keep in perfect peace him whose mind is
> >>    steadfast, because he trusts in you."               Isaiah 26:3
> >>
> >>               Tim Tautges            Argonne National Laboratory
> >>           (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
> >>           phone: (608) 263-8485      1500 Engineering Dr.
> >>             fax: (608) 263-4499      Madison, WI 53706
> >>
> >>
> > 
> > 
> > 
-- 
Mark C. Miller, Lawrence Livermore National Laboratory
email: mailto:miller86 at llnl.gov
(M/T/W) (925)-423-5901 (!!LLNL BUSINESS ONLY!!)
(Th/F)  (530)-753-8511 (!!LLNL BUSINESS ONLY!!)

More information about the itaps-parallel mailing list