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 <bosilca_at_[hidden]> 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
> 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
>> we need to have _some_ C-representation as well, otherwise we disregard
>> 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
>> as I can tell...
>> We do however still have a buglet with FCFLAGS='-i8 -r16', but that's with
>> internal storage of [cdw]_f_to_c_index, so it's a different issue (ticket
>> 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: keller_at_[hidden]
>> Oak Ridge, TN 37831-2008 AIM/Skype: rusraink
>> devel mailing list
> devel mailing list