February 2013 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPI3 Fortran] Fwd: [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Tobias Burnus 28 Feb '13

28 Feb '13

N.M. Maclaren wrote: > Drop ALL of the BIND(C) from the functions, as they aren't currently > conforming. Plain INTEGER is not guaranteed to be > interoperable, and nor is DOUBLE PRECISION (Wtime, Wtick). I hope to > make default types more interoperable in the next standard, but > that hasn't even been discussed yet. That's probably the simplest. The actual implementation might even use C binding in this case, iff the Fortran interface is already interopable with C, e.g. integer matches "int" etc. For logicals, it could either make sure to only use the .true./.false. values for the Fortran compiler or to ensure other values are properly handled. [0 and 1 seems work correctly with all compilers I tested and might be a reasonable assumption for an implementation (but not the MPI spec itself).] Whether there is a bind(C) or not should undetectable from the user program. If the Fortran interface is not interoperable, the MPI implementation can then still use a wrapper. N.M. Maclaren wrote: > On Feb 28 2013, Craig Rasmussen wrote: >>> The real question is what (integer) value does .TRUE._C_BOOL have? Currently? My experience is that you get with most compilers 1 but with some compilers -1. >> Would great damage be done to the international standard gods if >> .TRUE._C_BOOL evaluates to the integer value 1? I guess the C >> programmer has to know what value (not processor dependent) to set it to. Well, the C99 standard states: "When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1." ("6.3.1.2 Boolean type"). > I can't see why it should be. It's not the solution I proposed, but is > in many ways simpler. I also do no see a problem with requiring that .TRUE._C_BOOL evaluates to 1. One could argue that the current standard (F2008 combined with C99) already mandates this for interoperability. (A clarification in the Fortran standard wouldn't harm, however.) (But I do not see how that would help. The problem with the current MPI specification is not that logical(C_BOOL) doesn't interoperate with _Bool but that it currently uses "LOGICAL", which is on most systems not the same as _Bool.) Bill Long wrote: > The fatal flaw in the MPI interface here is that the corresponding C > formal parameter is not _Bool or anything that looks like LOGICAL. > Instead it is 'int'. I mostly concur, except that the Fortran and the C code do not need to have the same data type. (Well, unless one insists that the binding name is the same, which the current MPI spec implies via "bind(C)".) If one doesn't require the same binding name, one could use logical(C_bool) or something else on the Fortran side ï¿½ while C uses "int". Craig Rasmussen wrote: > 1. Suppose a compiler has a default logical size equivalent to a > default integer. Since the standard only requires one logical kind, > this compiler may not have a type that is interoperable with a _Bool C > type. In this instance C_BOOL would be a negative value. As written, 32bit Darwin seems to use sizeof(_Bool) == 4 by default. And, thus, sizeof(int)==sizeof(_Bool). However, that doesn't imply that a compiler cannot support _Bool. It just means that _Bool only should have the values 0 and 1 while "int" can have any value. That's not different to the more common sizeof(_Bool) == 1, which is not the same as "signed char" even if both have the same size. In any case, the byte size is independent from whether the Fortran+accompanying C compiler supports _Bool or not (i.e. c_bool < 0). > 3. Suppose a Fortran compiler has the following mapping: > _Bool flag = 0; /* flag maps to .FALSE. */ > if (flag != 0) ...; /* flag maps to .TRUE. */ > This seems to me to be the sane way to map values from C to Fortran. > The same mapping can be done for any C integer type to an equivalently > sized Fortran LOGICAL. First, in C99, "flag != 0" is not a _Bool but an "int" (see C99, "6.5.9 Equality operators"). Secondly, is it completely unclear what you mean by "a Fortran compiler has". "flag != 0" is not a valid Fortran expression and whether the compiler translates a "logical(c_bool)" variable into assembler code which resembles "flag != 0" or not is really compiler dependent. A simple "if(flag)" on an x86 system will likely be translated into "jz" or "jnz" (jump if zero or jump if not zero); that will regard any nonzero integer as .true. However, ".not." can be implemented by flipping a single bit, if true is always "1" (or, e.g., "-1"). If the compiler expects 0 and 1 and flips the respective bit, then ".not." of "-1" will give "-2" which in conditions (via jz/jnz) is regarded as .true. as is -1. That issue occurs with GCC for Fortran's logicals (and also for C99's _Bool); seemingly, NAG's Fortran compiler does something similar in some cases. N.M. Maclaren wrote: > On Feb 28 2013, Craig Rasmussen wrote: >>> (3) Or one forces the compiler to accept also other values than >>> .true./.false. As with the previous item, it will affect also all >>> non-Bind(C) logicals. And C_Bool should presumably excluded as one >>> otherwise might get in trouble with the C compiler. >> >> It seems it has to anyway to be compatible with C. I don't have the >> C99 standard but it appears that there isn't a constant for "true" >> and "false" without including stdbool.h. Thus a Fortran compiler will >> have to anticipate values other than .true./.false. > > true and false are specified to be 1 and zero in stdbool.h. I think most C programmers regard them as canonical values for true and false - and use them as such. (It is also in line with C99's _Bool). Also from the Fortran side I would be fine with using those. (I am not sure whether all vendors would be.) However, it is nearly certain that most C programmer will assume that "int" <-> logical(c_int) will work such that any nonzero integer is regarded as .true., even if we write in the Fortran standard that only 1 and 0 are supported. That will lead to difficult to find wrong-code problems, which depend on the compiler, the optimization flag and the expression. >>> (4) Last, handling dummy arguments/result variables of BIND(C) >>> procedures differently. That probably would work, but it requires a >>> bunch of the careful addition of additional constraints. For >>> instance, to prohibit the TARGET/POINTER attribute for those. >> >> To me this is the only sane response given that C evaluates 0 to >> false and everything else to true. Nick you want to weigh in on the C >> standard. > > Tempting, but no. I will say that I can see no reason to prohibit the > TARGET/POINTER attribute according to whether BIND(C) is there. Do you mean in terms of the consistency/conciseness of the standard? Or in terms of a reason why it would be needed? I assume the former. But regarding the latter: Assume "-1" is passed to a "LOGICAL(kind=4), target :: dummy". Then "logical(kind=4), pointer :: ptr; ptr => dummy" will cause problems: Either "ptr" is "-1" but the compiler does not know that the value has to be treated in a special way. Or the compiler changes "ptr" to "1" on entering the BIND(C) procedure ï¿½ which gives a segfault if "-2" is in read-only memory. Or it creates a copy, which doesn't work as soon as the value is changed through "ptr" and read via "dummy" (or vice versa). Thus, prohibiting TARGET/POINTER seems to be required to allow for a different internal representation. I can perfectly understand that one doesn't want to go this route, but if one does, such a constraint seems to be required. Tobias

