Re: Bug 84894 - [F2018] provide iso_fortran_binding.h

Re: Bug 84894 - [F2018] provide iso_fortran_binding.h

[Dominique d'Humières]

[-- Attachment #1: Type: text/plain, Size: 283 bytes --]

In my last fortran-dev install I see a file

intall_dir/lib/gcc/x86_64-apple-darwin15.6.0/7.0.0/include/ISO_Fortran_binding.h

I am attaching. Could you please check

(1) if it provides what you need for MPICH 3.2?

(2) if it does need some change(s)?

TIA

Dominique


[-- Attachment #2: ISO_Fortran_binding.h --]
[-- Type: application/octet-stream, Size: 8389 bytes --]

/* ISO_Fortran_binding.h of GCC's GNU Fortran compiler.
   Copyright (C) 2013 Free Software Foundation, Inc.

This file is part of the GNU Fortran runtime library (libgfortran)
Libgfortran is free software; you can redistribute it and/or
modify it under the terms of the GNU Library General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later version.

Libgfortran is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
Library General Public License for more details.

You should have received a copy of the GNU Library General Public
License along with libquadmath; see the file COPYING.LIB.  If
not, write to the Free Software Foundation, Inc., 51 Franklin Street
- Fifth Floor, Boston, MA 02110-1301, USA.  */


/* Definitions as defined by ISO/IEC Technical Specification TS 29113:2012
   on Further Interoperability of Fortran with C.

   Note: This header file contains some GCC-specific CFI_type macros.
   Additionally, the order of elements in CFI_cdesc_t (except of the
   first three) and of CFI_dim_t is not defined by TS29113 - and both
   are permitted to have extra fields.  */


#ifndef ISO_FORTRAN_BINDING_H
#define ISO_FORTRAN_BINDING_H

#ifdef __cplusplus
extern "C" {
#endif

#include <stddef.h>  /* For size_t and ptrdiff_t.  */
#include <stdint.h>  /* For int32_t etc.  */


/* Constants, defined as macros.  */

#define CFI_VERSION 1
#define CFI_MAX_RANK 15

/* Attribute values.  */

#define CFI_attribute_pointer 1
#define CFI_attribute_allocatable 2
#define CFI_attribute_other 3

/* Error status codes.  */

#define CFI_SUCCESS 0
#define CFI_ERROR_BASE_ADDR_NULL 1
#define CFI_ERROR_BASE_ADDR_NOT_NULL 2
#define CFI_INVALID_ELEM_LEN 3
#define CFI_INVALID_RANK 4
#define CFI_INVALID_TYPE 5
#define CFI_INVALID_ATTRIBUTE 6
#define CFI_INVALID_EXTENT 7
#define CFI_INVALID_DESCRIPTOR 8
#define CFI_ERROR_MEM_ALLOCATION 9
#define CFI_ERROR_OUT_OF_BOUNDS 10


/* Types definitions.  */

typedef ptrdiff_t CFI_index_t;
typedef int8_t CFI_rank_t;
typedef int8_t CFI_attribute_t;
typedef int16_t CFI_type_t;


typedef struct CFI_dim_t
{
  CFI_index_t lower_bound;
  CFI_index_t extent;
  CFI_index_t sm;
}
CFI_dim_t;

typedef struct CFI_cdesc_t
{
  void *base_addr;
  size_t elem_len;
  int version;
  CFI_rank_t rank;
  CFI_attribute_t attribute;
  CFI_type_t type;
  size_t offset;
  CFI_dim_t dim[];
}
CFI_cdesc_t;


/* Extension: CFI_CDESC_T but with an explicit type.  */

#define CFI_CDESC_TYPE_T(r, base_type) \
struct {\
  base_type *base_addr;\
  size_t elem_len;\
  int version; \
  CFI_rank_t rank; \
  CFI_attribute_t attribute; \
  CFI_type_t type;\
  size_t offset;\
  CFI_dim_t dim[r];\
}

#define CFI_CDESC_T(r) CFI_CDESC_TYPE_T (r, void)


/* Functions. */

void *CFI_address (const CFI_cdesc_t *, const CFI_index_t []);
int CFI_allocate (CFI_cdesc_t *, const CFI_index_t [], const CFI_index_t [],
		  size_t);
int CFI_deallocate (CFI_cdesc_t *);
int CFI_establish (CFI_cdesc_t *, void *, CFI_attribute_t, CFI_type_t, size_t,
		   CFI_rank_t, const CFI_index_t []);
int CFI_is_contiguous (const CFI_cdesc_t *);
int CFI_section (CFI_cdesc_t *, const CFI_cdesc_t *, const CFI_index_t [],
		 const CFI_index_t [], const CFI_index_t []);
int CFI_select_part (CFI_cdesc_t *, const CFI_cdesc_t *, size_t, size_t);
int CFI_setpointer (CFI_cdesc_t *, CFI_cdesc_t *, const CFI_index_t []);


/* Types. Consisting of the type and the kind number. */

#define CFI_type_mask 0xFF
#define CFI_type_kind_shift 8

/* Intrinsic types - not to be used directly.  */

#define CFI_type_Integer 1
#define CFI_type_Logical 2
#define CFI_type_Real 3
#define CFI_type_Complex 4
#define CFI_type_Character 5

/* Types without kind paramter.   */

#define CFI_type_struct 6
#define CFI_type_cptr 7
#define CFI_type_cfunptr 8
#define CFI_type_other -1


/* Types with kind parameter; usually the kind is the same as the byte size.
   Exception is  REAL(10) which has a size of 64 bytes but only 80 bits
   precision.  And for complex variables, their byte size is twice the kind
   number (except for complex(10)).  The ucs4_char matches wchar_t
   if sizeof (wchar_t) == 4.  */

#define CFI_type_char (CFI_type_Character + (1 << CFI_type_kind_shift))
#define CFI_type_ucs4_char (CFI_type_Character + (4 << CFI_type_kind_shift))

/* TS 29113 types.  */

#define CFI_type_signed_char (CFI_type_Integer + (1 << CFI_type_kind_shift))
#define CFI_type_short (CFI_type_Integer + (2 << CFI_type_kind_shift))
#define CFI_type_int (CFI_type_Integer + (4 << CFI_type_kind_shift))
#define CFI_type_long (CFI_type_Integer + (8 << CFI_type_kind_shift))
#define CFI_type_long_long (CFI_type_Integer + (8 << CFI_type_kind_shift))
#define CFI_type_size_t (CFI_type_Integer + (8 << CFI_type_kind_shift))
#define CFI_type_int8_t (CFI_type_Integer + (1 << CFI_type_kind_shift))
#define CFI_type_int16_t (CFI_type_Integer + (2 << CFI_type_kind_shift))
#define CFI_type_int32_t (CFI_type_Integer + (4 << CFI_type_kind_shift))
#define CFI_type_int64_t (CFI_type_Integer + (8 << CFI_type_kind_shift))
#define CFI_type_int_least8_t (CFI_type_Integer + (1 << CFI_type_kind_shift))
#define CFI_type_int_least16_t (CFI_type_Integer + (2 << CFI_type_kind_shift))
#define CFI_type_int_least32_t (CFI_type_Integer + (4 << CFI_type_kind_shift))
#define CFI_type_int_least64_t (CFI_type_Integer + (8 << CFI_type_kind_shift))
#define CFI_type_int_fast8_t (CFI_type_Integer + (1 << CFI_type_kind_shift))
#define CFI_type_int_fast16_t (CFI_type_Integer + (2 << CFI_type_kind_shift))
#define CFI_type_int_fast32_t (CFI_type_Integer + (4 << CFI_type_kind_shift))
#define CFI_type_int_fast64_t (CFI_type_Integer + (8 << CFI_type_kind_shift))
#define CFI_type_intmax_t (CFI_type_Integer + (8 << CFI_type_kind_shift))
#define CFI_type_intptr_t (CFI_type_Integer + (8 << CFI_type_kind_shift))
#define CFI_type_ptrdiff_t (CFI_type_Integer + (8 << CFI_type_kind_shift))
#define CFI_type_int128_t (CFI_type_Integer + (16 << CFI_type_kind_shift))
#define CFI_type_int_least128_t (CFI_type_Integer + (16 << CFI_type_kind_shift))
#define CFI_type_int_fast128_t (CFI_type_Integer + (16 << CFI_type_kind_shift))
#define CFI_type_Bool (CFI_type_Logical + (1 << CFI_type_kind_shift))
#define CFI_type_float (CFI_type_Real + (4 << CFI_type_kind_shift))
#define CFI_type_double (CFI_type_Real + (8 << CFI_type_kind_shift))
#define CFI_type_long_double (CFI_type_Real + (10 << CFI_type_kind_shift))
#define CFI_type_float128 (CFI_type_Real + (16 << CFI_type_kind_shift))
#define CFI_type_float_Complex (CFI_type_Complex + (4 << CFI_type_kind_shift))
#define CFI_type_double_Complex (CFI_type_Complex + (8 << CFI_type_kind_shift))
#define CFI_type_long_double_Complex (CFI_type_Complex + (10 << CFI_type_kind_shift))
#define CFI_type_float128_Complex (CFI_type_Complex + (16 << CFI_type_kind_shift))

/* gfortran intrinsic non-character types.  */

#define CFI_type_Integer1 (CFI_type_Integer + (1 << CFI_type_kind_shift))
#define CFI_type_Integer2 (CFI_type_Integer + (2 << CFI_type_kind_shift))
#define CFI_type_Integer4 (CFI_type_Integer + (4 << CFI_type_kind_shift))
#define CFI_type_Integer8 (CFI_type_Integer + (8 << CFI_type_kind_shift))
#define CFI_type_Integer16 (CFI_type_Integer + (16 << CFI_type_kind_shift))
#define CFI_type_Logical1 (CFI_type_Logical + (1 << CFI_type_kind_shift))
#define CFI_type_Logical2 (CFI_type_Logical + (2 << CFI_type_kind_shift))
#define CFI_type_Logical4 (CFI_type_Logical + (4 << CFI_type_kind_shift))
#define CFI_type_Logical8 (CFI_type_Logical + (8 << CFI_type_kind_shift))
#define CFI_type_Logical16 (CFI_type_Logical + (16 << CFI_type_kind_shift))
#define CFI_type_Real4 (CFI_type_Real + (4 << CFI_type_kind_shift))
#define CFI_type_Real8 (CFI_type_Real + (8 << CFI_type_kind_shift))
#define CFI_type_Real10 (CFI_type_Real + (10 << CFI_type_kind_shift))
#define CFI_type_Real16 (CFI_type_Real + (16 << CFI_type_kind_shift))
#define CFI_type_Complex4 (CFI_type_Complex + (4 << CFI_type_kind_shift))
#define CFI_type_Complex8 (CFI_type_Complex + (8 << CFI_type_kind_shift))
#define CFI_type_Complex10 (CFI_type_Complex + (10 << CFI_type_kind_shift))
#define CFI_type_Complex16 (CFI_type_Complex + (16 << CFI_type_kind_shift))

#ifdef __cplusplus
}
#endif

#endif  /* ISO_FORTRAN_BINDING_H */

Re: Bug 84894 - [F2018] provide iso_fortran_binding.h

[Damian Rouson]

 
Dominique, thanks for sending the ISO_Fortran_binding.h file. Could you give me some guidance on where to install it to see if it satisfies the needs of the MPICH installation scripts?  

Jeff, do you have (or would you write) a simple program I can use for testing purposes. I checked the MPI-3.1 standard, but the examples I see there aren’t complete. They omit lots of arguments in the MPI calls. I’m sure I could fumble my way to a working example, but I’m hoping there exists something simple as a starting point.  So far, the only example I’ve found is so simple that it doesn’t even do any communication: 

http://mailman.cse.ohio-state.edu/pipermail/mvapich-discuss/2013-December/004724.html

Even just for instructional purposes, it would be nice to have some a little more involved — at least something that does communication.

Damian



On March 16, 2018 at 3:31:53 AM, Dominique d'Humières (dominiq@lps.ens.fr(mailto:dominiq@lps.ens.fr)) wrote:

> In my last fortran-dev install I see a file
>  
> intall_dir/lib/gcc/x86_64-apple-darwin15.6.0/7.0.0/include/ISO_Fortran_binding.h
>  
> I am attaching. Could you please check
>  
> (1) if it provides what you need for MPICH 3.2?
>  
> (2) if it does need some change(s)?
>  
> TIA
>  
> Dominique
>  

Re: Bug 84894 - [F2018] provide iso_fortran_binding.h

[Jeff Hammond]

On Mon, Mar 19, 2018 at 4:05 PM, Damian Rouson <damian@sourceryinstitute.org
> wrote:

>
> Dominique, thanks for sending the ISO_Fortran_binding.h file. Could you
> give me some guidance on where to install it to see if it satisfies the
> needs of the MPICH installation scripts?
>
> Jeff, do you have (or would you write) a simple program I can use for
> testing purposes. I checked the MPI-3.1 standard, but the examples I see
> there aren’t complete. They omit lots of arguments in the MPI calls. I’m
> sure I could fumble my way to a working example, but I’m hoping there
> exists something simple as a starting point.  So far, the only example I’ve
> found is so simple that it doesn’t even do any communication:
>
>
Try test/mpi/f08 in the MPICH repo.

Jeff


> http://mailman.cse.ohio-state.edu/pipermail/mvapich-discuss/
> 2013-December/004724.html
>
> Even just for instructional purposes, it would be nice to have some a
> little more involved — at least something that does communication.
>
> Damian
>
>
>
> On March 16, 2018 at 3:31:53 AM, Dominique d'Humières (dominiq@lps.ens.fr
> (mailto:dominiq@lps.ens.fr)) wrote:
>
> > In my last fortran-dev install I see a file
> >
> > intall_dir/lib/gcc/x86_64-apple-darwin15.6.0/7.0.0/
> include/ISO_Fortran_binding.h
> >
> > I am attaching. Could you please check
> >
> > (1) if it provides what you need for MPICH 3.2?
> >
> > (2) if it does need some change(s)?
> >
> > TIA
> >
> > Dominique
> >
>
>


-- 
Jeff Hammond
jeff.science@gmail.com
http://jeffhammond.github.io/

Re: Bug 84894 - [F2018] provide iso_fortran_binding.h

[Damian Rouson]

On March 20, 2018 at 7:14:31 AM, Vladimír Fuka (vladimir.fuka@gmail.com) wrote:

> In my last fortran-dev install I see a file 

> intall_dir/lib/gcc/x86_64-apple-darwin15.6.0/7.0.0/include/ISO_Fortran_binding.h 

> I am attaching. Could you please check 


Dominique, 

is the header compatible with the current array descriptor for GCC8? 
I assume it’s not compatible because the header file was written years ago and the new descriptors were communities on 25 January 2018.  First, I’m hoping to just check whether MPICH will recognize it and progress to the next step so that I can ensure whether there is also another issue that crops up.  Even if MPICH accepts the file and attempts to use it, I’m sure there will be many test failures because of the descriptor change and other forms of bit rot.

Damian

Re: Bug 84894 - [F2018] provide iso_fortran_binding.h

[Vladimír Fuka]

> In my last fortran-dev install I see a file

> intall_dir/lib/gcc/x86_64-apple-darwin15.6.0/7.0.0/include/ISO_Fortran_binding.h

> I am attaching. Could you please check


Dominique,

is the header compatible with the current array descriptor for GCC8?

Sorry if I am completely off, I have taken a lot of time off from
lurking here and I know very little of gfortran internals.

  Vladimir

Re: Bug 84894 - [F2018] provide iso_fortran_binding.h

[Jeff Hammond]

On Thu, Mar 15, 2018 at 9:31 PM, Steve Kargl <
sgk@troutmask.apl.washington.edu> wrote:

> On Thu, Mar 15, 2018 at 07:45:24PM -0700, Jeff Hammond wrote:
> >
> > Is it your intent to filibuster this feature and prevent
> > gfortran from supporting MPI-3 or do you want to have a
> > constructive conversation where we talk about things that
> > benefit users?
>
> I don't speak for gfortran/gcc development or developers.
>
> I am not preventing a feature.  Anyone, including you, are
> more than welcomed to submit a patch.  iso_fortran_binding.h
> won't be in gcc 8.1 as it is too late in the development
> cycle.  I also predict, that unless Anyone, including you,
> step up to plate that this header won't appear for a very
> long time in gfortran.  It's quite simple.  Too many bugs
> and features to implement, too few developers.
>

Have you analyzed Tobias' patch from 2013 that implements this?  What
issues did you find?

https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=198447


> I simply find it odd that MPI 3.1 implemented a module
> named mpi_f08 that uses features not included in the
> F2008 Standard.
>

ISO Fortran committee members were intimately involved in the development
of the mpi_f08 module.  You are welcome to question them about this.  I
honestly don't remember any debate about the name.  The MPI Forum does not
bikeshed names.

I fix bugs in gfortran as a hobby.  29 bugs since the
> beginning of the year.  The oldest was 10 years old.  The
> newest bug was 9 days old.  I've reviewed a number of
> patches from other contributors as they have reviewed
> my patches.
>

I sincerely appreciate your effort.  While I'm no longer dependent on
gfortran, many users of the applications I develop are, and it is essential
to the HPC enterprise that we have a good free Fortran compiler.


> As to filibustering, I have no intension of implementing
> iso_fortran_binding.h.   If Anyone, including you or
> someone associated with OpenCoarray, implements
> iso_fortran_binding.h before close of stage 4 for gcc
> 8.1, I will review the patch and help shepard it into
> the tree.
>

I'll likely contribute to testing it.  I'm hoping the OpenCoarrays team
will do the real work of implementing it.


> The ball is in your court.
>

A link to a six year-old implementation of the desired feature was included
in the first email in this thread.  The next step in the process is for
people to review that and describe the changes required for it to be
merged.  I can only assume that there was a reason why it was never merged,
but I don't have that information.

Jeff

-- 
Jeff Hammond
jeff.science@gmail.com
http://jeffhammond.github.io/

Re: Bug 84894 - [F2018] provide iso_fortran_binding.h

[Steve Kargl]

On Thu, Mar 15, 2018 at 07:45:24PM -0700, Jeff Hammond wrote:
> 
> Is it your intent to filibuster this feature and prevent
> gfortran from supporting MPI-3 or do you want to have a
> constructive conversation where we talk about things that
> benefit users?

I don't speak for gfortran/gcc development or developers.

I am not preventing a feature.  Anyone, including you, are
more than welcomed to submit a patch.  iso_fortran_binding.h
won't be in gcc 8.1 as it is too late in the development 
cycle.  I also predict, that unless Anyone, including you,
step up to plate that this header won't appear for a very
long time in gfortran.  It's quite simple.  Too many bugs
and features to implement, too few developers.

I simply find it odd that MPI 3.1 implemented a module
named mpi_f08 that uses features not included in the
F2008 Standard.

I fix bugs in gfortran as a hobby.  29 bugs since the
beginning of the year.  The oldest was 10 years old.  The
newest bug was 9 days old.  I've reviewed a number of
patches from other contributors as they have reviewed
my patches.

As to filibustering, I have no intension of implementing
iso_fortran_binding.h.   If Anyone, including you or
someone associated with OpenCoarray, implements 
iso_fortran_binding.h before close of stage 4 for gcc 
8.1, I will review the patch and help shepard it into
the tree.

The ball is in your court.

-- 
Steve

Re: Bug 84894 - [F2018] provide iso_fortran_binding.h

[Jeff Hammond]

Sorry, I meant J3 not J5 but in any case,
http://mpi-forum.org/docs/mpi-3.1/mpi31-report/node409.htm contains this:

===================

*Rationale.*

The features in TS 29113 on further interoperability with C were decided on
by ISO/IEC JTC1/SC22/WG5 and designed by PL22.3 (formerly J3) to support a
higher level of integration between Fortran-specific features and C than
was provided in the Fortran 2008 standard; part of this design is based on
requirements from the MPI Forum to support MPI-3.0. According to [41
<http://mpi-forum.org/docs/mpi-3.1/mpi31-report/node522.htm#-Bib41>], ``an
ISO/IEC TS is reviewed after three years in order to decide whether it will
be confirmed for a further three years, revised to become an International
Standard, or withdrawn. If the ISO/IEC TS is confirmed, it is reviewed
again after a further three years, at which time it must either be
transformed into an International Standard or be withdrawn.''

The TS 29113 contains the following language features that are needed for
the MPI bindings in the mpi_f08 module: assumed-type and assumed-rank. It
is important that any possible actual argument can be used for such dummy
arguments, e.g., scalars, arrays, assumed-shape arrays, assumed-size
arrays, allocatable arrays, and with any element type, e.g., REAL,
CHARACTER*5, CHARACTER*(*), sequence derived types, or BIND(C) derived
types. Especially for backward compatibility reasons, it is important that
any possible actual argument in an implicit interface implementation of a
choice buffer dummy argument (e.g., with mpif.h without argument-checking)
can be used in an implementation with assumed-type and assumed-rank
argument in an explicit interface (e.g., with the mpi_f08 module).

A further feature useful for MPI is the extension of the semantics of the
ASYNCHRONOUSattribute: In F2003 and F2008, this attribute could be used
only to protect buffers of Fortran asynchronous I/O. With TS 29113, this
attribute now also covers asynchronous communication occurring within
library routines written in C.

The MPI Forum hereby wishes to acknowledge this important effort by the
Fortran PL22.3 and WG5 committee. (* End of rationale.*)

===================

When we voted this into MPI-3, we thought it was going to appear in Fortran
much sooner.

In any case, all of the Fortran compiler implementors that attend the MPI
Forum supported this.  IBM, Intel, and Cray implemented it rather quickly.

Jeff


On Thu, Mar 15, 2018 at 7:45 PM Jeff Hammond <jeff.science@gmail.com> wrote:

>
>
> > On Mar 15, 2018, at 7:07 PM, Steve Kargl <
> sgk@troutmask.apl.washington.edu> wrote:
> >
> >> On Thu, Mar 15, 2018 at 06:50:11PM -0700, Damian Rouson wrote:
> >>
> >>> On March 15, 2018 at 5:43:03 PM, Jeff Hammond (jeff.science@gmail.com
> (mailto:jeff.science@gmail.com)) wrote:
> >>>
> >>> It’s in TS29113. Look at
> https://gcc.gnu.org/onlinedocs/gfortran/Further-Interoperability-of-Fortran-with-C.html
> for details.
> >>>
> >>
> >> And the features described in TS29113 have been incorporated into the
> Fortran 2018 Draft International Standard available at
> http://isotc.iso.org/livelink/livelink?func=ll&objId=19442438&objAction=Open&viewType=1
> .
> >>
> >
> > The module name is mpi_f08 not mpi_f08_ts29113 or mpi_f18.
> > Seems strange to name a module with a moniker that identifies
> > a specific standard, which does not include the required
> > information.
>
> Please talk to one of the J5 members who was part of both MPI-3 and
> TS29113 efforts if you want the history.
>
> Is it your intent to filibuster this feature and prevent gfortran from
> supporting MPI-3 or do you want to have a constructive conversation where
> we talk about things that benefit users?
>
> Jeff

-- 
Jeff Hammond
jeff.science@gmail.com
http://jeffhammond.github.io/

Re: Bug 84894 - [F2018] provide iso_fortran_binding.h

[Jeff Hammond]

> On Mar 15, 2018, at 7:07 PM, Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:
> 
>> On Thu, Mar 15, 2018 at 06:50:11PM -0700, Damian Rouson wrote:
>> 
>>> On March 15, 2018 at 5:43:03 PM, Jeff Hammond (jeff.science@gmail.com(mailto:jeff.science@gmail.com)) wrote:
>>> 
>>> It’s in TS29113. Look at https://gcc.gnu.org/onlinedocs/gfortran/Further-Interoperability-of-Fortran-with-C.html for details.  
>>> 
>> 
>> And the features described in TS29113 have been incorporated into the Fortran 2018 Draft International Standard available at http://isotc.iso.org/livelink/livelink?func=ll&objId=19442438&objAction=Open&viewType=1.
>> 
> 
> The module name is mpi_f08 not mpi_f08_ts29113 or mpi_f18.  
> Seems strange to name a module with a moniker that identifies
> a specific standard, which does not include the required 
> information.

Please talk to one of the J5 members who was part of both MPI-3 and TS29113 efforts if you want the history.

Is it your intent to filibuster this feature and prevent gfortran from supporting MPI-3 or do you want to have a constructive conversation where we talk about things that benefit users?

Jeff

Re: Bug 84894 - [F2018] provide iso_fortran_binding.h

[Steve Kargl]

On Thu, Mar 15, 2018 at 06:50:11PM -0700, Damian Rouson wrote:
> 
> On March 15, 2018 at 5:43:03 PM, Jeff Hammond (jeff.science@gmail.com(mailto:jeff.science@gmail.com)) wrote:
> 
> > It’s in TS29113. Look at https://gcc.gnu.org/onlinedocs/gfortran/Further-Interoperability-of-Fortran-with-C.html for details.  
> >  
> 
> And the features described in TS29113 have been incorporated into the Fortran 2018 Draft International Standard available at http://isotc.iso.org/livelink/livelink?func=ll&objId=19442438&objAction=Open&viewType=1.
> 

The module name is mpi_f08 not mpi_f08_ts29113 or mpi_f18.  
Seems strange to name a module with a moniker that identifies
a specific standard, which does not include the required 
information.

-- 
Steve

Re: Bug 84894 - [F2018] provide iso_fortran_binding.h

[Damian Rouson]

 



On March 15, 2018 at 5:43:03 PM, Jeff Hammond (jeff.science@gmail.com(mailto:jeff.science@gmail.com)) wrote:

> It’s in TS29113. Look at https://gcc.gnu.org/onlinedocs/gfortran/Further-Interoperability-of-Fortran-with-C.html for details.  
>  

And the features described in TS29113 have been incorporated into the Fortran 2018 Draft International Standard available at http://isotc.iso.org/livelink/livelink?func=ll&objId=19442438&objAction=Open&viewType=1.

Damian

Re: Bug 84894 - [F2018] provide iso_fortran_binding.h

[Jeff Hammond]

It’s in TS29113. Look at https://gcc.gnu.org/onlinedocs/gfortran/Further-Interoperability-of-Fortran-with-C.html for details. 

Jeff

> On Mar 15, 2018, at 5:24 PM, Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:
> 
>> On Thu, Mar 15, 2018 at 04:45:59PM -0700, Damian Rouson wrote:
>> 
>> 
>> This bug is being submitted to track progress and interest in this
>> feature and to preserve a link to the above file as a potential
>> starting point. The lack of iso_fortran_bindin.h currently blocks
>> MPICH 3.2 from providing gfortran users the mpi_f08 module that
>> the MPI 3.1 standard requires.
>> 
> 
> MPI 3.1 uses a header file that isn't in the Fortran
> 2008 Standard?  Seems like MPICH 3.2 will need to
> generate the header file for each compiler that it
> supports.  
> 
> -- 
> Steve

Re: Bug 84894 - [F2018] provide iso_fortran_binding.h

[Steve Kargl]

On Thu, Mar 15, 2018 at 04:45:59PM -0700, Damian Rouson wrote:

> 
> This bug is being submitted to track progress and interest in this
> feature and to preserve a link to the above file as a potential
> starting point. The lack of iso_fortran_bindin.h currently blocks
> MPICH 3.2 from providing gfortran users the mpi_f08 module that
> the MPI 3.1 standard requires.
> 

MPI 3.1 uses a header file that isn't in the Fortran
2008 Standard?  Seems like MPICH 3.2 will need to
generate the header file for each compiler that it
supports.  

-- 
Steve

Bug 84894 - [F2018] provide iso_fortran_binding.h

[Damian Rouson]

 
See below for the text of the above referenced bug report.

Damian  


Fortran 2018 requires that compilers provide an iso_fortran_binding.h C header file for further interoperability with C. Such a file was on the fortran-dev branch in 2013: 

https://gcc.gnu.org/viewcvs/gcc/branches/fortran-dev/libgfortran/ISO_Fortran_binding.h.tmpl?&view=markup#l1

This bug is being submitted to track progress and interest in this feature and to preserve a link to the above file as a potential starting point. The lack of iso_fortran_bindin.h currently blocks MPICH 3.2 from providing gfortran users the mpi_f08 module that the MPI 3.1 standard requires. 

Damian