Per the MPI_Flogical issue -- I think Rainer just exposed some old
ugliness. We've apparently had MPI_Flogical defined in
ompi_config.h.in for a long, long time -- we used it in some places
and used ompi_fortran_logical_t in other places.
Even though I *may* be responsible for this particular bit of ugliness
way back in the past :-), I think the #define for MPI_Flogical should
be removed if for no other reason than 6-12 months from now when
someone else re-discovers it, they'll have to go lookup to see if it's
a real MPI type -- which it's not. Even though it's longer, we should
use ompi_fortran_logical_t everywhere.
My $0.02.
On Jun 1, 2009, at 1:23 PM, Brian W. Barrett wrote:
Well, this may just be another sign that the push of the DDT to OPAL
is a
bad idea. That's been my opinion from the start, so I'm biased.
But OPAL
was intended to be single process systems portability, not MPI crud.
Brian
On Mon, 1 Jun 2009, Rainer Keller wrote:
> Hmm, OK, I see.
> However, I do see potentially a problem with work getting ddt on
the OPAL
> layer when we do have a fortran compiler with different alignment
requirements
> for the same-sized basic types...
>
> As far as I understand the OPAL layer to abstract away from
underlying system
> portability, libc-quirks, and compiler information.
>
> But I am perfectly fine with reverting this!
> Let's discuss, maybe phone?
>
> Thanks,
> Rainer
>
>
> On Monday 01 June 2009 10:38:51 am Jeff Squyres wrote:
>> Hmm. I'm not sure that I like this commit.
>>
>> George, Brian, and I specifically kept Fortran out of (the non-
>> generated code in) opal because the MPI layer is the *only* layer
that
>> uses Fortran. There was one or two minor abstraction breaks (you
>> cited opal/util/arch.c), but now we have Fortran all throughout
Opal.
>> Hmmm... :-\
>>
>> Is MPI_Flogical a real type? I don't see it defined in the MPI-2.2
>> latex sources, but I could be missing it. I *thought* we used
>> ompi_fortran_logical_t internally because there was no officially
>> sanctioned MPI_<foo> type for it...?
--
Jeff Squyres
Cisco Systems