1 0

Re: [MPI3 Fortran] Fwd: [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by N.M. Maclaren 28 Feb '13

28 Feb '13

On Feb 28 2013, Tobias Burnus wrote: > >(a) LOGICAL(C_Bool) >This is interoperable with C99 _Bool and defined within the standard. >(One can argue how well-defined it is, esp. on the C99 side.) I think that it's truly horrible, as is anything to do with _Bool. >(b) Using INTEGER(C_INT) >That matches the C version's "int", but requires to use integers for >Boolean purposes and is odd with the the non-MPI_F08 version. Yes, but it's portable and reliable. >(c) Using LOGICAL without BIND(C) >That surely works, but it makes the work for the MPI implementation much >harder. Without BIND(C), there is no defined C interface and the >implementation has to be compiler specific. Especially for dimension(..) >and for passing characters (scalar, array, allocatable/pointer or >neither), different compilers will handle them differently. No, it doesn't have to be. It is easy to write a portable interface that calls the C. >(d) LOGICAL(C_INT) >This proposal requires a change of Fortran standard; It effectively >matches the current MPI 3 spec. For compilers which implement LOGICAL >internally as INTEGER, it is probably fine. However, some compilers >don't, e.g. GCC's and NAG's. Probably no chance, and certainly not in that form. C_BOOL_INT is technically possible, but I doubt that J3/WG5 would approve. >* Has someone an additional proposal? Yes. (e) Drop ALL of the BIND(C) from the functions, as they aren't currently conforming. Plain INTEGER is not guaranteed to be interoperable, and nor is DOUBLE PRECISION (Wtime, Wtick). I hope to make default types more interoperable in the next standard, but that hasn't even been discussed yet. My order is (e), (b), (c), (a) and (d). Regards, Nick Maclaren.

1 0

Re: [MPI3 Fortran] Fwd: [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Bill Long 28 Feb '13

28 Feb '13

In C when any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise the result is 1. (6.3.1.3 Boolean type). The value of C_BOOL as a Fortran KIND type for LOGICAL is such that 1) The bitsize of LOGICAL(C_BOOL) matches the bitsize of _Bool in C for the companion processor. 2) The Fortran processor uses the internal bit pattern in LOGICAL (C_BOOL) of 0 to represent false, and 1 to represent true. If both of these is true (which is the case for many implementations) then C_BOOL > 0. Otherwise C_BOOL will be negative, and there is no interoperability with C for LOGICAL. The fatal flaw in the MPI interface here is that the corresponding C formal parameter is not _Bool or anything that looks like LOGICAL. Instead it is 'int'. There is no concept of a Fortran argument of type LOGICAL interoperating with a C formal parameter of type int. Usage of that sort in an MPI interface is simply wrong. One side or the other of the call needs to be fixed. I would vote for changing the Fortran side to be type INTEGER(C_INT). Cheers, Bill On 2/28/13 12:29 PM, Craig Rasmussen wrote: > > Ack.... > > I just did a quick rereading of clause 15, Interoperability with C, and > it appears ill defined to me. Consider the following: > > 1. Suppose a compiler has a default logical size equivalent to a default > integer. Since the standard only requires one logical kind, this > compiler may not have a type that is interoperable with a _Bool C type. > In this instance C_BOOL would be a negative value. > 2. If a compiler does support LOGICAL(kind=C_BOOL), what values of a C > type _Bool map to .TRUE.? What values map to .FALSE.? These mappings > may be in clause 15 but I didn't see them at first glance. > 3. Suppose a Fortran compiler has the following mapping: > > _Bool flag = 0; /* flag maps to .FALSE. */ > > if (flag != 0) ...; /* flag maps to .TRUE. */ > > This seems to me to be the sane way to map values from C to Fortran. > The same mapping can be done for any C integer type to an equivalently > sized Fortran LOGICAL. > -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

