[petsc-users] Problems with DMDAVecGetArrayF90 + Intel

[Jed Brown]

Satish Balay <balay at mcs.anl.gov> writes:

> On Tue, 15 May 2018, Jed Brown wrote:
>
>> > Your notation requires the following change
>> >
>> > PETSC_EXTERN void PETSC_STDCALL dmdavecgetarrayf901_(DM *da,Vec *v,F90Array1d *a,PetscErrorCode *ierr PETSC_F90_2PTR_PROTO(ptrd))
>> > PETSC_EXTERN PetscErrorCode F90Array1dCreate(void*,MPI_Datatype,PetscInt,PetscInt,F90Array1d* PETSC_F90_2PTR_PROTO_NOVAR);
>> >
>> > to:
>> >
>> > PETSC_EXTERN void PETSC_STDCALL dmdavecgetarrayf901_(DM *da,Vec *v,F90Array1d a,PetscErrorCode *ierr PETSC_F90_2PTR_PROTO(ptrd))
>> > PETSC_EXTERN PetscErrorCode F90Array1dCreate(void*,MPI_Datatype,PetscInt,PetscInt,F90Array1d PETSC_F90_2PTR_PROTO_NOVAR);
>> 
>> Yes.
>> 
>> > [this doesn't look right.] 
>> 
>> I don't know why not, 
>
> output argument without a explicit pointer in definition is weird for c - and can result in future bugs [when this code is changed]

The pointer is inside a typedef for all the basic PETSc types.

>> but I don't care about this narrow bit of
>> compiler-enforced type safety enough to push for the more intrusive fix.
>
> I'm not sure I understand what extra type safety is obtained by 'F90Array1d*' vs 'F90Array1d' usage
>
> Or does 'typedef struct { void *ptr; } F90Array3d;' give the extra safety? I could change this part of typedef.

Yeah, that's an alternative way to get a strong typedef, and you could
keep the other code unmodified.

typedef struct { char dummy; } F90Array1d;
typedef struct { char dummy; } F90Array2d;
typedef struct { char dummy; } F90Array3d;

These are all distinct types.  Better to use char for the dummy because
we don't have reason to know that the pointer is word aligned, but the
standard says that any data pointer can be cast to a char*.

>> 
>> > So I guess 'pointer to address (void*)' is the correct notation - as
>> > we pass these back to fortran calling routine wrt
>> > dmdavecgetarrayf901_() and an output argument for F90Array1dCreate().
>> 
>> It's actually just the pointer that we have.  The thing it points to is
>> of some type that is not known statically in F90Array1dCreate/Destroy.
>
> Yes. we get something opaque - and we pass it down to fortran utility routine or up to the calling fortran routine - unmodified.
>
> My current patch is at balay/fix-F90Array__Destroy/maint
>
> Satish