This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [OT] cure for nasty #ifdef's?


On May 24 2012, Toon Moene wrote:
On 05/24/2012 01:43 PM, Salvatore Filippone wrote:

One annoying case is when you start mixing up parameters for KINDs in
various data types with MPI calls....

Why do you think we wanted coarrays in the 2008 Standard ?

Well, some people did - but a hell of a lot didn't!


More seriously, there are perfectly good mechanisms for dealing with
KIND in MPI that eliminates any need for #if: MPI_Type_create_f90_real
and all that.  There are issues that it doesn't resolve (including the
one you mention below), but #if doesn't help with them either.

I've been working with MPI since the mid-90's - surely by now it should be replaced by something compilers understand beyond "well, I have an external procedure here - hope the programmer got its arguments correct" ....

Well, yes, but coarrays aren't that. They DO get the type checking right, but at the cost of introducing potential, almost undetectable, race conditions where most MPI code can be proved not to have them. I don't consider that a gain. But that's off-topic for here.

Harking back to gfortran.  One of the things on my list is whether I
could extend it enough (in an interoperability-style mode) enough to
resolve this issue, and introduce the ability to have type-checked
MPI.  I could parse the (trivial) extra syntax with trivial hacks,
but got bogged down trying to understand how the code generation
works, and didn't have time to reverse engineer it :-(  But it could
be done.


Regards, Nick Maclaren.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]