1 0

Re: [MPI3 Fortran] Fwd: [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Craig Rasmussen 28 Feb '13

28 Feb '13

On Feb 28, 2013, at 11:47 AM, N.M. Maclaren wrote: > On Feb 28 2013, Craig Rasmussen wrote: >>> (3) Or one forces the compiler to accept also other values than .true./.false. As with the previous item, it will affect also all non-Bind(C) logicals. And C_Bool should presumably excluded as one otherwise might get in trouble with the C compiler. >> >> It seems it has to anyway to be compatible with C. I don't have the C99 standard but it appears that there isn't a constant for "true" and "false" without including stdbool.h. Thus a Fortran compiler will have to anticipate values other than .true./.false. > > true and false are specified to be 1 and zero in stdbool.h. > While Fortran can't rely on programmers including stdbool.h, these are at least well-defined values. -craig

1 0

Re: [MPI3 Fortran] Fwd: [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by N.M. Maclaren 28 Feb '13

28 Feb '13

On Feb 28 2013, Craig Rasmussen wrote: >> >> (3) Or one forces the compiler to accept also other values than >> .true./.false. As with the previous item, it will affect also all >> non-Bind(C) logicals. And C_Bool should presumably excluded as one >> otherwise might get in trouble with the C compiler. > > It seems it has to anyway to be compatible with C. I don't have the C99 > standard but it appears that there isn't a constant for "true" and > "false" without including stdbool.h. Thus a Fortran compiler will have to > anticipate values other than .true./.false. true and false are specified to be 1 and zero in stdbool.h. >> (4) Last, handling dummy arguments/result variables of BIND(C) >> procedures differently. That probably would work, but it requires a >> bunch of the careful addition of additional constraints. For instance, >> to prohibit the TARGET/POINTER attribute for those. > > To me this is the only sane response given that C evaluates 0 to false > and everything else to true. Nick you want to weigh in on the C standard. Tempting, but no. I will say that I can see no reason to prohibit the TARGET/POINTER attribute according to whether BIND(C) is there. Regards, Nick Maclaren.

1 0

Re: [MPI3 Fortran] Fwd: [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by N.M. Maclaren 28 Feb '13

28 Feb '13

On Feb 28 2013, Craig Rasmussen wrote: > >> The real question is what (integer) value does .TRUE._C_BOOL have? > > Would great damage be done to the international standard gods if > .TRUE._C_BOOL evaluates to the integer value 1? I guess the C programmer > has to know what value (not processor dependent) to set it to. I can't see why it should be. It's not the solution I proposed, but is in many ways simpler. Regards, Nick Maclaren.

1 0

Re: [MPI3 Fortran] Fwd: [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Craig Rasmussen 28 Feb '13

28 Feb '13

On Feb 28, 2013, at 11:14 AM, N.M. Maclaren wrote: > The real question is what (integer) value does .TRUE._C_BOOL have? Would great damage be done to the international standard gods if .TRUE._C_BOOL evaluates to the integer value 1? I guess the C programmer has to know what value (not processor dependent) to set it to. -craig

1 0

Re: [MPI3 Fortran] Fwd: [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by N.M. Maclaren 28 Feb '13

28 Feb '13

On Feb 28 2013, Craig Rasmussen wrote: > > I just did a quick rereading of clause 15, Interoperability with C, and > it appears ill defined to me. Consider the following: Yes. I hope to get these improved in the next standard. I have already made proposals to the UK, for consideration. > 1. Suppose a compiler has a default logical size equivalent to a default > integer. Since the standard only requires one logical kind, this compiler > may not have a type that is interoperable with a _Bool C type. In this > instance C_BOOL would be a negative value. That is correct. That would also be the case if it were a C90 compiler not a C99 one. > 2. If a compiler does support LOGICAL(kind=C_BOOL), what values of a > C type _Bool map to .TRUE.? What values map to .FALSE.? These mappings > may be in clause 15 but I didn't see them at first glance. No, but an interpretation would almost certainly say that any compiler that didn't treat zero as .FALSE. and non-zero as .TRUE. is non-conforming. Malcolm or Bill might correct me, but I doubt it :-) The real question is what (integer) value does .TRUE._C_BOOL have? Regards, Nick Maclaren.

1 0

Re: [MPI3 Fortran] Fwd: [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Craig Rasmussen 28 Feb '13

28 Feb '13

Craig Rasmussen CAS Scientific Programmer rasmus(a)cas.uoregon.edu Ack.... I just did a quick rereading of clause 15, Interoperability with C, and it appears ill defined to me. Consider the following: 1. Suppose a compiler has a default logical size equivalent to a default integer. Since the standard only requires one logical kind, this compiler may not have a type that is interoperable with a _Bool C type. In this instance C_BOOL would be a negative value. 2. If a compiler does support LOGICAL(kind=C_BOOL), what values of a C type _Bool map to .TRUE.? What values map to .FALSE.? These mappings may be in clause 15 but I didn't see them at first glance. 3. Suppose a Fortran compiler has the following mapping: _Bool flag = 0; /* flag maps to .FALSE. */ if (flag != 0) ...; /* flag maps to .TRUE. */ This seems to me to be the sane way to map values from C to Fortran. The same mapping can be done for any C integer type to an equivalently sized Fortran LOGICAL. Also see my specific comments below. -craig On Feb 28, 2013, at 7:10 AM, Tobias Burnus wrote: > Let my try to sum up the proposals in this thread: > > > (a) LOGICAL(C_Bool) > This is interoperable with C99 _Bool and defined within the standard. (One can argue how well-defined it is, esp. on the C99 side.) May not be interoperable as C_Bool may be negative. Is this even well defined on the Fortran side (see above)? > > > (b) Using INTEGER(C_INT) > That matches the C version's "int", but requires to use integers for Boolean purposes and is odd with the the non-MPI_F08 version. Here at least a programmer can provide something that is well defined and explicitly convert between integer and LOGICAL types. > > > Both (a) and (b) require special user handling, e.g. instead of ".true." one has to use ".true._c_bool" or (e.g.) "1"/"MPI_TRUE". In addition, they might cause problems with the MPI 3 goal: "In a single application, it must be possible to link together routines which USE mpi_f08, USE mpi, and INCLUDE 'mpif.h'." (page 598, 17.1 Fortran Support) > > > (c) Using LOGICAL without BIND(C) > That surely works, but it makes the work for the MPI implementation much harder. Without BIND(C), there is no defined C interface and the implementation has to be compiler specific. Especially for dimension(..) and for passing characters (scalar, array, allocatable/pointer or neither), different compilers will handle them differently. > This may be what MPI is forced to do. MPI provides a Fortran only binding for any interface with a Fortran LOGICAL dummy argument. We have to provide wrappers anyway so this can be done but makes a mess of the interfaces (some bind(C) some not) and makes it much more complex for MPI tool writers. > > (d) LOGICAL(C_INT) > This proposal requires a change of Fortran standard; It effectively matches the current MPI 3 spec. For compilers which implement LOGICAL internally as INTEGER, it is probably fine. However, some compilers don't, e.g. GCC's and NAG's. I just tested gfortran and Intel Fortran and they both provide LOGICAL(kind=kind(1)) although gfortran provides a WARNING unless tricked. > > (1) If one has a different kind value as the normal Fortran LOGICALs, it should work; i.e. kind(.true.) != C_BOOL_INT. But that defies the whole purpose and one could simply use version (a) – or (b). > > If one demands C_INT == C_BOOL_INT [or the support of LOGICAL(kind=kind(.true.))], I see three possibilities: > > (2) One is to only allow certain values like 0 or 1. This has two down sides: (a) it either forces the user to use the compiler-specific true/false values or the compiler to use some specified values (0 and 1 instead of 0 and -1), including for existing, non-BIND(C) code! (b) It probably will break sooner or later with user code, which uses different values on the C side. What does Fortran do now for C values? > > (3) Or one forces the compiler to accept also other values than .true./.false. As with the previous item, it will affect also all non-Bind(C) logicals. And C_Bool should presumably excluded as one otherwise might get in trouble with the C compiler. It seems it has to anyway to be compatible with C. I don't have the C99 standard but it appears that there isn't a constant for "true" and "false" without including stdbool.h. Thus a Fortran compiler will have to anticipate values other than .true./.false. > > (4) Last, handling dummy arguments/result variables of BIND(C) procedures differently. That probably would work, but it requires a bunch of the careful addition of additional constraints. For instance, to prohibit the TARGET/POINTER attribute for those. > To me this is the only sane response given that C evaluates 0 to false and everything else to true. Nick you want to weigh in on the C standard. > > * * * > > For me: (a), (c) and (d)(4) are acceptable solutions; I don't like (b) and (d)(1), and I strongly oppose (d)(2) and (d)(3). > > Tobias

1 0

Re: [MPI3 Fortran] Fwd: [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Tobias Burnus 28 Feb '13

28 Feb '13

Let my try to sum up the proposals in this thread: (a) LOGICAL(C_Bool) This is interoperable with C99 _Bool and defined within the standard. (One can argue how well-defined it is, esp. on the C99 side.) (b) Using INTEGER(C_INT) That matches the C version's "int", but requires to use integers for Boolean purposes and is odd with the the non-MPI_F08 version. Both (a) and (b) require special user handling, e.g. instead of ".true." one has to use ".true._c_bool" or (e.g.) "1"/"MPI_TRUE". In addition, they might cause problems with the MPI 3 goal: "In a single application, it must be possible to link together routines which USE mpi_f08, USE mpi, and INCLUDE 'mpif.h'." (page 598, 17.1 Fortran Support) (c) Using LOGICAL without BIND(C) That surely works, but it makes the work for the MPI implementation much harder. Without BIND(C), there is no defined C interface and the implementation has to be compiler specific. Especially for dimension(..) and for passing characters (scalar, array, allocatable/pointer or neither), different compilers will handle them differently. (d) LOGICAL(C_INT) This proposal requires a change of Fortran standard; It effectively matches the current MPI 3 spec. For compilers which implement LOGICAL internally as INTEGER, it is probably fine. However, some compilers don't, e.g. GCC's and NAG's. (1) If one has a different kind value as the normal Fortran LOGICALs, it should work; i.e. kind(.true.) != C_BOOL_INT. But that defies the whole purpose and one could simply use version (a) ï¿½ or (b). If one demands C_INT == C_BOOL_INT [or the support of LOGICAL(kind=kind(.true.))], I see three possibilities: (2) One is to only allow certain values like 0 or 1. This has two down sides: (a) it either forces the user to use the compiler-specific true/false values or the compiler to use some specified values (0 and 1 instead of 0 and -1), including for existing, non-BIND(C) code! (b) It probably will break sooner or later with user code, which uses different values on the C side. (3) Or one forces the compiler to accept also other values than .true./.false. As with the previous item, it will affect also all non-Bind(C) logicals. And C_Bool should presumably excluded as one otherwise might get in trouble with the C compiler. (4) Last, handling dummy arguments/result variables of BIND(C) procedures differently. That probably would work, but it requires a bunch of the careful addition of additional constraints. For instance, to prohibit the TARGET/POINTER attribute for those. * * * Thus, (a), (b) and (c) require MPI 3 changes. (c) is simple from the MPI spec side but puts the burden on the MPI implementers. And (d) requires changes of the Fortran standard (and possibly simpler changes on the MPI spec side). * Has someone an additional proposal? * Can you give a thump up/down for all the different proposals, allowing a straw vote and helping the MPI forum to decide which way to take? If (d) turns out to be favored, it probably makes sense to at least discuss it on the J3 list before the next meeting of the MPI forum, which is already in 11 days. * * * For me: (a), (c) and (d)(4) are acceptable solutions; I don't like (b) and (d)(1), and I strongly oppose (d)(2) and (d)(3). Tobias

1 0