Please feel free to do so, George, as far as I'm concerned. I will modify the ORTE code in anticipation of it by removing the arch-related calls. Should have that for you later today or tomorrow.
If it doesn't move, no harm done - like I said, I really don't need it any more, but was suggesting the move only to finally clear that abstraction break we all hated when I originally did it (apologies in hindsight). :-) On Tue, Jun 2, 2009 at 9:45 AM, George Bosilca <bosi...@eecs.utk.edu> wrote: > The datatype engine (where the arch code was originally from), needs a way > to describe the architectures in order to know how to convert the data. > Therefore I will advocate the return of the opal/util/arch.h back in the > datatype. > > george. > > > On Jun 2, 2009, at 07:24 , Rainer Keller wrote: > > Hi Jeff, >> no, that's not an issue. The comment is correct: For any Fortran >> integer*kind >> we need to have _some_ C-representation as well, otherwise we disregard >> the >> type (tm), see e.g. the old and resolved ticket #1094. >> The representation chosen is set in opal/util/arch.c and is conclusive as >> far >> as I can tell... >> >> We do however still have a buglet with FCFLAGS='-i8 -r16', but that's with >> our >> internal storage of [cdw]_f_to_c_index, so it's a different issue (ticket >> #1812). >> >> CU, >> Rainer >> >> PS: I especially like the comment in opal/util/arch.c ;-): >> /* sizeof fortran logical >> * >> * RHC: technically, use of the ompi_ prefix is >> * an abstraction violation. However, this is actually >> * an error in our configure scripts that transcends >> * all the data types and eventually should be fixed. >> * The guilty part is f77_check.m4. Fixing it right >> * now is beyond a reasonable scope - this comment is >> * placed here to explain the abstraction break and >> * indicate that it will eventually be fixed >> */ >> >> >> >> On Tuesday 02 June 2009 09:57:46 am Jeff Squyres wrote: >> >>> On Jun 2, 2009, at 9:08 AM, Rainer Keller wrote: >>> >>>> Rainer -- is it safe for Ralph to move the arch.c stuff back up into >>>>> OMPI, or will that conflict with your stuff? >>>>> >>>> >>>> Yes, we use it. >>>> Please leave it at the OPAL layer. We need a way to describe and >>>> store the >>>> remote architecture at the OPAL layer. >>>> >>> >>> Question about the fortran stuff in opal/util/arch.c... >>> >>> I see the following comment: >>> >>> ** The fortran integer is dismissed here, since there is no >>> ** platform known to me, were fortran and C-integer do not match >>> >>> You can tell the intel compiler (and maybe others?) to compile fortran >>> with double-sized integers and reals. Are we disregarding this? >>> I.e., does this make this portion of the datatype heterogeneity >>> detection incorrect? >>> >> >> -- >> ------------------------------------------------------------------------ >> Rainer Keller, PhD Tel: +1 (865) 241-6293 >> Oak Ridge National Lab Fax: +1 (865) 241-4811 >> PO Box 2008 MS 6164 Email: kel...@ornl.gov >> Oak Ridge, TN 37831-2008 AIM/Skype: rusraink >> >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel >
